云逸工作室 - Linux
type: channel
link: https://blog.hfyunyi.cn/index.php/category/Linux/
items: MySQL 双主热备 + Keepalived 全自动切换方案
items: Docker 在线安装
items: linux服务器传感器输出格式说明
items: 给Docker添加默认的日志文件大小限制
items: Ansible script 模块进阶：异步执行与超时控制详解
items: NTP 时间同步故障排查：`ntpq` 超时但 `ntpdate` 正常
items: Linux 时间同步实战：从 ntpdate 到 chrony 的命令
items: Zabbix 自定义监控指南
items: Zabbix 主动与被动监控模式详解
items: Zabbix 配置详解

MySQL 双主热备 + Keepalived 全自动切换方案
type: item
date: 2026-05-07T14:35:14+08:00
description: 纯热备场景下，用最少的组件（Keepalived + MySQL 原生复制）实现故障全自动切换、自动恢复、零数据丢失。兼容 MySQL 5.7 / 8.0 / MariaDB。一、设计思路1.1 核心问题在做这个方案之前，先想清楚三个问题：问题 1：为什么不用 MHA / ProxySQL？MHA 的 Manager 是单点，且切换后 Manager 自动退出，旧主恢复后仍需人工处理ProxySQL 功能强但引入了新的高可用问题（ProxySQL 本身也要做 HA），纯热备场景下得不偿失Keepalived 极其成熟，几万行 C 代码跑了二十年，比任何"智能"方案都可靠问题 2：为什么用双主而不是主从？传统主从 + VIP 的问题：切换后需要 CHANGE MASTER 反转拓扑。双主（互为主从）的好处是：不管 VIP 在哪台，另一台本来就是它的从库，切换时无需改复制拓扑，VIP 漂过去就能直接写。问题 3：如何防止恢复后 VIP 自动回切？这是整个方案最核心的设计点。来看看常规方案的问题：常规方案（仅用 priority + weight）： db-a priority=100 (主), db-b priority=90 (备) db-a 宕机 → db-a=80, db-b=90 → db-b 接管 ✓ db-a 恢复 → db-a=100, db-b=90 → db-a 抢回 ✗ （不必要的第二次中断！）如果加 nopreempt：nopreempt 只对 Keepalived 进程启动时的状态转换生效对 track_script 引起的动态权重变化不生效更糟的是，如果两台都加 nopreempt，连正常的故障切换都会被阻止本方案的解法：让 health check 脚本利用 MySQL 原生的复制 IO 线程状态来判断"主库是否还活着"：check_mysql.sh 逻辑： 1. MySQL 进程是否存活？→ 否 → exit 1（降权） 2. 我是只读（read_only=ON）吗？ - 是 → IO 线程是否在运行？ - 是 → 主库还活着，我安心当备机 → exit 1（降权，不抢占） - 否 → 主库挂了，我可以竞选 → exit 0 - 否 → 我已是主库 → exit 0这样恢复后的节点自动检测到当前主库还活着，主动降低优先级，不会抢占 VIP。1.2 方案架构应用 ──► VIP (192.168.7.33) ──► 当前主库 (read_only=OFF) └─► 备机 (read_only=ON) 双向复制 (GTID + 半同步) | check 脚本监控复制 IO 线程 判断主库是否存活 → 控制优先级1.3 故障切换时序正常状态： db-a (priority=100, read_only=OFF, IO-thread 活跃) db-b (priority=90, read_only=ON, IO-thread 活跃 → check 返回 1 → 实际=70) db-a 宕机后 8 秒内： db-a check 连续失败 2 次 → priority=80 db-b check 发现 IO 线程断开 → 返回 0 → priority=90 90 > 80 → db-b 接管 VIP notify_master 将 db-b read_only 关闭 db-a 恢复： MySQL 启动，read_only=ON（my.cnf 默认） IO 线程连上 db-b → 活跃 → check 返回 1 → priority=80 db-b 仍是 priority=90 80 < 90 → VIP 留在 db-b（不回切！）1.4 Priority 推演表场景db-a 状态db-a 实际 prioritydb-b 状态db-b 实际 priorityVIP 在初始正常read_only=OFF100read_only=ON, IO 活跃70 (90-20)db-adb-a 宕机MySQL 挂了80 (100-20)read_only=ON, IO 断开90db-bdb-a 恢复read_only=ON, IO 活跃80 (100-20)read_only=OFF90db-b（不回切）db-b 宕机read_only=ON, IO 断开100MySQL 挂了70 (90-20)db-a二、环境信息角色IP初始状态Keepalived prioritydb-a192.168.7.31read_only=ON，等 Keepalived 竞选100db-b192.168.7.32read_only=ON，等 Keepalived 竞选90VIP192.168.7.33——注意：两台 my.cnf 都配置 read…

