Метрики, мониторы, оповещения

Содержание:

Резюме
Подробности
Связанное
Примечания

Резюме

Проблема

Мы хотим использовать метрики, мониторы и оповещения, потому что хотим знать, насколько хорошо работают наши приложения, и знать, когда возникает проблема.

Решение

В работе.

Состояние

Сбор информации. Мы начинаем с правдоподобных крайностей спектра: самого рекомендуемого старого бесплатного инструмента (Nagios) и самого рекомендуемого нового платного инструмента (New Relic).

Подробности

Допущения

Мы хотим создавать современные, быстрые, надёжные, отзывчивые и т. д. веб-приложения.

Мы хотим покупать, а не создавать.

Ограничения

Нам нужны инструменты, хорошо работающие с нашим devops-конвейером и нашими облаками развёртывания.

Позиции

Сейчас мы изучаем позиции.

AlertManager
AppDynamics
AppOptics
Azure Monitor/Analytics/Insights/Dashboards
Bosun
Checkly
Circonus
Cloudwatch
EFK
ELK
Grafana
Grafana
Graphite
Graylog
Healthchecks.io
Heroku
icinga2
InfluxDB
Instana
Kafka
Logagent
Logz.io
Loki
Monitis
Nagios
Nagios
Nagiosgraph
NewRelic
OpsGenie
Outlyer
PagerDuty
Pagerduty
PagerDuty
Papertrail
Prometheus
Rollbar
Scalyr
Sematext Metrics, Logs, Experience, Tracing
Sensu
SignalFX
Slack
Splunk
Stackdriver
Stackstorm
Telegraf
Telegraf
Thanos
VictorOps
Wavefront
Zabbix

Аргументация

Пока Nagios и New Relic — крайности спектра. Nagios — самый старый, простейший, бесплатный, жизнеспособный инструмент. New Relic — самый новый по функциям, самый полный, платный, жизнеспособный инструмент. Мы начнём с оценки этих двух. По мере необходимости мы будем перемещаться по спектру.

Пока у Zabbix лучшие рекомендации, и он также предлагает наиболее полные возможности.

Пока у ELK лучшая популярность среди open-source вариантов «собрать самим вместо покупки».

Пока у Prometheus + Grafana лучшая популярность.

Следствия

Предстоит сделать (TODO).

Связанное

Связанные решения

Выбор повлияет на тестируемость, телеметрию и, вероятно, другие системы, например для обслуживания клиентов, инженерии надёжности сайтов и т. д.

Связанные требования

Предстоит сделать (TODO).

Связанные артефакты

Предстоит сделать (TODO).

Связанные принципы

Легко обратимо.

Необходимость скорости.

Примечания

Довольно хороший стек с открытым исходным кодом:

Prometheus для метрик и оповещений на основе метрик
Grafana для отображения метрик
Elasticsearch/Logstash/Kibana (ELK) для журналов и структурированных событий
Pushover для мобильных уведомлений

Свободные текстовые сообщения и структурированные сообщения о событиях

Свободные текстовые сообщения: например, всякая случайная всячина, которую можно найти в /var/log/messages, и то, что намеренно генерирует приложение. Сообщения полезны для выявления других происходящих на машине событий, таких как нехватка памяти или аппаратные ошибки, но содержат много мусора.

Структурированные сообщения о событиях: генерируются приложением, с фиксированным или динамическим набором атрибутов, например журнал HTTP-запросов, учётный журнал, вход пользователя.

В целом хорошо логировать детали каждого запроса так, чтобы можно было детализировать по атрибутам. Поэтому добавление, например, userid или sessionid ко всему позволяет трассировать. Явная трассировка, конечно, тоже хороша. Использование ELK для этого — своего рода «ELK для бедных» вместо https://www.honeycomb.io/

Graylog проще

По моему опыту, Graylog проще поднять.

Prometheus требует некоторой настройки

