你们是如何设计 Prometheus 告警规则的？一条好的告警规则应该包含哪些要素？

我们告警设计原则：每条告警必须可操作，有 runbook 链接。

规则结构：expr 写 PromQL 条件，for 设持续时长避免抖动，severity 分 critical/warning 两级走不同渠道——critical 打电话，warning 发钉钉。

真实规则示例：Pod 内存超 85% 持续 5 分钟触发 warning，超 95% 持续 2 分钟触发 critical。

踩过的坑：for 没设，CPU 瞬间抖动就告警，值班半夜被叫醒发现是误报，后来所有规则强制加 for: 3m。

你们是如何做日志分析的？当线上出现问题时，如何通过日志快速定位根因？

我们的日志体系是victorialog，主要的组件有vmselect负责查，vminsert负责数据输入，vmstorage负责数据存储，flunt服务日志的采集。
使用vm的展示页面快速定位网关接口的状态和接口超时时间，快速排查页面响应慢的问题
之前排查接口慢要登每台机器查日志，平均 15 分钟；用 VictoriaLogs 后直接搜 traceId，2 分钟定位到根因。
踩过的坑：各服务日志格式不统一，有 JSON 有纯文本，查询时无法跨服务聚合，后来统一了结构化日志格式。

什么是分布式链路追踪？Jaeger 是如何工作的？你们是如何接入的？

链路追踪解决的问题是：一个请求经过 N 个微服务，出了问题不知道卡在哪一跳，traceId 把全链路串起来。
jaeger采集应用端的接口链路，需要应用端加上opentelemery的agent依赖并配置jaeger的服务端的配置，当访问api/v1的接口信息时能够采集的响应时间和响应头
我用过go的微服务配置过jaeger采集订单信息，发现一个订单信息响应6s，通过jaeger能快速排查对应的接口，快速响应和修复。
生产环境不能 100% 采集，性能损耗大，一般设 10%~20% 采样率，只采部分请求。

你们的监控告警是如何分级的？P1/P2/P3 各自的响应流程是什么？

我们按业务影响范围分三级：P1 核心功能不可用，P2 部分功能异常，P3 潜在风险。

P1 电话+钉钉双渠道，5 分钟内必须响应，502/支付失败直接触发；P2 钉钉通知 30 分钟响应，接口超时 2 秒以上触发；P3 邮件通知工作时间处理，内存 85% 触发。

真实 P1 案例：订单页面 502，5 分钟内通过 Jaeger 定位是数据库连接池耗尽，扩连接池后恢复。

踩坑：P2 告警太多导致值班疲劳，合并后只保留真正需要快速响应的。