Elastic 中的 Temporal Cloud 可观测性：50+ 个指标，无需采集器

作者：来自 Elastic Ishleen Kaur

Elastic 抓取 metrics.temporal.io 的指标，因此，一个已经卡在 Running 状态一小时的工作流，最终发现是一个没有任何轮询的任务队列，而你无需打开任何一个 worker 日志，就能发现这一点。

Elastic 原生支持 OpenTelemetry。通过 OTLP 将 traces、logs 和 metrics 直接发送到 Elasticsearch，无需使用专有 agent。查看它们如何协同工作，在 cloud 中免费试用，或者在本地运行。

Temporal 云在 Elastic 中的可观测性只需要一个 API key，无需其他配置。Elastic 自行抓取 metrics.temporal.io，因此你的 worker 上无需运行 agent，也无需考虑 collector 的规模配置。Temporal OpenTelemetry Integration 会引入超过 50 个 OpenMetrics series，并且数据进入数据流后，一个 dashboard、7 个告警模板和 3 个 SLO 模板会自动安装。Elastic 也被列在 Temporal 自己的可观测性集成页面上。

一个 Temporal 工作流可能长时间处于 Running 状态，但仍然处于卡住状态。也许本应该轮询其任务队列的 worker 已经消失。或者 namespace 正在消耗其 action 预算，或者某个 activity 在 StartToClose 阶段超时，而 frontend 延迟图表看起来仍然正常。你运行 worker，Temporal 运行服务，而故障通常就发生在两者之间的间隙中。只有当 Cloud 指标数据源位于一个可以与你技术栈的其他部分一起进行查询的位置时，你才能发现这一点。

Elastic 会收集哪些 Temporal Cloud 指标？

Temporal Cloud 发布超过 50 个 OpenMetrics series，并以一分钟为窗口进行聚合。每次抓取只会返回最近一个已完成分钟的数据，因此 Elastic 必须保存历史记录。指标名称保持 Temporal 发布时的名称，在 metrics-temporal.cloud_metrics.otel-* 下使用 metrics.*。

有用的划分方式并不是"基础设施 vs 应用程序"。而是：

如果你想了解	从这里开始
工作流是否正在完成？	成功、失败和超时计数，以及 schedule-to-close 延迟
activity 是否在 worker 上失败？	activity 失败率和超时率，包括 heartbeat 与 StartToClose
工作是否正在空闲 worker 集群中等待？	`no_poller_tasks_count`、poll 成功率与 poll 超时率、backlog 大小
Cloud frontend 本身是否缓慢？	按 operation 划分的 service request 数量、错误数量和 p99 延迟
是否即将受到限流？	action、operation 和 poller 限制与消耗量
多区域 namespace 是否正在发生偏移？	replication lag 百分位数

完整的指标目录位于 Temporal 的指标参考中。该集成不会对这些名称进行重命名。

如何将 Temporal Cloud 指标连接到 Elastic

在 Temporal Cloud 中，进入 Settings → Service Accounts ，创建一个具有 Metrics Read-Only 角色的 Service Account。
为该账户生成 API key 并保存。它只会显示一次。
确认 endpoint 可以正常响应。你应该看到 # TYPE temporal_cloud_v1_... 行，而不是浏览器页面。不带 bearer token 打开该 URL 会返回 Jwt is missing。

bash 复制代码

`curl -H "Authorization: Bearer <API_KEY>" https://metrics.temporal.io/v1/metrics`AI写代码

在 Kibana 中，进入 Management → Integrations ，搜索 Temporal (OpenTelemetry)，然后添加它。
将 endpoint 保持为 metrics.temporal.io:443，将路径保持为 /v1/metrics。
粘贴 API key。

在 Discover 中使用 data_stream.dataset: "temporal.cloud_metrics.otel" 进行验证。第一批文档会在第一个已完成的一分钟窗口结束后的几分钟内出现。当这些数据进入 metrics-temporal.cloud_metrics.otel-* 后，Temporal OpenTelemetry Assets 软件包会自动安装 dashboard、告警模板和 SLO 模板。你无需手动添加这些内容。

