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.
There are two versions of the
manifest.json file. While we will continue supporting manifest version 1 for existing integrations, all new integrations, Datadog Apps, and Marketplace offerings should use version 2 of the manifest.
If you see the following at the top of your
manifest.json file, this means you are using version 2:
Otherwise, you can assume that you are using version 1.
These two versions have different attributes and structures. You can find the complete list of mandatory and optional attributes for both versions of the
manifest.json file below:
|String Enum||Mandatory||Version of the manifest schema. Supported values include |
|String||Mandatory||The unique identifying name of this offering. Usually kebab case of the app title. For example, if the app title is “Marketplace Offering”, then the |
app_id would be
|UUID||Mandatory||Globally unique UUID for this application.|
|Dictionary||Mandatory||Object containing any Datadog installable entity.|
|Dictionary||Optional||Out-of-the-box dashboards associated with this offering.|
|String||Mandatory||Key/value pairs of any out-of-the-box dashboards. The key is the globally unique short name of the dashboard and the value is the relative path to the dashboard’s JSON definition in relation to this manifest.|
|Dictionary||Optional||Object containing information about the integration.|
|Dictionary||Mandatory, can be |
|Object representing the configuration specification for this integration.|
|String||Mandatory||Relative path to where the configuration spec lives in relation to this manifest.|
|Dictionary||Mandatory||Information about events emitted by this integration.|
|Boolean||Mandatory||Whether or not this integration emits events to Datadog.|
|Dictionary||Mandatory||Information about the metrics this integration emits.|
|String or List of String||Mandatory||A string or list representing metrics that this integration always emits on every run.|
|String||Mandatory||Relative path to where the metrics metadata lives in relation to this manifest.|
|String||Mandatory||The prefix for metrics emitted by this integration.|
|Dictionary||Mandatory, but can be |
|Information about service checks emitted by this integration.|
|String||Mandatory||Relative path to where the service check metadata lives in relation to this manifest.|
|String||Mandatory||User-facing name of this integration.|
|String||Mandatory||Key/value pairs for any recommended monitors. The key is the globally unique short name of the monitor and the value is the relative path to the monitor’s JSON definition in relation to this manifest.|
|Dictionary||Mandatory||Information about the author of this app.|
|String (URL)||Mandatory||The web URL to the homepage of the author.|
|String||Mandatory||The human-readable name for this company.|
|String (Email)||Mandatory||The email to contact for any subscription-level events.|
|String (Email)||Mandatory||The email to contact for any support and maintenance queries.|
|String||Mandatory||The vendor ID to use for subscription purposes. Must be globally unique and cannot be changed. Should follow the strict standards of |
app_id where only dashes and alphabetic chars are allowed. This value is provided to partners.
|Array of String||Mandatory, can be |
|Some classifier information about this app. This includes information such as |
|Boolean||Mandatory||Whether or not information about this listing is displayed on the public Datadog docs site. Once this is set to True, it cannot be changed.|
|Dictionary||Mandatory||Any legal documentation that a user needs to agree to in order to use this app.|
|String||Mandatory||Relative path to the EULA (End User License Agreement) PDF in relation to this manifest.|
|Array of Dictionaries||Mandatory||List of objects representing the pricing model of the integration. See Marketplace GitHub repository for pricing details. The Marketplace GitHub repository is private, email email@example.com for access.|
|Dictionary||Mandatory||Information about this offering|
|Array of Dictionaries||Mandatory, can be |
|Information about various image and video style objects that are presented in the media gallery carousel on the listing page.|
|String or Enum||Mandatory||The type of media this is. Allowed values are |
|String||Mandatory||The caption for the image.|
|String||Mandatory||The relative path to this image in relation to this manifest file.|
|String||Mandatory||A brief description of what this offering provides. Limited to 80 characters.|
|String||Mandatory||The user-friendly title for this app.|
|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 included 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.
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|
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.|
|Optional||Marks the metric as noteworthy for a given type (|
memory are both accepted types).