Skip to main content

Integration manifest and payload schema

The file layout of an integration template, so you can write and contribute one.

An integration template is a component's monitoring in one bundle: collector config, dashboards, alert rules and metric descriptions. Nightingale ships 88 of them under integrations/ in the source repository, loaded into the Components page at startup.

To cover a component that is not there yet, follow this layout and open a pull request.

Directory layout​

One directory per component; the directory name is what shows on the card:

integrations/MySQL/
├── icon/
│ └── mysql.png icon for the card
├── markdown/
│ ├── README.md collection notes (Chinese)
│ ├── README.en_US.md collection notes (English)
│ └── mysql.md further docs, any number
├── collect/
│ └── *.toml sample Categraf collector config
├── dashboards/
│ └── *.json dashboards, any number
├── alerts/
│ └── *.json alert rules, any number
├── metrics/
│ └── *.json metric descriptions, feeding the built-in metric views
└── i18n/
└── en_US.json translations

Every part is optional — a contribution with dashboards but no rules is fine.

The formats​

dashboards/*.json is the dashboard export format. Build it in the UI, export it, drop it in.

alerts/*.json is the alert rule export format, either one object or an array. The fields that matter: name, cate, prod, severity, rule_config (since v6 the queries live in its queries array and the top-level prom_ql stays empty), prom_eval_interval, prom_for_duration, append_tags, annotations. Full field list in Import, export and reuse.

metrics/*.json describes what metrics the component emits and what each means, feeding the product's built-in metric views. There are over 1300 built in.

collect/*.toml is a sample Categraf configuration. Note that in the open-source build these files are only used by the AI documentation index; the collection wizard on the host list uses a separate frontend catalogue plus public/n9e-collect-templates/*.toml.

i18n/en_US.json is a key/value map with the Chinese original as the key. GET /api/n9e/builtin-payloads returns names in the language of the request's X-Language header.

When it loads​

The n9e process reads integrations/ next to the binary at startup. Changes need a restart to show up.

Templates created by hand in the Components page live in the database and are merged with the ones from disk; on a name collision the database row wins.

Contributing​

Add a directory under integrations/ in ccfos/nightingale and open a PR. Run the whole bundle in your own environment first — dashboards drawing real data, rules actually firing — rather than submitting JSON alone.