monitoring-alerting-commerce

监控与告警 — Commerce

概述

通用基础设施监控（CPU、内存、错误率）不足以满足电子商务需求——你需要 Commerce 领域的指标：结账漏斗转化率、按支付网关和卡类型细分的支付成功率与失败情况、购物车弃购率，以及库存缺货事件。本技能介绍如何在不同平台上设置监控、使用 OpenTelemetry 为自定义店面添加监测、构建 Commerce KPI 仪表板，以及设置告警，让问题在销售报告显示收入影响之前就能触发。

何时使用此技能

• 为新的无头店面或 Commerce 服务设置可观测性时
• 发生事故后，发现自己没有设置告警，无法及早发现问题时
• 需要实时了解结账性能和支付失败情况时
• 排查转化率下降，且原因可能是技术问题时
• 在大型促销活动前，为结账流程制定 SLO（服务等级目标）时

核心说明

步骤 1：确定你的平台以及可监控的内容

平台	内置监控	可添加的监控
Shopify	Shopify 管理后台显示订单、转化率和包含 Core Web Vitals 的性能报告	安装 Lucky Orange 或 Microsoft Clarity 来录制会话并跟踪漏斗流失；将 Shopify 连接到 Google Analytics 4，以详细跟踪结账漏斗
WooCommerce	WooCommerce 分析仪表板显示订单和收入；不内置性能监控	安装 MonsterInsights（GA4 集成）、WooFunnels（结账漏斗跟踪），并设置 Uptime Robot（免费套餐：50 个监控项）来发送可用性告警
BigCommerce	BigCommerce Analytics 显示订单、转化率和弃购购物车	通过原生集成将 BigCommerce 连接到 GA4；使用 Lucky Orange 在结账页面创建热力图并录制会话
自定义 / 无头	无——需要自行构建	使用 OpenTelemetry 添加监测，将指标发送到 Grafana Cloud（免费套餐：10K 个序列）或 Datadog；使用 PromQL 构建结账漏斗仪表板；参见下文的实现方式

步骤 2：按平台设置监控

---

Shopify

设置 GA4 结账漏斗跟踪：

1. 在 Shopify 管理后台中，前往 Online Store → Preferences → Google Analytics
2. 连接你的 GA4 媒体资源——Shopify 会自动发送所有标准电子商务事件（page_view、add_to_cart、begin_checkout、purchase）
3. 在 Google Analytics → Explore 中，创建漏斗探索：
   • 步骤 1：begin_checkout 事件
   • 步骤 2：add_shipping_info 事件
   • 步骤 3：add_payment_info 事件
   • 步骤 4：purchase 事件
   • 这会准确显示顾客在结账流程中的流失位置

监控店面的 Core Web Vitals：

1. 前往 Online Store → Themes，然后点击 View report
2. 此处会显示来自实际顾客的真实用户 LCP、CLS 和 FID 数据
3. 移动设备 LCP 评分较差（红色，> 4s）通常意味着主视觉图片需要优化，或需要设置 fetchpriority="high"

设置可用性与错误告警：

1. 安装 Lucky Orange（$19/month）或 Microsoft Clarity（免费），以便在结账错误发生时录制会话——这能准确展示出现故障时顾客看到的内容
2. 设置 Shopify Email 或 Slack 失败订单通知：前往 Settings → Notifications，启用 Order payment failure 通知
3. 如需监控正常运行时间：使用 Uptime Robot（免费，每 5 分钟检查一次）或 Better Uptime，在店面 URL 无法访问时向你发送告警

---

WooCommerce

将 WooCommerce 连接到 GA4：

1. 从 wordpress.org 安装 MonsterInsights（提供免费版，Pro 版起价为每年 $99）
2. 前往 Insights → Settings → General，连接 GA4 媒体资源
3. 启用 Enhanced eCommerce 跟踪功能 — 这会自动向 GA4 发送 add_to_cart、begin_checkout 和 purchase 事件

跟踪结账漏斗流失情况：

1. 从 wordpress.org 安装 WooFunnels（提供免费版）
2. 创建一个漏斗，并将购物车、结账和订单确认页面设为步骤
3. WooFunnels 会显示每个步骤的转化率，以及顾客在哪一步放弃

