ilert: альтернатива Opsgenie – перше знайомство, Alertmanager, Slack
5 (1)

Автор |  24/02/2026
0 коментарів
Click to rate this post!
[Total: 1 Average: 5]

Думаю, всі юзери Opsgenie в курсі, що Atlassian вбиває закриває проект.

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

Коли почав шукати альтернативи – натрапив на пост на Reddit – Anyone using Opsgenie? What’s your replacement plan, де дуже багато писали про incident.io – але це саме той випадок, коли мільйони мух таки можуть помилятись, бо більш ущєрбної системи я не бачив.

До речі, зрозумів одну річ: якщо знайомство з системою приводить тебе до думки піти на Youtube, аби глянути як люди цю систему налаштовують – то у цієї у системи явні проблеми або з UI/UX, або з документацією – і це 100% випадок incident.io, при чому по обом пунктам.

Прої… Провозившись з нею кілька днів в спробах таки змусити її відправляти текст в Slack так, як я того хочу – знов почав шукати альтернативи, і в тому ж треді на Reddit натрапив на ilert, і… Боже – це любов з першого погляду.

Все завелось просто за 15 хвилин і без всякого додаткового геморою з налаштуванням того, як повідомлення будуть виглядати в Slack.

Якісь косяки/незручності 100% зустрінуться, але поки що система виглядає саме так, як це має бути – без зайвих свістопєрдєлок, з простим, зручним і інтуїтивно зрозумілим (інтуїтивно зрозумілим, блт – чуєш, incident.io?!) інтерфейсом.

Отже сьогодні подивимось на основні можливості і налаштуємо ilert на відправку алертів.

Власне – що особисто мені треба від системи алертів? Ну… алерти. Відправка алертів. Зручний UI для перегляду алертів, і можливість налаштування шаблонів для повідомлень в Slack, бо це у нас основний канал доставки.

З інтеграцій треба вміти приймати алерти від стандартного Alertmanager та від AWS SNS.

Ну і наявність адекватної (адекватної, incident.io!) документації.

Все!

Поїхали.

Посилань на документацію ilert буде багато, почати можна з Opsgenie to ilert Migration Guide або VictoriaMetrics Integration.

ilert overview та основні можливості

Після реєстрації попадаємо в дашборд – і ви просто зацініть, як тут все класно виглядає – просто, функціонально, зрозуміло:

Основні можливості:

  • є Terraform provider
    • є експорт конфігурації відразу в Terraform
  • алертинг – SMS, Voice calls, Slack, Telegram, web-hooks і упасібоже MS Teams
  • стандартний On-call management  – ротації, розклад, ескалації
  • ChatOps – управління алертами зі Slack
  • AI SRE – ще не трогав, але спробую, хоча це наче ще в Beta
  • postmortems, incidents
  • REST API
  • десь бачив можливість збирати метрики з Prometheus/VictoriaMetrics, але це ще тестив
  • MCP для LLM
  • мобільна апка (теж ще не дивився)
  • Status Pages

Ну і овер 100 інтеграцій – All Integrations.

Pricing

Див. Pricing.

Є Free Plan, в який до того ж входить Heaerbeat, є Status Page, On-call/voice/SMS – з обмеженнями, але включено.

Є в дашборді:

Початок роботи

Основне – це, звісно, алерти, тому глянемо що тут є.

Головні концепти ilert по алертам – це Alert sources та Alert actions:

  • Alert sources: власне, джерела алертів – Alertmanager, AWS SNS, etc
  • Alert actions: правила того, що з алертами робити – відправити повідомлення, оновити статус Status Pages, пушнути webhook

З чого почнемо, і що мені треба з основного:

  • почати приймати алерти від Alertmanager
  • налаштувати відправку в Slack
    • подивитись на роутинг алертів – аби в Slack відправляти по різним каналам
    • подивитись на шаблони повідомлень

Підключення Alertmanager

Переходимо в Alert sources, додаємо новий:

Вибираємо Prometheus – це, власне, і буде Alertmanager:

Документація – Prometheus Integration, і взагалі посилання на документацію є майже всюди, та і сама документація чудова.

Задаємо ім’я:

Задаємо Esclation Policy – далі трохи про них ще поговоримо:

Grouping – none, в мене цим займається Alertmanager:

Тут жеж можна налаштувати Templaing, але поки не робимо – далі буде трохи детальніше:

