监控需求来源
刚开始的需求就是出了问题,我们可以精确感知到。
后来的需求扩展为:
通过监控了解数据趋势,知道系统在未来的某个时刻可能出问题,预知问题。
通过监控了解系统的水位情况,为服务扩缩容提供数据支撑。
通过监控来给系统把脉,感知到哪里需要优化,比如一些中间件参数的调优。
通过监控来洞察业务,提供业务决策的数据依据,及时感知业务异常。
可观测性三大支柱
指标监控:只能处理数字,但是因为历史存储数据简单,实时性好,生态好,所以很受欢迎。
日志:有软件的运行情况、业务的运营情况等,通常量比较大,不够结构化,存储成本较高。
链路追踪:以请求串联上下游模块,为每个请求生成一个随机字符串作为请求 ID。服务之间互相调用的时候,把这个 ID 逐层往下传递,每层分别耗费了多长时间,是否正常处理,都可以收集起来附到这个请求 ID 上。后面追查问题时,拿着请求 ID 就可以把串联的所有信息提取出来。
这三者不是完全割裂开的,文章来源:https://www.toymoban.com/news/detail-699242.html
业界方案横评
名称 | Zabbix | Open-Falcon | Prometheus | Nightingale |
---|---|---|---|---|
描述 | 企业级的开源解决方案,擅长设备、网络、中间件的监控。Zabbix 核心由两部分构成,Zabbix Server 与可选组件 Zabbix Agent。 | 组件比较散。 Open-Falcon 基于 RRDtool 做了一个分布式时序存储组件 Graph。这种做法可以把多台机器组成一个集群,大幅提升海量数据的处理能力。前面负责转发的组件是 Transfer,Transfer 对监控数据求取一个唯一 ID,再对 ID 做哈希,就可以生成监控数据和 Graph 实例的对应关系,这就是 Open-Falcon 架构中最核心的分片逻辑。结合我们给出的架构图来看,告警部分是使用 Judge 模块来做的,发送告警事件的是 Alarm 模块,采集数据的是 Agent,负责心跳的模块是 HBS,负责聚合监控数据的模块是 Aggregator,负责处理数据缺失的模块是 Nodata。当然,还有用于和用户交互的 Portal/Dashboard 模块。 | 针对 Kubernetes 做了直接的支持,提供了多种服务发现机制,大幅简化了 Kubernetes 的监控 | 和 Prometheus 做良好的整合,打造一个更完备的方案。当下的架构,主要是把 Prometheus 当成一个时序库,作为 Nightingale 的一个数据源。 |
优点 | 1.对各种设备的兼容性较好,Agentd 不但可以在 Windows、Linux 上运行,也可以在 Aix 上运行。2.架构简单,使用数据库做时序数据存储,易于维护,备份和转储都比较容易。3.社区庞大,资料多。 | 1.可以处理大规模监控场景。2.组件拆分得比较散,大都是用 Go 语言开发的,Web 部分是用 Python,易于做二次开发。 | 1.对 Kubernetes 支持得很好,目前来看,Prometheus 就是 Kubernetes 监控的标配。w生态庞大,有各种各样的 Exporter,支持各种各样的时序库作为后端的 Backend 存储,也有很好的支持多种不同语言的 SDK,供业务代码嵌入埋点。 | 1.有比较完备的 UI,有权限控制,产品功能比较完备,可以作为公司级统一的监控产品让所有团队共同使用。2.兼容并包,设计上比较开放 |
缺点 | 1.使用数据库做存储,无法水平扩展,容量有限。 2.Zabbix 面向资产的管理逻辑,监控指标的数据结构较为固化,没有灵活的标签设计,面对云原生架构下动态多变的环境,显得力不从心。 | 1.生态不够庞大,是小米公司在主导,很多公司做了二次开发,但是都没有回馈社区,有一些贡献者,但数量相对较少。2开源软件的治理架构不够优秀 | 1.易用性差。2.Exporter 参差不齐,通常是一个监控目标一个 Exporter,管理起来成本比较高 。3.容量问题,Prometheus 默认只提供单机时序库,集群方案需要依赖其他的时序库。 | 1.机房网络割裂问题,告警引擎单独拆出一个模块下沉部署到各个机房。2.告警事件发送缺少聚合降噪收敛逻辑 |
此文章为9月Day 5学习笔记,内容来源于极客时间《运维监控系统实战笔记》。文章来源地址https://www.toymoban.com/news/detail-699242.html
到了这里,关于运维监控背景信息的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!