919服务器巡检

Linux 业务巡检与监控报警完善方法技巧

一、巡检策略与工具

自动化巡检框架
- 使用 Ansible/SaltStack 编写巡检脚本 - 定时任务结合 Jenkins 实现定期巡检
- 自定义巡检模板（CPU、内存、磁盘、服务状态等）
关键巡检内容
- 系统资源：CPU使用率、内存占用、磁盘空间
- 服务状态：关键进程存活、端口监听
- 日志分析：错误日志扫描、异常登录记录
- 安全检测：未授权访问、可疑进程

二、监控报警体系搭建

监控系统选型
- Zabbix：企业级开源监控方案
- Prometheus + Grafana：云原生监控组合
- Nagios：传统但稳定的监控工具
监控指标完善
- 基础监控：服务器性能指标 - 应用监控：服务响应时间、错误率
- 业务监控：交易量、成功率等核心指标
- 网络监控：延迟、丢包率、带宽使用

三、报警优化策略

分级报警机制
- P0（紧急）：电话+短信+钉钉
- P1（高）：短信+钉钉
- P2（中）：钉钉 - P3（低）：邮件
智能报警优化
- 报警合并：相同类型报警聚合
- 报警抑制：主服务故障时抑制相关子报警
- 智能降噪：设置报警时间段，避免夜间打扰

四、最佳实践

持续优化
- 定期review报警有效性
- 建立报警知识库，完善处理流程
- 模拟故障演练，验证监控覆盖完整性
可视化与报告
- Grafana 大屏展示关键指标
- 定期生成巡检报告
- 趋势分析预测潜在风险

通过以上方法，可构建完善的Linux业务巡检与监控报警体系，确保系统稳定运行。

在Linux环境下，业务巡检与监控报警的核心目标是主动发现风险、快速定位故障、减少业务中断，需从"巡检体系标准化""监控维度全面化""报警策略精细化"三个维度构建方案，以下是具体方法与技巧：

一、Linux业务巡检：从"手动零散"到"自动化标准化"

巡检的核心是覆盖关键维度、减少人为误差、提升效率，需区分"系统层""业务层""数据层""安全层"四大维度，结合"原生工具+自动化平台"实现标准化。

1. 巡检核心维度与关键指标

需明确各维度的"必检项"，避免遗漏核心风险点，具体如下表：

巡检维度	关键指标/检查项	常用工具/命令	风险阈值参考
系统资源层	CPU使用率（ idle% ）	top、vmstat、mpstat	持续5分钟 idle% < 10% 告警
	内存使用率（used%）	free、vmstat、nmon	持续5分钟 used% > 90% 告警
	磁盘使用率（used%）	df -h、iostat、du	分区 used% > 90% 告警（/boot > 80%）
	磁盘IO负载（util%）	iostat -x 1	持续5分钟 util% > 95% 告警
	系统负载（load average）	uptime、top	15分钟 load > CPU核心数*1.5 告警
	进程状态（僵尸进程、高占用进程）	ps -ef、top、pstree	僵尸进程数 > 5 或单进程CPU/内存占比 > 50%
网络层	网卡流量（in/out）	iftop、iftstat、sar -n DEV	超出带宽80% 或突发流量翻倍
	网络连接数（ESTABLISHED、TIME_WAIT）	netstat -an、ss -tuln	TIME_WAIT > 10000 或监听端口异常关闭
	丢包率/延迟（ping、traceroute）	ping -c 10、mtr	丢包率 > 1% 或延迟 > 100ms
业务服务层	服务存活状态	systemctl status、ps -ef	服务未运行（如nginx、mysql、redis）
	服务端口监听	ss -tuln、telnet、nc	监听端口未开启（如80、3306）
	业务进程健康度	自定义脚本（检查进程PID、日志）	进程频繁重启（10分钟内>3次）
数据层	数据库连接数（MySQL/PostgreSQL）	show processlist、pg_stat_activity	连接数 > 最大连接数的80%
	数据库慢查询	slow_query_log、pt-query-digest	慢查询数5分钟内>10条
	缓存命中率（Redis/Memcached）	redis-cli info stats	Redis 命中率 < 95%
