Метрики, мониторинг, известия

Съдържание:

Резюме
Подробности
Свързани
Бележки

Резюме

Проблем

Искаме да използваме метрики, мониторинг и известия, защото искаме да знаем колко добре работят нашите приложения и да знаем кога възникне проблем.

Решение

В процес на работа (WIP).

Състояние

Събиране на информация. Започваме от вероятните краища на спектъра: най-препоръчваният по-стар безплатен инструмент (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 + Grafana имат най-добра популярност.

Последици

TODO.

Свързани

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

Изборите ще повлияят на тестваемостта, телеметрията и вероятно други системи, например за обслужване на клиенти, инженерство за надеждност на сайтове (SRE) и т.н.

Свързани изисквания

TODO.

Свързани артефакти

TODO.

Свързани принципи

Лесно обратимо.

Нужда от скорост.

Бележки

Доста добър стек с отворен код е:

Prometheus за метрики и известия, базирани на метрики
Grafana за показване на метрики
Elasticsearch/Logstash/Kibana (ELK) за логове и структурирани събития
Pushover за мобилни известия

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

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

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

Като цяло е добре да се логват подробности за всяка заявка по начин, който позволява да се проникне в дълбочина по атрибути. Така добавянето на напр. userid или sessionid към всичко позволява проследяване. Изричното проследяване (tracing) също е добро, разбира се. Използването на ELK за това е нещо като бедняшка версия на https://www.honeycomb.io/

Graylog е по-лесен

Според мен Graylog е по-лесен за пускане.

Prometheus изисква малко настройка

Като цяло съм доволен от Prometheus за метрики. Известията изискват малко настройка, но са доста добри. Зависи от вашето приложение. Мисля, че най-добре е да се известява за състояния, видими за крайния потребител, а не за първопричини. Например времето за зареждане на страница е добро, броят заявки в секунда — не. Макар нула заявки в секунда да подсказва, че нещо не е наред.

Предимството на една услуга е, че предлага допълнителна интелигентност от кутията. Като цяло харесвам Datadog. Услугите могат да бъдат плашещо скъпи, ако имате много данни, а понякога имат ценови модели, които не са удобни за облака, напр. таксуване на инстанция, когато инстанциите са динамични. Има и разлика между услуги, при които всяка заявка идва от платящ потребител, и такива, свързани с реклама, при които само малък процент от заявките печелят пари. Може да се озовете с много данни и не толкова голям бюджет.

Работя по някои услуги, които получават 1 милиард заявки на ден, така че има смисъл да хоствате собствен мониторинг и логване. Ако обемите ви са по-малки, хостваните услуги са по-лесни.

Услугите на AWS са смесени

Опитът ми с услугите на AWS е смесен. Тяхната услуга Elasticsearch беше ненадеждна, затова си пускаме собствени инстанции. Метриките на CloudWatch са скъпи, затова като цяло ги използваме само за метрики на ниво „инфраструктура“, а не на приложение, т.е. метрики, свързани със здравето, където AWS може да знае по-добре какво се случва от софтуера, работещ на инстанцията. Логовете на CloudWatch могат да са бавни за обновяване и нямат толкова метаданни. Пускането на 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 обаче в момента е доста ненадеждна. Ухапаха ме няколко проблема от страницата ѝ с issues в GitHub, които изглежда никога не се поправят. Искам да се откажа от нея и да изпращам директно от нашите приложения към Kafka.

Коментар: Сега изпращаме структурирани събития директно от приложението към Kafka. Основната мотивация беше да докосваме логовите данни по-рядко и да избегнем многократното четене и запис на диска. В системи с голям обем логването може да изисква повече работа от самото приложение. Мисля и journald също да изпраща логове директно, от програма на C.

Loki

Следете Loki. Още не е готово, но когато бъде, очаквам да пасне по-добре на този стек. Loki е агрегатор на логове, създаден от Grafana Labs, използва подобен синтаксис за събиране и етикети като Prometheus.

Prometheus + alertmanager + Rollbar + Graylog + Grafana

Prometheus + alertmanager за метрики. <3 Prometheus.

Rollbar/Graylog за логване/докладване на грешки (има известно припокриване; малка услуга вероятно не се нуждае от двете).

В момента известията отиват само в един от няколко канала в Slack, където заинтересованите страни имат включени известия. Ако приемехме дежурството (on-call) по-сериозно, щяха да отиват в PagerDuty/VictorOps и т.н.

Grafana за графики и табла. Също така очаквам с нетърпение да видя дали предстоящите им възможности за логване ще направят Graylog ненужен.

Thanos

Използваме Thanos като front-end за нашата HA настройка. Може да дедупликира HA двойки.

В момента пазим 6 месеца локални данни на Prometheus. За нас работи сравнително добре. Но съм в средата на въвеждането на хранилище bucket в настройката ни на Thanos за дългосрочно съхранение на данни. Теоретично хранилището GCS ще бъде с около 30% по-евтино от стандартния постоянен диск на GCE, който използваме сега.

В момента не правим резервни копия на данните на Prometheus. Данните всъщност не са важни за нас освен да имаме достатъчно за известия. Общото ни внедряване на флота се променя толкова много от година на година, че историческите данни, по-стари от няколко месеца, не са наистина интересни. Може да е интересно да имаме няколко основни статистики година към година; мога да настроя набор от правила за запис за основни статистики и да ги съхранявам с помощта на Federation или просто да оставя Thanos да се погрижи.

EDIT: Малко уточнение, аз съм разработчик на 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. Логовете все още отиват в плана birch на LogDNA, защото забелязахме, че ELK е твърде тежък за нашия скромен клъстер с мин. 3 и макс. 5 възела в GKE.

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.

За докладване на сривове на front-end използваме Sentry, но скоро ще преминем към Experience.

Отказ от отговорност: аз съм Sematextan (служител на 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 за пакетни задачи/cronjob-ове

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 за end-to-end мониторинг на услуги, главно за уеб API и уеб приложения

OpsGenie за управление на известия

Slack за получаване на информация за състоянието от нашите системи

Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail

Дългогодишен (dev)ops инженер. Израснах с Nagios. Бих искал да чуя мнения за моя bootstrapped 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. Все още не съм 100% решен относно управлението на логове.

Nagios + ELK

Поддържаме над 100 продукта.

За on-prem това са най-вече Nagios и ELK. В облака мигрираме от DataDog към NewRelic.

Datadog vs. 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% от случаите автоматизацията + нашите скриптове ни държат извън беда).

Имаме вътрешни runbook-ове в нашата база знания за случай, че автоматите се провалят или трябва да се поправи нещо извън обхвата.

Prometheus + AlertManager + Grafana + Stackdriver

Prometheus (Operator) / AlertManager / Grafana за метрики в нашите клъстери GKE и на виртуални машини.

Google Stackdriver за логове (защото е включен и активен по подразбиране и в момента е достатъчен за нашите нужди).

Zabbix

Zabbix за всичко. Не е нужен друг софтуер.