运维监控与网络排查工具

Zabbix

架构

Zabbix 采用经典的三层分布式架构，由 Zabbix Server、Zabbix Proxy 和 Zabbix Agent 组成。

text

                    ┌─────────────────────────────────────┐
                    │           Zabbix Server              │
                    │  ┌─────────┐  ┌──────────┐          │
                    │  │  数据库  │  │   Web UI  │          │
                    │  │(MySQL / │  │(Nginx/Apache)         │
                    │  │PostgreSQL) │  │+ PHP)    │          │
                    │  └─────────┘  └──────────┘          │
                    └──────┬──────────────────────┬───────┘
                           │                      │
                    ┌──────┴──────┐       ┌──────┴────────┐
                    │ Zabbix Proxy│       │  Zabbix Proxy  │
                    │  (数据中心A) │       │   (数据中心B)  │
                    └──┬───────┬──┘       └──┬────────┬────┘
                       │       │             │        │
                  ┌────┴─┐ ┌──┴──┐      ┌───┴──┐ ┌───┴───┐
                  │Agent │ │Agent│      │Agent │ │Agent  │
                  └──────┘ └─────┘      └──────┘ └───────┘

组件	角色	说明
Zabbix Server	核心服务	负责数据收集、处理、告警评估、Web UI 展示，所有数据存储于数据库
Zabbix Proxy	分布式代理	可选组件，用于跨机房、跨网络场景，代理 Server 收集数据并缓存转发
Zabbix Agent	终端采集	部署在被监控机器上，采集 CPU、内存、磁盘、进程等系统指标
Zabbix Database	数据存储	支持 MySQL / PostgreSQL / TimescaleDB，存储配置、历史数据和事件
Zabbix Web UI	管理界面	PHP 编写的 Web 前端，用于配置监控项、查看图表和接收告警

监控项 (Item)、触发器 (Trigger)、告警 (Action)

监控项 (Item)

监控项是 Zabbix 采集数据的最小单元，定义了"采集什么、如何采集、采集频率"。

常见的监控项 Key：

Key	说明	示例
`system.cpu.load`	CPU 负载	`system.cpu.load[all,avg1]`
`system.cpu.util`	CPU 使用率	`system.cpu.util[,idle]`
`vm.memory.size`	内存信息	`vm.memory.size[available]`
`system.uptime`	系统运行时间	`system.uptime`
`net.if.in`	网络入站流量	`net.if.in[eth0]`
`net.if.out`	网络出站流量	`net.if.out[eth0]`
`vfs.fs.size`	磁盘空间	`vfs.fs.size[/,pfree]`
`proc.num`	进程数量	`proc.num[nginx]`
`system.swap.size`	Swap 使用	`system.swap.size[,pfree]`

Zabbix Agent 端主动模式与被动模式：

被动模式 (Passive)：Server/Proxy 主动连接 Agent 的端口（默认 10050）拉取数据
主动模式 (Active)：Agent 主动向 Server/Proxy（默认 10051）推送数据，适合大量被监控节点场景

触发器 (Trigger)

触发器对监控项采集的值进行逻辑评估，当条件满足时产生事件。表达式语法示例：

text

{host:system.cpu.load[all,avg1].last()}>5
{host:vm.memory.size[available].last()}<1G
{host:vfs.fs.size[/,pfree].last()}<10
{host:net.if.in[eth0].avg(5m)}>100M

触发器表达式函数：

函数	说明	示例
`last()`	最新值	`last()>80`
`avg()`	指定时间段的平均值	`avg(5m)>90`
`min()` / `max()`	指定时间段的最小/最大值	`min(10m)<10`
`count()`	条件计数	`count(10m,0)` — 10 分钟内值为 0 的次数
`nodata()`	无数据检测	`nodata(5m)=1` — 5 分钟没有收到数据
`change()`	值变化量	`change()>10`

告警配置 (Action)

Action 定义触发条件满足后执行的操作：

告警媒介：Email（SMTP）、钉钉/企业微信 Webhook、Slack、短信（自定义脚本）
操作步骤：发送告警 → escalation（升级告警）→ 自动恢复通知
通知模板：支持 {HOST.NAME}、{ITEM.VALUE}、{TRIGGER.STATUS} 等宏变量

Action 配置流程：

配置告警媒介 (Media Type)
  → 创建用户并关联告警媒介
    → 创建 Action，绑定触发器
      → 设置操作步骤 (Operations)
        → 设置恢复操作 (Recovery operations)

自动发现 (Auto Discovery)

Zabbix 提供两种自动发现机制：

网络自动发现 (Network Discovery)

Zabbix Server 定期扫描指定 IP 段，发现新设备并自动加入监控。

text

配置路径：Configuration → Discovery → Create discovery rule

关键参数：
- IP 范围：192.168.1.1-254
- 检查方式：ICMP ping / SSH / Telnet / SNMP
- 发现间隔：3600s（默认）
- 动作 (Action)：发现后自动添加主机并关联模板

主动注册 (Active Agent Auto-registration)

Agent 启动时主动向 Server 注册，Server 自动为其分配模板和接管监控。

text

Agent 端配置 (zabbix_agentd.conf)：
  ServerActive=192.168.1.100:10051
  Hostname=web-server-01
  HostMetadata=linux,nginx

Server 端动作：配置 Auto-registration action，根据 HostMetadata 自动关联模板

低级别发现 (LLD - Low Level Discovery)

自动发现并监控动态资源（文件系统、网络接口、Docker 容器），无需手动逐个创建监控项。

text

