- 博客(195)
- 收藏
- 关注
RSS订阅翻译 SRE 踩坑记：JVM 暂停竟然是因为日志
摘要： 本文讲述了一个由JVM垃圾回收日志写入引发的性能问题案例。在高吞吐量Java服务中，GC日志写入因磁盘I/O竞争导致15秒以上的全局停顿（STW）。通过分析GC日志发现，实际CPU时间仅0.3秒，但挂钟时间长达15秒，问题根源在于GC线程等待磁盘I/O。解决方案包括：1) 将GC日志写入内存文件系统(tmpfs)；2) 使用JDK 17+的异步日志功能(-Xlog:async)。文章强调关键路径应避免阻塞I/O，并警示容器环境下stdout日志同样可能因管道阻塞导致性能问题。核心经验是：当real时
2025-12-15 12:17:53
8
原创 夜莺监控设计思考（五）告警原理和处理流程深度剖析
本文介绍了夜莺监控系统的告警处理流程设计。系统通过告警引擎周期性地查询数据源，根据预设规则生成告警事件。核心流程包括：事件生成（基于PromQL查询）、状态判定（持续异常才触发）、屏蔽检查、事件持久化（分为活跃事件和历史事件）以及通知处理。系统支持两种通知规则关联方式：直接绑定或通过订阅规则筛选。V8版本新增了事件处理器Pipeline，提供更灵活的告警处理能力。整个设计借鉴了Prometheus的思路，同时扩展支持多种数据源和边缘部署场景，通过多级处理和丰富的事件属性/标签，实现了灵活的告警管理能力。
2025-10-31 16:17:02
478
原创 夜莺监控设计思考（四）关于机器那些事儿
夜莺监控系统针对机器管理提供了独特的平衡设计：一方面保留了Prometheus生态的标签机制，另一方面针对机器场景增加了业务组和标签的双重分类体系。通过Categraf采集器实现机器信息自动上报、元信息展示（CPU/内存等）和特殊告警功能（失联/时间偏移）。系统支持业务组权限管理，并可将机器标签自动附加到监控指标。仪表盘可基于业务组筛选机器数据，告警规则支持变量配置实现业务组专属告警阈值。这种设计解决了机器服务混部带来的管理难题，同时兼顾了Prometheus生态兼容性。
2025-10-29 11:11:30
789
原创 夜莺监控设计思考（三）时序库、agent 的一些设计考量
本文介绍了夜莺监控的设计思路，重点阐述其与时序库和采集器的对接逻辑。夜莺从V5版本开始专注告警引擎功能，放弃自研时序库，转而对接多种数据源。文章分析了PUSH/PULL两种数据采集模式的特点，并解释了开发Categraf采集器的原因：统一各类采集器的体验，满足企业用户需求。最后指出夜莺的核心是告警引擎，Categraf是可选项，但建议用于采集基础指标以获得更好体验。该设计体现了产品定位的精准性和架构的灵活性。
2025-10-28 20:24:45
858
原创 夜莺监控设计思考（二）边缘机房架构思考
夜莺监控边缘架构模式解析 本文介绍了夜莺监控在多数据中心网络环境下的边缘架构解决方案。当存在网络链路较差的数据中心（如美东机房）时，可以将告警引擎独立部署为n9e-edge模块，从中心端同步告警规则并在本地进行告警判定。这种架构即使网络临时中断，仍能保证基本告警功能，同时不影响告警信息通过外网推送。文章还预告了下期将探讨夜莺监控在时序存储和agent设计方面的考量。
2025-10-16 19:52:51
393
原创 利用 OpenTelemetry 集成 JMX 监控
JMX（Java管理扩展）是Java平台提供的标准管理和监控框架，用于监控应用程序运行状态、动态配置修改及远程管理。摘要介绍了JMX的核心功能、常见应用场景（如Kafka、Tomcat等），以及它与OpenTelemetry的三种集成方式：通过JMX指标收集器JAR、OpenTelemetry Java代理或Collector配置JMX接收器。文中还提供了Tomcat启用JMX的Docker配置示例，并演示了使用JConsole验证JMX连接和指标采集的方法。最后对比了直接使用JMX抓取工具与Java代理的
2025-10-14 15:55:56
328
原创 夜莺监控设计思考（一）整体定位、架构设计、单进程多进程选择、高可用设计
摘要：夜莺监控定位为告警引擎，统一管理多数据源（如Prometheus、MySQL等）的告警规则，通过事件Pipeline实现告警处理与通知。相比Grafana侧重可视化，夜莺专注告警治理，支持规则Relabel、事件丰富等功能。其核心架构包含无状态WebAPI（配置管理）和有状态alert模块（规则执行），采用单进程设计平衡部署复杂度与维护性，通过数据库心跳实现高可用。后续将探讨跨机房的边缘架构方案。
2025-10-14 09:53:07
706
原创 夜莺监控新版表格配置图文讲解
本文详细介绍了夜莺监控8.3版本新增的表格功能配置方法，通过图文方式演示了如何创建机器列表监控仪表盘。文章首先展示最终效果，包含变量筛选和多指标展示功能；随后逐步讲解变量配置（数据源和查询类型）、原始数据指标选择、表格基础配置（数据转换和字段隐藏）以及字段覆盖配置（不同可视化样式）。该方法同样适用于MySQL、Redis等监控对象的SLI数据展示，帮助用户快速发现异常实例。文末还提供了相关配置的JSON文件参考。
2025-09-01 15:54:58
1262
原创 利用 OpenTelemetry 建设尾部采样
尾部采样正在改变可观测性数据收集的范式。相比传统头部采样，尾部采样通过延迟决策机制，在跟踪完成后基于错误率、延迟等关键指标智能筛选数据。OpenTelemetry提供了完善的尾部采样实现方案，支持多条件复合策略，可显著提升故障诊断效率并降低60%-80%存储成本。该技术面临内存占用和实时性等挑战，但结合AI的发展趋势，未来将实现更智能的预测性采样和边缘计算集成。尾部采样代表可观测性领域的重大进步，帮助企业在数据爆炸时代精准获取最有价值的系统信息。
2025-08-26 16:25:30
376
原创 开源夜莺里如何引用标签和注解变量
摘要： 夜莺监控是一款专注于多数据源告警的开源项目，支持Prometheus、ElasticSearch、MySQL等数据源，解决传统告警方案（如Prometheus）在规则维护、多实例管理、日志告警等方面的痛点。其核心架构包括Web交互模块和告警引擎，通过告警规则、屏蔽规则、通知规则等实现事件处理与通知分发。夜莺支持灵活的事件处理管道（Pipeline），可对告警事件进行二次处理或智能分析，并集成多种通知媒介。适用于复杂场景下的统一告警管理。 关键词： 夜莺监控、开源告警、多数据源、事件处理、Promet
2025-08-25 12:11:59
687
原创 Grafana侧重可视化，那多数据源告警呢？
摘要： 夜莺监控是一款专注于多数据源告警的开源项目，支持Prometheus、ElasticSearch、MySQL等数据源，解决传统告警方案（如Prometheus）在规则维护、多实例管理、日志告警等方面的痛点。其核心架构包括Web交互模块和告警引擎，通过告警规则、屏蔽规则、通知规则等实现事件处理与通知分发。夜莺支持灵活的事件处理管道（Pipeline），可对告警事件进行二次处理或智能分析，并集成多种通知媒介。适用于复杂场景下的统一告警管理。 关键词： 夜莺监控、开源告警、多数据源、事件处理、Promet
2025-08-21 15:39:33
1120
原创 可观测性体系建设五步心法：明业务、立规范、采数据、显特征、获洞见
本文总结了可观测性体系建设的五个关键步骤：明业务（梳理核心业务指标）、立规范（制定统一标准）、采数据（规范数据采集）、显特征（提取数据特征）、获洞见（通过数据分析定位故障）。作者基于11年监控领域经验指出，企业需从业务目标出发，建立统一规范，有效采集组织数据，最终通过特征分析获取故障定位依据。文章强调规范的早期建立可显著提升后期效率，并建议结合专业工具实现数据可视化分析。该框架为可观测性体系建设提供了系统性思路。
2025-08-18 08:52:25
925
原创 Prometheus 监控 Kubernetes Cluster 最新极简教程
摘要 本文介绍了如何利用Prometheus监控Kubernetes集群。作为CNCF开源项目，Prometheus通过时间序列数据库存储指标，支持动态发现K8s服务，并可与Grafana集成实现可视化。文章重点讲解了使用kube-prometheus-stack Helm Chart一键部署完整监控栈（包括Prometheus、Node-Exporter、Grafana等组件），详细演示了安装步骤、PromQL查询方法以及Grafana仪表板配置。该方案简化了K8s监控体系的搭建，帮助开发者实时掌握集群资
2025-08-15 15:46:07
1234
原创 监控系统如何选型：Zabbix vs Prometheus
监控系统选型之争：Zabbix与Prometheus深度对比分析 本文从技术演进角度对比了两大主流监控系统：Zabbix和Prometheus。Zabbix作为2001年诞生的"老将"，擅长传统IT基础设施监控；而2014年问世的Prometheus则专为云原生环境设计，源自Google Borgmon理念。两者在监控理念上存在根本差异：Zabbix采用静态资产管理方式，Prometheus则基于动态自动发现机制。在产品集成度方面，Zabbix是大而全的一体化方案，Prometheus则
2025-08-13 14:48:48
733
原创 夜莺开源监控，模板函数一览
本文介绍了夜莺开源监控项目中的模板函数功能。夜莺内置了多种模板函数，用于在告警规则和消息模板中对告警事件进行渲染和格式化处理，方便运维人员处理告警。这些模板函数分为六大类：附加查询函数（如动态查询指标数据）、格式化函数（如数值和时间的可读化处理）、字符串处理函数（如大小写转换）、时间处理函数、数学运算函数和数据处理函数。文章详细说明了每类函数的用途和使用示例，特别介绍了实用的query函数和多种格式化输出方法，帮助用户根据实际需求灵活定制告警信息。
2025-08-12 15:23:33
485
原创 Prometheus 告警时为何无法获取现场值
Prometheus告警恢复时无法获取恢复值的原因是：当指标恢复正常时，Prometheus查询不到数据，Alertmanager只能基于内存中的旧告警事件标记为恢复。开源监控系统Nightingale通过额外配置recovery_promql实现了恢复值获取功能，在恢复时重新查询指标值并存入告警事件的Annotations字段。这种设计弥补了Prometheus原生功能的不足，为告警处理提供了更完整的数据支持。
2025-08-12 10:05:40
1054
原创 为 Prometheus 告警规则增加 UI 管理能力
摘要：Prometheus作为主流监控工具面临告警规则管理难题，如YAML文件维护复杂、需运维团队统一审核导致效率低下。如何解决？
2025-08-10 11:09:34
904
原创 如何监控多个进程的存活和CPU、内存占用
本文介绍了如何利用夜莺监控和Categraf构建进程监控系统。夜莺是一款侧重告警的开源监控项目，可与多种时序数据库集成；Categraf是数据采集工具，支持采集进程存活状态、CPU、内存等指标。文章详细演示了部署VictoriaMetrics时序库、夜莺监控服务端和Categraf客户端的步骤，并配置procstat插件监控指定进程。通过procstat_lookup_count等关键指标，可及时发现进程异常并告警。这套方案特别适合尚未采用Kubernetes的传统企业进行基础监控建设。
2025-08-08 13:23:39
1122
原创 Kafka 不难，只是你用得不对
摘要：本文介绍了6个Kafka使用的最佳实践模式：1）按事件类型而非服务划分主题；2）合理设计消费者组对应业务逻辑单元；3）避免无状态链式事件，应结合业务状态；4）采用发件箱模式确保数据一致性；5）使用退避重试机制处理失败消息；6）统一Schema管理确保兼容性。这些模式能有效解决Kafka使用中的常见问题，帮助构建松耦合、可扩展的健壮系统。文章强调遵循这些基本原则可避免系统复杂性，使Kafka真正成为可靠的事件驱动架构基础。
2025-07-29 17:15:07
725
原创 底层的告警，上层业务团队应该收吗？
本文探讨了业务应用的DEV或SRE是否应该接收底层基础设施告警的问题。作者认为关键要看是否有可执行的SOP（标准操作流程）：若无法主动处理（如单机房部署），建议通过可视化页面监控SLI指标；若具备应对措施（如切流能力），则可通过订阅规则接收告警。文中推荐了两种实践方式：一是让底层服务为关键告警打标签便于订阅，二是在上层应用自行埋点采集成功率/延迟等精细化指标。
2025-07-24 15:35:27
168
原创 CPU 负载高，到底应不应该告警？
摘要：CPU负载高是否告警取决于告警是否可执行(actionable)。告警应分3级：Critical(立即处理)、Warning(延迟处理)、Info(仅记录)。关键原则是只有需要后续处理动作的告警才应配置，否则会产生告警疲劳。每个告警规则都应配套SOP处理预案，标注在告警规则的Annotations中。这比单纯搭建监控系统更有价值，能真正提升故障处理效率。作者建议从业务影响角度评估告警必要性，避免无效告警噪音。
2025-07-23 17:18:46
406
原创 夜莺监控V8发版，内置支持 DeepSeek 对接
夜莺监控发布v8.beta14生产可用版本，建议升级，正式版将于7月4日夜莺大会推出。主要更新包括：新增Postgres告警支持，可对业务数据（如订单、商品）进行异常检测；告警事件Pipeline接入AI Summary功能，使用DeepSeek等模型自动生成告警总结；改进告警事件匿名访问机制，支持生成带过期时间的分享链接。升级注意事项：v6/v7版本可平滑升级，需备份关键文件，DB账号需有改表权限，容器用户可直接拉取最新镜像。产品介绍PPT已同步更新。
2025-06-24 09:47:42
1077
原创 开源夜莺支持MySQL数据源，更方便做业务指标监控了
夜莺监控项目最新版本增强告警引擎功能，新增MySQL数据源支持，扩展业务监控能力。此前版本已支持Prometheus、VictoriaMetrics等传统数据源，现进一步丰富数据源类型。本次更新修复了通知媒介保存和Elasticsearch语法报错两个Bug。升级时可从GitHub获取最新发布包，v6/v7版本可平滑升级，建议备份后替换文件。产品特性可通过提供的PPT了解详细功能。
2025-06-11 09:43:31
758
原创 运维想转SRE？先了解这7个原则
软件开发的大部分工作理所当然地集中在创建上，包括 DevOps，这是一个相关但不同的领域，更关注产品的整个生命周期。但系统上线并不意味着工作就完成了。在 Google SRE 指南的前言中，作者指出，“系统总成本的 40%到 90%是在上线后产生的。”SRE 关注上线后的情况，旨在帮助确保产品尽可能保持可用。SRE 最重要的元素是系统可靠性和运行时间。世界上最好的服务如果无法运行，对任何人也没有多大用处。因此，SRE 专注于最小化停机时间并创建可靠的系统。
2025-05-28 08:12:37
1174
原创 使用 Feature Flag 的常见错误，SRE 总要懂的一些最佳实践
希望本文能够帮助你更好地理解 Feature Flag 的使用，避免常见的错误和陷阱。Feature Flag 是一个强大的工具，但需要谨慎使用。通过遵循最佳实践，你可以充分利用它们的优势，同时避免潜在的问题。
2025-05-22 17:02:53
1018
1
原创 顶级流媒体服务商 Spotify 2025.04 故障复盘报告，吃他人的堑长自己的智
2025年4月16日，Spotify经历了一次全球性服务中断，影响了除亚太地区外的全球用户。中断持续了约3小时25分钟，原因是Spotify在更改Envoy过滤器的顺序时触发了一个错误，导致所有Envoy实例崩溃。由于Envoy的最大堆大小设置高于Kubernetes的内存限制，Kubernetes不断重启Envoy实例，形成了恶性循环。亚太地区因流量较低未受影响。Spotify通过增加服务器容量缓解了问题，并承诺修复相关bug、改进配置更改发布方式和监控能力，以防止未来类似事件发生。此次事件强调了小变更可
2025-05-20 19:32:14
1164
原创 可观测性第四大支柱：配置数据的监控
日志、指标和跟踪仍然是可观测性的关键组成部分，而配置数据代表了第四根支柱，提供了对您系统独特见解。通过实施全面的配置数据监控，组织可以增强其安全态势、确保合规性、优化成本，并更深入地了解其基础设施。随着系统变得越来越复杂和分布式，配置数据监控的价值将只会增加。那些认识到这一第四支柱并将其纳入其可观测性策略中的组织，将更好地处于理解、排查故障和优化其日益复杂基础设施的有利位置。译者注：原文作者这个观点值得借鉴，但是对于故障定位等场景真的那么有用吗？也未可知。
2025-05-07 11:25:52
1036
原创 又来一个挑战 ElasticSearch 的，初识 SigLens
Elastic Stack 在日志领域具备无与伦比的地位，各类新兴的开源项目都声称比 Elastic 更节省资源，同时检索速度也不慢，比如 ClickHouse、Loki、OpenObserve、VMLogs，今天我们来看看另一个项目：SigLens。
2025-04-21 08:49:30
1079
原创 AI 和可观测性到底如何整合？
这一波 AI 浪潮跟以往都不同，各个行业都看到了新的可能性，都想把 AI 引入自己的场景，看看能迸发什么样的助力。上面的思路确实可以放到开源夜莺项目（Nightingale）里，作为一款开源软件，在一些功能上做增强，确实会变得更性感。但这些增强都是面向“点”的，有没有面向“面”的更让人眼前一亮的思路呢？
2025-04-17 07:31:59
937
原创 夜莺监控新版，中心端连不通的时序库也可以告警了
本文介绍夜莺新版本的一个重要更新，支持在中心端无法连通的时序库的告警。这个版本的更新增强了夜莺的灵活性和可用性，尤其是在复杂网络环境下的应用场景。希望大家能在实际使用中体验到这个新功能的便利。
2025-03-31 10:38:27
1168
原创 夜莺监控 v8.0 新版通知规则 | 对接飞书告警
夜莺监控 v8.0 版本抽象了通知规则的概念，本文讲解在新版通知规则里如何对接飞书，发送飞书告警，既可以支持普通飞书消息也可以支持飞书卡片消息。
2025-03-17 10:48:18
756
原创 夜莺监控 v8.0 新版通知规则 | 对接企微告警
夜莺监控v8.0版本引入了新版通知规则，可以很方便对接钉钉、企微、飞书，本文介绍如何对接企微告警
2025-03-13 14:45:52
957
原创 夜莺监控 v8.0 新版通知规则 | 对接钉钉告警
夜莺 v8 从 beta7 版本开始，抽象了通知规则的概念，本文介绍如何使用新版通知规则对接钉钉通知
2025-03-07 16:03:05
1142
2
原创 夜莺监控巨大革新：抽象出通知规则，增强告警通知的灵活性
夜莺监控在 v8.beta7 中做了一个巨大革新，抽象了一个通知规则的概念，来增强告警通知的灵活性，解决多年来的夙愿。
2025-03-06 11:03:01
1148
原创 夜莺监控 - 边缘告警引擎架构详解
夜莺类似 Grafana 可以接入多个数据源，查询数据源的数据做告警和展示。但是有些数据源所在的机房和中心机房之间网络链路不好，如果由 n9e 进程去周期性查询数据并判定告警，那在网络链路抖动或拥塞的时候，告警就不稳定了。所以，夜莺引入了边缘告警引擎：n9e-edge。n9e-edge 进程部署在边缘机房，和边缘机房的时序库部署在一起，由 n9e-edge 负责边缘机房的告警判定工作，这样整个架构就稳定的多了。
2025-02-25 12:01:17
1561
原创 Prometheus 历史峰值看不到了，这监控不准啊
Prometheus 生态的 step 参数是一个很重要的概念，对于监控数据的查询有着重要的影响。大部分情况下，用户不需要关心这个参数，因为监控系统会自动计算 step，以保证查询效率和数据展示的合理性。但是如果你想看原始数据，或者想了解监控数据的采集频率，那就需要了解 step 参数的含义，以及如何手工指定 step 参数啦。
2025-02-24 11:03:13
602
原创 是时候解决告警事件数据孤岛问题了
大家有没有发现，随着公司发展，慢慢引入了越来越多的监控、可观测性的系统，云上的、云下的，开源的、商业的，通用的、特定产品的，导致告警事件分散在非常多的地方，形成一个一个的数据孤岛。比如下面这些监控系统，你们应该不止用了一个吧：上图中有些系统你可能会困惑，比如 OceanBase，明明是个数据库，为啥出现在这里。因为 OceanBase 自己内置有自己的监控能力，没有复用 Prometheus 之类的通用监控系统，这就是上面我提到的特定产品的监控。
2025-02-18 12:10:11
738
原创 夜莺监控发布 v8.beta5 版本，优化 UI，新增接口认证方式便于鉴权
夜莺监控发布v8.beta5版本，重点优化了告警规则配置的UI，同时支持用户token认证鉴权方式，简化接口调用，便于和公司内部系统对接
2025-02-17 11:03:18
1262
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人