Cảnh báo bằng cuộc gọi cho Prometheus Alertmanager: chỉ đánh thức khi thật nguy cấp

Mục lục

• Vì sao Alertmanager không thể tự làm điện thoại bạn đổ chuông
• Bạn cần những gì
• Bước 1 — Tạo một kênh sẽ gọi cho bạn
• Bước 2 — Thêm một receiver webhook
• Bước 3 — Hiểu rõ thứ thật sự được gửi tới
• Bước 4 — Gửi thông báo phục hồi dưới dạng push yên tĩnh
• Bước 5 — Định tuyến theo mức nghiêm trọng, đừng gửi tất tần tật
• Bước 6 — Cái bẫy mang tên Watchdog
• Tinh chỉnh để nó không hóa thành cậu bé chăn cừu
• Chỉ đổ chuông ngoài giờ làm việc
• Xử lý vấn đề commonLabels rỗng
• Giữ cho payload nhỏ gọn
• Chia sẻ cảnh báo với cả nhóm
• Những gì thiết lập này không mang lại cho bạn
• Xử lý sự cố
• Câu hỏi thường gặp
• Prometheus Alertmanager có tự gọi điện được không?
• Cuộc gọi có vượt qua chế độ Không làm phiền không?
• Cách này có dùng được với Alertmanager sau tường lửa hoặc bên trong Kubernetes không?
• Làm sao để không bị gọi khi một cảnh báo được giải quyết?
• Vì sao điện thoại tôi reo bốn tiếng một lần cho cùng một cảnh báo?
• Nhiều người có thể cùng được gọi cho một cảnh báo không?
• Nên lọc mức nghiêm trọng trong Alertmanager hay trong điều kiện của Echobell?
• Tổng kết
• Liên quan

Alertmanager không có receiver gọi thoại. Để nhận cuộc gọi khi một cảnh báo Prometheus kích hoạt, hãy thêm một receiver webhook_configs trỏ tới một kênh Echobell có loại đăng ký là Cuộc gọi. Bài viết này trình bày đúng đoạn YAML cần dùng, điều kiện giúp cảnh báo đã phục hồi không gọi cho bạn, cách định tuyến theo mức nghiêm trọng, và cảnh báo Watchdog — thứ nếu không xử lý sẽ làm điện thoại bạn đổ chuông bốn tiếng một lần, mãi mãi.

Prometheus là hệ thu thập số liệu mặc định của phần lớn hạ tầng được xây trong thập kỷ qua, và Alertmanager thật sự rất giỏi ở những phần khó: khử trùng lặp cảnh báo, gom nhóm, tắt tiếng trong lúc bảo trì, và ức chế tiếng ồn phía dưới khi một thành phần phụ thuộc phía trên gặp sự cố.

Thứ nó không làm được là đánh thức ai đó dậy.

Vì sao Alertmanager không thể tự làm điện thoại bạn đổ chuông

Alertmanager có sẵn receiver cho email, Slack, PagerDuty, OpsGenie, Discord, Telegram, Pushover, Webex, MS Teams và cả tá thứ khác. Nhưng tất cả đều gửi đi một tin nhắn, mà tin nhắn thì chịu sự chi phối của nút gạt chuông, chế độ Không làm phiền và các chế độ Tập trung của iOS. Vào 03:00, điều đó có nghĩa là cảnh báo đến nơi và chẳng có gì xảy ra.

Không hề có voice_configs. Những lựa chọn mà người ta thường tìm đến là:

• PagerDuty / OpsGenie / Splunk On-Call — chúng thật sự gọi điện, và chúng là các nền tảng quản lý sự cố đầy đủ với mức giá theo đầu người tương xứng. Đây là câu trả lời đúng nếu bạn cần lịch xoay ca và cây leo thang; nhưng quá nặng nếu bạn chỉ cần một chiếc điện thoại đổ chuông. (Riêng OpsGenie thì đang dần đóng cửa, đó là lý do rất nhiều nhóm đang đánh giá lại tầng này ngay lúc này.)
• Cầu nối SMS như Sachet — bạn phải chạy thêm một dịch vụ, trả tiền cho gateway theo từng tin, và SMS rốt cuộc vẫn chỉ là một tin nhắn. Trên iOS, một tin nhắn không xuyên qua chế độ Tập trung trừ khi người gửi nằm trong danh sách cho phép của bạn.
• Tự ghép nối với Twilio — viết một receiver webhook nhỏ, mua một số điện thoại, trả tiền theo cuộc gọi, và thế là bạn sở hữu thêm một mảnh hạ tầng production mà việc duy nhất của nó là làm một chiếc điện thoại reo lên.

