Метрики, моніторинг, сповіщення

Зміст:

Підсумок
Подробиці
Пов’язане
Примітки

Підсумок

Проблема

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

Рішення

Робота триває.

Статус

Збираємо інформацію. Ми починаємо з правдоподібних країв спектра: найрекомендованіший старіший безкоштовний інструмент (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 має найкращу популярність серед відкритих рішень за принципом «будувати, а не купувати».

Поки що Prometheus + Graphana мають найкращу популярність.

Наслідки

TODO.

Пов’язане

Пов’язані рішення

Вибір вплине на тестованість, телеметрію та, ймовірно, інші системи, як-от для обслуговування клієнтів, інженерії надійності сайтів тощо.

Пов’язані вимоги

TODO.

Пов’язані артефакти

TODO.

Пов’язані принципи

Легко скасовувати.

Потреба у швидкості.

Примітки

Досить гарний стек з відкритим кодом:

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

Довільні текстові повідомлення чи структуровані повідомлення про події

Довільні текстові повідомлення: наприклад, різний випадковий вміст, який ви знайшли б у /var/log/messages, і те, що застосунок згенерував навмисно. Ці повідомлення корисні для виявлення інших подій на машині, як-от нестача пам’яті чи апаратні помилки, але містять багато сміття.

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

Загалом гарно записувати подробиці про кожен запит так, щоб можна було деталізувати за атрибутами. Тож додавання, напр., userid чи sessionid до всього дозволяє відстежувати. Явне трасування, звісно, теж добре. Використання 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. Ці дані просто не дуже важливі для нас, окрім того, що їх достатньо для сповіщень. Наше загальне розгортання парку так сильно змінюється з року в рік, що історичні дані старші за кілька місяців просто не цікаві. Можливо, цікаво мати кілька основних статистик рік до року, я можу налаштувати набір основних правил запису статистики й зберігати їх через Federation або просто довірити це Thanos.

РЕДАГУВАННЯ: невелике застереження, я розробник Prometheus.

Prometheus HA

HA в Prometheus досягається дублюванням: ви запускаєте кілька збирачів, є способи опитувати кілька й дедуплікувати дані

Масштабування відбувається шляхом поділу мережі та налаштування різних Prometheus для опитування різних частин мережі

Довгострокове зберігання — не сильна сторона prom, але його можна перекласти на щось на кшталт 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 для графіків.

завдяки гнучкості правил apply в 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

Push Gateway prometheus для пакетних завдань/cron-завдань

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 продуктів.

Для локальних розгортань це здебільшого 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 % випадків автоматизація + наші скрипти не дають нам потрапити в халепу)

У нас є внутрішні посібники з експлуатації (runbooks) у нашій базі знань на випадок, коли автоматизації не спрацьовують або коли є щось поза межами, що потрібно виправити.

Prometheus + AlertManager + Grafana + Stackdriver

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

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

Zabbix

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