Linux

概述 凌晨三点，你被告警吵醒——线上数据库写入失败，Nginx 起不来，SSH 登录卡顿。登上服务器一查，df -h 显示根分区 100%。这种事每个运维都遇到过，磁盘满大概是生产环境最高频的故障类型之一，根据实际运维统计，磁盘相关告警占比约 15%-20%。 但磁盘满不是一个简单问题。df -h 看到的 100% 可能并不是全部真相： inode 耗尽：磁盘空间还有剩余，但文件系统inode用完了，照样报 No space left on device。这种问题更隐蔽，排查难度也更大。 已删除文件未释放：rm 删了大文件，df 显示空间没变。因为还有进程持有文件描述符，数据块并没有真正释放。 预留空间：ext4 默认预留 5% 空间给 root，400GB 的数据盘就有 20GB 被"藏"起来了。 这篇文章把磁盘空间和 inode 管理的排查思路、清理策略、预防机制一次说透。所有命令都在 Ubuntu 22.04 和 CentOS 7.9 上实测过，能直接拿去用。 磁盘空间的两个维度：blocks 与 inode 很多人对磁盘空间的理解只停留在"还剩多少 GB"这个层面。但 Linux 文件系统管理的是两个独立资源：数据块（blocks） 和 索引节点（inode）。 打个比方：文件系统像一个停车场。blocks 是停车位，inode 是停车记录。停车场可能还有空车位（blocks 没满），但记录本写满了（inode 耗尽），新来的车也停不进去。 inode 是什么 inode（Index Node，索引节点）是文件系统里描述文件元数据的数据结构。每个文件或目录对应一个 inode，存储了以下信息： 元数据字段 说明 文件类型 普通文件、目录、符号链接等 权限信息 rwx 权限位 所有者 uid 和 gid 文件大小 字节数 时间戳 atime / mtime / ctime 数据块指针 指向实际数据存储位置的索引 硬链接数 指向该 inode 的目录项数量 注意一个关键点：inode 不存储文件名。文件名存在目录项（dentry）中，目录项将文件名映射到 inode 编号。这也是为什么硬链接能存在——多个文件名可以指向同一个 inode。...

概述 一次线上故障让我彻底重视起时间同步这件事。某天凌晨，业务反馈 HTTPS 请求大面积失败，报错 SSL_ERROR_BAD_CERTIFICATE。排查了两个小时，翻遍网络拓扑、防火墙规则、证书配置，都没问题。最后有人无意间看了眼系统时间——比真实时间快了 12 秒。就这 12 秒，让服务器在验证客户端证书的 notBefore 时间时判定"证书尚未生效"，拒绝了所有握手。 这不是孤例。时间不同步在分布式系统里是一颗隐形地雷：Kerberos 认证对时间偏差容忍只有 5 分钟，超了直接拒登；Kubernetes 节点时间偏差过大，kubelet 心跳过期，Pod 被驱逐；MySQL 主从复制依赖时间戳，偏差大会导致 binlog 顺序错乱；分布式事务的二阶段提交，节点间时钟不同步会让超时判断失效。 时间同步听起来简单——装个 NTP 客户端，指向时间服务器就完事了。但生产环境的坑远不止于此：虚拟机时钟漂移、容器里没有 NTP 守护进程、多机房时钟源选型、chrony 和 ntpd 冲突、证书续期任务因时间跳变失败。这篇文章把这些问题一次性讲清楚，给出生产可用的配置和排障思路。 从 ntpd 到 chrony：为什么换了 ntpd 是老牌的时间同步服务，跑了二十多年。但从 RHEL 8、CentOS 8、Ubuntu 20.04 开始，主流发行版默认都换成了 chrony。原因不是 ntpd 不好，而是 chrony 在几个关键场景下表现更好： 对比维度 ntpd chrony 首次同步速度 慢，需要逐步逼近 快，iburst 几秒内拉到毫秒级 网络中断后恢复 慢，重新同步耗时长 快，历史漂移率记录加速收敛 虚拟机时钟漂移 处理差，容易抖动 处理好，driftfile 自动补偿 资源占用 较高 更低 离线保持 漂移大 driftfile 让离线也能维持 是否支持时间服务器功能 是 是（allow 指令） 关键区别在首次同步速度。ntpd 出于"不能让时间跳变"的设计哲学，启动后是缓慢逼近目标时间，可能要十几分钟才稳定。chrony 的 iburst（initial burst）选项，启动时一次性发 4 个探测包，几秒内就能完成首次同步。这对虚拟机、容器这种频繁启停的场景至关重要——你不可能等 10 分钟才让一个容器的时间正确。...