Docker 在线安装
type: item
date: 2026-04-21T15:17:00+08:00
description: 在云原生时代，Docker 已成为应用打包、交付和运行的事实标准。本文将以 CentOS 7 系统为例，详细介绍如何利用阿里云镜像站在线安装 Docker CE、配置国内镜像加速源、安装 Docker Compose，并演示一个典型的多服务容器化部署流程。一、安装 Docker CE（社区版）1.1 安装必要系统工具首先需要安装 yum-utils，它提供了 yum-config-manager 工具，方便我们管理软件源。sudo yum install -y yum-utils1.2 添加阿里云 Docker 软件源使用阿里云提供的官方仓库地址，能显著提升下载速度和稳定性。yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo1.3 安装 Docker 及相关组件执行以下命令安装 Docker 引擎、CLI 工具、容器运行时以及构建插件和 Compose 插件。sudo yum install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y注：docker-compose-plugin 是 Docker Compose V2 的插件形式，若习惯使用 docker-compose 命令，也可以单独安装传统版本的 Compose（见后文）。1.4 启动 Docker 服务sudo systemctl enable --now docker1.5 校验安装查看 Docker 版本信息，确认安装成功。docker version如果正常显示客户端和服务端版本号，说明 Docker 已正确安装并运行。二、配置国内镜像加速源（重要）由于网络原因，直接从 Docker Hub 拉取镜像可能非常缓慢。通过配置国内镜像加速器，可以大幅提升拉取速度。2.1 创建/编辑 daemon.jsonvim /etc/docker/daemon.json2.2 写入以下内容{ "registry-mirrors": [ "https://51mbg7lq.mirror.aliyuncs.com", "https://9cpn8tt6.mirror.aliyuncs.com", "https://registry.docker-cn.com", "https://a0f4d5484dea442caf5d1193f09abdd4.mirror.swr.myhuaweicloud.com", "https://do.nark.eu.org", "https://dc.j8.work", "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://docker.mirrors.ustc.edu.cn", "https://docker.nju.edu.cn", "https://hub-mirror.c.163.com", "https://mirror.baidubce.com", "https://ccr.ccs.tencentyun.com" ] }说明：这里列出了多个国内常用镜像源（阿里云、华为云、中科大、南京大学、网易、百度、腾讯云等），按优先级排列。你可以根据实际网络情况增删。2.3 重新加载配置并重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker2.4 设置开机自启sudo systemctl enable docker完成上述步骤后，Docker 的基础环境就准备好了。三、安装 Docker Compose（可选）如果你的项目需要使用 docker-compose.yml 进行多容器编排，建议安装 Docker Compose。 若已通过 docker-compose-plugin 安装了 V2 版本，可以直接使用 docker compose 命令（注意中间没有横线）。但传统 docker-compose 命令在很多教程中仍被广泛使用，因此下面也提供独立安装方法。3.1 下载稳定版二进制文件以 v2.5.1 为例（你也可以到 GitHub Releases 查看最新版本号）：sudo curl -L "https://github.com/docker/compose/releases/download/v2.5.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/doc…

