Định nghĩa Triggers và Actions trong Zabbix Server

Trong bài viết trước – Hướng dẫn thiết lập cảnh báo cơ bản trong Zabbix chúng ta đã tìm hiểu về các thành phần cơ bản của hệ thống cảnh báo và cách cấu hình Media Types (phương thức gửi) cùng User (người nhận). Giờ đây, để hệ thống cảnh báo của bạn thực sự thông minh và tự động, chúng ta cần đi sâu vào việc định nghĩa “khi nào” một vấn đề được phát hiện và “hành động cụ thể gì” sẽ được thực hiện. Đó chính là vai trò của Triggers và Actions.

Tạo Action: Định nghĩa hành động khi có sự cố

Action là thành phần liên kết một Event (phát sinh từ Trigger) với một hoặc nhiều hành động cụ thể (ví dụ: gửi thông báo).

1. Đi đến “Alerts” > “Actions” và chọn “Trigger actions” từ menu phụ.
2. Nhấp vào nút “Create action” ở góc trên bên phải.
3. Sau khi điền xong Template, nhấn “Add” hoặc “Update” để lưu cấu hình.

Tab “Action”

Tab này định nghĩa các điều kiện để Action được thực thi và các thuộc tính chung của Action.

• Name: Đặt tên cho Action (ví dụ: “Gửi cảnh báo Email cho Admin khi CPU cao”).
• Type of calculation: Chọn phương thức đánh giá nếu có nhiều điều kiện:
  • And: Tất cả các điều kiện phải được đáp ứng.
  • Or: Chỉ cần một trong các điều kiện được đáp ứng.
  • And/Or: Kết hợp giữa AND cho các loại điều kiện khác nhau và OR cho cùng loại điều kiện.
  • Custom expression: Công thức tùy chỉnh do người dùng định nghĩa.
• Conditions: Đây là các điều kiện để Action này được kích hoạt. Nhấn “Add” để thêm điều kiện.
  • Điều kiện giúp lọc các Event mà Action sẽ xử lý.
  • Ví dụ phổ biến:
    • Condition type: Trigger severity >= Value: Average (Chỉ kích hoạt nếu mức độ nghiêm trọng từ Average trở lên).
    • Condition type: Host group = Value: Linux servers (Chỉ kích hoạt cho các Host thuộc nhóm “Linux servers”).
    • Condition type: Event is not acknowledged (Chỉ kích hoạt khi sự kiện chưa được xác nhận).
    • Lưu ý: Nếu không cấu hình điều kiện nào, Action sẽ chạy cho mọi sự kiện Trigger.
• Enabled: Đánh dấu ô này để kích hoạt Action.

Tab “Operations”

Phần này định nghĩa những gì sẽ xảy ra khi Action được kích hoạt, bao gồm các hành động chính và các bước leo thang.

• Default operation step duration: Thời lượng mặc định cho một bước hoạt động (ví dụ: 1h cho 1 giờ).
• Operations: Định nghĩa các hành động sẽ được thực hiện khi có sự cố.

1. Nhấn nút “Add” trong khối “Operations” để thêm một hành động mới.

2. Cấu hình chi tiết Operation trong cửa sổ “Operation details”:

• Operation type: Chọn loại hành động. Phổ biến nhất là “Send message” (gửi thông báo). Ngoài ra có thể chọn “Execute remote command” (thực thi lệnh từ xa).
• Steps: Định nghĩa các bước leo thang cảnh báo (ví dụ: 1 - 1 để gửi ngay lập tức chỉ một lần; 1 - 3 với Step duration là 5m để gửi 3 lần cách nhau 5 phút).
• Step duration: Thời lượng tùy chỉnh cho các bước này (0 = sử dụng thời lượng mặc định của Action).
• Send to user groups / Send to users: Chọn nhóm người dùng hoặc người dùng cụ thể sẽ nhận thông báo. Lưu ý: Người dùng/nhóm người dùng phải có quyền đọc đối với host liên quan để nhận thông báo.
• Send to media type: Chọn loại Media mà thông báo sẽ được gửi (ví dụ: Email, Slack, Telegram).
• Custom message: (Tùy chọn) Đánh dấu ô này để định nghĩa tiêu đề và nội dung tin nhắn riêng cho Action này.
  • Subject: Tiêu đề tin nhắn.
  • Message: Nội dung tin nhắn.
  • Bạn có thể sử dụng các macros của Zabbix để hiển thị thông tin động và chi tiết về sự cố (ví dụ: {HOST.NAME}, {ITEM.LASTVALUE}, {EVENT.SEVERITY}, {TRIGGER.NAME}, {TRIGGER.URL}).
