Learn Zabbix - Actions, Media & Alerting

#Introduction

Episode 7 gave Zabbix the ability to detect problems via triggers and events. But a detected problem without a response is just a note on a screen. Episode 8 bridges detection and action: you'll configure actions that decide what happens when an event appears, media as the delivery channels, and escalation so notifications reach the right people.

Alerting is the part of monitoring whose quality is most often evaluated: timely alarms that don't flood operators are the mark of a mature monitoring team. This episode gives you the entire toolkit for building healthy, accountable alerting.

#Actions: Responding to Events

#Conditions: When an Action Fires

An action is a rule that defines the response to an event. Every action has one or more conditions that determine when it's active. Example conditions: the host group is Linux/Production, trigger severity is High or Disaster, or an event tag contains service:web.

Conditions are combined with AND or OR logic. An action only fires if the combination of conditions is met — this is the most effective way to make sure notifications are only sent for genuinely important events.

#Operations: What the Action Does

When the conditions are met, the action runs one or more operations:

• Send message: send a notification through a media type to a specific user or user group.
• Execute remote command: run a command on the host via the agent, for example restarting a service.
• Escalate: send to the next level in an escalation step.

A remote command is executed on the problematic host through the agent, like the command systemctl restart zabbix-agent2 to bring the agent back up. This feature is powerful but must be constrained carefully — combining it with RBAC and an IP allowlist in episode 15 becomes mandatory.

#Action Log: A Trail of Every Execution

Every action execution is recorded in the Action log under the Reports menu. This log shows the execution time, success or failure status, and the reason for failure — for example a media type not configured or a user without media. Get into the habit of checking the action log whenever a notification doesn't arrive; the answer is almost always there.

#Media: Notification Channels

#Email: The Most Basic Media Type

Email media is configured in the Users → Media menu. You set the SMTP server, port, and credentials, then link each user to their email address. Email remains the most universal channel and is most often used as a fallback.

SMTP server:   smtp.example.com
SMTP helo:     example.com
SMTP email:    zabbix@example.com

#Webhooks and Official Integrations

Zabbix provides a generic webhook and official integrations for Slack, Telegram, Microsoft Teams, PagerDuty, VictorOps, and Alert Manager. Webhooks are configured as media types under the Alerts → Media types menu. Here's an example of triggering a webhook with curl:

curl -s -X POST https://hooks.slack.com/services/T000000/B000000/XXXX \
  -H "Content-Type: application/json" \
  -d '{"text":"Zabbix: server down"}'

The command curl -s -X POST https://hooks.slack.com/services/... calls a Slack incoming webhook manually — a quick way to test a channel before configuring the media type in Zabbix. The official integrations are just wrappers over the same mechanism.

#SMS via Script

For environments that need notifications without internet, Zabbix supports SMS scripts: script media types call an executable with arguments like the phone number and message. Third-party SMS gateways can be integrated via a simple script.

/usr/lib/zabbix/alertscripts/send_sms.sh "08123456789" "Zabbix: host down"

Script media types call an executable with arguments already set in the media type configuration. The send_sms.sh script above is a simple example that calls a gateway API — the delivery logic is entirely yours, from parsing the number to the message format accepted by the provider.

#Escalation and Notification Scheduling

#Multi-Step Escalation

Escalation sends tiered notifications based on how long a problem has been running:

0 minutes:   notify level 1 on-call team
15 minutes:  notify level 2 on-call team
60 minutes:  notify the manager

Each step waits for a certain interval since the problem was first detected. If the problem recovers mid-escalation, the remaining steps are cancelled automatically.

#Time Periods and Maintenance

Media and actions can be restricted to time periods — for example only sending during working hours. For scheduled maintenance, use maintenance windows in the Configuration menu: during that period, triggers on the affected hosts produce no notifications.

#Designing Healthy Alerting

Some principles that keep alerting useful:

• One root cause, one notification: use trigger dependencies from episode 7 and specific conditions.
• Severity determines the channel: email for warnings, chat for high, SMS for disaster.
• Test media regularly: notifications that fail silently are just as bad as no notifications at all.
• Document every action: the action name should explain its purpose, for example Notify on Disaster.
• Audit the action log: review alarms that flap and fix the trigger or action.

#Closing

Episode 8 completed the alerting chain: actions read events and run operations, media types deliver messages via email, webhook, Telegram, or SMS, and escalation ensures problems reach the right people on time.

Key takeaways:

• Actions connect events to responses: message, remote command, or escalation.
• Conditions filter events so only important incidents produce notifications.
• Media types define the channel: email, webhook, Slack or Telegram integrations, even SMS scripts.
• Multi-step escalation promotes problems that remain unresolved.
• The action log is the first place to check when notifications don't arrive.

In the next episode 9 we'll discuss visualization: dashboards, graphs, and maps — designing dashboard widgets, custom graphs, network map topology, and scheduled reports so Zabbix data is readable by both operators and management.