安全层	SSH登录日志（异常IP、失败次数）	/var/log/secure、grep "Failed password"	10分钟内失败登录>10次
	异常进程（未知进程、挖矿进程）	ps -ef、pstree、chkconfig	进程路径非系统/业务目录（如/usr/bin/kinsing）
	文件权限（敏感文件可写）	ls -l /etc/passwd、/etc/shadow	非root用户对/etc/shadow有写权限

2. 巡检工具：从"手动"到"自动化"

手动执行命令效率低、易漏检，需结合工具实现自动化，常见方案如下：

（1）轻量型：脚本化巡检（适合中小规模）

核心逻辑：用Shell/Python脚本批量执行检查命令，输出结构化报告（如CSV/HTML），异常项标红。

示例脚本片段（检查磁盘使用率） ：

bash 复制代码

#!/bin/bash
# 检查所有挂载分区使用率
df -h | grep -vE 'tmpfs|loop|udev' | awk '{print $6,$5}' | while read dir use; do
  use_num=${use%\%*}
  if [ $use_num -ge 90 ]; then
    echo "【异常】分区 $dir 使用率 $use（阈值90%）" >> /var/log/inspect_disk.log
  fi
done

定时执行 ：通过crontab设置周期（如核心业务每小时1次，非核心每日凌晨2次）：
bash 复制代码
```
# 每小时执行磁盘巡检脚本
0 * * * * /usr/local/scripts/inspect_disk.sh
```

（2）企业级：自动化运维平台（适合大规模集群）

工具选型：Ansible、SaltStack、Puppet（批量执行巡检脚本，收集结果）。
优势：支持上千台主机并发巡检，结果统一存储到数据库（如MySQL），结合Web界面展示（如Ansible Tower）。

示例（Ansible批量检查服务存活） ：

yaml 复制代码

# inspect_service.yml
- name: 检查nginx服务状态
  hosts: all
  tasks:
    - name: 查看nginx是否运行
      systemd:
        name: nginx
        state: started
      register: nginx_status
      ignore_errors: yes
    - name: 输出异常结果
      debug:
        msg: "【{{ inventory_hostname }}】nginx服务未运行"
      when: nginx_status.failed

执行命令 ：ansible-playbook -i inventory.ini inspect_service.yml

3. 巡检报告：可视化与故障溯源

报告形式：避免纯文本，用HTML/Markdown生成结构化报告，包含"异常项、主机IP、指标值、建议方案"。
工具推荐 ：
- 轻量：Shell脚本结合sed/awk生成HTML报告；
- 企业级：结合Grafana（展示历史趋势）、Jira（同步故障工单）。

二、监控报警完善：从"误报漏报"到"精准预警"

监控报警是"巡检的延伸"，需实现实时采集、多维度监控、分级报警、自动响应，核心解决"该报的没报、不该报的乱报"问题。

1. 监控体系搭建：选对工具链

需根据业务规模（单机/集群/云原生）选择监控工具，主流方案对比如下：

监控方案	核心组件	优势	适用场景
传统环境	Zabbix	功能全面（监控+报警+自动发现）、社区成熟、支持自定义脚本	物理机/虚拟机集群、中小规模业务
云原生环境	Prometheus + Grafana + Alertmanager	时序数据存储高效、支持动态服务发现、 Grafana可视化强	Kubernetes集群、微服务、云环境
日志监控	ELK/EFK（Elasticsearch+Logstash+Kibana）	实时收集日志、支持全文检索、异常日志告警	业务错误日志、系统日志分析
轻量监控	Node Exporter + Prometheus	部署简单、资源占用低（<50MB）	单机/小规模集群的系统监控

2. 监控指标："基础指标+业务指标+自定义指标"全覆盖

监控不是"越多越好"，而是"关键指标不遗漏"，需区分三类指标：

（1）基础指标（系统层）

