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