02 | 基本概念：指标+日志+链路追踪=可观测性？
什么是可观测性？
指标 + 日志 + 链路追踪 = 可观测性？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了软件系统中的可观测性概念及其重要性。强调了可观测性对于理解和管理复杂软件系统的重要性，以及指标、日志和链路追踪在实现可观测性方面的局限性。作者指出，可观测性需要支持高基数、高维度和可探索性工具。文章还详细介绍了结构化事件、基数和维度在可观测性中的作用，以及如何利用这些概念来快速定位和解决系统中的问题。总的来说，本文为读者提供了深入了解软件系统可观测性的重要性以及实现方法的详实内容。
《深入浅出可观测性》，新⼈⾸单¥29
全部留言(11)
- 最新
- 精选
LYy尝试做个总结： · What: 老师这节课试图在为我们正本清源，把可观测性从大家认知里中具体的Metrics、Logs、Tracing这些实现层的概念抽象成通用的为了理解和解释系统所处状态的能力。同时指出这种能力应该做到不需要修改代码就可以观察到所有已知/未知状态，这就要求可观测在设计阶段就应该被当做一个质量属性(指业务维度之外的系统复杂度，如高可用、高性能、安全等)得到合适的设计。 · How: 回答完"复杂性是什么？"这个"What"之后，老师提出了基于结构化事件(Structed Events)来实现可观测性的理论，并且说明高基数(特异性)和高维度(丰富度)的结构化事件是我们设计时应该追求的目标。 · Why not? 精炼的概括Metrics、Logs、Tracing的本质和弊端，指出有了"三大件"也不一定能真的懂咱们的系统： - Metrics: 一段时间内的数值。聚合性强，但是粒度粗、关联性差； - Logs: 一次事件的记录。离散度高、缺少结构化，难于收集和理解； - Tracing: 一次请求的E2E路径。全覆盖难(受限于框架、语言等生态因素)、维护/运行成本高。 总结完期待后面能有具体的基于结构化事件的可观测落地案例~ 这里提一个问题，当前基于"三大件"也有"指标异常圈定问题范围" -> "链路追踪找到问题环节" -> "报错日志发现问题原因"这样看起来很美的方法论，理论上也能达到快速发现问题的效果，这种系统构建可观测性的价值是否就没那么高了？作者回复: 感谢你的分享！比较全面，其他同学也可以一起看看。 有关最后的问题，可观测性并不是某种工具提供的某种能力，而是能真正达到在分析系统状态或者问题时候，数据的关联和多维度分析，帮助定位问题原因。如果还是几个工具的整合，需要人工在工具间跳转和并搜寻判断，那这样的效率会打很多折扣。
2022-10-14归属地：上海33
运维夜谈老师好，在谈到可观测性时，指标、日志、链路是基础，而指标里看到比较多的是在说一些通用性指标，但我觉得是不是还得结合业务来设置监控指标或者说是事件型告警，举个例子：一个文件传输和入库的场景，我们需要知道文件入库是否有延迟，这时候我们可以监控数据库或者磁盘目录，但是延迟的原因是什么告警不会说明，所以结合业务情况，可以再添加数据库连接失败告警、文件传输进程告警、上游是否产生文件的告警等等，我们可以通过添加很多维度的告警来判断问题出现在哪里。 可观测性的目的也是为了尽快找到故障点，所以我觉得监控指标或者告警设置的更全面更容易知道故障源头，不知道我理解对不对？ 但是，告警设置太多，就会导致源头出现故障，会有大量后续环节的告警产生，容易产生告警风暴，想请教老师这个问题有什么解决思路？作者回复: 感谢分享！你说的没错，是需要根据系统和服务的不同类似，来从不同维度建立告警。告警风暴，一般是可以从分组、抑制、静默等角度去降低，而另一方面，在我后面的课程中也会讲到，最重要的告警应该是和用户使用相关，应该关注真正影响到用户体验的指标。
2022-09-24归属地：上海3- Geek_fa3bb6目前我们的监控都是一些基础指标的采集与告警，很多时候我们只是根据监控解决网络以及配置问题，在具体到应用业务故障时，我们就捉襟见肘，我们都需要通过metrics、logs、traces转一圈回来，然后再和业务方讨论才能确定问题根因 老师，听下来，可观测性似乎通过不断地收集多元多维的数据，然后通过数据做分析来得出根因，那么对存储、延迟等要求就高了？
作者回复: 可观测的数据采集确实更多维度，对后端存储性能要求更高，包括不同数据类型的存储
2022-09-18归属地：上海2 
includestdio.h我们业务部署在k8s中，出现的故障经常是雪崩式的，每次故障的复盘都可以通过传统监控系统收集到大量故障时候的信息，但是最难的是没有人能把这些故障信息有理有据的串联起来，这一部分的工作完全靠直觉和推测，目前看起来可观测性好像可以解决我的问题作者回复: 可观测性的目标就是保障系统可靠性，快速找到问题的根本原因
2022-09-15归属地：上海2
奕可观测下性是系统的属性，方法论。依赖 指标、日志和追踪 等数据类型进行分析作者回复: 归纳得很到位！
2022-09-17归属地：上海1
耿安鹏大量的插桩增加了工作量的同时也降低了系统的可靠性，同时大量的插桩也会占用比较高的计算资源，中间件的插桩代码如何解决，老师这个问题有啥思路呢？作者回复: 这里我主要是想表明不能仅仅局限在应用链路的插桩之上，也需要关注其他维度的数据采集和联合。
2022-09-16归属地：上海1- Geek_fa3bb6“为了减轻这种复杂性，工程团队现在必须能够以灵活的方式不断收集遥测数据，及时调试问题，而不需要首先预知故障可能如何发生” 这句话还是太明白，这里提到 “灵活的方式” 是指什么？以及 “不需要首先预知”，难道在收集遥测数据的时候，不需要关注如何插桩吗？，感觉一句很包含很多冲突
作者回复: “灵活的方式”是指能从各种角度，设定各种标签，从而在之后分析数据的时候能够从各种维度分析。“不需要首先预知”，也是和传统监控的区别，因为现代化系统架构复杂，很多时候发生问题，可能之前都没有遇到过，也没法把所有情况就先预估出来。这个和插桩并不矛盾，插桩是需要的，但也不可能把所有可能出现问题的地方都事先进行插桩，重要的还是能够在出现问题的时候，进行各维度的分析以及快速定位。
2022-12-13归属地：上海 - Geek_42abae1，监控维度不全，比如缺少业务监控，只有服务，中间件，基础设施类的。 2，链路不全，请求经过不同的网络层，比如SLB，WAF这部分就不太容易跟踪。另外经过中间件的也容易缺失，MQ，DB，CACHE等，再有就是发起的异步分支跟踪困难 3，缺少关联分析，很多告警是表面现象，找到根因困难 4，缺少all-in-one产品
作者回复: 关联分析和 All-in-One 产品可以看下后续的实战课程，会有示例的介绍。业务的监控需要和业务一起来进行分析，是需要有一些自定义的插桩
2022-11-09归属地：上海 
刘小浩“如果我们必须拥有可观测性的三个支柱，那么它们应该是支持高基数、高维度和可探索性工具。” 但如今比较火的prometheus，如果暴露数据具备高基数和高纬度的话，经常会挂。但业务方又对prometheus工具较熟悉。问题： 1、如何解决这种高基数和高纬度问题 2、对于服务来说，那些维度是有用的，那些是没用的作者回复: 可观测性数据的体量确实比以往要大很多。但数据的采集还是建议更加全面，这样在分析问题的时候才更有效率。所以从另一方面来说，数据存储也是在不断更新换代，可以考虑更高性能的方案，比如VictoriaMetrics等。
2022-09-27归属地：上海
花花大脸猫这一篇文章有点像纯理论性的描述了，我觉得老师可以带一下，然后具体的可以给一个官方的链接。作者回复: 前面会多说一些概念，后面就会有实战的课程
2022-09-22归属地：上海