linux服务器传感器输出格式说明
type: item
date: 2026-04-16T11:34:00+08:00
description: 无论你是用 ipmitool、sensors 还是 BMC 网页，传感器数据格式五花八门。本文带你一次搞懂！前言服务器硬件监控是运维的基本功。但当你敲下 ipmitool sensor list 或者 sensors 命令时，面对满屏的数字、英文缩写、竖线分隔符，是不是经常一脸懵？为什么有的行有 10 列，有的只有 6 列？那个 na 到底是不是故障？本文将系统地介绍 4 种最常见的传感器输出格式，逐一拆解每一列的真正含义，并教你 3 秒钟快速定位异常。格式一：ipmitool sensor list – 完整阈值格式（10 列）这是最标准、最完整的传感器输出，常见于华为、曙光、HPE 等主流服务器。输出示例+VCORE0 | 1.700 | Volts | ok | 1.000 | 1.100 | 1.200 | 2.500 | 2.600 | 2.700 PCH_Temp | 44.000 | degrees C | ok | -6.000 | -4.000 | -2.000 | 79.000 | 81.000 | 83.000 列拆解（从第 1 列到第 10 列）列号含义说明1传感器名称如 +VCORE0（CPU核心电压）、PCH_Temp（芯片组温度）2当前读数实时值3单位Volts、degrees C、RPM、Watts、Amps、percent、discrete（离散状态）4状态ok=正常，cr=临界，nc=非临界，na=无数据5LNR低不可恢复阈值 – 低于此值硬件可能损坏6LC低临界阈值 – 严重告警7LNC低非临界阈值 – 警告，性能可能下降8UNC高非临界阈值 – 警告，建议检查9UC高临界阈值 – 严重告警10UNR高不可恢复阈值 – 高于此值硬件可能损坏如何判断异常？状态列不是 ok → 立即处理。当前值 < LNC（第7列）或 > UNC（第8列） → 发出警告。当前值 < LC（第6列）或 > UC（第9列） → 严重告警。当前值 < LNR（第5列）或 > UNR（第10列） → 硬件面临损坏风险。注意：未设置的阈值会显示 na，表示该级阈值不存在。格式二：简化阈值格式（6 列）很多服务器（如浪潮 NF5270M3、部分 Supermicro）只输出 低阈值 + 高阈值，没有细分的 LNR/LC/LNC。输出示例CPU0_VTT | 0.990 | Volts | ok | 0.720 | 1.180 P1V1_PCH | 1.090 | Volts | ok | 0.810 | 1.240 DIMM_0 | 29.000 | degrees C | ok | na | 90.000 列拆解（6 列）列号含义1传感器名称2当前读数3单位4状态5低阈值（下限）6高阈值（上限）判断逻辑当前值 < 低阈值 或 > 高阈值 → 异常。若阈值显示 na，表示未设置该方向阈值（例如只有高阈值，没有低阈值）。这种格式简单直观，但缺少“严重程度”分级。建议结合厂商手册了解阈值含义。格式三：离散传感器格式（discrete）有些传感器不是连续的数值，而是状态标志。它们用 十六进制数 表示事件。输出示例CPU0_Status | 0x0 | discrete | 0x8080| na | na | na | na | na | na PSU_Redundant | 0x0 | discrete | 0x0180| na | na | na | na | na | na Fan1_Present | 0x0 | discrete | 0x0280| na | na | na | na | na | na 列含义当前值：通常 0x0 表示正常/无事件。非 0x0 可能表示故障或特定状态（如冗余丢失、设备不在位）。状态列（第4列）：对于离散传感器，这一列常显示 0x**** 格式的事件码，而不是 ok。需要查阅 IPMI OEM 手册才能解析每个 bit 的含义。运维建议大部分离散传感器当前值为 0x0 且状态也是 0x0 或 0x0080 时可视为正常。如果看到 0x01、0x02 等非零值，或状态码有明显变化，需要进一步排查。一个常见的例外：Pwr Unit Redund 显示 0x1200 可能表示电源冗余降级，虽然当前值为 0x0，但状态码给出了详细原因。格式四：lm-sensors 命令输出（Linux 常用）如果你安装了 lm-sensors 包，sensors 命令会提供更人性化的输出，常用于 PC 服务器或工作站。输出示例coretemp-isa-0000 Adapter: ISA adapter Package id 0: +45.0°C (high = +85.0°C, crit = +95.0°C) …

