Опять observability.

Признаюсь, за весь свой опыт работы с алёртингом я больше тратил время не на технические задачи.
Сделать сбор метрик, отсеять лишние, повесить алёрты и создать каналы слака/телеграма, забив их людьми и повесив дежурство это на самом деле не сложно.
Не сложно и напилить борды в графане и сделать линк до инцидента в самом алёрте.
Технические задачи решаются легче всего.

Самое сложное сперва было
- разобраться с severity levels
- сделать порядок (флоу?rule?) куда чего и как будет идти
- понять кто за что ответственен

Вот допустим мы говорим строго про инженеров платформы/инфраструктуры.
Чего мы хотим видеть в северити:
- info - информативные сообщения, которые скорее всего будут добавлены в канал оповещения с mute и лезть мы туда будем постфактум "а чо было". Например что джоба в кубере выполнялась больше 25 минут.
- warning - предупреждения, что скоро будет не ок. Например 80% заполнения диска на критикал инфре. Пока не проблема, но может стать проблемой в будущем.
- critical - ну тут понятно. Кластер упал, место закончилось, бизнес аппликейшн последние 3 минуты выдает 502 ошибки и всё легло.
Никаких вопросов тут не вызывало никогда у меня, ни развесить северити, ни определиться с каналом оповещения.

А что делать со сторонними сервисами?
Мы так много говорим про девопс, но не можем самим себе ответить на простые вопросы.
Например ArgoCD.
Куда отправлять алёрты такого плана?

argocd_app_info{health_status!="Healthy"} != 0
argocd_app_info{sync_status!="Synced"} != 0

Девелоперам? Инженерам инфры? А если не прод, а demo/UAT кластер?
Нужно ли это смотреть девопсам?
В общий канал про прод критикал инциденты или отдельный для арго?
Если для арго, то один общий на все енвы или под каждый стенд/енв/проект?

Ладно, допустим арго не самая сложная штука.
Мы мониторим Azure Enterprise application (+service principle credentials expire).
Вот в аппликейшн не заходили полгода. Куда писать, чтобы удалить эту неиспользуемую? Это ворнинг или инфо?
Если креды протухнут скоро кому писать? Опсы и девопсы вообще не в курсе что это за креды и где они могут использоваться.

Airflow. Упал DAG.
опять кому писать? о чем?
То, что там нет метода это не важно опсам, но нужно QA.
А если DAG упал, потому что на нодах, где запускаются воркеры нет ресурсов, то это уже инфровая часть.
Как их разделять если там нет привычного label фильтрации.
Нужно ли знать о том, что в проде упал даг или это простая фигня не важная?

Усложняем задачи.
У нас есть базы данных и deadlock. Кому писать?
А дедлок по факту свершения или есть их +5 за последние 5 минут?
Это критикал или ворнинг?

Ладно, trino. На UAT долго повис запрос и сожрал всю память, а остальные 56 запросов висят в очереди час.
(кстати это аффектит и Airflow и всё ETL)
Кому об этом писать и как?


Наверное пора прийти к какому-то шаблону для тех, кто приходит с новым алёртом.
Думаю о варианте типа:
- автор алёрта(команда/человек)
- expr/metric+threashold
- какой severity алёрта
- в какой канал уведомлять(почта/слак/телеграм/голуби)
- правило, если каналов несколько
Нет этой информации - нет и алёрта.
Эх, мечты мечты, придут ко мне срочно и всё равно и без заявки и без ответственного лупану алёрт в общий канал.🤣

То есть большую часть занимают размышление и правильный флоу, чем написание кода и конфигов.

Основная же стратегия пока примерно такая:
- у каждого алёрта есть обязательный severity, который назначается при создании алёрта
например

- alert: JobFailed
  expr: kube_job_status_failed{} > 0
  labels:
    severity: info

- на всех метриках мы используем лейбл cluster(если он есть), либо обогащаем этим лейблом, если это не в кубере(например виртуальная машина)
- а затем через rules мы роутим в нужные каналы уведомлений согласно типа алёрта/кластера/имени алёрта/аутедж и так далее
- пример отобразил на графике

Это не финальный результат, наверняка буду менять не единожды, но это уже работает и большинство коллег устраивает.

#observability #alertmanager