日志文件定位与路径配置

日志文件在哪儿？这个问题听起来简单，但实际巡检脚本里，八成以上的坑都跟路径有关。我刚开始写审计日志脚本时，直接把路径写死在变量里，结果换了个服务器环境就跑不动了——嗯，现在想想，这事其实有更稳妥的解法。

路径配置的两种模式

日常工作中，日志文件的位置无外乎两类：

• 系统默认路径：比如 /var/log/ 下的 auth.log、secure、messages。不同发行版有差异，但大方向固定。
• 自定义路径：业务应用、自建中间件、微服务容器，日志很可能丢在 /data/logs/ 或 /app/xxx/logs/ 下。

我个人习惯把两者放在不同的配置层里处理。系统日志直接写通用路径，自定义日志用外部配置文件驱动。这样一来，脚本换环境时只需要改一个地方。

用变量而不是硬编码

你想想看，假如在脚本里写了二十处 /var/log/secure，突然要改成 /var/log/auth.log，难道要一行一行改？

所以我在脚本开头统一定义一组路径变量：

# 日志根目录
LOG_ROOT="/var/log"

# 系统审计日志文件
SYS_AUTH_LOG="${LOG_ROOT}/secure"
SYS_MSG_LOG="${LOG_ROOT}/messages"

# 应用日志目录（可外部覆盖）
APP_LOG_DIR="/data/logs/myapp"
APP_LOG_FILE="${APP_LOG_DIR}/app_audit.log"

这样做的好处是，后续所有逻辑都引用变量名。就算换机器，只要把头部几行改掉，整个脚本就适应了。我曾经见过一个同事把路径散落在二三十个函数里，最后改到崩溃——说白了，变量就是你的路径管理 API。

动态探测日志路径

还有一种更“野”的做法：让脚本自己去猜路径。为什么需要这样？因为同一份脚本要在多台机器上跑，每台机器的日志位置可能不同。我写过一个巡检脚本，在几十台服务器上部署，每台机器的auth.log位置都不一样，于是用了这套逻辑：

# 动态定位认证日志
if [ -f "/var/log/secure" ]; then
    AUTH_LOG="/var/log/secure"
elif [ -f "/var/log/auth.log" ]; then
    AUTH_LOG="/var/log/auth.log"
else
    echo "错误：找不到认证日志文件，请检查系统配置。"
    exit 1
fi

这方法简单粗暴，但有效。不过要注意，你只能用在确定不会出现歧义的场景里。比如系统日志，不同发行版只会存在其中一个，不会同时存在两个。如果两个文件都出现了（比如你手动创建过），那脚本可能拿到错误的那一个——我会在探测后加一行ls -l验证。

路径配置的外部化

当脚本需要交付给团队使用时，把所有路径放到一个独立的配置文件里，比写在脚本主体中更干净。我通常的做法是：

1. 创建一个 audit_log_config.sh 文件，里面只放路径变量和选项。
2. 在脚本主体头部用 source 或 . 引入这个配置。
3. 配置文件中提供明确的注释，说明每个变量的用途和默认值。

# audit_log_config.sh 示例
# 系统日志根目录
SYS_LOG_DIR="/var/log"

# 应用日志目录（部署时按需修改）
APP_LOG_DIR="/data/apps/logs"

# 巡检天数范围
DAYS_AGO=1

# 是否启用压缩日志扫描（true/false）
SCAN_COMPRESSED="false"

你可能会问，为什么不直接放在 yaml 或 json 里？说实话，Shell 脚本里用 source 加载纯 shell 变量文件是最轻量的方案，没有解析开销，也不需要额外工具。但要注意，配置文件里不能有可执行代码，只做变量声明——这是一个安全红线。

路径中的通配符与 glob 扩展

很多时候日志按日期滚动，比如 app-2025-04-07.log。如果要在脚本里匹配最近几天的日志，可以用日期变量拼接文件名。但在查找时，我喜欢用 find 命令替代 ls 或通配符，因为它更稳定且支持时间过滤：

# 查找最近7天的日志文件
find "${LOG_DIR}" -name "*.log" -mtime -7 -type f

注意，路径变量如果不加双引号，遇到空格或特殊字符就会裂开。这个坑我踩过不止一次——日志文件名里有空格，脚本瞬间报错。所以所有路径变量引用时都要用双引号包住。

混合路径的处理

有的系统会把日志放在远程挂载点或符号链接指向别处。做路径配置时最好先确认真实路径，避免因为链接断掉而拿到空文件。我建议在脚本初始化阶段做一个简单的可达性检查：

for path in "${SYS_AUTH_LOG}" "${APP_LOG_DIR}"; do
    if [ ! -d "$(dirname "$path")" ]; then
        echo "警告：目录 $(dirname "$path") 不存在，请检查路径配置。"
    fi
done

这样一来，脚本在正式巡检前就能暴露路径问题，而不是运行时才出错——提前止损，比事后排查省心得多。

路径配置的验证策略

配置加好了，不代表一定能用。我遇到过一种情况：路径在配置文件里写了，但对应的目录根本没挂载。所以脚本启动时最好做一次轻量验证，比如：

• 检查目录是否存在（test -d）
• 检查文件是否可读（test -r）
• 检查路径是否是一个常规文件（test -f），避免误认设备文件或管道

你可以把这些检查放在一个函数里，统一调用：

validate_log_path() {
    local path="$1"
    local label="$2"
    if [ ! -e "$path" ]; then
        echo "[WARN] ${label}: $path 不存在"
        return 1
    fi
    if [ ! -r "$path" ]; then
        echo "[WARN] ${label}: $path 不可读，需检查权限"
        return 1
    fi
    echo "[OK] ${label}: $path"
    return 0
}

# 调用示例
validate_log_path "${AUTH_LOG}" "系统认证日志"

这个函数返回非 0 状态码后，脚本可以选择跳过该日志源或直接退出。我个人倾向跳过并记录警告，因为其他日志源可能还能正常工作。但如果是核心审计日志（比如 secure），那我会直接中止——毕竟没有它，巡检等于废了一半。

关于路径的常见误区

最后一点建议