给Docker添加默认的日志文件大小限制
type: item
date: 2026-04-16T01:44:22+08:00
description: 在使用Docker容器的过程中，日志管理是一个容易被忽视但又至关重要的环节。默认情况下，Docker会使用json-file日志驱动，并将容器的标准输出（stdout）和标准错误（stderr）全部记录到宿主机上的JSON文件中。如果不加任何限制，这些日志文件会无休止地增长，最终占满磁盘空间，导致容器异常甚至整个宿主机服务瘫痪。本文将详细介绍如何通过修改Docker守护进程的配置文件，为所有容器统一设置日志轮转策略，并解释每个参数的实际含义。为什么需要限制容器日志？防止磁盘写满：一个频繁输出日志的容器，一天可能产生几十GB的日志文件。提升可维护性：单个巨大的日志文件难以用普通文本工具查看，也拖慢日志分析效率。降低I/O压力：轮转后的日志可以压缩或删除，减少对磁盘的持续写入。配置步骤1. 编辑Docker配置文件使用你熟悉的编辑器（如vim、nano）打开Docker的守护进程配置文件：sudo vim /etc/docker/daemon.json如果该文件不存在，可以新建一个。2. 添加日志相关参数在daemon.json中写入以下内容：{ "log-driver": "json-file", "log-opts": { "max-size": "500m", "max-file": "3" } }注意：如果文件中已有其他配置（如镜像加速器、 insecure registries等），只需将log-driver和log-opts作为顶层字段合并进去。例如：{ "registry-mirrors": ["https://your-mirror.com"], "log-driver": "json-file", "log-opts": { "max-size": "500m", "max-file": "3" } }3. 参数详解参数说明log-driver指定日志驱动。json-file是Docker默认驱动，也是我们想要配置的目标。max-size单个日志文件的最大大小。超过该值后会自动轮转（rotate）。示例中的500m表示500兆字节。支持单位：k(KB)、m(MB)、g(GB)。max-file最多保留的日志文件数量。轮转后会保留max-file个旧文件，超出部分将被删除。例如：当前日志container.log，轮转后变为container.log.1、container.log.2、container.log.3，再产生新日志时会删除最早的container.log.3。4. 重启Docker服务配置修改后，需要重新加载并重启Docker守护进程，使配置生效：sudo systemctl daemon-reload sudo systemctl restart docker或者在某些使用service命令的系统中：sudo service docker restart5. 验证配置是否生效可以通过以下命令查看Docker的当前配置，确认日志参数已加载：docker info | grep -A 5 "Logging Driver"期望输出类似：Logging Driver: json-file WARNING: No swap limit support进一步检查某个运行中容器的日志配置：docker inspect <容器名或ID> | grep -A 3 "LogConfig"输出中应显示："LogConfig": { "Type": "json-file", "Config": { "max-file": "3", "max-size": "500m" } }注意事项仅对新容器生效：修改daemon.json并重启Docker后，已经存在的容器不会自动应用新的日志限制。你需要删除并重新创建这些容器（例如docker rm后docker run），或者在创建容器时通过--log-opt参数单独指定。已有日志文件不会被清理：配置只控制未来产生的日志的轮转行为。宿主机上已经积累的旧日志文件需要手动删除，例如：sudo rm /var/lib/docker/containers/*/*.log替代方案：如果不想全局修改，也可以在运行单个容器时直接指定日志选项：docker run -d --log-opt max-size=500m --log-opt max-file=3 your-image日志驱动兼容性：json-file是最常用的驱动，但Docker还支持syslog、journald、fluentd等。如果使用其他驱动，需要确认它们是否支持max-size和max-file（部分驱动不支持）。

Ansible script 模块进阶：异步执行与超时控制详解
type: item
date: 2026-04-15T15:43:00+08:00
description: 在使用 Ansible 进行自动化运维时，script 模块是我们推送并执行本地脚本的利器。然而，当目标主机上的脚本运行时间较长（如系统巡检、数据备份、批量处理），或者脚本本身存在阻塞风险（如等待输入、死循环、网络超时）时，Ansible 的默认同步执行模式会导致整个 Playbook 卡住，直到脚本结束——甚至永久等待。本文将详细介绍如何通过 异步执行 和 超时控制 来解决这些问题，让 script 模块更健壮、更可控。一、问题场景：当脚本“不听话”时你可能会遇到这样的情况：- name: 运行健康检查脚本 script: health_check.sh如果 health_check.sh 在某些主机上需要运行 10 分钟，或者因为网络挂载问题而阻塞，那么 Ansible 会一直停留在该任务上，无法继续处理其他主机，甚至无法响应 Ctrl+C。这就是同步执行的弊端。为此，Ansible 提供了异步执行机制，以及精细的超时控制参数。二、异步执行核心参数：async 与 poll要让一个任务异步运行，只需在任务中添加两个参数：async 和 poll。1. async —— 最大允许运行时长作用：指定任务在被管理节点上允许运行的最大秒数。超时后任务会被标记为失败。必选条件：一旦使用 async，就必须同时指定 poll（除非 poll=0 有特殊含义）。示例：async: 600 表示任务最长运行 10 分钟。2. poll —— 轮询间隔作用：Ansible 控制节点每隔多少秒去检查一次远程任务是否完成。取值：poll > 0：Ansible 会在后台轮询，直到任务结束或超时。此时 Playbook 会“停”在该任务，但不会阻塞 SSH 连接，控制节点可以定期获取状态。poll = 0：启动任务后立即继续执行后续任务（“发射后不管”）。此时需要用 async_status 模块手动查询结果。示例：poll: 10 表示每 10 秒检查一次。3. 经典组合- name: 异步执行脚本，每10秒检查一次，最长10分钟 script: long_task.sh async: 600 poll: 10运行逻辑：Ansible 将脚本上传并启动一个后台作业。每隔 10 秒询问该作业是否完成。如果 600 秒内完成 → 成功。如果超过 600 秒仍未完成 → 失败（async 超时）。三、更严格的保护：timeout 参数async 控制的是远程脚本的运行时长，而 Ansible 任务本身还可能受到网络抖动、控制机负载等因素的影响。timeout 参数（任务级超时）提供了第二道防线。作用：规定整个 Ansible 任务（包括文件传输、轮询等待、网络通信）的最大执行时间，超时后强制中断任务。与 async 的区别：参数控制范围超时后影响async远程脚本的实际执行时间仅标记任务失败，不中断 SSH 连接timeout整个 Ansible 任务生命周期强制杀死任务进程，抛出异常建议：当使用异步时，将 timeout 设置为比 async 稍大一些的值（考虑轮询开销和网络延迟）。完整示例：- name: 安全运行长脚本 script: heavy_check.sh async: 1200 # 脚本最多跑20分钟 poll: 30 # 每30秒查一次 timeout: 1500 # 整个任务最多等待25分钟 ignore_errors: yes # 可选：即使超时也不停止整个Playbook四、实战案例：批量服务器巡检假设我们有一个巡检脚本 collect_info.sh，在某些老旧服务器上可能运行超过 5 分钟。我们希望：最多等待 10 分钟；每 15 秒检查一次进度；如果某台主机卡死，不阻塞其他主机。Playbook 片段：- hosts: all gather_facts: no tasks: - name: 分发并执行巡检脚本（异步+超时） script: collect_info.sh async: 600 poll: 15 timeout: 720 register: result ignore_errors: true - name: 显示执行结果 debug: msg: | 主机 {{ inventory_hostname }} 脚本输出： when: result is defined如果某个节点 600 秒后仍未完成，Ansible 会将其标记为失败，但继续执行其他主机的后续任务。五、注意事项与最佳实践1. 不要对所有任务都使用异步异步会增加控制节点的轮询开销。对于几秒钟就能完成的脚本，同步执行更简单高效。2. poll: 0 的特殊用法当 poll: …

NTP 时间同步故障排查：`ntpq` 超时但 `ntpdate` 正常
type: item
date: 2026-04-15T10:15:27+08:00
description: 在 CentOS 6 运维中，你是否遇到过这样的场景：ntpdate 能正常同步时间，但 ntpq -p 却始终超时，NTP 服务明明在运行却“查无可查”？本文将通过一个真实案例，深入分析背后的原因，给出简洁有效的解决方案，并系统介绍 ntpd 的配置参数与典型场景。一、问题现象某 CentOS 6 服务器在配置 NTP 时间同步时表现出异常行为：[user@host ~]# ntpdate -q ntp-server.example.com server ntp-server.example.com, stratum 2, offset 6.870186, delay 0.03954 15 Apr 10:08:16 ntpdate[18825]: step time server ntp-server.example.com offset 6.870186 sec [user@host ~]# ntpq -p localhost: timed out, nothing received ***Request timed out观察结果：ntpdate -q 可以正常查询远程 NTP 服务器，并成功步进系统时间（偏移约 6.87 秒）。ntpq -p 却始终超时，无法获取本地 NTP 服务的任何状态信息。检查 NTP 服务状态，显示进程正在运行：[user@host ~]# service ntpd status ntpd (pid 11324) is running...服务进程存在，端口也在监听，为什么 ntpq 就是连不上？二、排查过程2.1 确认 NTP 服务是否正常监听[user@host ~]# netstat -ulnp | grep :123 udp 0 0 0.0.0.0:123 0.0.0.0:* 11324/ntpd udp 0 0 :::123 :::* 11324/ntpd输出显示 ntpd 已正确监听在所有接口的 UDP 123 端口，服务本身没有问题。2.2 检查防火墙规则ntpq 需要通过本地回环接口（lo，127.0.0.1）与本地 ntpd 进程通信。如果防火墙屏蔽了回环流量，就会导致通信失败。查看当前 iptables 配置：[user@host ~]# iptables -L -n Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 10.0.0.0/8 0.0.0.0/0 ACCEPT all -- 192.168.0.0/16 0.0.0.0/0 ...（其他业务网段规则）关键发现：INPUT 链默认策略为 DROP。没有任何规则允许来自 127.0.0.1 或接口 lo 的流量。这意味着所有进入本机的数据包，如果不匹配已有连接或显式允许的源网段，都会被丢弃。而 ntpq 发起的本地连接正是这样一个“全新”的连接。2.3 为什么 ntpdate 可以工作，ntpq 却不行？ntpdate 直接向外部的 NTP 服务器发起 UDP 请求，远程服务器的响应包属于 RELATED,ESTABLISHED 状态，会被第一条 ACCEPT 规则放行，因此能正常完成查询和时间同步。ntpq 与本地 ntpd 的通信是全新的连接：源 IP 127.0.0.1，目的 IP 127.0.0.1，不属于任何已有连接，也不匹配任何显式 ACCEPT 规则，于是被默认 DROP 策略无情丢弃，客户端等待超时。三、解决方案添加一条规则，允许本地回环接口（lo）上的所有流量，并将其插入到 INPUT 链的最前面：iptables -I INPUT 1 -i lo -j ACCEPT验证规则已生效：[user@host ~]# iptables -L INPUT -n --line-number Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 /* lo */ 2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ...持久化规则（重启不失效）CentOS 6 / RHEL 6 使用以下命令保存规则：service iptables save # 或者 iptables-save > /etc/sysconfi…

