mysql不提供连接失败告警功能，需通过错误日志中“access denied”条目配合外部脚本实现；因其明确标识权限校验失败，且默认开启、轻量可靠，而general_log和performance_schema无法准确反映失败连接。
直接结论：MySQL 本身不提供“连接失败告警”功能，必须靠日志 + 外部脚本 + 阈值判断来实现；核心监控目标是错误日志里的 Access denied 条目，而非 general_log 或 performance_schema。
为什么只盯错误日志里的 Access denied
MySQL 的 general_log 记录所有连接（含成功），但体积大、性能开销高，且无法区分“拒绝”和“超时”；performance_schema.threads 只反映当前活跃连接，失败连接根本不会出现在那里。真正可靠、轻量、默认开启的信号，只有错误日志中反复出现的 Access denied for user 'xxx'@'yyy' —— 它明确表示权限校验失败，是暴力破解或配置错误的第一手证据。
常见错误现象：
- 脚本扫描
general_log发现大量Connect，却无法判断哪些是失败的 - 查
information_schema.processlist返回空，误以为“没人在连”，其实失败连接早被丢弃了 - 用
SHOW VARIABLES LIKE 'max_connect_errors'查到值是 100，但这个参数只影响单个 IP 的临时封禁，不记录、不告警、不汇总
如何定位并提取有效的 Access denied 日志条目
先确认错误日志路径：SHOW VARIABLES LIKE 'log_error';。典型输出是 /var/log/mysql/error.log 或 /var/lib/mysql/hostname.err。不要依赖 mysqld --help --verbose | grep "log-error"，它可能显示默认值而非实际生效路径。
关键操作：
- 用
grep -i "access denied" /var/log/mysql/error.log | tail -20快速验证日志是否真在记录失败事件 - 注意时间格式：MySQL 8.0+ 错误日志默认带 ISO 时间戳（如
2026-04-17T15:22:33.123456Z），用date +%Y-%m-%dT%H:%M匹配更准，别用老式%b %d %H:%M - 过滤掉误报：有些中间件（如 ProxySQL）会伪造
Access denied，需结合HOST字段判断来源是否真实客户端，例如排除'proxy'@'127.0.0.1'
用 Shell 脚本实现分钟级失败次数统计与告警
把日志分析变成 cron 任务，核心逻辑是“按 IP 统计最近 60 秒内失败次数”。以下为可直接部署的片段（假设日志路径为 /var/log/mysql/error.log）：
#!/bin/bash
LOG="/var/log/mysql/error.log"
THRESHOLD=5
WINDOW="60 seconds ago"
<h1>提取最近 60 秒内的 Access denied 行，并提取 IP（来自 @ 后面的地址）</h1><p>SUSPICIOUS=$(grep -i "access denied" "$LOG" | \
awk -v date_cmd="date -d '$WINDOW' '+%Y-%m-%dT%H:%M'" \
'$0 ~ date_cmd {match($0, /@[^)]+/); if (RSTART) print substr($0, RSTART+1, RLENGTH-1)}' | \
sort | uniq -c | awk -v t="$THRESHOLD" '$1 > t {print $2}')</p><p>if [ -n "$SUSPICIOUS" ]; then
echo "ALERT: IPs with >$THRESHOLD failed logins in last minute: $SUSPICIOUS" | \
mail -s "MySQL Auth Flood Alert" admin@example.com
fi</p>
注意事项：
- 别用
tail -n 1000简单截取——日志轮转后可能漏掉关键段；必须用时间戳过滤 -
awk中的正则/@[^\)]+/是为兼容 IPv6（如@'[::1]'）和带端口的 host（如@'192.168.1.100:54321'），比单纯切字段更鲁棒 - 邮件告警只是起点，生产环境应接入
curl调用企业微信/钉钉机器人，或写入syslog供 ELK 收集
如何避免误触发和漏报
阈值设成 5 次/分钟看似合理，但实际要结合业务调整。比如运维批量重置密码时，所有客户端会在几秒内重连，必然触发告警。此时需加白名单机制：
- 在脚本开头加入静态白名单检查：
echo "$SUSPICIOUS" | grep -vE "(10\.0\.0\.5|192\.168\.1\.100)" - 对已知合法跳板机 IP，直接跳过统计，不参与阈值判断
- 若使用 fail2ban，确保其
mysql-auth.conf的findtime和脚本窗口一致（都设为 60 秒），否则两者统计口径错位 - MySQL 8.0+ 的
caching_sha2_password插件会导致老客户端反复失败，这类问题应归类为“兼容性故障”，而非安全事件，需单独识别关键字Client does not support authentication protocol
最易被忽略的一点：错误日志默认不记录完整 IP，当 MySQL 配置了 skip-name-resolve，HOST 字段就是纯 IP；但若没关 DNS 解析，它可能显示主机名（如 user@'web01.example.com'），这时脚本里的 IP 提取逻辑会失效——务必先确认你的 MySQL 是否启用了 skip-name-resolve。
