怎样将自己做的网站给别人看,网站建设 客户拜访,中国行业信息网,网站开发薪水一般多少简介#xff1a; 对于建设一套公司内部使用的监控系统平台#xff0c;相对来说可选的方案还是非常多的#xff0c;无论是用开源方案自建还是使用商业的SaaS化产品#xff0c;都有比较多的可选项。但无论是开源方案还是商业的SaaS产品#xff0c;真正实施起来都需要考虑如何…简介 对于建设一套公司内部使用的监控系统平台相对来说可选的方案还是非常多的无论是用开源方案自建还是使用商业的SaaS化产品都有比较多的可选项。但无论是开源方案还是商业的SaaS产品真正实施起来都需要考虑如何将数据给到监控平台或者说监控平台如何获取到这些数据。这里就涉及到数据获取方式的选型Pull拉还是Push推模式 作者 | 元乙 来源 | 阿里技术公众号
一 形形色色的监控系统
监控一直是IT系统中的核心组成部分负责问题的发现以及辅助性的定位。无论是传统运维、SRE、DevOps、开发者都需要关注监控系统并参与到监控系统的建设和优化。从最开始大型机的作业系统、Linux基础指标监控系统就已经开始出现并逐渐演进现阶段能够搜索到的监控系统不下于上百种按照不同类别也有非常多的划分方式例如
监控对象通用型通用的监控方式适应于大部分的监控对象专一型为某一功能定制例如Java的JMX系统、CPU的高温保护、硬盘的断电保护、UPS切换系统、交换机监控系统、专线监控等数据获取方式PushCollectD、Zabbix、InfluxDBPullPrometheus、SNMP、JMX部署方式耦合式和被监控系统在一起部署单机单机单实例部署分布式可以横向扩展SaaS化很多商业的公司提供SaaS的方式无需部署数据获取方式接口型只能通过某些API拿去DSL可以有一些计算例如PromQL、GraphQLSQL标准SQL、类SQL商业属性开源免费例如Prometheus、InfluxDB单机版开源商业型例如InfluxDB集群版、Elastic Search X-Pack闭源商业型例如DataDog、Splunk、AWS Cloud Watch
二 Pull or Push
对于建设一套公司内部使用的监控系统平台相对来说可选的方案还是非常多的无论是用开源方案自建还是使用商业的SaaS化产品都有比较多的可选项。但无论是开源方案还是商业的SaaS产品真正实施起来都需要考虑如何将数据给到监控平台或者说监控平台如何获取到这些数据。这里就涉及到数据获取方式的选型Pull拉还是Push推模式 基于Pull类型的监控系统顾名思义是由监控系统主动去获取指标需要被监控的对象能够具备被远端访问的能力基于Push类型的监控系统不主动获取数据而是由监控对象主动推送指标。两种方式在非常多的地方都有区别对于监控系统的建设和选型来说一定要事先了解这两种方式各自的优劣选择合适的方案来实施否则如果盲目实施后续对监控系统的稳定性和部署运维代价来说将是灾难性的。
三 Pull vs Push概览
下面将从几个方面来展开介绍为了节约读者时间这里先用一个表格来做概要性的论述细节在后面会展开 四 原理与架构对比 如上图所示Pull模型数据获取的核心是Pull模块一般和监控的后端一起部署例如Prometheus核心组成包括
服务发现系统包括主机的服务发现一般依赖于公司内部自己的CMDB系统、应用服务发现例如Consul、PaaS服务发现例如KubernetesPull模块需要具备对这些服务发现系统的对接能力Pull核心模块除了服务发现部分外一般使用通用协议去远端拉取数据一般支持配置拉取间隔、超时间隔、指标过滤/Rename/简单的Process能力应用侧SDK支持监听某个固定端口来提供被Pull的能力由于各类中间件/其他系统不兼容Pull协议因此需要开发对应的Exporter的Agent支持拉取这些系统的指标并提供标准的Pull接口
Push模型相对比较简单
Push Agent支持拉取各类被监控对象的指标数据并推送到服务端可以和被监控系统耦合部署也可以单独部署ConfigCenter可选用来提供中心化的动态配置能力例如监控目标、采集间隔、指标过滤、指标处理、远端目标等应用侧SDK支持发送数据到监控后端或者发送到本地Agent通常是本地Agent也实现一套后端的接口
小结纯粹从部署复杂性上而言在中间件/其他系统的监控上Pull模型的部署方式太过复杂维护代价较高使用Push模式较为便捷应用提供Metrics端口或主动Push部署代价相差不大。
五 Pull的分布式解决方案 在扩展性上Push方式的数据采集天然就是分布式的在监控后端能力可以跟上的时候可以无限的横向扩展。相比之下Pull方式扩展较为麻烦需要
Pull模块与监控后端解耦Pull作为Agent单独部署Pull Agent需要做分布式的协同一般最简单是做Sharding例如从服务发现系统处获取被监控的机器列表对这些机器进行Hash后取模Sharding来决定由哪个Agent来负责Pull。新增一个配置中心可选用来管理各个PullAgent
相信反应快的同学已经看出来这种分布式的方式还是有一些问题
单点瓶颈还是存在所有的Agent都需要去请求服务发现模块Agent扩容后监控目标会变化容易产生数据重复或缺失
六 监控能力对比
1 监控目标存活性
存活性是监控所需要做的第一件也是最基础的工作Pull模式监控目标存活性相对来说非常简单直接在Pull的中心端就知道能否请求到目标端的指标如果失败也能知道一些简单的错误比如网络超时、对端拒绝连接等。
Push方式相对来说就比较麻烦应用没有上报可能是应用挂了也可能是网络问题也可能是迁移到了其他的节点上了因为Pull模块可以和服务发现实时联动但Push没有所以只有服务端再和服务发现交互才能知道具体失败的原因。
2 数据齐全度计算
数据齐全度这个概念在大型的监控系统中还是非常重要的比如监控一千个副本的交易应用的QPS这个指标需要结合一千个数据进行叠加如果没有数据齐全度的概念若配置QPS相比降低2%告警由于网络波动超过20个副本上报的数据延迟几秒那就会触发误报。因此在配置告警的时候还需要结合数据齐全度数据进行综合考虑。
数据齐全度的计算也一样是依赖于服务发现模块Pull方式是按照一轮一轮的方式进行拉取所以一轮拉取完毕后数据就是齐全的即使部分拉取失败也知道数据不全的百分比是多少
而Push方式由每个Agent、应用主动Push每个客户端的Push间隔、网络延迟都不一样需要服务端去根据历史情况计算数据齐全度相对代价比较大。
3 短生命周期/Serverless应用监控
在实际场景中短生命周期/Serverless的应用也有很多尤其是对成本友好的情况下我们会大量使用Job、弹性实例、无服务应用等例如渲染型的任务到达后启动一个弹性的计算实例执行完毕后立马销毁释放机器学习的训练Job、事件驱动的无服务工作流、定期执行的Job例如资源清理、容量检查、安全扫描等。这些应用通常生命周期极短可能在秒级或毫秒级Pull的定期模型极难去监控一般都需要使用Push的方式由应用主动推送监控数据。
为了应对这种短生命周期的应用纯Pull的系统都会提供一个中间层例如Prometheus的Push Gateway接受应用主动Push再提供Pull的端口给监控系统。但这就需要额外多个中间层的管理和运维成本而且由于是Pull模拟Push上报的延迟会升高而且还需要即使清理这些立即消失的指标。
4 灵活性与耦合度
从灵活性上来讲Pull模式稍微有一些优势可以在Pull模块配置到底想要哪些指标对指标做一些简单的计算/二次加工但这个优势也是相对的Push SDK/Agent也可以去配置这些参数借助于配置中心的存在配置管理起来也是很简单的。
从耦合度上讲Pull模型和后端的耦合度要低很多只需要提供一个后端可以理解的接口即可具体连接哪个后端后端需要哪些指标等不用关心相对分工比较明确应用开发者只需要暴露应用自己的指标即可由SRE监控系统管理者来获取这些指标Push模型相对来说耦合度要高一些应用需要配置后端的地址以及鉴权信息等但如果借助于本地的Push Agent应用只需要Push本地地址相对来说代价也并不大。
七 运维与成本对比
1 资源成本
从整体成本上讲两种方式总体的差别不大但从归属方角度来看
Pull模式核心消耗在监控系统侧应用侧的代价较低Push模式核心消耗在推送和Push Agent端监控系统侧的消耗相比Pull要小很多
2 运维成本
从运维角度上讲相对而言Pull模式的代价要稍高Pull模式需要运维的组件包括各类Exporter、服务发现、PullAgent、监控后端而Push模式只需要运维Push Agent、监控后端、配置中心可选部署方式一般是和监控后端一起。
这里需要注意的一点是Pull模式由于是服务端向客户端主动发起请求网络上需要考虑跨集群连通性、应用侧的网络防护ACL等相比Push的网络连通性比较简单只需要服务端提供一个可供各节点访问的域名/VIP即可。
八 Pull or Push如何选型
目前开源方案Pull模式的代表Prometheus的家族方案之所以称之为家族主要是默认单点的Prometheus扩展性受限社区有非常多Prometheus的分布式方案比如Thanos、VictoriaMetrics、Cortex等Push模式的代表InfluxDB的TICKTelegraf, InfluxDB, Chronograf, Kapacitor方案。这两种方案都有各自的优缺点在云原生的大背景下随着Prometheus在CNCF、Kubernetes带领下的大火很多开源软件都开始提供Prometheus模式的Pull端口但同时还有很多系统本身设计之初就难以提供Pull端口这些系统的监控相比而言使用Push Agent方式更为合理。
而应用本身到底该使用Pull还是Push一直没有一个很好的定论具体的选型还需要根据公司内部的实际场景例如如果公司集群的网络很复杂使用Push方式较为简单有很多短生命周期的应用需要使用Push方式移动端应用只能用Push方式系统本身就用Consul做服务发现只需要暴露Pull端口就可以很容易实施。
所以综合考虑情况下对于公司内部的监控系统来说应该同时具备Pull和Push的能力才是最优解
主机、进程、中间件监控使用Push AgentKubernetes等直接暴露Pull端口的使用Pull模式应用根据实际场景选择Pull or Push
九 SLS在Pull和Push上的策略
SLS目前支持日志Log、时序监控Metric、分布式链路追踪Trace的统一存储和分析。对于时序监控方案是兼容Prometheus的格式标准提供的也是标准的PromQL语法。面对数十万SLS的用户应用场景可能会千差万别不可能用单一的Pull或Push来对应所有客户需求。因此SLS在Pull和Push的选型上SLS并没有走单一路线而是兼容Pull和Push模型。此外对于开源社区和AgentSLS的策略是完全兼容开源生态而非自己去造一个闭合生态
Pull模型完全兼容Prometheus的Pull Scrap能力。可以使用Prometheus的Remote Write让Prometheus来做Pull的Agent和Prometheus Scrap一样能力的VMAgent也可以这样使用SLS自己的Agent Logtail也可以实现Prometheus的Scrap能力Push模型目前业界的监控PushAgent生态最完善的当属TelegrafSLS的Logtail内置了Telegraf可以支持所有的Telegraf的上百种监控插件相比VMAgent、Prometheus这类Pull Agent以及原生TelegrafSLS额外提供了最迫切的Agent配置中心和Agent监控能力可以在服务端去管理每个Agent的采集配置以及监控这些Agent的运行状态尽可能降低运维管理代价。
因此实际使用SLS进行监控方案的搭建会非常简单
在SLS的控制台Web页面去创建一个存储监控数据的MetricStore部署Logtail的Agent一行命令在控制台上配置监控数据的采集配置Pull、Push都可以
十 总结
本文主要介绍了监控系统中最纠结的Pull or Push选择问题笔者结合数年的实际经验以及遇到的各类客户场景对Pull和Push的各类方向进行了比对仅供大家在监控系统建设过程中参考也欢迎大家留言和讨论。
原文链接
本文为阿里云原创内容未经允许不得转载。