Linux 时间同步实战：从 ntpdate 到 chrony 的命令
type: item
date: 2026-04-15T09:45:58+08:00
description: 在 Linux 系统管理中，精确的系统时间是日志审计、分布式协作、安全认证的基石。时间偏差可能导致认证失败、数据错乱甚至服务中断。本文将系统介绍三大主流时间同步工具：经典的 ntpdate（一次性同步）、传统的 ntpd（守护进程）以及现代的 chrony，从基础用法、诊断命令到选型建议，为你提供一份完整的操作参考。一、ntpdate：经典的一次性时间同步工具ntpdate 是一个历史悠久的命令行工具，用于手动、一次性地通过网络时间协议（NTP）调整系统时间。它简单直接，但在最新 Linux 发行版中逐渐被 chrony 取代，在老旧系统或临时校正场景仍有使用价值。1.1 基本用法sudo ntpdate [选项] NTP服务器地址核心功能：立即向指定 NTP 服务器查询时间，并跳跃式或平滑式修改系统时钟。常见示例（使用阿里云 NTP，推荐 -u 参数避免防火墙问题）：sudo ntpdate -u ntp.aliyun.com1.2 常用选项选项作用适用场景-u使用非特权端口（>1024）发送请求推荐日常使用，穿透防火墙-q仅查询时间偏移，不修改系统时钟测试连通性、查看偏差-d调试模式，显示详细同步过程排查同步故障-b强制使用“跳跃”方式（step），即使偏差小于 0.5 秒系统启动时快速设时-B强制使用“平滑”调整（slew）避免时间跳跃影响应用-t指定超时时间（秒）高延迟网络1.3 注意事项与常见错误设置计划任务自动同步（不推荐生产环境）：0 * * * * /usr/sbin/ntpdate -u ntp.aliyun.com > /dev/null 2>&1同步硬件时钟：ntpdate 只改系统时间，需额外执行 hwclock -w 写入 BIOS。常见错误：command not found：安装 ntpdate 包（Ubuntu: apt install ntpdate，CentOS: yum install ntpdate）。no server suitable for synchronization found：检查网络、防火墙，确认是否遗漏 -u。冲突提醒：如果系统已运行 ntpd 或 chronyd 服务，直接运行 ntpdate 可能失败或建议停止服务。1.4 时间调整机制：Step vs SlewStep（跳跃）：误差 > 0.5 秒时，时间直接跳变。速度快，但可能打断日志连续性或服务状态。Slew（平滑）：误差 < 0.5 秒时，通过微调时钟频率逐渐修正。对系统影响小，但耗时长。二、ntpd：传统 NTP 守护进程ntpd 是经典 NTP 协议的守护进程实现，通过持续跟踪多个时间源、平滑调整系统时钟，保证长期准确。它在 RHEL/CentOS 6、Ubuntu 14.04 及更早版本中广泛使用。2.1 核心配置文件：/etc/ntp.conf典型配置片段：server ntp.aliyun.com iburst server time.cloudflare.com iburst restrict default kod nomodify notrap nopeer noquery restrict 127.0.0.1iburst：加速初始同步。restrict：控制访问权限。启动服务：sudo systemctl start ntpd # 或 service ntpd start sudo systemctl enable ntpd2.2 主要诊断命令2.2.1 ntpq —— 查询 NTP 守护进程状态（最常用）ntpq 通过 mode 6 协议获取 ntpd 内部信息，无需 root。命令作用ntpq -p列出所有时间源（类似 chronyc sources）ntpq -c as显示所有关联（association ID）的简要状态ntpq -c "rv <assoc_id>"查看特定关联的详细变量ntpq -c sysinfo显示系统时间同步整体信息ntpq -c peers同 -pntpq -p 输出示例： remote refid st t when poll reach delay offset jitter ============================================================================== *ntp.aliyun.com 10.137.38.86 2 u 34 64 377 13.427 -0.213 1.002 +time.cloudflare 10.136.38.86 3 u 12 64 377 21.104 +0.045 0.875 -ntp.ubuntu.com 193.79.237.14 2 u 52 …