• Conditions (cho Operation): (Tùy chọn) Thêm điều kiện cụ thể cho Operation này (ví dụ: Event is not acknowledged để chỉ gửi thông báo nếu sự kiện chưa được xác nhận).

3. Nhấn “Add” để thêm Operation. Bạn có thể thêm nhiều Operation để tạo quy trình leo thang cảnh báo phức tạp hơn (ví dụ: gửi email cho admin sau 5 phút, nếu không phản hồi thì gửi Slack cho đội SRE sau 15 phút).

• Recovery operations: Định nghĩa các hành động sẽ được thực hiện khi sự cố được khắc phục (ví dụ: “Notify all involved” – thông báo cho tất cả những người liên quan rằng sự cố đã được giải quyết).
• Update operations: Định nghĩa các hành động sẽ được thực hiện khi có cập nhật về sự cố (ví dụ: gửi tin nhắn SMS nếu có thay đổi trạng thái hoặc nhận acknowledged).
• Pause operations for symptom problems: Đánh dấu nếu muốn tạm dừng các hoạt động (sau hoạt động đầu tiên) cho các vấn đề triệu chứng.
• Pause operations for suppressed problems: Đánh dấu nếu muốn trì hoãn các hoạt động trong thời gian bảo trì.
• Notify about canceled escalations: Đánh dấu để nhận thông báo khi quá trình leo thang cảnh báo bị hủy (ví dụ: khi host, item, trigger hoặc action bị vô hiệu hóa).
• Sau khi cấu hình xong các tab Action và Operations, nhấn “Add” hoặc “Update” để hoàn tất việc tạo Action.

Tạo Trigger: Định nghĩa điều kiện kích hoạt cảnh báo

Triggers là trái tim của hệ thống cảnh báo, chúng đánh giá dữ liệu từ Item và chuyển trạng thái sang “PROBLEM” khi phát hiện sự cố. Triggers thường được định nghĩa trên Template để áp dụng cho nhiều Host.

1. Đi đến “Data collection” > “Hosts”.
2. Chọn Template mong muốn (ví dụ: “OS Linux by Zabbix agent”).
3. Nhấn vào “Triggers” trong hàng của Template đó.
4. Nhấn nút “Create trigger” ở góc trên bên phải.
5. Sau khi điền xong Template, nhấn “Add” hoặc “Update” để lưu cấu hình.

Tab “Trigger”

Tab này chứa tất cả các thuộc tính thiết yếu của Trigger.

• Name: Tên mô tả của Trigger (ví dụ: “CPU load quá cao trên {HOST.NAME}”). Bạn nên sử dụng các macros như {HOST.NAME} hoặc {ITEM.VALUE} để hiển thị thông tin cụ thể của Host hoặc giá trị item tại thời điểm xảy ra vấn đề.
• Event name: (Tùy chọn) Nếu được định nghĩa, tên này sẽ được sử dụng để tạo tên sự kiện vấn đề thay vì tên Trigger. Nó hữu ích để xây dựng các cảnh báo có ý nghĩa chứa dữ liệu sự cố.
• Operational data: Cho phép định nghĩa các chuỗi tùy ý cùng với macros. Các macros sẽ được giải quyết động thành dữ liệu thời gian thực trong “Monitoring” > “Problems”, cung cấp thông tin mới nhất một cách linh hoạt.
• Severity: Mức độ nghiêm trọng của vấn đề (ví dụ: Not classified, Information, Warning, Average, High, Disaster).
• Expression: Đây là phần quan trọng nhất, định nghĩa điều kiện để Trigger kích hoạt.
  • Nhấn “Add” để mở trình xây dựng biểu thức.
  • Chọn Item mà bạn muốn giám sát (ví dụ: system.cpu.load[percpu,avg1]).
  • Chọn hàm (Function) phù hợp (ví dụ: last() cho giá trị gần nhất, avg() cho giá trị trung bình trong một khoảng thời gian).
  • Chọn toán tử và giá trị (ví dụ: > (lớn hơn), < (nhỏ hơn), =).
  • Ví dụ biểu thức: last(/OS Linux by Zabbix agent/system.cpu.load[percpu,avg1])>2 (Trigger sẽ kích hoạt khi giá trị CPU load trung bình 1 phút trên mỗi nhân của Host vượt quá 2).
