可观测性 这个话题主要看什么
软件暴露的指标、状态页面、打印的日志、事件、吐出的链路追踪数据,Profiling,都是提升软件可观测性的手段;从软件运行环境中收集到的信息,比如从 OS 层面收集到的软件占用的 CPU、内存、句柄、IO 等,也是观测软件的有效手段,提升了软件的可观测性。
可观测性,亦可看做软件在线 debug 的能力,助力排查线上问题。当然,也可以用可观测性数据衡量成本、建立知识沉淀机制等等,可观测性数据在很多场景都有价值。
可观测性,类似软件可用性,是软件的一大特性。如果通过软件暴露的各类信息可以方便了解软件内部运行状态,我们就说软件具备很好的可观测性。可观测性,亦可看做软件在线 debug 的能力,助力排查线上问题。当然,也可以用可观测性数据衡量成本、建立知识沉淀机制等等,可观测性数据在很多场景都有价值。
围绕 可观测性 的实践、选型、案例和产品内容,按同一阅读路径持续整理。
本文是 VictoriaMetrics 公司创始人所著,探讨了开源时序库的兴起历史、值得关注的项目以及未来的发展方向。时序库是监控、可观测性领域的基础设施,如果您是基础设施方向的工程师,尤其值得关注。
如果您已经实施了跟踪但缺乏强大的指标功能怎么办? SpanConnector 是一个通过将跟踪数据转换为可操作指标来弥补这一差距的工具。这篇文章详细介绍了 SpanConnector 的工作原理,提供了有关其配置和实现的指南。
相较于传统的单体应用,以及过去相对静态化的基础设施,现代的应用架构,是一种松耦合的、动态变化的、数量巨大的微服务构成的网络。为了看清楚网络中众多不同的服务之间的依赖关系,以及看清楚一次请求经过的路径上各个节点之间的耗时等信息,传统监控,已经无力应对了。这个网络的每个节点,都有可能是出问题的风险点,tracing 能够追踪每个请求在全生命周期过程中所经过的每个节点的信息,成为了云原生时代和微服务架构下构建可观测体系的关键一环。
Logs 是“可观测性三支柱”中历史包袱最重的监控数据类型,日志的格式更随意,缺乏标准和规范。推荐在应用研发阶段,按照 OTel Logs 规范打印日志。
笔者从 14 年开始做监控,到现在接近 10 年,认知在持续迭代,最近又有一些新想法,跟大家分享一下我眼中的理想的监控系统到底是什么样的
SigNoz号称自己是开源领域的Datadog,基于OpenTelemetry做了一套可观测性方案。夜莺从V6版本开始,也希望做全栈可观测性方案,巧了,大家目标一致,今天我们一起来对SigNoz做个初步了解,看看其产品设计如何,也帮大家未来选型做参考。
如果您之前对可观测性重要性,益处,以及组成不甚了解,本文是一个合适的指南手册
日志,指标和分布式链路追踪这三个可观测性的传统支柱,已经是过时的,过于关注数据采集和底层数据格式,而不去关注结果(我们建设可观测性的初心和目标),这个做法实在是滑天下之大稽
优秀的运维和架构师应该是怎样的?运维能给人工智能时代带来价值吗?