Elastalert always display UTC timezone in alert_text

[andro42]

I spend quite some time to make this work. By default when using use_local_time: true in Alert Rule is ignored when you use it in Alert text (alert_text).
I would suggest to correct this in main solution.

But in the meantime for workarround I used this Custom Enhancement. I am using docker image.

mkdir enhancement
cd enhancement
nano my_enhancements.py

Script:

from elastalert.enhancements import BaseEnhancement
from dateutil.parser import parse
from dateutil import tz

class TimeEnhancement(BaseEnhancement):
    def process(self, match):
        # List the fields you want to transform from UTC to Local
        fields_to_convert = ['@timestamp', 'some_other_field']
        
        # This tells Python to use the server's current local timezone
        system_tz = tz.tzlocal()

        for field in fields_to_convert:
            if field in match:
                value = match[field]
                try:
                    if isinstance(value, str) and value.endswith('Z'):
                        # Parse the UTC string from Elasticsearch
                        dt = parse(value)
                        # Convert to the system's local time
                        local_dt = dt.astimezone(system_tz)
                        # 3. Create the NEW variable name (e.g., @timestamp_local)
                        new_field_name = f"{field}_local"
                        # Store the formatted local time in the new variable
                        match[new_field_name] = local_dt.strftime('%Y-%m-%d %H:%M:%S')
                except Exception:
                    # Skip if the field isn't a valid date string
                    continue

Rule:

name: ALERTRULE_test-alert-pysqlxe2
type: any
is_enabled: true
index: <index_name>*
timestamp_field: "@timestamp"
timestamp_type: "iso"
use_local_time: true
# Custom enhancement to show @timestamp in local time
match_enhancements:
  - "elastalert_modules.my_enhancements.TimeEnhancement"

num_events: 1
realert:
  minutes: 1
terms_size: 1
timeframe:
  minutes: 1

#filter:
#- query:
#    query_string:
#      query: "duration_ms > 200000"


alert_subject: "ElastAlert: {0} at {1}"
alert_subject_args:
  - rule_name
  - "@timestamp_local"
alert_text_type: alert_text_jinja
alert_text: |
  SQL Performance Alert: {{ rule_name }}
  
  Details:
  - Actual Count: {{ value }}
  - Alert time: {{ _data['@timestamp_local'] }}
  - Some Other Field: {{ some_other_field_local }}

....... Continue .........

Docker compose:

services:
  elastalert:
    image: ghcr.io/jertel/elastalert2/elastalert2
    container_name: elastalert
    restart: always
    command: ["--config", "/opt/elastalert/config.yaml", "--verbose"]
    volumes:
      - ./data/elastalert.yaml:/opt/elastalert/config.yaml
      - ./data/rules:/opt/elastalert/rules
      - ./data/certs:/opt/elastalert/certs
      - ./data/logs:/opt/elastalert/logs
      - ./data/smtp_auth.yaml:/opt/elastalert/smtp_auth.yaml
      - ./data/enhancement:/opt/elastalert/elastalert_modules
    networks:
      - es_default
    environment:
      - TZ=Europe/Berlin

networks:
  es_default:
    external: true
    name: es_default

sudo docker compose up

[jertel]

Each year there are a couple questions on this topic of showing localized times in alert messages. So I'm certainly not opposed to a permanent fix going into the product. However, there are some nuances. First, this would require the addition of a localized_<timestamp_field> to avoid breaking existing deployments that rely on the alert's <timestamp_field> to remain in UTC. Another complication is that many real-world events have other fields that also contain times, and I'm not sure that we could reliably find and convert all of them, because of the complex nature of nested fields, and differing date/time field types and formats. Yet another complication is that some people want the alerted time format to be different from the rule's configured time format. So there's likely not going to be a one-size-fits-all solution. That said, tackling the first point is the simplest and would probably help out a good portion of users that want localized timestamps in their alerts and aren't concerned with formatting or additional date/time fields.