core dump 路径定义以及监控

核心要点

Core Dump 是进程异常退出时保存的运行状态文件，常用于事后定位 crash 原因，也适合作为故障发现信号。
Linux 上能否生成 core 文件，首先受 ulimit -c 影响；如果 core file size 为 0，就不会生成 core dump。
core 文件路径和命名由 /proc/sys/kernel/core_pattern 控制，可以通过 %e、%p、%h、%t 等占位符标识进程、PID、主机名和时间。
生产环境建议统一 core dump 目录，例如 /opt/cores，这样才能稳定监控新文件生成。
catpaw 的 mtime 插件可以监控指定目录在时间窗口内是否有文件变更或新文件产生，用于发现新的 core dump 文件。

Core Dump 是什么？

Core Dump 是指进程异常退出时，操作系统将进程的内存状态保存到文件中，这个文件就是 Core Dump 文件，中文一般翻译为“核心转储”，哈，看起来还不如不翻译。

我们可以认为 Core Dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。

Core Dump 有什么用？

一个是用于排查问题，例如程序 crash 了，我们可以通过 gdb 等工具来分析 core dump 文件，找到问题的原因。另一个是监控，我们可以通过监控手段及时发现程序 crash 了，及时处理。

程序自身产生的 Core Dump 文件一般可以用来分析程序运行到哪里出错了。

Linux 平台常用的 coredump 文件分析工具是 gdb；Solaris 平台用 pstack 和 pflags；Windows 平台用 userdump 和 windbg。

测试生成 Core Dump 文件

[root@VM-0-33-debian:~# cd /home/user
[root@VM-0-33-debian:~# ulimit -c unlimited
[root@VM-0-33-debian:~# kill -s SIGSEGV $$

这将会在你当前的 shell 下触发一个段错误，进而生成一个 core dump 文件，文件名为 core 或 core.pid，pid 是当前 shell 的进程号。

注意，ulimit -c unlimited 是告诉操作系统，不要限制 core dump 文件的大小，如果你执行 ulimit -c 看到输出 0，就表示 core dump 文件大小限制为 0 了，也就不会生成。比如我的机器环境：

[root@VM-0-33-debian:~# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 30148
max locked memory           (kbytes, -l) 969535
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 30148
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

注意 core file size 那一行，我的环境是 0，就表示限制了 core dump 文件的生成。

Core Dump 文件路径定义

在 Linux 下，core dump 文件的路径是由 /proc/sys/kernel/core_pattern 定义的，如果这个文件不存在，或者内容为空，那么 core dump 文件就会生成在当前目录下。

[root@VM-0-33-debian:~# cat /proc/sys/kernel/core_pattern
core

上面的输出表示，core dump 文件会生成在当前目录下，文件名为 core。

我们可以通过修改 /proc/sys/kernel/core_pattern 来定义 core dump 文件的路径和文件名，例如：

[root@VM-0-33-debian:~# mkdir -p /tmp/cores
[root@VM-0-33-debian:~# chmod a+rwx /tmp/cores
[root@VM-0-33-debian:~# echo "/tmp/cores/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern

然后，我们重新生成 core dump 文件：

[root@VM-0-33-debian:~# cd /home/user
[root@VM-0-33-debian:~# ulimit -c unlimited
[root@VM-0-33-debian:~# kill -s SIGSEGV $$

此时，我们会生成一个类似这样的文件：/tmp/cores/core.bash.8539.VM-0-33-debian.1236975953。其中，bash 是进程名，8539 是进程号，VM-0-33-debian 是主机名，1236975953 是时间戳。文件存储在 /tmp/cores 目录下。

对于 core_pattern 的定义，可以使用如下的占位符：

%p: pid
%: '%' is dropped
%%: output one '%'
%u: uid
%g: gid
%s: signal number
%t: UNIX time of dump
%h: hostname
%e: executable filename
%: both are dropped

其中，%h hostname 最好加上，假如我们把 core dump 文件存放在 NFS 上，就可以用 %h 来区分 core dump 文件来自哪个机器了。

echo "/tmp/cores/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern 这种设置方式，是临时生效，如果机器重启，就会失效。如果想要永久生效，可以修改 /etc/sysctl.conf 文件，添加一行：

# Own core file pattern...
kernel.core_pattern=/tmp/cores/core.%e.%p.%h.%t

然后执行 sysctl -p 命令，使配置生效。

监控落地步骤

Core Dump 监控可以拆成四步：

统一生成策略：确认关键主机的 ulimit -c 不为 0。
统一存储目录：通过 core_pattern 把 core 文件写入固定目录，并在文件名里带上进程名、PID、主机名和时间戳。
统一权限：保证目标目录存在，且进程有权限写入。
统一告警：监控固定目录里是否出现新 core 文件，并把告警发送到负责团队。

这四步缺一不可。只配置路径但不放开 ulimit，不会生成文件；只生成文件但不监控目录，故障仍然可能没人知道。

Core Dump 文件监控

一般来讲，对于规范化做的好的公司，core_pattern 是系统部交付机器的时候，统一设置好的，公司所有的机器的 core_pattern 都是一致的，会设置成一个统一的目录，例如 /opt/cores，这样就可以方便地对 core dump 新文件进行监控了。

这里，推荐大家使用 catpaw（基本介绍参考这里：太卷了，史上最简单的监控系统 catpaw 简介），catpaw 从 v0.3.0 版本开始，引入了 mtime 监控插件，可以监控近期的文件变更，进而监控新的 core dump 文件的产生。

mtime 插件的配置如下：

[[instances]]
time_span = "3m"
directory = "/opt/cores"
check = "file changed or created"
interval = "30s"

[instances.alerting]
## Enable alerting or not
enabled = true
## Same functionality as Prometheus keyword 'for'
for_duration = 0
## Minimum interval duration between notifications
repeat_interval = "5m"
## Maximum number of notifications
repeat_number = 3
## Whether notify recovery event
recovery_notification = true
## Choice: Critical, Warning, Info
default_severity = "Warning"