___ ___ ____ __ __ ___ ____ __ __ | | | / || | || \ / || | | | _ _ || o || | || \ | o || | | | \_/ || || ~ || D || || ~ | | | || _ ||___, || || _ ||___, | | | || | || || || | || | |___|___||__|__||____/ |_____||__|__||____/ ~~~~~~~~~~~~~~~~~~~~~~~~~\o/~~~~~~~~~~~~~~~~~~~~~~~~ ><> <><
Mayday is a tool to simplify gathering support information. It is built in the
spirit of sysreport, son of sysreport (sosreport), and similar support tools.
Mayday gathers information about the configuration, hardware, and running state of a system.
The goals of mayday are:
In it's most simplistic form, all a user needs to do is run
This will collect a basic set of data and emit it in a tar archive for transmission to a systems administrator, site reliability engineer, or support technician for further troubleshooting.
In addition, more data can be collected by running as the superuser:
$ sudo mayday
Even more data can be collected by adding the
$ sudo mayday --danger
By default, mayday operates in a "safe" mode. No sensitive information is collected -- only information that support might need. This includes things like:
The following is collected only if the
--danger flag is activated:
The following information is never collected:
Mayday can be integrated into other projects by defining a default configuration
file at either the location
/usr/share/mayday/default.json. Through the use of viper
YAML and TOML are now supported as well, though CoreOS
will continue to use JSON as the mechanism of choice. If multiple products are
to be supported specialized configurations can be provided as "profiles" located
in the above directories (e.g.
/etc/mayday/quay.json) and the referenced via:
$ mayday -p quay
The configuration file is comprised of objects (As of 1.0.0 valid objects are "files" and "commands"). A example of the syntax can be seen in the file default.json. Each top level object contains an array of the relevant items to collect. Optionally items can be annotated with a "link" which will provide an easy to locate pointer for commonly accessed data.
Files are directly retrieved. Commands are executed and the results of standard
stdout) are collected. Assets are placed into a Go "tarable"
interface and then gzipped and serialized out to a file on disk.