n9ecommunity的博客

JMX（Java管理扩展）是Java平台提供的标准管理和监控框架，用于监控应用程序运行状态、动态配置修改及远程管理。摘要介绍了JMX的核心功能、常见应用场景（如Kafka、Tomcat等），以及它与OpenTelemetry的三种集成方式：通过JMX指标收集器JAR、OpenTelemetry Java代理或Collector配置JMX接收器。文中还提供了Tomcat启用JMX的Docker配置示例，并演示了使用JConsole验证JMX连接和指标采集的方法。最后对比了直接使用JMX抓取工具与Java代理的

尾部采样正在改变可观测性数据收集的范式。相比传统头部采样，尾部采样通过延迟决策机制，在跟踪完成后基于错误率、延迟等关键指标智能筛选数据。OpenTelemetry提供了完善的尾部采样实现方案，支持多条件复合策略，可显著提升故障诊断效率并降低60%-80%存储成本。该技术面临内存占用和实时性等挑战，但结合AI的发展趋势，未来将实现更智能的预测性采样和边缘计算集成。尾部采样代表可观测性领域的重大进步，帮助企业在数据爆炸时代精准获取最有价值的系统信息。

本文总结了可观测性体系建设的五个关键步骤：明业务（梳理核心业务指标）、立规范（制定统一标准）、采数据（规范数据采集）、显特征（提取数据特征）、获洞见（通过数据分析定位故障）。作者基于11年监控领域经验指出，企业需从业务目标出发，建立统一规范，有效采集组织数据，最终通过特征分析获取故障定位依据。文章强调规范的早期建立可显著提升后期效率，并建议结合专业工具实现数据可视化分析。该框架为可观测性体系建设提供了系统性思路。

摘要 本文介绍了如何利用Prometheus监控Kubernetes集群。作为CNCF开源项目，Prometheus通过时间序列数据库存储指标，支持动态发现K8s服务，并可与Grafana集成实现可视化。文章重点讲解了使用kube-prometheus-stack Helm Chart一键部署完整监控栈（包括Prometheus、Node-Exporter、Grafana等组件），详细演示了安装步骤、PromQL查询方法以及Grafana仪表板配置。该方案简化了K8s监控体系的搭建，帮助开发者实时掌握集群资

监控系统选型之争：Zabbix与Prometheus深度对比分析 本文从技术演进角度对比了两大主流监控系统：Zabbix和Prometheus。Zabbix作为2001年诞生的"老将"，擅长传统IT基础设施监控；而2014年问世的Prometheus则专为云原生环境设计，源自Google Borgmon理念。两者在监控理念上存在根本差异：Zabbix采用静态资产管理方式，Prometheus则基于动态自动发现机制。在产品集成度方面，Zabbix是大而全的一体化方案，Prometheus则

Prometheus告警恢复时无法获取恢复值的原因是：当指标恢复正常时，Prometheus查询不到数据，Alertmanager只能基于内存中的旧告警事件标记为恢复。开源监控系统Nightingale通过额外配置recovery_promql实现了恢复值获取功能，在恢复时重新查询指标值并存入告警事件的Annotations字段。这种设计弥补了Prometheus原生功能的不足，为告警处理提供了更完整的数据支持。

摘要：Prometheus作为主流监控工具面临告警规则管理难题，如YAML文件维护复杂、需运维团队统一审核导致效率低下。如何解决？

本文介绍了如何利用夜莺监控和Categraf构建进程监控系统。夜莺是一款侧重告警的开源监控项目，可与多种时序数据库集成；Categraf是数据采集工具，支持采集进程存活状态、CPU、内存等指标。文章详细演示了部署VictoriaMetrics时序库、夜莺监控服务端和Categraf客户端的步骤，并配置procstat插件监控指定进程。通过procstat_lookup_count等关键指标，可及时发现进程异常并告警。这套方案特别适合尚未采用Kubernetes的传统企业进行基础监控建设。

本文探讨了业务应用的DEV或SRE是否应该接收底层基础设施告警的问题。作者认为关键要看是否有可执行的SOP（标准操作流程）：若无法主动处理（如单机房部署），建议通过可视化页面监控SLI指标；若具备应对措施（如切流能力），则可通过订阅规则接收告警。文中推荐了两种实践方式：一是让底层服务为关键告警打标签便于订阅，二是在上层应用自行埋点采集成功率/延迟等精细化指标。

摘要：CPU负载高是否告警取决于告警是否可执行(actionable)。告警应分3级：Critical(立即处理)、Warning(延迟处理)、Info(仅记录)。关键原则是只有需要后续处理动作的告警才应配置，否则会产生告警疲劳。每个告警规则都应配套SOP处理预案，标注在告警规则的Annotations中。这比单纯搭建监控系统更有价值，能真正提升故障处理效率。作者建议从业务影响角度评估告警必要性，避免无效告警噪音。