概述 凌晨两点，告警炸了。服务连不上数据库，curl 超时，但 ping IP 通。你说这到底是网络问题还是应用问题？十有八九是 DNS 解析出了岔子。 DNS 解析是 Linux 系统最基础也是最容易被忽视的基础设施。平时没人关注它，一旦出问题，整个系统像突然失忆了一样——所有域名都认不出来。更恶心的是，DNS 问题表现千奇百怪：有的直接报 Temporary failure in name resolution，有的莫名其妙卡 5 秒，有的间歇性失败。如果不清楚解析链路，排查起来就是一通乱试。 这篇文章把 Linux DNS 解析的完整链路拆开讲：从 /etc/hosts 到 nsswitch，从 resolv.conf 到 systemd-resolved，从 dig 到 tcpdump。每个环节配实战案例，看完能在生产环境独立排查 DNS 问题。 Linux DNS 解析的完整链路 先搞清楚一个问题：当你在终端敲下 curl http://example.com 的时候，系统到底干了什么？ DNS 解析不是一步完成的，它经过多个层级。理解这条链路是排查问题的前提。打个比方：DNS 解析就像寄快递。你写的收件地址是"北京市朝阳区"，快递员不会直接知道具体在哪——先查邮编分区，再查街道，最后查门牌号。DNS 也一样，一层一层往下找。 解析优先级 Linux 系统解析一个域名时，默认按以下顺序查找： 本地 hosts 文件（/etc/hosts）——优先级最高，匹配到就直接返回 DNS 缓存——如果系统装了 nscd 或 systemd-resolved，会先查缓存 配置的 DNS 服务器（/etc/resolv.conf 中的 nameserver）——最后才走网络查询 但这个顺序不是写死的。真正控制解析顺序的是 /etc/nsswitch.conf 文件中的 hosts 行： # 查看 nsswitch 配置 cat /etc/nsswitch....

概述 凌晨三点，你被告警吵醒，登录服务器发现屏幕上只有一行 Kernel panic - not syncing: Fatal exception，然后系统就重启了。等你好不容易连上去，崩溃现场什么都没留下——没有日志，没有 core dump，没有调用栈。你只能对着一句 systemd-logind: System is going down 发呆。 这种场景，每个干过几年运维的人都遇到过。内核崩溃本身已经够头疼了，但更头疼的是崩溃后什么都抓不到，问题根本没法定位。 kdump 就是解决这个问题的。它相当于给 Linux 服务器装了一台飞行记录仪——飞机坠毁时，黑匣子能告诉你最后几秒发生了什么；内核崩溃时，kdump 能把崩溃瞬间的完整内存状态保存下来，让你事后用 crash 工具逐帧分析。 这篇文章不讲虚的，从 kdump 的工作原理到生产环境的完整配置流程，再到 crash 工具的实际分析操作，全部覆盖。读完之后，你应该能在自己的服务器上搭一套可靠的崩溃捕获系统。 kdump 是怎么工作的 双内核机制 要理解 kdump，先搞懂一个关键概念：崩溃时主内核已经不可信了。你不能指望一个已经 panic 的内核去把自己的内存好好保存下来——它连正常执行代码都做不到。 kdump 的思路很巧妙：系统启动时，提前预留一块物理内存，在里面加载一个精简的"捕获内核"（capture kernel，也叫第二内核）。主内核正常运行时，这块内存被隔离，谁都不许动。一旦主内核崩溃，kexec 机制会直接把 CPU 控制权交给捕获内核——不走 BIOS，不重启硬件，直接在预留内存里启动。捕获内核接管后，主内核的内存内容还完好无损地躺在那里，捕获内核把它打包成 vmcore 文件，写到磁盘上。 整个过程像这样： ┌──────────────────────────────────────────────┐ │ 物理内存布局 │ │ │ │ ┌────────────────┐ ┌───────────────────┐ │ │ │ 主内核区域 │ │ 预留内存区域 │ │ │ │ (正常运行) │ │ (crashkernel) │ │ │ │ │ │ │ │ │ │ 用户进程 │ │ 捕获内核 + │ │ │ │ 内核模块 │ │ initramfs │ │ │ │ 页缓存....

概述 凌晨三点，你被告警吵醒。登录服务器一看，某个关键配置文件被改了，但 last 命令显示那个时间段没有人登录，bash_history 也没记录。你知道出事了，但不知道是谁干的、怎么干的。 这时候你需要的是 auditd——Linux 内核自带的审计系统。它就像飞机的黑匣子，记录系统上发生的每一个关键动作：谁执行了什么命令、访问了哪些文件、改了什么配置、什么时候提的权。而且这些记录在内核层面生成，不依赖 shell history 或应用日志——攻击者就算删了 ~/.bash_history，也删不掉 auditd 的日志。 本文从安装部署讲到规则编写、日志分析和生产调优。不是手册翻译，是踩过坑后的实战经验。 auditd 是什么，和 syslog 有什么区别 先说清楚一个常见的混淆。很多人觉得"我有 syslog/journald 了，还要 auditd 干嘛？" 两者记录的东西完全不同： 对比项 syslog/journald auditd 记录层级 应用层 内核层 记录内容 服务启动/停止、应用日志、登录记录 系统调用、文件访问、权限变更 粒度 粗（按事件） 细（按系统调用） 防篡改 无（root 可随意修改） 有（日志写入前加密校验） 性能影响 极低 有，取决于规则数量和复杂度 典型用途 日常运维日志 安全审计、合规检查、应急响应 打个比方：syslog 像小区门口的保安登记簿，谁进谁出记一笔。auditd 像每户人家的门禁记录加室内监控——什么时候开了哪个门、谁开的、开了多久，精确到秒。 auditd 最初源自 Solaris 的审计子系统，Linux 内核 2.6（2004 年）开始引入，由 Red Hat 和 IBM 主导开发。现在已经是 CIS Benchmark、PCI-DSS、HIPAA 等安全合规标准的必备组件。 auditd 已成为 Linux 安全标准（如 CIS Benchmark、PCI-DSS、HIPAA）的重要组成部分。参考来源：Demystifying Auditd: A Complete Guide for Linux Security Monitoring...

