如何使用AWS EMF（嵌入式指标格式）实现错误与超时事件的日志追踪

你现有的耗时追踪逻辑无需大幅调整，只需扩展指标定义和新增业务维度即可满足需求，参考实现代码如下：

// 提前根据业务逻辑赋值请求状态变量
const isError = ret.isError || false;
const isTimeout = ret.isTimeout || false;
const errorType = ret.errorType || "none"; // 枚举值：none/timeout/connection_refused/status_code_5xx等
const retryAttempt = ret.retryAttempt || 0; // 0代表首次请求，N代表第N次重试

log.info("track those network dependencies", {
  duration: ret.duration,
  functionName: context.functionName,
  hostname: new URL(url).hostname,
  isError,
  isTimeout,
  errorType,
  retryAttempt,
  _aws: {
    Timestamp: new Date().getTime(),
    CloudWatchMetrics: [
      {
        Namespace: "ytemf",
        Dimensions: [
          ["functionName", "hostname"],
          ["functionName", "hostname", "errorType"],
          ["functionName", "hostname", "retryAttempt"]
        ],
        Metrics: [
          {
            Name: "duration",
            Unit: "Milliseconds",
          },
          {
            Name: "request_count",
            Unit: "Count",
            Value: 1
          },
          {
            Name: "request_error",
            Unit: "Count",
            Value: isError ? 1 : 0
          },
          {
            Name: "request_timeout",
            Unit: "Count",
            Value: isTimeout ? 1 : 0
          }
        ],
      },
    ],
  },
});

常见问题解答 #

• 是否需要每个错误上报1的数值？
  是。计数类指标采用错误事件赋值1、正常事件赋值0是通用实现方式，后续在CloudWatch中可直接通过SUM(request_error)获取指定周期错误总数，通过SUM(request_error)/SUM(request_count)计算错误率，无需额外数据转换。
• 重试场景需要累加计数吗？
  不要在单条日志中合并累加多次重试的计数。最优做法是每次请求（包含每一次重试）都单独上报一条EMF日志，通过新增的retryAttempt维度标注当前是第几次重试。该方案既可以统计含重试的总请求量，也能下钻统计不同重试阶段的成功率、耗时变化，还可以计算平均重试次数等衍生指标；如果合并计数会丢失重试过程的维度信息，不利于后续问题排查。

行业最佳实践 #

• 维度分层设计：定义多组维度组合，基础维度满足全局统计需求，新增错误类型、重试次数等下钻维度支撑细分场景的问题排查
• 指标分类规范：耗时类指标保留原始值，方便计算P50/P95/P99等耗时分位；计数类指标统一用Count单位，取值0或1，降低后续聚合计算的复杂度
• 避免高基数维度：不要将请求ID、用户ID、动态错误信息等取值量级极大的字段放入EMF维度中，避免导致CloudWatch指标数量暴增产生额外成本
• 字段取值统一：错误类型等维度的取值要提前统一枚举规则，不要使用动态生成的字符串作为维度值，保证指标统计的一致性

内容的提问来源于stack exchange，提问作者hendry