APM 最佳实践：从业者指南中的注意事项与禁忌

Elastic 中国社区官方博客

于 2025-07-04 10:40:19 发布

阅读量641

点赞数 11

CC 4.0 BY-SA版权

分类专栏： Observability Elastic 文章标签：大数据 elasticsearch 搜索引擎全文检索功能测试可用性测试性能优化

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/UbuntuTouch/article/details/149110649

Elastic 同时被 2 个专栏收录

1942 篇文章

订阅专栏

Observability

276 篇文章

订阅专栏

作者：来自 Elastic Observability Team

应用性能管理（Application performance management - APM）是定期跟踪、衡量和分析软件应用程序性能和可用性的做法。APM 可以帮助你在复杂的 microservices 环境中获得可见性，而这种复杂性可能会让 site reliability engineering （ SRE ）团队应接不暇。由此产生的洞察力可以带来最佳的用户体验，并实现预期的业务成果。这个过程虽然复杂，但目标很明确：确保应用程序顺利运行，满足用户和业务的期望。

清晰地了解应用程序的运行情况以及主动进行 APM 实践，对于维护高性能的软件应用程序至关重要。APM 不应该是事后的想法，它应该从一开始就被考虑进去。当主动实施时，它可以通过将监控组件直接嵌入应用程序中，整合到软件运行的方式里。

什么是应用性能管理？

应用性能管理（Application performance management）包括对应用程序后端和前端性能的持续监控、分析和管理。应用监控正在不断扩展和演进，但 APM 策略不应孤立制定。将多个利益相关者、业务专家、应用程序开发人员和运维团队纳入进来至关重要。成功的 APM 策略不仅仅关注 uptime 或服务器健康状况，而是在问题影响到用户之前就关注应用程序的服务水平目标（service level objectives - SLOs ）。

现代 APM 实施方式包括对你的应用程序进行检测，以收集三种类型的 telemetry 数据：traces（请求流程）、metrics（聚合指标）和 logs（离散事件）。挑战不仅仅是收集数据，而是要在不影响性能的前提下收集正确的数据。

了解更多关于 observability metrics 的内容。

检测有多种方式，但最有效的策略是将自动检测（针对框架和库）与手动检测（针对业务逻辑）相结合。使用 OpenTelemetry agent 的自动检测可以以最少的代码更改，覆盖你 80% 的 observability 需求：

# Auto-instrumentation handles this automatically
@app.route('/api/orders')
def create_order():
    # Add manual span only for critical business logic
    with tracer.start_as_current_span("order.validation") as span:
        span.set_attribute("order.value", order_total)
        if not validate_order(order_data):
            span.set_status(Status(StatusCode.ERROR))
            return 400

建议：从自动检测开始，然后为关键业务操作添加手动 span。
禁忌：不要对每个函数调用都进行手动检测 —— 这会带来性能开销和噪音。
陷阱：过度检测可能会增加 15%–20% 的延迟。通过基准性能对比来监控你的监控。

组织或企业在制定 APM 策略时需要考虑的一些组件包括：

性能监控，包括评估延迟、服务水平目标（ SLOs ）、响应时间、吞吐量和请求量
错误跟踪，包括异常、崩溃和失败的 API 调用
基础设施监控，包括支持应用程序的服务器、容器和 cloud 环境的健康状况与资源使用情况
用户体验指标，包括加载时间、会话性能、点击路径以及浏览器或设备信息（需要记住的是，即使系统指标看起来正常，用户仍可能遇到性能问题）

高效 APM 的关键原则

高效应用性能管理的核心原则包括端到端可见性（从用户浏览器到数据库）、实时监控与洞察，以及以用户和业务目标为中心的上下文洞察。APM 可以通过持续优化和性能提升来增强应用的可扩展性。

建议：实现基于 SLO 的实时仪表盘与告警，而不是依赖随意设定的阈值。
禁忌：不要仅依赖周期性性能评估或 CPU / memory 告警 —— 应该监控用户体验指标。
陷阱：来自底层系统指标的告警疲劳。应聚焦能反映真实问题的用户相关 SLO。

制定 APM 策略时，可参考以下关键原则：

主动监控：在问题影响用户之前就进行预防，通过设置告警并快速响应异常。但要避免告警疲劳，将自动化告警与人工监督结合，聚焦结果而非单纯系统指标。
实时洞察：不仅仅记录问题，而是基于实时数据和仪表盘快速做出决策，优先关注最关键的业务事务。利用 telemetry 数据（logs、metrics 和 traces）来解析性能洞察。
端到端可见性：监控整个环境中的应用程序、完整用户流程及从前端到后端的所有层级。
以用户为中心的方法：从最终用户的角度优先考虑性能和体验，同时兼顾关键业务目标。
真实用户监控：工作不应在交付到用户手中时就停止。通过监控用户体验，依据他们的反馈进行迭代和优化。
持续改进：利用洞察信息持续优化，定期发现和解决未报告的问题。问题应动态应对，而不是等周期性评估时才处理。

