Ads
Comments
А какие-то реальные истории можете поведать нам, когда именно комплексное лог-решение, а-ля топик, помогло найти что-то что не было бы обнаружено иными средствами?

Или плюсы больше в сторону варианта «одним инструментом всё настрою», а-ля папеты/шефы?
Для относительно больших потоков (более 1000 запросов в секунду), я к LS прикручиваю rabbitmq или redis (он пошустрее будет), что бы более-менне быть уверенным, что какие-то логи не потерялись.
Ещё как вариант делать логи сразу в формате json, тогда отпадает надобность использовать grok-шаблоны, что прилично нагружает CPU.
Используя grep-awk можно тоже всё найти из логов, но меня не устраивает их скорость, ну и хочется немного визуализации — напрмер графики. Logstash+Elasticsearch+Кибана меня устраивают во всём — скорость, удобство.
Как пример — один наш webserver генерирует более 40 миллионов строк логов в сутки. И есть ещё и куча других устройств создающих кучу всевозможных логов. Вручную что-то искать в них я уже не хочу и не буду.
Т.е. это в итоге даёт одно место по имени «логи» в которых искать удобно? Или ещё частично как мониторинг-средство используется?

И всё-таки, были ли случаи, когда что-то было найдено/поймано именно с помощью одного вот этого единого ридера? Я не админ, поэтому всех деталей предметной области не знаю.
Мониторинг скорее постфактум — случилось-посмотрел. Алерты однозначно требуют доработки. Сейчас надо после каждого изменения перегружать программу.

Были найдены случаи отказа работы некоторых веб-серверов — нашли 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 для хранения логов пока не используем — хотя, в теории, это должно избавить от необходимости хранения гигабайтов логов на каждой машинке. впрочем, эта задача может прекрасно решаться средствами попроще.
В статье просто описаны логические основы без красивой обвертки.
Но если это все централизировать и поднять Kibana — все выглядит очень даже достойно и удобно.

Как для продакшна, я считаю, подобная технология просто must have
В прочем и для девелопмента и тестирования очень удобно
Есть какие-то отличия от стандартного syslog-ng? В нём есть тот же конвеер по обработке входящих логов.
syslog-ng настраивается для посылки определённых событий на центральный сервер, где все события обрабатываются и агрегируются по заданным признакам.

P.S. timukas посмотри ещё на Graylog2.
GL2 я смотрел и старые версии, и последнюю 0.10.Rc3.
Вещь не плохая, но сейчас там беда со stream'ами и quicksearch. Если есть кастомные поля в логах, то в них не работают regex. Это совсем не то что надо.

Но зато сделали наконец-то Drools. Возможно там сделаю отсылку алертов. Хотя тоже вариант не удобный — надо рестартит сервер, после изменений в файле.
Спасибо за статью, наткнулся совершенно случайно.
Узнал о logstash когда был на SCALE11, с тех пор используем его постоянно. Elastic Search позволяет делать невероятные вещи с поиском в реальном времени — парсим не только логи с ошибками, но и логи с метриками, на базе которых строим графики. Вручную или с помощью децентрализованных инструментов такое сделать просто нереально, поток данных — сотни и тысячи событий в секунду. Вообще, если задуматься, logstash сэкономил нам ОООчень много денег вместо того чтобы покупать Splunk.
Автоматизировал развертывание агента на Linux и Windows машины, описал в Puppet конфигурацию. Девелоперы знают, что если писать лог с суффиксом *logstash* то он будет подобран автоматически. Часто используем .json формат для записи структурированных данных.
Очень рекомендую, прекрасный продукт, прекрасное коммьюнити!
Only those users with full accounts are able to leave comments. Log in, please.