如何用Syslog进行系统性能监控

系统性能监控这事儿，说难不难，说简单也不简单。真正让很多运维朋友头疼的，不是监控本身，而是怎么把零散的日志数据串联起来，形成一套可持续的分析闭环。Syslog作为Linux系统里最基础的日志服务，其实完全可以承担起性能数据采集和上报的职责。关键就看你怎么用它——配置得当，它就是一套轻量级的性能监控方案。

一提到用Syslog做性能监控，很多人可能第一反应是：这不就是个日志收集器吗？没错，但它的潜力远不止于此。从数据采集到结构化存储，再到可视化呈现和告警触发，完全可以一条龙搞定。下面我们就一步步拆开来看。

一、前置准备：让Syslog先“听得懂”性能日志

要让Syslog成为性能监控的数据源，首先得确保它能收到并处理性能相关的日志。以Linux上最常见的rsyslog为例，有两件事需要先办好。

开启远程日志接收这一步可选，但强烈推荐。尤其是当你需要监控多台机器的时候，总不能让每台机器都各自为战。配置方法很简单，修改/etc/rsyslog.conf或/etc/rsyslog.d/50-default.conf，取消下面几行的注释（没有就自己加上）:

module(load="imudp")        # 加载UDP模块
input(type="imudp" port="514")  # 开启UDP 514端口监听
module(load="imtcp")        # 如果需要更可靠，加一个TCP模块
input(type="imtcp" port="514")  # TCP监听也开起来

保存后别忘了重启服务：sudo systemctl restart rsyslog。

定向性能日志到独立文件这一步是为了不让性能日志跟系统日志混在一起。创建自定义配置文件，比如/etc/rsyslog.d/performance.conf，通过关键字过滤出与性能相关的日志，写到独立的文件里。比如：

:msg, contains, "CPU usage" -/var/log/cpu_usage.log
& stop
:msg, contains, "Memory low" -/var/log/memory_alert.log
& stop
:msg, contains, "Disk I/O error" -/var/log/disk_io_error.log
& stop

同样，改完重启rsyslog使其生效。

二、采集关键性能指标：把数据“喂”给Syslog

配置好Syslog之后，接下来的问题就是：性能数据从哪里来？答案是自己动手写脚本。通过logger命令，脚本可以把采集到的性能数据以Syslog格式发送到服务器。

CPU使用率用top或/proc/stat获取CPU利用率，设定一个阈值，超过就发告警。脚本示例如下（保存为/usr/local/bin/cpu_monitor.sh）：

#!/bin/bash
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}')
THRESHOLD=80
if (( $(echo "$CPU_USAGE > $THRESHOLD" | bc -l) )); then
    logger -t CPU_MONITOR "CPU usage is high: ${CPU_USAGE}% (Threshold: ${THRESHOLD}%)"
fi

再通过crontab设置定时任务，比如每5分钟跑一次：*/5 * * * * /usr/local/bin/cpu_monitor.sh。

内存占用类似，用free命令获取内存使用率：

#!/bin/bash
MEM_USAGE=$(free | grep Mem | awk '{print $3/$2 * 100.0}')
THRESHOLD=90
if (( $(echo "$MEM_USAGE > $THRESHOLD" | bc -l) )); then
    logger -t MEMORY_MONITOR "Memory usage is high: ${MEM_USAGE}% (Threshold: ${THRESHOLD}%)"
fi

磁盘I/O则需要用iostat（来自sysstat包）：

#!/bin/bash
IO_WAIT=$(iostat -c 1 2 | tail -1 | awk '{print $4}')
THRESHOLD=20
if (( $(echo "$IO_WAIT > $THRESHOLD" | bc -l) )); then
    logger -t DISK_MONITOR "Disk I/O wait is high: ${IO_WAIT}% (Threshold: ${THRESHOLD}%)"
fi

这样，性能数据就会以Syslog的格式乖乖进入你在第一步配置好的日志通道里。

三、日志解析与存储：把文本变成可分析的结构化数据

