分析服务健康、SLA、服务网格与运行时瓶颈时，用 RED…

当需要基于 Dynatrace DQL 分析服务响应时间、错误率、吞吐量、SLA、服务网格开销以及 Java/Node.js/.NET/Python/PHP/Go 运行时指标时使用。

适用场景

解决思路

1. 使用 metrics-based timeseries 查询监控服务的 Rate、Errors、Duration（RED 指标）。
2. 围绕核心指标查询：dt.service.request.response_time（微秒）、dt.service.request.count、dt.service.request.failure_count。
3. 对响应时间按 avg、p50、p95、p99 聚合，并跟踪错误率尖峰、吞吐/峰值/增长、性能退化、多集群对比。
4. 写 RED 查询时使用 DQL 模板：timeseries { p95 = percentile(dt.service.request.response_time, 95), total_requests = sum(dt.service.request.count), failures = sum(dt.service.request.failure_count) }, by: {dt.service.name} | fieldsAdd p95_ms = p95[] / 1000, error_rate_pct = (failures[] * 100.0) / total_requests[]。
5. 详细 RED 查询参考 references/service-metrics.md。
6. 对需要复杂过滤、自定义逻辑或详细分析的场景，改用 span-based 查询：fetch spans。
7. 用 span 查询做 SLA 合规跟踪（自定义阈值）、服务健康评分、operation/endpoint 级性能分析、自定义错误分类、带错误详情的失败模式检测。
8. 写 SLA span 查询模板：fetch spans, from: now() - 1h | filter request.is_root_span == true | fieldsAdd meets_sla = if(request.is_failed == false AND duration < 3s, 1, else: 0) | summarize total = count(), sla_compliant = sum(meets_sla), by: {dt.service.name} | fieldsAdd sla_compliance_pct = (sla_compliant * 100.0) / total。
9. 详细 SLA/高级服务分析查询参考 references/service-metrics.md。
10. 监控基于消息的服务通信（队列、主题），使用 messaging 指标。
11. 查询消息关键指标：dt.service.messaging.publish.count、dt.service.messaging.receive.count、dt.service.messaging.process.count、dt.service.messaging.process.failure_count。
12. 用这些指标监控消息吞吐（publish/receive 速率）、处理失败、队列/主题健康，并通过 publish 与 receive 速率对比检测 consumer lag。
13. messaging DQL 模板：timeseries { published = sum(dt.service.messaging.publish.count), received = sum(dt.service.messaging.receive.count), processed = sum(dt.service.messaging.process.count), failed = sum(dt.service.messaging.process.failure_count) }, by: {dt.service.name}。
14. 详细 messaging 查询参考 references/service-metrics.md。
15. 监控 service mesh ingress 性能与开销。
16. 查询 mesh 指标：dt.service.request.service_mesh.response_time（微秒）、dt.service.request.service_mesh.count、dt.service.request.service_mesh.failure_count。
17. 用 mesh 指标做 mesh vs direct 性能对比、计算 mesh overhead、分析 mesh 失败、gRPC 流量、多集群 mesh 性能。
18. mesh DQL 模板：timeseries { direct_p95 = percentile(dt.service.request.response_time, 95), mesh_p95 = percentile(dt.service.request.service_mesh.response_time, 95) }, by: {dt.service.name} | fieldsAdd mesh_overhead_ms = (mesh_p95[] - direct_p95[]) / 1000。
19. 详细 mesh 查询参考 references/service-metrics.md。
20. 做运行时特定监控：按技术栈加载对应 reference 并查询运行时性能/资源指标。
21. Java/JVM：参考 references/java.md，查询 memory（heap、pools、metaspace）、GC（impact、suspension、frequency、pause time）、threads（count monitoring、leak detection）、classes（loading、unloading、growth）。
22. Node.js：参考 references/nodejs.md，查询 event loop（utilization、active handles）、V8 heap（memory used、total）、GC（collection time、suspension）、process（RSS memory）。
23. .NET CLR：参考 references/dotnet.md，查询 memory（按 generation 的 consumption）、GC（collection count、suspension time）、thread pool（threads、queued work）、JIT（compilation time）。
24. Python：参考 references/python.md，查询 threads（active thread count）、heap（allocated blocks）、GC（collection by generation、pause time）、objects（collected、uncollectable）。
25. PHP：参考 references/php.md，查询 OPcache（hit ratio、memory、restarts）、GC（effectiveness、duration）、JIT（buffer usage）、interned strings（usage、buffer）。
26. Go：参考 references/go.md，查询 goroutines（count、leak detection）、GC（suspension、collection time）、memory（heap by state、committed）、scheduler（worker threads、queue size）、CGo（call frequency）。
27. Agent 执行时遵循 Act First, Refine Later：对阈值检查、异常检测、性能对比等分析请求，立即用合理默认值执行，不要就参数做访谈。
28. 当分析工具（如 static-threshold-analyzer）需要 threshold/service scope 时，选择默认值并在回答中说明，让用户后续细化。
29. 未指定时采用默认：响应时间阈值 1000 ms（即 1,000,000 µs，因为指标基本单位是微秒）；服务范围 All services；时间范围按请求，否则阈值检查用 last 30 min，一般分析用 2h。
30. 处理阈值违规请求：用 create-dql 构建 timeseries 查询 avg(dt.service.request.response_time)，按 dt.smartscape.service 分组。
31. 将该查询传给 static-threshold-analyzer，设置 threshold = 1000000（µs），alertCondition = ABOVE。
32. 用 get-entity-name 将实体 ID 解析为名称。
33. 呈现违规时包含 service names、timestamps、values、duration。
34. 识别用户措辞：当用户说「the fixed threshold」「a threshold」「the limit」时，理解为静态阈值检查，而不是用户期望你已知具体数值；「fixed」用于区分静态截止值与动态/季节性基线。此时套用 1000 ms 默认值并给出结果，允许用户细化。
35. 遵守 Scope Boundary：本技能只覆盖服务性能指标和运行时监控；遇到产品文档或配置问题（如「How do I add custom sensors?」「How do I configure service detection?」）改用 ask-dynatrace-docs。
36. 根据用户意图映射能力：service performance/response time/error rate → Service Performance (RED)，查 service-metrics.md。
37. SLA tracking/health scoring → Advanced Service Analysis，查 service-metrics.md。
38. service mesh/Istio/Linkerd/mesh overhead → Service Mesh Monitoring，查 service-metrics.md。
39. messaging/queue/topic/publish/consumer → Service Messaging Metrics，查 service-metrics.md。
40. JVM GC/Java memory/heap → Runtime-Specific (Java)，查 java.md。
41. Node.js event loop/V8 heap → Runtime-Specific (Node.js)，查 nodejs.md。
42. .NET CLR/GC generation → Runtime-Specific (.NET)，查 dotnet.md。
43. Python GC/thread count → Runtime-Specific (Python)，查 python.md。
44. OPcache/PHP GC → Runtime-Specific (PHP)，查 php.md。
45. goroutines/Go GC/scheduler → Runtime-Specific (Go)，查 go.md。
46. 查询构造模式 1：metrics-based (timeseries)，用于标准监控、仪表盘、告警；模式为 timeseries <metric> = <aggregation>(<metric_name>), by: {dimensions}；文件：service-metrics.md 和所有 runtime-specific 文件。
47. 查询构造模式 2：span-based (fetch spans)，用于复杂过滤、自定义逻辑、详细分析；模式为 fetch spans | filter request.is_root_span == true | fieldsAdd ... | summarize ...；文件：service-metrics.md 的 Advanced Service Analysis 部分。
48. 查询构造模式 3：比较查询；用 append 做 baseline comparison；用 shift: -15m 做 time-shifted baselines；示例：性能退化检测。
49. 构造响应时总是包含：metric name(s)（清晰的指标标识）、aggregation（avg/sum/percentile 等聚合方式）、grouping（使用的维度，如 dt.service.name、k8s.workload.name 等）、unit conversion（适当将微秒转换为毫秒）、filtering（相关阈值或条件）。
50. 引用运行时特定内容时：先检查用户技术栈；只提供相关运行时查询，不要把 6 种运行时全部堆给用户；解释运行时特定指标（例如「OPcache hit ratio」衡量 PHP opcode cache 效率）。
51. Workflow: Service Health Check：1) 检查 response time（RED 指标）；2) 检查 error rate（RED 指标）；3) 检查 traffic patterns（RED 指标）；4) 若怀疑运行时问题，加载 runtime-specific reference。
52. Workflow: SLA Monitoring：1) 定义 SLA 条件（例如 < 3s response time AND < 1% error rate）；2) 用 span-based 查询实现自定义 SLA 逻辑；3) 计算 compliance percentage；4) 过滤 non-compliant services。
53. Workflow: Service Mesh Analysis：1) 检查 mesh response time；2) 对比 mesh vs direct performance；3) 计算 mesh overhead；4) 分析 mesh failure rates。
54. Workflow: Runtime Troubleshooting：1) 识别技术栈并加载 runtime-specific reference；2) 依次检查 memory/GC metrics → threads/goroutines → runtime features。
55. 排障：响应时间值过大时，因为指标单位为微秒，除以 1000 转成毫秒。
56. 排障：service mesh 指标无数据时，检查 service mesh 是否未配置，验证 mesh sidecar injection 是否启用。
57. 排障：runtime 指标缺失时，确认是否选错技术栈或没有 OneAgent，确认 runtime 受支持且 OneAgent 处于活动状态。
58. 排障：dt.smartscape.service 返回 SmartscapeId 而不是名称时，用 getNodeName(dt.smartscape.service) 解析实体名称。
59. 排障：error rate 始终为零时，检查是否用错失败指标；应使用 dt.service.request.failure_count，而不是自定义字段。
60. 查阅参考：service-metrics.md（RED、SLA、service mesh 完整查询）；java.md、nodejs.md、dotnet.md、python.md、php.md、go.md。

适用边界 · 注意事项

• 不适用于基础设施指标、日志分析和分布式追踪/数据库性能分析；这些应使用 dt-obs-hosts、dt-obs-logs、tracing/database 对应技能。
• 不适用于解释已有查询、产品文档或配置/How-to 问题；应改用 ask-dynatrace-docs。
• 不适用于未接入 Dynatrace/OneAgent 或没有对应 DQL 分析工具的环境。