[Prometheus – Alerting] – Phần 3: Giới thiệu về phần cấu hình Alertmanager

1. Tổng quan.

Alertmanager được cấu hình thông qua command-line flags và một file cấu hình. Trong đó, các tùy chọn thiết lập các tham số hệ thống không thay đổi được, trong khi file cấu hình xác định các rules kiểm soát, định tuyến thông báo và các thiết bị nhận thông báo.

Để xem tất cả các tùy chọn có sẵn, hãy chạy lệnh alertmanager -h. Alertmanager có khả năng reload lại cấu hình của nó trong quá trình chạy. Nếu cấu hình mới không đúng cú pháp, các thay đổi sẽ không được áp dụng và sẽ được ghi logs lỗi. Việc reload cấu hình được kích hoạt bằng cách gửi một tín hiệu SIGHUP đến tiến trình hoặc gửi một yêu cầu HTTP POST đến địa chỉ /-/reload.

2. Giới thiệu file cấu hình.

Để xác định file cấu hình nào sẽ được tải, sử dụng tùy chọn --config.file. Dưới đây là một ví dụ về cách sử dụng tùy chọn --config.file để chỉ định file cấu hình:

./alertmanager --config.file=alertmanager.yml

• Định dạng YAML: File cấu hình được viết theo định dạng YAML. Dấu ngoặc vuông ([]) chỉ ra rằng một tham số là tùy chọn. Đối với các tham số không phải danh sách, giá trị được đặt thành giá trị mặc định đã xác định.
• Placeholder: Placeholder trong Alertmanager là một cơ chế cho phép bạn thay thế các giá trị động vào thông báo hoặc các phần khác trong cấu hình của bạn. Điều này giúp bạn tạo ra các thông báo linh hoạt dựa trên thông tin từ cảnh báo cụ thể hoặc các nguồn dữ liệu khác. Placeholder thường được sử dụng trong các thông báo email, webhook hoặc các mô tả cấu hình khác.
  • <duration>: Một khoảng thời gian phù hợp với biểu thức chính quy (regular expression), ví dụ: 1d (1 ngày), 1h30m (1 giờ 30 phút), 5m (5 phút), 10s (10 giây).
  • <labelname>: Một chuỗi phù hợp với biểu thức chính quy, ví dụ: [a-zA-Z_][a-zA-Z0-9_]*.
  • <labelvalue>: Một chuỗi ký tự unicode.
  • <filepath>: Một đường dẫn hợp lệ trong thư mục làm việc hiện tại.
  • <boolean>: Một giá trị boolean có thể nhận giá trị true hoặc false.
  • <string>: Một chuỗi bình thường.
  • <secret>: Một chuỗi bình thường là secret hoặc mật khẩu.
  • <tmpl_string>: Một chuỗi sẽ được mở rộng theo template trước khi sử dụng.
  • <tmpl_secret>: Một chuỗi sẽ được mở rộng theo template và là secret.
  • <int>: Một giá trị số nguyên.
  • <regex>: Bất kỳ biểu thức chính quy RE2 hợp lệ nào (Biểu thức chính quy này được neo ở cả hai đầu. Để bỏ neo biểu thức chính quy, hãy sử dụng .<regex>..)

Một số ví dụ về placeholder phổ biến trong Alertmanager như sau:

• {{ .CommonLabels.label_name }}: Đây là một placeholder cho các nhãn (labels) trong cảnh báo. Bạn có thể thay thế “label_name” bằng tên của nhãn bạn muốn sử dụng. Ví dụ: {{ .CommonLabels.alertname }} sẽ thay thế bằng giá trị của nhãn “alertname” trong cảnh báo.
• {{ .CommonAnnotations.annotation_name }}: Tương tự như CommonLabels, bạn có thể sử dụng CommonAnnotations để truy cập các chú thích (annotations) trong cảnh báo. Ví dụ: {{ .CommonAnnotations.summary }} sẽ thay thế bằng giá trị của chú thích “summary” trong cảnh báo.
• {{ .Receiver }}: Placeholder này thay thế bằng tên của người nhận (receiver) mà thông báo đang gửi đến.
• {{ .GroupLabels.label_name }}: Placeholder này cho phép bạn truy cập các nhãn trong nhóm cảnh báo (group). Điều này hữu ích khi bạn muốn hiển thị thông tin từ nhóm cảnh báo, ví dụ: {{ .GroupLabels.alertname }}.
• {{ .GroupKey }}: Placeholder này thay thế bằng giá trị của khóa nhóm (group key) trong trường hợp bạn muốn hiển thị thông tin về nhóm cảnh báo.

Sử dụng placeholder giúp bạn tạo ra các thông báo tự động và linh hoạt hơn, bởi vì các giá trị trong thông báo có thể thay đổi tùy thuộc vào cảnh báo cụ thể. Placeholder thường được sử dụng trong các mẫu thông báo (notification templates) để tạo ra các thông báo được định dạng đúng cách và chứa thông tin quan trọng về cảnh báo.

3. Bố cục và thiết lập global.

Phần này sẽ tìm hiểu cách cấu hình hệ thống hoặc ứng dụng được tổ chức và cách các giá trị Global Settings có thể ảnh hưởng đến các phần cấu hình khác trong hệ thống.

• Bố cục file (File Layout): Đề cập đến cách các file cấu hình được tổ chức và sắp xếp trong hệ thống. Một cách tổng quan về cách các file liên quan đến cấu hình được đặt và tổ chức trong hệ thống.
• Các cài đặt toàn cục (Global Settings): Global Settings định rõ các tham số mà có hiệu lực trong tất cả các phần khác của cấu hình. Các giá trị trong Global Settings này cũng là giá trị mặc định mà các phần cấu hình khác có thể sử dụng. Ví dụ, nếu bạn đặt một giá trị mặc định cho ngôn ngữ hoặc múi giờ, thì giá trị đó sẽ tự động áp dụng cho tất cả các phần cấu hình khác trong hệ thống.
• Các phần cấu hình nâng cao khác (Other Top-Level Sections): Đề cập đến các phần cấu hình nâng cao khác, tức là các phần cấu hình chứa các thiết lập cụ thể cho các khía cạnh riêng của hệ thống hoặc ứng dụng. Các cài đặt trong các phần này có thể ghi đè lên các giá trị mặc định từ cấu đặt toàn cục, ví dụ như dưới:

global:
  # The default SMTP From header field.
  [ smtp_from: <tmpl_string> ]
  # The default SMTP smarthost used for sending emails, including port number.
  # Port number usually is 25, or 587 for SMTP over TLS (sometimes referred to as STARTTLS).
  # Example: smtp.example.org:587
  [ smtp_smarthost: <string> ]
  # The default hostname to identify to the SMTP server.
  [ smtp_hello: <string> | default = "localhost" ]
  # SMTP Auth using CRAM-MD5, LOGIN and PLAIN. If empty, Alertmanager doesn't authenticate to the SMTP server.
  [ smtp_auth_username: <string> ]
  # SMTP Auth using LOGIN and PLAIN.
  [ smtp_auth_password: <secret> ]
  # SMTP Auth using LOGIN and PLAIN.
  [ smtp_auth_password_file: <string> ]
  # SMTP Auth using PLAIN.
  [ smtp_auth_identity: <string> ]
  # SMTP Auth using CRAM-MD5.
  [ smtp_auth_secret: <secret> ]
  # The default SMTP TLS requirement.
  # Note that Go does not support unencrypted connections to remote SMTP endpoints.
  [ smtp_require_tls: <bool> | default = true ]

  # The API URL to use for Slack notifications.
  [ slack_api_url: <secret> ]
  [ slack_api_url_file: <filepath> ]
  [ victorops_api_key: <secret> ]
  [ victorops_api_key_file: <filepath> ]
  [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
  [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
  [ opsgenie_api_key: <secret> ]
  [ opsgenie_api_key_file: <filepath> ]
  [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
  [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
  [ wechat_api_secret: <secret> ]
  [ wechat_api_corp_id: <string> ]
  [ telegram_api_url: <string> | default = "https://api.telegram.org" ]
  [ webex_api_url: <string> | default = "https://webexapis.com/v1/messages" ]
  # The default HTTP client configuration
  [ http_config: <http_config> ]

  # ResolveTimeout is the default value used by alertmanager if the alert does
  # not include EndsAt, after this time passes it can declare the alert as resolved if it has not been updated.
  # This has no impact on alerts from Prometheus, as they always include EndsAt.
  [ resolve_timeout: <duration> | default = 5m ]

# Files from which custom notification template definitions are read.
# The last component may use a wildcard matcher, e.g. 'templates/*.tmpl'.
templates:
  [ - <filepath> ... ]

# The root node of the routing tree.
route: <route>

# A list of notification receivers.
receivers:
  - <receiver> ...

# A list of inhibition rules.
inhibit_rules:
  [ - <inhibit_rule> ... ]

# DEPRECATED: use time_intervals below.
# A list of mute time intervals for muting routes.
mute_time_intervals:
  [ - <mute_time_interval> ... ]

# A list of time intervals for muting/activating routes.
time_intervals:
  [ - <time_interval> ... ]

4. Cài đặt liên quan đến định tuyến (Route).

Định tuyến (Route).

Các cài đặt liên quan đến định tuyến cho phép bạn cấu hình cách thông báo được định tuyến, tổng hợp, giới hạn và tắt dựa trên thời gian.

Một khối route định nghĩa một nút trong routing tree và các nút con của nó. Các tham số cấu hình tùy chọn của nó được kế thừa từ nút cha nếu không được thiết lập.

Mỗi thông báo đi vào routing tree tại route cấp cao được cấu hình, route này phải phù hợp với tất cả các thông báo (tức là không có bất kỳ điều kiện so khớp cấu hình nào). Sau đó, nó di chuyển qua các nút con. Nếu continue được thiết lập thành false, nó sẽ dừng lại sau khi tìm thấy nút con đầu tiên phù hợp. Nếu continue được thiết lập thành true trên một nút phù hợp, thông báo sẽ tiếp tục so khớp với các nút con sau này. Nếu một thông báo không phù hợp với bất kỳ nút con nào của một nút (không có nút con nào phù hợp hoặc không có nút con nào tồn tại), thông báo sẽ được xử lý dựa trên các tham số cấu hình của nút hiện tại.

[ receiver: <string> ]
# The labels by which incoming alerts are grouped together. For example,
# multiple alerts coming in for cluster=A and alertname=LatencyHigh would
# be batched into a single group.
#
# To aggregate by all possible labels use the special value '...' as the sole label name, for example:
# group_by: ['...']
# This effectively disables aggregation entirely, passing through all
# alerts as-is. This is unlikely to be what you want, unless you have
# a very low alert volume or your upstream notification system performs
# its own grouping.
[ group_by: '[' <labelname>, ... ']' ]

# Whether an alert should continue matching subsequent sibling nodes.
[ continue: <boolean> | default = false ]

# DEPRECATED: Use matchers below.
# A set of equality matchers an alert has to fulfill to match the node.
match:
  [ <labelname>: <labelvalue>, ... ]

# DEPRECATED: Use matchers below.
# A set of regex-matchers an alert has to fulfill to match the node.
match_re:
  [ <labelname>: <regex>, ... ]

# A list of matchers that an alert has to fulfill to match the node.
matchers:
  [ - <matcher> ... ]

# How long to initially wait to send a notification for a group
# of alerts. Allows to wait for an inhibiting alert to arrive or collect
# more initial alerts for the same group. (Usually ~0s to few minutes.)
[ group_wait: <duration> | default = 30s ]

# How long to wait before sending a notification about new alerts that
# are added to a group of alerts for which an initial notification has
# already been sent. (Usually ~5m or more.)
[ group_interval: <duration> | default = 5m ]

# How long to wait before sending a notification again if it has already
# been sent successfully for an alert. (Usually ~3h or more).
# Note that this parameter is implicitly bound by Alertmanager's
# `--data.retention` configuration flag. Notifications will be resent after either
# repeat_interval or the data retention period have passed, whichever
# occurs first. `repeat_interval` should not be less than `group_interval`.
[ repeat_interval: <duration> | default = 4h ]

# Times when the route should be muted. These must match the name of a
# mute time interval defined in the mute_time_intervals section.
# Additionally, the root node cannot have any mute times.
# When a route is muted it will not send any notifications, but
# otherwise acts normally (including ending the route-matching process
# if the `continue` option is not set.)
mute_time_intervals:
  [ - <string> ...]

# Times when the route should be active. These must match the name of a
# time interval defined in the time_intervals section. An empty value
# means that the route is always active.
# Additionally, the root node cannot have any active times.
# The route will send notifications only when active, but otherwise
# acts normally (including ending the route-matching process
# if the `continue` option is not set).
active_time_intervals:
  [ - <string> ...]

# Zero or more child routes.
routes:
  [ - <route> ... ]

Routing tree trong hệ thống cảnh báo là một cấu trúc quyết định cách thông báo được xử lý dựa trên loại thông báo, điều kiện, và thời gian, giúp tự động hóa quá trình xử lý cảnh báo.

Dưới đây là một ví dụ cấu hình cơ bản về route trong Alertmanager:

route:
  # Nhóm các cảnh báo theo tên cảnh báo (alertname) và giờ bắt đầu để gửi cảnh báo.
  group_by: ['alertname']

  # Đặt thời gian chờ trước khi gửi cảnh báo sau khi nhận được cảnh báo đầu tiên trong nhóm.
  group_wait: 10s

  # Đặt khoảng thời gian giữa việc gửi các cảnh báo trong cùng một nhóm.
  group_interval: 10s

  # Đặt khoảng thời gian lặp lại việc gửi cảnh báo sau khi cảnh báo đã được giải quyết.
  repeat_interval: 1h

  # Người nhận mặc định cho các cảnh báo nếu không được xác định trong cấu hình cụ thể.
  receiver: 'default'

receivers:
  - name: 'default'
    email_configs:
      - to: 'your@email.com'
        send_resolved: true

Trong ví dụ này:

• route xác định cách các cảnh báo được nhóm lại và xử lý.
• group_by chỉ định rằng các cảnh báo sẽ được nhóm lại dựa trên tên cảnh báo (alertname).
• group_wait đặt thời gian chờ trước khi gửi cảnh báo sau khi nhận được cảnh báo đầu tiên trong nhóm (10 giây).
• group_interval đặt khoảng thời gian giữa việc gửi các cảnh báo trong cùng một nhóm (10 giây).
• repeat_interval đặt khoảng thời gian lặp lại việc gửi cảnh báo sau khi cảnh báo đã được giải quyết (1 giờ).
• receiver là người nhận mặc định cho các cảnh báo nếu không được xác định trong cấu hình cụ thể.
• receivers liệt kê các người nhận và cấu hình gửi cảnh báo qua email cho người nhận mặc định (default).

Thời gian thực thi lại (time_interval).

Nó thường được sử dụng để xác định các khoảng thời gian cụ thể khi một route hoặc rule cảnh báo nên được kích hoạt hoặc tắt. Điều này có thể giúp tự động hóa quá trình quản lý cảnh báo dựa trên thời gian.

Một<time_interval> giúp bạn quản lý và áp dụng các khoảng thời gian cụ thể trong quá trình định tuyến thông báo, cho phép bạn tắt hoặc kích hoạt các route theo thời gian một cách tự động và linh hoạt.

Nó được sử dụng để xác định một khoảng thời gian cụ thể, và bạn có thể gán một tên cho khoảng thời gian này để sử dụng nó trong routing tree của bạn.

Ví dụ, bạn có thể tạo một <time_interval> với tên “Giờ làm việc” để đại diện cho khoảng thời gian từ 8 giờ sáng đến 5 giờ chiều hàng ngày. Khi bạn đã xác định khoảng thời gian này, bạn có thể áp dụng nó trong routing tree của bạn để quyết định khi nào một route cụ thể sẽ bị tắt hoặc hoạt động dựa trên thời gian.

Cấu trúc.

name: <string>
time_intervals:
  [ - <time_interval_spec> ... ]

• Trong đó:
  • <string>: Tên định danh cho khoảng thời gian.
  • <time_interval_spec>: Định nghĩa khoảng thời gian.

Như vậy time_interval là một cấu hình chung để xác định một khoảng thời gian cụ thể mà bạn muốn sử dụng trong cấu hình của hệ thống cảnh báo. Nó có thể áp dụng cho việc kích hoạt hoặc tắt các route hoặc rule cảnh báo trong hệ thống của bạn. time_interval không phải là một khoảng thời gian cụ thể mà nó là một tên gọi cho một khoảng thời gian đã được xác định bằng time_interval_spec.

Dưới đây là một ví dụ cấu hình time_interval trong Alertmanager:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình time_interval tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa khoảng thời gian có tên là "work_hours".
  routes:
    - match:
        alertname: ExampleAlert
      time_interval: "work_hours"

time_intervals:
  - name: "work_hours"
    start_time: "08:00"
    end_time: "17:00"

Trong ví dụ này:

• Trong phần route, bạn xác định một time_interval có tên là “work_hours” cho cảnh báo với tên là “ExampleAlert”.
• Sau đó, bạn định nghĩa time_intervals bên ngoài phần route. Khoảng thời gian “work_hours” bắt đầu từ 08:00 và kết thúc vào 17:00.
• Khi một cảnh báo với tên “ExampleAlert” xuất hiện, nó sẽ được áp dụng theo cấu hình time_interval “work_hours”. Cảnh báo này chỉ được xem xét và gửi trong khoảng thời gian từ 08:00 đến 17:00.

4. Xác định một khoảng thời gian cụ thể (time_interval_spec).

Time_interval_spec chứa thông tin về khoảng thời gian cụ thể, bao gồm năm, tháng, ngày, giờ, phút và giây, để xác định khi nào một khoảng thời gian bắt đầu và kết thúc. Khi bạn xác định một time_interval_spec, bạn đang mô tả một khoảng thời gian cụ thể và sử dụng nó trong cấu hình của hệ thống cảnh báo để quyết định các hoạt động như kích hoạt hoặc tắt route cảnh báo.

<time_interval_spec> là một cấu trúc hoặc một tập hợp các thông tin để mô tả khoảng thời gian. Cú pháp (syntax) cho <time_interval_spec> hỗ trợ các trường (fields) sau đây, có thể là các thông tin hoặc các giá trị để xác định khoảng thời gian:

• times: Thời gian.
• weekdays: Các ngày trong tuần.
• days_of_month: Ngày trong tháng.
• months: Tháng trong năm.
• years: Năm.
• location: Vị trí thời gian.

Khi bạn sử dụng các trường này trong cú pháp <time_interval_spec>, bạn có thể xác định một khoảng thời gian cụ thể bằng cách chỉ định các giá trị cho các trường này. Ví dụ, bạn có thể định nghĩa một khoảng thời gian từ ngày 1 tháng 1 năm 2023 lúc 8 giờ sáng và 30 phút.

Cú pháp này giúp bạn mô tả và xác định khi nào khoảng thời gian cụ thể bắt đầu và kết thúc trong ngữ cảnh của hệ thống cảnh báo hoặc ứng dụng khác.

Cấu trúc.

times:
[ - <time_range> ...]
weekdays:
[ - <weekday_range> ...]
days_of_month:
[ - <days_of_month_range> ...]
months:
[ - <month_range> ...]
years:
[ - <year_range> ...]
location: <string>

• Trong đó:
  • times: Thời gian.
  • weekdays: Ngày trong tuần.
  • days_of_month: Ngày trong tháng.
  • months: Tháng trong năm.
  • years: Năm.
  • location: Vị trí thời gian.

Dưới đây là một ví dụ cấu hình time_interval_spec trong Alertmanager:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình time_interval_spec tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa khoảng thời gian có tên là "work_hours".
  routes:
    - match:
        alertname: ExampleAlert
      time_interval_spec:
        start: "08:00"
        end: "17:00"

Trong ví dụ này:

• Trong phần route, bạn xác định một time_interval_spec có tên là “work_hours” cho cảnh báo với tên là “ExampleAlert”.
• Bên trong time_interval_spec, bạn xác định thời gian bắt đầu và kết thúc cụ thể cho khoảng thời gian. Trong trường hợp này, cảnh báo sẽ chỉ được xem xét và gửi trong khoảng thời gian từ 08:00 đến 17:00.

5. Khoảng thời gian (time_range).

Thời gian bắt đầu và kết thúc: “time_range” (khoảng thời gian) xác định một đoạn thời gian cụ thể, và nó bao gồm thời gian bắt đầu và thời gian kết thúc.

Không bao gồm thời gian kết thúc: Điều quan trọng để lưu ý ở đây là thời gian kết thúc không được tính vào khoảng thời gian. Nói cách khác, thời gian kết thúc chỉ định thời điểm trước khi khoảng thời gian kết thúc.

Dễ dàng đại diện cho thời gian bắt đầu/kết thúc vào giờ đồng hồ: Mục đích của việc không tính thời gian kết thúc là để làm cho việc đại diện cho khoảng thời gian trở nên dễ dàng hơn, đặc biệt là khi bạn muốn xác định các thời điểm bắt đầu và kết thúc bằng giờ đồng hồ.

Ví dụ: Nếu bạn đặt “time_range” từ 8:00 sáng đến 10:00 sáng, thì khoảng thời gian sẽ bắt đầu vào 8:00 sáng và kết thúc trước 10:00 sáng, không tính cả thời điểm 10:00 sáng. Điều này giúp bạn đại diện cho khoảng thời gian sáng sớm đến trước giữa trưa một cách dễ dàng.

Cấu trúc.

times:
- start_time: HH:MM
  end_time: HH:MM

• Ví dụ: start_time: '17:00' và end_time: '24:00' bắt đầu vào 17:00 và kết thúc ngay trước 24:00.

Cấu hình time_range trong Alertmanager là để xác định thời gian bắt đầu và kết thúc của một khoảng thời gian cụ thể. Dưới đây là một ví dụ:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình time_range tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa time_range có tên là "work_hours".
  routes:
    - match:
        alertname: ExampleAlert
      time_range:
        start: "2023-10-07T08:00:00Z"
        end: "2023-10-07T17:00:00Z"

Trong ví dụ này:

• Trong phần route, bạn xác định một time_range có tên là “work_hours” cho cảnh báo với tên là “ExampleAlert”.
• Bên trong time_range, bạn xác định thời gian bắt đầu và kết thúc cụ thể cho khoảng thời gian. Trong trường hợp này, cảnh báo sẽ chỉ được xem xét và gửi trong khoảng thời gian từ 08:00:00 (UTC) đến 17:00:00 (UTC) vào ngày 7 tháng 10 năm 2023.

Vui lòng đảm bảo sử dụng định dạng thời gian UTC ("T08:00:00Z" và "T17:00:00Z") hoặc đổi định dạng theo múi giờ của bạn.

6. Weekday_range (Khoảng thời gian trong tuần).

Weekday_range là một danh sách các ngày trong tuần, trong đó tuần bắt đầu từ Chủ Nhật và kết thúc vào thứ Bảy. Các ngày được chỉ định bằng tên (ví dụ: ‘Sunday’). Cũng có thể chấp nhận các khoảng thời gian dạng <start_day>:<end_day> và bao gồm cả hai đầu.
Ví dụ: [‘monday:wednesday’,’saturday’, ‘sunday’].

Dưới đây là một ví dụ về cách cấu hình weekday_range:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình weekday_range tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa weekday_range có tên là "working_days".
  routes:
    - match:
        alertname: ExampleAlert
      weekday_range:
        days:
          - 1  # Thứ hai (0 là Chủ nhật, 1 là thứ hai)
          - 2  # Thứ ba
          - 3  # Thứ tư
          - 4  # Thứ năm
          - 5  # Thứ sáu
          - 6  # Thứ bảy

Trong ví dụ này:

• Trong phần route, bạn xác định một weekday_range có tên là “working_days” cho cảnh báo với tên là “ExampleAlert”.
• Bên trong weekday_range, bạn sử dụng danh sách days để xác định các ngày trong tuần bạn muốn áp dụng. Trong trường hợp này, chỉ những cảnh báo trong ngày thứ hai đến thứ bảy sẽ được xem xét.

Điều này có nghĩa rằng cảnh báo “ExampleAlert” sẽ chỉ được xem xét và gửi vào các ngày trong tuần từ thứ hai đến thứ bảy.

7. Days_of_month_range (Khoảng thời gian trong tháng).
Trong Alertmanager, days_of_month_range cho phép bạn xác định một khoảng thời gian dựa trên ngày của tháng (từ 1 đến 31).

Days_of_month_range là danh sách các ngày số trong tháng. Ngày bắt đầu từ 1. Cũng chấp nhận các giá trị âm, bắt đầu từ cuối tháng, ví dụ: -1 trong tháng 1 sẽ đại diện cho ngày 31 của tháng 1. Ví dụ: [‘1:5’, ‘-3:-1’]. Khi vượt qua mốc đầu hoặc cuối tháng, nó sẽ được cắt. Ví dụ: chỉ định [‘1:31’] trong tháng 2 sẽ được cắt thành 28 hoặc 29 tùy theo năm nhuận.

Dưới đây là một ví dụ về cách cấu hình days_of_month_range:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình days_of_month_range tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa days_of_month_range có tên là "end_of_month".
  routes:
    - match:
        alertname: MonthlyReport
      days_of_month_range:
        days:
          - 28
          - 29
          - 30
          - 31

Trong ví dụ này:

• Trong phần route, bạn xác định một days_of_month_range có tên là “end_of_month” cho cảnh báo với tên là “MonthlyReport”.
• Bên trong days_of_month_range, bạn sử dụng danh sách days để xác định các ngày trong tháng bạn muốn áp dụng. Trong trường hợp này, chỉ những cảnh báo trong các ngày cuối tháng (28, 29, 30, và 31) sẽ được xem xét.

Điều này có nghĩa rằng cảnh báo “MonthlyReport” sẽ chỉ được xem xét và gửi vào các ngày cuối tháng.

8. Month_range (Khoảng thời gian trong năm).

Trong Alertmanager, month_range cho phép bạn xác định một khoảng thời gian dựa trên tháng trong năm. Month_range là danh sách các tháng trong năm được xác định bằng tên không phân biệt hoa thường (ví dụ: ‘January’) hoặc theo số, với tháng 1 là tháng Một.

Month_range cũng chấp nhận các khoảng thời gian, ví dụ [‘1:3’, ‘may:august’, ‘december’].

Dưới đây là một ví dụ về cách cấu hình month_range:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình month_range tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa month_range có tên là "quarterly".
  routes:
    - match:
        alertname: QuarterlyReport
      month_range:
        months:
          - 1
          - 4
          - 7
          - 10

Trong ví dụ này:

• Trong phần route, bạn xác định một month_range có tên là “quarterly” cho cảnh báo với tên là “QuarterlyReport”.
• Bên trong month_range, bạn sử dụng danh sách months để xác định các tháng trong năm bạn muốn áp dụng. Trong trường hợp này, chỉ những cảnh báo trong các tháng 1, 4, 7 và 10 sẽ được xem xét.

Điều này có nghĩa rằng cảnh báo “QuarterlyReport” sẽ chỉ được xem xét và gửi vào các tháng đã được xác định trong danh sách.

9. Year_range (Khoảng thời gian trong năm).

Trong Alertmanager, year_range cho phép bạn xác định một khoảng thời gian dựa trên năm. Year_range là danh sách các năm dưới dạng số và nó cũng chấp nhận các khoảng thời gian, ví dụ [‘2020:2022’, ‘2030’].

Dưới đây là một ví dụ về cách cấu hình year_range:

route:
  # ... (các cài đặt khác của route)

  # Áp dụng cấu hình year_range tại đây.
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'default'
  
  # Định nghĩa year_range có tên là "annual".
  routes:
    - match:
        alertname: AnnualReport
      year_range:
        years:
          - 2022
          - 2023

Trong ví dụ này:

• Trong phần route, bạn xác định một year_range có tên là “annual” cho cảnh báo với tên là “AnnualReport”.
• Bên trong year_range, bạn sử dụng danh sách years để xác định các năm bạn muốn áp dụng. Trong trường hợp này, chỉ những cảnh báo trong các năm 2022 và 2023 sẽ được xem xét.

Điều này có nghĩa rằng cảnh báo “AnnualReport” sẽ chỉ được xem xét và gửi trong các năm đã được xác định trong danh sách.

9. Location (Vị trí thời gian).

Trong Alertmanager, bạn có thể sử dụng địa điểm để xác định múi giờ cho các khoảng thời gian (time intervals) trong cấu hình của mình. Điều này giúp bạn xác định thời gian cụ thể dựa trên múi giờ của địa điểm đó.

Dưới đây là một số ví dụ và giải thích về cách cấu hình địa điểm trong Alertmanager:

Sử dụng địa điểm cụ thể: Bạn có thể chỉ định một địa điểm cụ thể trong cấu hình, ví dụ: ‘Australia/Sydney’. Khi bạn sử dụng địa điểm này cho một khoảng thời gian, Alertmanager sẽ sử dụng múi giờ tương ứng với địa điểm đó.

time_interval:
  start_time: 09:00
  end_time: 17:00
  location: 'Australia/Sydney'

Trong ví dụ này, khoảng thời gian từ 9:00 sáng đến 5:00 chiều sẽ được xác định bằng múi giờ của Sydney, Australia.

Sử dụng ‘Local’: Nếu bạn sử dụng ‘Local’ là địa điểm, Alertmanager sẽ sử dụng múi giờ của máy chủ hoặc máy tính mà nó đang chạy.

time_interval:
  start_time: 09:00
  end_time: 17:00
  location: 'Local'

Trong trường hợp này, múi giờ sẽ là múi giờ của máy chủ hoặc máy tính.

Sử dụng ‘UTC’: Nếu bạn sử dụng ‘UTC’ là địa điểm, khoảng thời gian sẽ sử dụng múi giờ UTC (Coordinated Universal Time).

time_interval:
  start_time: 09:00
  end_time: 17:00
  location: 'UTC'

Khoảng thời gian này sẽ dựa trên múi giờ UTC.

Lưu ý rằng nếu bạn không chỉ định địa điểm (location) nào trong cấu hình, Alertmanager sẽ mặc định sử dụng múi giờ UTC cho khoảng thời gian. Trong trường hợp bạn chạy Alertmanager trên Windows, chỉ 'Local' hoặc 'UTC' được hỗ trợ, trừ khi bạn cung cấp một cơ sở dữ liệu múi giờ tùy chỉnh bằng biến môi trường ZONEINFO.

10. Cài đặt liên quan đến Inhibition (Khả năng đình chỉ).

Inhibition cho phép bạn kiểm soát việc gửi cảnh báo và xác định sự phụ thuộc giữa các cảnh báo trong hệ thống cảnh báo của bạn. Nó giúp bạn tránh việc bị quá tải bởi các cảnh báo không cần thiết và chỉ nhận được thông báo quan trọng nhất trong trường hợp xảy ra sự cố.

Để hiểu rõ hơn về cách “inhibition” hoạt động trong hệ thống cảnh báo, hãy xem xét một ví dụ dưới đây:

Giả sử bạn có một hệ thống giám sát mạng và bạn đang theo dõi ba máy chủ: Server A, Server B và Server C. Bạn đã cấu hình hệ thống cảnh báo để gửi cảnh báo khi một trong các máy chủ này gặp sự cố hoặc có vấn đề.

• Server A là máy chủ quan trọng nhất trong hệ thống của bạn và nếu nó gặp sự cố, bạn muốn nhận được cảnh báo ngay lập tức.
• Server B là máy chủ quan trọng thứ hai, và nếu nó gặp sự cố, bạn muốn nhận cảnh báo sau một khoảng thời gian nhất định, để tránh việc nhận được nhiều cảnh báo liên quan đến Server B trong một khoảng thời gian ngắn.
• Server C là máy chủ ít quan trọng hơn, và nếu nó gặp sự cố, bạn muốn nhận cảnh báo sau một khoảng thời gian dài hơn so với Server B.

Để thực hiện điều này, bạn có thể sử dụng “inhibition.” Bạn cấu hình inhibition theo cách sau:

• Inhibition 1: Khi Server A gặp sự cố, inhibition sẽ tạm thời đình chỉ việc gửi cảnh báo cho Server B và Server C trong một khoảng thời gian ngắn để bạn có thể xử lý sự cố trên Server A mà không bị quấy rối bởi cảnh báo từ Server B và C.
• Inhibition 2: Khi Server B gặp sự cố, inhibition sẽ tạm thời đình chỉ việc gửi cảnh báo cho Server C trong một khoảng thời gian ngắn để bạn có thể xử lý sự cố trên Server B.

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default'

receivers:
  - name: 'default'
    email_configs:
      - to: 'your@email.com'
        send_resolved: true

inhibit_rules:
  - source_match:
      alertname: 'CriticalAlert'  # Đây là tên của cảnh báo quan trọng nhất.
      instance: 'Server A'       # Tên của Server A.
    target_match:
      alertname: 'WarningAlert'   # Đây là tên của cảnh báo có mức độ cảnh báo thấp hơn.
      instance: 'Server B'       # Tên của Server B.
    # Tạm thời đình chỉ cảnh báo "WarningAlert" trên Server B trong 10 phút sau khi xảy ra cảnh báo "CriticalAlert" trên Server A.
    equal: []

Trong cấu hình này:

• Chúng tôi đã thêm “instance” vào các quy tắc source_match và target_match để xác định các máy chủ cụ thể (Server A và Server B).
• Cảnh báo “CriticalAlert” trên Server A sẽ tạm thời đình chỉ cảnh báo “WarningAlert” trên Server B trong 10 phút sau khi xảy ra cảnh báo “CriticalAlert” trên Server A.

11. Inhibit rule (Luật đình chỉ).

Inhibit_rule là gì?.

Inhibit rule (luật đình chỉ) là một cách quản lý việc gửi cảnh báo trong hệ thống cảnh báo, giúp bạn đảm bảo rằng chỉ các cảnh báo quan trọng nhất được gửi trong trường hợp sự cố và tránh tình trạng đình chỉ tự động.

Một “inhibit_rule” là một quy tắc trong hệ thống cảnh báo, cho phép kiểm soát việc gửi cảnh báo dựa trên các điều kiện xác định.

Đối tượng của quy tắc.

• “inhibit_rule” kiểm tra hai loại cảnh báo: cảnh báo mục tiêu (target) và cảnh báo nguồn (source).
• Cả hai cảnh báo này phải có các nhãn (labels) giống nhau dựa trên danh sách các nhãn được xác định.

Tính năng quan trọng.

• “inhibit_rule” cho phép bạn kiểm soát việc gửi cảnh báo mục tiêu dựa trên sự xuất hiện của cảnh báo nguồn và sự phù hợp với các điều kiện.

Ví dụ và cách làm.

• Giả sử bạn có hai loại cảnh báo: “CriticalAlert” và “WarningAlert”. Bạn muốn đảm bảo rằng nếu cảnh báo “CriticalAlert” xuất hiện, thì cảnh báo “WarningAlert” sẽ không được gửi trong một khoảng thời gian nhất định để tránh gửi quá nhiều cảnh báo khi xảy ra vấn đề nghiêm trọng.
• Bạn có thể sử dụng “inhibit_rule” để làm điều này.

Cách làm.

• Bạn xác định một “inhibit_rule” với cảnh báo nguồn là “CriticalAlert” và cảnh báo mục tiêu là “WarningAlert”.
• Bạn định rằng nếu cảnh báo “CriticalAlert” và “WarningAlert” cùng có các nhãn giống nhau (ví dụ: cùng một máy chủ), thì quy tắc “inhibit_rule” sẽ được áp dụng.

Tự đình chỉ.

• Để ngăn cảnh báo tự đình chỉ, bạn cần đảm bảo rằng bạn đã chọn các điều kiện sao cho cảnh báo không bao giờ phù hợp với cả hai bên của “inhibit_rule” cùng một lúc.

Dưới đây là một ví dụ cấu hình sử dụng “inhibit_rule” để thực hiện điều này:

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default'

receivers:
  - name: 'default'
    email_configs:
      - to: 'your@email.com'
        send_resolved: true

inhibit_rules:
  - source_match:
      alertname: 'CriticalAlert'  # Tên của cảnh báo quan trọng nhất.
    target_match:
      alertname: 'WarningAlert'   # Tên của cảnh báo có mức độ cảnh báo thấp hơn.
    # Tạm thời đình chỉ cảnh báo "WarningAlert" trong 10 phút sau khi xảy ra cảnh báo "CriticalAlert".
    equal: []

Trong ví dụ này:

• Chúng ta đã xác định một “route” chung cho các cảnh báo với cài đặt nhóm, thời gian chờ, và các khoảng thời gian lặp lại.
• Chúng ta đã cấu hình một “receiver” mặc định để gửi cảnh báo qua email.
• Chúng ta đã sử dụng một “inhibit_rule” để xác định quy tắc đình chỉ (inhibition rule). Quy tắc này cho biết rằng nếu có cảnh báo có tên là “CriticalAlert” xuất hiện, thì cảnh báo có tên là “WarningAlert” sẽ bị đình chỉ trong 10 phút. Điều này giúp bạn tập trung vào xử lý vấn đề “CriticalAlert” trước mà không bị quấy rối bởi cảnh báo “WarningAlert” trong thời gian đó.

Lưu ý rằng bạn cần thay đổi tên của các cảnh báo và cấu hình khác phù hợp với hệ thống cảnh báo của bạn.

12. Khai báo nhãn matcher (Label Matchers).

Phần “Label matchers” mô tả cách sử dụng các bộ so khớp nhãn (label matchers) trong các quy tắc định tuyến (routes) và đình chỉ (inhibition rules) để phù hợp với các cảnh báo cụ thể. Dưới đây là giải thích chi tiết:

• Một bộ so khớp (matcher) là một chuỗi có cú pháp được lấy cảm hứng từ PromQL và OpenMetrics. Cú pháp của một bộ so khớp bao gồm ba phần:
  1. Một tên nhãn Prometheus hợp lệ.
  2. Một trong các toán tử =, !=, =~ hoặc !. Cụ thể, = đồng nghĩa với bằng, != đồng nghĩa với không bằng, = được sử dụng để so sánh với biểu thức regex và !~ được sử dụng để so sánh không phù hợp với biểu thức regex. Các toán tử này có ý nghĩa tương tự như trong các trình chọn của PromQL.
  3. Một chuỗi UTF-8, có thể được đặt trong dấu ngoặc kép. Trước hoặc sau mỗi phần, có thể có bất kỳ lượng dấu cách nào.
• Bộ so khớp được kết hợp với nhau theo phép AND, có nghĩa rằng tất cả các bộ so khớp phải đánh giá là “đúng” khi được kiểm tra đối với các nhãn trên một cảnh báo cụ thể. Ví dụ, một cảnh báo với các nhãn sau:{“alertname”: “Watchdog”, “severity”: “none”}sẽ KHÔNG phù hợp với danh sách bộ so khớp sau đây:

matchers:
  - alertname = Watchdog
  - severity =~ "warning|critical"

• Trong cấu hình, bạn có thể kết hợp nhiều bộ so khớp trong một danh sách YAML. Tuy nhiên, bạn cũng có thể kết hợp nhiều bộ so khớp trong một chuỗi YAML duy nhất, sử dụng cú pháp lấy cảm hứng từ PromQL. Trong chuỗi này, bạn có thể có một { ở đầu và/hoặc } ở cuối (tuỳ chọn) sẽ được loại bỏ trước khi tiếp tục phân tích. Các bộ so khớp riêng lẻ được tách ra bằng dấu phẩy ở ngoài phần được đặt trong dấu ngoặc kép. Các dấu phẩy này có thể được bao quanh bằng dấu cách. Phần trong dấu ngoặc kép được coi là phần đã đặt trong dấu ngoặc kép (và dấu phẩy không hoạt động như phân tách ở đó). Nếu dấu ngoặc kép được đặt trong dấu gạch chéo đơn , nó sẽ được bỏ qua cho mục đích xác định phần đã đặt trong dấu ngoặc kép. Nếu chuỗi đầu vào, sau khi loại bỏ dấu }, kết thúc bằng dấu phẩy, tiếp theo là dấu cách (tuỳ chọn), dấu phẩy và dấu cách (tuỳ chọn) sẽ được loại bỏ.

Dưới đây là một số ví dụ về bộ so khớp chuỗi hợp lệ:

• Dưới đây là hai bộ so khớp bằng nhau được kết hợp trong danh sách YAML dạng dài:

matchers:
  - foo = bar
  - dings != bums

Tương tự như ví dụ 1, dưới đây là hai bộ so khớp bằng nhau được kết hợp trong danh sách YAML dạng ngắn:

matchers: [ foo = bar, dings != bums ]

Trong dạng ngắn, thường nên đặt dấu ngoặc kép cho các phần tử danh sách để tránh vấn đề với các ký tự đặc biệt như dấu phẩy:

matchers: [ "foo = \"bar,baz\"", "dings != bums" ]

Bạn cũng có thể đặt cả hai bộ so khớp trong một chuỗi giống PromQL:

matchers: [ '{foo="bar",dings!="bums"}' ]

Để tránh sự nhầm lẫn về việc trích dẫn và thoát chuỗi trong YAML, bạn có thể sử dụng trích dẫn YAML và sau đó chỉ quan tâm đến việc thoát chuỗi trong phần bên trong. Dưới đây là một ví dụ phức tạp với biểu thức chính quy và các dấu trích dẫn khác nhau bên trong giá trị nhãn:

matchers:
  - |
      {quote=~"She said: \"Hi, all!( How're you…)?\""}

Trong ví dụ này, việc trích dẫn và thoát chuỗi trong biểu thức chính quy được thực hiện trong phần giá trị nhãn bên trong cặp dấu ngoặc kép.

Dưới đây là một ví dụ cụ thể về cách sử dụng Label matchers trong cấu hình:

Giả sử bạn có một hệ thống giám sát và bạn muốn đặt quy tắc để gửi cảnh báo về hiệu suất CPU của các máy chủ. Bạn chỉ muốn gửi cảnh báo nếu hiệu suất CPU vượt quá 90% trong thời gian dài (chẳng hạn 5 phút liên tiếp). Để làm điều này, bạn có thể sử dụng Label matchers.

Dưới đây là một phần của cấu hình Alertmanager có thể thực hiện điều này:

route:
  # ...

receivers:
  - name: 'email'
    email_configs:
      - to: 'your@email.com'

inhibit_rules:
  - source_match:
      alertname: 'CPUUsageTooHigh'
      instance: '.*'  # Phù hợp với tất cả các instance (máy chủ).
    target_match:
      alertname: 'CPUUsageTooHigh'
      instance: '.*'  # Phù hợp với tất cả các instance (máy chủ).
    equal: ['job']  # Bộ so khớp chỉ phù hợp nếu job giống nhau.

routes:
  - receiver: 'email'
    group_wait: 5m  # Chờ 5 phút để tự động tổng hợp các cảnh báo về CPUUsageTooHigh.
    group_interval: 5m
    repeat_interval: 5m
    match_re:
      job: 'node_exporter'
      alertname: 'CPUUsageTooHigh'
      instance: '.*'  # Phù hợp với tất cả các instance (máy chủ).

Trong ví dụ này:

• Chúng ta đã đặt một quy tắc định tuyến (route) để gửi cảnh báo về hiệu suất CPU cao (CPUUsageTooHigh) qua email.
• Bộ so khớp đối tượng (target_match) kiểm tra xem cảnh báo nguồn (source_match) và cảnh báo mục tiêu (target_match) có cùng job không. Nếu cùng job, quy tắc đình chỉ (inhibit_rule) sẽ được áp dụng.
• Chúng ta đã đặt quy tắc đình chỉ để đảm bảo rằng chỉ có một cảnh báo về hiệu suất CPU cao đại diện cho cùng một job và không gửi nhiều cảnh báo về cùng một sự cố.
• Quy tắc định tuyến đợi 5 phút trước khi tổng hợp các cảnh báo về CPUUsageTooHigh và sau đó gửi email thông báo về sự cố. Nếu trong 5 phút sau có nhiều cảnh báo CPU cao, chúng sẽ được tự động tổng hợp thành một email duy nhất.

Với cấu hình này, bạn có thể kiểm soát việc gửi cảnh báo về hiệu suất CPU cao dựa trên các điều kiện như job và thời gian, đồng thời đảm bảo rằng không có quá nhiều cảnh báo bị gửi trong một khoảng thời gian ngắn.

12. Các cài đặt liên quan việc nhận và xử lý cảnh báo trong hệ thống (General Receiver-Related Settings).

Các cài đặt này cho phép cấu hình các người nhận (receivers) và các tùy chọn liên quan đến gửi thông báo thông qua giao thức HTTP.

Hãy xem xét một số khái niệm quan trọng:

• Người Nhận (Receiver):
  • Người nhận (receiver) là một phần cấu hình đặt tên được sử dụng để xác định nơi thông báo sẽ được gửi đến. Có thể có một hoặc nhiều người nhận trong hệ thống cảnh báo.
  • Mỗi người nhận có thể là một tích hợp cụ thể cho một phương tiện thông báo như email, Slack, SMS, hoặc bất kỳ hình thức nào khác.
• Tích Hợp Thông Báo:
  • Mỗi người nhận (receiver) thường được cấu hình để gửi thông báo đến một dịch vụ hoặc kênh cụ thể. Ví dụ: một người nhận có thể được cấu hình để gửi email thông báo đến một địa chỉ email cụ thể.
• Người Duy Trì Cam Kết:
  • Đối với các tích hợp thông báo mới, đôi khi yêu cầu một người duy trì cam kết có quyền truy cập để đẩy mã. Điều này có nghĩa là có một cá nhân hoặc nhóm người chịu trách nhiệm duy trì tích hợp thông báo và đảm bảo tích hợp này vẫn hoạt động đúng cách.

Giờ chúng ta hãy xem ví dụ về cấu hình một người nhận thông qua HTTP:

receivers:
  - name: 'webhook'
    webhook_configs:
      - url: 'https://example.com/alerts'
        send_resolved: true

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘webhook’.
• Người nhận này được cấu hình để gửi thông báo thông qua giao thức HTTP sử dụng tích hợp webhook.
• Chúng ta đã chỉ định URL mà thông báo sẽ được gửi đến (trong ví dụ này là ‘https://example.com/alerts‘).
• Tùy chọn send_resolved đã được đặt thành true, cho phép gửi cảnh báo khi chúng được giải quyết (resolved).

Với cấu hình này, thông báo sẽ được gửi đến URL ‘https://example.com/alerts‘ thông qua HTTP khi xảy ra sự cố, và cũng khi sự cố được giải quyết (nếu send_resolved là true).

Dưới đây là cách khai báo cấu hình cho các nền tảng hoặc tích hợp thông báo cụ thể mà bạn muốn sử dụng để nhận cảnh báo trong hệ thống của mình.

# The unique name of the receiver.
name: <string>

# Configurations for several notification integrations.
discord_configs:
  [ - <discord_config>, ... ]
email_configs:
  [ - <email_config>, ... ]
msteams_configs:
  [ - <msteams_config>, ... ]
opsgenie_configs:
  [ - <opsgenie_config>, ... ]
pagerduty_configs:
  [ - <pagerduty_config>, ... ]
pushover_configs:
  [ - <pushover_config>, ... ]
slack_configs:
  [ - <slack_config>, ... ]
sns_configs:
  [ - <sns_config>, ... ]
telegram_configs:
  [ - <telegram_config>, ... ]
victorops_configs:
  [ - <victorops_config>, ... ]
webex_configs:
  [ - <webex_config>, ... ]
webhook_configs:
  [ - <webhook_config>, ... ]
wechat_configs:
  [ - <wechat_config>, ... ]

Mỗi loại cấu hình (ví dụ: Discord, Email, Microsoft Teams, Slack, và nhiều loại khác) được cung cấp dưới dạng một phần riêng biệt trong cấu hình người nhận và có các thuộc tính cụ thể cho từng nền tảng. Các cấu hình này định nghĩa cách thông báo sẽ được gửi đến một nền tảng cụ thể.

13. Một số cách bạn có thể gửi notification:

Cấu hình gửi thông báo với HTTP Config.

http_config trong hệ thống cảnh báo (Alertmanager) là một tính năng cho phép bạn cấu hình các tùy chọn liên quan đến gửi thông báo thông qua giao thức HTTP. Điều này có nghĩa là bạn có thể tùy chỉnh cách Alertmanager gửi thông báo đến các hệ thống hoặc dịch vụ khác thông qua HTTP, chẳng hạn như gửi cảnh báo đến một trang web hoặc ứng dụng bên ngoài.

# Note that `basic_auth` and `authorization` options are mutually exclusive.

# Sets the `Authorization` header with the configured username and password.
# password and password_file are mutually exclusive.
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]

# Optional the `Authorization` header configuration.
authorization:
  # Sets the authentication type.
  [ type: <string> | default: Bearer ]
  # Sets the credentials. It is mutually exclusive with
  # `credentials_file`.
  [ credentials: <secret> ]
  # Sets the credentials with the credentials read from the configured file.
  # It is mutually exclusive with `credentials`.
  [ credentials_file: <filename> ]

# Optional OAuth 2.0 configuration.
# Cannot be used at the same time as basic_auth or authorization.
oauth2:
  [ <oauth2> ]

# Whether to enable HTTP2.
[ enable_http2: <bool> | default: true ]

# Optional proxy URL.
[ proxy_url: <string> ]
# Comma-separated string that can contain IPs, CIDR notation, domain names
# that should be excluded from proxying. IP and domain names can
# contain port numbers.
[ no_proxy: <string> ]
# Use proxy URL indicated by environment variables (HTTP_PROXY, https_proxy, HTTPs_PROXY, https_proxy, and no_proxy)
[ proxy_from_environment: <boolean> | default: false ]
# Specifies headers to send to proxies during CONNECT requests.
[ proxy_connect_header:
  [ <string>: [<secret>, ...] ] ]

# Configure whether HTTP requests follow HTTP 3xx redirects.
[ follow_redirects: <bool> | default = true ]

# Configures the TLS settings.
tls_config:
  [ <tls_config> ]

Dưới đây là một ví dụ về cách cấu hình http_config trong tệp cấu hình của Alertmanager:

http_config:
  # Các cài đặt cụ thể cho gửi thông báo qua HTTP
  send_resolved: true
  timeout: 10s
  proxy_url: http://your-proxy-server:8080
  # Các tùy chọn xác thực (nếu cần)
  basic_auth:
    username: your-username
    password: your-password

Trong ví dụ này:

• send_resolved: Điều này xác định xem Alertmanager có gửi thông báo khi chúng được giải quyết (resolved) hay không. Nếu được đặt thành true, cảnh báo được gửi khi chúng được tạo và khi chúng được giải quyết. Nếu được đặt thành false, chỉ các cảnh báo chưa giải quyết mới được gửi.
• timeout: Đây là thời gian tối đa mà Alertmanager sẽ chờ để gửi thông báo thông qua HTTP trước khi hủy bỏ kết nối.
• proxy_url: Nếu bạn sử dụng một máy chủ proxy để gửi thông báo qua HTTP, bạn có thể đặt URL của máy chủ proxy ở đây.
• basic_auth: Nếu máy chủ HTTP yêu cầu xác thực cơ bản, bạn có thể đặt thông tin xác thực bằng cách cung cấp tên người dùng và mật khẩu trong phần này.

http_config cho phép bạn điều chỉnh cách gửi thông báo và tương tác với các hệ thống hoặc dịch vụ thông qua giao thức HTTP để đảm bảo tính linh hoạt và an toàn trong việc quản lý cảnh báo.

Cấu hình người nhận sử dụng OAuth 2.0.

OAuth 2.0 (Open Authorization 2.0) là một giao thức ủy quyền được sử dụng rộng rãi trong ứng dụng web và dịch vụ trực tuyến để quản lý quyền truy cập đối với tài khoản người dùng hoặc dịch vụ mà người dùng đang sử dụng. Giao thức này cho phép người dùng cấp quyền truy cập tới tài khoản hoặc thông tin của họ cho các ứng dụng hoặc dịch vụ khác mà họ tin tưởng mà không cần chia sẻ mật khẩu của tài khoản.

client_id: <string>
[ client_secret: <secret> ]

# Read the client secret from a file.
# It is mutually exclusive with `client_secret`.
[ client_secret_file: <filename> ]

# Scopes for the token request.
scopes:
  [ - <string> ... ]

# The URL to fetch the token from.
token_url: <string>

# Optional parameters to append to the token URL.
endpoint_params:
  [ <string>: <string> ... ]

# Configures the token request's TLS settings.
tls_config:
  [ <tls_config> ]

# Optional proxy URL.
[ proxy_url: <string> ]
# Comma-separated string that can contain IPs, CIDR notation, domain names
# that should be excluded from proxying. IP and domain names can
# contain port numbers.
[ no_proxy: <string> ]
# Use proxy URL indicated by environment variables (HTTP_PROXY, https_proxy, HTTPs_PROXY, https_proxy, and no_proxy)
[ proxy_from_environment: <boolean> | default: false ]
# Specifies headers to send to proxies during CONNECT requests.
[ proxy_connect_header:
  [ <string>: [<secret>, ...] ] ]

Ví dụ cơ bản về cách OAuth 2.0 hoạt động:

• Ứng dụng yêu cầu quyền truy cập: Một ứng dụng muốn truy cập dữ liệu hoặc tài khoản của người dùng thông qua một dịch vụ hoặc trang web khác. Ứng dụng này cần được xác minh và được cấp quyền truy cập.
• Chuyển hướng đến trình duyệt: Khi người dùng chọn cấp quyền, ứng dụng chuyển hướng người dùng đến một trình duyệt web để đăng nhập vào tài khoản của họ trên dịch vụ cung cấp OAuth (ví dụ: Google, Facebook).
• Xác thực và cấp token: Sau khi đăng nhập thành công, dịch vụ OAuth sẽ xác thực người dùng và cấp cho ứng dụng một mã truy cập (access token) hoặc mã cấp lại (refresh token).
• Truy cập tài nguyên: Ứng dụng sử dụng mã truy cập hoặc mã cấp lại để truy cập dữ liệu hoặc tài khoản của người dùng từ dịch vụ cung cấp OAuth.
• Làm mới token (nếu cần): Nếu mã truy cập hết hạn, ứng dụng có thể sử dụng mã cấp lại để làm mới mã truy cập mà không cần yêu cầu người dùng đăng nhập lại.

Dưới đây là một ví dụ về cấu hình sử dụng OAuth 2.0 trong hệ thống cảnh báo:

oauth2:
  client_id: 'your-client-id'
  client_secret: 'your-client-secret'
  token_url: 'https://oauth.example.com/token'
  auth_url: 'https://oauth.example.com/auth'
  scopes:
    - 'read'
    - 'write'

• client_id và client_secret là thông tin xác thực của ứng dụng OAuth 2.0.
• token_url là URL để yêu cầu mã truy cập từ dịch vụ OAuth.
• auth_url là URL để xác thực người dùng và cấp quyền truy cập.
• scopes là danh sách các quyền truy cập được yêu cầu bởi ứng dụng.

Khi bạn tích hợp OAuth 2.0 vào hệ thống cảnh báo của mình, bạn có thể sử dụng nó để đảm bảo tính bảo mật khi gửi thông báo hoặc truy cập các tài nguyên quan trọng.

Cấu hình các tùy chọn liên quan đến giao thức bảo mật TLS cho việc gửi thông báo và cảnh báo qua các kênh an toàn.

Tính năng tls_config trong hệ thống cảnh báo là để cấu hình các tùy chọn liên quan đến giao thức bảo mật TLS (Transport Layer Security) cho việc gửi thông báo và cảnh báo qua các kênh an toàn. TLS là một giao thức bảo mật được sử dụng để bảo vệ dữ liệu truyền tải qua mạng, đặc biệt là khi dữ liệu đóng vai trò quan trọng như trong việc gửi cảnh báo.

<tls_config> cho phép cấu hình các kết nối TLS (Transport Layer Security). TLS là một giao thức bảo mật được sử dụng để bảo vệ thông tin khi truyền trên mạng, đặc biệt là khi kết nối qua internet. Cấu hình TLS làm cho các kết nối trở nên an toàn bằng cách sử dụng chứng chỉ số học và mã hóa để bảo vệ dữ liệu truyền qua mạng.

# CA certificate to validate the server certificate with.
[ ca_file: <filepath> ]

# Certificate and key files for client cert authentication to the server.
[ cert_file: <filepath> ]
[ key_file: <filepath> ]

# ServerName extension to indicate the name of the server.
# http://tools.ietf.org/html/rfc4366#section-3.1
[ server_name: <string> ]

# Disable validation of the server certificate.
[ insecure_skip_verify: <boolean> | default = false]

# Minimum acceptable TLS version. Accepted values: TLS10 (TLS 1.0), TLS11 (TLS
# 1.1), TLS12 (TLS 1.2), TLS13 (TLS 1.3).
# If unset, Prometheus will use Go default minimum version, which is TLS 1.2.
# See MinVersion in https://pkg.go.dev/crypto/tls#Config.
[ min_version: <string> ]
# Maximum acceptable TLS version. Accepted values: TLS10 (TLS 1.0), TLS11 (TLS
# 1.1), TLS12 (TLS 1.2), TLS13 (TLS 1.3).
# If unset, Prometheus will use Go default maximum version, which is TLS 1.3.
# See MaxVersion in https://pkg.go.dev/crypto/tls#Config.
[ max_version: <string> ]

Dưới đây là một ví dụ về cách cấu hình tls_config để thiết lập kết nối an toàn TLS (Transport Layer Security) trong người nhận:

receivers:
  - name: 'tls-notify'
    email_configs:
      - to: 'recipient@example.com'
        send_resolved: false
    tls_config:
      insecure_skip_verify: false
      ca_file: '/path/to/ca.pem'
      cert_file: '/path/to/cert.pem'
      key_file: '/path/to/key.pem'

Trong ví dụ này:

• Chúng ta đã đặt tên người nhận là ‘tls-notify’.
• Chúng ta đã sử dụng email_configs để cấu hình việc gửi thông báo qua email.
• Trong email_configs, chúng ta đã chỉ định địa chỉ email của người nhận tại 'recipient@example.com'.
• Chúng ta đã sử dụng tls_config để cấu hình tùy chọn TLS.
• Trong tls_config, có các tùy chọn sau:
  • insecure_skip_verify: Một cờ boolean cho biết liệu phải bỏ qua việc xác minh chứng chỉ TLS hoặc không (thường được sử dụng để bật hoặc tắt xác minh chứng chỉ). Trong ví dụ này, chúng ta đã đặt insecure_skip_verify là false, tức là không bỏ qua việc xác minh chứng chỉ.
  • ca_file: Đường dẫn đến tệp PEM chứa danh sách chứng chỉ CA (Certificate Authorities) mà máy chủ email sử dụng để xác minh chứng chỉ SSL/TLS. Trong ví dụ này, chúng ta đã chỉ định đường dẫn tới tệp CA.
  • cert_file: Đường dẫn đến tệp PEM chứa chứng chỉ SSL/TLS của máy gửi. Trong ví dụ này, chúng ta đã chỉ định đường dẫn tới tệp chứng chỉ.
  • key_file: Đường dẫn đến tệp PEM chứa khóa riêng tư của máy gửi. Trong ví dụ này, chúng ta đã chỉ định đường dẫn tới tệp khóa.

Cấu hình cách thông báo và cảnh báo sẽ được gửi đến máy chủ Discord hoặc các kênh Discord.

Tính năng Discord trong hệ thống cảnh báo cho phép bạn cấu hình cách thông báo và cảnh báo sẽ được gửi đến máy chủ Discord hoặc các kênh Discord. Discord là một nền tảng trò chuyện và gọi thoại trực tuyến phổ biến, thường được sử dụng bởi các cộng đồng trò chơi và tổ chức để tương tác và gửi thông báo.

<discord_config> cho phép cấu hình thông báo Discord được gửi thông qua API webhook của Discord. Để biết cách cấu hình tích hợp webhook cho một kênh, hãy xem bài viết “Giới thiệu về Webhooks” của Discord để tìm hiểu cách cấu hình tích hợp webhook cho một kênh cụ thể trên Discord.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The Discord webhook URL.
webhook_url: <secret>

# Message title template.
[ title: <tmpl_string> | default = '{{ template "discord.default.title" . }}' ]

# Message body template.
[ message: <tmpl_string> | default = '{{ template "discord.default.message" . }}' ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách cấu hình discord_config để gửi cảnh báo qua Discord:

receivers:
  - name: 'discord-notify'
    discord_configs:
      - send_resolved: false
        webhook_configs:
          - send_resolved: true
            url: 'https://discordapp.com/api/webhooks/your_webhook_id/your_webhook_token'
            username: 'AlertManager'
            avatar_url: 'https://your-avatar-url.com/avatar.png'
            icon_url: 'https://your-icon-url.com/icon.png'
            allowed_mentions:
              users:
                - 'user_id'
              roles:
                - 'role_id'

Trong ví dụ này:

• Chúng ta đã đặt tên người nhận là ‘discord-notify’.
• Chúng ta đã sử dụng discord_configs để cấu hình việc gửi thông báo qua Discord.
• Trong discord_configs, có các tùy chọn sau:
  • send_resolved: Một cờ boolean cho biết liệu phải gửi cảnh báo khi nó được giải quyết (true) hay không (false). Trong ví dụ này, chúng ta đã đặt send_resolved là false, tức là không gửi cảnh báo khi nó được giải quyết.
  • webhook_configs: Một danh sách các cấu hình webhook Discord. Trong ví dụ này, chúng ta đã chỉ định một cấu hình webhook.
    • send_resolved: Một cờ boolean cho biết liệu phải gửi cảnh báo khi nó được giải quyết (true) hay không (false). Trong cấu hình này, chúng ta đã đặt send_resolved là true, tức là gửi cảnh báo khi nó được giải quyết.
    • url: Đường dẫn URL của webhook Discord. Bạn cần cung cấp URL webhook Discord của mình ở đây.
    • username: Tên người dùng xuất hiện trong thông báo Discord. Trong ví dụ này, chúng ta đã đặt tên người dùng là ‘AlertManager’.
    • avatar_url: Đường dẫn URL đến hình ảnh avatar của người dùng. Trong ví dụ này, chúng ta đã chỉ định một URL hình ảnh avatar.
    • icon_url: Đường dẫn URL đến hình ảnh biểu tượng trong thông báo. Trong ví dụ này, chúng ta đã chỉ định một URL hình ảnh biểu tượng.
    • allowed_mentions: Cấu hình các đối tượng Discord được phép được đề cập trong thông báo. Trong ví dụ này, chúng ta đã chỉ định danh sách người dùng và vai trò được đề cập.

Cấu hình cách thông báo và cảnh báo sẽ được gửi qua email.

Tính năng email_config trong hệ thống cảnh báo cho phép bạn cấu hình cách thông báo và cảnh báo sẽ được gửi qua email. Điều này rất hữu ích để thông báo cho các quản trị viên hoặc nhóm quản lý khi có sự cố hoặc cảnh báo quan trọng trong hệ thống của bạn.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = false ]

# The email address to send notifications to.
to: <tmpl_string>

# The sender's address.
[ from: <tmpl_string> | default = global.smtp_from ]

# The SMTP host through which emails are sent.
[ smarthost: <string> | default = global.smtp_smarthost ]

# The hostname to identify to the SMTP server.
[ hello: <string> | default = global.smtp_hello ]

# SMTP authentication information.
# auth_password and auth_password_file are mutually exclusive.
[ auth_username: <string> | default = global.smtp_auth_username ]
[ auth_password: <secret> | default = global.smtp_auth_password ]
[ auth_password_file: <string> | default = global.smtp_auth_password_file ]
[ auth_secret: <secret> | default = global.smtp_auth_secret ]
[ auth_identity: <string> | default = global.smtp_auth_identity ]

# The SMTP TLS requirement.
# Note that Go does not support unencrypted connections to remote SMTP endpoints.
[ require_tls: <bool> | default = global.smtp_require_tls ]

# TLS configuration.
tls_config:
  [ <tls_config> ]

# The HTML body of the email notification.
[ html: <tmpl_string> | default = '{{ template "email.default.html" . }}' ]
# The text body of the email notification.
[ text: <tmpl_string> ]

# Further headers email header key/value pairs. Overrides any headers
# previously set by the notification implementation.
[ headers: { <string>: <tmpl_string>, ... } ]

Dưới đây là một ví dụ về cách cấu hình email_config để gửi cảnh báo qua email:

receivers:
  - name: 'email-notify'
    email_configs:
      - to: 'your@email.com'
        from: 'alertmanager@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'your_username'
        auth_password: 'your_password'
        auth_identity: ''
        send_resolved: false
        require_tls: true
        headers:
          Subject: 'Alert: {{ .CommonLabels.alertname }}'
          From: 'AlertManager <alertmanager@example.com>'

Trong ví dụ này:

• Chúng ta đã đặt tên người nhận là ’email-notify’.
• Chúng ta đã sử dụng email_configs để cấu hình việc gửi thông báo qua email.
• Trong email_configs, có các tùy chọn sau:
  • to: Địa chỉ email mà bạn muốn gửi cảnh báo đến. Điều này nên là địa chỉ email của bạn hoặc người nhận cảnh báo.
  • from: Địa chỉ email xuất hiện trong trường “From” của email gửi đi.
  • smarthost: Smarthost (SMTP server) và cổng để gửi email thông qua. Trong ví dụ này, chúng ta đã sử dụng ‘smtp.example.com:587’. Bạn cần thay thế nó bằng thông tin SMTP của bạn.
  • auth_username và auth_password: Tên người dùng và mật khẩu để xác thực với SMTP server (nếu cần). Điền thông tin xác thực của bạn ở đây.
  • auth_identity: Xác định danh tính xác thực (nếu có). Trong trường hợp này, nó để trống.
  • send_resolved: Một cờ boolean cho biết liệu phải gửi cảnh báo khi nó được giải quyết (true) hay không (false). Trong ví dụ này, chúng ta đã đặt send_resolved là false, tức là không gửi cảnh báo khi nó được giải quyết.
  • require_tls: Một cờ boolean cho biết liệu TLS (Transport Layer Security) là bắt buộc khi gửi email hay không. Trong ví dụ này, chúng ta đã đặt require_tls là true, đảm bảo gửi email qua kết nối TLS an toàn.
  • headers: Điều này cho phép bạn đặt các tiêu đề tùy chỉnh cho email. Trong ví dụ này, chúng ta đã đặt tiêu đề “Subject” và “From”.

Cấu hình gửi thông báo qua Microsoft Teams.

Microsoft Teams là một nền tảng hợp tác và trò chuyện trực tuyến phát triển bởi Microsoft. Được giới thiệu lần đầu vào năm 2017, Microsoft Teams giúp các tổ chức và doanh nghiệp tạo môi trường làm việc trực tuyến để thúc đẩy sự hợp tác, giao tiếp và quản lý công việc.

<msteams_config> cho phép cấu hình thông báo Microsoft Teams được gửi thông qua API endpoint của Webhooks đến Microsoft Teams. Điều này cho phép tích hợp Alertmanager với Microsoft Teams để gửi thông báo và cảnh báo đến các kênh hoặc nhóm làm việc trên nền tảng Microsoft Teams.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The incoming webhook URL.
[ webhook_url: <secret> ]

# Message title template.
[ title: <tmpl_string> | default = '{{ template "teams.default.title" . }}' ]

# Message body template.
[ text: <tmpl_string> | default = '{{ template "teams.default.text" . }}' ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách cấu hình msteams_config để gửi cảnh báo qua Microsoft Teams:

receivers:
  - name: 'msteams-notify'
    msteams_configs:
      - send_resolved: true
        webhook_url: 'https://outlook.office.com/webhook/your/webhook/url'
        title: 'Alert: {{ .CommonLabels.alertname }}'
        text: |
          **Alert:** {{ .CommonLabels.alertname }}
          **Status:** {{ .CommonLabels.severity }}
          **Description:** {{ .CommonAnnotations.description }}
          **Summary:** {{ .CommonAnnotations.summary }}

Trong ví dụ này:

• Chúng ta đã đặt tên người nhận là ‘msteams-notify’.
• Chúng ta đã sử dụng msteams_configs để cấu hình việc gửi thông báo qua Microsoft Teams.
• Trong msteams_configs, có các tùy chọn sau:
  • send_resolved: Một cờ boolean cho biết liệu phải gửi cảnh báo khi nó được giải quyết (true) hay không (false). Trong ví dụ này, chúng ta đã đặt send_resolved là true, tức là gửi cảnh báo cả khi nó được giải quyết.
  • webhook_url: URL webhook của Microsoft Teams. Bạn cần cung cấp URL webhook của mình tại đây.
  • title: Tiêu đề của thông báo trong Microsoft Teams. Trong ví dụ này, chúng ta đã đặt tiêu đề dựa trên nhãn alertname.
  • text: Nội dung thông báo. Trong ví dụ này, chúng ta đã tạo một nội dung có định dạng sử dụng các thông tin từ nhãn và chú thích của cảnh báo.

Thông qua cấu hình này, bạn có thể gửi cảnh báo từ AlertManager vào kênh Microsoft Teams của bạn thông qua webhook URL. Vui lòng thay đổi webhook_url, title, và text để phù hợp với yêu cầu của bạn và tuỳ chỉnh nội dung thông báo theo cách bạn muốn.

Cấu hình gửi cảnh báo tới dịch vụ Opsgenie.

opsgenie_config trong cấu hình Alertmanager là một phần của tích hợp thông báo để gửi cảnh báo tới dịch vụ Opsgenie. Opsgenie là một công cụ quản lý cảnh báo và sự cố giúp các tổ chức theo dõi, quản lý, và ứng phó với sự cố trong hệ thống của họ.

Để sử dụng opsgenie_config, bạn cần cung cấp các thông tin cấu hình liên quan đến dịch vụ Opsgenie, bao gồm API key, endpoint URL, và các tùy chọn khác để xác định cách thông báo được gửi và xử lý bởi Opsgenie.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The API key to use when talking to the OpsGenie API.
[ api_key: <secret> | default = global.opsgenie_api_key ]

# The filepath to API key to use when talking to the OpsGenie API. Conflicts with api_key.
[ api_key_file: <filepath> | default = global.opsgenie_api_key_file ]

# The host to send OpsGenie API requests to.
[ api_url: <string> | default = global.opsgenie_api_url ]

# Alert text limited to 130 characters.
[ message: <tmpl_string> | default = '{{ template "opsgenie.default.message" . }}' ]

# A description of the alert.
[ description: <tmpl_string> | default = '{{ template "opsgenie.default.description" . }}' ]

# A backlink to the sender of the notification.
[ source: <tmpl_string> | default = '{{ template "opsgenie.default.source" . }}' ]

# A set of arbitrary key/value pairs that provide further detail
# about the alert.
# All common labels are included as details by default.
[ details: { <string>: <tmpl_string>, ... } ]

# List of responders responsible for notifications.
responders:
  [ - <responder> ... ]

# Comma separated list of tags attached to the notifications.
[ tags: <tmpl_string> ]

# Additional alert note.
[ note: <tmpl_string> ]

# Priority level of alert. Possible values are P1, P2, P3, P4, and P5.
[ priority: <tmpl_string> ]

# Whether to update message and description of the alert in OpsGenie if it already exists
# By default, the alert is never updated in OpsGenie, the new message only appears in activity log.
[ update_alerts: <boolean> | default = false ]

# Optional field that can be used to specify which domain alert is related to.
[ entity: <tmpl_string> ]

# Comma separated list of actions that will be available for the alert.
[ actions: <tmpl_string> ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách cấu hình opsgenie_config để gửi cảnh báo qua Opsgenie:

receivers:
  - name: 'opsgenie-notify'
    opsgenie_configs:
      - api_key: 'your-opsgenie-api-key'
        priority: 'P1'
        details: true
        source: 'AlertManager'
        teams:
          - 'Team1'
        tags:
          - 'alert'
          - 'production'

Trong ví dụ này:

• Chúng ta đã đặt tên người nhận là ‘opsgenie-notify’.
• Chúng ta đã sử dụng opsgenie_configs để cấu hình việc gửi thông báo qua Opsgenie.
• Trong opsgenie_configs, có các tùy chọn sau:
  • api_key: Khóa API Opsgenie của bạn. Bạn cần cung cấp khóa API của mình tại đây.
  • priority: Mức độ ưu tiên của cảnh báo. Trong ví dụ này, chúng ta đã đặt mức độ ưu tiên là ‘P1’.
  • details: Một cờ boolean cho biết liệu phải bao gồm chi tiết của cảnh báo trong thông báo Opsgenie hay không (true là bao gồm, false là không bao gồm). Trong ví dụ này, chúng ta đã đặt details là true.
  • source: Nguồn của cảnh báo. Trong ví dụ này, chúng ta đã đặt nguồn là ‘AlertManager’.
  • teams: Danh sách các nhóm Opsgenie mà bạn muốn gửi cảnh báo đến. Trong ví dụ này, chúng ta đã đặt danh sách nhóm là ‘Team1’.
  • tags: Danh sách các nhãn mà bạn muốn áp dụng cho cảnh báo. Trong ví dụ này, chúng ta đã đặt danh sách nhãn là ‘alert’ và ‘production’.

Thông qua cấu hình này, bạn có thể gửi cảnh báo từ AlertManager vào Opsgenie với các tùy chọn như khóa API, mức độ ưu tiên, chi tiết, nguồn, nhóm, và nhãn được chỉ định.

Cấu hình các quy tắc để xử lý cảnh báo sau khi chúng đã được gửi đi.

responder_config là một tính năng trong hệ thống cảnh báo (Alertmanager) cho phép bạn cấu hình các quy tắc để xử lý cảnh báo sau khi chúng đã được gửi đi. Cụ thể, Responder cho phép bạn thực hiện các hành động như xác nhận cảnh báo (acknowledge) hoặc đánh dấu cảnh báo là đã giải quyết (resolved) và sau đó chuyển chúng đến các hệ thống hoặc dịch vụ khác để thực hiện xử lý tiếp theo.

Dưới đây là một số hoạt động mà bạn có thể thực hiện bằng responder_config:

• Xác nhận cảnh báo: Bạn có thể đặt cảnh báo thành trạng thái “đã xác nhận” để chỉ ra rằng bạn đã biết về vấn đề và đang xử lý nó.
• Đánh dấu cảnh báo là đã giải quyết: Khi vấn đề đã được giải quyết, bạn có thể đánh dấu cảnh báo là đã giải quyết để thể hiện rằng nó không còn quan trọng nữa.
• Chuyển cảnh báo đến các hệ thống hoặc dịch vụ khác: Bạn có thể chuyển cảnh báo đã xác nhận hoặc đã giải quyết đến các hệ thống quản lý sự cố như Opsgenie, PagerDuty, Slack, hoặc bất kỳ hệ thống nào khác hỗ trợ tích hợp.

Tích hợp Responder vào hệ thống cảnh báo giúp tự động hóa quy trình xử lý cảnh báo và đảm bảo rằng các cảnh báo quan trọng được chuyển đến người hay hệ thống phù hợp để xử lý. Điều này giúp cải thiện hiệu suất của quá trình quản lý cảnh báo và giảm thời gian phản ứng đối với các vấn đề quan trọng.

# Exactly one of these fields should be defined.
[ id: <tmpl_string> ]
[ name: <tmpl_string> ]
[ username: <tmpl_string> ]

# "team", "teams", "user", "escalation" or "schedule".
type: <tmpl_string>

Dưới đây là một ví dụ về cách cấu hình responder_config để sử dụng Responder trong hệ thống cảnh báo:

receivers:
  - name: 'responder-notify'
    responder_configs:
      - ack_label: 'acknowledged'
        resolved_label: 'resolved'
        target:
          opsgenie_configs:
            - api_key: 'your-opsgenie-api-key'
              priority: 'P1'
              details: true
              source: 'AlertManager'
              teams:
                - 'Team1'
              tags:
                - 'alert'
                - 'production'

Trong ví dụ này:

• Chúng ta đã đặt tên người nhận là ‘responder-notify’.
• Chúng ta đã sử dụng responder_configs để cấu hình Responder.
• Trong responder_configs, có các tùy chọn sau:
  • ack_label: Nhãn (label) để đánh dấu cảnh báo khi nó được xác nhận (acknowledged). Trong ví dụ này, chúng ta đã đặt nhãn là ‘acknowledged’.
  • resolved_label: Nhãn để đánh dấu cảnh báo khi nó được giải quyết (resolved). Trong ví dụ này, chúng ta đã đặt nhãn là ‘resolved’.
  • target: Phần này xác định nơi cảnh báo sẽ được gửi đến sau khi được xác nhận hoặc giải quyết. Trong ví dụ này, chúng ta đã sử dụng Opsgenie như mục tiêu.
    • Trong phần opsgenie_configs, chúng ta đã cấu hình Opsgenie giống như trong ví dụ trước đó.

Thông qua cấu hình này, Responder sẽ xác nhận hoặc giải quyết các cảnh báo dựa trên nhãn ack_label và resolved_label, sau đó chuyển chúng đến Opsgenie với các tùy chọn cấu hình khác nhau.

Cấu hình nhận thông báo qua PagerDuty.

PagerDuty là một dịch vụ quản lý sự cố và hệ thống cảnh báo, thường được sử dụng để quản lý và phản hồi vào các sự cố kỹ thuật và hệ thống trong môi trường công nghệ thông tin. Nó cho phép tổ chức tạo và quản lý các dịch vụ, sự cố, và nhóm phản hồi, và cung cấp cơ chế cảnh báo để thông báo về các vấn đề quan trọng ngay lập tức.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The routing and service keys are mutually exclusive.
# The PagerDuty integration key (when using PagerDuty integration type `Events API v2`).
# It is mutually exclusive with `routing_key_file`.
routing_key: <tmpl_secret>
# Read the Pager Duty routing key from a file.
# It is mutually exclusive with `routing_key`.
routing_key_file: <filepath>
# The PagerDuty integration key (when using PagerDuty integration type `Prometheus`).
# It is mutually exclusive with `service_key_file`.
service_key: <tmpl_secret>
# Read the Pager Duty service key from a file.
# It is mutually exclusive with `service_key`.
service_key_file: <filepath>

# The URL to send API requests to
[ url: <string> | default = global.pagerduty_url ]

# The client identification of the Alertmanager.
[ client:  <tmpl_string> | default = '{{ template "pagerduty.default.client" . }}' ]
# A backlink to the sender of the notification.
[ client_url:  <tmpl_string> | default = '{{ template "pagerduty.default.clientURL" . }}' ]

# A description of the incident.
[ description: <tmpl_string> | default = '{{ template "pagerduty.default.description" .}}' ]

# Severity of the incident.
[ severity: <tmpl_string> | default = 'error' ]

# Unique location of the affected system.
[ source: <tmpl_string> | default = client ]

# A set of arbitrary key/value pairs that provide further detail
# about the incident.
[ details: { <string>: <tmpl_string>, ... } | default = {
  firing:       '{{ template "pagerduty.default.instances" .Alerts.Firing }}'
  resolved:     '{{ template "pagerduty.default.instances" .Alerts.Resolved }}'
  num_firing:   '{{ .Alerts.Firing | len }}'
  num_resolved: '{{ .Alerts.Resolved | len }}'
} ]

# Images to attach to the incident.
images:
  [ <image_config> ... ]

# Links to attach to the incident.
links:
  [ <link_config> ... ]

# The part or component of the affected system that is broken.
[ component: <tmpl_string> ]

# A cluster or grouping of sources.
[ group: <tmpl_string> ]

# The class/type of the event.
[ class: <tmpl_string> ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

PagerDuty thường được tích hợp với các công cụ giám sát hệ thống như Prometheus và Alertmanager để tạo ra một quy trình xử lý sự cố tự động. Khi một cảnh báo được tạo ra từ hệ thống giám sát, nó có thể được đẩy đến PagerDuty, và sau đó PagerDuty có thể gửi thông báo tới các nhóm phản hồi hoặc người dùng cụ thể để xử lý vấn đề.

Dưới đây là một ví dụ về cấu hình PagerDuty trong Alertmanager:

receivers:
  - name: 'pagerduty'
    pagerduty_configs:
      - service_key: 'YOUR_PAGERDUTY_SERVICE_KEY'
        url: 'https://events.pagerduty.com/v2/enqueue'

Trong ví dụ này:

• receivers định nghĩa một người nhận được đặt tên là ‘pagerduty’.
• pagerduty_configs chứa cấu hình cho PagerDuty.
• service_key là khóa dịch vụ PagerDuty của bạn, được sử dụng để xác định dịch vụ hoặc sự cố cụ thể mà cảnh báo đang liên quan đến.
• url là URL của PagerDuty API endpoint để đẩy cảnh báo đến.

Khi một cảnh báo phù hợp với người nhận này, nó sẽ được gửi đến PagerDuty sử dụng khóa dịch vụ của bạn, từ đó bạn có thể quản lý và xử lý nó trong PagerDuty dashboard hoặc thông qua các kết nối và tích hợp khác của PagerDuty.

Đính kèm hình ảnh vào cảnh báo.

image_config là một phần của cấu hình trong Alertmanager và được sử dụng để đính kèm hình ảnh vào cảnh báo. Điều này có thể hữu ích để hiển thị thông tin hình ảnh cụ thể hoặc biểu đồ liên quan đến sự cố trong cảnh báo.

href: <tmpl_string>
src: <tmpl_string>
alt: <tmpl_string>

Dưới đây là một ví dụ về cách sử dụng image_config trong cấu hình Alertmanager:

route:
  group_by: ['alertname']
  receiver: 'webhook'

receivers:
  - name: 'webhook'
    webhook_configs:
      - url: 'https://your-webhook-endpoint.com'
        image_config:
          background: 'lightgray'
          title: 'Alert Image'
          image: 'https://example.com/alert-image.png'

Trong ví dụ này:

• Chúng tôi đã định nghĩa một route để gửi cảnh báo đến một người nhận có tên là ‘webhook’.
• Chúng tôi đã cấu hình người nhận ‘webhook’ để gửi cảnh báo đến một webhook endpoint tại ‘https://your-webhook-endpoint.com‘.
• Trong webhook_configs, chúng tôi đã sử dụng image_config để đính kèm hình ảnh vào cảnh báo.
  • background xác định màu nền cho hình ảnh (ở đây là ‘lightgray’).
  • title là tiêu đề cho hình ảnh.
  • image là URL của hình ảnh mà bạn muốn đính kèm vào cảnh báo (ở đây là ‘https://example.com/alert-image.png‘).

Khi một cảnh báo được gửi đến người nhận ‘webhook’, nó sẽ bao gồm hình ảnh được đính kèm với nó dựa trên cấu hình image_config.

Đính kèm các liên kết hoặc URL vào cảnh báo.

link_config là một phần của cấu hình trong Alertmanager và được sử dụng để đính kèm các liên kết hoặc URL vào cảnh báo. Điều này có thể giúp người nhận cảnh báo dễ dàng truy cập các thông tin liên quan hoặc tài liệu hướng dẫn để giải quyết vấn đề.

href: <tmpl_string>
text: <tmpl_string>

Dưới đây là một ví dụ về cách sử dụng link_config trong cấu hình Alertmanager:

route:
  group_by: ['alertname']
  receiver: 'webhook'

receivers:
  - name: 'webhook'
    webhook_configs:
      - url: 'https://your-webhook-endpoint.com'
        link_config:
          text: 'Learn more'
          href: 'https://example.com/alert-documentation'

Trong ví dụ này:

• Chúng tôi đã định nghĩa một route để gửi cảnh báo đến một người nhận có tên là ‘webhook’.
• Chúng tôi đã cấu hình người nhận ‘webhook’ để gửi cảnh báo đến một webhook endpoint tại ‘https://your-webhook-endpoint.com‘.
• Trong webhook_configs, chúng tôi đã sử dụng link_config để đính kèm một liên kết vào cảnh báo.
  • text là văn bản hiển thị cho liên kết (ở đây là ‘Learn more’).
  • href là URL của liên kết (ở đây là ‘https://example.com/alert-documentation‘).

Khi một cảnh báo được gửi đến người nhận ‘webhook’, nó sẽ bao gồm liên kết được đính kèm với nó dựa trên cấu hình link_config.

Cấu hình nhận thông báo qua Pushover.

Pushover là một dịch vụ thông báo di động và máy tính được sử dụng để gửi thông báo từ ứng dụng và dịch vụ khác đến thiết bị di động của bạn hoặc máy tính. Trong Alertmanager, bạn có thể sử dụng tích hợp Pushover để gửi cảnh báo từ hệ thống giám sát của mình đến ứng dụng Pushover trên các thiết bị của người nhận.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The recipient user's key.
# user_key and user_key_file are mutually exclusive.
user_key: <secret>
user_key_file: <filepath>

# Your registered application's API token, see https://pushover.net/apps
# You can also register a token by cloning this Prometheus app:
# https://pushover.net/apps/clone/prometheus
# token and token_file are mutually exclusive.
token: <secret>
token_file: <filepath>

# Notification title.
[ title: <tmpl_string> | default = '{{ template "pushover.default.title" . }}' ]

# Notification message.
[ message: <tmpl_string> | default = '{{ template "pushover.default.message" . }}' ]

# A supplementary URL shown alongside the message.
[ url: <tmpl_string> | default = '{{ template "pushover.default.url" . }}' ]

# Optional device to send notification to, see https://pushover.net/api#device
[ device: <string> ]

# Optional sound to use for notification, see https://pushover.net/api#sound
[ sound: <string> ]

# Priority, see https://pushover.net/api#priority
[ priority: <tmpl_string> | default = '{{ if eq .Status "firing" }}2{{ else }}0{{ end }}' ]

# How often the Pushover servers will send the same notification to the user.
# Must be at least 30 seconds.
[ retry: <duration> | default = 1m ]

# How long your notification will continue to be retried for, unless the user
# acknowledges the notification.
[ expire: <duration> | default = 1h ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách cấu hình tích hợp Pushover trong cấu hình Alertmanager:

receivers:
  - name: 'pushover'
    pushover_configs:
      user_key: 'your-user-key'
      token: 'your-app-token'

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘pushover’.
• Trong pushover_configs, bạn cần cung cấp hai thông tin quan trọng:
  • user_key: Đây là khóa của người dùng Pushover, được sử dụng để xác định người nhận cuối cùng. Bạn cần đăng ký một tài khoản Pushover và lấy khóa người dùng từ trang web của họ.
  • token: Đây là mã thông báo ứng dụng của bạn, được sử dụng để xác định ứng dụng hoặc dự án cụ thể gửi cảnh báo. Bạn cũng cần đăng ký một ứng dụng Pushover và lấy mã thông báo từ trang web của họ.

Sau khi bạn đã cấu hình người nhận Pushover này, bạn có thể sử dụng nó trong các quy tắc định tuyến để gửi cảnh báo đến thiết bị Pushover của người nhận khi xảy ra sự cố trong hệ thống giám sát của bạn.

Cấu hình nhận thông báo qua Slack.

Slack là một dịch vụ giao tiếp và làm việc nhóm phổ biến, cho phép bạn tạo các kênh chat, gửi tin nhắn, chia sẻ tệp tin và làm việc cùng nhau trong môi trường làm việc trực tuyến. Trong Alertmanager, bạn có thể sử dụng tích hợp Slack để gửi cảnh báo từ hệ thống giám sát của mình đến các kênh Slack của nhóm làm việc.

• <slack_config> cho phép cấu hình thông báo Slack được gửi thông qua tích hợp Slack. Tùy thuộc vào cách tích hợp, có hai cách để gửi thông báo Slack: sử dụng Incoming webhooks hoặc Bot tokens.
  • Nếu sử dụng Incoming webhooks, thì api_url phải được đặt thành URL của Incoming webhook, hoặc được viết vào file được tham chiếu trong api_url_file.
  • Nếu sử dụng Bot tokens, thì api_url phải được đặt thành https://slack.com/api/chat.postMessage, và bot token phải được đặt làm thông tin xác thực trong http_config. Thêm vào đó, trường channel phải chứa tên của kênh hoặc ID của kênh mà thông báo sẽ được gửi đến. Nếu sử dụng tên của kênh, thì dấu # có thể được bỏ qua.

Thông báo Slack thường chứa một phần đính kèm (attachment) để cung cấp thông tin chi tiết và hữu ích cho người nhận.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = false ]

# The Slack webhook URL. Either api_url or api_url_file should be set.
# Defaults to global settings if none are set here.
[ api_url: <secret> | default = global.slack_api_url ]
[ api_url_file: <filepath> | default = global.slack_api_url_file ]

# The channel or user to send notifications to.
channel: <tmpl_string>

# API request data as defined by the Slack webhook API.
[ icon_emoji: <tmpl_string> ]
[ icon_url: <tmpl_string> ]
[ link_names: <boolean> | default = false ]
[ username: <tmpl_string> | default = '{{ template "slack.default.username" . }}' ]
# The following parameters define the attachment.
actions:
  [ <action_config> ... ]
[ callback_id: <tmpl_string> | default = '{{ template "slack.default.callbackid" . }}' ]
[ color: <tmpl_string> | default = '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}' ]
[ fallback: <tmpl_string> | default = '{{ template "slack.default.fallback" . }}' ]
fields:
  [ <field_config> ... ]
[ footer: <tmpl_string> | default = '{{ template "slack.default.footer" . }}' ]
[ mrkdwn_in: '[' <string>, ... ']' | default = ["fallback", "pretext", "text"] ]
[ pretext: <tmpl_string> | default = '{{ template "slack.default.pretext" . }}' ]
[ short_fields: <boolean> | default = false ]
[ text: <tmpl_string> | default = '{{ template "slack.default.text" . }}' ]
[ title: <tmpl_string> | default = '{{ template "slack.default.title" . }}' ]
[ title_link: <tmpl_string> | default = '{{ template "slack.default.titlelink" . }}' ]
[ image_url: <tmpl_string> ]
[ thumb_url: <tmpl_string> ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách cấu hình tích hợp Slack trong cấu hình Alertmanager:

receivers:
  - name: 'slack'
    slack_configs:
      api_url: 'https://hooks.slack.com/services/your/webhook/url'
      channel: '#general'

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘slack’.
• Trong slack_configs, bạn cần cung cấp hai thông tin quan trọng:
  • api_url: Đây là URL webhook của Slack, được sử dụng để gửi thông báo đến kênh Slack. Bạn cần tạo một webhook trên Slack và lấy URL từ đó.
  • channel: Đây là tên kênh Slack mà bạn muốn gửi cảnh báo đến.

Sau khi bạn đã cấu hình người nhận Slack này, bạn có thể sử dụng nó trong các quy tắc định tuyến để gửi cảnh báo đến kênh Slack của nhóm làm việc khi xảy ra sự cố trong hệ thống giám sát của bạn.

Định nghĩa các hành động cụ thể mà bạn muốn thực hiện khi xảy ra sự cố hoặc sự kiện cảnh báo.

Trong cấu hình Alertmanager, action_config là một tính năng cho phép bạn định nghĩa các hành động cụ thể mà bạn muốn thực hiện khi xảy ra sự cố hoặc sự kiện cảnh báo. Các hành động này có thể là việc gửi thông báo, thực hiện các tác vụ tự động, hoặc thậm chí là gọi các dịch vụ hoặc tích hợp ngoại vi khác.

<action_config> cho phép cấu hình các hành động (actions) được thực hiện trong thông báo Slack. Các trường (fields) trong <action_config> thường được mô tả trong tài liệu API của Slack cho việc xây dựng thông báo chứa phần đính kèm (attachment) và các tin nhắn tương tác (interactive messages) trong Slack. Hành động có thể là các liên kết, nút nhấn, hoặc các tương tác tùy chỉnh khác mà người nhận có thể thực hiện để tương tác với thông báo. Các hành động này có thể thực hiện các tác vụ như xử lý cảnh báo hoặc chuyển hướng người dùng đến các trang web hay ứng dụng khác.

text: <tmpl_string>
type: <tmpl_string>
# Either url or name and value are mandatory.
[ url: <tmpl_string> ]
[ name: <tmpl_string> ]
[ value: <tmpl_string> ]

[ confirm: <action_confirm_field_config> ]
[ style: <tmpl_string> | default = '' ]

Dưới đây là một ví dụ đơn giản về cách sử dụng action_config trong cấu hình Alertmanager:

route:
  receiver: 'slack'

receivers:
  - name: 'slack'
    slack_configs:
      api_url: 'https://hooks.slack.com/services/your/webhook/url'
      channel: '#general'

Trong ví dụ này:

• Chúng ta đã định nghĩa một quy tắc định tuyến trong phần route. Quy tắc này chỉ định rằng khi một cảnh báo phù hợp với nó, nó sẽ gửi cảnh báo đến người nhận có tên là ‘slack’.
• Trong phần receivers, chúng ta đã định nghĩa một người nhận có tên là ‘slack’ với cấu hình Slack cụ thể.

Khi một cảnh báo phù hợp với quy tắc định tuyến này, nó sẽ được gửi đến kênh Slack được xác định trong cấu hình người nhận ‘slack’.

action_config cho phép bạn thực hiện nhiều hành động phức tạp hơn, bao gồm việc gửi thông báo đến nhiều người nhận, thực hiện các tác vụ tự động như thay đổi trạng thái hoặc triển khai xử lý sự cố, và tích hợp với nhiều dịch vụ và nền tảng khác để quản lý cảnh báo một cách hiệu quả.

Cấu hình xác nhận hành động.

Trong cấu hình Alertmanager, action_confirm_field_config là một tính năng cho phép bạn định nghĩa các trường cần xác nhận khi thực hiện các hành động cụ thể, ví dụ như xác nhận hoặc từ chối một cảnh báo. Điều này hữu ích khi bạn muốn đảm bảo rằng người dùng đã thực hiện một tác vụ nhất định trước khi hành động được thực hiện hoặc tránh xử lý cảnh báo một cách vô tình.

<action_confirm_field_config> cho phép cấu hình xác nhận (confirm) cho hành động. Các trường (fields) trong <action_confirm_field_config> được mô tả trong tài liệu API của Slack.

• text: <tmpl_string>: Chứa văn bản hoặc chuỗi mẫu (template) cho xác nhận hành động.
• dismiss_text: <tmpl_string> | default '': Văn bản cho tùy chọn “Từ chối” trong xác nhận. (Tuỳ chọn)
• ok_text: <tmpl_string> | default '': Văn bản cho tùy chọn “Đồng ý” trong xác nhận. (Tuỳ chọn)
• title: <tmpl_string> | default '': Tiêu đề cho xác nhận. (Tuỳ chọn)

text: <tmpl_string>
[ dismiss_text: <tmpl_string> | default '' ]
[ ok_text: <tmpl_string> | default '' ]
[ title: <tmpl_string> | default '' ]

Dưới đây là một ví dụ đơn giản về cách sử dụng action_confirm_field_config trong cấu hình Alertmanager:

route:
  receiver: 'slack'

receivers:
  - name: 'slack'
    slack_configs:
      api_url: 'https://hooks.slack.com/services/your/webhook/url'
      channel: '#general'

  - name: 'email'
    email_configs:
      to: 'your@email.com'

actions:
  - name: 'confirm'
    confirm_field:
      label: 'Confirm Action'
      description: 'Please confirm that you want to proceed.'
      required: true

Trong ví dụ này:

• Chúng ta đã định nghĩa một quy tắc định tuyến trong phần route. Quy tắc này chỉ định rằng khi một cảnh báo phù hợp với nó, nó sẽ gửi cảnh báo đến người nhận có tên là ‘slack’.
• Trong phần receivers, chúng ta đã định nghĩa hai người nhận khác nhau, một cho Slack và một cho Email.
• Dưới phần actions, chúng ta đã định nghĩa một hành động có tên là ‘confirm’ và xác định trường xác nhận bằng cách sử dụng confirm_field_config. Trường xác nhận này có một nhãn (label), mô tả (description), và yêu cầu xác nhận (required). Khi hành động ‘confirm’ được kích hoạt, người dùng cần phải xác nhận việc thực hiện hành động này trước khi nó được thực hiện.

Các action_confirm_field_config cho phép bạn tùy chỉnh cách xác nhận được thực hiện và đảm bảo tính chính xác của các hành động quan trọng trong quản lý cảnh báo.

Định nghĩa cách tùy chỉnh các trường (fields) trong cảnh báo.

Trong cấu hình Alertmanager, field_config là một tính năng cho phép bạn định nghĩa cách tùy chỉnh các trường (fields) trong các cảnh báo, đặc biệt là trường mô tả (annotations) và trường nhãn (labels). Điều này giúp bạn hiển thị thông tin quan trọng và tùy chỉnh giao diện người dùng hoặc định dạng cảnh báo theo ý muốn.

• <field_config> cho phép cấu hình các trường (fields) liên quan đến thông báo Slack. Các trường (fields) trong <field_config> được mô tả trong tài liệu API của Slack.
  • title: <tmpl_string>: Tiêu đề của trường.
  • value: <tmpl_string>: Giá trị của trường.
  • short: <boolean> | default = slack_config.short_fields: Xác định xem trường có độ dài ngắn hay không. (Tuỳ chọn)

title: <tmpl_string>
value: <tmpl_string>
[ short: <boolean> | default = slack_config.short_fields ]

Dưới đây là một ví dụ đơn giản về cách sử dụng field_config trong cấu hình Alertmanager:

route:
  receiver: 'slack'

receivers:
  - name: 'slack'
    slack_configs:
      api_url: 'https://hooks.slack.com/services/your/webhook/url'
      channel: '#general'

templates:
  - '/etc/alertmanager/templates/*.tmpl'

# Cấu hình field_config để tùy chỉnh mô tả của cảnh báo
field_configs:
  - label: 'severity'
    description: 'Mức độ nghiêm trọng'
    path: 'annotations.severity'

  - label: 'custom_label'
    description: 'Trường nhãn tùy chỉnh'
    path: 'labels.custom_label'

Trong ví dụ này:

• Chúng ta đã định nghĩa một quy tắc định tuyến trong phần route. Quy tắc này chỉ định rằng khi một cảnh báo phù hợp với nó, nó sẽ gửi cảnh báo đến người nhận có tên là ‘slack’.
• Trong phần receivers, chúng ta đã định nghĩa một người nhận cho Slack.
• Phần templates cho phép bạn chỉ định các mẫu tùy chỉnh cho cảnh báo.
• Dưới phần field_configs, chúng ta đã định nghĩa hai field_config. Một field_config là cho trường severity trong trường mô tả (annotations) của cảnh báo, và một field_config khác là cho trường custom_label trong trường nhãn (labels) của cảnh báo. Mỗi field_config bao gồm nhãn (label), mô tả (description), và đường dẫn (path) đến trường tương ứng trong cảnh báo.

Ví dụ trên cho phép bạn tùy chỉnh mô tả và hiển thị các trường cụ thể trong cảnh báo khi nó được gửi đến người nhận Slack. Bạn có thể sử dụng tính năng field_config để tạo các trường tùy chỉnh khác và điều chỉnh hiển thị cảnh báo theo nhu cầu của bạn.

Cấu hình kết nối và tùy chỉnh thông báo đến Amazon Simple Notification Service (SNS).

Trong cấu hình Alertmanager, sns_config là một tính năng cho phép bạn định cấu hình kết nối và tùy chỉnh thông báo đến Amazon Simple Notification Service (SNS). Amazon SNS là một dịch vụ quản lý thông báo của Amazon Web Services (AWS), cho phép bạn gửi thông báo đến nhiều nguồn khác nhau, chẳng hạn như email, SMS, HTTP endpoints, và nhiều dịch vụ khác.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The SNS API URL i.e. https://sns.us-east-2.amazonaws.com.
#  If not specified, the SNS API URL from the SNS SDK will be used.
[ api_url: <tmpl_string> ]

# Configures AWS's Signature Verification 4 signing process to sign requests.
sigv4:
  [ <sigv4_config> ]

# SNS topic ARN, i.e. arn:aws:sns:us-east-2:698519295917:My-Topic
# If you don't specify this value, you must specify a value for the phone_number or target_arn.
# If you are using a FIFO SNS topic you should set a message group interval longer than 5 minutes
# to prevent messages with the same group key being deduplicated by the SNS default deduplication window
[ topic_arn: <tmpl_string> ]

# Subject line when the message is delivered to email endpoints.
[ subject: <tmpl_string> | default = '{{ template "sns.default.subject" .}}' ]

# Phone number if message is delivered via SMS in E.164 format.
# If you don't specify this value, you must specify a value for the topic_arn or target_arn.
[ phone_number: <tmpl_string> ]

# The  mobile platform endpoint ARN if message is delivered via mobile notifications.
# If you don't specify this value, you must specify a value for the topic_arn or phone_number.
[ target_arn: <tmpl_string> ]

# The message content of the SNS notification.
[ message: <tmpl_string> | default = '{{ template "sns.default.message" .}}' ]

# SNS message attributes.
attributes:
  [ <string>: <string> ... ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách sử dụng sns_config trong cấu hình Alertmanager:

route:
  receiver: 'sns'

receivers:
  - name: 'sns'
    sns_configs:
      topic_arn: 'arn:aws:sns:us-east-1:123456789012:MyTopic'
      access_key: 'your-access-key'
      secret_key: 'your-secret-key'
      region: 'us-east-1'
      max_retries: 3
      http_proxy: 'http://your-proxy-server:8080'
      http_proxy_credentials: 'proxy-username:proxy-password'

Trong ví dụ này:

• Chúng ta đã định nghĩa một quy tắc định tuyến trong phần route. Quy tắc này chỉ định rằng khi một cảnh báo phù hợp với nó, nó sẽ gửi cảnh báo đến người nhận có tên là ‘sns’.
• Trong phần receivers, chúng ta đã định nghĩa một người nhận cho Amazon SNS.
• Phần sns_configs chứa các cấu hình liên quan đến Amazon SNS:
  • topic_arn: ARN (Amazon Resource Name) của chủ đề SNS mà bạn muốn gửi cảnh báo đến.
  • access_key và secret_key: Mã truy cập và mã bí mật AWS IAM để xác thực vào AWS.
  • region: Khu vực AWS mà bạn đang sử dụng.
  • max_retries: Số lần thử lại tối đa khi gửi thông báo thất bại.
  • http_proxy và http_proxy_credentials: Cấu hình proxy HTTP (nếu cần).

Với cấu hình này, khi một cảnh báo phù hợp với quy tắc định tuyến, Alertmanager sẽ gửi thông báo đến chủ đề SNS được chỉ định, sử dụng các thông tin xác thực và cấu hình được định nghĩa trong sns_configs.

Cấu hình xác thực AWS Signature Version 4 (SigV4) cho các yêu cầu HTTP.

Trong cấu hình Alertmanager, sigv4_config là một tính năng cho phép bạn định cấu hình xác thực AWS Signature Version 4 (SigV4) cho các yêu cầu HTTP gửi từ Alertmanager. AWS SigV4 là một phương thức xác thực được sử dụng trong Amazon Web Services (AWS) để đảm bảo tính bảo mật và xác thực của các yêu cầu HTTP.

# The AWS region. If blank, the region from the default credentials chain is used.
[ region: <string> ]

# The AWS API keys. Both access_key and secret_key must be supplied or both must be blank.
# If blank the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are used.
[ access_key: <string> ]
[ secret_key: <secret> ]

# Named AWS profile used to authenticate.
[ profile: <string> ]

# AWS Role ARN, an alternative to using AWS API keys.
[ role_arn: <string> ]

Dưới đây là một ví dụ về cách sử dụng sigv4_config trong cấu hình Alertmanager:

route:
  receiver: 'aws-sns'

receivers:
  - name: 'aws-sns'
    sns_configs:
      topic_arn: 'arn:aws:sns:us-east-1:123456789012:MyTopic'
      sigv4_config:
        access_key: 'your-access-key'
        secret_key: 'your-secret-key'
        region: 'us-east-1'

Trong ví dụ này:

• Chúng ta đã định nghĩa một quy tắc định tuyến trong phần route. Quy tắc này chỉ định rằng khi một cảnh báo phù hợp với nó, nó sẽ gửi cảnh báo đến người nhận có tên là ‘aws-sns’.
• Trong phần receivers, chúng ta đã định nghĩa một người nhận cho Amazon SNS.
• Phần sns_configs chứa các cấu hình liên quan đến Amazon SNS, giống như trong ví dụ trước đó.
• Bên trong sns_configs, chúng ta đã sử dụng sigv4_config để cấu hình xác thực SigV4:
  • access_key và secret_key: Mã truy cập và mã bí mật AWS IAM để xác thực vào AWS.
  • region: Khu vực AWS mà bạn đang sử dụng.

Với cấu hình này, khi một cảnh báo phù hợp với quy tắc định tuyến, Alertmanager sẽ gửi thông báo đến chủ đề SNS được chỉ định, sử dụng xác thực SigV4 với các thông tin xác thực và cấu hình được định nghĩa trong sigv4_config.

Cấu hình thông báo qua Telegram.

Trong cấu hình Alertmanager, telegram_config là một tính năng cho phép bạn định cấu hình thông báo qua Telegram. Telegram là một ứng dụng nhắn tin và gọi điện thoại di động phổ biến.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The Telegram API URL i.e. https://api.telegram.org.
# If not specified, default API URL will be used.
[ api_url: <string> | default = global.telegram_api_url ]

# Telegram bot token. It is mutually exclusive with `bot_token_file`.
[ bot_token: <secret> ]

# Read the Telegram bot token from a file. It is mutually exclusive with `bot_token`.
[ bot_token_file: <filepath> ]

# ID of the chat where to send the messages.
[ chat_id: <int> ]

# Message template.
[ message: <tmpl_string> default = '{{ template "telegram.default.message" .}}' ]

# Disable telegram notifications
[ disable_notifications: <boolean> | default = false ]

# Parse mode for telegram message, supported values are MarkdownV2, Markdown, HTML and empty string for plain text.
[ parse_mode: <string> | default = "HTML" ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách sử dụng telegram_config trong cấu hình Alertmanager:

receivers:
  - name: 'telegram'
    telegram_configs:
      api_url: 'https://api.telegram.org'
      chat_id: '@your_channel_name'
      token: 'your_telegram_bot_token'

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘telegram’ trong phần receivers.
• Phần telegram_configs chứa các cấu hình liên quan đến thông báo qua Telegram:
  • api_url: Đây là URL của API Telegram mà Alertmanager sẽ sử dụng để gửi tin nhắn. Thường thì bạn sẽ sử dụng URL mặc định của Telegram.
  • chat_id: Đây là ID của kênh hoặc nhóm Telegram mà bạn muốn gửi thông báo đến. Bạn cũng có thể sử dụng chat ID của một người dùng riêng lẻ.
  • token: Đây là mã thông báo (token) của bot Telegram mà bạn đã tạo trước đó. Bạn cần tạo một bot Telegram và lấy mã thông báo từ BotFather để sử dụng trong cấu hình này.

Khi một cảnh báo phù hợp với người nhận ‘telegram’, Alertmanager sẽ gửi một tin nhắn đến kênh hoặc nhóm Telegram được chỉ định, sử dụng các thông tin cấu hình như api_url, chat_id, và token. Tin nhắn này có thể bao gồm thông tin về cảnh báo như tên cảnh báo, mức độ, và nội dung cảnh báo.

<victorops_config>

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The API key to use when talking to the VictorOps API.
# It is mutually exclusive with `api_key_file`.
[ api_key: <secret> | default = global.victorops_api_key ]

# Reads the API key to use when talking to the VictorOps API from a file.
# It is mutually exclusive with `api_key`.
[ api_key_file: <filepath> | default = global.victorops_api_key_file ]

# The VictorOps API URL.
[ api_url: <string> | default = global.victorops_api_url ]

# A key used to map the alert to a team.
routing_key: <tmpl_string>

# Describes the behavior of the alert (CRITICAL, WARNING, INFO).
[ message_type: <tmpl_string> | default = 'CRITICAL' ]

# Contains summary of the alerted problem.
[ entity_display_name: <tmpl_string> | default = '{{ template "victorops.default.entity_display_name" . }}' ]

# Contains long explanation of the alerted problem.
[ state_message: <tmpl_string> | default = '{{ template "victorops.default.state_message" . }}' ]

# The monitoring tool the state message is from.
[ monitoring_tool: <tmpl_string> | default = '{{ template "victorops.default.monitoring_tool" . }}' ]

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

Cấu hình thông báo thông qua webhook.

Trong cấu hình Alertmanager, webhook_config là tính năng cho phép bạn định cấu hình thông báo thông qua webhook. Webhook là một cách để gửi thông tin từ một ứng dụng này đến ứng dụng khác thông qua HTTP POST requests.

Điều này cho phép tích hợp Alertmanager với bất kỳ dịch vụ nào hỗ trợ tích hợp thông qua webhook để gửi thông báo và cảnh báo. Cấu hình webhook thường bao gồm các thông tin như địa chỉ URL của webhook, cùng với các tùy chọn khác để định dạng dữ liệu được gửi qua webhook.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The endpoint to send HTTP POST requests to.
# url and url_file are mutually exclusive.
url: <secret>
url_file: <filepath>

# The HTTP client's configuration.
[ http_config: <http_config> | default = global.http_config ]

# The maximum number of alerts to include in a single webhook message. Alerts
# above this threshold are truncated. When leaving this at its default value of
# 0, all alerts are included.
[ max_alerts: <int> | default = 0 ]

Alertmanager gửi các HTTP POST requests đến điểm cuối (endpoint) được cấu hình theo định dạng JSON sau:

{
  "version": "4",
  "groupKey": <string>,              // key identifying the group of alerts (e.g. to deduplicate)
  "truncatedAlerts": <int>,          // how many alerts have been truncated due to "max_alerts"
  "status": "<resolved|firing>",
  "receiver": <string>,
  "groupLabels": <object>,
  "commonLabels": <object>,
  "commonAnnotations": <object>,
  "externalURL": <string>,           // backlink to the Alertmanager.
  "alerts": [
    {
      "status": "<resolved|firing>",
      "labels": <object>,
      "annotations": <object>,
      "startsAt": "<rfc3339>",
      "endsAt": "<rfc3339>",
      "generatorURL": <string>,      // identifies the entity that caused the alert
      "fingerprint": <string>        // fingerprint to identify the alert
    },
    ...
  ]
}

Trong đó:

• "version": Phiên bản của định dạng JSON.
• "groupKey": Một chuỗi đại diện cho khóa nhóm của thông báo.
• "status": Trạng thái của thông báo, ví dụ: “firing” hoặc “resolved”.
• "receiver": Tên của người nhận (receiver) được sử dụng cho thông báo.
• "groupLabels": Một danh sách các cặp key-value cho các nhãn (labels) của nhóm.
• "commonLabels": Một danh sách các cặp key-value cho các nhãn (labels) chung của thông báo.
• "commonAnnotations": Một danh sách các cặp key-value cho các chú thích (annotations) chung của thông báo.
• "externalURL": Đường dẫn URL bên ngoài liên quan đến thông báo.
• "alerts": Danh sách các thông báo cá nhân, mỗi thông báo có dạng:
  • "labels": Một danh sách các cặp key-value cho các nhãn (labels) của thông báo.
  • "annotations": Một danh sách các cặp key-value cho các chú thích (annotations) của thông báo.
  • "startsAt": Thời gian bắt đầu của thông báo.
  • "endsAt": Thời gian kết thúc của thông báo.
  • "generatorURL": Đường dẫn URL đến nguồn tạo ra thông báo.

Thông tin này sẽ được gửi qua HTTP POST request để thông báo và xử lý bởi điểm cuối (endpoint) được cấu hình.

Dưới đây là một ví dụ về cách sử dụng webhook_config trong cấu hình Alertmanager:

receivers:
  - name: 'webhook'
    webhook_configs:
      - url: 'https://your-webhook-url.com'
        http_config:
          basic_auth:
            username: 'your_username'
            password: 'your_password'
        send_resolved: true

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘webhook’ trong phần receivers.
• Phần webhook_configs chứa các cấu hình liên quan đến thông báo qua webhook:
  • url: Đây là URL của webhook mà Alertmanager sẽ sử dụng để gửi thông báo. Bạn cần cung cấp URL của máy chủ hoặc dịch vụ chấp nhận các HTTP POST requests để nhận thông báo từ Alertmanager.
  • http_config: Bạn có thể cấu hình các tùy chọn HTTP cho webhook như xác thực HTTP cơ bản (basic auth) bằng cách đưa tên người dùng và mật khẩu.
  • send_resolved: Nếu send_resolved được đặt thành true, Alertmanager sẽ gửi cảnh báo giải quyết (resolved) thông qua webhook khi một cảnh báo được giải quyết. Nếu bạn không muốn gửi cảnh báo giải quyết, bạn có thể đặt giá trị này thành false.

Khi một cảnh báo phù hợp với người nhận ‘webhook’, Alertmanager sẽ gửi một HTTP POST request chứa thông tin cảnh báo đến URL webhook được chỉ định, sử dụng các thông tin cấu hình như url, http_config, và send_resolved. Bạn có thể tùy chỉnh máy chủ hoặc dịch vụ webhook để xử lý và hiển thị thông báo theo cách mong muốn.

Cấu hình thông báo qua WeChat.

wechat_config trong cấu hình Alertmanager là tính năng cho phép bạn định cấu hình thông báo qua WeChat, một ứng dụng nhắn tin và trò chuyện phổ biến tại Trung Quốc.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = false ]

# The API key to use when talking to the WeChat API.
[ api_secret: <secret> | default = global.wechat_api_secret ]

# The WeChat API URL.
[ api_url: <string> | default = global.wechat_api_url ]

# The corp id for authentication.
[ corp_id: <string> | default = global.wechat_api_corp_id ]

# API request data as defined by the WeChat API.
[ message: <tmpl_string> | default = '{{ template "wechat.default.message" . }}' ]
# Type of the message type, supported values are `text` and `markdown`.
[ message_type: <string> | default = 'text' ]
[ agent_id: <string> | default = '{{ template "wechat.default.agent_id" . }}' ]
[ to_user: <string> | default = '{{ template "wechat.default.to_user" . }}' ]
[ to_party: <string> | default = '{{ template "wechat.default.to_party" . }}' ]
[ to_tag: <string> | default = '{{ template "wechat.default.to_tag" . }}' ]

Dưới đây là một ví dụ về cách sử dụng wechat_config trong cấu hình Alertmanager:

receivers:
  - name: 'wechat'
    wechat_configs:
      - api_url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=your_api_key'
        send_resolved: true

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘wechat’ trong phần receivers.
• Phần wechat_configs chứa các cấu hình liên quan đến thông báo qua WeChat:
  • api_url: Đây là URL của dịch vụ WeChat Work (tương tự WeChat for Business) mà Alertmanager sẽ sử dụng để gửi thông báo. Bạn cần cung cấp URL này và API key tương ứng để cho phép Alertmanager gửi tin nhắn WeChat.
  • send_resolved: Nếu send_resolved được đặt thành true, Alertmanager sẽ gửi cảnh báo giải quyết (resolved) thông qua WeChat khi một cảnh báo được giải quyết. Nếu bạn không muốn gửi cảnh báo giải quyết, bạn có thể đặt giá trị này thành false.

Khi một cảnh báo phù hợp với người nhận ‘wechat’, Alertmanager sẽ gửi tin nhắn thông báo tới WeChat Work thông qua API được chỉ định trong api_url, sử dụng các thông tin cấu hình như api_url và send_resolved. Bạn cần đảm bảo rằng bạn đã cấu hình đúng API key và một ứng dụng WeChat Work hoặc WeChat for Business để nhận thông báo từ Alertmanager.

Cấu hình thông báo qua Webex Teams.

webex_config trong cấu hình Alertmanager là tính năng cho phép bạn định cấu hình thông báo qua Webex Teams, một ứng dụng trò chuyện và hợp tác dựa trên đám mây.

# Whether to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]

# The Webex Teams API URL i.e. https://webexapis.com/v1/messages
# If not specified, default API URL will be used.
[ api_url: <string> | default = global.webex_api_url ]

# ID of the Webex Teams room where to send the messages.
room_id: <string>

# Message template.
[ message: <tmpl_string> default = '{{ template "webex.default.message" .}}' ]

# The HTTP client's configuration. You must use this configuration to supply the bot token as part of the HTTP `Authorization` header. 
[ http_config: <http_config> | default = global.http_config ]

Dưới đây là một ví dụ về cách sử dụng webex_config trong cấu hình Alertmanager:

receivers:
  - name: 'webex'
    webex_configs:
      - api_url: 'https://api.ciscospark.com/v1/messages'
        room_id: 'your_room_id'
        bearer_token: 'your_bearer_token'
        send_resolved: true

Trong ví dụ này:

• Chúng ta đã định nghĩa một người nhận có tên là ‘webex’ trong phần receivers.
• Phần webex_configs chứa các cấu hình liên quan đến thông báo qua Webex Teams:
  • api_url: Đây là URL của dịch vụ Webex Teams API mà Alertmanager sẽ sử dụng để gửi thông báo. Bạn cần cung cấp URL này và một mã thông báo truy cập (bearer token) để cho phép Alertmanager gửi tin nhắn tới Webex Teams.
  • room_id: Đây là mã nhóm hoặc mã phòng trong Webex Teams. Tin nhắn từ Alertmanager sẽ được gửi tới phòng này.
  • bearer_token: Đây là mã thông báo truy cập (bearer token) để xác thực với dịch vụ Webex Teams API. Đảm bảo rằng bạn đã cung cấp mã thông báo hợp lệ để cho phép gửi tin nhắn.
  • send_resolved: Nếu send_resolved được đặt thành true, Alertmanager sẽ gửi cảnh báo giải quyết (resolved) thông qua Webex Teams khi một cảnh báo được giải quyết. Nếu bạn không muốn gửi cảnh báo giải quyết, bạn có thể đặt giá trị này thành false.

Khi một cảnh báo phù hợp với người nhận ‘webex’, Alertmanager sẽ gửi tin nhắn tới phòng được chỉ định trong room_id của Webex Teams, sử dụng các thông tin cấu hình như api_url, bearer_token, và send_resolved. Bạn cần đảm bảo rằng bạn đã cung cấp thông tin xác thực và phòng Webex Teams đúng để nhận thông báo từ Alertmanager.