作者 | 星巴克中国技术团队

策划 | 华卫

背景与历史问题

随着业务与日志规模增长，早期基于 ElasticSearch 的查询式告警逐步暴露出瓶颈：性能与时效上，ES 在高写入与复杂聚合下查询变慢、易超时；误告警上，索引刷新 / 落盘延迟导致“当前实践窗口看不到最新日志”，或查询抖动失败，被脚本误判为异常；分析与留存上，用全文检索临时聚合 RED 指标既昂贵又缓慢，历史留存周期短，趋势 / 回溯困难；运维复杂度上，Logstash/ES/Zabbix 多段链路需要持续调优与演练，稳定性高度依赖单一检索引擎。基于这些现实约束，我们决定从“日志查指标”转向“日志就地指标化”：在日志进入链路即解析与去噪，直接产出接口级 Metrics，由 Prometheus 聚合与告警，缩短链路、降低延迟并强化聚合能力。

当前通用可观测性目标，主流做法是围绕“黄金信号 /RED”构建以请求、错误、时延为核心的度量，并用指标、日志、追踪三类遥测数据形成联动，既保证低延迟告警，也便于根因定位与长期趋势分析；据此，我们在不引入重型流式计算（如 Flink）的前提下，采用 Vector 将访问日志指标化的方式，联动并用指标与日志。

基于 Vector 的新监控体系

为解决上述问题，可观测性团队采用了“日志转指标”的思路，最终选择 Vector+Prometheus 作为核心架构。

与 Flink 等通用流计算框架相比，Vector 更专注日志处理，无需编写代码、部署维护成本低、学习曲线平缓，更适合日志转指标这类以稳定性和效率为优先的可观测性场景。

图 2 Vector 监控架构

Vector 实例作为 Kafka 消费者，不再经过 ElasticSearch，从 Kafka 中直接消费日志数据，利用强大的 VRL（Vector Remap Language）引擎对原始日志进行解析和清洗，将日志内容转化为结构化事件。例如解析出日志中的接口路径、HTTP 状态码、响应时间、域名等字段。

利用 Vector 的 log_to_metric 转换，将每条日志转变为一条或多条指标数据。同时对于每一次请求日志，生成计数和延时等度量值，如 http_requests_total（请求计数）和 http_request_duration_seconds（请求延迟直方图）等，并附加相应的标签（如接口名称、状态码）。

最后将转换得到的指标数据通过 Prometheus Exporter 方式对外暴露为指标端点。Prometheus 定期抓取 Vector 实例的指标。Prometheus 不仅存储指标，还支持在服务端根据原始时间序列定义 Recording Rule（记录规则），提前计算出更高层次的聚合指标，降低用户使用门槛的同时也降低后端 VictoriaMetrics 的存储和查询压力。

可观测性团队为 RED 指标设计了多组 Recording Rules。例如计算每个接口的总请求率、错误率和各百分位延迟。通过 PromQL 将 http_requests_total 按标签聚合并计算出每分钟请求数，以及利用 histogram_quantile() 对延时直方图计算 P95/P99 延迟等。这些计算结果作为新的时序指标存储在 Victoriametrics 中。通过 Recording Rules，复杂计算前置到采集阶段，查询与告警时只需读取现成结果，进一步提升了查询和告警配置效率。

同时，引入了 Flashcat（夜莺商业版）作为统一的可视化和监控配置入口。Flashcat 提供了“灭火图”界面，将各业务域、服务、接口的健康状态以层级和结构化方式呈现。当 Metrics 达到告警条件时，通过 Flashcat 触发告警通知。在 Flashcat 中将 Metrics、日志、告警、Traces 打通，实现了一处界面中从整体概览到指标细节再到日志 / 追踪的多层次下钻功能。运维人员可以在灭火图上直观地看到哪里出现异常，并一步步深入分析根因。

新架构最大的变化就是把日志分析前置为指标产出。这样，原本需要在查询时临时计算的工作改为在日志流入时实时计算并存储，大幅降低了 ElasticSearch 压力和提高了指标的查询速度。最终数据存储在 VictoriaMetrics，SRE 和研发伙伴可以毫秒内完成对业务关键指 RED 指标的查询和分析。总的来说，新方案在性能、实时性、查询能力各方面都显著优于旧架构。

技术实现

下面从日志解析配置、维度丰富、指标设计、架构扩展、数据存储等方面进行深入介绍。

日志采集与 Vector 转换

在部署上，每个 Vector 实例作为 Kafka 消费者节点，订阅相应的日志 Topic。为提升消费并行度，Kafka 的日志 Topic 被设置为多个分区，Vector 实例以消费组形式共同消费，实现负载均衡。在 Vector 的配置中，定义了 Kafka source（指定集群地址、Topic、消费组 ID 等）和后续的 transforms 来处理日志。

