AuraBoot
免费开始
English简体中文

可观测性

审计日志流(可观测性数据流之一)

AuraBoot 构建在 Spring Boot 的 Micrometer 仪表之上，并为 meta 引擎、command pipeline、BPM 与 crawler 子系统补充了平台特有的 gauge 与 counter。目标是：任何一起生产事故都能仅凭时间序列与结构化日志复现。

三大支柱

支柱后端真源
MetricsPrometheus每个节点的 /actuator/prometheus
LogsLoki / ELKstdout JSON 行
TracesOpenTelemetry collectorOTLP exporter，通过 traceparent 传播

每个请求带一个 traceparent header。处理该请求过程中产生的 logs 与 metrics 都打上同一个 trace id，因此一个 trace id 就能在三大支柱之间相互跳转。

何时使用

  • 搭建新环境：在把 URL 暴露给用户之前，先接入 Prometheus 抓取与 Grafana 看板。
  • 排查延迟：从 trace 入手，钻入 span，再用 metrics 印证。
  • 容量规划：对 http_server_requests_seconds_* 做长周期的 Prometheus 查询。
  • 审计：结构化日志是安全事件的权威记录。

指标命名约定

平台自定义指标统一以 auraboot_ 为前缀，采用 Prometheus 的 snake_case 命名；tag 也用小写 snake_case。

指标示例含义
auraboot_command_execution_totalauraboot_command_execution_total{command_code="qualify_crm_lead", model_code="crm_lead", status="success"}Command 执行次数 counter
auraboot_command_execution_duration_secondsauraboot_command_execution_duration_seconds{command_code="qualify_crm_lead", model_code="crm_lead"}Command 执行延迟 timer（带 histogram）
auraboot_api_requests_totalauraboot_api_requests_total{path="/api/...", method="POST", status="200"}API 请求次数 counter
auraboot_active_sessionsgauge当前活跃会话数
auraboot_llm_requests_totalauraboot_llm_requests_total{provider="...", model="...", status="success"}LLM 请求次数 counter
auraboot_plugin_install_totalauraboot_plugin_install_total{plugin_code="...", status="success"}插件安装次数 counter

避免无界 tag（原始用户输入、记录 id）。基数爆炸是 Prometheus 自打自爆的头号原因。

工作原理

# application.yml（节选）
management:
  endpoints:
    web:
      exposure:
        include: ${ACTUATOR_ENDPOINTS:health,info,metrics,prometheus}
  metrics:
    tags:
      application: auraboot
  tracing:
    sampling:
      probability: 1.0   # dev 默认 100%，生产可降到 0.1
    propagation:
      type: w3c
  otlp:
    tracing:
      endpoint: http://localhost:4318/v1/traces   # dev 默认；生产改为 collector 服务地址

上面 OTLP endpoint 是开发默认值。生产部署中通常指向 collector 的服务地址（如 Kubernetes 内的 http://otel-collector:4318/v1/traces）。

Prometheus 抓取配置：

scrape_configs:
  - job_name: auraboot
    metrics_path: /actuator/prometheus
    scrape_interval: 15s
    static_configs:
      - targets: ["app-1:6443", "app-2:6443", "app-3:6443"]
        labels:
          env: prod

Grafana 中常用的查询：

# 最近 5 分钟按 command 的 p95 命令延迟
histogram_quantile(0.95,
  sum by (le, command_code) (rate(auraboot_command_execution_duration_seconds_bucket[5m])))

# 命令执行的失败率
sum(rate(auraboot_command_execution_total{status="error"}[5m]))
  / sum(rate(auraboot_command_execution_total[5m]))

# 按状态码统计的 API 请求速率
sum by (status) (rate(auraboot_api_requests_total[1m]))

结构化日志

每一行日志都是一个 JSON 对象，至少包含：@timestamp、level、logger、message、trace.id、tenant.id、user.id（已认证时）。缺少 trace.id 的行无法关联，属于缺陷。

{"@timestamp":"2026-05-28T10:11:12.345Z","level":"INFO","logger":"c.a.cmd.CommandPipeline","message":"command executed","trace.id":"4bf92f3577b34da6a3ce929d0e0e4736","tenant.id":"tenant_001","command_code":"qualify_crm_lead","status":"success","duration_ms":42}

验证

  • curl -sS http://app-1:6443/actuator/prometheus | grep auraboot_command_execution 返回非空序列。
  • Grafana 看板至少能渲染：command 执行延迟与失败率、API 请求速率、LLM 请求量的 p50/p95/p99。
  • OTLP 后端中采样到的 trace 含 HTTP → command → JDBC 的 span，且 span 属性包含 tenant.id。
  • 日志量是 JSON，每行都带 trace.id，单一 trace id 能在跨节点端到端 grep 出来。
  • 已对以下场景配置告警规则：p99 命令延迟、命令执行失败率、API 5xx 比率、JVM 堆压力、Postgres 连接池饱和。

相关