01
事务与 Apdex优先关注关键端点
按交易比较响应时间、吞吐量、错误率和 Apdex。结合使用百分位数和平均值，以观察较慢的请求。
应用性能监控
应用运行缓慢？
查看时间消耗的各个环节。
从结账缓慢到API响应停滞，可关联事务、SQL、外部服务和代码，为团队提供共享证据，帮助优先处理影响用户的因素。
01 / 发现找出影响业务的端点
02 / 诊断分离代码、SQL 和 API 响应时间
03 / 验证将部署与基线进行比对验证
请求内部流程
超越‘变慢’的表面现象
检查每一步
选择一个场景以查看概览、选定的追踪记录以及下一步调查步骤
应用程序 / checkout-api · Node.js · app-03
15分钟样本窗口性能概览
p95 响应时间2.84 s95% 的请求在此时间内完成
吞吐量428 rpm每分钟请求数
错误率0.8 %失败请求占比
Apdex0.72与配置目标对比
响应时间 / p95 checkout-api
14:00–14:15 · 14:07 部署 v2.8.1
服务依赖关系
checkout-api
SQL支付 API
追踪中观察到的关系
选定追踪
2,480 ms · 追踪 #a72fPOST /api/checkout
跨度 / 持续时间
01,240 ms2,480 ms
POST /api/checkout2,480 ms
↳ checkout.handler2,380 ms
↳ SELECT inventory1,820 ms
↳ POST payment /authorize280 ms
CPU 性能剖析 / 火焰图示例说明 · 非时间线
checkout.handler 100% 采样
calculatePromotions 82%
evaluateRules 68%
matchRules 51%
宽度代表示意性的 CPU 样本份额，与上文的耗时轨迹无关。
该轨迹为单个请求。父跨度包含其子跨度，因此行耗时不会相加。上方的 p95 汇总了时间窗口。
调查：SQL 占该请求的 73%
调查证据SELECT inventory 操作耗时 1,820 毫秒。在决定进行 SQL 修改前，请检查其查询计划、索引、行数及锁情况。
示意图中的控制台和指标解释了工作流程；它们并非客户实际结果或性能保证。
全面掌握应用状况
从应用健康状况
深入到代码级细节。
日常操作、故障诊断以及变更后验证时，请使用右侧视图。
02
分布式追踪跨服务追踪请求
检查父跨度和子跨度的每步耗时。连接能够传播追踪上下文的已监控服务。
03
服务拓扑图了解服务依赖关系
映射观察到的服务关系，然后结合延迟和错误率确定需要调查的位置。
04
数据库与 N+1查找慢 SQL 和重复查询
分离数据库时间，检查与SQL调用相关联的追踪信息，识别N+1模式，当项目数量增加时查询调用也随之增长。
05
外部服务定位外部 API 的耗时
检查对支付、ERP及第三方API的调用。审查原始请求追踪中的端点、状态和超时情况。
06
异常与 HTTP 故障结合上下文调查错误
按异常进行分组，并检查堆栈追踪、事务和HTTP失败，以区分代码错误与服务调用失败。
07
持续性能分析分析 CPU 和内存热点
使用性能分析和火焰图来检查资源消耗高的函数，比较不同时间段并调查性能下降问题。运行时支持首先经过验证。
08
关联上下文将追踪与相关事件关联
在兼容的数据采集配置下，使用日志、基础设施指标和会话追踪。额外工具在提案中进行规划。
09
版本与部署对比部署前后的变化
将应用程序版本和时间窗口与部署标记进行对比。在归因原因之前，调查延迟或错误的变化情况。
10
主机追踪识别表现异常的主机
按主机进行过滤，以区分整体服务问题与单台机器的问题，结合版本和可用资源上下文进行分析。
11
告警与升级处理将告警发送给对应负责人
使用预设阈值或异常基线，并配置邮件、Slack、Teams或Webhook通知。制定维护计划的抑制策略和测试升级路径。
12
报告与对比共享证据，支持决策
定期审查请求、失败情况和Apdex指标，按日、周或月生成报告。通过对比不同时间段，使开发和运维团队能够共同追踪改进情况。
连接方式
您的应用处理请求。
APM 分析遥测数据。
兼容的代理或监控工具将遥测数据发送至APM。用户请求在应用路径中继续处理，无需经过APM。
跨服务追踪需要上下文传播。采集端点、采样和数据访问功能将根据您的环境进行规划。
应用请求／响应
用户／客户端
⇄应用程序APM 探针
⇄SQL / API
↓追踪 · 指标 · 错误遥测数据独立发送
APM 平台分析 · 关联 · 告警
↓ 开发与运维共同排查并规划变更
连接您的技术栈
从您的团队
已在使用的语言开始。
在受控环境中验证运行时、版本和框架，选择代理并测试数据采集功能。
Go
PHP
Node.js
Java
Python
Ruby
.NET自动监控、自定义跨度、性能分析和上下文关联因语言、版本和库而异。在生产发布前，我们将确认兼容性、开销和重启需求。
企业接入
清晰掌握系统状况。
采用团队能够运维的部署方案。
Ruk-Com将帮助围绕贵组织的实际情况规划数据采集和调查工作流程，并明确访问权限和责任归属。
01范围
确定问题与范围
识别关键业务交易、运行时、主机、负责人及事件时间段。
明确范围的交付成果服务清单与成功标准
02接入监测
在数据管控下接入监测
为敏感头信息、查询或数据体定义采样、保留和屏蔽策略。在采集生产数据前必须进行测试。
明确范围的交付成果监测接入与访问计划
03基线
建立基线与告警
验证追踪的连续性、指标和告警的传递情况。在具有代表性的工作负载下记录正常行为。
明确范围的交付成果基线与告警验证
04交接
移交证据与职责
与开发人员共同优先处理发现的问题，明确变更后的对比基准，并移交运行手册和升级联系人。
明确范围的交付成果调查结果与运维手册
APM 提供调查证据。代码、索引和生产环境配置变更需指定责任人、审批流程和测试，纳入您的变更管理流程。托管运维及额外开发工作在方案中明确说明。
Ruk-Com Agent
各服务均提供代理支持
与技术及网络安全专家团队合作：监控、异常分析、规划及协调响应。
价格明确／范围清晰
为需要深入了解
自身应用的团队提供 APM。
优先选择影响收入或服务交付的应用程序，然后根据证据逐步扩大覆盖范围。
应用性能监控
฿3,500 / 台 / 月
提供您的机器数量、运行时长和症状信息，以便提出具有明确安装与支持范围的方案。
接入前确认
申请 APM 评估 →机器和容器数量、数据量、采样率、保留周期、访问权限、部署费用、税费以及任何额外集成工具的费用。
开始之前
接入生产环境
之前。
明确边界，以便收集团队可采取行动的证据。
APM 与服务器监控有何不同？
CPU 和内存反映资源健康状况。APM 将症状与事务、SQL 查询、外部调用和代码关联起来，共同帮助聚焦应用和基础设施的排查工作。
APM 能否自动使应用变快？
不能。APM 用于定位调查目标。团队需分析根本原因、选择变更方案、在部署后通过相似工作负载和指标进行测试和验证。
敏感信息会进入 APM 吗？
这取决于代理和配置。请检查请求头、查询字符串、SQL 参数和请求体；配置并测试数据屏蔽或排除规则，然后在生产环境采集前就保留和访问权限达成一致。
如何与微服务和容器协同工作？
对所需服务进行监控，并保持上下文追踪的一致性。定义服务、环境和版本标签。在报价前确认机器或容器的计费单位。
需要为 Ruk-Com 准备哪些信息？
分享您的架构、编程语言和版本、机器数量、慢请求端点、故障时间段及影响范围，以及负责人和访问限制，以明确范围和成功标准。