如何定期检查Ubuntu backlog

定期检查 Ubuntu Backlog 的实用方案

一、先明确 Backlog 类型

• 系统日志积压：journald/rsyslog 中未及时轮转或查询缓慢导致的“堆积感”。
• 网络连接 Backlog：监听套接字的未完成连接队列（半连接 SYN 队列、全连接 accept 队列），关注 Recv‑Q 与内核参数。
• 任务计划 Backlog：Cron/at 任务未执行或失败堆积。
• 打印队列 Backlog：打印机等待处理的文档队列。
• 软件包更新 Backlog：可升级软件包列表的积压。
• 应用队列 Backlog：如 Postfix 邮件队列、MySQL 进程/慢查询积压。
  以上类型与对应检查命令见下文速查表与示例。

二、速查表

三、命令行快速检查示例

• 查看各监听端口的当前接收队列（Recv‑Q）与内核上限
  • 查看监听套接字与队列：ss -lnt
  • 查看系统最大监听队列：cat /proc/sys/net/core/somaxconn
  • 查看 SYN 队列上限：sysctl net.ipv4.tcp_max_syn_backlog
• 查看系统日志与服务日志的近期错误
  • 本次启动日志：journalctl -b
  • 实时跟踪服务日志：journalctl -u nginx -f
  • 近期错误概览：journalctl -xe
• 查看 Cron 执行情况
  • 当前用户任务：crontab -l
  • 系统级任务：cat /etc/crontab；ls /etc/cron.d/
  • 服务状态与日志：systemctl status cron；grep CRON /var/log/syslog
• 查看应用队列
  • Postfix：postqueue -p
  • MySQL：mysql -e “SHOW PROCESSLIST”
    以上命令覆盖系统日志、网络、任务计划与应用队列的常用检查路径。

四、设置定期检查与告警

• 使用 Cron 做周期性巡检（示例）
  • 每小时检查关键服务的 Recv‑Q 是否接近上限（需根据实际端口与阈值调整）：

    # crontab -e
    0 * * * * /usr/bin/ss -lnt | awk 'NR>1 {if($2>800) printf "WARN: %s Recv-Q=%s\n", $4, $2}' | mail -s "High TCP backlog" admin@example.com
    

  • 每天检查可升级软件包数量：

    0 2 * * * /usr/bin/apt list --upgradable | wc -l | mail -s "Daily upgradable packages count" admin@example.com
    

• 使用 Prometheus + Alertmanager 做可视化与阈值告警
  • 以 node_exporter 的 textfile 收集器或自定义脚本导出指标（如 backlog_queue_length），在 Prometheus 配置告警：

    groups:
    - name: backlog
      rules:
      - alert: HighBacklog
        expr: backlog_queue_length > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "High backlog detected"
          description: "The backlog queue length has exceeded the threshold."
    

  • Alertmanager 负责去重、分组与通知（邮件/企业微信/钉钉等）。
    以上给出基于 Cron 与 Prometheus 的两种落地方式，可按环境选择其一或组合使用。

五、发现异常时的处置要点

• 网络 Backlog 持续增长
  • 检查应用并发/处理能力（worker 数、线程池、慢请求）；必要时优化应用或扩容。
  • 适度调大内核/服务队列：sysctl -w net.core.somaxconn=1024；并在服务配置中同步增大 backlog（如 Nginx worker_connections、listen backlog=…）。
• 系统日志积压
  • 先定位错误源（journalctl -xe、服务日志），再修复根因；必要时扩容磁盘或优化日志级别与保留策略。
  • 使用 journald 管理日志体积：journalctl --vacuum-time=7d 或 --vacuum-size=500M；并确保 logrotate 正常运行（/etc/cron.daily/logrotate）。
• 任务计划/应用队列
  • Cron：修复失败任务脚本、检查环境依赖与权限；必要时分散任务时间窗。
  • Postfix/MySQL：清理或终止异常/长时间任务，优化查询与索引，检查连接数限制与超时设置。
    上述处置思路涵盖网络、日志与应用层面的常见根因与修复方向。