Receiver webhook dạng chung chính là lối thoát. Nó POST một payload JSON có tài liệu rõ ràng tới bất kỳ URL nào, và đó là tất cả những gì bạn cần.

Bạn cần những gì

• Một hệ Prometheus + Alertmanager đang chạy, và quyền sửa alertmanager.yml
• Đã cài Echobell (App Store / Google Play)
• Mười phút

Bài viết này được viết dựa trên Alertmanager 0.31. Payload webhook đã ở version: "4" suốt nhiều năm, nên các bản 0.2x cũng hoạt động y hệt.

Alertmanager của bạn cần kết nối HTTPS ra ngoài tới hook.echobell.one. Nó không cần truy cập được từ Internet, nên một Alertmanager nằm trong cluster, trong VPC hay trong homelab đều dùng tốt.

Bước 1 — Tạo một kênh sẽ gọi cho bạn

Trong Echobell, hãy tạo một kênh tên kiểu như Prometheus Critical. Đặt loại thông báo của đăng ký là Cuộc gọi. Đây chính là thiết lập quan trọng: cảnh báo loại Cuộc gọi hiện lên như một màn hình cuộc gọi đến và đổ chuông xuyên qua chế độ Tập trung và Không làm phiền của iOS, điều mà thông báo đẩy không làm được.

Hãy đặt mẫu để đọc thẳng payload của Alertmanager:

Title: 🔴 {{commonLabels.alertname}} on {{commonLabels.instance}}
Body: {{commonAnnotations.summary}}
{{commonAnnotations.description}}

Và trong Cài đặt nâng cao, đặt một Mẫu liên kết để bản ghi thông báo nhảy thẳng tới biểu đồ:

{{alerts[0].generatorURL}}

Sau đó sao chép Webhook URL của kênh:

https://hook.echobell.one/t/<channel-token>

Hãy coi URL đó là thông tin bí mật — ai cầm nó cũng có thể làm điện thoại bạn đổ chuông.

Bước 2 — Thêm một receiver webhook

Trong alertmanager.yml:

route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-critical

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false

Nạp lại cấu hình bằng curl -X POST http://localhost:9093/-/reload hoặc SIGHUP.

Hãy để ý send_resolved: false. Mặc định của receiver webhook là true, khác với hầu hết các receiver khác của Alertmanager, nên bỏ trống dòng này nghĩa là điện thoại bạn reo khi dịch vụ hỏng và reo lần nữa khi nó tự phục hồi. Chính cuộc gọi thứ hai mới là thứ dạy người ta bỏ qua cuộc gọi thứ nhất. Bước 4 chỉ cách lấy lại thông báo phục hồi mà không kèm tiếng chuông.

Bước 3 — Hiểu rõ thứ thật sự được gửi tới

Alertmanager gom nhóm các cảnh báo, rồi POST một payload cho mỗi nhóm:

{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighErrorRate\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "echobell-critical",
  "groupLabels": { "alertname": "HighErrorRate" },
  "commonLabels": { "alertname": "HighErrorRate", "severity": "critical" },
  "commonAnnotations": { "summary": "Error rate above 5% for 10m" },
  "externalURL": "http://alertmanager.internal:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighErrorRate", "instance": "api-7d9f:8080" },
      "annotations": { "summary": "Error rate above 5% for 10m" },
      "startsAt": "2026-09-04T02:41:07.351Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "http://prometheus:9090/graph?g0.expr=...",
      "fingerprint": "a1b2c3d4e5f60718"
    }
  ]
}

Echobell đọc nguyên phần body JSON, nên mọi trường trong đó đều dùng được trong mẫu và điều kiện. Truy cập lồng nhau dùng được cả hai cú pháp — {{commonLabels.severity}} hoặc {{alerts[0].labels["instance"]}}.

Hai đặc tính của payload này chi phối mọi thứ bên dưới:

Trường status ở cấp cao nhất là firing nếu bất kỳ cảnh báo nào trong nhóm đang kích hoạt. Nó chỉ chuyển thành resolved khi mọi cảnh báo trong nhóm đã được giải quyết. Điều đó khiến nó là thứ rất gọn để lọc theo.

