BitzOrcas 模板定义告警阈值但不自动触发告警。一个外部监控系统——Prometheus、Datadog、Azure Monitor 或 Grafana——抓取 OpenTelemetry 指标并按这些阈值触发告警。本页是参考阈值表与逐信号 runbook;监控与告警覆盖通用可观测性设置。
告警阈值
| 指标 | 来源 | Warning | Severe | 频率 |
|---|---|---|---|---|
/health/ready 失败 | K8s readiness 探针 | 连续 1 次失败 | 连续 3 次失败 | 每 10s |
| HTTP 5xx 错误率 | OTel http.server.request.duration | >1%(5min) | >5%(5min) | 每 30s |
| CAP outbox 积压 | Cap.Published,未投递行 | >100 行 | >1000 行 | 每 1min |
| 作业连续失败 | /api/audit?Category=BackgroundJob 的 Success/ErrorCode | 1 次失败 | 3 次失败 | 每个 cron 周期 |
| 审计写入积压 | 审计通道队列深度 | >10000 条 | >50000 条 | 每 1min |
| Seed 初始化失败 | --init-schema CLI 退出码(无平台 REST 端点) | 任意非零 | — | 执行时 |
| 生产中 InMemory/Null 适配器 | GET /api/operations/adapters | 任意关键端口 = Default/Unavailable | — | 每 5min |
| 缺失/弱 key 配置 | GET /api/operations/config | 任意 required 缺失/过短 | — | 每 5min |
| 未授权 Operations 访问 | /api/audit?Category=Security | 单 IP >10/min | >50/min | 实时 |
逐信号诊断 runbook
通用形态:读 Operations 适配器/配置端点,检查具名子系统,检查依赖基础设施(SQL/RabbitMQ/Redis),修正配置,重启或滚动重新部署,并通过健康探针确认恢复。
/health/ready 连续失败
GET /api/operations/adapters——识别哪个 readiness 标记的健康检查失败。GET /api/operations/config——确认连接串与 RabbitMQ 配置。- 连接 SQL Server 并运行
SELECT 1确认可达。 - 检查 RabbitMQ 管理 UI 的连接数与队列状态。
- 若依赖恢复,Kubernetes 自动恢复流量分发。
HTTP 5xx 错误率激增
GET /api/audit?Category=Exception&From=<5min-ago>——读取受限 Envelope,并用 CorrelationId 关联日志与 Trace 详情。- 检查 OTel trace 找到错误最多的端点。
- 对 EF Core/SqlSugar 异常,检查 DB 连接池与死锁。
- 对 OOM,检查
dotnet-counters的 GC 与堆大小。
CAP outbox 积压
- RabbitMQ 管理 UI——确认
bitzorcas.*exchange 有消费者。 SELECT COUNT(*) FROM Cap.Published WHERE Retries < 50——查看积压量。- 若消费者未注册,检查 API/JobHost 是否正确启动。
- 若 RabbitMQ 不可达,CAP 自动重试;恢复后积压排空。
作业连续失败
GET /api/audit?Category=BackgroundJob&Module=Auditing——读取作业结果与稳定错误码,再关联日志查看异常详情。- 若
IAuditRetentionPort未注册,确认调用了AddBitzOrcasSqlSugarAuditStore。 - 对 SQL 执行超时,检查审计表索引与数据量。
- 通过
scripts/database/seed-demo.sh(seed 问题)手动重跑或重启 JobHost。
生产中 InMemory/Null 适配器
GET /api/operations/adapters——确认哪些端口是 Default/Unavailable。GET /api/operations/config——确认ConnectionStrings:Default与RabbitMq:Host已配置。- 若配置缺失,通过环境变量注入并滚动重启。
- 若配置正确但适配器仍为 Default,检查
PersistenceRegistration中的分支逻辑。
缺失/弱 key 配置
GET /api/operations/config——找到缺失或过短的 key。- 通过 K8s Secret / Key Vault 注入正确值。
- 滚动重启。
修复前后的证据采集
先保存基础健康、适配器和配置诊断。三个响应要来自同一实例、同一时间窗,Secret 字段不得进入事件附件:
# 基础 readiness 与运行时组合快照。curl -fsS https://<HOST>/health/ready > ready.jsoncurl -fsS -H "Authorization: Bearer <TOKEN>" \ https://<HOST>/api/operations/adapters > adapters.jsoncurl -fsS -H "Authorization: Bearer <TOKEN>" \ https://<HOST>/api/operations/config > config-diagnostics.json恢复后使用相同查询窗口重新采集审计 Envelope。查询端没有 Result 参数,应按返回的 Success 与 ErrorCode 统计,不要把未识别 Query 当成服务端过滤:
# 保留时间边界,便于比较修复前后作业和异常证据。curl -fsS --get -H "Authorization: Bearer <TOKEN>" \ --data-urlencode "category=BackgroundJob" --data-urlencode "module=Auditing" \ --data-urlencode "from=<INCIDENT-START-UTC>" --data-urlencode "pageSize=200" \ https://<HOST>/api/audit > background-jobs.json监控系统接入
| 监控系统 | 采集方式 |
|---|---|
| Prometheus | OTel Collector → Prometheus exporter;抓取 /metrics |
| Datadog | OTel Collector → Datadog exporter |
| Azure Monitor | OTel Collector → Azure Monitor exporter |
| Kubernetes | readiness/liveness 探针 → 自动告警 |
| Grafana | OTel → Tempo(trace)+ Prometheus(指标)+ Loki(日志) |