В целом я доволен Prometheus для метрик. Оповещения требуют некоторой настройки, но вполне хороши. Это зависит от вашего приложения. Я думаю, лучше оповещать о состояниях, видимых конечному пользователю, а не о глубинных причинах. Например, время загрузки страницы — хорошо, количество запросов в секунду — нет. Хотя ноль запросов в секунду указывает, что что-то не так.

Преимущество сервиса в том, что он из коробки предлагает дополнительный интеллект. Я в целом люблю Datadog. Сервисы могут быть пугающе дорогими, если у вас много данных, а иногда у них модели ценообразования, не дружественные облаку, например плата за экземпляр, когда экземпляры динамические. Есть также разница между сервисами, где каждый запрос исходит от платящего пользователя, и теми, что связаны с рекламой, где лишь небольшой процент запросов приносит вам деньги. Можно получить много данных и не очень большой бюджет.

Я работаю над некоторыми сервисами, получающими 1 млрд запросов в день, так что имеет смысл самим размещать мониторинг и логирование. Если ваши объёмы меньше, то размещённые сервисы проще.

Сервисы AWS неоднозначны

Мой опыт с сервисами AWS неоднозначен. Их сервис Elasticsearch был нестабилен, поэтому мы запускаем собственные экземпляры. Метрики CloudWatch дороги, поэтому мы обычно используем их только для метрик уровня «инфраструктуры», а не приложения, то есть метрик, связанных со здоровьем, где AWS может лучше знать, что происходит, чем программное обеспечение, работающее на экземпляре. CloudWatch Logs могут медленно обновляться и не содержат много метаданных. Запуск ELK помогает в этом. Если мне действительно нужны данные в реальном времени, то лучше использовать Kafka в качестве транспорта для журналов. Это довольно хорошо поддерживается Logstash. Управлять кластером Kafka, впрочем, — не для слабонервных, там много выставленной наружу «сантехники».

Kafka

Комментарий: Kafka порой бывает очень сложной, а порой она непоколебимо надёжна, и вы почти забываете, что она там, связывая всё воедино.

Комментарий: Kafka была надёжной, но её запуск потребовал на удивление много работы. Я думаю о ней как о реляционной базе данных, но вы работаете только на «физическом» уровне, например табличные пространства, файлы и разделы. Было время в начале, когда утилит управления не хватало, и нам приходилось писать программы, например для сброса группы потребителей. http://howfuckedismydatabase.com/nosql/

Комментарий: Мы используем Kafka как «буфер» для сообщений журнала и место, где можно делать потоковую обработку в реальном времени данных, поступающих с нескольких серверов. Если нас атакуют DDOS, нам нужен способ анализа данных по нескольким экземплярам. Если мы логируем напрямую с серверов в ELK, нагрузка может «взорвать» кластер Elasticsearch.

Комментарий: Kafka хороша для нас, потому что при DDOS-атаке нам нужен способ анализа данных по нескольким экземплярам. Если мы логируем напрямую с серверов в ELK, нагрузка может «взорвать» кластер Elasticsearch.

Комментарий: Kafka делает меньше работы и эффективнее, поэтому лучше справляется с нагрузкой. И мы ставим работу Kafka в очередь и повторяем. А перегрузка Kafka не влияет на пользователей, пытающихся интерактивно работать с Kibana, как это было бы, если бы Elasticsearch испытывал трудности.

Комментарий: Потоковая обработка в основном ищет злоупотребления, например слишком большой трафик с одного IP по всему кластеру, а затем делится блокировкой по всему кластеру.

Комментарий: Плагин logstash-output-kafka на данный момент довольно ненадёжен. Я сталкивался с несколькими проблемами на странице его проблем на GitHub, которые, похоже, никогда не исправляются. Я хочу отойти от его использования и отправлять напрямую из наших приложений в Kafka.

Комментарий: Теперь мы отправляем структурированные события напрямую из приложения в Kafka. Основной мотивацией было меньшее число обращений к данным журнала и избегание многократного чтения и записи на диск. В системах с большим объёмом логирование может требовать больше работы, чем само приложение. Я думаю о том, чтобы заставить journald тоже отправлять журналы напрямую, из программы на C.