设置正常运行时间和错误告警：

1. 注册 Uptime Robot（免费版：50 个监控项，每 5 分钟检查一次）
2. 为主页、商店页面、结账页面和 /wp-admin/admin-ajax.php 添加监控项（WooCommerce 会大量使用此项）
3. 设置电子邮件或 Slack 通知，以便在任何监控项发生故障时收到通知

监控服务器运行状况：

1. 在托管服务控制面板（cPanel、Cloudways、Kinsta）中，为以下情况启用电子邮件告警：
   • PHP 错误日志（致命错误）
   • 磁盘使用率超过 80%
   • 内存使用率超过 80%
2. 在预发布环境中安装 Query Monitor 插件（免费，可从 wordpress.org 获取），以便在开发期间找出缓慢的数据库查询 — 在生产环境中将其停用

---

自定义 / Headless

对于自定义店面，请实施完整的可观测性技术栈：使用 OpenTelemetry 进行埋点，使用 Prometheus 或 Grafana Cloud 存储指标，并使用 Grafana 创建仪表板。

在构建仪表板之前定义电商 SLO — 这些将成为告警阈值：

指标	目标	告警阈值
支付成功率	95%	连续 2 分钟 < 90%
结账 P99 延迟	< 3000ms	连续 3 分钟 > 5000ms
结账可用性	99.9%	连续 2 分钟没有启动
目录页面 P95	< 1000ms	连续 5 分钟 > 2000ms

使用 OpenTelemetry 为店面添加埋点：

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-metrics-otlp-http @opentelemetry/exporter-trace-otlp-http \
  @opentelemetry/sdk-metrics

// instrumentation.ts — import before any other module
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http';
import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics';

const sdk = new NodeSDK({
  serviceName: 'commerce-storefront',
  traceExporter: new OTLPTraceExporter({ url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT }),
  metricReader: new PeriodicExportingMetricReader({
    exporter: new OTLPMetricExporter({ url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT }),
    exportIntervalMillis: 15000,
  }),
  instrumentations: [getNodeAutoInstrumentations({
    '@opentelemetry/instrumentation-http': { enabled: true },
    '@opentelemetry/instrumentation-pg': { enabled: true },
    '@opentelemetry/instrumentation-ioredis': { enabled: true },
  })],
});
sdk.start();

跟踪结账漏斗指标：

// lib/metrics/checkout-metrics.ts
import { metrics } from '@opentelemetry/api';

const meter = metrics.getMeter('commerce-checkout');

const checkoutStarted = meter.createCounter('checkout.started');
const checkoutCompleted = meter.createCounter('checkout.completed');
const paymentAttempts = meter.createCounter('payment.attempts');
const paymentSuccesses = meter.createCounter('payment.successes');
const paymentFailures = meter.createCounter('payment.failures');
const orderCreationDuration = meter.createHistogram('order.creation.duration_ms', {
  boundaries: [100, 250, 500, 1000, 2000, 5000, 10000],
});

export const checkoutMetrics = {
  recordCheckoutStart(channel: string) {
    checkoutStarted.add(1, { channel });
  },
  recordCheckoutComplete(channel: string, paymentMethod: string) {
    checkoutCompleted.add(1, { channel, payment_method: paymentMethod });
  },
  recordPaymentAttempt(gateway: string, method: string) {
    paymentAttempts.add(1, { gateway, method });
  },
  recordPaymentSuccess(gateway: string, method: string) {
    paymentSuccesses.add(1, { gateway, method });
  },
  recordPaymentFailure(gateway: string, declineCode: string) {
    paymentFailures.add(1, { gateway, decline_code: declineCode });
  },
  recordOrderCreation(durationMs: number, channel: string) {
    orderCreationDuration.record(durationMs, { channel });
  },
};

用于 Grafana 仪表板面板的 PromQL 查询：

# Payment success rate (gauge panel — target 95%)
rate(payment_successes_total[5m])
/
(rate(payment_successes_total[5m]) + rate(payment_failures_total[5m]))

