Inspecting coredumps like it's 2021

On traditional Linux-systems the kernel has to be configured manually in order to take care of coredumps. A log entry which represents a coredump contains additional properties prefixed with COREDUMP. These are used by coredumpctl to find the most recent coredumps. The output of coredumpctl generates an overview over the most recent coredumps. Coredumps total represents the total amount of coredumps on a system grouped by the kernel's boot id. This is necessary because the exporter loads - just like coredumpctl(1) - this information from the journal which can become arbitrarily large and it's unfortunately only possible to get all coredumps in O(n) time because every log-entry has to be checked for COREDUMP * fields. Coredumps represents the total amount of coredumps grouped by boot id, program that has crashed and which signal(7) was sent. After learning about all of these tricks, I actually started to consider coredumps a helpful asset to debug issues.