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 文件监控
一般来讲，对于规范化做的好的公司，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"
上面的意思表示，每 30s 探测一次，每次探测最近 3 分钟内是否有文件变更或新文件产生。比如我随便对某个目录做了测试，最终输出的内容长这个样子：
总结
希望本文介绍的内容对你有帮助，愿不吝点赞、在看。如果有其他这类事件监控的场景需求，也可以联系我，后面都会一并做到 catpaw 里。
虽然 FlashDuty 有免费套餐，如果就是不想用，也可以模仿 FlashDuty 的事件接收接口自己搞个 HTTP Server，接收 catpaw 的事件推送，然后自己处理，比如发送到钉钉、飞书、邮件等。
enjoy...make a better world ?