将原始诊断保存在他们的专业系统中
不要镜像每个日志行或跨度。当请求、作业或工作流达到值得使用 SQL 进行分析的结果时，发送一个有界事件。
选择框架
选择知道结果的边界
无需复制有效负载即可关联
使用批准的跟踪或请求标识符在系统之间进行转换，同时排除堆栈跟踪、日志消息、跨度属性和客户内容。
在应用程序边界标准化
在事件到达分析表之前，将记录器级别和异常转换为受控结果和错误类别。
共享事件合约
保持第一个模式可互操作
- event_name、服务、环境、版本、状态和 duration_ms
- 批准的 trace_id、request_id、account_id 和受控的 error_type
- 操作、依赖、retry_count、终端业务成果
使这些字段适应工作流程，但在多个服务依赖同一个表之前保持单位、状态类别、标识符和所有权明确。
验证
在发出警报之前练习故障路径
- 1使用批准的标识符将一个事件与其原始日志或跟踪进行比较。
- 2确认异常不会复制堆栈文本、参数或凭据。
- 3检查一个逻辑结果不会成为每个日志行或跨度的一个事件。
- 4按服务和版本查询结果和错误趋势。
实施指南
匹配框架、提供程序或运行时
来源实施指南
皮诺结构化事件分析
将 Pino 诊断日志与有界 Telemetry 结果事件配对，以进行 Node.js 请求、作业和产品可靠性分析。
打开指南来源实施指南
温斯顿结构化事件分析
将 Winston 应用程序诊断连接到小型 SQL 就绪请求、工作流和作业结果，而无需复制整个日志流。
打开指南来源实施指南
OpenTelemetry 结构化事件中的上下文
通过在工作流边界记录安全跟踪和跨度标识符，将 Telemetry 业务事件连接到现有 OpenTelemetry 跟踪。
打开指南来源实施指南
.NET 和 Serilog 结构化事件分析
除了针对 ASP.NET 请求延迟、故障、版本和客户影响的 Serilog 诊断之外，添加重点 Telemetry 结果事件。
打开指南来源实施指南
Spring Boot 结构化事件监控
通过 Telemetry 的 HTTP API 记录 Spring MVC 和预定工作流结果，并提供稳定的路由、延迟、状态和跟踪上下文。
打开指南首先验证一个端到端工作流程
创建一个免费的 API 密钥，选择最接近的运行时指南，并在扩大覆盖范围之前发送已知的成功和失败信息。