首先通过 Remap Transform 利用 VRL 脚本对日志进行解析和清洗。例如对于 JSON 格式的日志，直接解析出各字段；对于文本格式的日志（如 Nginx/Kong 访问日志），则使用正则提取出 method、path、status、duration 等字段。还可以对原始字段进行格式转换，如解析不同格式的日期格式等。

首先是关键的 log_to_metric 转换。Vector 允许针对每条日志事件派生出一个或多个指标。例如，在配置中我们为 HTTP 请求定义了两个指标：一个请求计数（counter）和一个响应时间直方图（histogram）。简化描述配置如下：

transforms:  make_metrics:    type: log_to_metric    inputs: [ "parsed_logs" ]    metrics:      - type: counter        name: http_requests_total        tags:          service: "{{sys}}"                # 业务系统名称，例如 "BizOps Portal"          endpoint: "{{endpoint}}"          # 归一化后的接口标识          method: "{{request.method}}"      # HTTP方法          status: "{{response.status}}"     # HTTP状态码      - type: histogram        name: http_request_duration_ms        field: response_time_ms            # 从日志提取的响应时间（毫秒）        buckets: [50, 100, 200, 500, 1000, 3000, 5000, 10000]   # 延时直方图桶边界(ms)        tags:          service: "{{sys}}"          endpoint: "{{endpoint}}"          method: "{{request.method}}"

上述配置含义是：对于每条 HTTP 请求日志，产生一条计数器 http_requests_total，并根据其内容附加四个标签；同时产生一组直方图样本 http_request_duration_ms，将该请求的耗时落入预先定义的一系列时间桶中（单位毫秒）。

通过这些定义，日志被转换成标准的时序指标。每当 Vector 处理一条日志，就会在内部维护的度量集合中将对应计数器 +1，并将延时样本计入相应桶。值得一提的是，Vector 的 log_to_metric 输出可以同时定义多条指标，如上例所示我们在一个转换中生成了两个指标。这种机制使我们能够高效地从一条日志提炼出多维度的数据点。

完成 log_to_metric 转换后，Vector 会将生成的指标缓存等待输出。由于指标输出不需要像日志那样逐条发送到外部系统，Vector 提供了 Prometheus Exporter 这种高效的汇聚输出。我们将 Vector 配置一个 Prometheus Exporter 类型的 sink：

sinks:  prometheus_out:    type: prometheus_exporter    inputs: [ "make_metrics" ]    address: 0.0.0.0:9100    flush_period_secs: 120

上述 sink 会令 Vector 在本机启动一个 HTTP 服务监听 9100 端口，对外提供 Prometheus 格式的 /metrics 接口。Vector 以内存形式维护所有活跃的指标，并通过 Prometheus Exporter 类型的 sink 实时暴露这些指标。

配置项 flush_period_secs:120 表示如果某个指标在 120 秒内没有出现新的日志事件更新它，Vector 会将其视为过期并从 /metrics 接口中移除。因此，这个配置项不代表汇总间隔，而是一个指标清理周期。为了避免 Prometheus 抓不到数据，通常应将 flush_period_secs 配置得略高于 Prometheus 的 scrape_interval。

丰富元数据

在日志转指标过程中，合理设计标签维度非常关键。过少的标签会导致指标缺乏区分度，过多的标签则可能引入高基数（high cardinality）问题，使存储和查询负担剧增。

星巴克中国技术团队在实践中高度重视维度规范和丰富，当前利用 CMDB 维护了一些映射表，例如域名或服务名称与业务属性的对应关系，通过 Vector 的 Enrichment Table 功能来动态查找并填充指标标签。

以域名映射表为例，CMDB 中记录了每个服务域名所属的业务系统代号（如会员系统、订单系统等）以及该系统归属的更高层业务域（如“用户运营域”、“交易域”等分类）。在 Vector 启动时，这张映射表会被加载为内存中的 Enrichment Table（类似于一张只读的键值表）。前文提到的 VRL 脚本就通过 get_enrichment_table_record 查询该表，以获取当前日志中域名对应的 sys 和 region 信息。然后将这两个字段附加为日志事件的属性，并在后续 log_to_metric 时作为标签引用（见上面的 service:"{{sys}}“和 endpoint:”{{endpoint}}"中的 sys）。

以下展示了 Vector 的部分配置片段示例，使用 VRL 对 Kong 网关的日志进行解析和字段提取，并根据预设规则对接口路径进行模式归类，同时从 CMDB 加载 Enrichment Table 来补充系统和业务域等维度标签，方便与业务紧密结合。