Тут жеж можна задати фільтри – при яких умовах алерт буде відправлений сюди, але поки теж не включаємо – теж буде трохи далі:

Клікаємо внизу Finish setup, отримуємо ключ і повний URL:

Налаштування Alertmanager

Переходимо до конфіга Alertmanager, додаємо новий роут:

...
      routes:

        - matchers:
            - component="devops"
          receiver: ilert-notifications
          continue: true
...

Та reciever:

...
    receivers:

      - name: 'ilert-notifications'
        webhook_configs:
        - url: 'https://api.ilert.com/api/v1/events/prometheus/il1prom***c94'
...

Можна відправити тестовий алерт з curl:

$ curl -X POST https://api.ilert.com/api/v1/events/prometheus/*** -H "Content-Type: application/json" -d '{"receiver":"ilert-default","status":"firing","alerts":[{"status":"firing","labels":{"alertname":"Test","severity":"warning"},"annotations":{"summary":"Test alert"},"startsAt":"2026-02-24T00:00:00Z","endsAt":"0001-01-01T00:00:00Z","fingerprint":"test123"}],"groupLabels":{"alertname":"Test"},"commonLabels":{"alertname":"Test","severity":"warning"},"commonAnnotations":{"summary":"Test alert"},"externalURL":"http://localhost:9093","version":"4","groupKey":"test"}'

І дуже корисні логи:

В яких буде видно весь payload, і як його розпарсив ilert:

Ну і простий і дуже зручний UI з алертами:

Налаштування алертів в Slack

Переходимо в Alert Actions, додаємо новий:

Вибираємо Slack, не включаємо галочку “Use webhook“:

Підключаємо Alert source, який буде сюди слати алерти, вибираємо на які події слати повідомлення:

Ну і фільтри – але поки пропускаємо:

Задаємо ім’я Action, вибираємо канал, в який будуть йти повідомлення:

Можна тицнути Test:

І посміятись 🙂

Чекаємо на алерт з Alertmanager – і ви просто подивіться на цю красу з коробки!

Всі Connectors трохи сховали – шукаємо в Settings:

Роутинг повідомлень в Slack channels

Тепер, як загальний алертинг працює – починаємо тюнити.

Перше, що треба – це роутинг алертів:

  • є кілька оточень – dev, staging, prod, ops
  • є різні команди – devops, backend, web, data

Для кожної команди у нас є окремі Slack channels – #alerts-backend-prod, #alerts-devops-ops і так далі.

Що треба зробити – щоб алерти Backend Prod йшли в канал #alerts-backend-prod, а алерти для девопсів, відповідно, в канал #alerts-devops-ops.

Для Opsgenie це в мене було реалізовано через роутинг в самому Opsgenie:

А labels задаються в алертах:

...
      - alert: Kubernetes Pod UnHealthy
        expr: k8s:pod:unhealthy{namespace="prod-backend-api-ns"} > 0
        for: 15m
        labels:
          severity: warning
          component: backend
          environment: prod
...

І вже по ним Opsgenie  вибирає через яку Slack-інтеграцію слати алерт.

Власне, в ilert можна зробити таким самим чином, бо аналогічно до Opsgenie – кожен Slack Connector прив’язується до конкретного каналу.

А тому:

  • маємо Alert Source: Alertmanager
  • для нього створюємо кілька Alert actions:
    • slack-alerts-backend-prod: використовує Slack connector, налаштований на #alerts-backend-prod
    • slack-alerts-devops-ops: використовує Slack connector, налаштований на #alerts-devops-ops

Ще є дуже прикольна штука з динамічними роутами через Escalation Policy – далі подивимось.

Static alert rounting

Спершу дивимось, в якому вигляді ilert отримує алерт – переходимо в Alert source > Alert logs, відкриваємо якийсь алерт:

Далі переходимо в Alert actions і додаємо новий (чи редагуємо старий) Action.

Тут все аналогічно до того, як підключали Slack вище – але тепер включаємо Conditional execution і задаємо умову:

Або пишемо кодом – див. ICL – ilert condition language:

(alert.labels.component in ["devops"])

Задаємо канал:

Фільтр готовий:

Тепер алерти з label component="devops" підуть в канал #alerts-devops-ops.

Dynamic alert routing

Інший прикольний варіант – через Dynamic escalation policy routing.

Суть його в тому, що створюється кілька Escalation policices, яким задається Routing key – просто якесь string значення.