commonLabels chỉ chứa những nhãn mà mọi cảnh báo trong nhóm cùng có. Đây là bất ngờ phổ biến nhất. Nếu group_by đủ rộng để một webhook mang theo HighErrorRate trên ba instance khác nhau, thì commonLabels.instance sẽ không tồn tại và {{commonLabels.instance}} hiển thị thành chuỗi rỗng. Cách xử lý được nói kỹ hơn ở bên dưới.

Bước 4 — Gửi thông báo phục hồi dưới dạng push yên tĩnh

Bạn vẫn muốn biết khi có thứ gì đó phục hồi — chỉ là không muốn bị gọi vì chuyện đó. Hãy thêm một kênh Echobell thứ hai tên Prometheus Recovered, đặt loại thông báo là Thông thường, và cho nó các mẫu này:

Title: ✅ {{commonLabels.alertname}} resolved
Body: {{commonAnnotations.summary}}

rồi trong Cài đặt nâng cao, đặt điều kiện này:

status == "resolved"

Điều kiện là các biểu thức được tính trước khi bất cứ thứ gì được gửi đi. Nếu biểu thức sai, Echobell vẫn chấp nhận request nhưng không gửi gì cả.

Sau đó trỏ cùng một receiver tới cả hai kênh — một receiver có thể chứa nhiều webhook_configs:

receivers:
  - name: echobell-critical
    webhook_configs:
      # Làm điện thoại đổ chuông. Chỉ khi đang kích hoạt.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # Push yên tĩnh. Điều kiện của kênh sẽ loại bỏ nửa "firing".
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true

Kênh phục hồi nhận cả payload firing lẫn resolved rồi vứt bỏ phần firing. Kết quả: lúc dịch vụ chết thì chuông reo, còn lúc phục hồi thì đến dưới dạng một thông báo đẩy bạn đọc vào buổi sáng.

Bước 5 — Định tuyến theo mức nghiêm trọng, đừng gửi tất tần tật

Một route bắt hết mọi cảnh báo rồi đẩy sang kênh cuộc gọi chính là cỗ máy sản xuất ra những cuộc gọi bị phớt lờ. Hãy tách theo mức nghiêm trọng ngay trong Alertmanager, nơi cây định tuyến vốn thuộc về:

route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-warning

  routes:
    # Watchdog không bao giờ được chạm tới con người. Xem Bước 6.
    - matchers:
        - alertname = "Watchdog"
      receiver: "null"

    - matchers:
        - severity = "critical"
      receiver: echobell-critical
      group_wait: 10s
      repeat_interval: 1h

receivers:
  - name: "null"

  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false

  - name: echobell-warning
    webhook_configs:
      - url: "https://hook.echobell.one/t/<normal-channel-token>"
        send_resolved: true

Các route được duyệt từ trên xuống dưới và khớp đầu tiên là thắng — mặc định continue là false. Nên thứ tự rất quan trọng: route Watchdog phải nằm trên bất cứ route nào có thể nuốt mất nó.

Nếu bạn muốn giữ một kênh duy nhất và lọc ở phía Echobell, điều kiện tương đương là:

status == "firing" && commonLabels.severity == "critical"

Làm trong Alertmanager thường tốt hơn, vì khi đó severity cũng chi phối luôn group_wait và repeat_interval. Làm trong Echobell thì tốt hơn khi bạn không thể merge một thay đổi cấu hình ngay hôm nay.

Bước 6 — Cái bẫy mang tên Watchdog

Nếu bạn chạy kube-prometheus-stack, bạn sẽ có một cảnh báo tên Watchdog với biểu thức là vector(1). Nó được thiết kế để kích hoạt mãi mãi — nó tồn tại để một hệ thống bên ngoài có thể nhận ra khi chính Prometheus đã ngừng chạy. Cấu hình mặc định định tuyến nó tới một receiver null.

Nếu bạn trỏ một route bắt-tất-cả tới kênh cuộc gọi mà không loại nó ra, Watchdog sẽ gọi cho điện thoại bạn sau mỗi repeat_interval, mãi mãi, và bắt đầu ngay lập tức. Đây là lý do số một khiến người ta kết luận rằng cảnh báo bằng cuộc gọi "không hoạt động".

