57% 的企业现在花在遥测上的钱比被监控的基础设施还多，而 56% 连回答质量都量不了

2026 年 10 月 20 日，Cisco 发布了第六份《Splunk State of Observability》年度报告，这次调查了 10 个国家 2,050 名 ITOps 与工程人员。核心结论并不复杂：部署 AI Agent 的紧迫程度，已经远远超过监控它们的能力。Cisco 总裁兼首席产品官 Jeetu Patel 的那句话很直白——大多数公司很快就会拥有远超员工的 Agent 数量，而大规模管理 Agent 需要把安全和可观测性一起重做：我们的 Agent 有没有被攻陷？它们干得好不好？在 agentic AI 的世界里，这两个问题不可分割，而且是以机器速度在跑。这份报告的价值在于，它把这种「不可分割」量化成了具体的百分比。

57% 说可观测性账单已经超过被观测对象的成本。

一、优先级很高，业务结果没接上

87% 的受访者确认「监控 AI」是组织的优先事项——这个数字高得几乎不需要讨论。但紧接着的两行数据才是问题所在：54% 并没有把清晰的业务结果挂到这件事上，而 56% 承认自己无法测量 AI 工作负载的指标，比如 LLM 的回答质量。换句话说，绝大多数团队已经在花钱监控 AI，却没有定义「监控成功长什么样」。报告对此的解释是结构性的：传统应用的监控看的是延迟、错误率、饱和度；AI Agent 需要的是另一类「行为指标」，要绑到业务结果和 Agent 的决策过程上。而这类指标，恰恰是最难定义、也最容易被跳过的一层。

# One span per agent run, with attributes you can actually bill against.
# Names follow the OpenTelemetry GenAI semantic conventions where they exist.

span_name: invoke_agent
attributes:
  gen_ai.operation.name: invoke_agent
  gen_ai.agent.id: reviewer-code-quality      # which agent
  gen_ai.agent.version: 2026-10-05             # which build
  gen_ai.request.model: claude-sonnet-5.5
  gen_ai.request.effort: high                  # effort IS a cost input
  gen_ai.usage.input_tokens: 184320
  gen_ai.usage.output_tokens: 6120
  gen_ai.usage.cache_read.input_tokens: 1041880
  gen_ai.usage.cache_creation.input_tokens: 72400
  app.workload: code-review                    # the billable unit
  app.tenant: acme
  app.outcome: posted_review                   # success | timeout | denied
  app.tool_calls: 16
  app.retries: 1

# Per-run attributes are what turn a telemetry lake into a cost model.
# Session-level aggregates only tell you that you spent money.

二、幻觉可见性：85% 说重要，58% 说做得到

报告里有一组对比特别适合贴在监控看板上方：85% 的人认为「能看见 AI 幻觉」很重要，只有 58% 声称自己有效地做到了。这不是态度问题，是工具问题——你无法用 P99 延迟去发现一段看起来通顺、实际上是编造的回答。这也解释了为什么「响应质量」这类指标在 56% 的组织里是空白：它需要抽样、需要评分器（judge）、需要把评分和成本记在同一个 run 上。而这三件事，传统 APM 一件都不做。

-- Attribute spend to an agent, a model and a workload, from telemetry
-- you already store. Cache writes and reads must be priced separately
-- or the number is wrong by a factor of ten.
WITH runs AS (
  SELECT
    span_attributes['app.workload']                   AS workload,
    span_attributes['gen_ai.agent.id']                AS agent_id,
    span_attributes['gen_ai.request.model']           AS model,
    sum(CAST(span_attributes['gen_ai.usage.input_tokens'] AS BIGINT))            AS in_tok,
    sum(CAST(span_attributes['gen_ai.usage.output_tokens'] AS BIGINT))           AS out_tok,
    sum(CAST(span_attributes['gen_ai.usage.cache_read.input_tokens'] AS BIGINT)) AS cache_read,
    sum(CAST(span_attributes['gen_ai.usage.cache_creation.input_tokens'] AS BIGINT)) AS cache_write,
    count(*) AS runs
  FROM otel_traces
  WHERE date >= current_date - INTERVAL '7' DAY
    AND span_attributes['gen_ai.operation.name'] = 'invoke_agent'
  GROUP BY 1, 2, 3
)
SELECT
  workload, agent_id, model, runs,
  round(
      in_tok      / 1e6 * price_input
    + out_tok     / 1e6 * price_output
    + cache_read  / 1e6 * price_cache_read
    + cache_write / 1e6 * price_cache_write
  , 2) AS usd_7d,
  round(
      (in_tok      / 1e6 * price_input
     + out_tok     / 1e6 * price_output
     + cache_read  / 1e6 * price_cache_read
     + cache_write / 1e6 * price_cache_write) / runs
  , 3) AS usd_per_run
FROM runs JOIN price_pivot USING (model)
ORDER BY usd_7d DESC;

-- Which of these numbers moved week over week is the actual alert.

三、成本：不是账单大，是账单不可预测

