peter
请教老师几个问题：
Q1：观测云的方案1中，日志通过两路发送到DataKit，这不是重复了吗？
为什么要这样设计
Q2：我打算建一个小网站，大约五万用户的规模，打算采用Prometheus。请问，针对我的情况，需要采用OpenTelemetry吗？
作者回复：Q1: 方案1是服务端和客户端分别发送日志，不会重复。Q2: Prometheus主要在于指标监控，如果还需要采集其他的数据例如链路追踪，需要OTel
2022-09-21
includestdio.h
感觉TDD转ODD会有很多困难，甚至会有一些风险，很多东西感觉要从根部矫正，特别是文化方面的东西，不过确实ODD感觉会更合理一些
2022-09-28
2
kaizen
Toil 挫事 哈哈 太贴切了
作者回复：因为挫所以希望越少越好！
2022-10-11
AKA三皮
错误预算堆栈：通过数据做决策，平衡开发和运营，实施起来比较困难。这个方法论如果做为监控体系的切入点是不是比较好，错误预算消耗过快===>告警===>发现问题===>解决问题。但是往往在内部，前端的同事（顾问），通常遇到一个问题（100%可靠性）就要求解决，这实际上与错误预算的文化是背道而驰的。你去跟他讲大道理，他会跟你说，客户要求～～～
作者回复：感谢分享！不过如果确实影响到客户使用和体验，那也是影响错误预算了
2022-09-30
Joky
请教老师,看了这个观测云,怎么感觉和国外的datadog非常相似?
可不可以理解为中国版的datadog?
作者回复：DataDog是国外可观测领域的标杆，观测云也是在不断努力不断进步！
2022-09-22
耿安鹏
opentelemetry中trace、metric和log在程序实现过程中如何关联的？比如metric通过什么样的数据结构关联的，有具体的例子可以参照吗？
作者回复：举个 Java 语言的例子，OpenTelemetry 通过 java-agent 方式注入到应用当中，应用产生链路信息后，通过设置 MDC 可以把 trace_id 和 span_id 作为参数传递给 log，这样 log 在输出的时候便会带上，从而与链路串联起来。
OpenTelemetry 同样也支持指标也就是 metric 的采集，通过 Collector 将指标输出到对应的Exporter，比如 Prometheus。Exporter 支持 metric 的输出，metric 和 log 及 trace 的关联可以通过主机名称，也就是标签为 server_name 进行关联。
2022-09-22
Geek_fa3bb6
目前我们的监控都是一些基础指标的采集与告警，很多时候我们只是根据监控解决网络以及配置问题，在具体到应用业务故障时，我们就捉襟见肘，我们都需要通过metrics、logs、traces转一圈回来，然后再和业务方讨论才能确定问题根因
老师，听下来，可观测性似乎通过不断地收集多元多维的数据，然后通过数据做分析来得出根因，那么对存储、延迟等要求就高了？
作者回复：可观测的数据采集确实更多维度，对后端存储性能要求更高，包括不同数据类型的存储
2022-09-18
2
Geek_fa3bb6
用的比较多的是prometheus，它的好处是上手快，接入便捷，灵活的部署架构以及exporter扩展能力，可按需配置多维标签，并结合PromQL查询语句、Altermanager和Grafana可以快速架构起一个监控告警系统。它的缺点是自身没有集群化和水平扩展能力，需要结合Thanos等外部系统，以及它适合做metric监控，不适合做log和trace监控
作者回复：确实，你总结得很到位，Prometheus有便利的地方也有比较明显的局限
2022-09-17
3
二十四桥仍在
Prometheues告警，发送给alertmanage，然后告警用什么数据存储比较好呢？
作者回复：这需要根据后端告警对接的消息平台，以及存储的目的，一种方式是可以将告警存储到ES中进行进一步的分析和处理
2022-09-15
1
耿安鹏
大量的插桩增加了工作量的同时也降低了系统的可靠性，同时大量的插桩也会占用比较高的计算资源，中间件的插桩代码如何解决，老师这个问题有啥思路呢？
作者回复：这里我主要是想表明不能仅仅局限在应用链路的插桩之上，也需要关注其他维度的数据采集和联合。
2022-09-16
1
讲师
翁一磊
观测云产品技术总监
编辑推荐
看过的人还看了