原始的Syslog日志说到底还是纯文本，要真正做分析，还得解析成结构化的格式，比如JSON。这一步有不少现成的工具可以帮忙。

rsyslog内置过滤可以在performance.conf中进一步解析日志：

if $msg contains "CPU usage is high" then {
    action(type="mmjsonparse")
    action(type="omfile" file="/var/log/structured_performance.log" template="RSYSLOG_TraditionalFileFormat")
    stop
}

这样符合条件的日志就会被转为JSON格式存下来。

ELK Stack无疑是更成熟的方案。Logstash作为日志收集器，配合正则解析可以提取出你关心的字段：

input {
    syslog {
        port => 514
        type => "syslog"
    }
}
filter {
    if [type] == "syslog" {
        grok {
            match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{DATA:program}\[%{POSINT:pid}\]: %{GREEDYDATA:message}" }
        }
        if [message] =~ /CPU usage/ { mutate { add_tag => ["cpu_perf"] } }
        if [message] =~ /Memory low/ { mutate { add_tag => ["memory_perf"] } }
    }
}
output {
    elasticsearch {
        hosts => ["localhost:9200"]
        index => "syslog-performance-%{+YYYY.MM.dd}"
    }
    stdout { codec => rubydebug }
}

数据进入Elasticsearch后，Kibana就可以派上用场了。创建索引模式syslog-performance-*，然后在Discover里查看日志，或者用Visualize构建仪表板——比如CPU使用率趋势图，是一目了然的。

四、可视化与告警：让监控从“有数据”变成“有用”

数据有了，结构化了，那接下来就是让它真正发挥作用。

可视化方面，Kibana的Dashboard可以展示CPU使用率、内存占用的时间序列图，还支持按主机名筛选钻取。Grafana搭配Elasticsearch或Prometheus数据源，能做出更丰富的仪表板，比如磁盘I/O负载热力图。

告警方面，Elasticsearch的Watcher可以配置定时查询，发现异常就发邮件。比如下面这个配置，每5分钟检查一次是否有CPU过高的告警日志：

PUT _watcher/watch/cpu_high_alert
{
  "trigger": { "schedule": { "interval": "5m" } },
  "input": {
    "search": {
      "request": {
        "indices": ["syslog-performance-*"],
        "body": {
          "query": {
            "bool": {
              "must": [
                { "match": { "message": "CPU usage is high" } },
                { "range": { "@timestamp": { "gte": "now-5m" } } }
              ]
            }
          }
        }
      }
    }
  },
  "actions": {
    "email_alert": {
      "email": {
        "to": "admin@example.com",
        "subject": "CPU High Usage Alert",
        "body": "CPU usage is high on {{ctx.payload.hits.hits._source.hostname}}: {{ctx.payload.hits.hits._source.message}}"
      }
    }
  }
}

当然，如果你已经在用Nagios或Zabbix这些传统监控工具，它们也能直接读取Syslog日志或采集/proc/stat来触发告警。选择哪种方案，取决于你现有的基础设施和团队习惯。

五、优化与维护：让这套方案持续可用

方案搭起来之后，有没有什么坑需要注意？当然有。三个点值得盯紧。

日志轮转一定要配置好。性能日志如果放任自流，一个月就能吃掉几个GB的磁盘。用logrotate可以轻松搞定：

/var/log/cpu_usage.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

日志级别要合理设置。无关的debug日志会冲淡性能数据，可以调整rsyslog的全局级别为warning，只记录警告及以上级别的日志：

.=warning;.=err;.=crit;.=alert;.=emerg /var/log/syslog
& ~

定期审查规则也很重要。业务量上去了，阈值可能需要调整——比如CPU阈值从80%改到70%；基础设施变了，过滤规则可能也需要更新——比如新增“Disk space low”的过滤条件。别嫌麻烦，监控方案必须与时俱进才能保持有效。

说到底，Syslog做性能监控这条路并不复杂，但每一步都需要认真对待。从底层配置到上层可视化，再到持续维护，任何一个环节掉链子，都可能让整套方案大打折扣。而一旦走通，你就能以极低的成本建立起一套真正可用的性能监控体系。