Learn Zabbix - Observability: Log Monitoring & Business Metrics

#Introduction

Metrics answer "how much?" — logs answer "why?". Episode 19 opens an observability dimension untouched in previous episodes: log monitoring to understand what's actually happening inside the system, and business services to translate technical health into business impact.

These two topics complete the picture. Log monitoring gives signals metrics can't — error patterns, attacks, and strange behavior. Business services, meanwhile, raise the viewpoint from individual items to the end-to-end services customers actually experience.

#Log Monitoring

#Log and Logrt Items

Zabbix monitors log files via Zabbix agent type items with the log[] and logrt[] keys. Both read new lines from log files:

• log[]: monitors a single log file with a fixed name.
• logrt[]: monitors log files whose names change — a common pattern for daily rotated logs like access.log becoming access.log.2026-08-10.

log[/var/log/nginx/error.log, "error", "utf8"]
logrt[/var/log/nginx/access.log, "500|502", "utf8", 1]

Log items produce a value for every line matching the pattern, complete with the file, timestamp, and source — full details are available in the official Zabbix documentation.

#Parsing Logs with Items

For a real example, this item monitors Nginx errors:

tail -n 20 /var/log/nginx/error.log | grep "error"

The command tail -n 20 ... | grep "error" shows the last 20 lines containing the word error. A Zabbix log item does the same thing in real time — every line matching the pattern becomes one value that can fire a trigger.

#Fail2ban-Style Log Analysis

A classic log monitoring pattern is detecting repeated failed login attempts. With logrt[] on the authentication log and a count() trigger:

count: number of "Failed password" lines in 10 minutes
threshold: more than 5 attempts

If the count exceeds the threshold, Zabbix sends an alert — behavior that mimics fail2ban but with full Zabbix notification capabilities: media, escalation, and action log. Combine it with the remote commands from episode 8 to take automatic action.

#Business Services (BSM)

#Service Tree and SLI/SLO

Business service monitoring maps business services to the technical components underneath them. A simple example: the "E-commerce Website" service depends on the database, application, and load balancer.

E-commerce Website (SLI/SLO)
    ├── Web server (10)
    ├── Application (10)
    └── Database (10)

Each service has an SLI (the measured indicator, for example availability) and an SLO (the target, for example 99.9%). Zabbix calculates service health from component health and displays it as a problem or OK status.

#Weighted Service Metrics

Not all components are equally important. Zabbix allows different weights per service — a failing database impacts more than a failing cache:

E-commerce Website
    ├── Web server (30)
    ├── Application (40)
    └── Database (30)

Weights and priority determine how fast service health drops when one component has a problem. With weighted calculations, a single health value per service can drive executive reports and dashboards.

#Service-Level Reporting

Because service health is stored as periodic values, Zabbix can calculate the percentage of time a service was in an OK state — the basis for availability calculations close to the real SLI:

SLO target:      99.9%  (52.6 minutes of downtime allowed per month)
Actual this month: 99.94%

This comparison between target and actual is what gets brought to business meetings. Monitoring data finally speaks the same language as service contracts.

#Connecting Logs with Business Services

Logs and business services reinforce each other. Logs provide the "why" context when a business service shows "how much it dropped". When the E-commerce Website service turns red, operators don't need to guess — the logs on the relevant components already show the underlying error pattern.

The best practice: link the most diagnostic log items to the service tree, so investigation from a failing service points straight to the relevant logs.

#Closing

Episode 19 completed the observability picture: log and logrt items for real-time log parsing, a fail2ban-style analysis pattern for security, and business services with a service tree, SLI/SLO, and weighted metrics for speaking the language of business.

Key takeaways:

• Log items monitor log files with patterns and produce a value per line.
• log[] for fixed files; logrt[] for logs with changing names.
• The fail2ban pattern uses count() over repeated failed login lines.
• A service tree maps business services to technical components.
• Weighted metrics and SLI/SLO turn monitoring into business language.

In the next episode 20 we'll discuss OpenTelemetry and Zabbix 8.0 — the OTel collector integration and metrics, logs, and traces ingestion, Zabbix 8.0 LTS features, and the migration path from 7.0 LTS.