Далі в Alert source вмикається Dynamic routing та вказується поле алерта, з якого отримується значення – і, використовуючи це значення, до нового алерта автоматично підключається Escalation policy.

А в Alert Action використовується значення не (alert.labels.component in ["devops"]), як робили вище – а з roting_id, через який підключається відповідна політика.

Цей підхід краще в плані того, що відразу налаштовується не тільки куди слати алерт – а і як його escalate.

Пробуємо.

Переходимо в On-Call > Escalation policies, створюємо нову політику:

Задаємо Routing key:

Аналогічно для Backend:

Тепер переходимо в Alert sources > Alert actions і задаємо фільтр по alert.escalationPolicy.id:

І для бекенду:

Дал редагуємо сам Alert source, включаємо Dynamic routing вказуємо label з алерта, яку треба читати – в моєму прикладі це {{ alerts[0].labels.routing }}:

Тепер:

  • Alert source розпарсить {{ alerts[0].labels.routing }}
  • отримає значення “devops“
  • по цьому значенню динамічно підключить Escalation policy
  • передать алерт в Alert Actions
  • а кожен екшен з Alert Actions перевірить свій фільтр alert.escalationPolicy.id – і спрацює той Action і його Connector, який “підключений” (чи “замаплений”) саме до slack-alerts-backend-prod або slack-alerts-devops-ops

В алертах додаємо нову лейблу – routing: alerts-devops-ops та routing: alerts-backend-prod:

...

      - alert: Route Test => alerts-devops-ops (alertname) 5
        expr: sum(kube_pod_info{namespace="ops-monitoring-ns", pod=~".*grafana.*"}) by (cluster, namespace, pod) >= 0
        for: 1s
        labels:
          severity: warning
          component: devops
          environment: ops
          routing: alerts-devops-ops
        annotations:
          summary: "Route Test (summary) 5"
          description:

      - alert: Route Test => alerts-backend-prod (alertname) 5
        expr: sum(kube_pod_info{namespace="ops-monitoring-ns", pod=~".*grafana.*"}) by (cluster, namespace, pod) >= 0
        for: 1s
        labels:
          severity: warning
          component: devops
          environment: ops
          routing: alerts-backend-prod
        annotations:
          summary: "Route Test (summary) 5"
          description:

...

І отримуємо алерти в різні канали.

Девопси:

Бекенди:

Блін – я в захваті від системи 🙂

Slack messages templating

Документація – Alert template.

Тут, в принципі, все доволі просто – задаємо поля з alert payload, можемо використовувати різні Functions – наприклад, [{{ commonLabels.severity.upperCase() }}].

В полях маленька кнопочка “play” справа внизу дозволяє відразу перевірити, як шаблон буде працювати:

Додамо новий алерт:

...
      - alert: Template Test (alertname) 1
        expr: sum(kube_pod_info{namespace="ops-monitoring-ns", pod=~".*grafana.*"}) by (cluster, namespace, pod) >= 0
        for: 1s
        labels:
          severity: warning
          component: devops
          environment: ops
          routing: alerts-devops-ops
        annotations:
          summary: "Template Test (summary) 1"
          description: "Template Test (description)"
          grafana_pod_overview_url: 'https://{{ .Values.monitoring.root_url }}/d/kubernetes-pod-overview/kubernetes-pod-overview?orgId=1&var-namespace={{ "{{" }} $labels.involvedObject_namespace }}&var-pod={{ "{{" }} $labels.pod }}'
...

Результат:

Heartbeat monitors

Heartbeat monitors – теж прикольна штука, але тут, в принципі, все просто – створюємо Alert source, отримуємо URL, і періодично до нього шлемо запит.

Як тільки пропустили відправку сигналу – спрацьовує алерт.

Пробуємо з curl:

$ curl -v https://beat.ilert.com/api/pings/ih2***
* Host beat.ilert.com:443 was resolved.
...
> GET /api/pings/ih2:25*** HTTP/1.1
...

І через заданий таймаут він стане Expired, і спрацює Alert action.

Deployment events – не тестив, але виглядає цікаво.

Summary або загальні враження

Просто система алертів, якою вона має бути.

Чим мені сподобався Backblaze – це простим і інтуїтивно зрозумілим інтерфейсом (див. Backblaze: знайомство з B2 Cloud Storage – перші враження).

Чому я просто закохався в ilert – простий інтерфейс, інтуїтивно зрозумілий інтерфейс і чудова документація.

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

Loading