常见 LLD 类型：
- 文件系统发现：自动为每个挂载点创建磁盘空间监控项
- 网络接口发现：自动为每个网卡创建流量监控项
- SNMP OID 发现：自动发现 SNMP 设备上的接口和磁盘
- JMX 发现：自动发现 Java JVM 中的 MBean
- 自定义发现：通过 Agent 返回 JSON 格式的发现数据

模板使用 (Template)

模板是监控配置的复用单元，包含监控项、触发器、图形和仪表盘的集合。

推荐实践：

使用官方预置模板（Linux by Zabbix agent、MySQL by Template DB）
按服务角色分组：Template OS Linux、Template App Nginx、Template DB MySQL
使用模板继承（Template inheritance）管理公共监控基线

自定义模板配置：

text

Configuration → Templates → Create template

名称：Template App Nginx
组：Templates/Applications
包含：
- 监控项：nginx.active-connections, nginx.accepts, nginx.handled, nginx.requests
- 触发器：nginx.service.down, nginx.connections.too.high
- 图形：Nginx connections, Nginx requests per second

Docker 部署示例

以下是使用 Docker Compose 部署 Zabbix 的完整示例：

yaml

version: "3.8"

services:
  zabbix-mysql:
    image: mysql:8.0
    container_name: zabbix-mysql
    environment:
      MYSQL_ROOT_PASSWORD: zabbix_root_pass
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbix_pass
    volumes:
      - zbx-mysql-data:/var/lib/mysql
    networks:
      - zbx-net
    restart: always

  zabbix-server:
    image: zabbix/zabbix-server-mysql:alpine-7.0-latest
    container_name: zabbix-server
    environment:
      DB_SERVER_HOST: zabbix-mysql
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbix_pass
      ZBX_JAVAGATEWAY: zabbix-java-gateway
    ports:
      - "10051:10051"
    volumes:
      - zbx-server-data:/var/lib/zabbix
    networks:
      - zbx-net
    depends_on:
      - zabbix-mysql
    restart: always

  zabbix-web:
    image: zabbix/zabbix-web-nginx-mysql:alpine-7.0-latest
    container_name: zabbix-web
    environment:
      ZBX_SERVER_HOST: zabbix-server
      DB_SERVER_HOST: zabbix-mysql
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbix_pass
      PHP_TZ: Asia/Shanghai
    ports:
      - "8080:8080"
    networks:
      - zbx-net
    depends_on:
      - zabbix-server
    restart: always

  zabbix-agent:
    image: zabbix/zabbix-agent2:alpine-7.0-latest
    container_name: zabbix-agent
    privileged: true
    environment:
      ZBX_HOSTNAME: zabbix-server
      ZBX_SERVER_HOST: zabbix-server
      ZBX_SERVER_PORT: 10051
    networks:
      - zbx-net
    depends_on:
      - zabbix-server
    restart: always

  zabbix-java-gateway:
    image: zabbix/zabbix-java-gateway:alpine-7.0-latest
    container_name: zabbix-java-gateway
    networks:
      - zbx-net
    restart: always

volumes:
  zbx-mysql-data:
  zbx-server-data:

networks:
  zbx-net:
    driver: bridge

Nagios

架构

Nagios Core 采用 插件式架构，核心服务负责调度和告警，实际监控由外部插件（Plugins）执行。

text

                    ┌───────────────────────────────────┐
                    │         Nagios Core               │
                    │  ┌──────────┐  ┌────────┐         │
                    │  │ Event     │  │ CGI     │        │
                    │  │ Scheduler  │  │ (Web UI)│        │
                    │  └──────────┘  └────────┘         │
                    │  ┌──────────┐  ┌────────┐         │
                    │  │ Nagios    │  │ Status  │        │
                    │  │ Daemon    │  │ DB      │        │
                    │  └──────────┘  └────────┘         │
                    └──────┬──────────────────────┬──────┘
                           │                      │
                          check_nrpe          check_nrpe
                           │                      │
                    ┌──────┴──────┐       ┌──────┴────────┐
                    │ NRPE + Nagios     │  NRPE + Nagios  │
                    │ Plugins           │  Plugins          │
                    │ (Linux Host A)    │  (Linux Host B)  │
                    └──────────────────┘  └─────────────────┘

组件	角色
Nagios Core	核心调度引擎，负责执行插件、评估状态、发送通知
Nagios Plugins	预置的监控插件集合（check_ping, check_http, check_disk 等）
NRPE (Nagios Remote Plugin Executor)	远程执行插件，用于监控远程 Linux/Unix 主机
NSClient++	用于 Windows 主机的远程监控代理
Web UI (CGI)	基于 CGI 的 Web 管理界面

NRPE 插件

NRPE 允许 Nagios Server 在远程主机上执行插件并获取结果。

NRPE 工作流程：

text

Nagios Server → check_nrpe → NRPE daemon (远程主机, 端口 5666)
                                  → 执行本地插件 (check_disk, check_load 等)
                                  → 返回状态码和输出文本到 Nagios Server

返回状态码：

状态码	含义	Nagios 图标
0	OK（正常）	绿色
1	WARNING（警告）	黄色
2	CRITICAL（严重）	红色
3	UNKNOWN（未知）	橙色

check_nrpe 配置

远程主机 NRPE 配置

text

# /etc/nagios/nrpe.cfg

# NRPE 守护进程监听地址和端口
server_address=0.0.0.0
server_port=5666

# 允许连接的 Nagios Server IP
allowed_hosts=127.0.0.1,192.168.1.100

# 定义命令
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_swap]=/usr/lib/nagios/plugins/check_swap -w 50% -c 25%
command[check_procs]=/usr/lib/nagios/plugins/check_procs -w 250 -c 400
command[check_mem]=/usr/lib/nagios/plugins/check_mem -w 80 -c 95

Nagios Server 定义主机和服务

text

# /etc/nagios/servers/web-server-01.cfg