Hãy giữ lại route null từ Bước 5. Rồi, nếu muốn, hãy làm điều hữu ích với nó: biến Watchdog thành một dead man's switch thực thụ.

    - matchers:
        - alertname = "Watchdog"
      receiver: deadmansswitch
      group_wait: 0s
      group_interval: 1m
      repeat_interval: 50s

receivers:
  - name: deadmansswitch
    webhook_configs:
      - url: "https://hc-ping.com/<your-check-uuid>"
        send_resolved: false

Bản thân Echobell không thể làm dead man's switch — nó cảnh báo khi một request đến, chứ không phải khi request ngừng đến. Vậy nên hãy gửi ping Watchdog tới một dịch vụ sinh ra để phát hiện sự im lặng (Healthchecks.io, Cronitor, Dead Man's Snitch), rồi trỏ webhook "check đã chết" của dịch vụ đó tới kênh cuộc gọi Echobell của bạn. Giờ thì một cuộc gọi có nghĩa là "chính hệ giám sát đã chết", tức là cảnh báo mà bạn muốn được đánh thức vì nó nhất, và cũng là cảnh báo chẳng ai chịu cấu hình.

Tinh chỉnh để nó không hóa thành cậu bé chăn cừu

Ba thiết lập của Alertmanager làm gần hết việc, cộng thêm một thiết lập của Prometheus:

repeat_interval là thứ đáng suy nghĩ nhất. Bốn tiếng là quá dài để một thứ nằm hỏng đó; hai mươi phút lại là cỗ máy khiến bạn tắt luôn kênh. Một tiếng cho mức critical là điểm khởi đầu hợp lý.

Nếu bạn muốn một cuộc gọi không có người nghe được thử lại ngay thay vì chờ tới repeat_interval kế tiếp, hãy bật Gọi lại khi cuộc gọi thất bại trong phần cài đặt ứng dụng Echobell.

Chỉ đổ chuông ngoài giờ làm việc

Trong giờ làm, nhiều khả năng bạn đã đang nhìn vào một bảng điều khiển rồi. Các biến thời gian hệ thống của Echobell (đều theo UTC) cho phép một kênh hành xử khác nhau theo giờ, mà không cần thêm route thứ hai trong Alertmanager:

status == "firing" && (hour >= 17 || hour < 9)

Điều kiện đó chỉ gọi cho bạn ngoài khung 09:00–17:00 UTC. Hãy trỏ một kênh thứ hai loại Thông thường tới điều kiện ngược lại để nhận push trong ngày:

status == "firing" && hour >= 9 && hour < 17

Thêm dayOfWeek >= 1 && dayOfWeek <= 5 để coi cuối tuần cũng là ngoài giờ. Hãy nhớ những giá trị này luôn được tính theo UTC — bạn phải bù lệch múi giờ của mình. Có bài viết chi tiết hơn ở thông báo theo khung thời gian dùng điều kiện UTC.

Xử lý vấn đề commonLabels rỗng

Khi một nhóm chứa cảnh báo từ nhiều instance, commonLabels.instance biến mất và tiêu đề thông báo của bạn đọc thành 🔴 HighErrorRate on .

Có ba lối ra, xếp theo thứ tự ưu tiên:

1. Đưa nhãn đó vào group_by. Nếu group_by có instance, thì mọi cảnh báo trong một nhóm đều dùng chung nhãn đó và commonLabels.instance luôn tồn tại. Cái giá là nhiều thông báo hơn — một thông báo cho mỗi instance thay vì một thông báo cho mỗi tên cảnh báo.
2. Đọc cảnh báo đầu tiên thay thế. {{alerts[0].labels.instance}} luôn có giá trị. Nó chỉ là một trong nhiều cảnh báo có thể có, nên hãy ghép nó với một con số đếm: {{alerts[0].labels.instance}} (+{{alerts.length}} alerts).
3. Thiết kế nhãn sao cho rỗng vẫn đọc được. Echobell không có toán tử giá trị mặc định — {{a || "unknown"}} hiển thị đúng chữ true chứ không phải giá trị dự phòng — nên hãy viết Instance: {{commonLabels.instance}} trên một dòng riêng, nơi một giá trị trống rõ ràng là trống chứ không phải một câu bị hỏng.

Giữ cho payload nhỏ gọn

Một nhóm bao trùm một trăm pod sẽ tạo ra một body JSON rất lớn, và Echobell từ chối các body kích hoạt lớn hơn 1 MiB với mã HTTP 413. Hãy giới hạn nó trong Alertmanager:

      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
        max_alerts: 20

