新规实施：申请手机号码将全面实行人脸比对
06-18
监控建设之道 温馨提示：本文内容较多，读完大概需要10分钟。本文包含以下内容： 1. 什么是监控 - 凡事皆有预谋，失败必将失败 2. 监控建设现状 - 千里之行始于足下 3. 监控建设面临的挑战- 我会从上到下探索 4. 监控建设的实践 - 纸上学的终究是肤浅的。
5、监控建设总结——历经千辛万苦，忆往昔。在正式阅读本文之前，我们先思考一个问题——几乎每个IT公司都有自己的运维监控系统。
每个公司都有自己的运维监控系统。公司运维都在开发监控系统，似乎每个公司都面临着一个问题。
监控系统使用不方便，无法解决实际监控问题。有没有更好的监控系统？答案是肯定的，本文将为您揭晓答案。
1.什么是监控——一切都提前做好，否则就毁了。运维说：监控是业务中的大事，是生死存亡之所，是生存之道。
必须遵守[1]。 监视的建设不亚于战争的准备。
无论是使用监控的用户还是构建监控的人都面临着监控是否好用、好用的实际挑战。因此，我们必须充分认识、认识监控。
监控，顾名思义，就是监视和控制。重点是第一个字“监控”，即监控、预防的意思。
在计算机运维领域，特指从目标状态中采样数据来判断其运行状态的一种方式。通常我们会重点关注以下监测数据[2]。
在本文中，我们重点关注最后四种类型的监控。由于APM属于特定领域监控，这里不做详细讨论。
那么，既然用户关心如此多的监控数据，那么如何构建满足业务需求的监控呢？有没有一种监控系统能够完全满足用户的监控需求？ 2、监控建设现状——千里之行，始于足下。监控平台的建设是一个长期的过程，不是一朝一夕就能完成的。
一般来说有四种玩法，一是基于开源监控平台，二是利用商业平台搭建，三是开源产品二次开发，四是完全自主研发。每种玩法都有其自身的特点和局限性。
1、基于开源监控软件搭建监控平台。您可以选择Nagios、Cacti、Ganglia、Zabbix、Graphite、Prometheus、TIGK（Telegraf、InfluxDB、Grafana、Kapacitor）等。
通常您只需要部署开源软件，然后丰富数据收集即可。能。
其特点是开源、社区解决方案众多、自由定制。2、基于商业软件搭建监控平台。
在商用监控领域，以前都是国外公司把持，比如IBM、HP、卓豪等，但随着本土基础设施厂商的崛起，国内厂商也在发力，有的已经崭露头角。优秀的商业监控软件，如云智能、监控易、OneAPM等，以及一些针对专有场景的监控软件。
其特点是只要花钱，就可以实现相应的监控服务，省去了监控建设的重复探索。适用于监控场景复杂、人力缺乏、急需监控解决方案的项目。
3、搭建基于开源软件二次开发的监控平台。开源软件本身功能齐全，比如提供API，提供数据查询接口，可以通过API进行管理和控制，比如基于Zabbix、Prometheus、Open-falcon等进行二次开发，可以实现完整的监控功能和友好的管理功能。
其特点是可以按需扩展监控采集源、按需集成、自由定制。如果您对现有软件提供的功能不满意，可以根据场景灵活定制。
建议“花钱买服务不能解决问题”时使用。的。
4、基于自主研发，从无到有搭建监控平台是一项浩大的工程，对技术和项目管理都是很大的挑战。为什么需要从头开始独立开发监控系统？原因可能有以下几点： 1、市场上的监控软件不能满足其业务需求，功能不够充分，性能不理想，管理不够支持其业务和组织架构的发展。
; 2、生态系统无法满足业务发展需求； 3、基于开源软件进行版权二次开发存在风险，受他人约束； 4、有业务需要、管理支持、技术人员充足、天时、地利、人和。其特点是开发周期长，目标期望与现实存在差距，开发速度和业务发展速度能否及时跟进。
如果不小心，软件项目就有失控的风险。考验的是项目管理水平和工程实现能力。
从以上四种方法来看，实施成本由低到高、由易到难。具体采用何种方法需要根据实际情况确定。
那么，主要取决于什么呢？人力、物力、财力也与企业所处的阶段密切相关。如果公司刚刚起步，追求速度和成本，花半天时间搭建一个开源监控系统是明智的选择。
你选择哪一款开源软件，可以选择你最熟悉、用户数量最多的一款。公司已初具规模，业务需求较多。
如果选择商业监控软件并基于开源进行二次开发，可以根据具体业务需求进行详细评估。规则是，花多少成本换取多少效益，而且还要考虑效益是否是长期的。
是的，这仍然是短期的。当企业发展到一定规模时，其组织架构和业务需求决定了软件架构需求。
所以，此时的监控系统也必须具备这种能力。因此，此时构建基础设施不仅仅关乎业务需求和产品能力。
这个问题与战略规划密切相关。因此，是选择完全自主开发，还是选择商业、开源的优秀产品二次开发，都是一个可选的方向。
取决于组织的技术储备和执行能力，天时、地利、人和。连一个都没有。
正如《孙子》所说：诸用兵法，千乘战车，千皮车，十万甲胄，万里粮草，内外费用，宾客之用，所用之物。胶水和油漆，还有战车和铠甲的支撑，都需要花费大量的资金，然后需要数十万人才能完成[3]”。
相应监控的独立开发需要项目、产品、设计、开发、测试、运维、运营等各类人员的参与。几个月后，它被释放。
演示、测试、验证，迭代一次又一次，十万台服务器可以监控。自主开发需要消耗人力、物力、财力，就像备战一样。
不应贸然采取行动，需要详细而仔细的计划才能采取行动。 3、监控建设的挑战——我会从上到下进行探索。
在第二节中，我们讨论了监控建设方案的选择。那么，除了上述问题之外，我们在施工过程中还存在哪些问题呢？ 1、关键系统指标缺失 监控建设从来都是一个持续的过程，没有一劳永逸的解决方案。
在持续监控和运维中，我们不断丰富和完善相关监控。常见的系统级和应用级监控指标如下。
从上图可以看出，具体监控用户的监控指标采集范围非常广泛。无论市场上哪种监控系统，其提供的默认监控指标都可能无法满足实际场景的需求。
随着监控系统的不断运行和业务的不断发展，采集更多监控指标的需求将变得越来越迫切。因此，我们希望监控系统能够提供自由扩展和灵活定制的能力。
2.功能扩展困难。在监测系统建设过程中，我们根据实际需要不断完善采集指标。
因此，监控平台原生是否支持多种采集方式可能会限制我们能力的发挥。例如，要监控网络、存储等硬件设备，我们必须使用SNMP协议来获取监控指标数据。
这应该是一个内置的平台之一。基本能力。
如果要我们自己从头实现的话，就相当于写了一个小型的监控软件。因此，这个监控系统应该提供扩展能力，要么开源代码，要么开放接口。
我们可以根据实际需要扩展模块和组件，以满足我们业务不断发展的需要。随着监测指标不断扩大，需要存储的指标数据量也会随之增加。
这时候对监控系统的QPS就有非常高的要求。监控系统能否支持高并发请求，直接决定了监控系统能否使用。
试想一下，如果监控系统每三天就出现问题，用户可能会失去甚至放弃使用该监控系统，而寻求更好的解决方案。 监控用户在使用过程中，对监控平台的预期SLA可能是%，但实际能达到的SLA可能是99.9%（每年停机时间约9小时）。
随着业务和技术的不断发展，监控用户对监控系统的要求越来越高。 SLA 可以继续改进吗？时间 99% 99.9% 99.99% 99.% 每天 14 分 24 秒 1 分 26 秒 9 秒 1 秒 每周 1 小时 40 分 48 秒 10 分 5 秒 1 分 6 秒 每月 7小时、12 分钟、43 分钟、12 秒 4 分钟 19 秒 26 秒 每年 3 天 15 小时 36 分钟 8 小时 45 分钟 36 秒 52 分钟 34 秒 5 分钟 15 秒 事实上，SLA 的改进是 19，这构成对系统带来很大的挑战，比如我们的架构是否支持，架构设计是否合理，架构是否冗余，是否可以支持水平扩展，是否存在单点故障，服务器资源是否充足、系统并发量是否呈直线等诸多因素直接决定了我们提供的监控系统的SLA能否持续提升？理想的情况是架构具有冗余。
当链路出现故障时，可以自动切换，并由备份机接管。当容量不足时，可以通过添加服务器来扩展容量，并且可以自动平衡负载。
因此，我们在设计监控系统时，一定要学习互联网架构中的高并发、高可用、分布式的架构设计方案。从此，无论是增加功能模块还是升级整个系统，有了架构保障，就可以按需进行升级和扩展，无需担心系统可用性。
用户不会意识到升级、更改和扩展。3. 系统可靠性得不到保证。
当监控主机规模达到10000台设备时，通用监控系统就会出现瓶颈。系统的QPS持续增长。
能否支持7*24小时稳定运行是一个非常重要的问题。最大的挑战是监控系统一直是一个高并发的系统。
同时，它也是一个大型数据库系统。比如每天新增5T、10T、50T数据，需要详细的历史数据。
保存期限需要7天或30天。 ，甚至1年，而趋势数据（归档历史数据，如每小时的最大值、最小值、平均值存储）则要求保留1年、2年甚至更长，那么监控系统的数据可能达到PB数据层面，其数据处理方式与海量大数据处理系统类似，采集->清洗->分析->入库->使用。
数据报告延迟的一般原因有以下三个。首先是收集器的问题，导致数据无法按照既定的周期进行收集，或者因为原始数据不存在，或者因为收集器已经达到了自身的性能极限；二是监控系统的清理。
，处理分析环节被阻塞，即采集、上报正常，但数据未入库；第三，数据处理后无法正常放入数据库，即监控的数据库有问题，即数据写入慢、查询慢、数据库超出限制。上限。
这三种情况，无论是哪一种，对于用户来说都是无法实现的。 无误报、无漏报、无延迟是监控系统的基本要求。
误报是数据处理中的问题，会降低用户对监控的信任。如果误报长期存在，用户就会对监控失去信任，逐渐放弃监控系统。
漏接警报是指本来应该发送但没有发送的警报。这种情况就更加严重了。
严重影响用户的正常使用，严重降低用户的期望。就像一架延误的飞机，无法按时到达目的地。
延迟是指现在产生警报但明天收到警报。这种情况表明监控系统处于不可用状态。
当故障应该发生时，却没有收到警报。当故障结束时，发出警报。
用户会完全不信任监控系统。如果监控系统连报警这个基本的事情都做不好，那么它就不是一个合格的监控系统，用户会把监控系统视为噪音。
当我们上报数据并解决报警问题后，系统可以正常工作，但我们又会面临新的问题。用户反馈，报警能不能做得更智能一些？试想一下，报警模块正常工作，用户每天收到1个报警，甚至0个报警，用户会发疯。
这简直就是一个警报“轰炸机”。过多的警报会变成噪音，干扰正常判断。
因此，告警能否收敛的问题就成为了重中之重。告警汇聚是指将策略相同、目标范围不同的多个告警进行组合发送，并按照一定的规则进行汇聚的告警发送方式。
例如，我们的某个云区域出现网络故障，会导致该区域的所有设备无法访问。然后会一一发送 ping 不可达警报。
如果该区域有机器，是否应该发送警报？它还是一个好东西吗？我相信大多数普通人只希望收到一个重要警报。报警收敛大大提高了报警的准确性，真正做到了运筹帷幄，不慌不忙。
不会让我们每天都紧张，让我们每天处于狼来了的境地，因为太多的闹钟会带来很多麻烦。青蛙效应使我们逐渐失去对警报的敏感度，渐渐地我们会因为警报太多而根本不会去注意。
有了警报汇聚，我们就可以高枕无忧了吗？不，我们还需要故障关联和自动故障分析。为什么我们需要这个功能？想象一下，一个机架停电，导致15台设备全部宕机，导致API超时、HTTP拨号测试失败、DB连接数增加等一系列故障。
能找到根本原因吗？能否提供一个重要的告警来帮助我们自动分析故障的根本原因？这时，故障关联和自动故障分析就显得尤为重要。因此，监控系统必须具备进行故障关联分析的能力，为我们的运维决策提供更加准确的信息。
另外，监控系统是否能够对当前环境的性能进行分析，系统容量分析也将是一个重要的能力，比如趋势预测，什么时候应该为业务扩容服务器容量，什么时候应该缩容服务器容量？目前性能是否足够，是否还有优化的空间。监控系统，因为有数据，可以提供这一系列数据作为重要依据。
4、技术落后于业务发展。随着业务的不断发展，组织架构将根据业务形态进行调整。
不同的人员需要对应不同的权限，需要划分更多的角色，如超级管理员、分级管理员、普通管理员等。普通用户甚至在菜单按钮层面还有更细粒度的权限控制需求。
如果监控系统从一开始就不考虑这些需求，就很难应对业务的增长需求。随着业务的发展，企业可以将一些日常事务外包，以降低成本。
这时，权力的层级控制就显得尤为重要。此时，监控系统不再是一个孤立的系统。
必须与统一的用户登录认证系统集成，实现配置与查询分离，以满足组织的业务发展。随着业务的不断发展，业务对监控系统提出了更高的要求，比如要求“微秒级监控数据采样”、要求“秒级报警”、要求监控系统提供%的可靠信息等。
根据监控系统提供的系统容量指标，使用数据对业务应用的目标服务器和容器进行扩容或缩容。监控系统作为底层依赖系统，此时就会发挥更大的作用。
4、监测建设实践——纸面上的成果很浅薄。在建设监控系统时，我们意识到了上述问题。
那么，我们如何解决以上问题呢？接下来我们详细看看具体的做法[4]。 1、降低使用门槛——对于服务器设备，开箱即可使用。
系统初始化后，默认安装Agent。无需任何配置即可采集主机监控数据。
如果CMDB中配置了进程信息，则会收集进程状态。数据。
基本流程指标如下 2、告别警报风暴。当主机默认连接时，可以自动添加默认报警策略。
如果达到阈值，则可以生成警报。如下图所示，包含了一些默认的报警策略。
为了防止过多的警报对用户造成干扰，我们使用了四个魔术来确保用户收到的警报有效。技巧 1 - 警报收敛。
在如下所示的事件中可以看出，收敛规则有效地降低了告警事件的收敛性，并且生成的事件与通知的比例为1:，甚至更高。设计原生支持的告警汇聚功能，有效防止告警风暴的发生。
提示 2 - 警报抑制。通常，由于用户的实际需求不同，会对同一报警内容配置不同的阈值。
例如，如果配置磁盘空间使用警报，则有80%警告、90%警告和95%严重。那么这三种策略如何发挥作用呢？如果当前磁盘空间使用率达到96%，是否会产生3条报警通知？实际情况下，如果监控系统发出三个报警，用户就会认为监控系统弱智。
因此，对于相同纬度的策略，我们只会发送告警级别的告警，即只会生成95%严重级别的告警通知。提示 3 - 警报摘要。
尽管我们的监控系统已经具备了报警汇聚和报警抑制两大功能，但仍然无法解决同时发送大量报警的问题。例如，如果同时满足多个报警规则，仍然可能发生报警洪水风暴。
因此，报警汇总功能确实很有必要。对于同时涌入的大量告警，对同一维度的告警进行汇总，对于不同策略，对告警进行合并。
有了报警汇总功能，我们就可以放心接收报警了。技巧 4 - 警报分析。
通过对历史报警数据的挖掘和分析，我们还可以发现异常报警，从而更好地分析原始数据和报警阈值，从而为报警配置和无阈值报警提供更好的数据支持。3. 功能扩展方便——即插即用。
4. 用户权限控制——按需授权。根据监控提供的功能，有两个基本的划分：查看和管理。
一般来说，有以下几种用户场景： 报警通知接收者：如运维、开发、测试、产品等。适用于应用查看、拦截操作。
监控配置器：如运维等。适合申请查看+管理操作。
监控平台管理器：全球适用的功能。 5.自动化的基石——效率优先。
与其他监控系统不同的是，定义采集可以直接在系统中完成，无需使用其他第三方控制系统或登录服务器部署。所有的配置都可以在界面上完成，包括插件的编写。
我们只需要打开创建插件的页面即可。 动态采集目标，当模块内主机数量增加或减少时，可以自动将插件下发到目标机器，无法手动部署采集插件。
同理，报警策略中的目标范围也会自动匹配。新添加的主机或模块无需编辑策略，范围自动生效。
5、监控建设总结——历经战事忆往昔。在监控平台建设的过程中，通过不断实践、不断总结经验，监控平台建设的功能会逐渐成熟。
但如果只把搭建监控平台作为核心目标，那么你会遇到监控本身以外的问题，比如发布和监控如何结合，发布过程中如何屏蔽报警等。监控如何与CMDB联动，监控系统与运维自动化系统如何联动，监控与管道发布系统如何联动，监控与运维各方面如何联动？这个问题无法通过独立的监控系统来解决，而是需要一个可扩展、可定制的运维平台。
回顾监控体系建设，我们总结出以下经验： 1、确定目标，明确需求。请不要盲目行动。
仔细分析业务需求，然后选择相应的监控方案，明确业务需求规划和项目规划，明确自己需要烟囱监控系统还是可互操作的运维平台系统？ 2、尽量使用成熟稳定的开源平台，如Zabbix、Pormetheus等，如果监控规模过大，可能会出现性能等使用问题。在这里，笔者推荐使用像蓝鲸[5]这样成熟稳定的平台，可以有效解决容量和性能问题，因为蓝鲸平台天然支持海量并发场景，并且可以横向扩展。
如果遇到容量不足的问题，只需扩展相应的服务模块即可。 3、随着业务的不断发展和技术的不断迭代更新，监控系统将不断优化总结，迭代更新。
因此，没有一劳永逸的解决方案，只有不断的动态发展平衡。4、我们需要从软件设计者的角度来构建一个监控系统。
面对监控需求，我们应该从现象到本质，更好地满足使用场景，而不是仅仅把它当作一个工具，因为监控和运维是息息相关的，需要从数据生产到消费，并且再进行分析关联，有助于运维目标——“提效率、提质量、提能源”。 所以运维说：监控是业务大事，是生死存亡之所，是生存之道，必须遵守[1]。
下载体验欢迎到蓝鲸智云官网（下载社区版本6.0进行体验。参考文献[1]。
《孙子兵法.计篇》第一句话[2]。 《孙子兵法.作战篇》[4]。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-17
06-17
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用