Aurora慢查询监控实战：Lambda自定义指标与告警方案

为什么需要自建慢查询监控体系

在生产环境中，慢查询是数据库性能劣化的首要信号。一条执行时间过长的SQL语句不仅会占用数据库连接资源，还可能引发连接池耗尽的连锁反应，最终导致整个应用不可用。从成本角度看，被动应对慢查询往往意味着需要升级实例规格，这是一种治标不治本的做法。

AWS原生监控的能力边界

AWS RDS/Aurora提供的Performance Insights虽然能展示慢查询详情，但存在几个关键缺陷：

• 无法设置自动化告警：必须人工登录控制台查看，无法实现主动监控
• 缺少慢查询计数指标：CloudWatch没有开箱即用的慢查询数量Metric
• 无法识别索引问题：原生指标不提供Rows_examined与Rows_sent的比率分析

基于以上限制，我建议通过自定义Lambda函数解析Slow Log，构建更精细的监控能力。

方案架构设计

本方案采用纯Serverless架构，核心组件包括：

• Aurora Slow Log：数据源，记录所有超过阈值的查询
• CloudWatch Logs：日志聚合层，接收Aurora导出的慢查询日志
• Lambda函数：计算层，解析日志并生成自定义指标
• CloudWatch Metrics：指标存储，支持告警规则配置
• SNS：通知层，可集成飞书、钉钉等企业通讯工具

核心指标计算逻辑

慢查询识别

从Slow Log中提取Query_time字段，与预设阈值比较。建议生产环境将阈值设为1秒，可通过环境变量灵活调整：

SLOW_QUERY_TIME = float(os.environ.get('SLOW_QUERY_TIME', '1.0'))

query_time_match = re.search(r'Query_time:\s+(\d+\.\d+)', message)
if query_time_match:
    query_time = float(query_time_match.group(1))
    if query_time > SLOW_QUERY_TIME:
        slow_query_count += 1

无索引查询判断

Rows_examined/Rows_sent比率是判断索引有效性的关键指标。该比率表示数据库为返回一行结果需要扫描多少行数据：

NO_INDEX_RATIO = float(os.environ.get('NO_INDEX_RATIO', '100.0'))

rows_examined = int(rows_examined_match.group(1))
rows_sent = int(rows_sent_match.group(1))

if rows_examined > 0 and rows_sent > 0:
    no_index_ratio = rows_examined / rows_sent
    if no_index_ratio > NO_INDEX_RATIO:
        no_index_query_count += 1

根据实践经验，比率的解读标准如下：

• 1-2：索引使用最优，无需优化
• 3-10：索引使用合理，可接受
• 10-100：存在优化空间，建议review索引设计
• 100以上：索引严重缺失或失效，需立即处理

发布CloudWatch自定义指标

cloudwatch.put_metric_data(
    Namespace='RDS/AuroraSlowLog',
    MetricData=[
        {
            'MetricName': 'AuroraSlowQueryCount',
            'Dimensions': [
                {'Name': 'DBClusterIdentifier', 'Value': cluster_id}
            ],
            'Value': slow_query_count,
            'Unit': 'Count',
            'Timestamp': timestamp
        },
        {
            'MetricName': 'AuroraNoIndexSlowQueryCount',
            'Dimensions': [
                {'Name': 'DBClusterIdentifier', 'Value': cluster_id}
            ],
            'Value': no_index_query_count,
            'Unit': 'Count',
            'Timestamp': timestamp
        }
    ]
)

Aurora参数组配置要点

在部署监控方案前，必须确保Aurora集群的参数组已正确配置。以下参数需要手动设置，Lambda函数仅做检查不会自动修改：

• slow_query_log：设为1启用慢查询日志
• long_query_time：建议设为1秒，根据业务特点调整
• log_output：必须设为FILE才能导出到CloudWatch
• log_queries_not_using_indexes：设为1记录未使用索引的查询
• min_examined_row_limit：设为0记录所有慢查询

实施建议与注意事项

从实际运维角度，我有以下建议：

• 告警阈值分级：建议设置Warning（5分钟内10条慢查询）和Critical（5分钟内50条）两级告警
• 无索引查询优先处理：这类查询优化ROI最高，添加合适索引后性能可能提升数十倍
• 定期review指标趋势：关注慢查询数量的周环比变化，及早发现性能退化
• 结合Performance Insights：自定义指标负责告警，PI负责深入分析具体SQL