企业官网建设流程全解析

1. Linux服务器健康监控概述

作为运维工程师，我们每天都要面对数十甚至上百台Linux服务器的运行状态监控。记得去年我们一个核心业务服务器突然负载飙升到50+，整个业务几乎瘫痪，排查后发现是某个日志文件疯狂增长占满了磁盘空间。这件事让我深刻意识到：没有完善的监控体系，就像在黑暗中开车——迟早要出事故。

服务器健康监控不仅仅是简单的"看仪表盘"，而是要从CPU、内存、磁盘、网络、进程等多个维度建立立体化的监控体系。一个成熟的监控方案应该具备以下核心能力：

• 实时性：能秒级发现异常（比如CPU使用率瞬间冲高）
• 全面性：覆盖硬件、系统、应用所有层面
• 预警性：在问题发生前就能发现趋势异常
• 追溯性：可以回放历史数据辅助排查

2. 核心监控指标详解

2.1 CPU监控的艺术

CPU使用率是最容易被误读的指标。很多人看到CPU使用率90%就慌，其实要看具体场景：

# 查看CPU核心数和型号 lscpu # 实时CPU使用率（1秒刷新） mpstat -P ALL 1 # 查看CPU运行队列 sar -q 1 3

关键指标解读：

• us%：用户态CPU时间。如果长期>70%，说明应用计算密集
• sy%：内核态CPU时间。正常应<20%，过高可能系统调用频繁
• id%：空闲时间。低于30%就需要警惕
• wa%：IO等待时间。>30%说明磁盘IO是瓶颈

经验：多核CPU要看单核负载，使用uptime查看1/5/15分钟平均负载，理想值是核心数×0.7

2.2 内存监控的陷阱

free命令的输出经常让人困惑：

free -h total used free shared buff/cache available Mem: 62G 7.2G 512M 1.3G 54G 53G Swap: 4.0G 1.2G 2.8G

重点看available而非free！Linux会主动利用空闲内存做缓存(buff/cache)，这部分内存应用需要时可以立即释放。

内存泄漏排查技巧：

# 按内存使用排序进程 ps aux --sort=-%mem | head # 监控slab内存 cat /proc/meminfo | grep Slab # 追踪内存分配 valgrind --tool=memcheck --leak-check=full ./your_app

2.3 磁盘IO的隐藏杀手

磁盘问题往往最容易被忽视，直到出现故障。推荐监控工具：

# 查看磁盘空间使用 df -Th # 监控磁盘IO（每秒刷新） iostat -xmdz 1 # 查找大文件 find / -type f -size +500M -exec ls -lh {} \;

关键指标：

• %util：设备繁忙百分比。>80%说明IO饱和
• await：IO平均等待时间(ms)。>20ms需要关注
• svctm：IO服务时间。应该<5ms

血泪教训：曾经因为一个开发在/tmp下写日志，导致根分区爆满。现在我们的监控必加/和/tmp分区报警

3. 网络监控进阶技巧

3.1 连接数监控

TCP连接数突然暴涨往往是故障前兆：

# 查看各状态连接数 ss -s # 监控ESTABLISHED连接 watch -n 1 'ss -tn state established | wc -l' # 按IP统计连接数 netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

3.2 带宽监控

iftop是实时带宽监控神器：

iftop -nNP # -n 不解析主机名 # -P 显示端口 # -N 数字格式显示

长期趋势建议用nload：

nload -u M eth0 # 以MB为单位显示eth0流量

4. 企业级监控方案实战

4.1 Prometheus + Grafana方案

这是我们目前生产环境的主力监控方案：

1. 部署Prometheus：

# 下载 wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* # 配置 vi prometheus.yml

2. Node Exporter安装（每台服务器）：

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz tar xvfz node_exporter-*.tar.gz cd node_exporter-* ./node_exporter &

3. Grafana仪表盘配置：

• 导入ID为1860的Node Exporter仪表盘
• 设置告警规则示例：

groups: - name: host_stats rules: - alert: HighCPU expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: "High CPU usage on {{ $labels.instance }}"

4.2 日志监控ELK方案

对于日志集中监控，我们使用：