上下文传递：确保 trace 上下文贯穿整个请求路径，尤其是跨服务边界时。

# Outgoing request - inject context
headers = {}
propagate.inject(headers)
response = requests.post('http://service-b/process', headers=headers)

抽样策略：使用智能抽样在可见性与性能之间取得平衡：
- 对高流量服务使用 1%–10% 的基于头部的抽样（ head-based sampling ）
- 对错误和慢请求使用 100% 的基于尾部的抽样（ tail-based sampling ）
- 监控检测开销 —— 目标是性能影响低于 5%

APM 实施最佳实践

合适的 APM 解决方案应以最小的检测成本支持你的技术栈。OpenTelemetry 已成为行业标准，提供可跨语言使用的、与供应商无关的检测方案：

@RestController
public class OrderController {
    
    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        // Auto-instrumentation captures this endpoint automatically
        // Add custom business context
        Span.current().setAttributes(Attributes.of(
            stringKey("order.value"), String.valueOf(request.getTotal()),
            stringKey("user.tier"), request.getUserTier()
        ));
        
        return ResponseEntity.ok(processOrder(request));
    }
}

建议：在生产环境中实施抽样策略，并监控检测开销。
禁忌：不要对高流量服务使用 100% 抽样 —— 这会影响性能并导致存储成本激增。
陷阱：基于头部的抽样可能会漏掉关键的错误 trace。使用基于尾部的抽样可以在减少数据量的同时捕获所有错误。

正确做法如下：

选择合适的 APM 解决方案：合适的 APM 工具应与应用架构和组织需求相匹配。该解决方案应为组织提供监控、跟踪、衡量和分析软件应用所需的工具和能力。企业可以使用 OpenTelemetry 这个开源的 observability 框架，对应用进行检测并收集 telemetry 数据（traces、metrics 和 logs）。
管理基数以控制成本：高基数属性会使指标难以使用且成本高昂：

# Good - bounded cardinality
span.set_attribute("user.tier", user.subscription_tier)  # 3-5 values
span.set_attribute("http.status_code", response.status_code)  # ~10 values

# Bad - unbounded cardinality  
span.set_attribute("user.id", user.id)  # Millions of values
span.set_attribute("request.timestamp", now())  # Infinite values

基于 SLOs 设置智能告警，而不是使用随意的阈值。利用错误预算来决定何时通知相关人员：

slos:
  - name: checkout_availability
    target: 99.9%
    window: 7d
  - name: checkout_latency  
    target: 95%  # 95% of requests under 500ms
    window: 7d

培训团队并促进协作。APM 策略影响广泛的利益相关者，不仅仅是开发人员。务必让 IT 团队和其他业务相关人员参与跨部门协作。通过将 APM 融入组织架构，共同合作。确保制定清晰的目标和 KPI，与业务需求和用户体验保持一致。
审查和评估。APM 策略会随着应用和业务需求的变化不断发展和调整。

APM 中的监控策略

成功的应用性能管理策略的关键之一是考虑如何以及何时使用不同的监控方法。结合多种监控策略至关重要，因为应用的不同组件，如用户体验或基础设施，需要针对性的方法来有效检测和解决问题。多样化的策略可确保全面覆盖、更快分析、更稳定的应用性能以及更满意的最终用户。

需要考虑的各种监控方法包括：

实时监控：以亚秒级粒度持续跟踪系统实时性能。除了技术指标外，还要针对业务逻辑实现自定义指标：

order_processing_duration = Histogram(
    "order_processing_seconds",
    "Time to process orders", 
    ["payment_method", "order_size"]
)

with order_processing_duration.labels(
    payment_method=payment.method,
    order_size=get_size_bucket(order.total)
).time():
    process_order(order)

合成监控：模拟用户交互，提前发现问题，防止真实用户受影响。对外部依赖尤为关键：

// Synthetic check for critical user flow
const syntheticCheck = async () => {
    const span = tracer.startSpan('synthetic.checkout_flow');
    try {
        await loginUser();
        await addItemToCart();
        await completePurchase();
        span.setStatus({code: SpanStatusCode.OK});
    } catch (error) {
        span.recordException(error);
        span.setStatus({code: SpanStatusCode.ERROR});
        throw error;
    } finally {
        span.end();
    }
};

深入诊断与性能分析：帮助排查复杂的性能瓶颈，包括第三方插件或工具。通过应用性能分析，你可以更深入地挖掘数据，分析其功能表现。
分布式追踪：微服务架构的关键。需要在异步边界仔细处理上下文传递：

# Event-driven systems - propagate context through messages
def publish_order_event(order_data):
    headers = {}
    propagate.inject(headers)
    
    message = {
        'data': order_data,
        'trace_headers': headers  # Preserve trace context
    }
    kafka_producer.send('order-events', message)

