### [雨云集中日志实战：rsyslog 多机日志收拢排查提速](https://www.jiyueip.com/article/12417)

**Published:** 2026-07-28T12:55:16

**Author:** 斑斓助理

**Excerpt:** 在雨云 VPS 上用 rsyslog 把多台机器的系统日志、SSH 与 Nginx 错误集中收集到日志机，走内网 VPC 转发避坑，配合 Netdata 监控补齐排障链路，并划清个人信息保护合规边界。

多台雨云VPS跑起来之后，日志散在每台机器上是最耽误事的一件事。上次一台美国VPS半夜被扫端口，我得挨台登上去翻 `/var/log`，等定位到来源已经过了半小时。后来我把所有机器的日志用 rsyslog 收拢到一台日志机，再把关键项接进看板，排查时间直接砍掉一大半。这篇就讲我是怎么在雨云上搭这套集中日志的，以及踩过的坑。

## 为什么要在雨云上做集中日志

单台机器看日志靠 `tail -f` 和 Netdata 的实时指标（我之前写过一篇[《雨云VPS装Netdata实时看板》](https://www.jiyueip.com/article/12411)）就够了，但机器一多就乱：

-   一台 Web 报 502，你不知道是上游应用崩了，还是数据库那台的连接被打满，两台日志各看各的很难串起来；
-   SSH 暴力破解的尝试分布在三四台机器，单看毫无规律，收拢后能立刻看出是同一批 IP 在扫；
-   OOM、磁盘写满这类问题往往先在某一台上冒头，等蔓延到其他机器再看就已经晚了。

所以集中日志的本质不是”存起来”，而是把**跨主机的因果链**拼出来。这也是它和监控指标最大的区别：Netdata 告诉你”现在很卡”，日志告诉你”为什么卡、谁干的”。

## 架构怎么选：推还是拉

雨云上我试过两种摆法，最后用的是**推模式（rsyslog 客户端转发）**，原因是简单、宕机影响面小。

推模式：每台业务机装 rsyslog，把 `/var/log/auth.log`、`/var/log/syslog`、`/var/log/nginx/error.log` 转发到一台专门的日志机。业务机挂了不影响其他机器，最多丢了那一台的日志。

拉模式（比如 Filebeat 去那边抓）：中心节点要能访问每台机器，权限和防火墙都更麻烦，机器一多中心很容易成为瓶颈。

如果你机器数在十台以内，推模式足够。再多建议上 Loki 这类带索引的方案，不过那属于另一个量级，本文先不展开。

## 动手：日志机先就位

挑一台配置不用太高的机器当日志机，我用的就是雨云香港节点的一台小规格 VPS，免备案、对外带宽稳，平时 CPU 占用几乎可以忽略。

关键点：**日志机和业务机尽量走内网，不要走公网转发 514 端口**。雨云有[内网互联和私有网络（多台机器组 VPC）](https://www.jiyueip.com/article/7648)，同区域机器之间内网互通、不占公网流量也不暴露端口，安全性和成本都更好。跨区域的机器如果只能走公网，务必用 TLS 加密转发，别明文把日志甩到互联网上。

日志机上的 rsyslog 开一个接收模块即可（imtcp 或 imudp），把收到的日志按主机名分目录落盘，后面排查时直接 `grep` 对应主机名就行。

## 业务机：把日志推出去

每台业务机改 rsyslog 配置，加一条转发规则，把需要的日志发往日志机的地址。auth、syslog、Nginx 错误这三个是我必转的，基本覆盖了安全、系统和 Web 三类问题。

转之前我习惯先在业务机上本地留一份，再做远程转发——双保险，日志机万一维护，本地还能查。宝塔和 1Panel 面板的机器也一样，面板的操作日志在各自目录，想收也可以额外加规则，不冲突。

有个细节容易漏：转发规则写好后要 `restart` rsyslog，别只 `reload`，部分老旧版本 reload 不重新加载远程目标。

## 收拢之后，我看什么

日志进了一处，真正省时间的是这几类查询：

-   **SSH 登录**：把 `auth.log` 里 `Failed password` 和 `Accepted` 按来源 IP 聚合，哪台被扫得凶一目了然，比单台看[那篇 SSH 安全加固教程](https://www.jiyueip.com/article/8536)讲的 SSH 加固告警更全局；
-   **Nginx 5xx**：哪台、哪个 upstream 在持续报错，直接定位是应用挂了还是后端连不上；
-   **OOM**：搜 `Out of memory`，看是被谁吃掉的，结合 Netdata 的内存曲线能确认是不是 slowly leak。

我把这几个维度做成了几个简单看板卡片，每天扫一眼就行，不用再登每台机器。

## 合规边界要画清楚

日志里会带用户名、来源 IP、访问路径这些信息，属于《个人信息保护法》管的范畴，集中存放更得注意：

-   日志机只放运维需要的系统日志，不收业务数据库里的用户明文数据；
-   按《数据安全法》做访问控制，日志机不对外开放查询端口，只在内网或跳板机可达；
-   留存周期设上限，过期清掉，不无限堆积；
-   用途限定在故障排查和安全审计，不把日志能力用于突破国家网络管控，也不对外提供扫描类服务。

香港、美国节点虽然免备案，但该守的合规底线一样要守。

## 几个我踩过的坑

-   **时区不一致**：业务机有的是 UTC 有的是 CST，日志对不上时间线。统一设成同一时区，或者在转发时打上机器本地时间戳并标注主机名；
-   **硬盘写爆**：日志机磁盘小，不轮转很快满。配好 `logrotate`，按大小切分、保留 N 份；
-   **514 端口暴露**：一开始图省事走公网明文，被扫了一波。后来全部切到内网 VPC，公网只留必要端口；
-   **重复日志**：某台机器既本地留又转发，日志机里出现两份。检查业务机是不是 `*.` 全量转发又叠加了模块重复发送，收窄规则即可。

## 适合从哪开始

不用一步到位。先挑两台机器 + 一台日志机把链路跑通，确认能收到、能搜到，再逐步把其他机器接进来。等稳定了，再把 SSH 登录异常、5xx 错误这类高频项做成看板。等机器规模再上一个台阶，再考虑 Loki 这类带标签索引的方案。

如果你还没在雨云上开机器，香港、美国节点免备案、带宽稳、价格也便宜，做日志机和业务机性价比都高，用[雨云优惠码 admin01 五折](https://www.jiyueip.com/link/5617)新开几台小规格先试这套架构最划算。

**Tags:** 云服务器, 建站教程, 网站运维, 雨云, 雨云优惠码

**Categories:** 行业洞察

---