《UNIX/Linux系统管理技术手册-读书笔记-第二十八章

监控

1. 监控概述

1.1 什么是监控

概念	说明	能做什么
监控	持续采集基础设施状态数据，评估是否符合预期，异常时通知管理员	在用户投诉前发现问题，变被动救火为主动预防
监控流水线三阶段	①采集原始数据 → ②评估（应用规则）→ ③响应（通知/操作）	将海量数据转化为可操作信息
监控是信仰	每个系统上线前必须加入监控；监控中断比服务中断更严重（失去可见性）	成为“超级英雄”——在小问题变灾难前扼杀

1.2 监控数据类型

类型	说明	示例
实时指标	数字/布尔值，描述当前运行状态	CPU负载、磁盘使用率、服务可达性
事件	状态变化或警报条件触发	日志条目、系统通知
历史趋势	实时指标的时间序列聚合	过去7天带宽利用率变化

1.3 监控原则

原则	说明
一切皆可监控	用户依赖的任何系统/服务都必须监控；所有高可用构件必须监控
监控数据人人可用	历史数据对所有人有用——开发/运维/管理都应能访问仪表盘
全员响应	所有技术角色都应收到警报，由最擅长修复的人解决问题
培训响应人员	培训如何解决警报，而非只是“按掉”；假警报是在鼓励无视监控系统
监控不是可选项	每个人员的工作计划都应包含监控相关内容
监控改善生活质量	可靠的监控让你无需时刻担心系统状态

2. 监控平台选型

2.1 开源实时平台（故障通知型）

平台	特点	适用场景
Nagios	第一代监控，插件丰富，高度可定制	小型网络（<1000台主机）
Icinga	Nagios分叉，Icinga2完全重写，UI更现代	推荐替代Nagios，自动构建依赖
Sensu Core	全栈框架，兼容Nagios插件，与Slack/Logstash集成	希望用现代UI但保留Nagios插件投资

第一代平台渐落后于时间序列系统——新部署建议选择时间序列平台。

2.2 开源时间序列平台（趋势+分析型）

平台	特点	适合场景
Prometheus	作者最爱，集成采集+趋势+警报，对DevOps友好	大多数新部署，但不支持集群（高可用需考虑）
Graphite	时间序列DB+查询语言，组件Carbon/Whisper	大规模分布式监控（数十万指标）
InfluxDB	开发友好，数据管理特性丰富，但曾有bug和不兼容	独立数据管理系统
Munin	插件自带显示规范，历史流行（斯堪的纳维亚）	简单场景；新部署建议Prometheus

2.3 开源图表平台

平台	特点
Graphite内建绘图	直接绘制Whisper数据
Grafana	30+数据源后端，图表更漂亮、UI更优秀，现为事实标准

💡 典型组合：Prometheus + Grafana（采集+展示+告警一体）

2.4 商业化平台（表28.1）

平台	特点
Datadog	云原生，海量系统/应用/服务集成
SignalFx	SaaS，大量云集成
Sysdig Cloud	Docker监控强项，跨服务关联
Pingdom	纯SaaS，适合Web应用外部探测
SolarWinds	网络监控老牌
Zenoss	极复杂，Icinga替代

💡 建议：非特殊需求，外包监控比自建更便宜可靠——优先考虑Datadog/Librato/SignalFx等云方案。

3. 数据采集

3.1 StatsD —— 通用数据提交协议

概念	说明
协议	Etsy开发，基于UDP的前端代理，将数据转储到监控平台
核心能力	接收任意统计数据并执行计算（计数、计量、计时、集合）
支持后端	Graphite、InfluxDB、Datadog等

发送测试数据：

1
2

# 计数指标：sample.count:1|c
echo "sample.count:1|c" | nc -u -w0 statsd.admin.com 8125

StatsD指标类型：

c：计数器（count）
g：计量器（gauge）
ms：计时器（timing）
s：集合（set）

存储聚合配置（/etc/carbon/storage-aggregation.conf）：

[sum]
pattern = \.sum$
xFilesFactor = 0
aggregationMethod = sum

[default_average]
pattern = .*
xFilesFactor = 0.3
aggregationMethod = average

xFilesFactor：汇总层需要的最小非空值百分比（0~1）
aggregationMethod：sum/average/min/max

3.2 从命令输出抓取数据

# 从uptime提取1分钟负载
uptime | perl -anF'[\s,]+' -e 'print $F[10]'

