Comments 33
Так же можно сделать выборку по любым атрибутам, чего еще не хватает чтобы считаться no-sql хранилищем?
А вы у себя используете X-Pack?
посмотрел на цену xpack и немного прифигел просто…
Возможно, вам будет интересна система ElastAlert? Коллеги ниже про неё написали, она бесплатна и предоставляет возможности из коробки.
Большинство метрик, думаю, вопросов не вызывает, расскажу подробнее про наиболее интересную — $request_id
на днях сам наткнулся, но есть один нюанс, эта переменная доступна начиная с nginx 1.11+. Пришлось выкручиваться через
$pid-$msec-$remote_addr-$remote_port-$request_length
А вот тут продолжение — как улучшили, чтобы можно было бинарным поиском искать эти request_id
https://youtu.be/8k2dPiUZXtI?t=6m39s и https://www.slideshare.net/profyclub_ru/sre-headhunter-headhunter/14 соответственно.
PS как и у X-Pack, кажется, что комьюнити и информации в открытых источниках меньше, чем у Prometheus.
Есть еще ElastAlert. Написан на питоне. Он бесплатный и довольно простой. Badoo его в итоге себе на пхп зачем-то переписали, но они все время так поступают.
PS как и у X-Pack, кажется, что комьюнити и информации в открытых источниках меньше, чем у Prometheus.
Да. Мы используем. У нас настроен мониторинг порядка десятка различных метрик, от поргового значения количества появления критикал сообщений в системе до анализа скорости ответа наших сервисов. Уведомления летят в слак в основном. Критичные дублируются смс-ками. С точки зрения сотни метрик и удобства. Сложный вопрос. Конфиги в нем пишутся на yaml-е так-что вопрос привычки. У нас ansible, поэтому нас устраивает. Просто добавляем на каждую метрику отдельный файлик в репозиторий, а гитлаб-ci прогоняет тесты и выкатывает все на хост с elastalert-ом.
По комьюнити и информации -на самом деле не густо. Плюс некоторые задачи у них решаются очень своеобразно. К примеру, чтобы не уведомлять в выходные, надо писать свое дополнение на питоне. Но все что нам нужно, мы в итоге смогли найти и разобраться.
Про $request_id — а как, собственно, реализовано его распространение по подсистемам, после начальной генерации первым nginx в цепочке? В заголовках запроса? Следующий nginx его не перезатрёт своим? В php-error.log можно как-то записать при необработанных ошибках?
Чтобы не перезатирал, у нас в Nginx проверки — если пришёл заголовок X-Request-Id, то берём его. Если нет, то генерируем новый. Nginx ставим через общую ansible-роль, так что командам не требуется дублировать логику.
Можно добавить свой обработчик PHP-ошибок, который будет дополнять сообщение нужной информацией и дописывать её в php-error.log. Но мы $request_id не пишем в php-ошибки, а смотрим в логах кибаны.
Я, один из тех, кто заведует ELK инфраструктурой в нашей компании и постараюсь дать информацию по вашему вопросу.
Тестов на потерю GELF сообщений мы не проводили, но и с конкретной проблемой об отсутствии GELF сообщений, пользователи к нам не приходили. Хотя нам приходит порядка 4000 GELF сообщений в секунду.
Вообще — все сообщения, которые нам отправляют по UDP, могут потеряться. И полагаю, что это нормально, т.к. UDP.
Будем считать, что данная проблема обошла на стороной, т.к. ещё не было замечено её влияния на анализ происходящих у нас событий.
Ещё одна система логирования, теперь на ElasticSearch, Logstash, Kibana и Prometheus