 |
VOOZH | about |
|
VOOZH | about |
The Datadog exporter supports sending system information about your hosts to Datadog, which you can see in the Infrastructure List. You can send this information in OTLP through the ‘Resource’ field as part of any of the existing signals. This is supported under any deployment pattern including gateway deploys.
Datadog uses OpenTelemetry semantic conventions to recognize system information about your hosts. Follow the instructions for setting up for host metrics to send the necessary metrics and resource attributes to Datadog. Alternatively, you can manually send this information in the way that best fits your infrastructure.
To use this feature, set the datadog.host.use_as_metadata resource attribute to true in all OTLP payloads that contain information about hosts.
Resources populate the infrastructure list information if they have a host-identifying attribute and the datadog.host.use_as_metadata attribute set to true.
To explicitly declare what resources to use for metadata, add the Boolean resource attribute datadog.host.use_as_metadata to all resources that have relevant host information.
For example, to set this for all resources in metrics, traces, and logs, use the transform processor with the following configuration:
processors:transform:metric_statements:- context:resourcestatements:- set(attributes["datadog.host.use_as_metadata"], true)trace_statements:- context:resourcestatements:- set(attributes["datadog.host.use_as_metadata"], true)log_statements:- context:resourcestatements:- set(attributes["datadog.host.use_as_metadata"], true)Add this processor to the processors list of all your pipelines.
You must explicitly tag all your resources with a host-identifying attribute. This is done by default by the recommended setup for host metrics.
The Datadog exporter supports both resource attribute-level semantic conventions and system metrics-level semantic conventions. Supported resource attribute semantic conventions are mainly under the host. namespace and the os. namespace. All supported system metrics-level semantic conventions are under the system. namespace.
| Semantic convention | Type | In-app field |
|---|---|---|
| Various host-identifying attributes | Resource attribute | Hostname |
os.description | Resource attribute | OS |
| Semantic convention | Type | In-app field |
|---|---|---|
host.cpu.vendor.id | Resource attribute | Vendor ID |
host.cpu.model.name | Resource attribute | Model Name |
host.cpu.cache.l2.size | Resource attribute | Cache Size |
host.cpu.family | Resource attribute | Family |
host.cpu.model.id | Resource attribute | Model |
host.cpu.stepping | Resource attribute | Stepping |
system.cpu.logical.count | System metric | Logical Processors |
system.cpu.physical.count | System metric | Cores |
system.cpu.frequency | System metric | MHz |
| Semantic convention | Type | In-app field |
|---|---|---|
host.ip | Resource attribute | IP Address & IPv6 Address |
host.mac | Resource attribute | Mac Address |
To collect these conventions with the OpenTelemetry Collector, set up the recommended setup for host metrics. The host metrics receiver collects all the relevant metrics, while the resource detection processor collects all relevant resource attributes.
Note: You need to add these processors and receivers in the Collector running on the host that you want to monitor. A gateway host does not collect this information from remote hosts.
Canonical cloud resource IDs (CCRIDs) are cloud provider-assigned resource IDs that uniquely identify a cloud resource. After adding CCRIDs across your different observability types, you can use them to consistently link different types of data for a given cloud resource. You can add CCRIDs in the same format across all cloud resource types. Widespread addition and adoption of CCRIDs gives you access to a variety of use cases across customers and internal teams.
Enable CCRIDs to jump between resources and their associated metrics, traces, and logs for all resource types, eliminating context switching and giving you an end-to-end view of your resources within the same workflow.
To use this feature, set the datadog.ccrid resource attribute to the value of the CCRID in all OTLP payloads.
See below for the list of identifier formats per-cloud:
| Cloud | Identifier Type | Example |
|---|---|---|
| AWS | ARN | arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi |
| Azure | Resource ID | /subscriptions/12345678-1234-5678-1234-567891234567/resourcegroups/exampleResourceGroup/Microsoft.Compute/virtualMachines/exampleVM |
| GCP | CAI Resource Name | //compute.googleapis.com/projects/example-project/locations/us-central1/instances/my-instance |
| OCI | OCID | ocid1.instance.oc1.eu-frankfurt-1.exampleuniqueid |
How to form a CCRID:
arn:aws:ec2:{region}:{accountId}:instance/{instanceId}.
Use this command to retrieve the instanceId:ec2metadata --instance-id
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}//compute.googleapis.com/projects/{projectID}/zones/{zoneName}/instances/{instanceName}"http://169.254.169.254/opc/v2/instance/idFor example, to set an AWS CCRID for all resources in metrics, traces, and logs, use the transform processor with the following configuration:
processors:transform:metric_statements:- context:resourcestatements:- set(attributes["datadog.ccrid"], "arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi")trace_statements:- context:resourcestatements:- set(attributes["datadog.ccrid"], "arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi")log_statements:- context:resourcestatements:- set(attributes["datadog.ccrid"], "arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi")The OpenTelemetry semantic conventions also define the cloud.resource_id attribute, which can be mapped in the configuration using the attributes processor.
Example:
processors:attributes/example:actions:- key:datadog.ccridfrom_attribute:cloud.resource_idaction:upsertAdditional helpful documentation, links, and articles:
| |