# 提交到StatsD（Perl示例）
use Net::Statsd;
$Net::Statsd::HOST = 'statsd.admin.com';
$loadavg = (split /[\s,]+/, `uptime`)[10];
Net::Statsd::gauge(hostname . '.loadAverage' => $loadavg);

3.3 collectd —— 通用系统数据采集守护进程

特性	说明
功能	按指定间隔采集系统指标，保存到本地或转发
插件数	100+（CPU、内存、磁盘、网络、进程等）
输出	RRDtool、Graphite、InfluxDB、Nagios等

配置示例（/etc/collectd/collectd.conf）：

Hostname client1.admin.com
Interval 30
LoadPlugin cpu
LoadPlugin memory
LoadPlugin load
LoadPlugin rrdtool
<Plugin rrdtool>
    DataDir "/var/lib/collectd/rrd"
</Plugin>

3.4 sysdig / dtrace —— 内核级执行跟踪

工具	平台	能力
sysdig	Linux	内核+进程系统调用跟踪，容器感知
dtrace	BSD	内核动态跟踪，全面监测进程活动
定位	“内核和进程的Wireshark”	深层内核参数+单进程系统调用

💡 花一个周末学习sysig/dtrace，将获得强大的排错超能力。

4. 网络监控

技术	说明	注意事项
ping（ICMP Echo）	最基础单元——验证主机可达和内核运行	频繁发送（10s间隔）OK；网关可丢弃ping
ping策略	覆盖所有重要网关和网络	单点故障：若ping无法穿过网关，数据也不返回
告警策略	采集为二元事件，累计百分比，避免瞬时误报	正常网络也偶有丢包
iPerf	测量两点间吞吐量	详见13.13.2节
SNMP	网络设备标准化监控（详见28.9）	专用设备适用，服务器监控已有更好替代

5. 系统监控

5.1 常用监控命令（表28.2）

命令	监控内容
`df`	磁盘空间+inode使用
`du`	目录大小
`free`	内存+交换使用
`iostat`	磁盘性能和吞吐量
`mpstat`	多核CPU单核利用率
`vmstat`	进程/CPU/内存统计
`lsof`	打开文件和网络端口
`sar`	系统活动报告（可移植性强）

sar网络接口监控示例：

`1`	`sar -n DEV 2 30 # 每2秒采集，共30次`

sar的BSD版本已不再维护，推荐使用其他工具。

5.2 采集策略

方式	适用	优缺点
直接读内核	`/proc`（Linux）或`sysctl`（FreeBSD）	最高效、最准确
命令输出解析	通用场景	灵活但需维护解析逻辑
监控平台插件	Nagios/Icinga/Sensu社区插件	经过测试、跨平台
collectd守护进程	大规模采集	可扩展、标准化

6. 应用监控

6.1 核心思路

层面	说明
参与方	业务部门+开发人员告知关注点（页面载入时长、PHP错误、数据库连接）
业务指标	产品销量、购物车平均停留时长——监控的商业价值
价值	应用监控成为“无价之宝”，监控者被视为数据和指标专家

6.2 日志监控

工具	特点
logwatch	灵活的批量日志汇总器——适合每日报告，非实时
OSSEC	实时日志监控+安全检测（详见27.5.8节）
ELK/Graylog	集中式日志管理系统（详见10.6节）——搜索+阈值+告警

6.3 轻量级组合：Supervisor + Munin

组件	功能
Supervisor	监控进程，异常时生成事件/通知
Munin	通用监控平台，300+插件，RRDtool图形
适用	小规模、不想维护大型监控平台的环境

6.4 商业化APM

平台	特点
New Relic	侧重应用层内部分析
AppDynamics	“全栈式”监控方案
共同点	量化团队收益，DevOps核心工具

7. 安全监控

7.1 文件完整性监控（FIM）

概念	说明
FIM	将系统文件内容与强加密（SHA-512）基准比对，变化即告警
重要原则	正常维护（补丁/升级）也会触发——需有流程区分合法变更和可疑变更
工具	Tripwire、OSSEC、Linux AIDE、FreeBSD mtree

mtree快速脚本示例：

#!/bin/bash
# -b：创建基准；-v：验证基准
mtree -c -K sha512 -s $KEY -p /sbin > mtree_sbin   # 创建
mtree -s $KEY -p /sbin < mtree_sbin                # 验证

7.2 入侵检测系统（IDS）

类型	说明	代表
NIDS（网络）	检查网络流量，识别可疑模式	Snort（开源事实标准）
HIDS（主机）	监控网络连接、文件校验和、日志、提权等	OSSEC（推荐）、AIDE

HIDS实践要点：

