Trong khi chúng ta tập trung vào việc cấu hình giám sát(monitor) cho một hệ thống làm sao cho sát và bao quát được nhiều phần nhất trong hệ sinh thái của mình thì việc cảnh báo khi các giá trị thu được từ công cụ giám sát có sự không ổn định cũng là một việc làm cần được bạn chú ý. Như chúng ta đều biết, bộ công cụ Prometheus và Grafana rất hữu dụng trong việc giám sát các hệ thống K8s. Trong bài viết này, Stringee sẽ chia sẻ cho các bạn cách cấu hình rule cảnh báo và gửi thông báo cho các admin của hệ thống nhé.

1. Alert manager

Alert manager trong kubernetes là một công cụ tự động gửi các alerts thông qua các dịch vụ khác nhau như email, slack, teams hay webhook. Alert manager được tích hợp trong Prometheus để có thể gửi đi các cảnh báo từ ứng dụng giám sát này.

Luồng giám sát có thể được mô tả lại như sau:

  • Prometheus lấy thông tin metric từ các đối tượng cần giám sát và lưu vào time series database của nó

  • Prometheus đọc các rule để quyết định những rule nào cần cảnh báo để gửi cho Alert manager. Chúng ta có thể cấu hình được rule cho Prometheus bằng 2 cách:

  • Cấu hình trực tiếp vào file value helm của stack với giá trị: additionalPrometheusRules.

Ví dụ:

additionalPrometheusRules:
- name: my-rule-file
groups:
  - name: my_group
    rules:
    - record: my_record
      expr: 100 * my_record
  • Sử dụng đối tượng PrometheusRule để khai báo rule cho service. Chúng ta sẽ cần cấu hình tham số ruleNamespaceSelector và ruleSelector chỉ định các Prometheus đọc các PrometheusRule của K8s.
  • Alert Manager sẽ có config riêng của nó để thực hiện phân luồng các cảnh báo gửi tới người dùng, điều này được gọi là route. Người nhận ở đây được gọi là receiver được cấu hình ở Alert Manager với nhiều loại được hỗ trợ như email, slack, Telegram, ...

2. Cấu hình Rule trực tiếp vào helm-value cho alert manager

Là cách 1 đề cập bên trên, các bạn sẽ cấu hình trực tiếp các rule và trong cấu hình additionalPrometheusRules. Cách này có thể thực hiện được một cách rất nhanh chóng và dễ dàng, tuy nhiên nó lại gây ra nhiều vấn đề mà bạn có thể sẽ phải đau đầu suy nghĩ cách xử lý:

  • Khi số lượng rule lớn, file helm-value sẽ trở nên rất lớn, cồng kềnh và khó quản lý

  • Mỗi khi cần tạo thêm rule lại phải update lại file helm-value này và update lại stack (bằng lệnh helm-upgrade)

  • Khó troubleshoot khi cấu hình bị sai lỗi cú pháp sẽ không update dc vào Prometheus sẽ tốn công debug

3. Sử dụng Prometheus Rule để cấu hình rule

Trước tiên, chúng ta cần hiểu được ý tưởng của cách thực hiện này. Chúng ta sẽ thực hiện như sau:

  • Cấu hình cho Prometheus đọc các PrometheusRule ở các namespace nhất định và phải khớp với một số label nhất định

  • Với mỗi service cần khai báo rule, chúng ta sẽ tạo 1 file Rule riêng có 2 phần quan trọng:

  • Label cần match với ruleSelector đã cấu hình để đảm bảo nó sẽ được load vào cấu hình rule của Prometheus
  • Các cấu hình rule cảnh báo của service (là các biểu thức so sánh các metric với các tham số ngưỡng để sinh cảnh báo)

Xem thêm bài viết:

- Hướng dẫn cài đặt Web server Apache trên CentOS 7

- Cài đặt cấu hình cân bằng tải với HaProxy và Docker

- Tìm hiểu về ràng buộc (Constraint) trong SQL

3.1. Cấu hình ruleSelector cho Prometheus

