从工作负载边界开始
优先选择稳定的服务、工作负载、队列和路由名称，而不是临时 Pod ID、原始资源路径或提供程序有效负载。
选择框架
选择知道结果的边界
将资源压力与需求配对
CPU、内存、重新启动、滞后和限制需要请求或作业量加上释放上下文，然后才能支持容量决策。
保留专家信号
使用基础设施、跟踪和提供者系统来获取其本机详细信息。将选定的应用程序结果发送到 Telemetry 以进行 SQL 分析和客户影响。
共享事件合约
保持第一个模式可互操作
- 服务、区域、环境、版本、状态和 duration_ms
- 提供者、运行时、工作负载、队列、依赖项和受控 error_type
- 请求量、资源饱和度、重试次数和客户影响字段
使这些字段适应工作流程，但在多个服务依赖同一个表之前保持单位、状态类别、标识符和所有权明确。
验证
在发出警报之前练习故障路径
- 1实施一种健康的部署和一种受控的提供程序或工作负载故障。
- 2确认区域、版本、服务和运行时维度保持有限。
- 3测试重试和超时行为，而不会出现递归遥测失败。
- 4将基础设施变化与请求、工作或产品结果进行比较。
实施指南
匹配框架、提供程序或运行时
来源实施指南
Cloudflare 工作人员 Telemetry
记录边缘请求状态、延迟、提供商故障、cron 运行以及来自 Cloudflare Workers 的队列工作人员。
打开指南来源实施指南
AWS Lambda 结构化事件监控
通过紧凑的结构化事件跟踪 Lambda 调用、冷启动、持续时间、重试和业务成果。
打开指南来源实施指南
AWS ECS 和 Fargate Telemetry 集成
使用本地任务元数据端点将 ECS 任务系列、修订、可用区和发布上下文添加到应用程序结果。
打开指南来源实施指南
AWS SQS 队列可观测性
跟踪 SQS 消息期限、接收尝试、处理结果、批处理行为和死信路由，而无需存储消息正文。
打开指南来源实施指南
谷歌云运行 Telemetry
使用应用程序拥有的结构化事件跟踪 Cloud Run 请求和作业结果、冷启动上下文、实例并发性、重试、延迟和发布。
打开指南来源实施指南
Google Cloud Pub/Sub 与 Telemetry 集成
使用稳定的消息标识符跟踪 Pub/Sub 发布、交付、确认、重新交付、排序、队列寿命和死信结果。
打开指南来源实施指南
Azure 函数 Telemetry
通过调用、重试、延迟、发布和客户影响上下文跟踪 Azure Functions HTTP、计时器、队列和事件触发结果。
打开指南来源实施指南
Azure 服务总线 Telemetry
跟踪 Azure 服务总线发送、接收、锁定续订、结算、重新传递、延迟和死信结果，而无需收集消息正文。
打开指南来源实施指南
Kafka 消费者延迟和处理分析
使用结构化事件监控 Kafka 消费者结果、分区延迟、处理延迟、重试和有害消息处理。
打开指南来源实施指南
Kubernetes 工作负载 Telemetry
将有界 Kubernetes 重启、准备情况和部署观察结果发送到 Telemetry 以进行工作负载级 SQL 分析。
打开指南来源实施指南
亚马逊基岩型号 Telemetry
通过模型或推理配置文件、令牌使用情况、延迟、停止原因、重试和业务成果来衡量 Bedrock Converse 请求。
打开指南来源实施指南
Azure OpenAI 响应 Telemetry
通过可编辑的 SQL 就绪事件跟踪 Azure OpenAI 部署使用情况、令牌成本、延迟、故障和产品结果。
打开指南来源实施指南
谷歌双子座 API Telemetry
跟踪 Gemini 请求延迟、模型使用情况、令牌、完成原因、错误和审查的产品结果，而无需存储提示或生成的内容。
打开指南来源实施指南
OpenTelemetry 结构化事件中的上下文
通过在工作流边界记录安全跟踪和跨度标识符，将 Telemetry 业务事件连接到现有 OpenTelemetry 跟踪。
打开指南首先验证一个端到端工作流程
创建一个免费的 API 密钥，选择最接近的运行时指南，并在扩大覆盖范围之前发送已知的成功和失败信息。