type: remapinputs:  - parse_external_kong_trace_messagesource: |  # 初始化业务系统和所属域  sys = "-"  region = "-"  # 查询 domain_info  if domain != "-" {    record = get_enrichment_table_record("domain_info", {"domain": domain}) ?? null    if record != null {      # 判断 record.sys 和 record.region 是否为有效值      if record.sys != "-" { sys = record.sys }      if record.region != "-" { region = record.region }    }  }

在该示例中，Vector 调用 get_enrichment_table_record 查询 CMDB 提供的域名映射表，获得对应的系统代号 (sys) 和业务域 (region)。这些丰富后的字段被添加回日志事件中，供后续指标转换和展示、告警系统使用。

通过 Enrichment Table 机制，实现了运维元数据与监控数据的打通：指标不仅体现技术参数，还携带业务语义。例如，一条接口请求指标现在会有“所属系统 = 会员中心”，“所属域 = 用户运营”等标签。这使得后续在查询和展示时，可以方便地按业务维度聚合查看。

比如 SRE 可以在 Flashcat 灭火图中筛选“交易域”的所有服务接口，观察其总体成功率；或者按系统查看各系统内异常指标。在 Flashcat 灭火图的界面中，不同业务域被分区显示，每个系统有独立卡片，正是基于这些丰富标签实现的。值得注意的是，通过 Enrichment Table 统一维护映射关系也方便了变更管理：当业务归属发生调整（比如某服务从平台域划归到用户域），只需更新 CMDB 表，监控系统的标签将自动随之变化，而不用修改大量配置。这种集中治理维度的做法确保了监控体系随业务演进而灵活调整，保持指标含义与组织结构一致。

RED 指标设计与 Recording Rules

有了基础的原始指标（请求总数、请求耗时等），下一步就是设计聚合计算规则，提炼出符合业务关心的 RED 指标和其他重要衍生指标。Prometheus 提供了 Recording Rules，可以将 PromQL 计算结果存储为新的时序数据，既减轻前端查询负担，又方便统一管理关键 SLO 指标。

以下列举星巴克技术团队定义的一些典型 Recording Rules：

请求率 / 流量

统计每个接口的请求吞吐。例如记录每 5 分钟内请求总次数的增量或平均 QPS。例如：

-record:api:request_count:5mexpr:increase(http_requests_total[5m])

计算过 5 分钟该接口收到的请求数增量，存储为新指标 api:request_count:5m。结合 Prometheus 的聚合，可以按业务系统或业务域对该值再汇总，用于观察整个系统的流量走势。

错误率 / 成功率

计算接口的错误比例。通常后端服务将 5xx 状态码视为服务端错误。可以通过状态码标签筛选 http_requests_total 来计算。例如：

- record: api:error_count:1m  expr: sum by(service, endpoint) (increase(http_requests_total{status=~"5.."}[1m]))- record: api:request_count:1m  expr: sum by(service, endpoint) (increase(http_requests_total[1m]))- record: api:success_rate  expr: (1 - api:error_count:1m / api:request_count:1m) * 100

首先计算每分钟 5xx 错误请求的数量，以及总请求数，然后计算成功率百分比 success_rate。这样每个接口每分钟的成功率都有一个记录。需要注意是否将 4xx 计入错误率取决于实际需求：在星巴克的场景中，一般 4xx 是用户请求错误，不计入服务可用性错误，但也可能单独监控其变化趋势，比如典型的 499 类错误。

延迟百分位

通过 PromQL 的 histogram_quantile 函数，从延迟直方图计算例如 P90、P95、P99 等时延指标。例如：

-record:api:latency_p99expr:histogram_quantile(0.99,sum by(service,endpoint,le)(rate(http_request_duration_ms_bucket[5m])))

规则对每个接口的延时直方图在 5 分钟滑动窗口上求和，计算第 99 百分位的响应时间，记录为 api:latency_p99。类似地可计算 P50、P95 等。通过 Recording Rule 预先计算，可以在故障发生时直接查看历史 P95、P99 曲线，而不必临时计算。

状态码分布

为了快速了解接口异常类型，团队还记录了不同状态码类别的占比。例如定义规则计算每分钟 2xx、4xx、5xx 的次数，存为 api:2xx_ratio 等指标，便于在可视化界面上直接展示饼图或堆积图来反映错误构成。

通过合理设计这些 Recording Rules，新架构将分散的原始数据转化为凝练的服务健康指标，并以统一命名规范存储。例如以 api: 前缀标识接口级指标，以 service: 前缀标识服务级汇总指标。这些规范在 Flashcat 平台的模板中得到应用，自动生成对应卡片和阈值。通过 Recording Rules 预计算 RED 指标不仅用于告警，也直接支撑了上层产品对服务可用性的量化展示。

