长文|基于Zabbix的可观测性监控

01 可观测性与可观测性监控

02 基于ZABBIX的可观测性监控

03 可观测性监控的探索

——王小东，多年运维老兵，《nginx应用与运维实战》作者

在这里插入图片描述

本文整理自王小东在2022Zabbix峰会演讲分享。ppt可在公众号后台回复“ppt"。

1、可观测性与可观测性监控

我从事运维近20年从Zabbix 1.0一直使用到6.0 ,基于多年的使用和Zabbix不断的演进和发展，给大家分享下基于Zabbix可观测性监控。

可观测性是什么？可观测性监控如何实施？认知一个新事物是从了解到熟悉的过程，了解的过程，我认为就是可观测性。

对于自然界里的物质，其可观测性的对象是物质，而对云原生世界里的物质，观测对象应该是微服务架构里的应用。

真正的自然界物质，如何去观测？常见可观测性的三个维度，分别是Metrics、 Logs及Trace三大支柱。当打开一个页面，就与页面进行了交互，该页面是否展示出所预期的页面？这面临着一致性和安全问题。安全分为两个层面，1.探测它是否安全；2.安全技术加固。随着对应用的认知和技术的不断发展，可能还会存在着更多可观测性的层面和属性。在自然界，所有物质都随着时间而呈现不同状态。对于监控，每一个应用都随着时间而发展为不同状态。

从四维时空理论，我们对于可观性监控更要以时间为切面去观测应用的多维度，从一个时间点或一个时间区间去看可观测性所展示出来相关的各种监控指标。

分享下我对可观性监控的看法。

01客观性。客观性对所监控的应用要有低嵌入方法。同时需从第三方的客观角度去观测或采集数据。

02系统性。不能单一地看某个指标，可观测性早先有三个维度，后来扩展并不断增加，如若只看一个角度，整体性将被忽略，无法对每个方面都进行观测数据。

03关联性。观察每一个监控指标时，除了要具有独立性，同时还要建立所有监控指标之间的关联性和各不同应用外部的关联性来实现整体的观测。

04可预见性。任何事物和应用、观察都基于时间的动态行为。监控的目的是提早发现风险和避免发生故障。

可观测性监控的认知观分为以下2点。

01云原生世界可观测性的观测对象是微服务框架的应用可观测性的观测对象，可观测性是具备固有属性及能力。可观测性的内容可对照认知物质世界的物理、化学方法去不断探索。

02可观测性监控的四个原则，客观性、系统性、关联性、预见性。

03可观测性监控，一定要建立以时间为视角的观察与分析，可观测性监控的能力取决于我们对可观测性的认知以及相关采取的技术手段。

2、基于Zabbix可观测性监控的实践

01 Zabbix和Prometheus实现有效的集成。

中国监控场景覆盖的现实情况在现有的架构中既有虚拟机又有云产品如K8s，监控工具通过Zabbix或者Prometheus某一个方面无法满足监控需求，因此需要配置包括监控的监控项、告警方法。每个工具都有独立的技术站，相应的维护成本是较高的。

每一个告警都要配相应的预值和告警人。方法如：Prometheus负责它专长的部分叫Exporter和Kubernetes。利用Zabbix的HTTP方式来查询多个Prometheus的接口，通过Zabbix现有的监控模板功能、预处理和自动发现功能，通过Prometheus API，用Prometheus把不同的监控项获取数据在Zabbix里自动创建监控项，包括预值创建，通过统一的应用关系标识，自动关联好监控的告警人，整体过程都是全自动的。

在查询时，以最低标准来查询，如：CPU使用率是80%或90%，告警的时候只需60%。60%时，数据已经获取到Zabbix服务器里，通过Zabbix自有的多分级的预值和设计能力，进行多级别、告警级别的管理。

优化了Prometheus的架构。Prometheus不集成在Kubernetes平台里，他是独立的，在实施的过程中利用的Prometheus的远程读写的功能进行多集群、多点Prometheus的部署，统一数据，通过influxDB进行数据汇总。通过只读的Prometheus向外进行数据展示，这便解决了展示问题。

Zabbix实现了统一的告警配置和统一告警人管理，当然整个架构也在Devops过程中持续监控的概念，监控不只是监控生产环境，测试过程的环境是全面监控的，通过整体的设计改造实现如上收益。

02如何做Elk集成。监控场景中Zabbix目前在日志方面还是无法进行有效实现的,Elk对日志的收集和展示较好,但在原有的Elk架构里面，大家都是统一一个大集群，不便于维护。

基于敏捷和最小实用原则，可以拆分出多个小集群，小集群如何进行构建和数据转发？使用集中化的Logstash集群进行日志收集路由，通过比各个不同的Kubernetes集群或者各个主机里面日志，统一发送到Logstash集群，根据不同的标识或者应用名分散到不同的一个 Elk集群。

随着业务的增长，以最小的集群，构建Elk集群，对集群做扩容或更复杂的操作，再同步、增加多个ES集群便可。Elk解决方案有很多，但需要有更多的技术方法，只要在Logstash中启用HTTP插件，将不同的告警策略写到Redis中，当有日志过滤时，通过Logstash的filter进行脚本重新过滤，通过falsk搭建Webserver，将相应的数据进行梳理修正为Zabbix_sender的数据格式发送到Zabbix的服务器上，服务器同样利用监控模板和监控模板里配置的预处理及自动发现功能，监控项是自动实时创建的不需要手动创建，根据整个日志级别，进行跨级别告警，整合统一的告警人，不需要配置更复杂的告警人，直接发送至邮件或者钉钉通知，

通过以上整个设计，优化了Elk的部署结构，小成本以适用企业的运维发展，运用Zabbix告警模板，简化了运维方式无需手动配置，全自动化，完成了自动化的落地。

03 TRACE与Skywalking集成。Skywalking基于最小构建原则。网上构建Skywalking集群需要很多设备和服务器，故此我们选择了最简单的Server端和ES数据库服务器。

集群存储的告警配置都是基于文件，配置很复杂且无法同步。Skywalking可以一次性配置完毕，包括告警预值、告警方式等。

Skywalking也有HTTP的输出的能力，可以输出到falsk，构建外部服务器，进行数据修正，将Skywalking的告警文件数据修正为Zabbix支持的方式,发送到Zabbix Server上,进行监控模板预处理，自动处理，自动发现，告警创建都是全自动的且不需要维护，优化了Skywalking的部署结构，按照企业当前最适用的最小构建原则，统一了告警人管理，实现了唯一的告警人和事件处理。