Skip to content

Datadog Integration

To ensure our infrastructure is properly visible in Datadog, we need to have certain things in place.

Resource Tagging

For proper categorization of infrastructure, we need to add certain tags to our AWS resources.

Those tag values should use a hyphen (-) as a separator and should not contain spaces or other non-alphanumeric characters.

  • cluster: The name of the cluster the resource belongs to. Available clusters are:
    • data-provisioning
    • go-to-market
    • api-ecosystems
    • discovery-usage
    • If your service doesn't belong to one of these clusters, please use other.
  • team: The name of the team that owns the resource. Available teams are:
    • acquisition-registration
    • ai-experience
    • analytics-engineering
    • api-data
    • api-ecosystems
    • architects
    • billing-subscription
    • billing-subscription-solutions
    • checkout-billing
    • checkout-payment
    • cloud-developer-experience-cdx
    • content-tools
    • data-and-content-delivery
    • data-platform
    • data-visualization
    • digital-workplace-operations
    • endpoints-workplace
    • gcs
    • go-to-market
    • home-navigation
    • hub-pages
    • iam
    • identity-application-management
    • it-infrastructure
    • it-operations
    • it-workplace-management
    • marketing-tech
    • my-home-search-experience
    • page-experience
    • people-americas
    • pit-project-and-process-management
    • pit-search-api
    • platform-engineering
    • platforms
    • procurement
    • research-ai
    • search-api
    • search-recommendations
    • security
    • self-service-hub
    • statistics
    • tech-process-and-project-management
    • tracking
    • user-authentication-services
    • user-tools
  • service: The name of the service that owns the resource. We don't enforce a specific naming convention here.
  • environment: The environment the resource belongs to. Available environments are:
    • dev
    • stage
    • prod
    • other (This is not a literal value but a placeholder for feature-specific environments).
  • version (optional): The version of the service that owns the resource. This is primarily for applications, not for infrastructure resources like databases or queues. The value should be a Git commit hash or a semantic version string (e.g. 1.0.0) so that Datadog can link it to a specific code commit. This tag can be supplied as an environment variable (DD_VERSION) or as a Docker label (com.datadoghq.tags.version). It also enables deployment tracking in Datadog.
  • git.repository_url: The URL of the Git repository that owns the resource. This is used to link the resource to the code in Datadog.

  • cost-category: This allows us to categorize resource costs in Datadog into the following buckets:

    • operational: Your service and all the resources it needs to function.
    • observability: Additional resources for observing the service (e.g., CloudWatch).
    • security: Additional resources for securing the service (e.g., CloudTrail).
    • other: Any other resources that do not fit into the above categories.

    Each resource should be only in one bucket. For example if a resource is required to fulfil our customers needs, it's an operational resource, while a Datadog Agent would be in the observability group.

    The cost-category tag can be used to split the account cost and have a view on cost for pure operations or how much is spend for security measures or ...

To verify proper tagging of your resources, we set up Policies in Datadog. Once on a policy you can filter for your AWS Accounts to verify correct tagging.

[!NOTE] All this in bundled into our @pit-shared/cdk Datadog construct!

Github Integration

We need to ensure the Github Linking from a service to the repository is properly set up. To do that, go to your service page (monolith in this example) and click on the tiny button up right called Service Config (dont edit anything in the Service Information tab, thats done with the Service Catalog section below). Just make sure the Setup Guidance is set up properly.

Make sure everything is green in the category Recommended Setup for this Service (you can ignore SLOs) Under Recommended Telemetry enable what suits your service best, but at least enable:

  • Distributed Tracing
  • Infrastructure Monitoring
  • Log Management
  • Continous Profiler

[!NOTE] be aware that some of these telemetry features might incur additional costs or are not even enabled on our Organization, so please check with your team lead or the architects before enabling them.

Service Catalog

To have a living documentation of your service, we need to ensure the Service Catalog is properly set up. See this documentation to get a glimpse on that.

To set up the Service Catalog add a service.datadog.yaml file to your repository in the root directory. See the Entity Model on how to configure it properly. When the Github Integration is properly configure (Repository:Read is required) this will automatically be sourced from Datadog.

In the end you will have your service properly documented in the Service Catalog and linked to your Git repository. This is an example how it will look like in the end: Numera-User-Service

for Remix Apps this is already set up for you.

Last updated: January 05, 2026 at 13:31
By: Markus Wolf