Linux服务器日志监控实战 Nginx 5xx错误与SSH暴力破解告警配置指南

首页

业界动态

热心网友

转载

2026-05-11

在Linux系统运维工作中，两类典型风险常令管理员倍感压力：一是Nginx服务持续返回5xx服务器错误，直接影响业务可用性，但缺乏即时通知机制；二是服务器SSH端口遭受不明来源IP的持续暴力破解尝试，安全威胁悄然升级。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

面对这类场景，许多工程师的第一选择是部署一套完整的监控系统，例如ELK Stack或Prometheus生态。这无疑是正确的技术方向，但对于业务体量中等、IT资源有限的中小规模环境而言，引入这些“重量级”解决方案的部署复杂度与长期维护成本，有时会超出实际承受能力。

事实上，一套高效、实时的日志监控与告警方案，其核心组件可能早已内置在您的Linux系统中。通过巧妙组合系统原生工具——tail、awk与curl——我们完全有能力构建出一套稳定可靠、响应迅速且资源开销极低的轻量级告警体系。

然而，这里存在一个至关重要的实践提醒：互联网上广泛流传的许多“一键监控脚本”，在架构设计上存在若干典型缺陷，若未经评估直接应用于生产环境，极易引发运维故障。常见的陷阱包括：

管道与子Shell引发的计数丢失：在管道命令链中使用变量进行计数，会因子Shell环境隔离导致数值无法正确累加。
伪“时间窗口”逻辑：大量脚本采用每分钟整点重置计数器的方式，而非基于事件时间的真实滑动窗口，可能造成误报或漏报。
grep缓冲区延迟问题：使用grep命令时若未关闭输出缓冲，日志事件无法被实时捕获和处理，导致告警响应滞后。
日志轮转后监控进程中断：简单的tail -f命令在日志文件发生轮转（rotate）后，可能无法持续跟踪新文件，造成监控盲区。

一、核心设计原则：规避常见陷阱

要构建一个真正可靠的轻量级监控方案，首先必须确立以下核心设计原则，从源头上避免上述问题。

1. 单进程状态管理
所有核心统计逻辑，包括事件计数与时间戳记录，均应集中在awk单个进程内部完成。此举旨在避免在Shell管道中使用多个命令时，因变量作用域隔离而导致状态不一致或丢失。简而言之，就是将数据与处理逻辑置于同一个执行上下文中。

2. 实现真正的滑动时间窗口
告警触发条件应定义为“在过去1分钟的动态时间窗口内，若异常事件超过N次则立即报警”。实现的关键在于“动态滑动”，而非固定间隔重置。技术上，可借助awk的systime()函数获取当前时间戳，并持续清理超过60秒的旧事件记录，以此模拟滑动窗口行为。

3. 降低对日志格式的强依赖
脚本应具备足够的健壮性。针对Nginx访问日志，默认采用标准日志格式，仅需按字段位置获取$1（客户端IP）和$9（HTTP状态码），避免使用复杂且易因日志格式微调而失效的正则表达式匹配。

4. 保持最小化外部依赖
整个方案的核心依赖仅为tail、awk和curl，这些工具在绝大多数Linux发行版中均默认存在，极大保证了方案的可移植性与易部署性。

5. 安全优先原则
脚本中避免使用eval等高危操作；内置IP白名单机制，防止对可信来源误报；在启动阶段对配置的Webhook地址进行基础可用性校验；对关键状态目录设置严格的访问权限。

二、生产环境就绪的监控脚本

请将以下脚本保存为 /usr/local/bin/log-alert.sh，并赋予可执行权限。

#!/bin/bash

# ================= 配置项 =================
NGINX_LOG="/var/log/nginx/access.log"
SSH_MODE="file" # file 或 journald
SSH_LOG="/var/log/secure"
WEBHOOK="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key"
NGINX_THRESHOLD=10
SSH_THRESHOLD=5
SILENT=300
STATE_DIR="/dev/shm/log_alert"
mkdir -p "$STATE_DIR"
chmod 700 "$STATE_DIR"
WHITELIST=("127.0.0.1" "10.0.0.0/8" "192.168.0.0/16")

# ================= 工具检查 =================
for cmd in tail awk curl; do
    command -v $cmd >/dev/null || { echo "缺少依赖: $cmd"; exit 1; }
done

# ================= webhook 校验 =================
resp=$(curl -s --max-time 5 "$WEBHOOK")
echo "$resp" | grep -q '"errcode":0' || {
    echo "Webhook 无效或不可用"
    exit 1
}