Loki

Следите за Loki пристально. Он ещё не готов, но когда будет готов, я ожидаю, что он лучше впишется в этот стек. Loki — агрегатор журналов от grafana labs, использующий тот же синтаксис сбора и тегов, что и Prometheus.

Prometheus + alertmanager + Rollbar + Graylog + Grafana

Prometheus + alertmanager для метрик. Обожаю Prometheus.

Rollbar/Graylog для логирования/отчётов об ошибках (здесь есть некоторое пересечение; небольшому сервису, вероятно, не нужны оба).

В настоящее время оповещения просто идут в один из нескольких каналов Slack, у заинтересованных сторон включены уведомления. Если бы мы серьёзнее относились к дежурствам, они шли бы в PagerDuty/VictorOps/и т. п.

Grafana для графиков и панелей мониторинга. Также с нетерпением жду, сделают ли их будущие возможности логирования Graylog ненужным.

Thanos

Мы используем Thanos как фронтенд для нашей настройки HA. Он умеет дедуплицировать пары HA.

Сейчас мы храним 6 месяцев локальных данных Prometheus. Это вполне хорошо для нас работает. Но я как раз в процессе развёртывания хранилища бакетов в нашей настройке Thanos для долгосрочного хранения данных. Теоретически хранилище GCS будет примерно на 30% дешевле стандартного постоянного диска GCE, который мы используем сейчас.

Резервное копирование данных Prometheus мы сейчас не делаем. Данные просто не очень важны для нас помимо того, чего достаточно для оповещений. Развёртывание нашего общего парка так сильно меняется из года в год, что исторические данные старше нескольких месяцев просто не очень интересны. Может быть интересно иметь несколько основных статистических показателей из года в год; я могу настроить набор правил записи основных показателей и хранить их с помощью федерации или просто позволить Thanos позаботиться об этом.

ПРАВКА: небольшая оговорка, я разработчик Prometheus.

Prometheus HA

HA в Prometheus достигается дублированием: вы запускаете несколько сборщиков, и есть способы опрашивать несколько и дедуплицировать данные.

Масштабирование достигается разделением сети и тем, что разные Prometheus опрашивают разные части сети.

Долгосрочное хранение — не сильная сторона Prometheus, но его выгружают во что-то вроде influx или timescaledb (который технически тоже ставит галочку HA). Статья, которую я читал об этом: https://blog.timescale.com/prometheus-ha-postgresql-8de68d19b6f5?gi=7df160f10e07

Долгосрочную часть я ещё не пробовал, так как всё ещё только экспериментирую и использую его для краткосрочных графиков, в то время как librenms следит за моей сетью в долгосрочной перспективе.

Datadog + PagerDuty + Threat Stack

Мы используем Datadog (с PagerDuty) и Threat Stack и не могли бы быть счастливее. Моя единственная претензия к DD — относительно высокая стоимость хранения метрик.

Zabbix

Zabbix с пользовательскими скриптами для мониторинга почти всего. Работает как часы.

Outlyer

Я использую Outlyer, но должен оговориться, что работаю здесь, а использование собственного продукта обязательно.

Всё ещё нужны Graylog, Sentry и Statuscake для улучшения.

Может прозвучать предвзято, но, с удовольствием проработав внутри компании с Nagios и другими системами мониторинга, на любой новой работе я бы купил размещённое решение и избавился от этой боли.

Nagios + Nagiosgraph

Мы запускаем Nagios для всего мониторинга и оповещений. Оповещения приходят по электронной почте (предупреждения и критические уведомления) и звуковыми уведомлениями приложения (для критических оповещений).

Nagiosgraph используется для визуализации.

Такая настройка очень эффективно держит нас всесторонне в курсе того, что происходит в нашей среде. Мы запускаем и отслеживаем около 110 критически важных серверов и около 760 точек данных, и эта утренняя система работает у нас более семи лет.