Alertmanager khi đó gửi tối đa hai mươi cảnh báo và đặt truncatedAlerts bằng số cảnh báo nó đã bỏ đi, và bạn có thể đưa con số đó ra phần nội dung:

Body: {{commonAnnotations.summary}}
Alerts: {{alerts.length}} (+{{truncatedAlerts}} truncated)

Chia sẻ cảnh báo với cả nhóm

Một kênh Echobell có thể được chia sẻ qua liên kết đăng ký, và mỗi người đăng ký tự chọn loại thông báo của mình. Nhờ vậy cùng một route có thể đổ chuông cho kỹ sư đang trực trong khi chỉ đến như một thông báo đẩy thông thường với mọi người khác — không tính tiền theo đầu người, và không cần thêm quy tắc định tuyến nào trong Alertmanager.

Điều đó cũng khớp với lý do khiến nhiều nhóm tự vận hành Prometheus ngay từ đầu: số liệu và quy tắc cảnh báo của bạn ở lại trên hạ tầng của bạn, còn Echobell giữ nội dung và lịch sử thông báo trên thiết bị thay vì trên máy chủ của họ.

Những gì thiết lập này không mang lại cho bạn

Thành thật về ranh giới sẽ giúp bạn tránh một cuộc chuyển đổi tồi về sau. Echobell là một lớp phân phối, không phải nền tảng quản lý sự cố. Nó không có:

• Lịch trực xoay ca hay bàn giao theo múi giờ
• Cây leo thang gọi người thứ hai khi người đầu không nghe máy
• Dòng thời gian sự cố, theo dõi xác nhận tiếp nhận hay công cụ viết báo cáo hậu sự cố

Nếu nhóm bạn cần những thứ đó, bạn cần PagerDuty, Grafana Cloud IRM hoặc tương tự. Thứ mà bài này bao phủ là đúng khoảng trống mà Alertmanager để ngỏ: biến một cảnh báo đang kích hoạt thành một chiếc điện thoại thật sự đổ chuông. Với người vận hành đơn lẻ, nhóm nhỏ và homelab, thường thì đó chính là toàn bộ nhu cầu.

Xử lý sự cố

Không có gì đến cả. Hãy xem log của chính Alertmanager trước (level=error component=dispatcher), rồi xác nhận route thật sự dẫn tới receiver của bạn — amtool config routes test severity=critical alertname=HighErrorRate cho bạn biết một cảnh báo sẽ rơi vào receiver nào mà không phải chờ nó kích hoạt thật.

Echobell trả về HTTP 404. Token của kênh sai hoặc kênh đã bị xóa. Một token không tồn tại trả về 404, chứ không phải âm thầm thành công.

Echobell trả về 200 kèm "notificationTriggered": false. Điều kiện của bạn được tính ra là sai. Phần body phản hồi cũng mang theo "conditionsMet": false, đây là cách nhanh nhất để phân biệt "điều kiện của tôi sai" với "webhook của tôi chưa từng tới nơi". Hãy đối chiếu status == "firing" với đúng thứ Alertmanager đã gửi — trường status ở cấp cao nhất, chứ không phải alerts[0].status.

HTTP 413. Payload vượt quá 1 MiB. Hãy đặt max_alerts như ở trên.

HTTP 405. Kênh đang bật POST Only và có thứ gì đó gửi GET. Alertmanager luôn dùng POST, nên lỗi này thường có nghĩa là bạn đã thử URL đó trong trình duyệt.

Tiêu đề có một khoảng trống. commonLabels không chứa nhãn đó cho nhóm này. Xem lại phần ở trên.

Không có chuông nào reo, nhưng thông báo vẫn đến. Loại thông báo của đăng ký đang là Thông thường hoặc Khẩn cấp, chứ không phải Cuộc gọi. Loại thông báo do từng người đăng ký tự chọn, nên hãy kiểm tra trên đúng chiếc máy không reo.

Kiểm thử mà không làm hỏng production. Hãy thêm một quy tắc với expr: vector(1), một alertname riêng biệt và severity: critical, để nó kích hoạt một lần rồi xóa đi. Hoặc bắn một cảnh báo bằng tay:

