Как настроить push-уведомления для сервисов?

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

Вот смотри, стандартный стек для этой песни — Prometheus + Alertmanager. Без них сейчас — как без рук, ёпта. Настраивается всё, в принципе, не адово, но если накосячить, то доверия ебать ноль будет от всей системы.

Как это обычно выглядит:

1. Prometheus — этот чувак всё мониторит и, если что, начинает орать. Но орать он будет не сам, а через правила. Пишешь их в alert_rules.yml:

   groups:
   - name: example
     rules:
     - alert: HighPodMemoryUsage
       expr: sum(container_memory_working_set_bytes{pod!=""}) by (pod) / sum(kube_pod_container_resource_limits{resource="memory"}) by (pod) > 0.9
       for: 5m
       labels:
         severity: warning
       annotations:
         summary: "Pod {{ $labels.pod }} memory usage is above 90%"

   Суть простая: если подъёбывает память больше 90% дольше пяти минут — готовься, щас будет волнение ебать. Главное, выражение в expr написать правильно, а то будет либо молчать, как партизан, либо орать почём зря.

2. Alertmanager — вот это уже хитрая жопа, которая решает, куда и как кричать. Его конфиг (alertmanager.yml) — это где вся магия маршрутизации.

   route:
     group_by: ['alertname', 'cluster']
     receiver: 'slack-notifications'
   receivers:
   - name: 'slack-notifications'
     slack_configs:
     - api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'
       channel: '#alerts-prod'
       title: '{{ .GroupLabels.alertname }}'
       text: '{{ range .Alerts }}{{ .Annotations.summary }}n{{ end }}'
   - name: 'pagerduty'
     pagerduty_configs:
     - routing_key: 'your_pagerduty_integration_key'

   Тут ты говоришь: «Слушай, все алерты, сгруппированные по имени и кластеру, летите в слак на канал `#alerts-prod». А если совсем пиздец (critical), то можно и в PagerDuty впендюрить, чтобы дежурный проснулся с чувством, что его ебёт медведь.

А ещё есть CI/CD, про который забывать нельзя. Ну, типа, пайплайн сломался или деплой прошёл — тоже надо знать. Тут обычно тупо вебхуки настраиваешь.

Вот смотри, кусок из .gitlab-ci.yml:

notify_on_failure:
  stage: .post
  script:
    - |
      if [ "$CI_JOB_STATUS" = "failed" ]; then
        curl -X POST -H 'Content-Type: application/json' --data "{"text":"Pipeline $CI_PIPELINE_ID for $CI_PROJECT_NAME failed."}" $SLACK_WEBHOOK_URL
      fi
  when: on_failure

Всё просто: упала джоба — скрипт берет и хуярит POST-запрос в слак. И ты сразу видишь, что твой код — говно, и надо срочно фиксить, а не пить кофе.

Главный принцип, который надо высечь у себя на подкорке: уведомление должно быть таким, чтобы с первого взгляда было понятно — что сломалось, насколько это серьёзно и куда бежать смотреть логи или графики. Просто сообщение «всё плохо» — это пиздопроебибна, от которой терпения ноль ебать через пять минут. Добавляй ссылки на дашборд, метки, severity. Сделай так, чтобы дежурный не тратил полчаса на то, чтобы просто понять, в каком сервисе проблема. И тогда, может быть, тебя не пошлют на хуй в следующий раз, когда в три ночи что-то грохнется.