Timestamp parsing error with an out-of-the-box setup

Hi,

I’m running ES 1.7.1 with no configuration, Logstash 1.5.3 provides basic entries using stdin for test purpose, Windows 7 64b and Python 2.7.9 (also tested under 2.6).

Logstash self-generated timestamp has this kind of format:

2015-09-11T13:38:19.378Z

I’m not sure if the timezone part meets ISO 8601 requirements.

When running elastalert, parsing crashes for timezone, and stops the whole process:

Successfully loaded Example rule

Traceback (most recent call last):
  File "C:\Python27\Scripts\elastalert-test-rule-script.py", line 9, in <module>
    load_entry_point('elastalert==0.0.60', 'console_scripts', 'elastalert-test-rule')()
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\test_rule.py", line 289, in main
    test_instance.run_rule_test()
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\test_rule.py", line 284, in run_rule_test
    self.run_elastalert(rule_yaml, args)
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\test_rule.py", line 251, in run_elastalert
    client.run_rule(rule, endtime, starttime)
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\elastalert.py", line 494, in run_rule
    if not self.run_query(rule, rule['starttime'], tmp_endtime):
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\elastalert.py", line 376, in run_query
    data = self.get_hits(rule, start, end, index)
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\elastalert.py", line 268, in get_hits
    elastalert_logger.info("Queried rule %s from %s to %s: %s hits" % (rule['name'], pretty_ts(starttime, lt), pretty_ts(endtime, lt), len(hits)))
  File "C:\Python27\lib\site-packages\elastalert-0.0.60-py2.7.egg\elastalert\util.py", line 110, in pretty_ts
    dt.hour, padding, dt.minute, dt.tzname())
  File "build\bdist.win-amd64\egg\dateutil\tz.py", line 41, in inner_func
UnicodeDecodeError: 'ascii' codec can't decode byte 0x92 in position 22: ordinal not in range(128)

1. Does it really crash because of an incorrect TZ format?
2. Is there any way to make elastalert works with standard ES configuration?
3. If not, is there any tweak for self-generated Logstash timestamps?
4. Does this mean that if any of the ES entries have an incorrect TZ format, the whole process will crash instead of simply ignoring the faulty entry?
5. Am I wrong and missing something obvious?

Thanks in advance!

[Qmando]

Interesting. There’s nothing wrong with that timestamp. This looks like a bug in dateutil when using timezone’s that contain unicode characters.

It looks like this bug, https://bugs.launchpad.net/dateutil/+bug/1087306/+activity.

There are a two things I recommend you try. First, try upgrading python-dateutil to the most recent version. I might have a buggy version pinned. If that doesn’t work, an ugly fix is you can apply a patch to elastalert/util.py

diff --git a/elastalert/util.py b/elastalert/util.py
index de67126..4fb7525 100644
--- a/elastalert/util.py
+++ b/elastalert/util.py
@@ -98,6 +98,7 @@ def pretty_ts(timestamp, tz=True):
     """Pretty-format the given timestamp (to be printed or logged hereafter).
     If tz, the timestamp will be converted to local time.
     Format: MM-DD HH:MM TZ"""
+    return timestamp

to avoid printing out the local timezone information.

Let me know if either of these work for you.

[LeRiton]

Hi Quentin,

First, I confirm that everything works fine when downgrading dateutil. And yes you’re right, it seems very unlikely that ES will expose a malformed timestamp, EA processing should be fine.

We’re just starting to play with EA so no improvement idea for now, but I’ll tell you if anything show-up!