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> # <KEY>: <VALUE>
Configuration blocks follow a few guidelines:
<THIS_IS_A_PLACEHOLDER>, as per the documentation contributing guidelines:
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, e.g.
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.
list, individual elements are not documented with the
objectyou can choose to either document elements individually with the
@paramspecification 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:
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 |
|String||Mandatory||Title displayed on the corresponding integration tile in the Datadog application and on the public documentation integrations page|
|String||Mandatory||Unique ID for the integration. Generate a UUID|
|Boolean||Mandatory||If set to |
|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.|
|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 in the Datadog application.|
|String||Optional||The namespace for this integration’s metrics. Every metric reported by this integration will be 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 |
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 |
|Optional||Description of the metric.|
|Mandatory||Set to |
|Mandatory||Name of the integration that emits the metric. Must be the normalized version of the |
|Mandatory||Explicit Unique ID for the metric.|
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 |
|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|