Zabbix 自定义监控指南
type: item
date: 2026-04-14T21:42:10+08:00
description: 概述默认模板监控项通过 Zabbix 客户端 + 各种模板可以实现以下监控：类别监控内容CPU使用率、负载、上下文切换等磁盘磁盘空间、I/O、inode 等内存内存使用、swap、缓存等网络网卡流量、丢包、错误等系统进程数、登录用户、运行时长等自定义监控的应用场景默认模板中没有需要的监控项特定业务指标自定义应用程序状态特定硬件设备模板中监控项过多精简监控项，减少资源消耗只关注关键指标自定义监控全流程┌─────────────────────────────────────────────────────────────┐ │ 客户端 │ │ 1. 通过命令/脚本取出对应的值 │ │ 2. 按 Zabbix 格式书写配置文件，创建键值对 │ │ 3. 重启客户端并测试键值 │ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 服务端 │ │ 1. 服务端测试键值是否可用 │ │ 2. Web 界面：键值与监控项关联 │ │ 3. Web 界面：配置触发器 │ │ 4. Web 界面：创建图形 │ └─────────────────────────────────────────────────────────────┘详细步骤步骤位置操作说明1客户端通过命令/脚本取出对应的值获取监控数据2客户端创建键值对配置文件键值对 key 用于获取客户端数据3客户端重启客户端并测试本地验证4服务端测试键值是否可用使用 zabbix_get5Web键值与监控项关联创建监控项6Web配置触发器设置告警条件7Web创建图形可视化展示实战案例案例一：监控 MySQL 3306 端口1. 确定监控命令# 检查 3306 端口是否存在 ss -lntpu | grep -w 3306 | wc -l # 返回 1 表示端口存在，返回 0 表示不存在2. 创建配置文件# 进入配置目录 cd /etc/zabbix/zabbix_agent2.d/ # 创建配置文件 cat > 3306.conf << 'EOF' # 格式：UserParameter=key,cmd # UserParameter=固定写法，表示要自定义键值 # key 表示键值名称，建议使用"单词.单词"格式 # cmd 表示命令或脚本 UserParameter=check.mysql,ss -lntpu | grep -w 3306 | wc -l EOF3. 重启客户端systemctl restart zabbix-agent24. 本地测试zabbix_agent2 -t check.mysql # 预期输出： # check.mysql [s|1]5. 服务端测试# 安装测试工具 yum install -y zabbix-get # 测试键值 zabbix_get -s 192.168.5.134 -k check.mysql # 预期输出：1 或 06. Web 界面配置创建监控项：进入 Configuration → Hosts → 选择主机 → Items点击 Create item填写信息：Name: MySQL 3306 Port StatusKey: check.mysqlType of information: Numeric (unsigned)Update interval: 1m创建触发器：进入 Triggers 选项卡点击 Create trigger填写信息：Name: MySQL 3306 port is downExpression: {Host:check.mysql.last()}=0Severity: High案例二：带参数的自定义监控目标检查指定用户是否存在异地登录。实现思路使用 lastlog 命令获取用户最后登录的 IP在服务端通过触发器进行对比判断命令选择# lastlog 可以显示所有用户的最后登录信息 lastlog | grep -w root | awk '{print $3}' # 输出示例：192.168.1.100创建带参数的配置cat > /etc/zabbix/zabbix_agent2.d/user_login.conf << 'EOF' # 注意：使用 $$3 而不是 $3，避免与 Zabbix 参数冲突 UserParameter=user.login.check[*],lastlog | grep -w "$1" | awk '{print $$3}' EOF测试# 本地测试 zabbix_…

