基于Zabbix的SLA监控体系构建与实践

本文来自Zabbix开源社区专家投稿。

投稿人简介：褚凤彬，斯凯菲尔电子（苏州）有限公司，IT经理。

SLA

SLA，全称是Service Level Agreement, 是用来管理服务的表现。在Zabbix中我们可以把自己的应用监控起来，还可以为它建立SLA。

Question1:

"SLA在Zabbix里的主要工作原理是什么？"

在Zabbix中，SLA的实现，是建立在Trigger基础上的。简单地说，当一个，或多个相关Trigger触发时，就会对我们定义的SLA产生影响，它会自动计算往下跌。Trigger一旦恢复，它就停止往下跌。

A

Question2: 

"如何构建自己的SLA？"

为了实现SLA，我们需要建立Services，它是Trigger和SLA之间的桥梁。

A

我假设这样一个场景来说明SLA的实践。

公司为一个Web应用制定了SLA，

假设它是受后台三台Nginx服务器的影响。

STEP 1.

01

第一步：规划好Trigger的Tag

当Trigger触发时，是通过Trigger里的Tag传送到Service中。所以我需要给三台Nginx服务器的这个Nginx服务不在运行的Trigger建立不同的Tag。保证这台主机的Nginx停止时，会有一个唯一的Tag传送出来。

（如上图所示，我给Nginx: Service is down的Trigger新建了一个名字是problem_tag，值是{HOST.NAME}_www的新Tag。）

02

第二步：规划好我们的Services

进入左侧Services / Services 菜单，点进右上角的Edit进入编辑模式，然后点Create service新建一个Service，命名为“某Web应用“，先不要理会它的属性页面。如下图：

点击它，在它下层再建三个Service。如下图：

在这里我们注意的是，我们需要在Problem tags里，把第一步中，为Trigger建立的Tag名字和值填进去。注意我现在用的值是Web4_www，也就是{HOST.NAME}宏在触发时会解析成Web4。

同样，另外两个Service是给Web5和Web7两台服务器建的。

至此，一个简单的“某Web应用“的Service已经建好。你会发现它就是一个简单的Parent/Child关系。Parent就是我们要关注的SLA，而它是受下面一个，或者多个不同Child组合的影响。

03

第三步：定义好Parent service

打开“某Web应用“的属性窗口。

切换到Tags页，我们新建一个service_tag，这个用处在第四步中讲述。

切换到Service页，这里最重要的就是这个选项，Service状态的计算规则：

*如果选了Most critical of child services，那么任何一个child service有问题，都会影响这个parent service。

*如果选了Most critical if all children have problems，只有当它所有的child service有问题，才会影响这个parent service。

*注意上图下半部分还有一个高级设置。如果你有非上述两种情况的计算规则，可以看一下这里。

04

第四步：最终形成我们定义的SLA

上述所说的parent service就是最终的SLA。

打开Services / SLA菜单，新建一个SLA。如下图：

在这里SLO就是你定义的最低百分比。如果实际值低于这个规定的值，Zabbix会显示红色。

Reporting period，SLA会在这个周期结束后恢复100%。

这里有一个Service tags，就是在第三步提醒您留意的，在parent service中的tag页面里自定义的一个tag。两者需要名字和值都完全相同。

到现在，我们可以看到，SLA就是利用Trigger触发时间的多少，来影响我们自定义的SLA。

Q

碰上系统维护怎么办？

A

如果碰上系统、应用、电力等因素而不得不导致SLA受影响，但我们允许Zabbix里的SLA保持不变，可以按下面两个方法之一来设置:

(1) 到Services / SLA菜单，点击那个我们不想发生影响的SLA，点击Excluded downtimes页面，把维护的时间填进去。这样的话，在这段时间里，无论发生什么情况，SLA会保持不变。如下图：

(2)给受影响的主机，制定维护计划，在某段时间里，报警压制，SLA也不受影响了。这个方法简单，但在7.0之前似乎还不支持。

Q

SLA有哪些注意点？

A

这些是我平时在应用SLA时总结的注意点，希望对大家有用：

(1)请注意Tag的名字和值，一定要区分大小写。在给模板Trigger新建Tag时，要有一个自己的规划，触发的时候Tag都是唯一的才可以方便地管理SLA。

(2)不要在SLA计算发生时，尝试通过去修改SLA定义，让它停下来。我在线下Meetup交流时，有人说可以在修改条件后尝试重启一下Zabbix 服务，这个有机会还是测一下。

(3)在大版本升级时，做好SLA的备份。Zabbix在这方面还没有做好，但你要是从5.0升级到6.0，看看下面的痛点。

Q

SLA有没有痛点？

A

我在做5.0升级到6.0，我们公司的SLA就成了这样：

绝大部分的SLA确实转换成功的，但我也发现有2、3个转换错了，好多SLA都无法阅读，而且按我的理解可能一个Trigger引发两个SLA变动，甚至没有一个SLA会受影响。我在6.0升级到7.0时，没有发现有问题，原样升上来了。