如何为Alexa技能配置错误告警及优化AWS Lambda日志管理策略？

我来分享下我和身边同行处理这类场景的经验，应该能帮到你：

1. 其他开发者如何管理非致命错误的日志与告警？ #

同行们常用的几种实用方案：

• 结构化日志输出：使用winston、pino这类日志库，将日志输出为包含level（如warn/error/info）、业务上下文（用户ID、请求ID等）的JSON格式，让CloudWatch可以精准过滤不同级别的日志。
• 自定义指标上报：遇到非致命错误时，直接调用CloudWatch的PutMetricData API，上报自定义指标（比如NonFatalErrorCount），基于指标而非日志内容来配置告警，可靠性更高。
• 统一前缀标记：给非致命错误日志加上固定前缀（如[NON-FATAL-ERROR]），这样CloudWatch的指标过滤器可以通过匹配前缀快速定位这类日志并触发告警。

2. 如何将现有日志转换为CloudWatch更易触发告警的形式？ #

可以从这几个方向入手，按改动成本排序：

方案一：引入结构化日志库（推荐） #

替换原生console，用日志库输出带级别的JSON日志，示例代码（以winston为例）：

const winston = require('winston');
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [new winston.transports.Console()]
});

// 记录非致命警告
logger.warn('用户输入格式不符合要求', { userId: 'amzn1.ask.account.XXX', requestId: 'amzn1.echo-api.request.XXX' });
// 记录内部故障（即使返回成功响应）
logger.error('第三方天气API请求超时', { userId: 'amzn1.ask.account.XXX', requestId: 'amzn1.echo-api.request.XXX' });

之后在CloudWatch中创建指标过滤器，匹配JSON中的"level":"warn"或"level":"error"字段，生成对应的告警指标。

方案二：轻量封装console（改动最小） #

如果不想引入新依赖，可以封装原生console，自动添加级别前缀：

const logger = {
  info: (msg, meta) => console.log(`[INFO] ${JSON.stringify({ message: msg, ...meta })}`),
  warn: (msg, meta) => console.log(`[WARN] ${JSON.stringify({ message: msg, ...meta })}`),
  error: (msg, meta) => console.log(`[ERROR] ${JSON.stringify({ message: msg, ...meta })}`)
};

后续用logger.warn/logger.error替代console.log，CloudWatch就能通过匹配[WARN]/[ERROR]前缀来过滤日志。

关键注意点 #

针对「内部故障但返回成功响应」的场景，一定要把这类故障的日志级别设为warn或error，而不是info——即使给Alexa返回了友好回复，日志里也要明确标记问题严重性，这样才不会漏掉告警。

3. 你的思路是否有误？是否只需满足于致命异常告警即可？ #

你的思路没问题，但不建议只关注致命异常告警：

• 非致命错误（比如第三方服务超时、用户输入异常）看似不影响当前请求，但积累起来会严重影响用户体验，甚至可能演变成致命故障（比如某个依赖服务持续超时，导致大量请求堆积）。
• 更合理的做法是分层监控：
  • 致命异常：通过CloudWatch默认的Lambda Errors指标告警，同时尽量在代码中捕获这类异常，返回自定义成功响应，避免Alexa返回通用错误提示，同时将异常记为error级别日志。
  • 非致命错误：用结构化日志+自定义指标监控，提前发现潜在问题，比如某个时段第三方API超时率飙升，就能及时排查处理，不用等到用户投诉。
• 如果后续需要更复杂的日志分析，也可以把CloudWatch日志导出到其他工具，但仅针对告警需求的话，CloudWatch配合结构化日志完全足够。

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