curl -X POST http://localhost:9093/api/v2/alerts -H 'Content-Type: application/json' -d '[
  {"labels":{"alertname":"EchobellTest","severity":"critical"},
   "annotations":{"summary":"Testing the phone call path"}}
]'

Câu hỏi thường gặp

Prometheus Alertmanager có tự gọi điện được không?

Không. Alertmanager có receiver cho email, Slack, PagerDuty, OpsGenie và nhiều thứ khác, nhưng không có receiver gọi thoại hay SMS. Muốn có cuộc gọi thì phải đưa receiver webhook dạng chung tới một dịch vụ gọi được, chẳng hạn Echobell, hoặc trả tiền cho một nền tảng quản lý sự cố.

Cuộc gọi có vượt qua chế độ Không làm phiền không?

Có. Loại thông báo Cuộc gọi của Echobell hiện lên như một cuộc gọi đến, nên nó đổ chuông xuyên qua chế độ Tập trung và Không làm phiền của iOS. Xem cách vượt qua chế độ Tập trung của iOS cho cảnh báo nguy cấp để biết chi tiết và các cài đặt liên quan.

Cách này có dùng được với Alertmanager sau tường lửa hoặc bên trong Kubernetes không?

Có. Webhook là một HTTPS request đi ra từ Alertmanager, nên nó chỉ cần tới được hook.echobell.one. Alertmanager của bạn không cần địa chỉ công khai hay một ingress nào.

Làm sao để không bị gọi khi một cảnh báo được giải quyết?

Hãy đặt send_resolved: false trên cấu hình webhook trỏ tới kênh cuộc gọi của bạn. Receiver webhook mặc định là true, khác với hầu hết receiver khác của Alertmanager, nên đây là chuyện phải chủ động tắt chứ không phải chủ động bật. Nếu vẫn muốn nhận thông báo phục hồi một cách yên tĩnh, hãy thêm một kênh thứ hai với điều kiện status == "resolved".

Vì sao điện thoại tôi reo bốn tiếng một lần cho cùng một cảnh báo?

Đó là repeat_interval, mặc định là 4h. Alertmanager báo lại về một cảnh báo vẫn đang kích hoạt theo nhịp đó. Hãy đặt nó theo từng route — 1h cho mức critical là lựa chọn phổ biến. Nếu các cuộc gọi bắt đầu ngay sau khi bạn thêm một route bắt-tất-cả, thì thủ phạm nhiều khả năng là cảnh báo Watchdog luôn kích hoạt; xem Bước 6.

Nhiều người có thể cùng được gọi cho một cảnh báo không?

Có. Hãy chia sẻ kênh với đồng đội và mỗi người đăng ký tự chọn loại thông báo của mình. Mọi người đăng ký kênh cuộc gọi đều được gọi, mà không tốn phí theo đầu người.

Nên lọc mức nghiêm trọng trong Alertmanager hay trong điều kiện của Echobell?

Hãy ưu tiên Alertmanager: định tuyến ở đó còn cho phép bạn đặt group_wait và repeat_interval theo từng mức nghiêm trọng, và cây định tuyến vẫn nằm trong hệ quản lý phiên bản cùng phần cấu hình còn lại. Hãy dùng điều kiện của Echobell khi bạn không thể sửa cấu hình Alertmanager, hoặc cho những bộ lọc mà Alertmanager không có khái niệm — chẳng hạn lọc theo giờ trong ngày.

Tổng kết

Toàn bộ thiết lập chỉ gồm một receiver, một dòng send_resolved: false, và một cây định tuyến giữ mọi thứ ngoài severity: critical tránh xa kênh cuộc gọi. Nó không đụng gì tới quy tắc cảnh báo, cách gom nhóm, các lệnh tắt tiếng và cơ chế ức chế của bạn, đồng thời khép lại khoảng cách giữa "Prometheus đã nhận ra" và "một con người đã nhận ra".

Tải Echobell cho iPhone hoặc tải trên Google Play, rồi hãy bắn thử cảnh báo EchobellTest ở trên trước khi bạn thật sự trông cậy vào đường đi này cho bất cứ việc gì nghiêm túc.

---

Liên quan

• Tài liệu tích hợp Prometheus
• Tài liệu tham khảo về điều kiện của kênh
• Thông báo bằng cuộc gọi cho Grafana
• Cảnh báo bằng cuộc gọi với Uptime Kuma
• Hướng dẫn cho lập trình viên về cách chữa chứng mệt mỏi vì cảnh báo