Prometheus: Alertmanager Web UI и Silence алертов

Автор: | 30/12/2020
Нет комментариев

Частота отправки активных алертов из Alertmanager определяется параметром repeat_interval в файле /etc/alertmanager/config.yml.

У нас этот интервал задан в 15 минут, в результате чего в Slack каждые 15 минут приходят уведомления обо всех активных алертах в системе.

Но некоторые алерты это такие себе “known issue”, когда о проблеме мы знаем, девелоперы её взяли в работу для фикса – а вот алерты продолжают приходить.

Что бы отключить повторную отправку таких алертов – их можно пометить как “silenced“.

Включается Silence алерта через Web UI самого Alertmanager, см. документацию.

Собственно, что будем делать:

  • обновим аргументы запуска Alertmanager, что бы настроить доступ к веб-интерфейсу
  • обновим виртуалхост NGINX, что бы получить доступ к Alertmanager
  • проверим и настроим работу Prometheus для отправки алертов
  • добавим алерт, и посмотрим, как его добавить в silenced

Настройка Alertmanager Web UI

У нас Alertmanager запускается из Docker Compose, добавляем в command два параметра – web.route-prefix, который указывает URI, по которому будет доступен Alertmanager Web UI, и web.external-url, который указывает на URL.

Полностью путь будет выглядеть как dev.monitor.example.com/alertmanager – добавляем их:

...
  alertmanager:
    image: prom/alertmanager:v0.21.0
    networks:
      - prometheus
    ports:
      - 9093:9093
    volumes:
      - /etc/prometheus/alertmanager_config.yml:/etc/alertmanager/config.yml
    command:
      - '--config.file=/etc/alertmanager/config.yml'
      - '--web.route-prefix=/alertmanager'
      - '--web.external-url=https://dev.monitor.example.com/alertmanager'
...

Alertmanager работает в Docker-контейнере, и доступен с хоста по адресу localhost:9093:

[simterm]

root@monitoring-dev:/home/admin# docker ps | grep alert
24ae3babd644        prom/alertmanager:v0.21.0                                          "/bin/alertmanager -…"   3 seconds ago       Up 1 second             0.0.0.0:9093->9093/tcp   prometheus_alertmanager_1

[/simterm]

В файле настроек NGINX добавляем новый upstream, в котором указываем Docker-контейнер с Alertmanager:

...
upstream alertmanager {
    server 127.0.0.1:9093;
}
...

Там же добавляем location, который будет проксировать все запросы на dev.monitor.example.com/alertmanager к этому апстриму:

...
    location /alertmanager {
        
        proxy_redirect          off;            
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://alertmanager$request_uri;
    }
...

Сохраняем, и перезапускаем NGINX и Alertmanager.

Открываем https://dev.monitor.example.com/alertmanager, и попадаем в веб-интерфейс:

Тут пока пусто – ждём, пока в Prometheus сработают алерты.

Prometheus: “Error sending alert” err=”bad response status 404 Not Found”

Сейчас в логах Prometheus при попытке им отправить алерты в Alertmanager будет ошибка:

caller=notifier.go:527 component=notifier alertmanager=http://alertmanager:9093/api/v1/alerts count=3 msg=”Error sending alert” err=”bad response status 404 Not Found”

Возникает она вполне логично, так как в настройках Prometheus Alertmanager задан как:

...
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - alertmanager:9093
...

Что бы добавить URI, по которому у нас теперь доступен Alertmanager – используем path_prefix:

...
alerting:
  alertmanagers:
  - path_prefix: "/alertmanager/"
    static_configs:
    - targets:
      - alertmanager:9093
...

Перезапускаем Prometheus, и ещё раз ждём алерты:

И они же появляются в UI самого Alertmanager:

Alertmanager: Silence алертов

Теперь отключим повторную отправку алертов.

Например, что бы отключить все алерты alertname=”APIendpointProbeSuccessCritical” – кликаем на +:

Затем Silence:

Лейбл alertname добавляется в условие, задаём период, по-умолчанию два часа, добавляем кто создал silence и описание:

Жмём Create – готово:

И можно проверить через API:

[simterm]

root@monitoring-dev:/home/admin# curl -s http://localhost:9093/alertmanager/api/v1/alerts | jq '.data[1]' 
{
  "labels": {
    "alertname": "APIendpointProbeSuccessCritical",
    "instance": "http://push.example.com",
    "job": "blackbox",
    "monitor": "monitoring-dev",
    "severity": "critical"
  },
  "annotations": {
    "description": "Cant access API endpoint http://push.example.com!",
    "summary": "API endpoint down!"
  },
  "startsAt": "2020-12-30T11:25:25.953289015Z",
  "endsAt": "2020-12-30T11:43:25.953289015Z",
  "generatorURL": "https://dev.monitor.example.com/prometheus/graph?g0.expr=probe_success%7Binstance%21%3D%22https%3A%2F%2Fokta.example.com%22%2Cjob%3D%22blackbox%22%7D+%21%3D+1&g0.tab=1",
  "status": {
    "state": "suppressed",
    "silencedBy": [
      "ec11c989-f66e-448e-837c-d788c1db8aa4"
    ],
    "inhibitedBy": null
  },
  "receivers": [
    "critical"
  ],
  "fingerprint": "01e79a8dd541cf69"
}

[/simterm]

Алерт в Slack отправляться не будет:

[simterm]

...
  "status": {
    "state": "suppressed",
    "silencedBy": [
      "ec11c989-f66e-448e-837c-d788c1db8aa4"
    ],
...

[/simterm]

Готово.