用Node Exporter（Prometheus生态）或Zabbix Agent采集，覆盖CPU、内存、磁盘、网络、进程等（无需重复开发）。

（2）业务指标（核心需求）

需自定义采集，比如：
- Web服务：QPS、响应时间（用nginx-module-vts采集Nginx指标）；
- 数据库：SQL执行成功率、事务提交数（用mysqld_exporter采集MySQL指标）；
- 自定义业务：订单成功率、支付转化率（通过业务接口暴露指标，如/metrics）。

（3）应用指标（中间件层）

中间件自带监控接口，如：
- Redis：用redis_exporter采集命中率、连接数；
- Kafka：用kafka_exporter采集Topic分区数、消费延迟。

3. 报警策略：精细化避免"报警风暴"

报警的核心是"让合适的人在合适的时间收到合适的信息"，需从"阈值、分级、聚合、抑制"四方面优化：

（1）阈值优化：拒绝"一刀切"

避免固定阈值（如无论业务高峰/低谷，都用同一阈值），推荐：
- 动态阈值 ：基于历史数据（如过去7天的95分位值）设置阈值（Prometheus可结合prometheus-adapter实现）；
- 阶梯阈值：分时段设置（如白天业务高峰阈值80%，凌晨低谷阈值60%）；
- 趋势阈值：监控指标增长率（如CPU使用率5分钟内从30%涨到90%，即使未超阈值也报警）。

（2）报警分级：按影响范围定级别

将报警分为4级，对应不同响应流程，避免"所有报警都一样"：

报警级别	定义（影响范围）	响应时间	通知渠道	处理流程
P0（致命）	核心业务中断（如支付失败、首页打不开）	5分钟内	短信+钉钉/企业微信@所有人+电话	运维/开发立即介入，停止非紧急工作
P1（严重）	非核心业务中断（如后台管理系统故障）	30分钟内	钉钉/企业微信@负责人	负责人优先处理，同步进度
P2（警告）	指标异常但未影响业务（如磁盘使用率85%）	2小时内	钉钉/企业微信群通知	工作时间内处理，记录日志
P3（提示）	优化建议（如慢查询增多）	24小时内	邮件通知	定期汇总优化

（3）报警聚合：避免"刷屏"

同一类问题合并报警，比如：
- 多台主机因交换机故障断网，只发1条"某网段批量断网"报警，而非每台主机发1条；
- Prometheus的Alertmanager支持"按标签聚合"（如按cluster标签聚合同集群的报警）。

（4）报警抑制：避免"级联报警"

父问题触发后，抑制子问题的报警，比如：
- "主机宕机"报警触发后，自动抑制该主机上的"nginx未运行""MySQL连接失败"等子报警（Alertmanager的inhibit_rules配置）。

4. 日志监控：从"事后排查"到"实时报警"

很多故障（如业务报错、配置错误）仅靠指标无法发现，需结合日志监控：

（1）日志采集与结构化

规范日志格式：用JSON格式输出日志（包含time"level""message""trace_id"），便于检索；
采集工具：用Filebeat（轻量）采集日志，发送到Elasticsearch（存储），Kibana（可视化）。

（2）日志报警规则

基于关键词报警：如"ERROR""Exception""Timeout"出现次数5分钟内>5次；
基于日志内容报警：如支付日志中"支付失败"且"原因=余额不足"外的异常（排除正常业务失败）；
工具实现：Elasticsearch的Watchers或Prometheus的loki（轻量日志监控）设置报警。

5. 自动化响应：减少"人工干预"

对重复、可标准化的故障，实现"报警触发→自动修复"，提升效率：

工具选型：Prometheus Alertmanager（调用Webhook）、Ansible（执行修复脚本）、Zabbix（触发器关联动作）；
常见自动化场景 ：
1. 磁盘使用率超90%：自动清理/var/log下30天前的日志；
2. Nginx进程挂掉：自动执行systemctl restart nginx；
3. Redis连接数超阈值：自动重启Redis（需确认业务可重启）；

示例（Alertmanager调用Webhook修复） ：