关于钱的那几行是整份报告里最有信息量的。55% 说自己控制不了 AI 成本，原因是消费在涨、用量又难以预测。60% 说「意外的账单尖峰」比「高基线成本」带来更大的运营压力——注意这个措辞的转向：痛的不是贵，是不确定。而 57% 的组织说，遥测成本已经超过了被监控基础设施本身的成本。这句话值得停一下：可观测性本来是为了让系统可控，现在它自己成了需要被控制的成本项。报告里给的应对方向是「统一视图」：67% 的受访者使用单一可观测性平台，这样才可能精确定位遥测成本从哪来。

一次 Agent 会话会产生 trace、日志、token、工具调用和钱，而它们很少落在同一个地方。

# Quality is a metric, not a vibe. Sample outcomes, score them,
# and store the score next to the cost of producing it.

def record_eval(run_id, agent_id, sampled_output, reference):
    score = judge(sampled_output, reference)   # 0..1, rubric-based
    emit_metric(
        name="agent.quality.score",
        value=score,
        attributes={
            "agent.id": agent_id,
            "run.id": run_id,
            "eval.model": judge.model,     # judges cost money too
            "sampled": True,
        },
    )

# Sampling policy that keeps the signal and cuts the volume:
# - 100% of failures, denials and timeouts
# - 100% of runs above a cost threshold
# - 2-5% of the remainder, stratified by agent and workload
# Then chart quality against cost per run on the same axis.
# A cost drop with a flat quality line is a win; a cost drop with a
# falling line is a regression you would otherwise call an optimisation.

四、安全与可观测性在合流

当 Agent 拿到整条技术栈的访问权之后，一个错误的动作就可能变成一次业务事故，于是「可观测性团队」和「安全团队」之间的历史隔墙开始塌。83% 的受访者对 AI Agent 的意外后果表示担忧；81% 说监控 AI 工作负载增加了可观测性与安全团队之间的协作；能把性能问题准确追到安全根因的比例是 73%，去年是 65%；和安全团队一起排障的比例从 2025 年的 62% 升到 77%；两个团队之间的数据共享从 74% 升到 84%。这些数字合起来是一句话：Agent 时代，可观测性和安全是同一件事的两面，分开做会双输。

# Telemetry that costs more than the system it watches is a design bug.
# Split by signal type and drop what nobody queries. Nothing below is a
# vendor default; it is a policy that has to be written down.
retention:
  traces:
    agent_runs: 30d            # expensive, sampled, keep short
    tool_calls: 7d             # high cardinality, low per-row value
  metrics:
    agent.quality.score: 400d  # cheap, keep long
    agent.cost.usd_per_run: 400d
  logs:
    agent_transcripts: 14d     # redact secrets before storage
sampling:
  tail:
    keep_if:                   # evaluate once the trace is complete
      - status == error
      - cost_usd > 0.50
      - attribute.app.workload in ('billing', 'security-review')
    default_rate: 0.03
cardinality:
  forbid_labels:
    - prompt_text       # never a label: unbounded values
    - user_email
    - file_path

五、「领先组」做对了什么，以及由此推出的四个埋点决策

报告单独切出了一组「领先者」——那些用可观测性拿到具体业务结果的团队。他们的三个做法是：频繁用 Agent 去做修复和预防、紧盯让 AI 保持受控的要素（模型质量、成本、用量、安全、隐私）、把信号连到业务影响上。结果差异很大：91% 的领先者能准确归因 AI 成本，非领先者只有 69%；领先者认为可观测性平台 ROI 显著超预期的概率是非领先者的 2.4 倍；54% 的领先者说可观测性带来了至少 500 万美元的年业务收入（非领先者 28%）。落到工程上就是四个决策。第一，按「run」埋点：一次 Agent 调用一个 span，带 agent id、版本、模型、effort、输入/输出 token、缓存读写 token、工具调用次数、重试次数和结果状态——没有这些属性，你的遥测湖变不成成本模型。第二，缓存读和缓存写必须分开定价，否则成本能差一个数量级。第三，质量要作为指标存在，抽样策略比评分模型更重要：失败、拒绝、超时和超阈值的 run 全量留，其余按 agent 和 workload 分层抽 2% 到 5%。第四，遥测自己也要被治理：按信号类型分保留期、尾部采样、禁止把 prompt 明文和用户标识做成标签。这套东西不便宜，但比起「账单尖峰才知道出事」，它便宜得多。

84% 的组织现在与安全团队共享可观测性数据，去年是 74%。

# The alert set that matches what the survey says is missing.
alerts:
  - name: agent_cost_spike
    expr: >
      sum by (agent_id) (rate(agent_cost_usd_total[1h]))
      > 1.5 * avg_over_time(
          sum by (agent_id) (rate(agent_cost_usd_total[1h]))[7d:1h] offset 1h
        )
    for: 30m
    why: 60% say surprise spikes hurt more than a high baseline

  - name: quality_regression
    expr: avg_over_time(agent_quality_score[24h]) < 0.75
    for: 2h
    why: 56% cannot measure LLM response quality today

  - name: unattributed_spend
    expr: >
      sum(agent_cost_usd_total) - sum(agent_cost_usd_total{agent_id!=""})
      > 20
    why: cost with no agent, model or workload attached is precisely
         the number leaders can attribute and non-leaders cannot