define host {
    use                linux-server
    host_name          web-server-01
    alias              Web Server 01
    address            192.168.1.10
    check_command      check-host-alive
    max_check_attempts 3
    check_period       24x7
    notification_period 24x7
    contact_groups     admins
}

define service {
    use                 generic-service
    host_name           web-server-01
    service_description CPU Load
    check_command       check_nrpe!check_load
    max_check_attempts  3
    check_interval      5
    retry_interval      1
    check_period        24x7
    notification_period 24x7
    contact_groups      admins
}

define service {
    use                 generic-service
    host_name           web-server-01
    service_description Disk Space
    check_command       check_nrpe!check_disk
    max_check_attempts  3
    check_interval      10
    retry_interval      2
    check_period        24x7
    notification_period 24x7
    contact_groups      admins
}

check_nrpe 命令定义

text

# /etc/nagios/objects/commands.cfg

define command {
    command_name    check_nrpe
    command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

手动测试 NRPE

bash

# 测试远程主机上的 check_load 插件
check_nrpe -H 192.168.1.10 -c check_load

# 指定端口
check_nrpe -H 192.168.1.10 -p 5666 -c check_disk

# 传递参数给插件（需要 NRPE 支持参数传递）
check_nrpe -H 192.168.1.10 -c check_disk -a '-w 10% -c 5% -p /data'

Nagios vs Zabbix 对比表

对比维度	Zabbix	Nagios
架构设计	Server/Proxy/Agent 三层，中心化统一管理	Core + Plugin，分布式需依赖 NRPE/NDOUtils
数据采集方式	支持 Agent (主动/被动)、SNMP、JMX、HTTP、IPMI	外部插件执行，无内置 Agent 协议
自动发现	支持网络发现、主动注册、LLD（低级别发现）	有限，需 Nedi 或外部工具配合
数据存储	内置数据库（MySQL/PostgreSQL/TimescaleDB）	文本文件或 NDOUtils 存入数据库
可视化能力	内置 Web UI，支持图表、聚合图形、仪表盘	内置 Web UI 较弱，建议搭配 Grafana 或 Nagios XI
模板机制	成熟的模板系统，支持模板继承和链接	有限，通过配置文件复制实现
告警机制	灵活的 Action + Media Type + Escalation	通过配置文件定义联系人、组和通知
扩展性	Proxy 天然支持大规模分布式监控	多 Nagios 实例 + NSCA 实现分布式
配置方式	Web UI 配置 + 导入/导出	纯文本配置文件，不支持 Web UI 配置
学习曲线	中等，Web UI 降低上手难度	较高，需要掌握配置文件语法
适用规模	小到大规模（数千节点）	小到中等规模（数百节点）
社区活跃度	非常活跃，版本迭代快	较平稳，Nagios Core 更新缓慢
容器支持	官方 Docker 镜像、Kubernetes 集成	社区方案，需自行构建镜像

选型建议：

新项目优先选择 Zabbix：功能全面、配置方便、可视化和自动发现能力更强
已有 Nagios 投资或超小型环境选择 Nagios：配置透明、插件生态丰富、对资源消耗极低
需要 Prometheus 生态的请参考 Prometheus + Grafana 文档

Netdata

实时监控

Netdata 是一款 零配置、高分辨率（每秒采集） 的实时监控工具，以低资源开销提供精细化的系统和应用指标。

核心特性：

特性	说明
采集粒度	每秒收集一次指标，实时性远优于传统工具的 5-60 秒间隔
资源占用	CPU 占用约 1% 单核，内存约 100-200MB，磁盘写入约 4MB/天
内置指标数	开箱即用 2000+ 指标，覆盖 CPU、内存、磁盘、网络、进程、容器等
交互式仪表盘	基于 HTML5 的 Web UI，数据实时渲染，支持随意拖动查看历史
自定义仪表盘	支持 PromQL、自定义图表配置

支持的技术栈：

text

系统层：CPU / Memory / Disk / Network / Swap / Uptime / Systemd
数据库：MySQL / PostgreSQL / MongoDB / Redis / Elasticsearch
Web 服务：Nginx / Apache / Tomcat / PHP-FPM
消息队列：Kafka / RabbitMQ / Nginx Stream
容器：Docker / Kubernetes / LXC / Containerd
应用：Go applications / Python apps / Node.js

零配置部署

Netdata 提供两行命令即可完成部署，无需修改系统配置或重启服务。

bash

# 一键安装脚本（推荐）
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

# Docker 部署
docker run -d \
  --name netdata \
  --restart always \
  --cap-add SYS_PTRACE \
  --security-opt apparmor=unconfined \
  -p 19999:19999 \
  -v /etc/passwd:/host/etc/passwd:ro \
  -v /etc/group:/host/etc/group:ro \
  -v /proc:/host/proc:ro \
  -v /sys:/host/sys:ro \
  -v /etc/os-release:/host/etc/os-release:ro \
  -v /var/log:/host/var/log:ro \
  netdata/netdata

# Docker Compose
cat > docker-compose.yml << 'EOF'
version: "3.8"
services:
  netdata:
    image: netdata/netdata
    container_name: netdata
    restart: always
    cap_add:
      - SYS_PTRACE
    security_opt:
      - apparmor=unconfined
    ports:
      - "19999:19999"
    volumes:
      - /etc/passwd:/host/etc/passwd:ro
      - /etc/group:/host/etc/group:ro
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /etc/os-release:/host/etc/os-release:ro
      - /var/log:/host/var/log:ro
      - netdata-cache:/var/cache/netdata
      - netdata-conf:/etc/netdata
volumes:
  netdata-cache:
  netdata-conf:
EOF

告警通知

Netdata 内置健康检查引擎（Health Engine），自动为每个指标设置告警阈值，支持多种通知渠道。

默认告警规则示例：

text

10 秒内 CPU 使用率超过 90%      → 触发 CRITICAL
30 秒内 RAM 使用率超过 80%      → 触发 WARNING
磁盘空间使用率超过 80%          → 触发 WARNING
磁盘 I/O 等待时间超过 50ms      → 触发 WARNING
网络接口丢弃包超过 5%          → 触发 CRITICAL
出站 TCP 连接数超过 1000       → 触发 WARNING

自定义告警规则：

yaml

# /etc/netdata/health.d/custom.conf

# CPU 高负载告警
template: user_cpu_high
  on: system.cpu
  class: Utilization
  type: System
  component: CPU
  calculation: $user * 100 / ($user + $system + $nice + $iowait + $irq + $softirq + $steal)
  units: %
  every: 10s
  warn: $this > 70
  crit: $this > 90
  info: User CPU utilization percentage
  to: sysadmin

# 自定义 Nginx 连接数告警
template: nginx_connections_warn
  on: nginx.active_connections
  class: Utilization
  type: Web Server
  every: 10s
  calc: $active / $max_active * 100
  units: %
  warn: $this > 80
  crit: $this > 95
  info: Nginx active connection usage
  to: webmaster

通知渠道配置：

text

# /etc/netdata/health_alarm_notify.conf

# 邮件通知
SEND_EMAIL="YES"
DEFAULT_RECIPIENT_EMAIL="admin@example.com"

# 钉钉机器人
SEND_DINGTALK="YES"
DINGTALK_WEBHOOK_URL="https://oapi.dingtalk.com/robot/send?access_token=your_token"

# 企业微信机器人
SEND_WECHAT="YES"
WECHAT_WEBHOOK_URL="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=your_key"

# Slack
SEND_SLACK="YES"
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/xxx"

# Webhook（自定义）
SEND_CUSTOM="YES"
CUSTOM_WEBHOOK_URL="http://your-alert-system/webhook"

三种监控工具对比选型表

对比维度	Zabbix	Nagios	Netdata
定位	企业级全栈监控平台	经典监控框架	实时细粒度性能监控
部署复杂度	中等（需数据库 + Web 服务）	简单（Core + Plugins）	极低（一键脚本 / 单容器）
采集粒度	30-300 秒（默认）	5-15 分钟（典型）	1 秒（每秒）
数据保留	自定义（默认 7-30 天）	依赖外部存储	自定义（默认 2-4 小时 RAM + 可配置归档）
自动发现	强（LLD / 网络发现 / 主动注册）	弱（需外部工具配合）	有限（仅自动识别系统和应用）
告警能力	强（Action + Media + Escalation）	中等（通过配置文件）	中等（内置 Health Engine）
可视化	内置仪表盘 + 聚合图形	弱（建议 Grafana）	强（内置交互式仪表盘）
扩展性	Proxy 支持大规模分布式	多实例 + NSCA	Parent-Child 架构
容器/K8s	官方支持	社区方案	原生支持（自动发现容器）
学习成本	中等	较高（纯文件配置）	极低
社区/商业	Zabbix（开源）/ Zabbix SIA（商业支持）	Nagios Core（开源）/ Nagios XI（商业）	Netdata（开源）/ Netdata Cloud（商业）
最佳场景	大规模、跨区域、需要统一管理平台	小规模、简单需求、极低资源环境	性能调优、容量规划、实时问题排查
典型端口	Server:10051, Agent:10050, Web:8080	Core:80, NRPE:5666, NSCA:5667	19999（Web 仪表盘）

选型建议：

Zabbix 适用于需要统一监控平台的中大型团队，覆盖服务器、网络、数据库、应用的全栈监控
Nagios 适用于极小规模环境或已有大量 Nagios Plugin 资产的组织
Netdata 作为 Zabbix/Nagios 的补充，提供秒级细粒度数据，辅助性能分析和故障排查

实际生产中常见组合：Zabbix + Netdata（Zabbix 负责告警和长期存储，Netdata 负责实时性能分析）或 Prometheus + Grafana + Netdata（云原生方案 + 实时指标补充）。

网络排查工具详解

ping / traceroute / mtr

ping — 连通性和延迟测试

ping 基于 ICMP Echo Request/Reply，用于测试目标主机是否可达以及网络延迟。

bash

# 基本连通性测试
ping 8.8.8.8

# 指定发送 5 个包
ping -n 5 8.8.8.8

# 指定间隔（单位：秒）
ping -i 0.5 8.8.8.8

# 指定包大小测试 MTU
ping -l 1472 -f 8.8.8.8

# 持续 ping 并显示时间戳
ping -D 8.8.8.8

输出解读：

text

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=14.1 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.800/12.733/14.100/0.980 ms

字段	含义
`ttl`	Time To Live，每经过一个路由器减 1，可推测距离（64 为本地，128 为 Windows 默认，255 为同一网段）
`time`	往返延迟（RTT），单位为毫秒
`packet loss`	丢包率，>0% 表示链路上有故障或拥塞
`mdev`	RTT 抖动，值越大表示网络越不稳定

排查场景：

现象	可能原因
100% loss	目标主机离线、防火墙拦截 ICMP、网络断连
高延迟（>100ms）	跨国链路、带宽瓶颈、路由迂回
高抖动（mdev > 50）	无线网络、链路拥塞、路由器负载高
部分丢包	链路层错误、端口中继故障、带宽不足

traceroute — 路由追踪

traceroute 通过递增 TTL 值探针，逐跳显示到达目标主机的路径。

bash

# Linux
traceroute -n 8.8.8.8

# Windows
tracert -d 8.8.8.8

# 指定最大跳数和超时
traceroute -m 30 -w 3 8.8.8.8

# 使用 TCP 代替 UDP（穿透防火墙）
traceroute -T -p 80 8.8.8.8

# 使用 ICMP（部分网络优先放行 ICMP）
traceroute -I 8.8.8.8

输出解读：

text

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1   0.423 ms   0.417 ms   0.373 ms
 2  10.0.0.1      2.143 ms   2.130 ms   2.119 ms
 3  172.16.1.1    5.211 ms   5.200 ms   5.185 ms
 4  202.96.x.x   12.345 ms  12.330 ms  12.310 ms
 5  * * *
 6  8.8.8.8      14.567 ms  14.550 ms  14.520 ms

排查场景：

现象	可能原因
某跳 `* * *`	路由器不响应 ICMP/TCP 探针，不一定代表故障
某跳延迟骤增	跨国链路、链路拥塞、路由迂回
路由环路	TTL 递增到 30 仍未到达，IP 路由配置错误
某跳后全部 `*`	该跳防火墙丢弃探针包，或下游路由不可达

mtr — 高级路由诊断

mtr 结合 ping 和 traceroute，持续对每一跳发送探测包，统计延迟和丢包率。

bash

# 基础使用
mtr 8.8.8.8

# 数字模式（不解析主机名）
mtr -n 8.8.8.8

# 指定报告模式（发送指定数量包后输出报告）
mtr -r -c 100 8.8.8.8

# 同时显示 IPv4 和 IPv6
mtr -4 8.8.8.8
mtr -6 2001:4860:4860::8888

# 指定包大小
mtr -s 1472 8.8.8.8

输出解读：

text

                            My traceroute  [v0.95]
Key: ! = ICMP unreachable  ? = unknown  . = timeout
   Host                           Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1                   0.0%    100   0.4   0.5   0.3   1.2   0.2
2. 10.0.0.1                      0.0%    100   2.1   2.3   1.9   5.4   0.5
3. 172.16.1.1                    0.0%    100   5.0   5.2   4.8   8.1   0.4
4. 202.96.x.x                    15.0%   100   12.3   25.6  12.1  200.3  30.2
5. 218.30.x.x                    15.0%   100   12.5   25.8  12.3  198.5  28.9
6. 8.8.8.8                       0.0%    100   14.1   14.5  13.8  18.2   0.6

排查要点：

如果第 4 跳丢包 15%，后面所有跳都丢包，说明 第 4 跳是丢包根源
如果某跳丢包但后面恢复，说明该跳优先级低，丢弃探测包但转发数据包
StDev（标准差）反映网络抖动，值大表示该链路不稳定

netstat / ss

netstat — 网络连接和端口状态

netstat 是传统的网络状态查看工具。

bash

# 列出所有 TCP 连接（含端口和进程）
netstat -anp tcp

# 列出所有监听端口及对应进程
netstat -ano | findstr LISTENING

# 显示路由表
netstat -r

# 按协议统计连接数
netstat -s

# 显示每个进程的网络连接
netstat -b

状态含义：

TCP 状态	说明
`LISTEN`	正在监听，等待客户端连接
`ESTABLISHED`	已建立连接，正在通信
`TIME_WAIT`	主动关闭方等待 2MSL，确保 ACK 到达
`CLOSE_WAIT`	被动关闭方等待应用层调用 close()
`SYN_SENT`	发送 SYN，等待 SYN+ACK
`FIN_WAIT1` / `FIN_WAIT2`	主动关闭过程

ss — 更快的连接查询

ss 是 netstat 的现代替代方案，性能更好，信息更全面。

bash

# 列出所有 TCP 连接
ss -tan

# 列出所有监听端口
ss -tln

# 显示进程信息
ss -tanp

# 列出所有 UDP 连接
ss -uan

# 显示连接统计
ss -s

# 按目标 IP 过滤
ss dst 192.168.1.100

# 按源端口过滤
ss src :80

# 显示 TCP 状态统计
ss -t state established

# 显示 TIME_WAIT 状态的连接数
ss -t state time-wait | wc -l

参数说明：

参数	含义
`-t`	显示 TCP 连接
`-u`	显示 UDP 连接
`-l`	仅显示监听状态
`-n`	数字格式（不解析主机名和服务名）
`-a`	显示所有（监听 + 非监听）
`-p`	显示进程信息
`-s`	统计汇总

排查场景（端口和连接）：

问题	排查命令	预期输出
端口是否在监听	`ss -tlnp \| grep :8080`	输出显示 `LISTEN` 状态
连接数是否超限	`ss -s`	检查 `TCP:` 行，关注 `estab` 数量
TIME_WAIT 过多	`ss -tan \| grep TIME-WAIT \| wc -l`	正常 < 2 万
查看 Nginx 连接	`ss -tanp \| grep nginx`	显示 ESTABLISHED / TIME_WAIT 连接
查看 MySQL 连接	`ss -tanp \| grep :3306`	显示客户端 IP 和连接状态
端口占用查询	`ss -tlnp \| grep -E ':80	:443'`

tcpdump

tcpdump 是命令行包抓取工具，配合 Wireshark 可以实现强大的网络问题分析。

基本使用

bash

# 抓取指定网卡的所有流量
tcpdump -i eth0

# 指定抓取包数后退出
tcpdump -i eth0 -c 100

# 不解析 DNS，显示 IP 地址
tcpdump -i eth0 -n

# 保存抓包文件供 Wireshark 分析
tcpdump -i eth0 -w capture.pcap

# 读取抓包文件
tcpdump -r capture.pcap -n

过滤表达式

bash

# 按主机过滤
tcpdump -i eth0 host 192.168.1.100
tcpdump -i eth0 src host 192.168.1.100
tcpdump -i eth0 dst host 192.168.1.100

# 按端口过滤
tcpdump -i eth0 port 80
tcpdump -i eth0 src port 443
tcpdump -i eth0 dst port 3306

# 按协议过滤
tcpdump -i eth0 tcp
tcpdump -i eth0 udp
tcpdump -i eth0 icmp

# 组合过滤
tcpdump -i eth0 "host 192.168.1.100 and tcp port 80"
tcpdump -i eth0 "src net 192.168.1.0/24 and dst port 443"

# TCP 标志位过滤
tcpdump -i eth0 "tcp[tcpflags] & (tcp-syn) != 0"          # SYN 包
tcpdump -i eth0 "tcp[tcpflags] & (tcp-fin) != 0"          # FIN 包
tcpdump -i eth0 "tcp[tcpflags] & (tcp-rst) != 0"          # RST 包
tcpdump -i eth0 "(tcp[tcpflags] & (tcp-syn|tcp-ack) == 0x12)"  # SYN-ACK 包

高级技巧

bash

# 抓取 HTTP GET 请求
tcpdump -i eth0 -A 'tcp port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420)'

# 抓取 HTTP POST 请求
tcpdump -i eth0 -A 'tcp port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)'

# 抓取 DNS 查询
tcpdump -i eth0 -n udp port 53

# 抓取 MySQL 查询
tcpdump -i eth0 -A -n 'tcp port 3306'

# 抓取 TCP 三次握手过程
tcpdump -i eth0 -n 'tcp port 80 and (tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0)'

# 限制抓取大小（避免大包影响性能）
tcpdump -i eth0 -s 96 -w capture.pcap

# 不抓取自己的 SSH 控制台流量
tcpdump -i eth0 not port 22

Wireshark 配合使用

服务器端抓包，Wireshark 分析：

bash

# 远程服务器抓包
ssh user@server "tcpdump -i eth0 -w - host 192.168.1.100 and tcp port 80" | \
  wireshark -k -i -

Wireshark 分析技巧：

过滤器	用途
`tcp.analysis.retransmission`	标记所有重传包，定位丢包
`tcp.analysis.duplicate_ack`	查找重复 ACK，判断乱序或丢包
`tcp.analysis.fast_retransmission`	快速重传，判断网络或服务器瓶颈
`http.response.code == 500`	快速定位服务端错误响应
`dns.flags.response == 0`	查看所有 DNS 查询
`ssl.handshake.type == 1`	查看 Client Hello（SSL/TLS 握手分析）
`tcp.port == 80 && ip.addr == 192.168.1.1`	复合过滤
`tcp.stream eq 0`	跟踪特定 TCP 流，查看完整会话内容

常见排查场景：

慢请求分析 — 抓包后在 Wireshark 查看 Time since first frame in this TCP stream，区分网络延迟 vs 服务处理慢
丢包定位 — 使用 tcp.analysis.flags 过滤异常包（重传、重复 ACK、零窗口）
SSL/TLS 握手分析 — 过滤 ssl.handshake，查看协商的 TLS 版本、密码套件、证书链
应用层协议调试 — HTTP/MySQL/Redis 都可抓包解析，逐步定位问题

curl / wget

curl — HTTP 接口测试

curl 是功能最丰富的命令行 HTTP 客户端。

bash

# 基本 GET 请求
curl https://api.example.com/v1/health

# 带请求头的 GET 请求
curl -H "Authorization: Bearer token123" \
     -H "Content-Type: application/json" \
     https://api.example.com/v1/users

# POST 请求（JSON 数据）
curl -X POST \
     -H "Content-Type: application/json" \
     -d '{"name":"test","value":42}' \
     https://api.example.com/v1/data

# 查看响应头（调试用）
curl -I https://api.example.com

# 查看请求和响应完整详情
curl -v https://api.example.com

# 查看更详细的信息（含 SSL 证书、握手过程）
curl --trace - https://api.example.com
curl --trace-ascii trace.log https://api.example.com

# 限制超时时间
curl --connect-timeout 5 --max-time 10 https://api.example.com

# 模拟 IP 访问（测试 Host 头
curl -H "Host: www.example.com" http://192.168.1.10

# 跟随重定向
curl -L http://example.com

# 输出响应时间分析（配合 -w 参数）
curl -w "\nTime: %{time_total}s, HTTP: %{http_code}, DNS: %{time_namelookup}s, TCP: %{time_connect}s, SSL: %{time_appconnect}s, Server: %{time_starttransfer}s\n" \
     -o /dev/null -s https://api.example.com

-w 参数输出详解：

变量	说明	典型值
`time_namelookup`	DNS 解析耗时	< 50ms（本地 DNS）
`time_connect`	TCP 三次握手耗时	< 10ms（同机房）
`time_appconnect`	SSL/TLS 握手耗时	100-500ms
`time_starttransfer`	服务器开始传输首个字节的时间（TTFB）	< 200ms（健康 API）
`time_total`	总耗时	各阶段之和
`http_code`	HTTP 响应状态码	200/301/401/500

排查场景：

bash

# 场景 1：接口返回缓慢，定位瓶颈
curl -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nSSL: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
     -o /dev/null -s https://api.example.com

# 场景 2：测试 DNS 解析是否正确
curl -v -H "Host: www.example.com" https://1.2.3.4

# 场景 3：测试特定 HTTP 方法
curl -X PUT -H "Content-Type: application/json" \
     -d '{"status":"active"}' \
     https://api.example.com/v1/item/123

# 场景 4：上传文件
curl -F "file=@/path/to/file.pdf" \
     -F "description=Report" \
     https://api.example.com/v1/upload

# 场景 5：快速测试 CDN 或负载均衡节点
for ip in 1.1.1.1 2.2.2.2 3.3.3.3; do
  echo "Testing $ip..."
  curl -H "Host: www.example.com" -o /dev/null -s -w "%{http_code} %{time_total}s\n" \
       https://$ip
done

wget — 文件下载和镜像

bash

# 基本文件下载
wget https://example.com/file.tar.gz

# 断点续传
wget -c https://example.com/large-file.iso

# 指定保存文件名
wget -O myfile.tar.gz https://example.com/file.tar.gz

# 限制下载速度和重试
wget --limit-rate=1M --tries=3 https://example.com/file.tar.gz

# 下载整个网站（递归但不超越域名）
wget --recursive --no-parent --convert-links \
     --html-extension \
     --domains example.com \
     https://example.com

nslookup / dig

nslookup — DNS 查询

bash

# 基本域名解析
nslookup www.example.com

# 指定 DNS 服务器
nslookup www.example.com 8.8.8.8

# 查询 MX 记录
nslookup -type=MX example.com

# 查询 NS 记录
nslookup -type=NS example.com

# 查询 TXT 记录
nslookup -type=TXT example.com

# 反向解析（IP 到域名）
nslookup 8.8.8.8

dig — 专业 DNS 诊断

dig 比 nslookup 提供更详细和格式化的 DNS 响应信息。

bash

# 基础查询
dig www.example.com

# 指定 DNS 服务器
dig @8.8.8.8 www.example.com

# 查询特定记录类型
dig www.example.com A
dig example.com MX
dig example.com NS
dig example.com TXT
dig www.example.com CNAME
dig example.com SOA

# 反向查询
dig -x 8.8.8.8

# 追踪 DNS 解析过程
dig +trace www.example.com

# 短格式输出（仅显示结果）
dig +short www.example.com

# 查询 DNS 响应时间
dig @8.8.8.8 www.example.com | grep "Query time"

# 批量查询
for domain in example.com google.com baidu.com; do
  echo "=== $domain ==="
  dig +short $domain
done

dig 输出解读：

text

; <<>> DiG 9.18.0 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.               IN      A

;; ANSWER SECTION:
www.example.com.        3600    IN      A       93.184.216.34

;; AUTHORITY SECTION:
example.com.            3600    IN      NS      a.iana-servers.net.
example.com.            3600    IN      NS      b.iana-servers.net.

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jul 09 10:00:00 CST 2026
;; MSG SIZE  rcvd: 104

字段	说明
`status: NOERROR`	查询成功，其他状态：NXDOMAIN（域名不存在）、SERVFAIL（服务器故障）、REFUSED（拒绝）
`ANSWER`	返回的记录数
`TTL (3600)`	DNS 缓存时间，单位为秒
`Query time`	DNS 服务器响应耗时
`flags: ra`	Recursion Available，递归查询可用

常见 DNS 排查场景：

bash

# 场景 1：检查 DNS 解析是否正常
dig +short www.example.com

# 场景 2：比较不同 DNS 服务器的解析结果
dig @8.8.8.8 www.example.com +short
dig @114.114.114.114 www.example.com +short
dig @your-internal-dns www.example.com +short

# 场景 3：查看 DNS 缓存时间（TTL）
dig www.example.com | grep -E "^[a-zA-Z]" | head -5

# 场景 4：检查域名是否存在
dig nonexistent-domain-12345.com | grep "status"

# 场景 5：检查 DNS 传播（使用全球节点）
dig +short www.example.com @8.8.8.8
dig +short www.example.com @1.1.1.1
dig +short www.example.com @208.67.222.222

常用排查命令速查表

连通性排查

命令	用途	示例
`ping <host>`	测试连通性和延迟	`ping -n 10 8.8.8.8`
`traceroute <host>`	追踪路由路径	`traceroute -n 8.8.8.8`
`mtr <host>`	持续路由诊断	`mtr -r -c 50 8.8.8.8`
`arp -a`	查看 ARP 表	`arp -a`

端口和服务排查

命令	用途	示例
`ss -tlnp`	列出所有 TCP 监听端口	`ss -tlnp \| grep :80`
`ss -tan`	列出所有 TCP 连接状态	`ss -tan \| grep ESTAB`
`netstat -ano`	查看端口和对应进程 PID	`netstat -ano \| findstr LISTENING`
`lsof -i :80`	查看端口占用进程	`lsof -i :3306`
`telnet <host> <port>`	测试端口连通性	`telnet 192.168.1.10 80`
`nc -zv <host> <port>`	扫描端口	`nc -zv 192.168.1.10 22-100`
`nmap -p 1-1000 <host>`	端口扫描	`nmap -sT -p 80,443,3306 192.168.1.10`

HTTP/API 排查

命令	用途	示例
`curl -I <url>`	查看 HTTP 响应头	`curl -I https://api.example.com`
`curl -v <url>`	查看完整 HTTP 交互	`curl -v https://api.example.com`
`curl -w`	查看各阶段耗时	`curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://api.example.com`
`wget -S <url>`	查看服务器响应头	`wget -S --spider https://example.com`

DNS 排查

命令	用途	示例
`dig <domain>`	详细 DNS 查询	`dig www.example.com`
`dig +trace <domain>`	DNS 递归追踪	`dig +trace example.com`
`nslookup <domain>`	基础 DNS 查询	`nslookup www.example.com`
`host <domain>`	简化的 DNS 查询	`host www.example.com`
`dig -x <ip>`	反向 DNS 查询	`dig -x 8.8.8.8`

包抓取分析

命令	用途	示例
`tcpdump -i eth0 host X`	抓取指定主机流量	`tcpdump -i eth0 host 192.168.1.100 -w cap.pcap`
`tcpdump -i eth0 port X`	抓取指定端口流量	`tcpdump -i eth0 tcp port 443`
`tcpdump -r file.pcap`	读取抓包文件	`tcpdump -r cap.pcap -n \| head -50`
`tshark -r file.pcap`	命令行 Wireshark 分析	`tshark -r cap.pcap -Y "http.request"`

系统资源排查

命令	用途	示例
`top` / `htop`	查看进程资源占用	`top -o %CPU`
`vmstat <interval>`	查看系统整体资源	`vmstat 1 5`
`iostat -x <interval>`	磁盘 I/O 性能	`iostat -x 1`
`sar -n DEV <interval>`	网络接口流量统计	`sar -n DEV 1 5`
`free -h`	内存使用情况	`free -h`
`df -h`	磁盘空间使用	`df -h`
`du -sh <dir>`	目录大小	`du -sh /var/log`

日志排查

命令	用途	示例
`tail -f <file>`	实时追踪日志	`tail -f /var/log/nginx/access.log`
`grep <pattern> <file>`	搜索日志内容	`grep "ERROR" /var/log/app.log \| tail -50`
`journalctl -u <service>`	查看 systemd 服务日志	`journalctl -u nginx --since "1 hour ago"`
`dmesg -T`	查看内核日志	`dmesg -T \| tail -20`

四层排查策略

故障现象	排查步骤
网站打不开	1. `ping` 测试连通性 → 2. `traceroute` 路由追踪 → 3. `telnet <ip>:80/443` 端口测试 → 4. `curl -I` 检查 HTTP 响应 → 5. 检查本地 `/etc/hosts` 和 DNS
接口响应慢	1. `curl -w` 分阶段计时（DNS/TCP/SSL/TTFB）→ 2. `tcpdump` 抓包分析重传 → 3. `ss -tanp` 查看连接队列 → 4. 服务器端 `top` / `iostat` 检查资源
连接被拒绝	1. `ss -tlnp` 确认端口是否在监听 → 2. `curl -v` 查看具体错误 → 3. 检查防火墙规则 → 4. 确认服务进程是否运行
丢包严重	1. `ping -n 100` 统计丢包率 → 2. `mtr` 定位丢包跳 → 3. `tcpdump` 抓包分析重传 → 4. 检查网卡错误计数 (`ip -s link`)
DNS 解析异常	1. `dig +trace` 递归追踪 → 2. 对比公共 DNS 和内网 DNS 结果 → 3. `nslookup` 分别查询 A/MX/NS 记录 → 4. 检查 `/etc/resolv.conf` 配置

运维监控与网络排查工具 ​

Zabbix ​

架构 ​

监控项 (Item)、触发器 (Trigger)、告警 (Action) ​

监控项 (Item) ​

触发器 (Trigger) ​

告警配置 (Action) ​

自动发现 (Auto Discovery) ​

网络自动发现 (Network Discovery) ​

主动注册 (Active Agent Auto-registration) ​

低级别发现 (LLD - Low Level Discovery) ​

模板使用 (Template) ​

Docker 部署示例 ​

Nagios ​

架构 ​

NRPE 插件 ​

check_nrpe 配置 ​

远程主机 NRPE 配置 ​

Nagios Server 定义主机和服务 ​

check_nrpe 命令定义 ​

手动测试 NRPE ​

Nagios vs Zabbix 对比表 ​

Netdata ​

实时监控 ​

零配置部署 ​

告警通知 ​

三种监控工具对比选型表 ​

网络排查工具详解 ​

ping / traceroute / mtr ​

ping — 连通性和延迟测试 ​

traceroute — 路由追踪 ​

mtr — 高级路由诊断 ​

netstat / ss ​

netstat — 网络连接和端口状态 ​

ss — 更快的连接查询 ​

tcpdump ​

基本使用 ​

过滤表达式 ​

高级技巧 ​

Wireshark 配合使用 ​

curl / wget ​

curl — HTTP 接口测试 ​

wget — 文件下载和镜像 ​

nslookup / dig ​

nslookup — DNS 查询 ​

dig — 专业 DNS 诊断 ​

常用排查命令速查表 ​

连通性排查 ​

端口和服务排查 ​

HTTP/API 排查 ​

DNS 排查 ​

包抓取分析 ​

系统资源排查 ​

日志排查 ​

四层排查策略 ​

运维监控与网络排查工具

Zabbix

架构

监控项 (Item)、触发器 (Trigger)、告警 (Action)

监控项 (Item)

触发器 (Trigger)

告警配置 (Action)

自动发现 (Auto Discovery)

网络自动发现 (Network Discovery)

主动注册 (Active Agent Auto-registration)

低级别发现 (LLD - Low Level Discovery)

模板使用 (Template)

Docker 部署示例

Nagios

架构

NRPE 插件

check_nrpe 配置

远程主机 NRPE 配置

Nagios Server 定义主机和服务

check_nrpe 命令定义

手动测试 NRPE

Nagios vs Zabbix 对比表

Netdata

实时监控

零配置部署

告警通知

三种监控工具对比选型表

网络排查工具详解

ping / traceroute / mtr

ping — 连通性和延迟测试

traceroute — 路由追踪

mtr — 高级路由诊断

netstat / ss

netstat — 网络连接和端口状态

ss — 更快的连接查询

tcpdump

基本使用

过滤表达式

高级技巧

Wireshark 配合使用

curl / wget

curl — HTTP 接口测试

wget — 文件下载和镜像

nslookup / dig

nslookup — DNS 查询

dig — 专业 DNS 诊断

常用排查命令速查表

连通性排查

端口和服务排查

HTTP/API 排查

DNS 排查

包抓取分析

系统资源排查

日志排查

四层排查策略