27万美元，制造业会损失42万美 元 美团故障？滴滴故障？腾讯故障？ 运维监控需求来源 01.监控的原始需求来自业务稳定性 如何减少服务停摆导致的经济损失？尽快发现故障并止损！故障处理过程中，监控是『发现』和『定位』两个环节 的关键工具。故障处理过程的首要原则是『止损』，因此，过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 独创在端上流式读取日志，根据正则提取指标的 机制，轻量易用，无业务侵入性 • 内置集成了多种数据库中间件的采集以及网络设 备的采集，复用telegraf和datadog-agent的能力 • 支持statsd的udp协议，用于业务应用的apm监控 分析 夜莺数据采集 01.监控数据采集，all in one的agentd 夜莺数据采集 02. Autoconfig Forwarder 夜莺数据采集 02

对于告警事件的后续处理，有哪些问题和需求以及何为最佳实践？我们从思路方法和工具实践两个方面分 别进行探讨，下面先行探讨思路方法，看看要解决这些问题和需求，我们有哪些可能的解法。 思路方法篇 告警事件的后续处理：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 处理等等。看起来需求很多，最核心的痛点有两个： ● 告警太多，打扰太多 ● 告警疏漏，无法闭环 会发现紧急需要处理的告警事件通常容易对应 Runbook，但是有些告警规则产生的告警确实没有那么紧急，有些只是想作为一个通知，好像又确实难以 对应一个固定的 Runbook。 针对这两种情况，我的做法是：不紧急的告警，也必须要有动作，虽然这个动作可能不是立马执行处理， 但至少要创建个低优先级的工单之类的，或者提高告警阈值，等问题严重一些再告警。对于只是想通知一 下的告警，其实都 分享一下我的理解，你可以参考 借鉴。 首先，不同级别的告警应该对应不同的处理逻辑，这样分级才有意义，比如通知渠道不同，通知范围不 同，或者介入处理的人的范围不同，处理时效不同 ，如果某两个级别对应完全一样的处理逻辑，就可以 合并成一个级别。 我的做法是把告警分成 3 个级别。 级别 通知渠道 说明 Critical 电话、短信、即时消息、邮件 影响收入的、影响客户的，必须立刻处理

system_load5{app="clickhouse"} > 8 unless vector1 unless vector2，结果是一个由vector1中的元素组成的向量，在vector2中没有完全匹 配标签集的元素，两个vector中的所有匹配元素都被删除。姑且可以理解为一个减法，vector1 - vector2。 举个例子，还是磁盘利用率的问题，对于超过1个T的大盘，剩余量小于300G就告警，promql 的每个条目找到一个匹配的元素，匹配行为分 为：one-to-one、many-to-one、one-to-many。 on 和 ignoring 上面演示 and、or、unless 的例子，两个vector的标签集都是一样的，那如果有些标签略微有 些差异，可以使用 on 和 ignoring 关键字来限制用于做匹配的标签集。举例： mysql_slave_status_slave_sql_running ==0表示slave sql线程没有在运行。 但是mysql_slave_status_slave_sql_running和mysql_slave_status_master_server_id这两个 metric的标签可能并非完全一致，不过好在二者都有个instance标签，且相同instance标签的数 据从语义上来看就表示一个实例的多个指标数据，那就可以用on关键字，指定只使用instance