# Filebeat配置示例 filebeat.inputs: - type: log paths: - /var/log/*.log output.logstash: hosts: ["logstash:5044"]

Logstash处理管道：

input { beats { port => 5044 } } filter { grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{GREEDYDATA:message}" } } } output { elasticsearch { hosts => ["http://elasticsearch:9200"] } }

5. 自动化运维技巧

5.1 监控脚本示例

这个脚本检查关键指标并发送报警：

#!/bin/bash # 阈值配置 CPU_WARN=80 MEM_WARN=90 DISK_WARN=90 # 检查CPU cpu_usage=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}') if (( $(echo "$cpu_usage > $CPU_WARN" | bc -l) )); then echo "CPU报警: 使用率 ${cpu_usage}%" | mail -s "CPU告警" admin@example.com fi # 检查内存 mem_usage=$(free | grep Mem | awk '{print $3/$2 * 100.0}') if (( $(echo "$mem_usage > $MEM_WARN" | bc -l) )); then echo "内存报警: 使用率 ${mem_usage}%" | mail -s "内存告警" admin@example.com fi # 检查磁盘 df -P | grep -v ^Filesystem | awk '{ print $5 " " $1 }' | while read output; do usage=$(echo $output | awk '{ print $1}' | cut -d'%' -f1 ) partition=$(echo $output | awk '{ print $2 }' ) if [ $usage -ge $DISK_WARN ]; then echo "磁盘报警: 分区 $partition 使用率 ${usage}%" | mail -s "磁盘告警" admin@example.com fi done

5.2 定时任务配置

建议将监控脚本加入crontab：

# 每5分钟运行监控 */5 * * * * /path/to/monitor_script.sh # 每天凌晨清理日志 0 0 * * * find /var/log -type f -name "*.log" -mtime +7 -delete

6. 性能优化实战案例

6.1 MySQL性能调优

我们某次优化案例：

-- 慢查询分析 mysqldumpslow -s t /var/log/mysql/mysql-slow.log -- 优化后配置(my.cnf) [mysqld] innodb_buffer_pool_size = 12G # 内存的70% innodb_log_file_size = 2G innodb_flush_log_at_trx_commit = 2 query_cache_type = 0 table_open_cache = 4000

6.2 Nginx调优经验

高并发场景下的关键参数：

worker_processes auto; worker_rlimit_nofile 100000; events { worker_connections 4000; use epoll; multi_accept on; } http { open_file_cache max=200000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; sendfile on; tcp_nopush on; tcp_nodelay on; }

7. 安全监控要点

7.1 登录监控

# 查看失败登录 grep "Failed password" /var/log/auth.log # 监控SSH暴力破解 fail2ban-client status sshd

7.2 文件完整性监控

使用AIDE建立基线：

aide --init mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz aide --check

8. 容器监控特别篇

对于Docker环境：

# 容器资源使用 docker stats --no-stream # 推荐使用cAdvisor docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:ro \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --publish=8080:8080 \ --detach=true \ --name=cadvisor \ google/cadvisor:latest

9. 报警策略设计

合理的报警分级：

• P0（电话报警）：核心业务不可用
• P1（短信报警）：性能严重下降
• P2（邮件报警）：潜在风险
• P3（企业微信）：提示信息

报警收敛策略示例：

def check_alert(metric, threshold, duration): """ metric: 监控指标 threshold: 阈值 duration: 持续时长(分钟) """ abnormal_points = 0 for _ in range(duration): current_value = get_metric(metric) if current_value > threshold: abnormal_points += 1 else: abnormal_points = 0 if abnormal_points >= 3: # 连续3次超标才报警 send_alert(f"{metric} 持续高于 {threshold}") break

10. 监控体系演进路线

根据业务规模推荐方案：

1. 初创阶段：Shell脚本 + crontab + 邮件报警
2. 成长阶段：Prometheus + Grafana + Alertmanager
3. 成熟阶段：多集群Thanos + 日志中台 + 智能告警
4. 超大规模：自研监控平台 + AIOps异常检测

监控系统建设要遵循"够用就好"原则，避免过度设计。我们曾经花费三个月搭建完美的监控系统，结果维护成本比解决的问题还多。现在采用渐进式演进策略，每个阶段只解决当前最痛的痛点。