# ================= 告警函数 =================
send_alert() {
    local title="$1"
    local content="$2"
    curl -s -o /dev/null -X POST "$WEBHOOK" \
    -H "Content-Type: application/json" \
    -d "{
        \"msgtype\": \"text\",
        \"text\": {\"content\": \"${title}\n${content}\"}
    }" &
}

# ================= 白名单判断 =================
is_white() {
    local ip="$1"
    [[ "$ip" == "127.0.0.1" ]] && return 0
    for w in "${WHITELIST[@]}"; do
        [[ "$ip" == "$w" ]] && return 0
    done
    return 1
}

# ================= NGINX 监控 =================
tail -F "$NGINX_LOG" | awk -v t="$NGINX_THRESHOLD" -v s="$SILENT" '
{
    ip=$1
    code=$9
    now=systime()
    if (code !~ /^5[0-9][0-9]$/) next
    key=ip
    events[key][++cnt[key]]=now
    # 清理旧数据
    for (i in events[key]) {
        if (now - events[key][i] > 60) delete events[key][i]
    }
    n=0
    for (i in events[key]) n++
    if (n >= t && now - last[key] > s) {
        last[key]=now
        print "NGINX|"ip"|"n
        fflush()
    }
}' | while IFS='|' read -r type ip count; do
    is_white "$ip" && continue
    send_alert "Nginx 5xx告警" "IP: $ip\n1分钟: $count 次"
done &

# ================= SSH 监控 =================
if [[ "$SSH_MODE" == "journald" ]]; then
    SRC="journalctl -f _COMM=sshd"
else
    SRC="tail -F $SSH_LOG"
fi

bash -c "$SRC" | grep "Failed password" | awk -v t="$SSH_THRESHOLD" -v s="$SILENT" '
{
    for(i=1;i<=NF;i++){
        if($i=="from"){ ip=$(i+1); break }
    }
    if(ip=="") next
    now=systime()
    key=ip
    events[key][++cnt[key]]=now
    for(i in events[key]){
        if(now - events[key][i] > 60) delete events[key][i]
    }
    n=0
    for(i in events[key]) n++
    if(n >= t && now - last[key] > s){
        last[key]=now
        print "SSH|"ip"|"n
        fflush()
    }
}' | while IFS='|' read -r type ip count; do
    is_white "$ip" && continue
    send_alert "SSH暴力破解告警" "IP: $ip\n失败次数: $count"
done &

wait -n
exit 1

三、配置为Systemd服务实现后台运行

为确保脚本在后台稳定运行，并具备开机自启、故障自动重启等生产级特性，强烈建议将其配置为Systemd服务。创建服务配置文件 /etc/systemd/system/log-alert.service：

[Unit]
Description=Log Alert Service
After=network.target

[Service]
ExecStart=/bin/bash /usr/local/bin/log-alert.sh
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal
NoNewPrivileges=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

配置完成后，执行以下命令启用服务：

sudo systemctl daemon-reload
sudo systemctl enable --now log-alert.service

四、关键实施要点与说明

1. 关于“近似滑动窗口”的实现
本脚本实现的并非精确到毫秒级的时间序列数据库滑动窗口，而是通过每秒清理超时事件来近似模拟。对于运维监控与告警场景——核心目标是快速发现异常趋势，而非进行精确审计——此精度已完全满足需求。

2. 运行时状态存储位置
脚本运行时的状态数据（如上次告警时间戳）存储于/dev/shm目录，该目录为内存文件系统，读写性能极高。请注意，服务器重启后这些状态数据会丢失，此行为符合设计预期，不会影响告警核心功能的正常运行。

3. IP白名单功能说明
脚本提供了基础的IP白名单匹配逻辑。需注意，示例中对CIDR格式（如10.0.0.0/8）的支持仅为简单的字符串匹配，并未实现完整的网络地址计算。在生产环境中，若需严格的CIDR网段匹配，可引入ipcalc工具或扩展脚本逻辑。

4. 对日志格式的依赖性
脚本默认假设Nginx日志为标准格式。如果您的日志格式经过自定义调整，请务必修改awk命令中获取客户端IP（$1）和HTTP状态码（$9）的字段位置索引，否则监控逻辑将无法正确解析日志。

来源:https://www.51cto.com/article/842800.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：中国移动MoMA平台发布AI服务成本降低30%开启智能化新纪元下一篇：千问AI购物助手正式上线淘宝一句话完成逛买售后全流程