• OK event generation: Xác định cách Trigger trở về trạng thái OK.
  • Expression: Sự kiện OK được tạo dựa trên cùng biểu thức với sự kiện PROBLEM.
  • Recovery expression: Sự kiện OK được tạo nếu biểu thức PROBLEM đánh giá là FALSE và biểu thức Recovery đánh giá là TRUE. (Hữu ích cho trigger hysteresis).
  • None: Trigger sẽ không bao giờ tự động trở về trạng thái OK.
• PROBLEM event generation mode: Chế độ tạo sự kiện vấn đề:
  • Single: Một sự kiện duy nhất được tạo khi Trigger chuyển sang trạng thái ‘Problem’ lần đầu tiên.
  • Multiple: Một sự kiện được tạo khi mỗi lần đánh giá Trigger là ‘Problem’.
• OK event closes: Chọn cách sự kiện OK đóng các sự kiện PROBLEM:
  • All problems: Đóng tất cả các vấn đề của Trigger này.
  • All problems if tag values match: Chỉ đóng các vấn đề Trigger có giá trị thẻ sự kiện phù hợp.
• Allow manual close: Đánh dấu để cho phép đóng thủ công các sự kiện vấn đề do Trigger này tạo ra.
• Menu entry name / Menu entry URL: (Tùy chọn) Cho phép định nghĩa một liên kết URL hiển thị trong menu sự kiện của Trigger, hữu ích cho việc liên kết đến các hệ thống khác (ví dụ: wiki, hệ thống quản lý sự cố).
• Description: Trường văn bản để cung cấp thêm thông tin về Trigger này, bao gồm hướng dẫn khắc phục sự cố, thông tin liên hệ của nhân viên chịu trách nhiệm, v.v..
• Enabled: Bỏ chọn ô này sẽ vô hiệu hóa Trigger.

Tab “Tags”

Tab này cho phép bạn định nghĩa các thẻ ở cấp độ Trigger. Tất cả các vấn đề của Trigger này sẽ được gắn thẻ với các giá trị được nhập tại đây.

• Name/Value: Đặt các thẻ tùy chỉnh để đánh dấu các sự kiện Trigger. Thẻ là một cặp tên và giá trị (ví dụ: Application: Webserver, Team: DevOps).
• Các thẻ sự kiện có thể được sử dụng để tương quan sự kiện, trong các điều kiện của Action và sẽ được hiển thị trong “Monitoring” > “Problems” hoặc widget “Problems”.

Tab “Dependencies”

Tab này chứa tất cả các phụ thuộc của Trigger.

• Add: Nhấp để thêm một phụ thuộc mới. Phụ thuộc được sử dụng để tránh tạo ra quá nhiều cảnh báo liên quan đến một sự cố gốc (ví dụ: nếu máy chủ bị lỗi, không cần cảnh báo về tất cả các dịch vụ đang chạy trên đó).

Kiểm tra và khắc phục sự cố cảnh báo

Sau khi thiết lập toàn bộ quy trình, việc kiểm tra là cực kỳ quan trọng để đảm bảo cảnh báo hoạt động đúng như mong đợi.

Kiểm tra sự kiện và thông báo

Sau khi đã cấu hình đầy đủ các thành phần (Media Type, User, Action, Trigger), bước cuối cùng là kiểm tra xem hệ thống cảnh báo có hoạt động như mong đợi hay không.

1. Tạo vấn đề giả định: Cố tình tạo một tình huống để kích hoạt Trigger.