日志、指标和跟踪仍然是可观测性的关键组成部分，而配置数据代表了第四根支柱，提供了对您系统独特见解。通过实施全面的配置数据监控，组织可以增强其安全态势、确保合规性、优化成本，并更深入地了解其基础设施。随着系统变得越来越复杂和分布式，配置数据监控的价值将只会增加。那些认识到这一第四支柱并将其纳入其可观测性策略中的组织，将更好地处于理解、排查故障和优化其日益复杂基础设施的有利位置。译者注：原文作者这个观点值得借鉴，但是对于故障定位等场景真的那么有用吗？也未可知。

Elastic Stack 在日志领域具备无与伦比的地位，各类新兴的开源项目都声称比 Elastic 更节省资源，同时检索速度也不慢，比如 ClickHouse、Loki、OpenObserve、VMLogs，今天我们来看看另一个项目：SigLens。

这一波 AI 浪潮跟以往都不同，各个行业都看到了新的可能性，都想把 AI 引入自己的场景，看看能迸发什么样的助力。上面的思路确实可以放到开源夜莺项目（Nightingale）里，作为一款开源软件，在一些功能上做增强，确实会变得更性感。但这些增强都是面向“点”的，有没有面向“面”的更让人眼前一亮的思路呢？

Fluentbit 是非常流行的日志采集器，作为 Fluentd 的子项目，是 CNCF 主推的项目，本文以夜莺的日志举例，使用 Fluentbit 采集，并直接写入 ElasticSearch，最终使用 Kibana 查看。借此实践过程，让读者熟悉 Fluentbit 的使用。

VictoriaMetrics 集群版也是开源的，但是维护更复杂，毕竟组件更多。如果数据量低于每秒​​一百万个数据点，建议使用单节点版本，而不是集群版本。单节点版本可以完美地适应 CPU 核心数、RAM 和可用存储空间。与集群版本相比，单节点版本更易于配置和操作，因此在选择集群版本之前请三思。VictoriaMetrics 集群版相比单机版，更适合大规模的监控数据存储和查询。但是，集群版的维护和运维成本更高，需要更多的硬件资源。在选择集群版之前，请三思。

详情中可以看到，商品实时下单量这个关键业务指标暴跌，在某些时刻直接跌到0了，这是一个明显的故障，用户可以在暴跌的位置点击鼠标，就可以看到那些相关的服务是否健康，不健康的直接红色标注，用户就可以快速定位到故障服务，比如这里明显看到。Flashcat 的做法，主打一个知识沉淀复用，平时用户定位故障时，先看什么数据，再看什么数据，都可以在 Flashcat 里沉淀下来。云上的、云下的，开源的、自建的、商业的，网络的、服务器的、数据库的、中间件的、应用的、业务的，指标的、日志的、链路的、事件的。

Prometheus 告警事件中的$value表示当前告警触发时的值，但是在告警恢复时，Resolved 事件中的$value仍然是最新告警时的值，并非是恢复时的值，这是什么原因和原理？是否有办法来解决呢？不废话，先说原理。

有了观测能力，保障连锁门店IT服务的稳定性还差最后一步，就是建立起相应的稳定性保障流程。让制度来驱动保障能力落地。Flashduty 就是针对性的解决这个环节的问题。Flashduty可以收集观测系统、灭火图、北极星以及各个告警源的告警，对所有告警事件做聚合降噪、优先级划分、值班排班、告警升级等设置。让整个保障流程通过告警驱动运行起来，实现用机制来保障稳定性的效果。各家连锁门店企业可能因业务的特点和已有观测能力的不同，建设的侧重点有所不同。和客户一起实施的过程中，Flashcat还实践了包括。

在这篇博客中，我们介绍了在 Kubernetes 集群上实现 JMX Exporter 的步骤。此外，在导出器 Configmap 中，您可以为 JMX Exporter 添加其他过滤器设置，以收集其他指标。原文：https://devopscube.com/jenkins-architecture-explained/译文：https://flashcat.cloud/blog/jenkins-architecture-explained/译者：巴辉特。

TargetsExportersPromQL让我们详细看看每个组件。这解释了 Prometheus 架构的主要组件，并将给出 Prometheus 配置的基本概述，您还可以使用配置做很多事情。每个组织的需求会有所不同，并且 Prometheus 在不同环境（例如 VM 和 Kubernetes）中的实现也有所不同。如果您了解基础知识和关键配置，您就可以轻松地在任何平台上落地它。本文翻译自这里。运维监控实战笔记。

Prometheus 生态的监控系统，在告警恢复消息中难以拿到恢复时的值，Nightingale 中提供了一个较为简单的方法，值得尝试

Prometheus 的重要性和流行度已经无需多言。直入主题，本文对 Prometheus 监控平台的各个组件做深度讲解，希望能帮助读者更好地理解 Prometheus。

Charity Majors 的这句话可能是对科技行业当前可观察性状态的最好总结——完全的、大规模的混乱。大家都很困惑。什么是 trace？什么是 span？一行日志就是一个 span 吗？如果我有日志，我还需要 trace 吗？如果我有很好的 metric，为什么还需要 trace？诸如此类的问题不胜枚举。Charity 与 Honeycomb 可观测系统中的其他杰出人士一起，一直在努力解决这些问题。

