SRETALK

前言 夜莺类似 Grafana 可以接入多个数据源，查询数据源的数据做告警和展示。但是有些数据源所在的机房和中心机房之间网络链路不好，如果由 n9e 进程去周期性查询数据并判定告警，那在网络链路抖动或

经常在夜莺社区收到用户反馈，说查询某个监控指标，昨天的峰值是 xx，今天再次查询，发现昨天的峰值看不到了，然后开始吐槽，你们这监控怎么搞的，一点都不准啊。事实真的是这样吗？ 真实原因 本质上这是因为

大家有没有发现，随着公司发展，慢慢引入了越来越多的监控、可观测性的系统，云上的、云下的，开源的、商业的，通用的、特定产品的，导致告警事件分散在非常多的地方，形成一个一个的数据孤岛。比如下面这些监控系统

夜莺监控发布v8.beta5版本，重点优化了告警规则配置的UI，同时支持用户token认证鉴权方式，简化接口调用，便于和公司内部系统对接

告警事件产生之后，会带有一些 labels、annotations、description 等信息，有时这些信息不够规整需要二次处理，有时这些信息不够丰富需要附加更多信息，才方便 SRE 等 OnCa

对于大部分公司，通常都不止一套监控、可观测性相关的系统，云上的、云下的，开源的、商业的，指标的、日志的、链路的，各个系统体验不同，权限难管，如何统一化并为各个团队赋能，是很多技术负责人极为头疼的问题。

夜莺开源监控项目发布了新版本，支持了 ES 日志告警，相比 ElastAlert 提供了更易用的体验

夜莺监控项目在上周突破了一万 star，算是一个小小的里程碑。在开源领域，通常把 star 数量看作项目的繁荣指标，star 数量越多，说明愿意关注你的人越多。这个数字的背后，是一群人对你的鼓励、认可

夜莺 v8 发布第一个 beta 版本，增强了机器监控的灵活性，支持告警阈值的覆盖操作，后续也将在 v8 里支持 ClickHouse、ElasticSearch 的告警，持续打造灵活的告警引擎