企业级监控系统-监控企业什么意思-厂级监控系统
最近几年一直使用监控系统，主要使用了两种监控工具。对于这两个监控系统，我们有一些在使用实践方面的经验。现在通过对比的方式来和大家分享这些经验。一、 和的出现和发展
是监控系统中很流行的工具，也很流行。比出现得更早，在 2001 年发布了 0.1。那时时序数据库尚未应用于监控领域，基于当时的环境，采用了关系型数据库来存储数据。
到 2016 年，时序数据库彻底火了起来。
现在的发展节奏是每 6 个月推出一个稳定版本，每 2 年推出一个大版本。当前处于 5.x 版本，并且 6.x 版本也在规划之中。
以每 6 周为一个小版本进行迭代，正逐步向前推进。目前处于 2.X 时代，最新的版本是 2.30.0。
当前时间节点下，即将发布 2.31.0，同时也已经发布了 5.4.0。我们看到了时序数据库在监控领域的前景，从 5.x 开始支持使用时序数据库来存储数据，并且在 4.4 时就已经支持将收集的数据存储在自己的关系型数据库中。从企业级监控系统的角度出发，开始对包含各种监控工具予以支持，进而朝着一个臃肿的大而全的系统方向演进，同时开始在小范围内尝试新的技术。依据自身最初的设计，仅仅负责监控工作，其他部分交由更专业的人员去做，以时序数据库为基础，持续进行优化，提升性能。目前看来，它基本已经成为云原生监控系统的实际标准，是最佳的选择。 扎根企业市场以功能大而全的优点毅力不倒。
二、和的优缺点
最近在使用时，被同事写的一个接口调用的 bug 致使主机信息、模版信息以及它们的关联关系全部丢失。由于配置了自动注册，在这些数据丢失之后，Agent 又进行了一次自身注册。接着，在通过备份数据恢复时，这两部分出现了冲突，需要一个表一个表地去解决问题。恢复完毕后，这个事情又再次发生了。第一次恢复紧急恢复的时间是一晚上十几个小时，全部恢复大概花费一周时间。而第二次全部恢复仅花了两个小时。
另外一件事是版本升级。因为一些安全方面的原因以及实际遇到的 BUG，我们决定对其进行版本升级。仅仅从 4.4.0 升级到 4.4.10 就花费了大约一周时间，期间进行了各种测试，还通过升级回滚来解决问题。当然，这也与当前的部署结构有关，比如结构不合理、负载不均衡等情况。
这个月主要就耗费在这里了。
针对总结一下，有以下的优点：
监控模版能够包含多个指标。在不涉及自定义采集脚本以及其他方式时，倘若使用 SNMP 或者 Agent，便可以实现开箱即用。
2、指标和触发器（的告警规则叫触发器）的关联交互挺好用；
https://img1.baidu.com/it/u=3875028589,491713474&fm=253&fmt=JPEG&app=120&f=JPEG?w=889&h=500
宏和宏变量的使用能够显著提高告警的便捷性，基本上能够针对每个 label 设置不同的阈值。
的指标采集较为丰富，其中包含采集间隔这一方面，同时还涉及是要一直进行采集，还是每天在固定的时间段来进行采集。
企业级软件的管理页面，它很大一部分的优势是通过这个页面来体现的，这确实不愧是企业级软件所具备的特点。
说完了优点来看看缺点：
架构原生为单点，不存在集群方案。官方推荐通过某种方式来实现 3 个点的负载均衡。此方案在现今仍具有较大的优化空间。
的数据存储采用关系型数据库。在 刚发布之际，当时没有其他选择，但如今来看，这是个很大的问题。随着指标数量的增加，数据的存储空间以及查询时间都变得极为恐怖。当前用 6TiB 的空间存储每帧 80 万条数据，采集间隔为一分钟，详细数据保留 1 个月，历史数据约 1 年半。相比之下，其他存储方式会节省很多。可以支持更大的数据收集规模，只是不清楚资源会以何种比例增长。
升级变得复杂起来。在体验了从 4.4.0 升级到 4.4.10 之后，发现升级过程十分麻烦。建议你的团队最好配置一位 DBA 来处理各种相关问题。
和 的结合状况不佳，语句写出来显得比较生硬，虽能使用，但在灵活性方面不如 。
这个月我进行了例行升级，大概花费了一个小时。我升级了十多个实例以及配套的和存储数据的 Minio。与之前相比，这让我感觉很舒服。
具备以下优点：
结构较为简单，不过能够进行水平扩展。通过与其他部分相结合，能够实现无缝的水平扩展。如果不喜欢某种方式，也可以利用自带的联邦功能来进行扩展。其思想在于：我尽量保持简单但又好用，而其余的功能可以交给其他人去完成。
采用时序数据库，存储空间得到了大大的节省，同时查询效率也得到了提升。我用 3TiB 的空间来存储每帧 300 万条数据，其中 30 秒采集一次的数据约有 120 万条，这些数据 15 秒采集一次。详细数据可以存储 2 个月，5 分钟降准数据能存储半年，一小时降准数据可存储一年，并且在此过程中不需要 DBA 参与。
采集配置较为简单，只需进行简单配置，之后便能收取丰富的指标，无需逐个指标去添加。
原生具备收集众多服务所暴露的监控数据的能力，然而要收集应用自身所提供的监控数据则较为困难。
对于 的缺点，
https://img1.baidu.com/it/u=1214168991,3731646719&fm=253&fmt=JPEG&app=138&f=JPEG?w=650&h=500
当前告警规则不能快速地对每个 label 设定一个阈值。要么采用统一的阈值，要么为每个 label 设定一条规则。当数量增多后，确实不好进行管理。如果大家在这方面有好的办法，还请指导我一下。
其他感觉和 比起来没啥缺点了。
另外一个不同点在于，若采集内容较多，会出现一台机器上有多个 Agent 的情况。就这方面而言，虽然只有一个 Agent，但很多内容需自己编写采集脚本，不过 Agent 比自己编写脚本的可靠性要高一些。此外，对于单节点多 Agent 的情况，也存在相应的解决方案。
三、 和的适用场景
在使用的过程中，曾把和放在不同场景下使用过，包括单个集群场景、多个集群场景、超级集群场景以及企业业务环境等场景。
我们先来看看集群环境。
对于单个中小规模的集群（500 节点以下或 1000 节点以下）而言，使用某种工具与使用另一种工具没有差别。无论是使用哪种工具，只要做好规划和设计，其使用起来基本都不会有问题。单机的资源使用情况、数据库所受压力以及场景的复杂程度，都不是特别大的问题。可以随意使用。
对于多集群而言，我们需考虑节点的资源使用状况，需考虑数据库的压力承载状况，需考虑集群扩展的方便性。当节点数量呈直线上升态势时，数据库的压力会持续增大，对单点数据库的配置要求会越来越高。当数量达到一定规模后，单点无法支撑该规模的系统，然而官方并未给出良好的集群方案。当节点规模增大时，数据库的压力会增大。监控数据的查询会变得很慢。为解决遇到的问题，数据库会变成一个集群。硬件资源的成本会直线上升。对于集群扩展，可基于自动注册和 Proxy 来实现。而数据是通过 Agent 推送回来的。当想要摘除被监控集群时，操作很繁琐。
对于某些情况而言，在存在多集群的情况下，能够让每个集群都使用一个特定的东西，借助某种方式来进行汇总。这样一来，水平扩展会特别便捷，也不会出现单点压力过大的状况。同时，还可以通过 Label 把不同的集群区分开来，单点所承载的节点能力比另一种方式要强很多。并且，利用时序数据库来存储监控数据，能够用极少的硬件资源提供更为强大的查询能力。使用 Agent 从开始到结束进行拉取来获取数据，能够在本地端轻松地操作采集那些节点，也可以放弃对某些节点的采集。
对于单集群节点数超过 5000 的超级集群，建议直接使用某方式。这样就可以不用之前的方式了，因为两者性能相差太多。在不考虑冗余的情形下，单点能够支持 5000 节点存储 1 个月的监控数据，而使用同配置的机器至少需要 3 到 4 台才能达到相同效果。并且某方式相较于之前的方式，维护更简单，使用也更方便。
企业的业务环境中，当节点数量超过 2000 台，业务服务数量大于 1000 个时，建议直接进行相关操作。此时需要一个完整的监控观测系统，要与 、Kafka、Redis、MySQL 等中间件以及各种系统相结合，直接获取服务自身所暴露的监控指标。在这种场景下，某种方式或产品是最适合的。与其他中间件的结合情况不佳，仅能完全依靠自定义脚本去实现，并未依托社区的力量。
四、小结
对于 和 的选取主要依据自身的使用场景。 和 都存在大规模被使用的场景。在使用的过程中，选取适合自己的才是最为恰当的。
我一直在持续使用和，也在持续探索验证很多新的特性和功能，若有新的发现，会与大家分享。
页:
[1]