Pull to refresh

Comments 33

С каких это пор elasticsearch стал no-sql хранилищем? Всегда вроде был поисково-аналитическим движком
в ES можно залить данные в json и получить их обратно в этом же формате, включая вложенные объекты. для некоторых свойств придется явно сказать, чтобы эластик сохранял исходное, не преобразованное для поиска поле.
Так же можно сделать выборку по любым атрибутам, чего еще не хватает чтобы считаться no-sql хранилищем?
Можно хранить любые json-документы, без схемы. Из этих соображений назвал ES no-sql хранилищем, с возможностью полнотекстового поиска.
А почему не устроили возможности logstash-а по отправке оповещений и сборов метрик?
Из документации непонятно, что с дедупликацией событий и сообщений, с обеспечением отказоустойчивости и масштабируемостью рассыльщика нотификаций. В документации Prometheus в этом смысле всё понятно описано и возможности нас устроили.
Я дедубликацию через плагин throttle реализовывал.
Но в целом да, на более масштабных инсталляциях пожалуй будет удобнее использовать внешний независимый агрегатор.
А Alerting в платном дополнении, xpack если не ошибаюсь, дорого получается?
Присоединяюсь к вопросу. почему не использовали X-Pack? Только вопрос денег или что то функциональное?
Кроме предоставляемых из коробки возможностей по оповещениям, у Prometheus нам понравилось большое комьюнити и много статей в открытом доступе — есть и ролики на Youtube, где рассказывают о возможностям системы, и статьи с опытом внедрения других компаний. По X-Pack нашли лишь гайды с официального сайта и форум, который непонятно в каком состоянии. При наличии бесплатного Prometheus оценили, что платить за X-Pack нецелесообразно.
А вы у себя используете X-Pack?
Я Splunk пользуюсь =)
посмотрел на цену xpack и немного прифигел просто…
Вы на своём сервере используете или в Облаках?
у себя, амазон не заинтересовал (у них в амазоне cloud)
Нет, дорого для нас. Но на время тестового периода произвел приятное впечатление. В случае его покупки наверное парни из эластика должны оказывать консультационные услуги? Поэтому комьюнити не столь актуально? Плюс изначально очень подкупала возможность взять все из коробки и в 1 месте.
На мой взгляд, комьюнити и информация в открытых источниках нужно, чтобы изучить возможные грабли и тонкости работы системы. Без такого изучения сложно что-то внедрить в использование и оперативно найти вопросы на ответы. Не могу ничего плохо сказать про парней из эластика, но чтобы им ответить на вопрос, нужно какое-то время и разница в часовом поясе будет очень неудобна.
Возможно, вам будет интересна система ElastAlert? Коллеги ниже про неё написали, она бесплатна и предоставляет возможности из коробки.
Большинство метрик, думаю, вопросов не вызывает, расскажу подробнее про наиболее интересную — $request_id

на днях сам наткнулся, но есть один нюанс, эта переменная доступна начиная с nginx 1.11+. Пришлось выкручиваться через $pid-$msec-$remote_addr-$remote_port-$request_length
Можно еще использовать вот этот модуль https://github.com/hhru/nginx_requestid — еще в 2012 году был доклад про него https://www.slideshare.net/kuchinskaya/sivko/9#9

А вот тут продолжение — как улучшили, чтобы можно было бинарным поиском искать эти request_id
https://youtu.be/8k2dPiUZXtI?t=6m39s и https://www.slideshare.net/profyclub_ru/sre-headhunter-headhunter/14 соответственно.
Да, для старых версий nginx было 2 или 3 модуля, но у нас в проде нельзя устаналивать сторонние модули. Так что приходится выкручиваться.
Для нотификации есть бесплатное решение ElastAlert
Спасибо, вы пользуетесь им? Можно ли настроить его на мониторинг не одного, а например, дюжины или сотни сервисов, при этом чтобы было удобно управлять конфигурацией?
PS как и у X-Pack, кажется, что комьюнити и информации в открытых источниках меньше, чем у Prometheus.

Да, пользуемся. Смотрит на elasticsearch. Дока сносная, не гайд в 2 кнопки, конечно, но все работает. Что-то используется из коробки, а для чего-то писал скрипты.

Есть еще ElastAlert. Написан на питоне. Он бесплатный и довольно простой. Badoo его в итоге себе на пхп зачем-то переписали, но они все время так поступают.

Спасибо, а вы пользуетесь данным решением? Можно ли настроить его на мониторинг не одного, а например, дюжины или сотни сервисов, при этом чтобы было удобно управлять конфигурацией?
PS как и у X-Pack, кажется, что комьюнити и информации в открытых источниках меньше, чем у Prometheus.

Да. Мы используем. У нас настроен мониторинг порядка десятка различных метрик, от поргового значения количества появления критикал сообщений в системе до анализа скорости ответа наших сервисов. Уведомления летят в слак в основном. Критичные дублируются смс-ками. С точки зрения сотни метрик и удобства. Сложный вопрос. Конфиги в нем пишутся на yaml-е так-что вопрос привычки. У нас ansible, поэтому нас устраивает. Просто добавляем на каждую метрику отдельный файлик в репозиторий, а гитлаб-ci прогоняет тесты и выкатывает все на хост с elastalert-ом.
По комьюнити и информации -на самом деле не густо. Плюс некоторые задачи у них решаются очень своеобразно. К примеру, чтобы не уведомлять в выходные, надо писать свое дополнение на питоне. Но все что нам нужно, мы в итоге смогли найти и разобраться.

Про $request_id — а как, собственно, реализовано его распространение по подсистемам, после начальной генерации первым nginx в цепочке? В заголовках запроса? Следующий nginx его не перезатрёт своим? В php-error.log можно как-то записать при необработанных ошибках?

Да, верно, $request_id распространяется в заголовках.
Чтобы не перезатирал, у нас в Nginx проверки — если пришёл заголовок X-Request-Id, то берём его. Если нет, то генерируем новый. Nginx ставим через общую ansible-роль, так что командам не требуется дублировать логику.
Можно добавить свой обработчик PHP-ошибок, который будет дополнять сообщение нужной информацией и дописывать её в php-error.log. Но мы $request_id не пишем в php-ошибки, а смотрим в логах кибаны.
А как вы решаете проблему с логгированием sensitive информации в поле payload (пароли, номера кредиток, ...)?
Kibana доступна только из нашей подсети + из текста сообщений вырезаем конфиденциальную информацию.
Добрый день!

Я, один из тех, кто заведует ELK инфраструктурой в нашей компании и постараюсь дать информацию по вашему вопросу.

Тестов на потерю GELF сообщений мы не проводили, но и с конкретной проблемой об отсутствии GELF сообщений, пользователи к нам не приходили. Хотя нам приходит порядка 4000 GELF сообщений в секунду.
Вообще — все сообщения, которые нам отправляют по UDP, могут потеряться. И полагаю, что это нормально, т.к. UDP.

Будем считать, что данная проблема обошла на стороной, т.к. ещё не было замечено её влияния на анализ происходящих у нас событий.
Alerting из X-Pack приятная штука, но цена подписки оказывается неподъемной для небольших компаний. Сами пользовались триалом- понравилось, но теперь придется искать бесплатную альтернативу оповещениям.
Возможно, из платного функционала кому-то будет интересен Machine Learning. Написали на Хабре статью как он работает в Elastic.
Sign up to leave a comment.