Я бы хотел когда-нибудь также агрегировать журналы с помощью Graylog или ELK.

Prometheus + Grafana + AlertManager

Prometheus + Grafana + AlertManager через замечательный helm-чарт Prometheus Operator. Журналы по-прежнему идут в план LogDNA birch, так как мы заметили, что ELK слишком тяжёл для нашего скромного кластера GKE минимум из 3, максимум из 5 узлов.

DataDog + Sentry + PagerDuty.

Раньше я запускал все свои решения для мониторинга сам, используя разнообразное ПО, включая Nagios, Icinga, Zabbix, ELK, Greylog2, Influx и многие другие инструменты, но правда в том, что на запуск собственной инфраструктуры мониторинга уходит слишком много усилий, особенно когда можно заплатить кому-то другому по таким низким тарифам, чтобы он делал это за вас!

Оплата чужого запуска инфраструктуры мониторинга освобождает моих клиентов для запуска их платформ вместо мониторинга мониторинга, а значит, ценность, которую они получают от стабильности своей платформы, намного превосходит любые затраты на мониторинг как услугу.

Sensu + Graphite + ELK

Моя компания очень привержена самостоятельно размещаемым решениям.

Sensu -> PagerDuty

Graphite/Grafana

ELK (Elasticsearch, Logstash, Kibana)

Prometheus + Alertmanager

Prometheus + Alertmanager для оповещений; моя команда считает, что простой мониторинг — хороший мониторинг.

Другие системы, такие как логирование и трассировка, дадут богатый контекст для диагностики, когда дежурный получает оповещение, но мы никогда не строим оповещения на них.

Sensu + Grafana + Graylog + Kibana + NewRelic.

Sensu, grafana, graylog, kibana, newrelic.

Prometheus + Circonus

Сервисы, оснащённые Prometheus => аналитика и визуализация Circonus

icinga2 + VictorOps + NewRelic + Sentry + Slack

Мы используем следующие сервисы:

icinga2 для мониторинга и VictorOps для оповещений

NewRelic для детального мониторинга сервиса

Sentry для отслеживания ошибок в сервисе

Slack/электронная почта — часть оповещений, срабатывающих из NewRelic или icinga2

AppDynamics + Papertrail + PagerDuty + Healthchecks.io + Stackdriver

AppDynamics

Papertrail

PagerDuty

Healthchecks.io

Stackdriver

icinga2 + elasticsearch

icinga2 с интеграцией elasticsearch для анализа и интеграцией graphite+grafana для графиков.

благодаря гибкости правил применения в icinga2 разработчики видят только те сервисы, о которых получают уведомления.

а через icinga2 director программисты могут легко определять собственные проверки (что они и делают каждые несколько дней — 100 проверок уходит, 100 других приходит) в большом масштабе без всяких хлопот.

DataDog + New Relic + ELK + EFK + Sentry + Alertmanager + VictorOps

Что у нас есть сейчас:

DataDog для метрик

New Relic для мониторинга приложений

ELK (Elastic Search + Logstash + Kibana) для журналов

Sentry (самостоятельно размещённый) для логирования исключений

Электронная почта + Slack + VictorOps для оповещений (в зависимости от серьёзности)

Что мы хотим иметь:

Prometheus для метрик (Grafana для визуализации)

New Relic (вероятно, Elastic Search APM) для мониторинга приложений

EFK (elastic search + fluentd + kibana) для логирования. Вероятно, Loki от Grafana будет готов к промышленной эксплуатации к тому времени, как мы туда доберёмся

Sentry для исключений

Alertmanager + электронная почта + VictorOps для оповещений

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack (оговорка: работаю в VMware)

Telegraf + Prometheus + InfluxDB + Grafana

Telegraf для серверных метрик, таких как ЦП, диск, память и сеть. Мы также используем Telegraf для мониторинга SNMP наших сетевых устройств.

