经常听到很多运维小伙伴争论，Prometheus好还是Zabbix好？在我看来，脱离实际应用场景去讨论技术的优劣是没有意义的。图片来自PexelsZabbix适合监控场景的监控维度在选择具体的监控平台之前，我们首先要明确我们的监控目标是什么？在我的理解中，监控分为两个维度：监控的广度和监控的深度。①监控的广度您需要监控的系统从几个到几十个不等，例如监控硬件、存储、操作系统、中间件、数据库和应用程序。在每个平台中，有多个平台：比如我们有华为、戴尔、惠普、IBM的硬件服务器或交换机，还有Windows、Linux、Aix、ESXi等各种操作系统。系统维度和平台维度的结合意味着我们不仅需要监控多层次的监控，也意味着每个层次内需要监控的对象更加细化。因此，系统的异构性和平台的多样性构成了运维的复杂性。综上所述，一个理想的监控平台应该支持基于各种系统的监控，覆盖各种厂商和平台。②监测深度相比之下，监测目标需要考虑的另一个维度是监测深度。在监控深度上，我们可以简单的分为四类：可用性监控、性能监控、日志监控、自定义监控。可用性监控：它的状态是一个布尔值，即只有1或者0。比如一个服务是停止还是运行，一个端口是Up还是Down，基于可用性监控，我们可以知道被监控的对象是否处于一个正常的状态。性能监控：是在可用性监控的基础上进一步监控。比如我们监控一个IP地址，我们会在可用性监控中ping这个IP。如果已连接，则说明该IP可达；更进一步，Ping延迟是对该IP的性能监控。通过性能监控，我们可以知道被监控对象的健康状况和负载水平。CPU、内存使用率、磁盘IOPS、网络吞吐量都是常见的性能监控指标。日志监控：无论是可用性监控还是性能监控，都是按照一定的轮询周期进行采样的。两个采样点之间的监控实际上是缺失的，所以两个采样点之间可能会漏掉一些异常的监控数据。通过日志监控，可以记录每一个操作或行为，保证监控的完整性。常用的日志监控分为安全日志、系统日志、应用日志和操作日志。自定义监控：顾名思义，我们根据自己的情况定义一些符合自己监控需求的监控指标。比如订单的数量，网络设备流量的聚合操作等等。一个理想的监控平台应该支持不同的监控深度和方式，从可用性监控、性能监控、日志监控到自定义监控。全面监控的广度和监控的深度，为我们选择监控平台提供了思路和依据：当我们的环境只有Windows服务器时，微软的SystemCenter显然更适合。它不仅能比其他平台更快地发现问题，而且拥有全面的知识库来提供具体的解决方案。但很多时候，我们的环境充满了网络设备、Linux、存储和其他需要监控的东西。这个时候用SystemCenter来监控可能会比较难实现。即使能够实施，也仍然会存在高昂的成本或技术上的局限性。同样，Solarwind更适合监控网络设备。那么有没有一款产品可以兼顾监控的广度和深度呢？经过各种评估和试用，我们认为Zabbix可能是目前兼顾监控广度和深度的最合适的监控平台。刚才也提到了Zabbix和Prometheus的优劣。一直是争论的热点。下面我们就从不同的维度对两者做一些简单的对比。①在UI方面，Zabbix5.0的界面如下：Zabbix一直以来被吐槽最多的就是它的UI。确实，在Zabbix1.8、2.2等早期版本中，其UI并没有那么友好和美观。但官方团队也在不断迭代和完善UI。5.0的UI已经很现代了，图形和图表的展示也更加丰富多彩。同时Zabbix90%以上的配置管理操作都可以通过Zabbix的Web端实现，只有一部分基础配置需要通过配置文件进行处理。这样有一个很大的好处：所有的维护都会有一个统一的入口，通过简单的点击和拖动操作就可以完成，大大提高了运维团队的效率。Prometheus的界面如下图所示：Prometheus的界面比较基础，提供了类似SQL的查询接口，可以简单的查询一些指标。Grafana更常用作Prometheus的前端。Zabbix本身也可以使用Grafana作为前端，但是和原生UI相比，Prometheus要简单一些。同时，Prometheus的大部分运维都是通过配置文件进行的。大量监控对象的维护必须依赖第三方配置管理工具，因此运维复杂度会比Zabbix高。②在架构方面，Zabbix架构图如下：Zabbix是一个分布式监控系统。在很多公司，尤其是金融机构，会有多个网络区域，每个区域都是相互隔离的。Zabbix支持在每个网络区域部署一个ZabbixProxy，即Zabbix的代理服务器。这个服务器的职责是收集当前区域的监控对象的监控数据。同时，ZabbixProxy会与ZabbixServer通信，将收集到的数据提供给ZabbixServer进行后续处理，比如触发告警。我们还将在用户可以访问的区域部署Web终端。这样做的好处是用户可以在正常的办公环境中访问Zabbix，而不是在机房中。对于Zabbix使用的数据库，使用一台proxy或者mycat可以提高其高可用，保证数据库的主从分离。这种架构的好处是从库作为读库提供对其他系统的访问，比如CMDB或者报表系统，而不影响主库的性能。由于Zabbix的各个组件是分离的，只需要在防火墙上开放一些必要的网络路径，而不需要像ZabbixServer一样暴露所有的监控主机端口，从而提高了安全性。Prometheus架构图如下：总的来说，Prometheus架构与Zabbix有很多相似之处：Prometheus使用各种Exporter进行监控，Exporter的功能类似于Zabbix的Agent，负责收集监控对象端的数据。Prometheus的AlertManager类似于Zabbix的Action，可以触发告警，比如发送短信和邮件。不同的是Prometheus使用的数据库是TSDB时序数据库，而Zabbix使用的是MySQL或者PgSQL的关系型数据库。TSDB在存储监控方面的性能会优于传统的关系型数据库，因此Zabbix也开始初步支持TSDB作为后端数据存储。选择监控平台时，还需要评估数据库是否是监控的瓶颈。当性能和压力不能成为监控平台的瓶颈时，TSDB时序数据库的优势就不会很明显。以上就是Zabbix和Prometheus在不同方面的对比，希望这些对比能为大家在选择监控平台时提供一定的参考。在我的环境中，选择Zabbix作为统一监控平台是因为我们需要监控很多不同类型的设备和平台。依托Zabbix的一些特性，自动化监控的水平也有了很大的提升。③Zabbix高级特性开源免费，社区支持：虽然很多软件都是开源的，但也有商业版和社区版，比如MySQL和Puppet。商业版将需要用户付费，但同时会提供更完善、更高级的功能。Zabbix本身不仅是开源的，而且没有商业版和社区版的区别。官方保持固定的版本更新频率，每个新版本都会修复问题或提升用户体验。同时，除了原厂团队，Zabbix还将有社区支持，在中国活跃的用户社区，每年定期举行Zabbix大会等活动。分布式高可用：Zabbix本身也是分布式高可用的，也解决了单点的问题。底层发现、自动发现：这是Zabbix全栈自动化监控最不可或缺的两个特性。低级发现：低级发现可以帮助我们发现一个设备上的所有监控对象。想象一个场景，我们有100台服务器，每台服务器至少有2个硬盘，最多有20个硬盘。如果我们要监控这些磁盘的IOPS、磁盘剩余空间1、磁盘队列长度等10个指标，需要如何添加监控呢？常规的做法是，在每台服务器上，根据服务器上的实际磁盘数量，为每个磁盘添加监控，如果平均有10个磁盘，那么需要添加100*10*10个监控项，共计10,000个监控项。不仅如此，继续为这10000个监控项配置触发器和告警规则。在Zabbix中，我们只需要创建一个模板，定义底层的发现规则，并将这个模板与需要监控的100台服务器相关联。Zabbix会根据服务器实际的磁盘数量自动生成相应的监控项，大大提高了添加监控的效率，也减少了手动添加监控的失误。自动发现：可以帮助我们快速发现网络中的设备，根据规则识别其类型，并与指定的模板关联起来。全栈级监控：正如刚才所说，Zabbix在监控的广度和深度上做了很好的权衡。它是一个全栈级监控平台。从底层的硬件、操作系统、中间件、数据库，到上层的应用和业务，都可以纳入Zabbix的监控范围。采用统一的监控平台覆盖所有监控对象不同层级的监控需求，同时减少维护多个监控平台的成本和所需的知识积累，简单易用。可定制，与DevOps管道集成：Zabbix本身也是一个开放系统。提供丰富的API，可以实现接口上几乎所有的功能，可以与企业内部的DevOps持续交付流水线集成，提升整体自动化水平。Zabbix全栈自动化监控实践案例下面我们来探讨一下Zabbix高级特性在实际使用场景中的最佳实践案例。分布式自动监控先来看看我们是如何通过自动发现功能自动添加监控的：我们会在Zabbix中配置自动发现规则，比如我们扫描指定的网段。当我们发现该网段某个IP的1433端口是开放的时，我们基本可以推断其上运行着MicrosoftSQLServer服务。因此，我们通过配置的规则，将查到的IP与SQLServer模板开放的1433端口关联起来。SQLServer模板是我们为微软数据库预先定制的监控模板。通过自动发现，我们可以实现两个目标：监控所有Microsoft数据库。所有被监控的数据库都使用同一套监控基线来实现标准化监控。同样的，我们也可以通过自定义不同的规则来添加不同类型的监控，比如3306就是MySQL监控等。除了关联模板，我们还会将监控对象添加到不同的组中，保证每个组都关联到对应的运维人员。这样做的好处是我们不需要经常更新告警策略，当出现故障时，相应的管理员也可以第一时间收到告警。二维管理（平台维度/业务维度）刚刚提到了群体的概念。在我们的实际应用中，一个监控对象属于两个组，即P组（平台组）和S组（业务组）。IT运维人员和业务人员的视角存在差异。通常，组织会雇用具有不同角色的IT专业人员，例如Windows管理员、Linux管理员和DBA。DBA将负责所有与数据库相关的运维工作，并不关心数据库属于哪个应用系统。所以所有的数据库服务器，就像所有的MySQL一样，都被放在一个叫做P-DB-MySQL的组中。该组中的所有告警将发送给指定的DBA，而不是Windows管理员，并与相应的MySQL监控模板相关联。这样做的好处是DBA只接收他们负责的系统的警报，并且监控是标准化的。业务人员关心的是整体业务应用是否正常运行。例如，一个登录系统可能有一个前端的Tomcat中间件，一个存储用户登录信息的MySQL，还有一个运行在底层的HP服务器。然后我们将这三个监控对象放在一个组中，叫做S-Department1-Login。这样做的好处是，一旦某个监控对象出现问题，我们可以第一时间知道影响到什么系统。通过P组和S组的组合，我们可以在不漏掉监控告警的情况下，将监控噪音降到最低，同时可以直观的知道当前的问题会影响到哪些业务。告警方式Zabbix支持非常多的告警方式，类似于Prometheus的AlertManager。首先我们对告警进行分类。Zabbix原生提供了5个级别的告警，分别是Disaster、High、Warning、Average和Info。我们使用其中的三个，并给出这三个级别告警的定义：灾难：触发后需要立即处理的告警。如果不加以处理，将直接影响生产系统。警告：触发后需尽快处理。如果短时间内不处理，不会对生产系统造成直接影响。信息：信息报警。不同级别的告警会对应不同的策略。例如，灾难警报将发送给IT经理和系统管理员；警告警报只会发送给系统管理员；信息不会发出警报，但会显示在监控大屏幕上。具体的告警分类和策略可以根据企业内部的实际情况和监控需求进行定制。告警的呈现方式主要有邮件、短信、监控大屏。多路报警确保我们的报警不会被遗漏。同时，我们也会细化告警内容的定制，包括告警状态（Problem或OK）、具体问题、发生问题的服务器和IP、问题的具体值。另外，我们也会在内容中添加告警对应的系统负责人姓名和联系方式，以便我们7x24的NOC在第一时间联系到相应的运维人员处理故障并减少停机时间。在我们的监控大屏上，也会显示各个系统目前的状态，具体的问题也会显示出来。灾害级告警用红色标注，预警级告警用黄色标注。持续集成/持续交付在之前的分享中提到，Zabbix提供了一个API。基于Zabbix的API，我们将其集成到DevOps持续交付流水线中。持续集成平台Jenkins在从版本控制系统Git中拉取代码构建，并通过Ansible等配置管理工具发布应用时，会调用ZabbixAPI将对应主机置于维护模式，从而避免监控时应用程序被释放噪声。同时，Zabbix也会通过基础信息的采集，为CMDB配置管理数据库提供数据。触发告警时，调用微信、邮箱等平台接口触发告警。通过与其他平台的整合，形成一个完整的持续交付闭环。带外管理自动化当物理服务器数量大幅增加时，硬件巡检是最耗脑的问题。硬件故障具有随机性。大多数组织通过定期手动检查来观察硬件故障。而一些机构会使用服务器自带的带外管理平台，如惠普的iLo、华为的iBMC、戴尔的iDrac等，进行带外管理。当一个机房有多台服务器时，如果仅仅依靠这些平台，除了昂贵的license授权外，管理成本也非常高。就算这些问题都解决了，那些只支持SNMP的网络设备和存储呢？我们来看看Zabbix是如何解决的：我们将Zabbix部署在一个带外管理网络中，这个网络会有一个DHCP服务器自动为所有设备分配IP地址。Zabbix将在这个带外网络中有一个Proxy代理服务器。通过Zabbix的自动发现功能，将所有带外地址添加到Zabbix；通过IPMI或SNMP标准协议应用监控模板，实现统一监控。采集到的带外数据可以作为重要的硬件信息存入CMDB配置管理数据库。Zabbix的带外管理大大节省了带外管理平台的授权费用，降低了带外管理的成本，实现了统一带外管理的目标。以上就是Zabbix在落地过程中的案例和最佳实践。总结如何选择监控平台如果我们只在Prometheus和Zabbix之间二选一，我们应该如何选择一个合适的监控平台呢？我的建议是：当环境是纯容器环境时，毫无疑问Prometheus是更合适的选择，Prometheus是为容器化平台打造的监控系统。而当我们的环境非常复杂，有各种操作系统、硬件、中间件、数据库等等，那么Zabbix是一个比较合适的监控平台。Zabbix兼顾了监控的深度和广度，实现了统一监控平台的目的。当整个环境中有容器等系统，又想使用监控系统，那么Zabbix就比较适合，因为最新版本的Zabbix增强了容器化监控功能。当然，如果你有余力，也可以采用两套监控系统，取长补短。使用Zabbix的好处Zabbix拥有简单易用的UI，自带的Graph和Screen也能满足企业级的展示需求。90%以上的配置都可以通过web统一操作实现，比严重依赖配置文件的Prometheus更加方便。当然，如果你对Zabbix原生的UI不满意，你仍然可以像Prometheus一样接入Grafana，大大降低了二次开发的成本。基于平台组和业务组的二维分组也使得Zabbix能够为同一组织内的不同团队提供更加个性化的呈现。Zabbix开源、免费的特点，让越来越多的企业，尤其是自主开发能力不强的中小企业，能够快速实现全栈监控。Zabbix几乎可以覆盖80%甚至更多的监控需求，其先进的特性也大大减少了人工干预，提高了自动化能力，并且可以与其他系统和平台持续集成。目前Zabbix社区非常活跃，拥有丰富的学习资源，大大降低了学习成本。也欢迎大家在使用Zabbix过程中遇到的问题或改进建议向我或Zabbix社区积极反馈。我们也希望通过不断的迭代优化，让它成为一个更好的监控平台。作者：蔡向华简介：Zabbix认证专家，国内首批Zabbix认证专家，DevOpsMaster。活跃于Zabbix和DevOps社区，参与《DevOps 最佳实践》和《Zabbix 官方手册》的翻译；10年四大和银行IT基础架构经验，7年Zabbix和DevOps经验。编辑：陶佳龙来源：转载自?DBAplus社区（ID：dbaplus），本文根据蔡向华先生在〖deeplus直播》在线演讲分享的内容整理而成《运维监控谈：比较与比较》Prometheus和Zabbix之间的选择》。
