5.5.3 utc

[derandreasberger]

Hello! Please let me know how if you want to make a 5.5.3 build or if I should take care of a proper build myself (we need 5.5.3 due to ES SaaS constraints).

[derandreasberger]

Please wait with review - it was working in debug-environment, but with the final build on our stage-environment the order seems to be wrong again; I'm currently trying to figure out what's wrong...

[sivasamyk]

Sure. I was planning to remove display_timestamp in future releases. It was added initially as an option to show source timestamp. With message format support , this can be added as part of message if required. Logtrail will only use timestamp to filter and display in first column. I need to evaluate few more use cases and confirm.

…

On Wed, Sep 20, 2017 at 17:32 derandreasberger ***@***.***> wrote: Please wait with review - it was working in debug-environment, but with the final build on our stage-environment the order seems to be wrong again; I'm currently trying to figure out what's wrong... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZXeqrZ6TJUVxoP3OmfaDRWVBcQGEm1ks5skP7WgaJpZM4Pds0h> .

[derandreasberger]

@sivasamyk the branch is ok (besides the merge-conflict)! I just verified the live-tail and search works on our stage with enabled utc-flag (it was just that kibana is optimizing/bundling plugins which i was not aware of, so i neede to manually purge the cached bundle-js files for logtrail).
Using one timestamp-field only sounds like a good idea!

Here is the actual configuration I used for testing:
{ "index_patterns" : [ { "es": { "default_index": "nms-logs_*", "allow_url_parameter": false }, "tail_interval_in_seconds": 1, "es_index_time_offset_in_seconds": 0, "display_timezone": "local", "display_timestamp_format": "YYYY-MM-DD HH:mm:ss,SSS", "display_timestamp_force_sort": true, "utc_based_timestamp": true, "max_buckets": 500, "default_time_range_in_days" : 0, "max_hosts": 100, "max_events_to_keep_in_viewer": 5000, "fields" : { "mapping" : { "timestamp" : "log_date", "display_timestamp" : "log_date", "hostname" : "host", "program": "appname", "message": "message" }, "message_format": "{{{env}}} {{{message}}}" } } ] }

As long as the newly introduced flags display_timestamp_force_sort are not active the default-behaviour should not be affected, but my testing was focused on UTC due to our use-case.

[sivasamyk]

@derandreasberger Thanks for pull request. Will review and let you know my comments!