Comments 17
И по моему скромному мнению, при наличии systemd, supervisor излишен.
Про systemd — согласен, но supervisor мне кажется более гибким (мне он еще и сообщения на почту шлёт, если пришлось перезапустить Storm). Но вообще это вопрос религии :-)
А как религия смотрит на установку питоновских модулей от рута (обновление pip и install supervisor)?
Чем supervisor-3.1.4 из EPEL не угодил?
Да, можно сделать через 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,…
А так, да, статься отличная, спасибо!
Хотя, справедливости ради, конкретно для запуска Storm подойдет даже 2.х, так что можно было и из Epel поставить
Стандартный вопрос. Почему не писать сразу логи в json и не засовывать сразу без обработчиков в elasticsearch?
А что если кластере капризнул и отказал принять ваши логи (это вполен нормально, ES не база данных и в стандарном виде скорее на чтение заточен чем на индексахию, да и при заточке, все бывает)… Вы напишете логику повтора после некторой задержки тоже сами?
Али что делать сели после написания 25-го сервиса всетаки решили немного переделать модель домента логов или просто новый индех создать, полезете править 25- боевых сервисов и передеплоить?
Всмысле? Писать то все равно стоит через logstash, но зачем на нем парсить, если можно писать логи так, что бы их не парсить?
Ок, тогда я вас не совсем понял, показалось что без logstash хотели…
Может тогда и вторая часть не совсем вам, но:
как же не парсить то, logstash этим то и занимается, парсит стринг и пишет в документ с соотвествующими полями…
И тут вам наверняка могут понадобится какие-то специфические поля, например id каких-то вещей. Вы можете начать выделять определенные события возможно с аттрибутами, тут можно много напарзить и важно подготовить правильно поля… Ну и представьте банальную реальность, все это просто не на greenfield а на легаси системе, с сервисами которые уже давно никто не ковырял и он даже не Loj4J2 логит.
А так же ИМХО вся фишка с ELK же в том, что вы свои логи можете отслеживать начиная "с клика по ссылке" и заканчивания вызовом како-го-то жесткого легаси или third party, вы строите логи абстрагируя от технологий, все логи и весь анализ в одном месте… В таком случае не только на log4j2, да и на java-сервисы замыкаться, многое терять..
Можно, но конкретно в этом случае в авторов log4j2. И у него есть вывод в json. Если можно использовать вывод в json и не парсить, зачем тогда сначала сохранять в тексте и потом еще парсить?
Я же не говорю не парсить совсем никогда, но там где можно, зачем парсить то?
Если нужно/можно писать напрямую из приложения в logstash -> ничего не мешает использовать json
На мой взгляд key-value гибче, т.к. в него можно завернуть любые логи. Например, тот же nginx в json писать будет довольно сложно научить. Ну и добавить новые поля можно в любое время, ничего не меняя в конфигурации принимающей стороны.
C log4j2 у меня опыта нет, но вот с nginx вы не угадали. Это делается довольно просто, вот так. Мне кажется, должен быть какой-то вариант научить log4j2 в однострочные json, вроде написать свой handler или что-то похожее.
Опять же, нет ничего гибче, чем json. У вас нет какого-то фильтра по полям на входе, вы просто записываете в elastic то, что вам прислали. А маппинг в еластике и так, и так нужно будет менять.
Как видите в статье:
filter {
kv {
source => "message"
recursive => "false"
add_tag => "%{loggerclass}"
}
}
мы не указываем какой-то конкретной конфигурации для каких либо items, просто говорим — ищи пары ключ-значения в поле message, ну а тэг — дело опциональное, хоть для Java и очень useful
Да, научить loj4j2 можно и я даже нашел соответствующий log4j2 appender на github, но пересобирать Storm с нужной jar'кой и потом еще писать и поддерживать CICD для этого процесса как-то стало лень, поэтому решил остановиться на key-value
Однако, возможно это тема для отдельной статьи или «второй редакции» этой статьи. Как будет время — соберу всё это и возможно напишу статью как логировать в json
Агрегация логов log4j2 средствами ELK