# Checkout P99 latency
histogram_quantile(0.99,
  sum(rate(order_creation_duration_ms_bucket[5m])) by (le, channel)
)

# Checkout funnel conversion rate
rate(checkout_completed_total[1h]) / rate(checkout_started_total[1h])

# Payment failures by decline code (top 5)
topk(5, sum(rate(payment_failures_total[5m])) by (decline_code))

Prometheus 告警规则：

# prometheus/commerce-alerts.yaml
groups:
  - name: commerce-critical
    rules:
      - alert: PaymentSuccessRateLow
        expr: |
          (
            rate(payment_successes_total[5m]) /
            (rate(payment_successes_total[5m]) + rate(payment_failures_total[5m]))
          ) < 0.90
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Payment success rate below 90%"
          description: "Rate is {{ $value | humanizePercentage }}. Check Stripe status page and recent deployments."
          runbook: "https://wiki.mystore.com/runbooks/payment-failures"

      - alert: CheckoutHighLatency
        expr: |
          histogram_quantile(0.99,
            sum(rate(order_creation_duration_ms_bucket[5m])) by (le)
          ) > 5000
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Checkout P99 latency above 5 seconds"
          description: "P99 is {{ $value }}ms. Check database slow query log and Redis connection pool."

      - alert: CheckoutServiceDown
        expr: rate(checkout_started_total[5m]) == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "No checkouts being started — possible service outage"

为 Core Web Vitals 添加真实用户监控：

// lib/rum.ts — initialize in root layout
import { onCLS, onINP, onLCP, onFCP, onTTFB } from 'web-vitals';

function sendVital(metric: any) {
  navigator.sendBeacon?.('/api/rum/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    page: window.location.pathname,
  }));
}

export function initRUM() {
  onCLS(sendVital);
  onINP(sendVital);
  onLCP(sendVital);
  onFCP(sendVital);
  onTTFB(sendVital);
}

最佳实践

• 针对症状告警，而非原因 — 针对“支付成功率 < 90%”告警（影响收入的症状），而非针对“Stripe API 延迟 > 500ms”告警（原因）；基于症状的告警触发更快，也更便于采取行动
• 逐步跟踪结账漏斗 — 分别为每个步骤（购物车 → 结账 → 支付 → 确认）添加埋点，以便准确找出用户在哪一步流失
• 跟踪拒绝代码，而不仅是失败次数 — 由 insufficient_funds 主导的 10% 失败率，与 do_not_honor（可能是欺诈或发卡机构故障）有所不同；两者需要完全不同的应对方式
• 使用合成监控检查可用性 — RUM 依赖真实流量；定时运行合成结账流程（Playwright + Lambda），能在凌晨 3 点、顾客发现故障之前捕获中断
• 在每条告警中附上运行手册链接 — 每条告警注释都应包含一个 runbook URL，指向说明如何诊断和解决相应问题的页面
• 设置 for 持续时间以避免告警抖动 — 30 秒的延迟峰值属于正常情况；只有在条件持续存在时，带有 for: 2m 的告警才会触发

常见陷阱

问题	解决方案
告警过多，信噪比低	从 3–5 个高价值告警开始（支付失败、结账延迟、服务宕机）；只有在确认每个告警都能在正确阈值触发后，才添加更多告警
出错时未记录指标	在容易出错的操作前后埋点；即使支付失败时抛出异常，仍应递增 payment.failures
仪表板看起来正常，但收入下降	在技术指标旁添加业务指标（每分钟订单数、每小时收入）；即使达到技术 SLO，用户体验问题仍可能降低转化率
RUM 数据受到机器人流量影响	按用户代理过滤 RUM 事件；机器人流量会扭曲 Core Web Vitals 指标，并可能掩盖真实用户性能回退
Shopify GA4 漏斗未显示数据	确认 Online Store → Preferences 中的 GA4 Measurement ID 与 GA4 媒体资源一致；检查 GA4 DebugView，确认事件已触发

相关技能

• @flash-sale-scaling
• @load-testing-commerce
• @database-optimization-commerce
• @edge-commerce