可观测性（Observability）是一种软件开发和系统构建的哲学，是对系统内部状态及行为的度量和推断能力，通常包括日志、指标、链路追踪等多个度量维度。也就是说，在软件开发和运维领域中，可观测性是指对于一个复杂的系统，能够通过监控、日志、指标、追踪等手段，快速地发现、诊断、解决问题的能力。

本文是从监控系统的构建角度，从采集->传输->存储->可视化->告警->事件分发不同阶段做了简要分析，给了一些可能的解法，希望对大家有帮助。如果你对监控系统的构建有更好的想法，欢迎留言交流。

ClickVisual 官方宣扬的核心功能是：轻量级日志查询、分析、报警可视化平台。报警这块有更好的方案，我这里主要尝试一下接入日志、存储、查询日志的整个流程。文档：https://clickvisual.net/代码：https://github.com/clickvisual/clickvisualClickVisual 的整体思路设计挺巧妙的，不过业界使用 ClickHouse 存储日志，大都是使用的双 array 存储动态字段。你们公司是如何做的呢？

本文介绍了稳定性保障中日志分析系统建设面临的问题、挑战、需求和建设中的权衡取舍。并介绍了 Flashcat 如何解决这些问题，做到效果和成本最佳，也最具落地的可行性。

Beyla 目前还不太稳定，还有很多功能没有完成。不过可以尝鲜研究了。可观测性整套技术栈搞起来还挺费劲的，如果您想建设这套技术栈，欢迎来和我们聊聊，我们提供这方面的咨询和商业产品，详情了解：快猫星云 Flashcat | 为了无法度量的价值 | 开源监控 | 夜莺监控 | 可观测平台 | 运维监控 | IT监控快猫星云(官网)，支持云原生监控、混合云监控、多云统一监控，解决云原生架构、混合云架构下统一监控难、故障定位慢的问题t=N7T8。

可观测性是一种了解和解释应用当前状态的能力，也是一种知道何时出现问题的方法。随着在 Kubernetes 和 OpenShift 上以微服务形式进行云部署的应用程序越来越多，可观察性受到了广泛关注。许多应用程序都有严格的承诺，比如在停机时间、延迟和吞吐量方面的 SLA，因此网络层面的可观测性是一项非常必要的功能。网络层面的可观测性由不同的编排器提供，有的是内置支持，有的是通过插件和 operator 提供。最近，eBPF（扩展的伯克利数据包过滤器）因其性能和灵活性成为在终端主机内核实现可观察性的热门选择。

OpenTelemetry 是一个非常优秀的项目，它为我们开发的软件抽象出一套实现可观测性的方案。通过使用 OTel ，我们能够获得最大化的可观测能力，而无需进行任何代码更改就能发现潜在的问题。我强烈推荐您深入了解 OpenTelemetry 项目！一旦您开始使用，您将会爱不释手！方法论：面向故障处理的可观测性体系建设白皮书：事件 OnCall 中心建设方法好工具：FlashDuty - 一站式告警处理平台：告警降噪、排班OnCall。

在 OpenTelemetry 中通过使用传播和行李，很好的解决了“分布式链路追踪”中“分布式”的问题。这样可以帮助您获取更有价值的链路追踪数据！方法论：面向故障处理的可观测性体系建设白皮书：事件 OnCall 中心建设方法好工具：FlashDuty - 一站式告警处理平台：告警降噪、排班OnCall。

OpenTelemetry Collector 是一个功能强大的工具，它的一大优点是您可以创建自己的收集器分发版来满足您的需求。在我看来，这种灵活性使得 OpenTelemetry Collector 在 OpenTelemetry 生态系统中具备重要作用。方法论：面向故障处理的可观测性体系建设白皮书：事件 OnCall 中心建设方法好工具：FlashDuty - 一站式告警处理平台：告警降噪、排班OnCall。

很棒前进了一步！按照上面步骤实现了，通过 API 获取了遥测数据，并将其从当前组件中被发送到一个导出器，并向其中添加了一些元数据（资源）！接下来我们将了解如何使用 OpenTelemetry 收集器来处理这来数据。方法论：面向故障处理的可观测性体系建设白皮书：事件 OnCall 中心建设方法好工具：FlashDuty - 一站式告警处理平台：告警降噪、排班OnCall。

埋点是 OpenTelemetry 的核心。它定义了如何去收集哪些遥测数据，我们既可以选择手动埋点还可以利用现成的自动埋点代码库。在下一篇博文中，我们将了解 OTel SDK 是如何处理这些数据！方法论：面向故障处理的可观测性体系建设白皮书：事件 OnCall 中心建设方法好工具：FlashDuty - 一站式告警处理平台：告警降噪、排班OnCall。

OpenTelemetry 是几年前 OpenCensus 和 OpenTracing 合并的产物。从那时起，OpenTelemetry（也简称为 "OTel"）就很好地将自己定位为在现代软件世界中获取遥测数据且厂商中立的方法。很多人会说 OpenTelemetry 是可观测性的未来，根据我的经验和接触，我倾向于同意这种说法。希望通过上面介绍让您现在对 OpenTelemetry 已经有所了解，知道它由哪些组件构成，以及我们将如何在本系列的其余部分深入实施。这仅仅是个开始！