Implementing SLA in Zabbix: From Service Monitoring to Availability Calculation
When we talk about monitoring, the first thing that usually comes to mind is checking whether a server or service is Up or Down. But in a real production environment, knowing the current status of a service is not enough.
For example, we may want to know how available a service was during the last month. How much downtime did it have? Did it meet the expected SLA?
This is where SLA in Zabbix becomes useful.
In the video on this page, I walk through a simple and practical scenario to show how SLA can be implemented in Zabbix from scratch.
What Is SLA?
SLA stands for Service Level Agreement. In simple terms, it defines the expected level of availability for a service during a specific period of time.
For example, if we define an SLA target of 99.9%, we expect the service to be available for at least 99.9% of the specified period.
This becomes more interesting when you realize that even a small difference between 99%, 99.9%, and 99.99% can make a significant difference in the amount of acceptable downtime.
The Scenario Used in the Video
To keep things practical instead of just talking about theory, I created a simple lab environment.
I opened several TCP ports on a server and treated each one as a separate service.
Then, I created Items in Zabbix to monitor the status of those ports. After that, I created the related Triggers so that if one of the ports became unavailable, Zabbix could detect it as a Problem.
At this point, we have the usual Zabbix monitoring flow:
TCP Port → Item → Trigger → Problem
But to implement SLA monitoring, we need to go one step further.
Defining Services in Zabbix
The next step is using the Services feature in Zabbix.
Services allow us to turn technical monitoring information from Triggers into something that represents an actual business or infrastructure service.
For example, instead of only seeing:
TCP Port 8080 is down
we can associate that problem with a service such as:
Web Application Service
This becomes especially useful when you have many Hosts, Items, and Triggers. Instead of looking at the infrastructure only from a technical monitoring perspective, you can look at it from a service-level perspective.
Connecting the Service to an SLA
Once the Service is created, we can define our SLA and associate the Service with it.
From this point, Zabbix can calculate the availability of the service over different periods and determine whether the SLA target has been met.
So the overall flow of the scenario looks like this:
TCP Service → Item → Trigger → Problem → Service → SLA
Understanding this relationship is one of the most important parts of working with SLA in Zabbix. Once the connection between Triggers, Services, and SLAs is clear, implementing more complex scenarios becomes much easier.
Where Is This Useful?
Imagine you are monitoring several important services such as websites, APIs, databases, or internal applications.
Getting an alert from Zabbix when something goes down is useful, but after a while, you will probably have bigger questions:
How available was this service during the last month?
How much downtime did we have?
Did the service achieve 99.9% availability?
Which services failed to meet their SLA targets?
This is where SLA becomes more than just another Zabbix feature. It gives us a practical way to measure and report the actual availability and reliability of our services.
In the video on this page, I implement the complete scenario step by step in Zabbix, starting with monitoring TCP ports and creating Items and Triggers, then defining Services, and finally configuring and calculating the SLA.
