Как стать автором
Обновить

Комментарии 17

Я стараюсь всегда время брать из логов и записывать в timestamp, с помощью date filter. Иначе, при каких либо задержках или пакетных доставках, время события будет отличатся от времени записи.

И по моему скромному мнению, при наличии systemd, supervisor излишен.
Да, действительно ценное замечание по поводу даты из логов, однако, как Вы могли заметить у меня есть timestamp принятого сообщения и logdate филд внутри самого сообщения — это позволяет, в том числе, посмотреть на задержку в доставке сообщений (у меня в Grafana даже есть алерт, если какой-то хост начинает слишком долго доставлять логи)

Про systemd — согласен, но supervisor мне кажется более гибким (мне он еще и сообщения на почту шлёт, если пришлось перезапустить Storm). Но вообще это вопрос религии :-)
В timestamp по умолчанию проставляется время получения сообщения. И все графики и счётные метрики (количество событий в секунду и тп) будут прыгать от него. И когда много сообщений придут одновременно, в статистике получится всплеск, которого нет. Потому удобно синхронизировать logdate и timestamp.
Да, соглашусь. Возможно даже переделаю свои боевые настройки

А как религия смотрит на установку питоновских модулей от рута (обновление pip и install supervisor)?
Чем supervisor-3.1.4 из EPEL не угодил?

Статья, в общем-то не о supervisor, но так как это системный демон он работает от рута, т.к. должен иметь необходимость запускать процессы от имени других пользователей. То есть в данном случае религия позволяет использовать системный python и от root

Да, можно сделать через sudo, есть и другие варианты, вплоть до запуска storm внутри docker, раз уж он все равно используется.

Но, повторюсь, статья не о настройке supervisor, поэтому я эту часть упростил, ибо в реальности, лично у меня всё запускается более сложным образом, с участием систем конфигурации и с запуском каждого сервиса от своего пользователя, а те сервисы, что нужно изолировать, — изолированы через контейнеры

Но так-то мы тут о логировании

Мы о статье, да, но и об обмене опытом.
Я хочу понять, python-meld3 доступен только из EPEL, там же лежит готовый supervisor, почему бы просто не сделать yum install supervisor:


Installing:
 supervisor noarch 3.1.4-1.el7 epel 446 k
Installing for dependencies:
 python-meld3 x86_64 0.6.10-1.el7 epel 73 k

Если что-то делается сложно, этому должны быть причины.
Достаточно сказать что-то такое: "это дань истории, когда в репах была только вторая ветка, которая то ли ничего не умела, то ли умела плохо"… и это будет ответ)
… например с логированием в syslog,…


А так, да, статься отличная, спасибо!

У меня лично, но по совместительству и у компании, где я работаю, политика ставить всегда latest stable. Да, в ветку 3.1.х портируются фиксы из 3.3.х, но лучше таки иметь последнюю версию продукта

Хотя, справедливости ради, конкретно для запуска Storm подойдет даже 2.х, так что можно было и из Epel поставить

Стандартный вопрос. Почему не писать сразу логи в json и не засовывать сразу без обработчиков в elasticsearch?

Можно, но придётся немного пошаманить с regexp, так как стандартный input для Logstash не умеет обрабатывать JSON с переносами строки, а в Loj4J2 вполне себе могут быть Exception и Stack Trace, которые будут многострочными. Фильтр kv в данном случае корректно обработает любые значения

А что если кластере капризнул и отказал принять ваши логи (это вполен нормально, ES не база данных и в стандарном виде скорее на чтение заточен чем на индексахию, да и при заточке, все бывает)… Вы напишете логику повтора после некторой задержки тоже сами?
Али что делать сели после написания 25-го сервиса всетаки решили немного переделать модель домента логов или просто новый индех создать, полезете править 25- боевых сервисов и передеплоить?

Всмысле? Писать то все равно стоит через logstash, но зачем на нем парсить, если можно писать логи так, что бы их не парсить?

Ок, тогда я вас не совсем понял, показалось что без logstash хотели…
Может тогда и вторая часть не совсем вам, но:
как же не парсить то, logstash этим то и занимается, парсит стринг и пишет в документ с соотвествующими полями…
И тут вам наверняка могут понадобится какие-то специфические поля, например id каких-то вещей. Вы можете начать выделять определенные события возможно с аттрибутами, тут можно много напарзить и важно подготовить правильно поля… Ну и представьте банальную реальность, все это просто не на greenfield а на легаси системе, с сервисами которые уже давно никто не ковырял и он даже не Loj4J2 логит.
А так же ИМХО вся фишка с ELK же в том, что вы свои логи можете отслеживать начиная "с клика по ссылке" и заканчивания вызовом како-го-то жесткого легаси или third party, вы строите логи абстрагируя от технологий, все логи и весь анализ в одном месте… В таком случае не только на log4j2, да и на java-сервисы замыкаться, многое терять..

Можно, но конкретно в этом случае в авторов log4j2. И у него есть вывод в json. Если можно использовать вывод в json и не парсить, зачем тогда сначала сохранять в тексте и потом еще парсить?
Я же не говорю не парсить совсем никогда, но там где можно, зачем парсить то?

Это на самом деле не проблема ELK, это проблема log4j2, он не совсем корректно работает и не умеет pretty json, а logstash в свою очередь не умеет в multistring.

Если нужно/можно писать напрямую из приложения в logstash -> ничего не мешает использовать json

На мой взгляд key-value гибче, т.к. в него можно завернуть любые логи. Например, тот же nginx в json писать будет довольно сложно научить. Ну и добавить новые поля можно в любое время, ничего не меняя в конфигурации принимающей стороны.

C log4j2 у меня опыта нет, но вот с nginx вы не угадали. Это делается довольно просто, вот так. Мне кажется, должен быть какой-то вариант научить log4j2 в однострочные json, вроде написать свой handler или что-то похожее.


Опять же, нет ничего гибче, чем json. У вас нет какого-то фильтра по полям на входе, вы просто записываете в elastic то, что вам прислали. А маппинг в еластике и так, и так нужно будет менять.

В случае с форматом key=(value) не нужно, просто в случае необходимости добавить еще одну пару значений (например) username=(%username%) — просто начинаем слать её в логи и она автоматом подхватывается Logstash

Как видите в статье:
filter {
kv {
source => "message"
recursive => "false"
add_tag => "%{loggerclass}"
}
}

мы не указываем какой-то конкретной конфигурации для каких либо items, просто говорим — ищи пары ключ-значения в поле message, ну а тэг — дело опциональное, хоть для Java и очень useful

Да, научить loj4j2 можно и я даже нашел соответствующий log4j2 appender на github, но пересобирать Storm с нужной jar'кой и потом еще писать и поддерживать CICD для этого процесса как-то стало лень, поэтому решил остановиться на key-value

Однако, возможно это тема для отдельной статьи или «второй редакции» этой статьи. Как будет время — соберу всё это и возможно напишу статью как логировать в json
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.