Zabbix 主动与被动监控模式详解
type: item
date: 2026-04-14T21:41:29+08:00
description: 概述Zabbix 支持两种主要的工作模式：被动模式（Passive） 和 主动模式（Active）。这两种模式是站在 Zabbix Agent 角度来说的工作模式。被动模式工作原理在被动模式下，Zabbix Agent 被动接受 Zabbix Server 周期性发送过来的数据收集指令：Zabbix Server 根据主机关联的模板中的监控项和数据采集间隔时间，周期性打开随机端口向 Zabbix Agent 服务器的 10050 端口发起 TCP 连接发送获取监控项数据的指令Zabbix Agent 接收到指令后采集数据并返回特点：Zabbix Server 发送什么指令，Zabbix Agent 就收集什么数据Zabbix Server 什么时候发送，Zabbix Agent 就什么时候采集Zabbix Server 不发送，Zabbix Agent 就一直不响应被动模式的优点✅ 配置简单，安装后即可使用✅ Zabbix 的默认工作模式✅ 无需额外配置被动模式的缺点❌ 会加大 Zabbix Server 的工作量❌ 在数百甚至数千台服务器的环境下，Zabbix Server 需要轮询向每个 Agent 发送数据采集指令❌ Zabbix Server 负载高时可能导致不能及时获取最新数据被动模式端口状态Zabbix Server (随机端口) → Zabbix Agent:10050Server 端会产生大量随机端口连接。被动模式配置Zabbix Agent 默认即为被动模式，只需配置 Server 参数：# /etc/zabbix/zabbix_agent2.conf Server=192.168.5.3主动模式工作原理在主动模式下，Zabbix Agent 主动向 Zabbix Server 的 10051 端口发起 TCP 连接请求：Zabbix Agent 主动连接到 Zabbix Server获取自己的监控项和数据采集间隔周期时间根据监控项主动采集数据将数据返回给 Zabbix Server特点：必须配置 ServerActive 指定 Zabbix Server 的 IP 或主机名Agent 主动获取监控项列表并定期上报数据不再需要 Server 向 Agent 发起连接请求主动模式的优点✅ 减轻 Zabbix Server 打开的本地随机端口和进程数✅ 在一定程度上减轻 Zabbix Server 的压力✅ 适合大规模监控环境✅ 支持 NAT/防火墙后的主机监控主动模式的缺点❌ 配置相对复杂❌ Zabbix 6.0 及以下版本主动模式主机可用性显示灰色（Zabbix 6.2+ 已修复）❌ 某些监控项不支持主动模式主动模式配置编辑 /etc/zabbix/zabbix_agent2.conf：PidFile=/var/run/zabbix/zabbix_agent2.pid LogFile=/var/log/zabbix/zabbix_agent2.log LogFileSize=0 Server=192.168.5.3 ServerActive=192.168.5.3 Hostname=192.168.5.134 Include=/etc/zabbix/zabbix_agent2.d/*.conf ControlSocket=/tmp/agent.sock Include=./zabbix_agent2.d/plugins.d/*.conf关键配置项：配置项说明Server被动模式服务端地址（建议同时配置，用于远程命令等）ServerActive主动模式服务端地址Hostname本机标识，必须与 Zabbix Server 配置的主机名一致版本注意事项重要：Zabbix 6.0 及以下版本使用主动模式时，主机可用性可能一直显示为灰色。建议升级到 Zabbix 6.2 或更高版本。模式对比特性被动模式主动模式连接方向Server → AgentAgent → ServerServer 端口随机端口10051Agent 端口10050随机端口配置复杂度简单较复杂Server 负载高低适用规模中小规模大规模NAT/防火墙支持受限良好监控项支持全部部分不支持Zabbix Proxy架构图Zabbix Agent → Zabbix Proxy → Zabbix Server ↓ Proxy DatabaseZabbix Proxy vs Zabbix Server功能Zabbix ProxyZabbix Server轻量级✅ 是相对重量级图形界面❌ 无✅ 带图形控制界面独立工作✅ 可以独立采集数据并存储✅ 数据采集、存储、分析、展示于一体易维护✅ 设置完成后基本无需管理维护也不难独立数据库保留少量最近数据保留指定时间内的所…

