共计 3356 个字符，预计需要花费 9 分钟才能阅读完成。
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 :)
