Integration Assets Reference
When preparing a new integration, you must include an example configuration that contains the necessary options and reasonable defaults. The example configuration file, which in this case is located at
<CHECK_NAME>/datadog_checks/<CHECK_NAME>/data/conf.yaml.example, has two top-level elements:
instances. The configuration under
init_config is applied to the integration globally, and is used in every instantiation of the integration, whereas anything within
instances is specific to a given instantiation.
Configuration blocks in either section take the following form:
## @<COMMAND> [- <ARGS>]
## <DESCRIPTION LINE 1>
## <DESCRIPTION LINE 2>
Configuration blocks follow a few guidelines:
- Description must not be empty
- Placeholders should always follow this format:
<THIS_IS_A_PLACEHOLDER>, as per the documentation contributing guidelines:
- All required parameters are not commented by default.
- All optional parameters are commented by default.
- If a placeholder has a default value for an integration (like the status endpoint of an integration), it can be used instead of a generic placeholder.
Practically speaking, the only command is
@param, which is used to describe configuration blocks—primarily for documentation purposes.
@param is implemented using one of the following forms:
@param <name> - <type> - required
@param <name> - <type> - optional
@param <name> - <type> - optional - default: <defval>
name: the name of the parameter, such as
type: the data type for the parameter value (mandatory). Possible values:
defval: default value for the parameter; can be empty (optional).
object variables span over multiple lines and have special rules.
- In a
list, individual elements are not documented with the
- In an
object you can choose to either document elements individually with the
@param specification or to have a common top-level description following the specification of the object itself.
An optional parameter must be commented by default. Before every line the parameter spans on, add
# with the same indentation as the
You can add a block comment anywhere in the configuration file with the following rules:
- Comments start with
- Comments should be indented like any variable (the hyphen doesn’t count)
For more information about YAML syntax, see Wikipedia. Feel free to play around with the Online YAML Parser, too!
Every integration contains a
manifest.json file that describes operating parameters, positioning within the greater Datadog integration eco-system, and other such items.
The complete list of mandatory and optional attributes for the
|String||Mandatory||The unique identifying name of this integration. Usually kebab case of the Display Name|
|Array of String||Mandatory||Integration categories used on the public documentation Integrations page.|
|Boolean||Mandatory||If the integration should be able to create events. If this is set to |
false, attempting to create an event from the integration results in an error.
|String||Mandatory||The title displayed on the corresponding integration tile on the Datadog site and the Integrations page.|
|String||Mandatory||Unique ID for the integration. Generate a UUID|
|Boolean||Mandatory||If set to |
false the integration
README.md content is not indexed by bots in the Datadog public documentation.
|String||Mandatory||Email of the owner of the integration.|
|String||Mandatory||Version of the current manifest.|
|String||Mandatory||Unique name for the integration. Use the folder name for this parameter.|
|String||Mandatory||Title of the integration displayed on the documentation. Should follow the following format: |
|String||Mandatory||This text appears at the top of the integration tile as well as the integration’s rollover text on the integrations page. Maximum 80 characters.|
|String||Mandatory||Owner of the integration.|
|Array of String||Mandatory||List of supported OSs. Choose among |
|String||Mandatory||Type of the integration, should be set to |
|Array of String||Optional||A list of URL aliases for the Datadog documentation.|
|String||Optional||This text appears when sharing an integration documentation link.|
false. If set to
true the integration
README.md content is not displayed in the Datadog public documentation.
|String||Optional||The presence of this metric determines if this integration is working properly. If this metric is not being reported when this integration is installed, the integration is marked as broken on the Datadog site.|
|String||Optional||The namespace for this integration’s metrics. Every metric reported by this integration is prepended with this value.|
|Array of String||Optional||A list of signatures that matches the command line of this integration.|
|Dictionary||Mandatory||Relative location of where certain asset files live and their respective names.|
|Dictionary||Mandatory||Dictionary where the key is the name of the dashboard (must be globally unique across integrations) and the value is the relative file path where the dashboard definition lives.|
|Dictionary||Mandatory||Dictionary where the key is the name of the monitor (must be globally unique across integrations) and the value is the relative file path where the dashboard definition lives.|
|String||Mandatory||Relative location of where the |
service_checks.json file lives.
metadata.csv file describes all of the metrics that can be collected by the integration.
Descriptions of each column of the
|Mandatory||Name of the metric.|
|Mandatory||Type of the metric.|
|Optional||Collection interval of the metric in second.|
|Optional||Unit of the metric. Complete list of supported units.|
|Optional||If there is a unit sub-division, i.e |
request per second
|Optional||Description of the metric.|
|Mandatory||Set to |
1 if the metric should go up, i.e
myapp.turnover. Set to
0 if the metric variations are irrelevant. Set to
-1 if the metric should go down, i.e
|Mandatory||The name of the integration that emits the metric. Must be the normalized version of the |
display_name from the
manifest.json file. Any character besides letters, underscores, dashes, and numbers are converted to underscores, for example:
Openstack Controller ->
|Mandatory||Explicit Unique ID for the metric.|
Service check file
service_check.json file describes the service checks made by the integration.
service_checks.json file contains the following mandatory attributes:
|Minimum Agent version supported.|
|The name of the integration that emits this service check. Must be the non-normalized |
|Name of the Service Check. It must be unique.|
|List of different status of the check, to choose among |
unknown is also a possibility.
|Tags sent with the Service Check.|
|Displayed name of the Service Check. The displayed name must be self-explanatory and unique across all integrations.|
|Description of the Service Check|