Zabbix 配置详解
type: item
date: 2026-04-14T21:40:32+08:00
description: 服务端配置1. 重要文件和目录文件/目录说明/etc/zabbix/zabbix_server.conf服务端主配置文件/var/log/zabbix/zabbix_server.log服务端日志文件/usr/lib/systemd/system/zabbix-server-mysql.serviceSystemd 服务文件（编译安装需手动创建，yum 安装自动生成）/usr/local/share/zabbix/alertscripts/告警脚本目录（如微信推送脚本）2. 配置文件详解2.1 基本配置示例# 查看生效的配置项 grep '^[a-Z]' /etc/zabbix/zabbix_server.conf典型配置：ListenPort=10051 LogFile=/var/log/zabbix/zabbix_server.log DBHost=localhost DBName=zabbix DBUser=alick DBPassword=zzjjhh123 Timeout=4 LogSlowQueries=3000 StatsAllowedIP=127.0.0.12.2 配置项说明配置项说明默认值ListenPort服务端监听端口10051LogFile日志文件位置-DBHost数据库服务器地址localhostDBName数据库名称zabbixDBUser数据库用户名-DBPassword数据库密码-DBPort数据库端口3306Timeout监控项超时时间（秒）3LogSlowQueries慢查询日志阈值（毫秒）0（不记录）StatsAllowedIP允许查看统计信息的 IP127.0.0.1StartPollers轮询进程数5StartTrapperstrapper 进程数5StartDiscoverers自动发现进程数13. 服务端常用操作# 启动服务 systemctl start zabbix-server # 停止服务 systemctl stop zabbix-server # 重启服务 systemctl restart zabbix-server # 查看状态 systemctl status zabbix-server # 查看日志 tail -f /var/log/zabbix/zabbix_server.log # 测试配置文件 zabbix_server -T客户端配置1. 重要文件和目录文件/目录说明/etc/zabbix/zabbix_agent2.confAgent2 主配置文件/etc/zabbix/zabbix_agent2.d/子配置文件目录，用于自定义监控/usr/lib/systemd/system/zabbix-agent2.serviceSystemd 服务文件/var/log/zabbix/日志目录/var/run/zabbix/PID 文件目录2. 安装文件列表rpm -ql zabbix-agent2主要文件：/etc/logrotate.d/zabbix-agent2 /etc/zabbix/zabbix_agent2.conf /etc/zabbix/zabbix_agent2.d/ /etc/zabbix/zabbix_agent2.d/plugins.d/ /usr/lib/systemd/system/zabbix-agent2.service /usr/sbin/zabbix_agent2 /usr/share/doc/zabbix-agent2-6.0.38/ /var/log/zabbix /var/run/zabbix3. 配置文件详解3.1 基本配置示例# 查看生效的配置项 grep '^[a-Z]' /etc/zabbix/zabbix_agent2.conf典型配置：PidFile=/run/zabbix/zabbix_agent2.pid LogFile=/var/log/zabbix/zabbix_agent2.log LogFileSize=0 Server=127.0.0.1 ServerActive=127.0.0.1 Hostname=Zabbix server Include=/etc/zabbix/zabbix_agent2.d/*.conf PluginSocket=/run/zabbix/agent.plugin.sock ControlSocket=/run/zabbix/agent.sock Include=./zabbix_agent2.d/plugins.d/*.conf3.2 关键配置项说明配置项说明Server被动模式：允许连接的服务端 IP 地址，多个 IP 用逗号分隔ServerActive主动模式：服务…