FIM和HIDS不是“设置就忘”的系统
将警报集成到故障报修系统，自动创建任务
对未解决的HIDS任务发出警报

8. SNMP

8.1 核心概念

概念	说明
SNMP	标准化网络设备监控协议
MIB	管理信息库——层级化命名空间，描述可访问数据
OID	对象标识符——点分路径（如`1.3.6.1.2.1.1.3`）
社区字符串	“密码”的晦涩名称（通常有只读/读写两个）
操作	`get`、`get-next`、`set`、`trap`（异步通知）

8.2 MIB-II常用OID（表28.3）

OID	类型	内容
`system.sysDescr`	string	系统信息
`interfaces.ifNumber`	int	网络接口数
`ip.ipForwarding`	int	是否网关
`icmp.icmpInRedirects`	int	接收到的ICMP重定向数
`tcp.tcpInErrs`	int	TCP错误数

8.3 Net-SNMP工具（表28.4）

命令	功能
`snmpget`	获取单个OID值
`snmpwalk`	从指定OID遍历整个MIB
`snmptable`	获取SNMP表
`snmptranslate`	搜索/描述OID
`snmptrap`	生成陷阱警报
`snmpdf`	远程磁盘容量

示例：

# 获取5分钟平均负载（Ubuntu）
snmpget -v 2c -c public localhost .1.3.6.1.4.1.2021.10.1.3.2

# 遍历MIB
snmpwalk -c secret -v1 tuva

8.4 SNMP适用建议

“SNMP可以是有趣的邻居，但不想常住那里。”

场景	建议
专用网络设备（路由器/交换机）	✅ SNMP仍合理
UNIX/Linux服务器	❌ 已有更好的替代（collectd/Prometheus）
数据采集策略	从SNMP快速获取数据 → 交给通用监控平台存储处理

9. 监控技巧与最佳实践

技巧	说明
不要忽略监控	确保值班团队得到定期休息——轮替值班制度
定义24×7关注点	并非所有问题都需凌晨3:30召集管理员——正常工作时段解决非关键问题
消除监控噪声	误报/非关键通知立即修复——否则狼来了效应
创建运行记录簿	常见重启/重置/纠正程序文档化——Wiki最佳
监控平台也得监控	监控系统本身故障导致漏报——需有“监控之外的监控”
遗漏即补	因未监控而遗漏的中断——立即纳入监控
先监控后上线	绝无例外：服务器必须先加入监控才能进入生产

10. 本章核心命令速查表

命令/操作	功能
`uptime`	运行时长+负载
`df -h`	磁盘空间
`free -h`	内存使用
`iostat -x 1`	磁盘性能（每秒）
`vmstat 2`	系统统计（每2秒）
`sar -n DEV 2 30`	网络接口统计
`echo metric:1`	c" \| nc -u -w0 statsd.host 8125`
`snmpget -v 2c -c public host OID`	SNMP获取
`snmpwalk -c public -v1 host`	SNMP遍历MIB
`collectd`	系统指标采集守护进程
`sysdig`（Linux）	内核+进程跟踪
`dtrace`（BSD）	动态内核跟踪
`mtree -c -K sha512 -p /path`	FreeBSD文件完整性基准

DBA视角补充：

数据库监控是DBA的核心职责：监控连接数、QPS/TPS、慢查询、锁等待、复制延迟、缓冲池命中率、磁盘I/O等。缺少监控的数据库就像没有仪表盘的飞机。

推荐工具组合：

Prometheus + Grafana：采集数据库指标（通过mysqld_exporter/postgres_exporter）+ 展示仪表盘 + 告警

Percona Monitoring and Management（PMM）：专为MySQL/PostgreSQL/MongoDB设计的开源监控平台（Grafana + Prometheus + 专用采集器）

云数据库：使用云供应商原生监控（AWS RDS Performance Insights、CloudWatch）

监控告警阈值：

复制延迟：>60秒告警

连接数：>80%最大连接数告警

磁盘空间：>80%告警

慢查询：>阈值（如1秒）的查询数量突增

日志监控：数据库错误日志（error.log）应纳入OSSEC/logwatch监控，自动发现异常（如ERROR、FATAL、Corruption）

备份监控：备份成功/失败必须纳入监控，错过备份是DBA最严重的失职之一

性能基准：用历史趋势数据建立性能基线——某天突然偏离基线，立即调查

监控平台也要监控：确保Grafana/Prometheus本身的高可用和告警通道（如Alertmanager）的可靠性

先监控后上线：新数据库实例上线前，必须完成监控配置（绝无例外）