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

PromQL 从⼊⻔到精通 对于 Prometheus 生态的监控系统，PromQL 是必备技能，本文着重点讲解这个查询语言，掺 杂一些生产实践场景，希望对你有所帮助。 ? 本文作者：秦晓辉，Open-Falcon、Nightingale 等开源项目创始人之一，极客时间《运 维监控系统实战笔记》作者；当前在创业（快猫星云联创），为客户提供监控/可观测性产品 方案，有需求的朋友欢迎联系我的微信 从了。 Prometheus 文档中有一个章节专门介绍函数，各个函数的介绍中，都会写明是用于 instant- vector，还是用于 range-vector，如果不理解查询类型，就无法很好的应用这些函数。 查询选择器 PromQL大括号里的部分是 selector，查询选择器，用于从一大堆监控数据中，过滤出真正关心 的数据，在 Prometheus 生态里，时序数据的标识，就是一堆标签集合，所以这里的过滤，就 (multiplication)  / (division)  % (modulo)  ^ (power/exponentiation) 1 1 举一个例子来演示真实环境下的算术运算符的应用，比如之前的例子，对于内存可用率的指标 mem_available_percent 这个指标是采集器直接计算好的，如果采集器没有计算，而是上报了 原始指标 mem_available 和 mem_total，我们仍然可以使用

FlashDuty 这种产品存在的价值。这些产品都是以 Duty 命名，核心就是支持告警 OnCall 值班处理的场景。 对于告警事件的后续处理，有哪些问题和需求以及何为最佳实践？我们从思路方法和工具实践两个方面分 别进行探讨，下面先行探讨思路方法，看看要解决这些问题和需求，我们有哪些可能的解法。 思路方法篇 告警事件的后续处理：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 OnCall 中心（ PagerDuty FlashDuty 这种产 品）在这些功能上会有一定的重叠，不过监控系统在这方面做得参差不齐，整体能力偏弱，使用统一的 OnCall 中心功能更强大，我们留待工具实践篇再详细阐述。 接下来我们聊一下“告警疏漏、无法闭环”的问题，核心就是告警发出来得有人处理，所谓的闭环，就是 指告警发出、认领、协作处理、问题恢复、复盘改进的整个过程。 虽然事 中心，下面我们以 FlashDuty 来举例，讲解 OnCall 中心的工具实践。 工具实践篇 称手好用的工具是可以大幅提升效率的，同时，好的工具可以沉淀最佳实践，沉淀经验，假设由你来设计 一款 OnCall 产品，处理告警分发相关的这一系列需求，你会如何设计呢？接下来，我们站在设计者的角 度，来讲解产品设计逻辑和实践方法，会更容易理解。 空间管理 通常来讲，一个公司不但会

快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 环节出问题都能及时感知 产品要求 01.端上、链路、资源、组件、应用多维度跨云监控 端上 卡顿 崩溃 链路 连通性 链路质量 服务端 硬件资源 组件服务 业务应用 夜莺介绍：国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 的 机制，轻量易用，无业务侵入性 • 内置集成了多种数据库中间件的采集以及网络设 备的采集，复用telegraf和datadog-agent的能力 • 支持statsd的udp协议，用于业务应用的apm监控 分析 夜莺数据采集 01.监控数据采集，all in one的agentd 夜莺数据采集 02. Autoconfig Forwarder 夜莺数据采集 02. Autoconfig