手把手教你写日志记录脚本，轻松掌握网络动态

为什么需要自己写日志记录脚本

家里路由器总是在半夜掉线，查来查去没头绪？公司服务器偶尔响应慢，但没人知道具体啥时候出的问题？这时候，光靠设备自带的日志功能可能不够用。系统日志往往只保留最近几条，关键信息一闪而过。与其被动等故障发生，不如主动动手写个简单的日志记录脚本，把你想盯的数据自动存下来。

从最基础的开始：用Shell记录网络连通性

比如你怀疑是宽带不稳定，可以写个脚本每隔一分钟ping一次公网地址，把结果记下来。下面这个小脚本就能实现：

#!/bin/bash
LOGFILE="/home/pi/network_log.txt"
TARGET="8.8.8.8"

while true; do
    timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    if ping -c 1 -W 1 $TARGET > /dev/null 2>&1; then
        echo "$timestamp,UP" >> $LOGFILE
    else
        echo "$timestamp,DOWN" >> $LOGFILE
    fi
    sleep 60
done

保存成 check_network.sh，给它执行权限 chmod +x check_network.sh，再丢进后台运行 nohup ./check_network.sh &，它就会默默帮你记录每一分钟的网络状态。过两天打开 network_log.txt，哪段时间断过一目了然。

进阶一点：用Python记录更丰富的信息

如果你不只想看通不通，还想看延迟、丢包率，甚至把数据写进表格方便分析，Python 更合适。下面这个例子会记录每次ping的延迟值：

import subprocess
import time
import datetime

logfile = open("ping_detail.log", "a")

while True:
    now = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    try:
        result = subprocess.run(
            ["ping", "-c", "1", "-W", "1", "1.1.1.1"], 
            capture_output=True, text=True
        )
        if "time=" in result.stdout:
            # 提取延迟时间
            latency_line = [line for line in result.stdout.split('\n') if "bytes from" in line][0]
            start = latency_line.find("time=") + 5
            end = latency_line.find(" ms", start)
            latency = latency_line[start:end]
            logfile.write(f"{now},UP,{latency}ms\n")
        else:
            logfile.write(f"{now},DOWN,timeout\n")
    except Exception as e:
        logfile.write(f"{now},ERROR,{str(e)}\n")
    
    logfile.flush()  # 立即写入文件
    time.sleep(60)

这段脚本跑起来后，生成的日志不仅有状态，还有具体的延迟数值。拿Excel或WPS打开，画个折线图，网络波动趋势清清楚楚。

别忘了设置开机自启，让它一直跑下去

脚本写好了，不能每次重启都手动开一次。在Linux里可以用 crontab 的 @reboot 实现自动启动。输入 crontab -e，加一行：

@reboot /usr/bin/python3 /home/pi/ping_logger.py

下次开机，脚本自动就跑起来了，真正实现无人值守监控。树莓派接个电源就能当监控小主机用，放在路由器旁边就行。

实际用起来的小建议

日志文件不能无限增长，不然迟早撑爆存储。可以在脚本里加个判断，比如每天生成一个新文件，或者每周轮转一次。也可以配合 logrotate 工具管理。另外，敏感信息别往日志里写，比如密码、密钥，万一文件被别人看到就麻烦了。记录频率也不用太高，一分钟一次足够发现大多数问题，太频繁反而增加系统负担。