浙江高端网站建设公司,世界建筑设计网站,嵌入式开发板哪款好,深圳建站公司企业减少故障有两个层面的意思#xff0c;一个是做好常态预防#xff0c;不让故障发生#xff1b;另一个是如果故障发生#xff0c;要能尽快止损#xff0c;减少故障时长。而监控的典型作用#xff0c;就是帮助我们发现及定位故障#xff0c;这两个环节对于减少故障时长至关…减少故障有两个层面的意思一个是做好常态预防不让故障发生另一个是如果故障发生要能尽快止损减少故障时长。而监控的典型作用就是帮助我们发现及定位故障这两个环节对于减少故障时长至关重要。
运维人员和研发人员是典型的关注稳定性的人不过侧重点不同。一般来说运维人员负责全公司所有业务的运维工作研发人员只负责自己业务线的研发工作所以发生故障的时候运维人员更希望快速找到问题根因及时止损。而研发人员更希望能“自证清白”。不管出于何种目的监控都是不可或缺的工具。
业务程序也有多种暴露方式比较知名的埋点工具是 StatsD、Prometheus。当然有些语言会有适合自己的更易用的埋点工具比如 Java 生态的 Micrometer。业务程序除了指标埋点监控通常还有更丰富的观测手段比如引入链路追踪的框架Zipkin、Jaeger、Skywalking 等。当然了所有软件都可以使用日志的方式来暴露健康状况不过这种方式最昂贵数据非结构化适合排查问题但不适合作为指标数据的来源。
指标监控只能处理数字但它的历史数据存储成本较低实时性好生态庞大是可观测性领域里最重要的一根支柱。
另一个重要的可观测性支柱是日志。从日志中可以得到很多信息对于了解软件的运行情况、业务的运营情况都很关键。比如操作系统的日志、接入层的日志、服务运行日志都是重要的数据源。
可观测性最后一大支柱是链路追踪。随着微服务的普及原本的单体应用被拆分成很多个小的服务服务之间有错综复杂的调用关系一个问题具体是哪个模块导致的排查起来其实非常困难。
链路追踪的思路是以请求串联上下游模块为每个请求生成一个随机字符串作为请求 ID。服务之间互相调用的时候把这个 ID 逐层往下传递每层分别耗费了多长时间是否正常处理都可以收集起来附到这个请求 ID 上。后面追查问题时拿着请求 ID 就可以把串联的所有信息提取出来。
Zabbix 是一个企业级的开源解决方案擅长设备、网络、中间件的监控。因为前几年使用的监控系统主要就是用来监控设备和中间件的所以 Zabbix 在国内应用非常广泛。 Zabbix 的优点
对各种设备的兼容性较好Agentd 不但可以在 Windows、Linux 上运行也可以在 Aix 上运行。架构简单使用数据库做时序数据存储易于维护备份和转储都比较容易。社区庞大资料多。Zabbix 大概是 2012 年开源的因为发展的时间比较久在网上可以找到海量的资源。
Zabbix 的缺点
使用数据库做存储无法水平扩展容量有限。如果采集频率较高比如 10 秒采集一次上限大约可以监控 600 台设备还需要把数据库部署在一个很高配的机器上比如 SSD 或者 NVMe 的盘才可以。Zabbix 面向资产的管理逻辑监控指标的数据结构较为固化没有灵活的标签设计面对云原生架构下动态多变的环境显得力不从心。
Open-Falcon 基于 RRDtool 做了一个分布式时序存储组件 Graph。这种做法可以把多台机器组成一个集群大幅提升海量数据的处理能力。前面负责转发的组件是 TransferTransfer 对监控数据求取一个唯一 ID再对 ID 做哈希就可以生成监控数据和 Graph 实例的对应关系这就是 Open-Falcon 架构中最核心的分片逻辑。 Open-Falcon 的优点
可以处理大规模监控场景比 Zabbix 的容量要大得多不仅可以处理设备、中间件层面的监控也可以处理应用层面的监控最终替换掉了小米内部的 perfcounter 和三套 Zabbix。组件拆分得比较散大都是用 Go 语言开发的Web 部分是用 Python易于做二次开发。
Open-Falcon 的缺点
生态不够庞大是小米公司在主导很多公司做了二次开发但是都没有回馈社区有一些贡献者但数量相对较少。开源软件的治理架构不够优秀小米公司的核心开发人员离职项目就停滞不前了小米公司后续也没有大的治理投入相比托管在基金会的项目缺少了生命力。 Prometheus 就是为 Kubernetes 而生的。它针对 Kubernetes 做了直接的支持提供了多种服务发现机制大幅简化了 Kubernetes 的监控。
在 Kubernetes 环境下Pod 创建和销毁非常频繁监控指标生命周期大幅缩短这导致类似 Zabbix 这种面向资产的监控系统力不从心而且云原生环境下大都是微服务设计服务数量变多指标量也呈爆炸态势这就对时序数据存储提出了非常高的要求。 Prometheus 的优点
对 Kubernetes 支持得很好目前来看Prometheus 就是 Kubernetes 监控的标配。生态庞大有各种各样的 Exporter支持各种各样的时序库作为后端的 Backend 存储也有很好的支持多种不同语言的 SDK供业务代码嵌入埋点。 Prometheus 的缺点
易用性差一些比如告警策略需要修改配置文件协同起来比较麻烦。当然了对于 IaC 落地较好的公司反而认为这样更好不过在国内当下的环境来看还无法走得这么靠前大家还是更喜欢用 Web 界面来查看监控数据、管理告警规则。Exporter 参差不齐通常是一个监控目标一个 Exporter管理起来成本比较高。容量问题Prometheus 默认只提供单机时序库集群方案需要依赖其他的时序库。
Nightingale 可以看做是 Open-Falcon 的一个延续因为开发人员是一拨人不过两个软件的定位截然不同Kubernetes 环境下Prometheus 已经大行其道再重复造轮子意义不大所以 Nightingale 的做法是和 Prometheus 做良好的整合打造一个更完备的方案。当下的架构主要是把 Prometheus 当成一个时序库作为 Nightingale 的一个数据源。如果不使用 Prometheus 也没问题比如使用 VictoriaMetrics 作为时序库也是很多公司的选择。 Nightingale 的优点
有比较完备的 UI有权限控制产品功能比较完备可以作为公司级统一的监控产品让所有团队共同使用。Prometheus 一般是每个团队自己用自己的比较方便。如果一个公司用同一套 Prometheus 系统来解决监控需求会比较麻烦容易出现我们上面说的协同问题而 Nightingale 在协同方面做得相对好一些。兼容并包设计上比较开放支持对接 Categraf、Telegraf、Grafana-Agent、Datadog-Agent 等采集器还有 Prometheus 生态的各种 Exporter时序库支持对接 Prometheus、VictoriaMetrics、M3DB、Thanos 等。
Nightingale 的缺点
考虑到机房网络割裂问题告警引擎单独拆出一个模块下沉部署到各个机房但是很多中小公司无需这么复杂的架构部署维护起来比较麻烦。告警事件发送缺少聚合降噪收敛逻辑官方的解释是未来会单独做一个事件中心的产品支持 Nightingale、Zabbix、Prometheus 等多种数据源的告警事件但目前还没有放出。
每种方案各有优缺点如果你的主要需求是监控设备推荐你使用 Zabbix如果你的主要需求是监控 Kubernetes可以选择 PrometheusGrafana如果你既要兼顾传统设备、中间件监控场景又要兼顾 Kubernetes做成公司级方案推荐你使用 Nightingale。 此文章为7月Day27学习笔记内容来源于极客时间《运维监控系统实战笔记》推荐该课程。