• Ví dụ: Để kiểm tra cảnh báo CPU cao, bạn có thể chạy các lệnh như cat /dev/urandom | md5sum trên máy chủ được giám sát để tăng tải CPU.
• Hoặc, bạn có thể tạm thời hạ thấp ngưỡng của Trigger để nó kích hoạt ngay lập tức.

2. Kiểm tra Events (Sự kiện):

• Đi đến “Monitoring” > “Problems”. Bạn sẽ thấy các vấn đề xuất hiện tại đây khi Trigger được kích hoạt và chuyển sang trạng thái “PROBLEM”.
• Trạng thái “Problem” thường sẽ nhấp nháy, cho thấy có một sự kiện mới đang diễn ra.

3. Kiểm tra Notifications (Thông báo đã gửi):

• Đi đến “Reports” > “Action log”. Kiểm tra xem thông báo đã được tạo và gửi đi chưa.
• Nhật ký hành động sẽ hiển thị chi tiết về việc thông báo được gửi đến ai, qua loại media nào và trạng thái gửi.

Khắc phục sự cố (Troubleshooting)

Nếu cảnh báo không được gửi hoặc có lỗi, hãy kiểm tra các điểm sau:

• Log Zabbix Server: Xem log của Zabbix Server tại /var/log/zabbix/zabbix_server.log để tìm thông tin chi tiết về lỗi gửi thông báo. Đây là nơi đầu tiên để tìm kiếm manh mối về các vấn đề nội bộ của Zabbix.
• Log của script cảnh báo tùy chỉnh: Nếu bạn sử dụng script tùy chỉnh cho Media Type (ví dụ: cho Webhook), hãy kiểm tra log của script đó để phát hiện lỗi trong quá trình thực thi script.
• Trạng thái Item và Trigger: Đảm bảo các Item đang thu thập dữ liệu chính xác và Trigger đang ở trạng thái “Enabled”. Một Trigger bị vô hiệu hóa sẽ không tạo ra sự kiện và do đó không gửi cảnh báo.
• Quyền người dùng: Đảm bảo người dùng nhận cảnh báo có đủ quyền để xem dữ liệu từ Host và Trigger liên quan. Zabbix Server sẽ không tạo cảnh báo nếu người dùng nhận không có quyền truy cập rõ ràng đến Host hoặc không có quyền nào đối với Host đó.
• Mạng và tường lửa: Đảm bảo Zabbix Server có thể kết nối đến máy chủ gửi email (SMTP) hoặc API webhook (Slack/Telegram) qua các cổng và giao thức đã cấu hình. Tường lửa (firewall) là nguyên nhân phổ biến gây ra lỗi kết nối.
• Sử dụng Test Media Type: Thực hiện lại bước kiểm tra Media Type trực tiếp từ “Alerts” > “Media types” để xác định lỗi nằm ở cấu hình Media Type hay ở các bước tiếp theo trong quy trình cảnh báo.

Kết luận

Việc thiết lập một hệ thống cảnh báo mạnh mẽ trong Zabbix là một bước then chốt để đảm bảo sự ổn định và hiệu suất của hạ tầng công nghệ thông tin của bạn. Bằng cách hiểu rõ luồng hoạt động từ việc thu thập dữ liệu (Items), định nghĩa điều kiện sự cố (Triggers), đến việc tự động hóa hành động (Actions) và lựa chọn phương thức gửi (Media Types), bạn có thể chủ động cấu hình các cảnh báo phù hợp với mọi nhu cầu giám sát của mình.

Zabbix cung cấp sự linh hoạt vượt trội, từ các phương thức truyền thống như email đến tích hợp hiện đại qua webhook với Slack/Telegram và nhiều dịch vụ khác, giúp bạn nhận thông báo kịp thời khi sự cố xảy ra. Nắm vững các bước cấu hình chi tiết này không chỉ giúp bạn phản ứng nhanh chóng, giảm thiểu đáng kể thời gian ngừng hoạt động mà còn bảo vệ hệ thống của bạn khỏi những rủi ro không mong muốn, đảm bảo hoạt động liên tục và hiệu quả.