Prometheus для метрик приложений. Мы кодируем проверки работоспособности в наше приложение, а Prometheus их собирает.

InfluxDB для хранения временных рядов. Сюда отправляются данные Telegraf.

Grafana для панелей мониторинга и оповещений. Механизм оповещений не очень надёжен, но свою работу делает. Мы также отправляем оповещения в Slack.

Чего у меня сейчас нет — это централизованного решения для логирования. ELK мощный, но сложен в настройке и управлении, и я не знаю бесплатных альтернатив, достаточно близких, чтобы их рассмотреть.

Sematext + Logagent + Experience

Sematext для метрик, для журналов, для трассировок, скоро и для мониторинга реальных пользователей. Проще/дешевле, чем использовать N разных инструментов/сервисов, по моему скромному мнению.

Для доставки журналов мы раньше использовали rsyslog, затем перешли на Logagent.

Для отчётов о сбоях фронтенда мы используем Sentry, но скоро перейдём на Experience.

Оговорка: я сотрудник Sematext.

Azure Monitor/Analytics + OpsGenie

Хотелось бы, чтобы у Log Analytics был лучший интерфейс. Мы отходим от splunk, по которому было гораздо проще ориентироваться.

Prometheus + Alertmanager + Grafana + Splunk + PagerDuty

Prometheus, Alertmanager, Grafana, Splunk, PagerDuty

Вам действительно не стоит запускать собственную систему уведомлений. Вы можете заменить Splunk на ELK, если только ваша команда безопасности не предпочитает Splunk.

Telegraf + Prometheus + Grafana + Alertmanager

Telegraf как сборщик, Prometheus + Alertmanager для мониторинга и оповещений, интегрированные с каналами slack и pagerduty для критических оповещений. Grafana для визуализации метрик хостов.

Prometheus + Grafana + Cloudwatch + sentry + kibana + elasticsearch

Prometheus для метрик + оповещений

Grafana для панелей Prometheus

Cloudwatch следит за экземплярами Prometheus

sentry для отслеживания исключений

kibana + elasticsearch

graylog

prometheus Push Gateway для пакетных заданий/cronjobs

SOP https://github.com/rapidloop/sop для «отправки/пересылки» метрик из одного экземпляра Prometheus в другой

клиенты используют либо клиенты Prometheus. Мы стараемся использовать opencensus.io на стороне клиента

PagerDuty + Monitis

PagerDuty + Monitis. А также некоторые индивидуальные Azure Functions для проверки работоспособности некоторых сервисов.

В этом году хотим внедрить Prometheus и Grafana

Prometheus + Grafana + Bosun

Prometheus для хранения данных временных рядов. Grafana для визуализации. Bosun для управления оповещениями.

Azure Monitor/Analytics/Insights/Dashboards

Магазин только на Azure: Azure Monitor, Log Analytics, App Insights, Azure Dashboards + Pager Duty

Grafana + Monitis + OpsGenie + Slack

Grafana для мониторинга контейнерных сервисов в Kubernetes через Prometheus

Monitis для сквозного мониторинга сервисов, главным образом для веб-API и веб-приложений

OpsGenie для управления оповещениями

Slack для получения информации о состоянии наших систем

Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail

Давний (dev)ops-инженер здесь. Вырос на Nagios. Хотел бы услышать мнения о моём SaaS, развиваемом на собственные средства, https://checklyhq.com. Мы занимаемся мониторингом API и мониторингом транзакций сайта с довольно глубокими оповещениями.

Я начал Checkly, потому что активный / синтетический мониторинг в сфере API был несколько ограничен (и дорог). Мониторинг на основе браузера / по скриптам ещё более проприетарен и дорог. Мы используем Puppeteer и держим цены как можно ниже.

Наш стек мониторинга:

Checkly (едим собственный корм...)

AppOptics (пользовательские графики)

AWS Cloudwatch и SNS для SMS-сообщений.

встроенные оповещения Heroku.

Pagerduty

Papertrail

Instana + Logz.io + slack