高可用性与水平扩展

在实现高实时性、高吞吐数据处理时，系统的可扩展性至关重要。星巴克中国技术团队在新架构中采用了“平行消费 + 哈希分片”策略：每个 Vector 实例都并行消费 Kafka 中所有分区，保证消费负载均衡，而不是按业务预先拆分日志流。消费到的所有日志事件均进入 Transform 流，统一进行解析和 log_to_metric 转换。

为了让同一域名或服务的指标最终由同一个 Prometheus 实例采集，Vector 给每条事件打上.tags.shard标签：

inputs:  - "external_kong_log_to_metric"  - "internal_kong_log_to_metric"source: |  .tags.shard = if exists(.tags.domain) {      to_string(abs(mod(seahash(.tags.domain), 5)))  } else if exists(.tags.service) {      to_string(abs(mod(seahash(.tags.service), 5)))  } else {      "0"  # 提供默认值  }

优先按域名分片, 只要日志含 domain 字段，就使用 seahash(domain)%5 计算出的数值作为 shard，部分内部业务日志没有域名，则采用回退策略，依次尝试 service、ip 字段，以此类推，确保每条日志都有一个分片标签；

至于分区数可配置，示例中取模 5，可根据 Prometheus 实例数量修改。如果 Prometheus 能力不足，平行扩容后这里修改为对应的数字即可。

这样以来，相同域名 / 服务的指标总落在同一个 shard 上，实现了跨实例数据一致性；而所有 Vector 对所有日志平行消费，又保证了整体的负载均衡与弹性扩容能力。在 Prometheus 端，只需根据 shard 标签将对应 Vector 输出划分到相应抓取 Job，最终用户侧查询或告警时，无需感知底层有多少实例在并行支撑，可透明地获得聚合后的一致指标。

遵循奥卡姆剃刀“如非必要，勿增实体”的原则，通过 seahash 保持跨实例数据一致性的同时，避免了引入 Prometheus 联邦集群的架构，降低运维复杂度的同时大幅降低成本。

其他注意事项

高基数（High Cardinality）

控制指标标签基数：Prometheus 中每一个唯一的标签集合（labelset）都对应一条独立的时间序列。也就是说，如果同一指标的某个标签值变化，该组合就会被视为新的时间序列，从而成倍增加存储数据量。高基数标签会导致 Prometheus Series 数量爆炸，带来查询变慢、存储开销巨大等问题。

应尽量精简指标的标签维度，只保留必要的核心业务标签（如服务名、接口名、部署区域等），避免使用高离散度的动态字段作为标签。避免使用动态字段作为标签：常见的高基数字段包括用户相关的唯一值或随机值，例如：完整的 URL 请求路径、用户 ID、请求的 Trace ID 等。这类字段每次请求可能都有不同取值，不适合作为指标标签。

但因为历史原因，星巴克日志中大量存在动态 ID 的 API，通过定义 API 前缀的方式，如果匹配到，就会按照前缀来计算，如示例中 /wechatcouponcallback/00001 和 /wechatcouponcallback/00002 就会被合并到 /wechatcouponcallback 的指标当中。得益于 Vector 的高性能，即使有上百个 patterns，CPU 增加非常有限。

type: remapinputs:  - parse_external_kong_trace_messagesource: |  # 定义URI前缀映射表  uri_patterns = {    "/app-bff-api/default/dynamic-ui": true,    "/app-bff-api/auth/stardash": true,    "/app-provision-api/default/app-config": true,    "/wechatcouponcallback": true,  }

Histogram 桶边界（Buckets）

直方图（Histogram）桶的设计需基于业务响应时延分布来平衡精度与存储开销。常见做法是覆盖快速返回和长尾延时两个区间，例如：

• 核心区间：50ms、100ms、200ms、500ms、1000ms

• 尾部区间：3000ms、5000ms、10000ms

• 每个直方图会生成le桶、_count、_sum三类序列，总序列数约为桶数 +2。

桶的边界值应结合真实数据分布进行调整，以兼顾监控精度和开销。原则上，数据密集的区间使用更细的桶划分，数据稀疏处则可拉大桶间距，从而使各桶内样本数大致均衡、接近“阶梯状”分布。大多数延时 / 大小等指标往往具有长尾分布，适合采用对数 / 指数形式递增的桶值。

如默认桶配置{0.005,0.01,0.025,0.05,…10}就是指数增长间隔。实际调优时，可以先用默认或倍增桶观察数据分布，再据此微调桶边界。特别地，如果关注特定高分位（如 P95/P99）的精度，可在靠近该分位数的区域设置更密集的桶，例如某服务 99% 请求延迟在 200ms 左右，则可在 150ms～250ms 范围内加密桶间隔。通过不断根据历史数据分布调整桶设计，确保关键分位数计算具有足够的分辨率和准确性。

指标清理周期（flush_period_secs）

Vector 的 flush_period_secs`并非聚合周期，而是对未活跃指标的清理窗口。当 Vector 的 Prometheus Exporter 在一个 flush_period_secs 时间窗口内没有接收到某个指标的任何新样本，就会认为该指标已经过期，并从 /metrics 接口中移除。就可能会存在问题：

如果把 flush_period_secs 配置为 120s：

第 1 分钟内，某 counter 类型指标累计到 100；

第 2、3 分钟都没有任何新样本，该指标在第 1 分钟结束后 120s 过期，被 Vector 清理掉；

第 4 分钟又出现新样本，这时该指标会被重新创建，值直接变成 150。

假设 Prometheus 用 rate(my_counter[5m]) 或 rate(my_counter[2m]) 来计算速率：

在数据点缺失的 2~3 分钟期间，Prometheus 视该序列不存在或重置，rate 计算只会基于两端剩余的点，导致结果远高于真实速率或不连续。

为避免上述假重置导致的误高峰问题，需确保 flush_period_secs>大于 Prometheus 的 scrape_interval，同时在 Recording Rules 中做兼容，如果 rate 得到的值为 NaN，则取当前值作为 Recording Rules 的结果。

可观测性落地效果

架构改造后，星巴克中国的可观测性平台响应速度大大提升，原来 SRE 打开一个监控面板，因为指标都要到 ElasticSearch 实时聚合，需要几十秒甚至 1-2 分钟，现在毫秒级别即可打开。

同时因为数据直接从 Kafka 消费，不再经过 ElasticSearch，所以 ElasticSearch 本身不再大量查询压力的同时，ElasticSearch 的稳定性状况也不再影响告警的准确性。在 Flashcat 提供的统一界面上，SRE 能够全局掌握系统健康状况，并快速深入到问题根源。以下从展示效果和运维效率两个方面总结落地成果：业务域健康概览（Flashcat 灭火图）：如上图所示，星巴克将整体系统按业务域划分为“业务运营域”、“交易域”、“平台域”、“用户运营域”、“稳定性平台”等几大板块，每个板块下包含若干业务系统或服务。

图三不同业务域汇总灭火图

如上图所示，Flashcat 灭火图用卡片代表各个观测对象（接口或服务），通过颜色和分数直观标识健康状态。图中各域的总览卡片均显示为 100 分绿色，表示最近周期内核心指标正常，没有出现异常飘红。同时每个域下方注明了包含的接口数（卡片数量）和分组数（通常对应微服务数量）。结构化的视图极大地方便了日常巡检：运维人员打开灭火图首页，就能一眼看到哪个业务域、哪个系统出现故障，无需在繁杂的监控面板中手动寻找。

接口级指标下钻

点击某个业务域，Flashcat 会下钻展示该域内各系统的健康详情；进一步选择具体系统或接口，则进入如上图所示的接口监控面板。

图中展示的是一个具体接口 /api/external/account/query 的实时指标：包括成功率、请求数、平均延迟等核心指标的当日、当周、当月、当季统计，以及下方详细的时间序列图表。例如“请求量”折线图、“成功率 %”曲线、“P99 延迟”柱状图、“5xx 次数”区域图等，一应俱全。

左下角的标签显示了该接口的多维度属性：所属业务系统（BizOps Portal）、域名、Kubernetes 部署与服务名、业务域等。这些标签均来自于前文通过 Enrichment Table 和日志解析添加的维度。从这些标签和图表，运维可以判断：该接口属于“业务运营域”的 BizOps 门户，部署在生产 K8s 集群的 api-gateway 模块。当前成功率 100%，无 5xx 错误，P99 延迟在较低水平。

指标与日志 /Traces 联动

更进一步，当某接口指标出现异常（例如成功率下降为 80%），运维人员可以点击界面提供的“关联分析”入口，直接查看与该接口相关的日志、链路追踪等信息。Flashcat 将不同观测数据源关联起来。

例如：调用日志（通过接口名或与 Opentelemetry trace-id 关联）、上游下游接口的拓扑关系、最近代码变更事件等。这种联动极大加速了故障诊断过程——过去需要在监控、日志、APM 三套系统之间来回切换，如今在一处界面就能串联完成指标异常 ->日志定位 ->调用链分析 ->根因确认的闭环。当某次事故发生时，这套工具如同一个智能助手，帮助 SRE 团队在最短时间内找到问题所在。

告警精准度提升与延迟降低

新的指标体系让告警条件设计更加科学，减少了误报漏报。以往基于日志关键字的告警往往受限于 ElasticSearch 性能，可能存在误告警，而且不能如果查询聚合语句过于复杂，ElasticSearch 往往超时。

而现在 Recording Rules 提供实时的聚合数据，支持毫秒级别展示的同时，也支持更复杂的多条件告警。此外，由于监控延迟降低到秒级，故障发现平均时间（MTTD）显著缩短，相应地恢复时间（MTTR）也减少了。

历史分析与容量规划

借助 VictoriaMetrics 长期存储，团队能够方便地分析历史趋势。例如比较今年“双十一”大促期间的流量峰值与往年同期，通过指标同比增长率来指导容量扩容计划；又如查看某接口延迟在过去半年逐渐升高的趋势，提前感知性能隐患。

以往在 ES 中做这类趋势分析非常困难（需要查询多个历史索引并离线统计），现在几秒钟即可在 Grafana 或 Flashcat 界面绘制半年曲线并导出报告。这使得可观测性平台不仅服务于运维保障，也为业务决策提供了数据支撑。

综合来看，新可观测性系统在星巴克中国落地后，实现了“全局概览、一键下钻、数据联动”的卓越效果，极大提升了运维响应效率和系统稳定性。

对比业界方案：Flink

业界在分析日志并生成实时指标方面，常见方案是引入流处理引擎，如 Apache Flink。相比于本次星巴克采用的 Vector+Prometheus 方案，Flink 流计算具有不同的特点和适用场景。

Apache Flink 的优势

Flink 是分布式流处理领域的佼佼者，具备高吞吐、低延迟的强大能力。它可以实时从 Kafka 等源读取数据，执行复杂计算逻辑，然后将结果输出到数据库或监控系统。

Flink 的核心优势在于精确的状态管理和窗口计算，能够在保证 Exactly-Once 语义的同时，对无界数据流进行开窗聚合、joins 等复杂操作。针对 RED 指标场景，Flink 完全可以实现类似功能：例如每隔 5 秒计算各接口过去 1 分钟的请求数和错误率，甚至可以直接在流上做百分位估算，生成监控所需的指标事件。

此外，Flink 可编写复杂的业务规则，比如检测到错误率突增时直接输出告警事件，而不仅仅是指标。这些能力是纯配置型工具所难以做到的。因此，在一些对计算逻辑要求极高的场合（比如日志中复杂模式的关联分析、跨流的关联计算），Flink 提供了更高的灵活性。

引入 Flink 的代价也不容忽视

开发和维护成本高，使用 Flink 需要开发人员编写流处理作业（使用 Java/Scala 等），这增加了项目的代码量和复杂度，相比配置化的 Vector 管道需要更多专业技能。开发完毕后，Flink 作业本身也需要部署和运维——维护一个 Flink 集群（或使用云服务）远比维护几台 Vector/Prometheus 复杂，需要考虑 JobManager/TaskManager 的高可用、资源调度、状态 checkpoint 等众多因素。

其次是资源开销相对较大。Flink 为了保障低延迟和状态可靠，往往需要长期占用一定的 CPU 和内存资源来跑作业，而 Vector 轻量级进程对系统资源要求较低。同等规模下，实现类似功能 Flink 可能需要数倍的资源投入。

再次，在响应速度上，Flink 虽然理论上可以做到毫秒级处理，但在实际监控应用中往往也会设置秒级的窗口来平滑数据，因此与 Prometheus 方案在监控颗粒度上差距不大。

星巴克方案的优势

选择 Vector+Prometheus，最大限度地利用了开源生态中成熟可靠的组件，减少了自行开发。Vector 的使用让团队无需从零编写流处理代码，只需编写配置和少量 VRL 脚本，上线速度快且配置变更方便。

Enrichment Table 功能的引入，也实现了类似 Flink 广播流的功能，让 Metrics 与旁路元数据紧密结合。

从成本角度考虑，Vector+Prometheus+VictoriaMetrics 方案主要消耗的是少数中间节点和一些存储空间，相比运行一个大规模实时计算集群，硬件和运营成本更低。需要说明的是，Flink 并非不适合做监控分析。在某些更大规模、复杂关联计算的监控场景，Flink 的流批一体能力和扩展性会有用武之地。但就星巴克中国目前的需求和规模来看，Vector 方案已经很好地满足了实时 RED 指标和日志监控需要，尚无必要引入更重型的流处理框架。

总的来说，星巴克中国在可观测性建设中选择了一条快速见效、平滑演进的道路：以较小代价换取了显著的监控能力提升。这一决策体现了架构师在“自行开发复杂系统”和“组合现有优秀组件”之间的权衡取舍。事实证明，对于大多数典型 Web 业务场景，通过恰当的开源工具组合，完全可以搭建起低延迟、高性能的监控体系，而不一定非要诉诸大数据平台的重炮。

对比业界方案：Arroyo

Arroyo 是什么

Arroyo 是一款用 Rust 编写的分布式流式处理引擎，主打“用 SQL 写实时计算”，支持在数据流上做过滤、聚合、窗口计算、连接（join），强调亚秒级结果和从零到百万级每秒吞吐的弹性伸缩，定位为“云原生、无需专门运维团队”的流处理平台。官方同时提供开源自建与托管形态。

Arroyo 将 Streaming SQL 编译为分布式数据流 DAG；作业状态通过基于 Chandy–Lamport 的快照变体实现一致性检查点，便于容错与快速扩缩容 / 升级，支持在 Kafka 等流源上构建实时管道

能力侧重点

Arroyo 更像通用版的 Flink，定位是实时计算平台，适合在流上做复杂、有状态的逻辑（窗口统计、跨流 join、模式匹配、富算子链路），并把结果写入多种外部存储 / 主题；用 SQL 降低开发门槛，追求“亚秒级”端到端时延。而 Vector 完全聚焦可观测数据管道，核心是采集 / 转换 / 路由可观测性数据（日志、指标、追踪），用 VRL 做轻量变换 / 富化，并通过 Prometheus exporter 暴露指标，交给 TSDB 做聚合与告警。它不是通用流计算引擎，而是“把日志就地指标化”的高性能代理。

开发与运维成本

在“日志→指标”的观测场景里，Vector 更偏配置驱动：通过 VRL/transform 做轻量解析与富化，prometheus_exporter 直接对外暴露指标，落地通常只需接入既有的 Prometheus/Grafana/ 告警链路，工程面聚焦在规则与标签治理即可，整体开发与运维成本较低、变更也更敏捷。Arroyo 属于通用流式计算引擎，优势在于用 Streaming SQL 描述窗口、会话、Join 等有状态计算，但这也引入了作业拓扑、状态与检查点、扩缩容、回压与升级等运维课题；即便其提供“单一二进制、K8s 部署”的便捷起步形态，本质仍是需要专门运维与容量治理的“计算面”。因此，若主要诉求是 RED 指标、关键字计数与简单维度富化，Vector 的链路更短、上线更快；若需要跨流 Join/ 复杂窗口 / 强状态语义，再考虑以 Arroyo 承载计算面更合适。

生态成熟度

Vector 源自 Timber，已在 2021 年被 Datadog 收购并持续投入，成为 Datadog Observability Pipelines 的开源内核之一，长期产品化与大规模生产验证使其在稳定性、集成面与社区资源上更成熟、风险更可控。Arroyo 则在 2023 年开源并快速迭代，聚焦 Rust 架构与 Streaming SQL 易用性，虽然增长迅速，但相较于以观测数据管道为核心、背靠大型商业厂商的 Vector，仍处在生态与企业级最佳实践积累的早期阶段，选型时通常需要更充分的 PoC 与风控评估。

我们的取舍

在当前“日志→指标”的观测诉求下（RED 指标、关键字计数、结合 CMDB 的轻量富化），我们优先选择 Vector+Prometheus 作为基座：Vector 的 VRL 以配置驱动完成就地指标化，链路短、上线快、与既有 Prometheus/Grafana/ 告警体系天然对齐，整体成本与演进阻力更低。

而 Arroyo 以 Streaming SQL 提供有状态流处理能力，定位清晰但仍在生态与企业级最佳实践积累阶段（虽近年有云厂商推动也尚属成长期），综合运维复杂度与团队经验门槛，短期内不作为我们的主干路径，待需求升级到“强状态 + 复杂算子”再纳入评估与 PoC。

架构优化点

遇到哪些问题

为快速上线我们采用 Prometheus+Recording Rules。在实际运行中暴露出一些问题，如：

• 稀疏与首点问题：一些 API 的错误 / 低频调用一天仅数次，而且错误信息相当重要，rate()/increase() 在“窗口内只有 1 个样本或新序列首样本”场景易给出 0/NaN，可能漏掉关键一次，导致告警不准确。

• 采集端资源高：因为要兼容稀疏与首点问题，Prometheus 需维护大量实例级时序与规则状态（如 rate(metricA[5m])or metricA），内存 /CPU/WAL 压力偏高，扩容 / 稳定性受限。

• 存储与查询放大：若长留实例级 / 原始序列到 VM，基数与扫描面放大，查询抖动与成本上升。

架构与方案（与现有的不同 & 数据流）

基于上述，可以优化现有方案，降低成本和提高稳定性。主要阐述与现有不同（Prometheus+Recording Rules）。由于思维定势，计数类数据，习惯使用 counter 类型，而由于 vector 的特性，完全可以按照分钟聚合成 gauge 类型。

• 计算前移：不再依赖读侧 rate/increase；由 Vector 在写入前直接产出“分钟产物”（requests_1m、errors_1m、request_duration_ms_bucket_1m），均为 gauge 类型。

• 写入侧聚合：gauge 类型要求实时抓取，不能遗漏，所以不再使用 scrape 的方式，而是使用 remote write 写入 vmaget，随后 vmagent 使用 streaming aggregation 跨实例合并 sum without(domain,endpoint) 聚合成最终指标。

• 轻读侧：Grafana/flashcat 直接用分钟产物；分位数对“分钟桶”做 5m 窗口后再 histogram_quantile，无需导数；

AIOPS 展望

在完善业务 Metrics 指标之后，以现有分钟级 RED、直方图桶、日志与链路数据为底座，先做 AI-Ready 数据治理：统一采集与语义（优先 OpenTelemetry）、标签标准化与路径归一、数据源权限与按需查询打通、字段级脱敏与审计；在此之上构建企业级系统本体 / 知识图谱（服务 / 接口 / 组件 / 依赖 /SLO/ 运行状态为“对象”，指标 / 日志 / 链路为对象属性），并联通变更、发布、容量等外部事实。知识层面用 Graph+ 向量索引承载结构化拓扑与非结构化文档 /Runbook，形成可被 LLM 调用的统一“可观测语义空间”。这一路径满足“AI 能理解系统 / 能查询数据 / 具备业务知识”的三大前提，是智能分析的必要建设。

如告警触发后，先做时间序列突变 / 基线检测与同环比归因，随后按知识图谱依赖扩张收集证据（同分钟窗口的关键指标、相关日志片段、上下游 Trace、变更事件）；以 GraphRAG 将“图邻域”与“文本知识”联合检索喂给 LLM，产出假设→证据打分→根因排序，并给出影响面 / 回滚与 SOP 步骤；结论与动作写回图谱与工单，实现人机协作 + 自动化修复的闭环，并用 MTTA/MTTR、误报率与覆盖率持续评估与学习迭代。该组合在不新增数据搬运的前提下最大化复用现有管线，实操上即可从 L1/L2 快速演进到 L3/L4 的系统级智能分析与推理。

门店侧统一采集与治理先行——在每家门店的网关 / 边缘主机部署 OTel/Vector，按分钟生成“结果值”（门店级 requests_1m/errors_1m/duration_bucket_1m），标准化标签（store_id/region/channel=device|pos|mobile|kiosk 等），离线可缓冲、在线 remote_write 到区域 vmagent→中央 VM 或者直接使用边缘告警组件；以“下单 / 支付 / 取餐 / 会员”四类业务链路设 SLO 与看板。

总    结

在本次可观测性系统升级中，星巴克中国可观测性团队成功地将传统的日志监控模式转变为以指标驱动的现代观测体系。通过引入 Vector 日志管道和 Prometheus 以及 VictoriaMetrics 时序数据库，实现了对数千接口的实时请求指标监测，构建了覆盖请求、错误、延时的黄金指标体系。

新平台在星巴克中国生产环境大规模落地：目前监控覆盖了约五个业务域、数十个关键业务系统、数千个 API 接口，VictoriaMetrics 管理的时间序列超过五万条，日均处理日志数亿行，生成指标数据数千万点。如此规模的监控数据仍能保持秒级更新和查询，证明了方案设计的高效合理。

新系统带来的价值是多方面的，更快的故障发现和精确的告警使运维团队能够将事故平均恢复时间降低了 30% 以上。多个重大活动期间（例如新品促销、会员日等），灭火图帮助团队及时发现潜在隐患，在用户无感知的情况下排除故障，确保了业务连续性。

同时运维人员从繁琐低效的日志检索中解放出来，将精力集中在指标分析和问题诊断上。一站式的观测平台减少了跨系统排查的时间。日常问题定位效率大大提升。研发团队也开始使用这些指标来评估功能发布影响、优化性能瓶颈，DevOps 协作更加顺畅。

实践表明，在追求高性能、高实时的监控目标时，巧用新兴工具、优化架构往往比一味叠加“大而全”框架更有效。通过在日志和指标之间架起桥梁，星巴克实现了对复杂系统运行状态的全面透视。在未来的发展中，这套系统还将持续迭代，融入更多智能化手段，助力星巴克在数字化道路上行稳致远。相信这一实践经验也能为更多企业的 SRE 和架构师提供借鉴，使大家共同迈向更加可观、可控、智能化的运维新时代。