返回列表

阿里云代充阿里云服务器日志管理方法

阿里云国际 / 2026-04-17 13:20:14

各位在阿里云上跑业务的朋友们，有没有过这种深夜三点的绝望时刻——

网站突然502，你火速登录ECS，tail -f /var/log/nginx/error.log，结果终端刷出一串「No such file or directory」？
再ls -lh /var/log/nginx/一看：好家伙，error.log.1.gz到.37.gz整整齐齐排成一列，而error.log本身空得能养鱼；
磁盘使用率98%，df -h一敲，/var/log 下躺着三个G的audit.log-20240412，还是七天前的；
你想重启rsyslog，发现它早被你上周“临时注释掉”后忘恢复了……

别慌。这不是玄学，是日志管理没跟上业务节奏。今天咱不讲虚的，就掏心窝子聊聊阿里云ECS上那点「日志江湖事」——怎么收、怎么存、怎么查、怎么甩包袱，全程实操，带梗不带AI味。

一、先搞清：你的日志，到底住在哪几栋楼？

阿里云ECS本身不生产日志，但它是所有日志的「合租公寓」。常见日志按来源分三类：

系统级：/var/log/messages（通用系统事件）、/var/log/secure（SSH登录审计）、/var/log/audit/（SELinux审计，若启用）；
服务级：Nginx的/var/log/nginx/*.log、Apache的/var/log/httpd/*.log、MySQL的/var/log/mysqld.log；
应用级：Java应用的logs/catalina.out、Python Flask的app.log——这个最野，全看开发者心情往哪写。

⚠️重点提醒：阿里云ECS默认不开启日志远程传输，所有日志乖乖躺在本地磁盘里。所以「本地存多久」「存不下怎么办」，是你必须亲手定的家规。

二、救命三板斧：查、压、删

第一斧：查得快
别总cat全量日志！记住这组黄金组合：

# 查最近100行错误（Nginx）
tail -100 /var/log/nginx/error.log | grep "ERROR\|50[0-9]"

# 按时间范围筛（比如查昨天14:00-15:00的访问）
sed -n '/24\/Apr\/2024:14:/,/24\/Apr\/2024:15:/p' /var/log/nginx/access.log

# 实时盯梢并高亮关键词（再也不用瞪眼找）
tail -f /var/log/messages | grep --color=always -i "fail\|panic\|oom"

第二斧：压得稳
日志不是越原始越好，是越易读越省空间越好。Linux自带logrotate就是干这个的。以Nginx为例，编辑/etc/logrotate.d/nginx：

/var/log/nginx/*.log {
    daily                    # 每天轮转一次
    missingok                # 日志文件不存在也不报错
    rotate 30                # 保留30个归档
    compress                 # 用gzip压缩旧日志
    delaycompress            # 压缩上上轮（留最新一轮明文方便查）
    notifempty               # 空文件不轮转
    create 644 nginx nginx   # 新日志权限和属主
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 `cat /var/run/nginx.pid`
        fi
    endscript
}

💡小知识：kill -USR1是Nginx的「优雅切日志」信号，比kill -HUP更精准，不中断连接。

第三斧：删得准
别手欠rm -rf /var/log/*！真这么干，第二天journalctl直接罢工。安全清理姿势：

清journalctl（systemd日志）：journalctl --disk-usage看占多少 → journalctl --vacuum-size=200M（只留200MB）；
清旧归档：find /var/log -name "*.log.*.gz" -mtime +90 -delete（删90天前的压缩包）；
清大文件（慎用）：find /var/log -size +100M -exec ls -lh {} \;定位后手动处理。

附赠一个「防手抖」脚本（存为/usr/local/bin/clean-logs.sh）：

#!/bin/bash
# 阿里云ECS日志温和清扫员
echo "【开始清理】$(date)"
echo "→ 清理journal日志..."
journalctl --vacuum-size=100M >/dev/null 2>&1

echo "→ 清理7天前Nginx归档..."
find /var/log/nginx -name "*.log.*.gz" -mtime +7 -delete 2>/dev/null

echo "→ 清理30天前系统归档..."
find /var/log -name "*.log.*.gz" -mtime +30 -delete 2>/dev/null

echo "→ 当前磁盘使用：$(df -h / | awk 'NR==2 {print $5}')"
echo "【清理完毕】"

加进crontab：0 2 * * * /usr/local/bin/clean-logs.sh >/var/log/clean-logs.log 2>&1，凌晨两点自动干活，你睡得香。

三、进阶方案：从「本地小仓库」到「云端情报中心」

如果公司上了规模，或者你负责的是核心业务，光靠本地轮转远远不够。推荐三套进阶打法：

① rsyslog + 远程日志服务器（适合中小团队）
在ECS上装rsyslog（CentOS 7+默认有），改/etc/rsyslog.conf末尾加：

*.* @your-log-server-ip:514  # UDP传输（更轻量）
# 或 *.* @@your-log-server-ip:514  # TCP（可靠但稍重）

重启systemctl restart rsyslog，所有系统日志自动飞走。优点：零成本、配置简单；缺点：需自建日志服务器，无搜索分析能力。

② 阿里云SLS日志服务（强烈推荐！）
开通SLS控制台 → 创建Project → 创建Logstore → 安装Logtail（阿里云官方采集器）。一行命令搞定：

wget http://logtail-release-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/linux64/logtail.sh
sudo sh logtail.sh install cn-hangzhou  # 替换为你所在地域

然后在SLS控制台勾选「采集Nginx日志」「采集系统日志」，填路径、选分隔符、预览解析效果——5分钟内，error.log里的每条报错都变成可检索、可图表、可告警的结构化数据。我们团队用它把故障定位时间从45分钟缩短到3分钟，老板说这钱花得比咖啡还值。

③ ELK Stack（适合技术控/重度定制需求）
Elasticsearch + Logstash + Kibana，自由度最高，但部署维护成本也最高。建议：除非你团队有专职SRE，否则优先选SLS——毕竟人家连「SQL查询日志」、「异常IP聚类」、「慢SQL自动标红」都给你焊死了。

四、血泪教训：那些年我们踩过的日志坑

• 坑一：logrotate配了daily，但忘记reload cron
改完配置不systemctl reload crond，等于白写。建议改完立刻logrotate -d /etc/logrotate.conf（dry-run模式测试）。

• 坑二：Java应用狂打catalina.out，没做切割
Tomcat默认不轮转stdout，一个上线活动就能冲爆磁盘。解决方案：在conf/logging.properties里启用FileHandler，或用logback-spring.xml配<rollingPolicy>。

阿里云代充 • 坑三：SLS Logtail采集失败，却以为是网络问题
真实原因：ECS安全组没开10010/udp端口（Logtail心跳端口）！记得在阿里云控制台安全组里放行。

最后送大家一句运维箴言：日志不是用来攒的，是用来读的；不是用来占磁盘的，是用来救火的。管好日志，你离「故障秒级响应工程师」，就差一个logrotate配置和一杯续命咖啡的距离。