能采用的 Zabbix，Kubernetes 的监控可能 用的 Prometheus（Kubernetes 可能有多套，以至于 Prometheus 可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 通过排班、认领、升级这些机制，可以确保告警递达指定的人，但要处理告警的话，只有值班人员自己就 未必搞得定了，需要有协同机制把相关人都拉进来一起处理才可以。对于某个故障，可能同时有多个告警 事件产生，大家基于一个统一的故障协同，而不是基于一堆事件分别协同，这就需要把这多个事件收敛成 一个故障，下面我们来聊一下这个收敛逻辑。 告警收敛逻辑 一般收敛逻辑是三级收敛，event -> alert -> inc "host=host1"]) 从 event 到 alert 的这个收敛逻辑，我们叫做一级收敛。只有这个收敛逻辑还不够，告警信息还是比较 散，不能基于这些散乱的告警分别做协同，把多个 alert 收敛成一个 incident（故障），基于 incident 做协同才比较方便。但是，event 到 alert 是有一个固定的收敛逻辑的，可以通过程序自动收敛，而 alert 到 incident

• 分布式⽂文件 • 进程监控 业务层 • qps/tps • 耗时分布 • 饱和度 • 吞吐量量 • 依赖响应 • 缓存命中率 • 调⽤用链 • SLA • ⽇日志 播放质量量 • 点播/直播 • 播放卡顿 • 平均⾸首帧 • 播放失败率 • 弹幕加载 • cdn质量量 客户端质量量 • ⽤用户端⽹网络质量量 • 劫持情况 • 分析监控场景对应监控⼿手段 类型 metric类型 ⽇日志类型 ⾃自定义类型 ⼿手段 时间序列列数据 ⽇日志处理理流 ⾃自研 ⽤用户端监控 apm ⾃自研 客户端 播放器器 如何推进？ 服务端监控 场景 分析监控场景对应监控⼿手段 类型 metric类型 ⽇日志类型 ⾃自定义类型 ⼿手段 时间序列列数据 ⽇日志处理理流 ⾃自研 ⽤用户端监控 apm 能覆盖⼤大部分监控场景 • 固定⼏几种数据类型 ✦ Counter ✦ Gauge ✦ 等.. • 时序数据 ✦ 具有统计特性 ✦ 具有规律律性 metric数据特征 选型原则 • 基于开源⽅方案，⼆二次开发 • 具备现代时间序列列数据库的特性 • 活跃项⽬目,具有成熟的⽣生态环境 结论 • prometheus • ⽀支持任意维度label • cncf基⾦金金会

监控数据采集，all in one的agentd Agentd 进程存 活 端口监 控 插件脚 本 日志监 控 网络设 备 中间件 类 数据库 类 • 支持在web上配置采集策略，不同的采集可以指定 不同的探针机器、目标机器，便于管理和知识传 承 • 独创在端上流式读取日志，根据正则提取指标的 机制，轻量易用，无业务侵入性 • 内置集成了多种数据库中间件的采集以及网络设

0909-60）~1661570909之间的 increase 数值。但是原始监控数据并没有 1661570849、1661570909 这两个时刻的数值，怎么办呢？ Prometheus只能基于现有的数据做外推，即使用最后一个点的数值减去第一个点的数值，得到 的结果除以时间差，再乘以60，即： (965323899880.0-965304237246.0)/(1661570900.0-1661570850 也没办法，这本来就是个预估 值，知道大概数量级就可以了，还是那句话，监控数据是采样数据，这么计算虽然不是那么准 确，但是成本低。 实际上，我们基于某个指标的历史所有数据计算分位值，意义不大，通常我们是基于最近一段时 间的增量数据来计算，比如基于10分钟区间的增量数据计算，就可以较为方便的知道，当前这 个10分钟的延迟是多少，上一个10分钟的延迟是多少。histogram_quantile