如需查看字段级别的详细信息，请使用 Temporal OpenTelemetry Integration 文档。

Temporal Cloud Metrics dashboard 展示了什么

Assets 软件包会安装一个 dashboard： $Temporal OTel$ Cloud Metrics。它是一个黄金信号面板，而不是包含 4 个产品领域标签页的 dashboard。

Temporal Cloud frontend 能跟得上吗？

概览和延迟图块会按 namespace 和 operation 显示请求量和 p99。这里出现的峰值会影响每个 StartWorkflow、Signal 和 poll，而不仅仅是某一个任务队列。

工作流是在完成还是超时？

错误视图会将工作流和 activity 的终止状态分为成功、失败和超时。工作流超时意味着执行过程耗尽了允许的实际时间。Activity StartToClose 超时意味着 worker 超出了其尝试次数预算。Heartbeat 超时通常意味着进程在运行过程中途退出。

是 worker 不够了，还是 action 配额用完了？

饱和度和容量涵盖积压深度、poller 是否存在、开放工作流数量以及 action-limit 余量。一个有任务但没有任何 poller 的队列，与一个已经使用了 80% action 限制的 namespace，是两种不同的故障事件。在工作流开始超时之前，这两种情况都会在这里显示。

Temporal Cloud 告警模板以及每条规则捕获的问题

Assets 软件包为 Temporal Cloud 实际发生故障的各种方式提供规则模板。按照故障原因进行分组，比按照指标前缀进行分组更加实用。

Worker 和任务队列告警

任务队列中没有 poller： 任务正在被分发，但没有人监听。该队列的新任务会立即卡住。
任务队列积压不断增长： 任务到达速度快于认领速度。如果不处理，最终会导致工作流超时。
Activity 任务超时率升高： StartToClose 与 heartbeat 可以帮助你区分缓慢的依赖项和崩溃的 worker。
Activity 任务失败率高： 重试次数正在不断消耗。持续的高失败率会耗尽重试预算，并导致工作流失败。

Namespace 容量告警

Namespace 接近 action 速率限制： 达到已配置 action 数量的 80%。超过限制后，Temporal Cloud 会对新事件进行限流。
开放工作流数量异常： 执行中的工作流数量不断增加，但吞吐量没有相应增长。某些任务没有完成。

工作流超时告警

工作流超时率升高： 执行过程触发了 workflowExecutionTimeout。这是时间问题，而不是重试问题。

三个 Temporal Cloud SLO 模板及其阈值

这三个模板都使用滚动 30 天窗口。

服务延迟 p99 低于 100ms，99%： Cloud frontend 保持足够快的速度，不会让 Start、Signal 和 poll 变慢。按照 namespace 和 operation 分组。
任务队列积压低于阈值，99%： 每个 namespace 和队列中，每个 5 分钟时间片内的待处理任务保持在 1,000 个以下。
工作流成功率 99.5%： 大多数一分钟时间片内，成功完成数保持在终止结果（成功、失败、超时）的 95% 以上，按照 namespace 划分。

在将这些数字视为正式的服务约定之前，请根据你自己的流量调整积压和成功率数值。

开始在 Elastic 中使用 Temporal Cloud 可观测性

如果你使用 Temporal Cloud，并且已经在使用 Elastic Cloud，那么你今天就可以开始使用。Elastic 会为你抓取 Temporal Cloud 的 OpenMetrics endpoint。你的 worker 上无需运行 agent，也无需运行 collector。

该集成要求使用 Elastic 9.5 或更高版本，可运行于 Elastic Cloud Serverless 或 Elastic Cloud Hosted。创建 Metrics Read-Only key，然后在 Kibana 中通过 Management → Integrations 添加 Temporal (OpenTelemetry) ，或者按照 Temporal OpenTelemetry Integration 文档进行操作。

原文：Temporal Cloud observability: 50+ metrics, no collector | Elastic Observability Labs