Instana оповещает нас в slack о проблемах инфраструктуры или снижении производительности, а мы настроили logz.io на оповещение в slack при определённом объёме журналов уровня ошибок из слоя приложения.

SignalFX + Splunk + PagerDuty + Slack

В настоящее время используем: SignalFX, Splunk, PagerDuty и Slack. Я не большой поклонник SignalFX, хотя их служба поддержки очень дружелюбна и отзывчива. Мне нравятся Splunk (стоит своих денег, если можете себе позволить), PagerDuty и Slack.

Раньше я использовал стек TICK, где C на самом деле было G, то есть Grafana, хотя Chronograf я тоже немного использовал. Это было здорово, но управлять им было мучительно. Классическая дилемма SaaS против самостоятельного размещения.

Я использовал DataDog, New Relic, Graylog, ELK и BugSnag. DataDog и New Relic мне очень нравятся, Graylog вполне хорош. ELK я не очень люблю. BugSnag приятен, мне на самом деле кажется, что отслеживание ошибок/исключений во многих случаях неплохо заменяет полный мониторинг журналов.

ELK + Prometheus + Grafana

Как и другие, мы используем ELK для журналов и Prometheus+Grafana для всего остального.

Поддерживать эту настройку легко, если позволить себе иногда терять данные. Например, если наша база данных ElasticSearch впадает в ступор (что, к сожалению, случается у нас раз в 2–3 месяца), мы не заморачиваемся с HA, а выбрасываем данные и продолжаем жить дальше. Если вам абсолютно необходим HA или долгосрочное хранение, удачи.

Datadog + Prometheus + Grafana

Я настроил Datadog помесячно, потому что, когда я пришёл сюда, не было ни мониторинга, ни оповещений. Только пара наших сайтов проверялась на доступность каждые 5 минут. Datadog, безусловно, проще всего настроить. Когда закончу решать все остальные проблемы, перейду на Prometheus+Grafana. Окончательно ещё не решил по управлению журналами.

Nagios + ELK

Мы поддерживаем более 100 продуктов.

Для локальных систем (on-prem) это в основном Nagios и ELK. Для облака мы переходим с DataDog на NewRelic.

Datadog или Site24x7 + StatusCake + PagerDuty + SumoLogic + Slack

Мы раньше использовали datadog, но нашли его слишком дорогим для наших нужд. Не поймите неправильно, он потрясающий, но у него огромная стоимость. Мы смогли настроить site24x7.com с годовой подпиской примерно за 2–3 месяца стоимости DD.

Наш стек мониторинга:

Site24x7 — APM, мониторинг внешних URL, мониторинг почтового потока SMTP, истечение срока действия ssl и мониторинг процессов.

StatusCake — для мониторинга и подтверждения URL — это наша резервная копия на случай, если site24x7 что-то пропустит (он не пропускает), но SC гибче для мониторинга внешних портов и сервисов для наших нужд.

Оба инструмента эскалируют в PagerDuty, а затем мы получаем эскалации в slack.

SumoLogic — для мониторинга журналов (отличный инструмент, но немного сложный для наших нужд)

Из slack мы можем подтвердить оповещение или устранить проблему.

Затем у нас много автоматизаций site24x7, которые подключаются к commando.io для «BedOps», как мы это называем, — где при срабатывании оповещения мы запускаем несколько скриптов или автоматизаций в попытке устранить ситуацию (в 99% случаев автоматизация и наши скрипты уберегают нас от неприятностей).

У нас есть внутренние рунбуки в нашей базе знаний на случай, когда автоматизации не срабатывают или нужно исправить что-то вне их области.

Prometheus + AlertManager + Grafana + Stackdriver

Prometheus (Operator) / AlertManager / Grafana для метрик в наших кластерах GKE и виртуальных машинах.

Google Stackdriver для журналов (так как он включён и активен по умолчанию и сейчас достаточен для наших нужд).

Zabbix

Zabbix для всего. Дополнительное ПО не нужно.