неверный часовой пояс в logstash/ELK/elasticsearch

Question

Я новичок в поиске эластичности и долгое время пытался решить вопрос ниже. Возможно, решение должно быть в документации - но это не :-(

У меня есть серверы, работающие в нескольких часовых поясах

Файлы журнала получают rsynced на серверы с различными часовыми поясами, но это легко. знать временную зону происхождения, либо полем часового пояса, например {«часовой пояс»: «UTC»}, либо самим форматом времени, например {"@timestamp": "2015-02-20T12: 11: 56.789Z"}

У меня есть полный контроль над файлами журнала и при необходимости можно их приспособить.

При использовании logstash - он изменяет формат времени на локальное время сервера t он работает. например "@timestamp" => "2015-02-21T22: 26: 24.920-08: 00"

Как я могу получить временную зону, последовательно взятую из исходного файла журнала, через журнал stash и в elasticsearch? (Очевидно - я захочу, чтобы это было в Кибане после этого). Я пробовал много вещей без успеха.

Заранее спасибо.

Answer 1

Моя цель состояла в том, чтобы создать _id в elasticsearch, что есть время протоколирования в нем - так, что он никогда не будет повторяться, даже если журнал снова отправляется через logstash

Бросив еще несколько часов на эту проблему - У меня есть некоторые выводы, которые, насколько мне известно, недостаточно хорошо документированы и рекомендуют работать.

1) Если в файле журнала есть часовой пояс - ничего не может быть сделано для его изменения в logstash. Поэтому - не тратьте время на часовые пояса или частичное совпадение или добавление часового пояса. Если время имеет Z в конце - тогда это будет GMT. Я думаю, что это ошибка, когда это происходит - предупреждение не выдается.

2) Выход Logstash для стандартного вывода/файла со временем в локальное время независимо от формата входной строки.

3) Logstash использует время в свое местное время - поэтому объединение времени в переменную становится испорченным - даже если исходная строка была GMT. поэтому просто не пытайтесь работать с переменной @timestamp !!!

4) эластичный поиск работает в GMT - поэтому он ведет себя правильно. Итак, то, что вы видите в выводе logstash как «@timestamp» => «2015-02-21T20: 26: 24.921-08: 00», правильно интерпретируется методом упругого поиска как «@timestamp» => «2015-02-21T12 : 26: 24.921Z»

так что моя работа вокруг выглядит следующим образом: 1) хранить журналы с временной меткой, НЕ @timestamp 2) последовательно экономить время в лог-файлы, как по Гринвичу и помечать их с задней Z 3) используйте фильтр даты в его базовой форме. Нет атрибута временной зоны

filter { 
    date { 
     match => ["log_time", "YYYY-MM-dd'T'HH:mm:ss.SSSZ"] 
     #timezone => "Etc/GMT-8" <--- THIS DOES NOT WORK IF THERE IS A Z IN SOURCE 
    } 
} 

4) Производите производные по времени непосредственно из переменной журнала - не из @timestamp. например

output { 
    stdout { codec => rubydebug } 
    elasticsearch { 
     host => localhost 
     document_id => "%{log_time}-%{host}" # <--- DO THIS 
     # document_id => "%{@timestamp}-%{host}" <--- DON'T DO THIS 
    } 
} 

Если Джордан Сиссель случается читать это - я считаю, что logstash должен соответствовать elasticsearch как по умолчанию - или, по крайней мере, есть возможность для вывода и работать внутри по Гринвичу. У меня было скалистое начало делать то, что каждый проходит, когда тестирует инструмент в первый раз с существующими журналами.