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

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

02 基于ZABBIX的可观测性监控

03 可观测性监控的探索

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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的部署结构，按照企业当前最适用的最小构建原则，统一了告警人管理，实现了唯一的告警人和事件处理。

对于任何监控系统，都有采集、存储、事件、动作和展示这五个模块，把这5个模块进行拆分，拆分成由多个工具进行相应的组合集成而实现。

01轻架构以最小适用原则来实现整体架构设计，不做过多浪费或超前设计，实现整个架构的使用。

02模块化，开源工具都是用相应的接口来实现的，如：各个不同阶段用不同工具在Zabbix进行集成。

03低嵌入。坚持第三方低嵌入原则，客观地去采集数据。如：Prometheus从Kubernetes集群里拿出来做独立部署。

04微服务化。运维工具要微服务化，通过API互相调用和实现，互相拆分模块处理，统一地基于Zabbix事件的处理能力和统一的告警输出。

05实现敏捷运维,模块化拆分。Docker环境没有使用复杂的Kubernetes集群，是纯Docker。当数据存储在本地或者相应的存储服务器上时，快速恢复或搭建只需Docker compose的文件快速秒集就可以实现。

06低成本。在运维的过程中，不只要实现运维工作，同时要坚持为企业降低成本，不要过多设计，遵循当前最实用的原则。

监控架构关于可观测性功能和一致性上如何实现？基于业务监控的能力以业务为驱动，在服务器部署好之后，是否做到为用户可用。

如：当用户从登录到整个业务链路的过程是需要监控的。利用Zabbix中Agent支持脚本的功能，编写Python脚本。

当任何异常都发送到Zabbix，实现业务一致性和端到端的检测，并非只监控CPU或某一资源目标。基于Zabbix统一事件的处理能力，可以进行前置统一收集、统一告警、告警抑制和关联降噪。

无需花费过大的精力做后端数据分析。可利用Zabbix告警的脚本定义功能，只需在Redis中不断记录不同应用的关系，直接读取，如与cmdb做关联，记录相应关系，编写Python脚本便可解决。基于此，只需不断优化Zabbix提供的功能，，就可以实现告警抑制和关联降噪的功能。

可观性监控，在认知中是要以时间为视角去观测查看的。Zabbix提供了非常好的功能：基于问题管理页面实现同一时间区间内多维度的统一查看。

页面中的所有应用、事件会记录到Zabbix中,可用时间点或时间区间来查看某应用在这个时间点或时间段的多视角多维度所发生的问题,如：Metric、Logs、Trace方面的告警问题。

智能监控的概念是用数据做存储和统一收集。可以做趋势预测，按时间维度来做，如：CPU使用率，根据时间维度不断的进行模拟曲线，实现下一个时间点可能产生趋势的预测，做未来预测。

按照时间点所形成的数据是可以用函数所表示的，引入毕达格拉斯：数学支配着宇宙，y=kx+b的数字可以铺满整个宇宙，存储原数据时，只存一个公式就不需要有大数据的存储了，科学可能需要我们进一步探索是否真正要存原数据。是否只存一个函数就可以。

微服架构的应用不断演进，会变得越发庞大，可能会超越我们人类所处理的能力，黑客帝国这个电影就已经拟人化的演示应用治理的场景，应用的压力测试和混沌工程。

通过人工智能，构建可控的治理环境，进行不断的自我破坏和实时的观测各种可观测性数据，进行反馈实现应用迭代，我觉得是应用可观测性给我们带来的现实的意义。如上就是我所分享的内容，谢谢！