01｜背景信息：监控需求以及开源方案的横评对比
监控需求来源
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了监控系统在互联网领域的重要性以及相关技术特点和业界常见的开源解决方案。首先，文章从监控需求来源、可观测性三大支柱以及业界方案横评等方面进行了详细介绍。其次，文章重点评价了代表性的开源解决方案Prometheus和Open-Falcon，分析了它们的优缺点以及适用场景。另外，还介绍了新一代整体方案代表Prometheus和新一代国产代表Nightingale的特点和优劣势。最后，文章总结了监控产品的需求来源、可观测性三大支柱以及开源解决方案的横评对比，为读者提供了技术选型的参考依据。通过本文的阐述，读者可以快速了解监控系统的背景信息、相关技术特点以及业界常见的开源解决方案，为技术选型提供了参考依据。
《运维监控系统实战笔记》，新⼈⾸单¥59
全部留言(32)
- 最新
- 精选
顶级心理学家秦总，IaC 落地 概念不是很清楚，想深入了解下，感谢👍作者回复: IaC其实是 Infrastructure as Code 的缩写，可以Google一下这个关键词，或者看看这个文章：https://www.redhat.com/zh/topics/automation/what-is-infrastructure-as-code-iac 另外 HashiCorp 搞了一个开源工具叫 Terraform 来践行 IaC，非常火爆，可以了解一下 Terraform 的基本工作机理，对 IaC 的了解也有帮助。举个例子，比如我要在公有云部署一个服务，需要一个mysql一个redis，一个LB，之前的做法是手工创建这些资源，应用了 IaC 之后（比如使用Terraform），就可以使用一个配置模板，和云厂商的OpenAPI联动，每次要创建这么一套环境的时候，就应用一下这个配置模板，Terraform就自动帮你创建、配置相关的资源。比如你测试完了之后可以销毁这些云资源，后面再想搭建这个环境的时候再应用一下这个配置模板，过一会这套软件又被拉起，非常方便。更多信息还是需要Google IaC这个关键词了解哈
2023-01-09归属地：上海519
StackOverflow监控不同指标要配置一堆exporter维护起来也很麻烦作者回复: 嗯，exporter做采集器确实有这个问题，可以试试telegraf catagraf grafana-agent datadog-agent这些all-in-one的采集器，一个采集器就可以采集各类机器、中间件的监控指标
2023-01-09归属地：上海216
无聊的上帝老师你好,在工作中遇到了日志监控和链路追踪很难落地的问题. 被挑战的点如下,请教老师这种局可有破解方法? 1. ELK成本较高,价值性较低.出现问题研发直接看pod的log.代码质量确实高,线上环境从未遇见严重bug. 2. 链路追踪的价值是什么,能给业务带来哪些提升?作者回复: 咱们这个专栏主要还是聊监控和稳定性的话题。从稳定性角度出发的话，落地ELK、链路追踪的系统，核心还是想解决故障定位、可观测性的问题，如果在这方面没有痛点，那确实没有落地的必要，去找点其他更能体现价值的事情做一下。 如果还是想在这方面找出一些价值点，可以问这么几个问题： 1、Pod销毁比较频繁，如果有个异常日志还没来得及看的时候Pod被销毁了，是否是个问题 2、如果把这些可观测性数据都收集到中心，可以在中心做一些串联打通，比如指标掉底了，可以方便的跳转到日志系统里看日志，在terminal里查看日志显然做不到这个效果，这个收益是否足够有吸引力 3、链路追踪通常用在微服务场景，服务越多，效果越明显，如果微服务不多，出了问题我们可以快速知道是哪个模块，确实很难讲清楚价值 临时想到这些，欢迎其他同学补充~
2023-01-11归属地：上海27
陈陈陈陈陈👅目前的困境是告警泛滥，希望能减少不必要的告警指标，但又会顾虑正式这些指标的缺失导致问题的发生作者回复: 需要告警合并，告警收敛，告警分级治理的一些手段，后面会有两讲介绍告警管理，希望能给你提供一些思路
2023-01-10归属地：上海7
怀朔全球的化节点部署或者多机房的机房部署。 运维维护往往其实还是多套数据，同一个展示 或者多个数据 多地方展示 因为要考虑的权限 容量 告警聚合收敛等问题作者回复: 这是行家里手👍😀
2023-01-09归属地：上海27
LiangDu希望老师提供完善的告警规则和grafana仪表盘文件，对很多小白来说这两块才是核心。作者回复: 课程主要还是想讲出所以然，不过实战部分可能会有一些帮助🤝
2023-01-09归属地：上海55
Gregory多套监控系统维护确实是个问题 目前还没太好的方案作者回复: 的确，监控数据可视化、告警规则管理、告警事件管理，这三块要是能有统一的一个产品来搞定就好了，专栏中也提到了一些方案，回头可以一起学习探讨😀
2023-01-09归属地：上海3
peter请教老师几个问题： Q1：生产环境中日志是开启的吗？ 出了问题以后，通过日志来定位问题。但是，生产环境中一般不能开启日志吧。如果不开启的话，怎么利用日志来定位问题呢。好像是个矛盾的事情。 Q2：大厂开发人员是怎么查看日志的？ 对于日志，开发人员是直接用Editplus一类的软件来打开看吗？还是说会用专门的工具软件来查看日志文件？如果用工具软件，用开源的软件还是公司自研的软件？ Q3：open-falcon架构图中怎么没有server？ Zabbix有server，Open-falcon是基于Zabbix发展起来的，按理说也应该有一个server，但架构图中看不出来哪个部分是server。 Q3：Prometheus两个问题 1 没有采用k8s的网站系统，可以用Prometheus吗？ 2 Prometheus可以完成全面的监控吗？ 包括机器、网络、应用、各个中间件等。 Q4：指标监控数据一般怎么存储的？存在MySQL中吗？作者回复: 1，生产环境也会开启日志打印的 2，一般用less、more、tail等命令 3，open-falcon尝试解决zabbix的容量问题，但并不是基于zabbix的架构，并且服务端组件拆得比较散，transfer、hbs、judge、graph等都是服务端组件 4，没用k8s也可以用prometheus 5，prometheus可以完成全面的指标监控 6，一般存储在时序库中，下一讲就开始介绍常用时序库了，zabbix是存mysql，这种不多见，一般都是使用专门的时序库
2023-01-10归属地：上海22
奥特虾不会写代码老师你好，想请教一下对于网络连通性受限的场景下除了 Pushgateway 还有更好的方案不，因为 Pushgateway 使用下来的体验确实不尽如人意，公有云厂商的云主机也是通过类似于Pushgateway 的机制对外推送指标吗？作者回复: 可以考虑remote write的方式哈，比如机器上部署categraf 或者 grafana-agent 或者 telegraf，采集了数据之后通过remote write 推给远端时序库比较方便
2023-01-10归属地：上海42
Hello Strong两三年前因为公司需要，做过一次监控平台的选型，此前在用的就是zabbix，对k8s支持主要靠一些不太热门的插件模块，感觉灵活度太低。选型主要是Prometheus和在用的elk日志平台，前者作为tsdb非常适合指标数据，性能也强。后者的缺点也是前者的优点，但elastic在对采集源的支持度上其实还是可以的，k8s、各种数据中间件、队列、web gateway等都有，这点和Prometheus体系相比不会差太多，图形化方面grafana和kibana也都ok，告警组件方面如果不付费，elastic主要靠一些开源第三方项目的支持，这点不如Prometheus。最后选择了elk方案，原因有点无奈，一方面是Prometheus数据存储的高可用原因，还要再引入其他存储，另一方面elk是已经长期在用的日志平台，各方面都相对熟悉，而且能投入的硬件资源也有限，在数据规模不大的情况下用同一套能满足。作者回复: 这是圈内人士，欢迎来一起交流探讨😁
2023-01-10归属地：上海2
