“Telemetry 是我转储日志和跟踪事件的首选。它很简单，SQL 工作台速度很快，而且我不必预先担心架构。通过 REST API 运行 SQL，我可以获取数据并将报告直接转储到 Slack。这是 Sentry 为我所做的事情的本质。”
Prem Viswanathan
创始人， SwiftCX确认的背景
此页面将已发布的反馈与其他团队可以应用的一般模式分开。
- Prem Viswanathan 是 SwiftCX 的创始人。
- 他发布的反馈特别提到了日志、跟踪事件、SQL 工作台、灵活的模式、REST 查询 API 以及交付给 Slack 的报告。
- 该声明描述了工作流程的适合性，而不是基准或保证的性能结果。
可重复的图案
具有相同需求的团队如何开始
1
使用单一事件路径进行调查和报告
具有类似需求的团队可以记录一次操作事件，以交互方式检查它们，并通过 API 重复使用已审核的 SQL 来生成计划报告。
2
让模式有意识地发展
在没有严格的前期仓库模型的情况下开始并不意味着忽略类型。发送测试事件，检查推断的架构，并在添加新上下文时保持现有字段类型稳定。
3
自动化审核的查询
一旦查询回答了正确的问题，就可以异步或按计划调用它，并在团队已经工作的地方提供紧凑的结果。将保存的 SQL 保留为可审计源。
评估蓝图
将工作流程变成您可以验证的证据
以下示例是从已发布的工作流程中得出的实用评估计划。它们不是关于客户的实施、事件模式或结果的声明。
1
问题和活动合同
一个事件路径可以支持调查和报告吗？
operation_completed 具有操作、状态、duration_ms、发布、环境和安全相关字段
验证检查
比较相同固定时间窗口和参数的交互式 SQL 和查询 API 输出。
2
问题和活动合同
事件模式能否在不破坏已保存报告的情况下发展？
添加可选的类型化上下文，同时保持现有字段名称和类型的稳定；记录schema_version
验证检查
重播旧的和新的合成事件，检查 null 行为，并在两个版本上运行现有的报告查询。
3
问题和活动合同
自动报告是否可追溯？
保留保存的查询标识符、报告窗口、generated_at 时间、行数和传送状态
验证检查
在依赖计划交付之前，手动重新运行相同的查询并比较紧凑的结果。
此工作流的 SQL 查询示例
相关产品功能
继续此工作流程 告警
将经过审查的可靠性查询提升到拥有的阈值和响应工作流程中。
尝试相同的事件到答案工作流程
创建 API 密钥，检测有意义的工作流程，并将第一个审核的查询转换为图表或报告。
更多客户案例
Browserflow: 从商业事件到显而易见的答案LogSnag: 从原始事件交付到团队可以使用的答案