概述 线上跑着一个高频交易系统，P99 延迟平时 2ms，但偶尔飙到 20ms。CPU 使用率不高，内存充足，网络正常。查了一圈，发现是 CPU 调度器把关键线程踢到了另一个核上，L3 缓存全部 miss，延迟直接翻了 10 倍。 这种问题不是靠加资源能解决的。问题出在"共享"——所有进程共享 CPU 核心，调度器自由分配，谁也不知道哪个线程是延迟敏感的。 解决办法就是 CPU 隔离：把关键业务绑到专属核心上，不让别的进程碰。同时做 NUMA 调优，让 CPU 和内存在物理上"就近"，避免跨节点访问带来的延迟翻倍。 这篇笔记覆盖从基础概念到生产实操的完整链路：isolcpus 内核参数、cpuset cgroup、taskset 绑核、NUMA 亲和性、中断绑核、以及组合使用的最佳实践。所有命令都在 Ubuntu 22.04（内核 5.15）和 CentOS 8 上实测过。 基础概念：为什么要隔离 CPU CPU 调度器是怎么工作的 Linux 默认使用 CFS（Completely Fair Scheduler，完全公平调度器）分配 CPU 时间。CFS 的设计目标是"公平"——每个进程根据权重获得 CPU 时间片，调度器在所有可用核心之间自由迁移进程。 听起来没问题，但对延迟敏感的场景是个灾难： 上下文切换开销：线程从 CPU A 迁移到 CPU B，L1/L2 缓存全部失效，需要重新从内存加载数据。一次迁移的代价是微秒级的延迟抖动。 缓存污染：其他进程跑在你的目标核上，把你之前缓存的数据挤出去，下次你的线程回来时全是 cache miss。 中断干扰：网卡中断、定时器中断随时打断你的线程。对于要求微秒级响应的系统，一次中断就是一次延迟尖峰。 NUMA 架构是什么 NUMA（Non-Uniform Memory Access，非统一内存访问）是多路服务器的标配架构。简单说就是：每个 CPU 插槽有自己的本地内存，访问自己的内存很快，访问别的 CPU 的内存要跨 QPI/UPI 总线，延迟翻倍。...

概述 Linux 命名空间与 cgroups：容器技术的底层基础是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Linux 命名空间与 cgroups 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Linux 命名空间与 cgroups能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Linux 命名空间与 cgroups的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Linux 命名空间与 cgroups的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Nginx 性能调优：从配置到内核参数的完整实践是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Nginx 性能调优 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Nginx 性能调优能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Nginx 性能调优的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Nginx 性能调优的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Linux 系统调用追踪：strace 与 ltrace 调试实战是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Linux 系统调用追踪 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Linux 系统调用追踪能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Linux 系统调用追踪的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Linux 系统调用追踪的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Linux 防火墙经历了从 ipfwadm → ipchains → iptables → nftables 的演进。底层均基于 Netfilter 框架，但上层语法和管理方式不断改进。从 Netfilter 架构出发，深入 iptables 的五链四表、nftables 的优势与用法、NAT/端口转发、连接追踪机制以及生产环境的性能优化实践。 Netfilter 框架 架构概览 Netfilter 是 Linux 内核中的数据包处理框架，通过在内核网络栈的关键位置挂载钩子（hook）来实现数据包过滤、地址转换、连接追踪等功能。 Netfilter 钩子点 [数据包进入] → PREROUTING → [路由判断] →─┬─→ FORWARD → POSTROUTING → [数据包发出] │ └─→ INPUT → [本地进程] → OUTPUT → POSTROUTING → [数据包发出] 五大钩子点 钩子点 触发时机 中文含义 NF_INET_PRE_ROUTING 数据包进入网络栈，路由前 路由前 NF_INET_LOCAL_IN 数据包目的地是本机 输入 NF_INET_FORWARD 数据包需要转发到其他接口 转发 NF_INET_LOCAL_OUT 本机产生的数据包 输出 NF_INET_POST_ROUTING 数据包即将离开网络栈 路由后 数据包流向 入站（访问本机）: NIC → PREROUTING → INPUT → 本机进程 出站（本机发出）: 本机进程 → OUTPUT → POSTROUTING → NIC 转发（经过本机）: NIC → PREROUTING → FORWARD → POSTROUTING → NIC iptables 五链四表 四张表 iptables 通过"表"来组织不同功能的规则链：...