# 服务日志告警 {#service-log-alerts}

在控制台的「可观测性 → 规则 → 服务日志匹配」选择一个应用（Nomad job ID），按需填写服务名、包含文本、排除文本或 JSON 字段和值。文本区分大小写，所有条件同时满足；JSON 字段支持点分路径。预览返回匹配条数和一个最多 512 UTF-8 字节的样例，不保存规则或发送通知。

阈值采用「大于」语义：填 4 表示至少匹配 5 行，填 0 表示一行即触发。建议匹配任务失败摘要，避免按堆栈行数重复统计。重试产生的摘要分别计数，并不代表不同业务任务。

Control 保存规则并读取小份缓存结果。独立的 `observe/log-alerts` 进程调用 VictoriaLogs 原生聚合接口，查询不在 Control 进程或 SQLite 锁内执行。告警事件、确认、静默、恢复和通知继续复用 Control 告警中心，不再通过 Alertmanager 重复发送。

## 资源限制与异常语义 {#budgets-and-failure-semantics}

- 最多 20 条日志规则，每条限定一个应用，窗口为 60–900 秒。
- 串行查询，全局查询间隔至少 2 秒，单条规则评估间隔至少 60 秒。VictoriaLogs 查询超时为 1 秒，客户端超时为 2 秒。
- 预览仅保留一个合并槽位，每 10 秒最多接受一个新预览，与定时规则共享查询预算。页面轮询最多 50 秒。
- 聚合响应上限 256 KiB，配置交换上限 64 KiB。Control 本机请求超时 500 毫秒，不等待日志查询完成。单条规则另有 2400 字节配置预算。
- 不创建日志临时文件、磁盘缓存、动态规则文件、持久化卷或后台重试任务。运行时根文件系统只读，禁用 Python 字节码写入，内存上限 96 MiB，CPU 调度份额 50 MHz；CPU 份额不是硬配额。
- 日志采集器必须追平所选服务的所有运行实例和日志流。读取或导出失败、轮转丢失、采集落后以及超过 150 秒的统计结果均视为不可用。监控状态最多保留 2048 个流。
- 指定 JSON 字段缺失、窗口内没有源日志，均不视为零错误或业务恢复。正常情况下长期无日志的服务应使用心跳或业务指标补充监控。
- 统计使用现有采集时间，重启、补采和重试可能影响窗口计数。错误减少不能证明丢失的业务任务已得到补偿。

## 部署和配置 {#delivery}

升级 Control（包含 API 和控制台），再部署 `observe/`，安装仅监听本机 9109 端口的日志告警进程及采集覆盖接口。旧版 observe 会返回不可用，不会伪造成功。文本规则无需修改业务应用。

部署本身不启用规则，需要在告警中心创建规则并选择通知渠道。编辑规则会保留 `logQuery`；匹配条件变化会重置当前事件，与阈值变更的处理一致。

`luma/log_alert_rules.py` 是共享规则契约，`observe/log_alert_rules.py` 保留完全相同的副本，保证 observe 构建目录独立，回归检查确保二者一致。

第一版仅接受声明式配置，不开放任意 LogsQL、无界正则、跨应用查询或历史回填。重要业务的完成率、耗时和积压监控，后续应结合业务指标实现。


## 事件日志与应用入口 {#incident-evidence-and-application-navigation}

每个应用详情页提供「告警」页签。告警中心的事件和规则列表也支持按应用筛选；统计和分页在数据库中按应用索引执行，不会先取一页再过滤。适用于全部应用的通用规则仍会显示，名称碰巧相同的节点告警不会混入应用事件。

同一次原生聚合使用 `json_values(...) limit 3` 取得最多 3 条代表性日志，不排序、不增加第二次查询。样例会清理常见凭据，消息最多保留 512 UTF-8 字节（开头和结尾），每条完整样例最多 900 个 JSON 编码字节。64 KiB 的配置和结果交换上限、串行查询频率及 96 MiB 进程内存上限均保持不变。

每个事件只保存一份有上限的日志快照，仅在新采样仍超过阈值时替换；恢复后保留最近的异常窗口。列表只传摘要，点进详情读取已保存的日志、来源、采样时间、窗口和匹配条数，不查询 VictoriaLogs。群消息使用同一份快照，并链接至对应应用的告警详情。「检索此窗口日志」会带上原应用、服务和时间范围，首次最多返回 100 行。

样例可能截断，顺序不保证，重复日志也可能合并；匹配行数不等于独立业务失败次数。快照随现有告警历史保留策略清理，不另建临时文件或不断追加的样例历史。升级前未保存日志的历史告警会明确提示，不会用当前日志冒充历史异常。