APM 数据分析与洞察

监控和收集数据只是开始。企业需要懂得如何解读应用性能管理数据，以便进行调优和决策。

识别趋势和模式有助于团队主动发现问题。利用关联分析将用户投诉与后端性能关联起来。下面是使用 ES|QL （ Elastic 查询语言）的示例：

FROM traces-apm*
| WHERE user.id == "user_12345" 
  AND @timestamp >= "2024-06-06T09:00:00" 
  AND @timestamp <= "2024-06-06T10:00:00"
| EVAL duration_ms = transaction.duration.us / 1000
| KEEP trace.id, duration_ms, transaction.name, service.name, transaction.result
| WHERE duration_ms > 2000
| SORT duration_ms DESC
| LIMIT 10

检测瓶颈：APM 揭示了常见的性能反模式，如下面代码中的 n+1 问题。使用 APM 来优化代码：

# N+1 query problem detected by APM
def get_user_orders_slow(user_id):
    user = User.query.get(user_id)
    orders = []
    for order_id in user.order_ids:  # Each iteration = 1 DB query
        orders.append(Order.query.get(order_id))
    return orders

# Optimized after APM analysis
def get_user_orders_fast(user_id):
    return Order.query.filter(Order.user_id == user_id).all()  # Single query

关联指标并将用户投诉与后端性能数据（包括历史数据）联系起来，可以揭示系统不同部分的交互方式。这有助于团队准确诊断根本原因，了解性能问题的全面影响。

自动化根因分析，利用基于 AI / machine learning 的工具如 AIOps，可以通过精准定位问题源头，加速诊断和解决，减少停机时间，释放资源。

重要的是使用数据的整体视图来指导未来决策。数据越多，利用价值越大。

建议：使用分布式追踪来识别导致性能下降的具体服务和操作。
禁忌：不要认为相关性就意味着因果关系 —— 要用代码级性能分析数据进行验证。
陷阱：遗留系统在追踪中常常表现为黑盒。应使用日志关联和合成 span 来保持可见性。

高级实施模式

复杂的生产环境带来独特挑战，需要采用高级实施策略。本节介绍处理多语言架构、遗留系统集成和复杂关联分析的实用方法。

多语言环境中的上下文传递：在不同语言和框架之间维护 trace 上下文，需要特别关注传递机制：

// Java - Auto-propagation with Spring Cloud
@PostMapping("/orders")
public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
    Span.current().setAttributes(Attributes.of(
        stringKey("order.type"), request.getOrderType(),
        longKey("order.value"), request.getTotalValue()));
    
    // OpenFeign automatically propagates context to downstream services
    return paymentClient.processPayment(request.getPaymentData());}

// Go - Manual context extraction and propagation
func processHandler(w http.ResponseWriter, r *http.Request) {
    ctx := otel.GetTextMapPropagator().Extract(r.Context(), 
                                              propagation.HeaderCarrier(r.Header))
    ctx, span := tracer.Start(ctx, "process_payment")
    defer span.End()
    // Continue with trace context maintained}

遗留系统集成：为无法直接进行检测的系统创建 observability 桥接：

# Synthetic spans with correlation IDs for mainframe calls
with tracer.start_as_current_span("mainframe.account_lookup") as span:
    correlation_id = format(span.get_span_context().trace_id, '032x')
    
    logger.info("CICS call started", extra={
        "correlation_id": correlation_id,
        "trace_id": span.get_span_context().trace_id
    })
    
    result = call_mainframe_service(account_data, correlation_id)
    span.set_attribute("account.status", result.status)

使用 ES|QL 进行高级追踪分析：利用 Elastic 查询语言将用户投诉与后端性能关联起来：

-- Find slow requests during complaint timeframe
FROM traces-apm*
| WHERE user.id == "user_12345" AND @timestamp >= "2024-06-06T09:00:00"
| EVAL duration_ms = transaction.duration.us / 1000
| WHERE duration_ms > 2000
| STATS avg_duration = AVG(duration_ms) BY service.name, transaction.name
| SORT avg_duration DESC

-- Correlate errors across service boundaries
FROM traces-apm*
| WHERE trace.id == "44b3c2c06e15d444a770b87daab45c0a"
| EVAL is_error = CASE(transaction.result == "error", 1, 0)
| STATS error_rate = SUM(is_error) / COUNT(*) * 100 BY service.name
| WHERE error_rate > 0

事件驱动架构模式：通过消息头显式传递上下文，以支持异步处理：

# Producer - inject context into message
headers = {}
propagate.inject(headers)
message = {
    'data': order_data,
    'trace_headers': headers  # Preserve trace context
}
await kafka_producer.send('order-events', message)

# Consumer - extract and continue trace
trace_headers = message.get('trace_headers', {})
context = propagate.extract(trace_headers)
with tracer.start_as_current_span("order.process", context=context):
    await process_order(message['data'])