B站统⼀一监控系统的设计,演进 与实践分享 梁梁晓聪 devops @lxcong About Me • 梁梁晓聪 • 2015年年加⼊入B站 • devops • 热爱新技术,热爱开源 • ⼩小宅男 故事的开始 B站炸了了.舆情监控(括弧笑脸) 我们的挑战 • 技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低

利用夜莺扩展能力打造全方位监控系统 喻波 滴滴 专家工程师 目 录 运维监控需求来源 01 监控痛点：全面完备、跨云 02 夜莺介绍： 国产开源监控系统 03 夜莺设计实现：Agentd 数据采集 04 夜莺设计实现：Server 数据处理 05 夜莺设计实现：技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术，IT故障会直接影响营业收入， 稳定性体系一定要重视起来，而监控，就是稳定性体系中至 Server02 Agentd Agentd LoadBalance 1. 单机版Prom 2. 集群版m3db 3. 集群版n9e-tsdb 3种存储方案，按需选择 Agentd 夜莺设计实现 Agentd 数据采集 第四部分 监控系统的核心功能，是数据采集、存储、分析、展示，完 备性看采集能力，是否能够兼容并包，纳入更多生态的能力， 至关重要 夜莺数据采集 01.监控数据采集，all Aggregator Checks Statsd Aggregator Serializer 夜莺数据采集 06. Serializer 夜莺数据采集 07. Forwarder 夜莺设计实现 Server 数据处理 第五部分 夜莺Server数据处理 01. 服务器 02. API 夜莺Server数据处理 03. AlarmRule Control 夜莺Server数据处理

佳实践，沉淀经验，假设由你来设计 一款 OnCall 产品，处理告警分发相关的这一系列需求，你会如何设计呢？接下来，我们站在设计者的角 度，来讲解产品设计逻辑和实践方法，会更容易理解。 空间管理 通常来讲，一个公司不但会使用多个监控系统，而且会有很多个团队，如果所有的告警事件都在一个地方 查看、管理，就会相互打扰。所以，OnCall 中心首先要设计一个协作空间的概念，来归类处理不同的事

__name__，所以之前查询的例子，可以这么写： {__name__="mem_available_percent", app="clickhouse"} 仍然可以达成相同的效果。有时采集的监控数据格式设计的不好，一些本该用 label 的信息，放 到了 metric 名称中了，此时就可以用 __name__ 做一些正则匹配。 Offset 监控系统里，经常会有同环比的需求，比如，当前的值相比一周之前，是否有巨大变化，那怎么 函数计算得到的。 histogram_quantile 要了解 histogram_quantile 函数的用法，首先得了解 Histogram 类型的数据。Histogram 翻 译过来是柱状图，设计这个数据类型，是为了描述响应延时的情况。 比如接口：/api/v1/query，如何度量这个接口的健康状况？最核心有两个指标，一个是成功 率，一个是延迟，成功率的计算代价比较小，只需要为每个请求指标打上 控系统中存储这1亿个请求，然后排序，然后求取分位值？那这个代价就太大了。监控数据是采 样数据，对准确性要求没有那么的高，有没有什么办法可以降低这个代价呢？这就是 Prometheus Histogram 的设计初衷了。 Histogram 类型，是把延迟数据分到多个桶里，比如下面的例子，我们查询一个bucket指标看 看效果，虽然这个指标的桶划分不是很合理，也可以说明问题： binlog_consu