Comments 13
А какие-то реальные истории можете поведать нам, когда именно комплексное лог-решение, а-ля топик, помогло найти что-то что не было бы обнаружено иными средствами?
Или плюсы больше в сторону варианта «одним инструментом всё настрою», а-ля папеты/шефы?
Или плюсы больше в сторону варианта «одним инструментом всё настрою», а-ля папеты/шефы?
а вы предлагаете на каждой машине отдельно логи читать?
Для относительно больших потоков (более 1000 запросов в секунду), я к LS прикручиваю rabbitmq или redis (он пошустрее будет), что бы более-менне быть уверенным, что какие-то логи не потерялись.
Ещё как вариант делать логи сразу в формате json, тогда отпадает надобность использовать grok-шаблоны, что прилично нагружает CPU.
Используя grep-awk можно тоже всё найти из логов, но меня не устраивает их скорость, ну и хочется немного визуализации — напрмер графики. Logstash+Elasticsearch+Кибана меня устраивают во всём — скорость, удобство.
Как пример — один наш webserver генерирует более 40 миллионов строк логов в сутки. И есть ещё и куча других устройств создающих кучу всевозможных логов. Вручную что-то искать в них я уже не хочу и не буду.
Ещё как вариант делать логи сразу в формате json, тогда отпадает надобность использовать grok-шаблоны, что прилично нагружает CPU.
Используя grep-awk можно тоже всё найти из логов, но меня не устраивает их скорость, ну и хочется немного визуализации — напрмер графики. Logstash+Elasticsearch+Кибана меня устраивают во всём — скорость, удобство.
Как пример — один наш webserver генерирует более 40 миллионов строк логов в сутки. И есть ещё и куча других устройств создающих кучу всевозможных логов. Вручную что-то искать в них я уже не хочу и не буду.
Т.е. это в итоге даёт одно место по имени «логи» в которых искать удобно? Или ещё частично как мониторинг-средство используется?
И всё-таки, были ли случаи, когда что-то было найдено/поймано именно с помощью одного вот этого единого ридера? Я не админ, поэтому всех деталей предметной области не знаю.
И всё-таки, были ли случаи, когда что-то было найдено/поймано именно с помощью одного вот этого единого ридера? Я не админ, поэтому всех деталей предметной области не знаю.
Мониторинг скорее постфактум — случилось-посмотрел. Алерты однозначно требуют доработки. Сейчас надо после каждого изменения перегружать программу.
Были найдены случаи отказа работы некоторых веб-серверов — нашли 20-40 секундные пустоты, хотя в это время должно было быть около 500 запросов в секунду.
RSS фиды можно настроить на определённые события.
Были найдены случаи отказа работы некоторых веб-серверов — нашли 20-40 секундные пустоты, хотя в это время должно было быть около 500 запросов в секунду.
RSS фиды можно настроить на определённые события.
Мы делаем запрос к elastic search напрямую. Т.е. «А сколько у нас событий такого типа в течение часа?» — результат мониторим nagios/opsview, который говорит «О, больше 1000, значит это Error и надо уведомить админов». Очень эффективно. Плюс график Kibana висит постоянно на мониторах в офисе, так что волей не волей увидишь красный цвет в графиках :)
logstash в первую очередь прекрасен grok'ом, во вторую — логикой доставки распарсенных данных.
а в третью — большим количеством вариантов, куда можно полученные данные отправить. хочешь — в statsd, хочешь — в graylog2, а хочешь — в файл пиши.
у нас сложился немного отличающийся от автора подход использования logstash: мы им логи парсим, цифры вытаскиваем, но в какое-то централизованное хранилище пока не складываем.
в основном мы вытаскиваем метрики приложений и демонов с последующим выводом в statsd, который, в свою очередь, отправляет метрики в graphite для построения красивых графиков и в zabbix для алертов в случае выхода метрик за определенные пределы.
по сути получилась удобная замена наколенным скриптикам, которыми до этого парсились логи на предмет вытаскивания в мониторинг нужных цифр.
пока что вся эта конструкция в статусе, так сказать, опытного внедрения.
по архитектуре сделал вывод, что на небольших нагрузках можно вешать logstash с фильтром прямо на ноду с приложением, а там, где логов генерится много и/или и без того нехватка ресурсов — проще фигачить в связку «log -> rsyslog (udp) на logserver -> logstash+grok» или даже «log -> rsyslog (udp) -> logstash-shipper -> redis -> logstash+grok».
elastic для хранения логов пока не используем — хотя, в теории, это должно избавить от необходимости хранения гигабайтов логов на каждой машинке. впрочем, эта задача может прекрасно решаться средствами попроще.
а в третью — большим количеством вариантов, куда можно полученные данные отправить. хочешь — в statsd, хочешь — в graylog2, а хочешь — в файл пиши.
у нас сложился немного отличающийся от автора подход использования logstash: мы им логи парсим, цифры вытаскиваем, но в какое-то централизованное хранилище пока не складываем.
в основном мы вытаскиваем метрики приложений и демонов с последующим выводом в statsd, который, в свою очередь, отправляет метрики в graphite для построения красивых графиков и в zabbix для алертов в случае выхода метрик за определенные пределы.
по сути получилась удобная замена наколенным скриптикам, которыми до этого парсились логи на предмет вытаскивания в мониторинг нужных цифр.
пока что вся эта конструкция в статусе, так сказать, опытного внедрения.
по архитектуре сделал вывод, что на небольших нагрузках можно вешать logstash с фильтром прямо на ноду с приложением, а там, где логов генерится много и/или и без того нехватка ресурсов — проще фигачить в связку «log -> rsyslog (udp) на logserver -> logstash+grok» или даже «log -> rsyslog (udp) -> logstash-shipper -> redis -> logstash+grok».
elastic для хранения логов пока не используем — хотя, в теории, это должно избавить от необходимости хранения гигабайтов логов на каждой машинке. впрочем, эта задача может прекрасно решаться средствами попроще.
В статье просто описаны логические основы без красивой обвертки.
Но если это все централизировать и поднять Kibana — все выглядит очень даже достойно и удобно.
Как для продакшна, я считаю, подобная технология просто must have
В прочем и для девелопмента и тестирования очень удобно
Но если это все централизировать и поднять Kibana — все выглядит очень даже достойно и удобно.
Как для продакшна, я считаю, подобная технология просто must have
В прочем и для девелопмента и тестирования очень удобно
Есть какие-то отличия от стандартного syslog-ng? В нём есть тот же конвеер по обработке входящих логов.
syslog-ng настраивается для посылки определённых событий на центральный сервер, где все события обрабатываются и агрегируются по заданным признакам.
P.S. timukas посмотри ещё на Graylog2.
P.S. timukas посмотри ещё на Graylog2.
GL2 я смотрел и старые версии, и последнюю 0.10.Rc3.
Вещь не плохая, но сейчас там беда со stream'ами и quicksearch. Если есть кастомные поля в логах, то в них не работают regex. Это совсем не то что надо.
Но зато сделали наконец-то Drools. Возможно там сделаю отсылку алертов. Хотя тоже вариант не удобный — надо рестартит сервер, после изменений в файле.
Вещь не плохая, но сейчас там беда со stream'ами и quicksearch. Если есть кастомные поля в логах, то в них не работают regex. Это совсем не то что надо.
Но зато сделали наконец-то Drools. Возможно там сделаю отсылку алертов. Хотя тоже вариант не удобный — надо рестартит сервер, после изменений в файле.
Спасибо за статью, наткнулся совершенно случайно.
Узнал о logstash когда был на SCALE11, с тех пор используем его постоянно. Elastic Search позволяет делать невероятные вещи с поиском в реальном времени — парсим не только логи с ошибками, но и логи с метриками, на базе которых строим графики. Вручную или с помощью децентрализованных инструментов такое сделать просто нереально, поток данных — сотни и тысячи событий в секунду. Вообще, если задуматься, logstash сэкономил нам ОООчень много денег вместо того чтобы покупать Splunk.
Автоматизировал развертывание агента на Linux и Windows машины, описал в Puppet конфигурацию. Девелоперы знают, что если писать лог с суффиксом *logstash* то он будет подобран автоматически. Часто используем .json формат для записи структурированных данных.
Очень рекомендую, прекрасный продукт, прекрасное коммьюнити!
Узнал о logstash когда был на SCALE11, с тех пор используем его постоянно. Elastic Search позволяет делать невероятные вещи с поиском в реальном времени — парсим не только логи с ошибками, но и логи с метриками, на базе которых строим графики. Вручную или с помощью децентрализованных инструментов такое сделать просто нереально, поток данных — сотни и тысячи событий в секунду. Вообще, если задуматься, logstash сэкономил нам ОООчень много денег вместо того чтобы покупать Splunk.
Автоматизировал развертывание агента на Linux и Windows машины, описал в Puppet конфигурацию. Девелоперы знают, что если писать лог с суффиксом *logstash* то он будет подобран автоматически. Часто используем .json формат для записи структурированных данных.
Очень рекомендую, прекрасный продукт, прекрасное коммьюнити!
Sign up to leave a comment.
Собираем, парсим и отдаём логи с помощью Logstash