Chúng ta sẽ cần cấu hình 2 tham số:

  • ruleNamespaceSelector: Để chỉ định sẽ đọc các PrometheusRule ở những namespace nào. Nếu muốn đọc từ tất cả namespace nên để giá trị này là mặc định

  • ruleSelector: Là cấu hình cách filter các đối tượng PrometheusRule sẽ được load vào Prometheus. Ở đây chúng ta sẽ dùng cách là filter theo label và đọc tất cả các PrometheusRule có gán label có key app và có giá trị trong các giá trị sau: "prometheus-stack", "prometheus-rule".

Và cứ như vậy, chúng ta sẽ cấu hình được 1 file value helm có giá trị cấu hình như sau:

ruleNamespaceSelector: {}

ruleSelector:
      matchExpressions:
      - key: app
        operator: In
        values:
          - prometheus-rule
          - prometheus-stack

Tới đây, bạn cần install lại service này bằng lệnh helm để chấp nhận các thay đổi. Sau khi dịch vụ được khởi động lại, Prometheus sẽ hiểu là nó cần đọc các đối tượng PrometheusRule ở tất cả các namespace và pod được đọc sẽ có gắn label "app=prometheus-stack" hoặc "app=prometheus-rule"

3.2. Khai báo PrometheusRule

Khi khai báo một PrometheusRule mới thì cái đầu tiên mình quan tâm là phải khai báo label match với cấu hình ruleSelector của Prometheus, cụ thể trong trường hợp này cần gán label là "app=prometheus-rule"

Chúng ta có thể tạo một file monitor-alert-rule.yaml có nội dung như sau:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    app: prometheus-rule
    role: alert-rules
  name: minio-prometheus-rule

spec:
  groups:
  - name: "minio-rule"
    rules:
    - alert: MinioDiskOffline
      for: 1m # Thời gian đạt điều kiện trước khi sinh cảnh báo.
      expr: minio_cluster_nodes_offline_total != 1 # Điều kiện so sánh để sinh cảnh báo
      annotations:
        message: Disk offline

4. Cấu hình Alert Manager

Như đã phân tích ở trên, chúng ta sẽ cần cấu hình route và receiver. Đây là 2 thành phần chính của Alert Manager, route sẽ làm nhiệm vụ điều hướng và phân tích các cảnh báo theo label để chuyển hướng tới các receiver khác nhau.

Trong bài viết này, chúng ta sẽ tìm hiểu cách cấu hình một alertmanager gửi tin nhắn tới một webhook khi có rule bị vi phạm nhé:

Đầu tiên, chúng ta sẽ tạo 1 file values.yaml có dạng như sau:

alertmanager:
  config:
    global:
      resolve_timeout: 5m
    route:
      group_by: ['alertname', "namespace"]
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 3h
      receiver: 'servicenow'
      routes:
      - match:
          alertname: Watchdog
        receiver: 'null'
      - match:
          alertname: TargetDown
        receiver: 'servicenow'
    receivers:
    - name: 'servicenow'
      webhook_configs:
      - url: "http://alertmanager-webhook-servicenow.monitoring.svc.cluster.local/webhook"
        send_resolved: true
    - name: 'null'

Trong cấu hình này ta gửi alert vào receiver ‘servicenow’, tùy chọn có thể gửi tới nhiều receiver khác nữa, như ví dụ trên ta sẽ bỏ qua các alert Watchdog (vì các alert này dành cho việc checking xem hệ thống alert có hoạt động không, có thể tạm bỏ qua ở đây) còn tất cả alert còn lại sẽ gửi tới servicenow.

Kết

Trên đây là bài viết chia sẻ tới các bạn các kiến thức về Alert manager trong một hệ thống k8s đến từ Stringee. Các bạn có thể tìm hiểu thêm về cách đẩy cảnh báo qua các kênh khác như telegram, msteam... Chúc các bạn thành công!

Stringee Communication APIs là giải pháp cung cấp các tính năng như gọi thoại, gọi video, tin nhắn chat, SMS hay tổng đài chăm sóc khách hàng có thể tích hợp trực tiếp vào các ứng dụng/website của doanh nghiệp nhanh chóng. Bộ giải pháp này giúp tiết kiệm đến 80% thời gian và chi phí cho doanh nghiệp bởi thông thường nếu tự phát triển các tính năng này có thể mất từ 1 - 3 năm.

Mời quý bạn đọc đăng ký dùng thử và nhận tư vấn tại đây: