datadog:
  apiKey: "<datadog_api_key>"
  pipelineId: "<observability_pipelines_configuration_id>"
  site: "datadoghq.com"

## Autoscaling
##
autoscaling:
  enabled: true
  minReplicas: 2
  targetCPUUtilizationPercentage: 80

podDisruptionBudget:
  enabled: true
  minAvailable: 1

## HorizontalPodAutoscaler (HPA) requires resource requests to function,
## so this example configures several default values. Datadog recommends
## that you change the values to match the actual size of instances that
## you are using.
resources:
  requests:
    cpu: 1000m
    memory: 512Mi

affinity:
  ## To prevent a single datacenter from causing a complete system failure,
  ## this example defaults to running pods in different availability zones.
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
              - key: app.kubernetes.io/name
                operator: In
                values:
                  - observability-pipelines-worker
          topologyKey: topology.kubernetes.io/zone


## Load Balancing
## This example configuration avoids cross-availability-zone costs where possible.
service:
  enabled: true
  type: "LoadBalancer"
  externalTrafficPolicy: "Local"
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"


## Buffering
## This creates an EBS drive that can be used for buffers, which
## must then be configured in the sinks themselves.
persistence:
  enabled: true
  storageClassName: "managed-csi"
  accessModes:
    - ReadWriteOnce
  size: 288Gi


## Observability Pipelines (OP) Configuration
## This is a sample configuration that Datadog recommends for
## getting started with OP. It sets up data proxying and provides hooks
## for your own processing steps.
pipelineConfig:
  ## SOURCES: Data sources that Observability Pipelines Worker collects data from.
  ## For a Datadog use case, we will receive data from the Datadog agent.
  sources:
    datadog_agent:
      address: 0.0.0.0:8282
      type: datadog_agent
      multiple_outputs: true

  transforms:
    ## The Datadog Agent natively encodes its tags as a comma-separated list
    ## of values that are stored in the string `.ddtags`. To work with
    ## and filter off of these tags, you need to parse that string into
    ## more structured data.
    logs_parse_ddtags:
      type: remap
      inputs:
        - datadog_agent.logs
      source: |
        .ddtags = parse_key_value!(.ddtags, key_value_delimiter: ":", field_delimiter: ",")

    ## The `.status` attribute added by the Datadog Agent needs to be deleted, otherwise
    ## your logs can be miscategorized at intake.
    logs_remove_wrong_level:
      type: remap
      inputs:
        - logs_parse_ddtags
      source: |
        del(.status)

    ## This is a placeholder for your own remap (or other transform)
    ## steps with tags set up. Datadog recommends these tag assignments.
    ## They show which data has been moved over to OP and what still needs
    ## to be moved.
    logs_enrich:
      type: remap
      inputs:
        - logs_remove_wrong_level
      source: |
        .ddtags.sender = "observability_pipelines_worker"
        .ddtags.opw_aggregator = get_hostname!()

    ## Before sending data to the logs intake, you must re-encode the
    ## tags into the expected format, so that it appears as if the Agent is
    ## sending it directly.
    logs_finish_ddtags:
      type: remap
      inputs:
        - logs_enrich
      source: |
        .ddtags = encode_key_value!(.ddtags, key_value_delimiter: ":", field_delimiter: ",")

    metrics_add_dd_tags:
      type: remap
      inputs:
        - datadog_agent.metrics
      source: |
        .tags.sender = "observability_pipelines_worker"
        .tags.opw_aggregator = get_hostname!()

  ## This buffer configuration is split into the following, totaling the 288GB
  ## provisioned above:
  ## - 240GB buffer for logs
  ## - 48GB buffer for metrics
  ##
  ## This should work for the vast majority of OP Worker deployments and should rarely
  ## need to be adjusted. If you do change it, be sure to update the size of the persistence
  ## block above.
  ##
  ## The "${DD_API_KEY}" parameters are automatically replaced by the API
  ## key you entered in the `datadog` section at the top of this file.
  sinks:
    datadog_logs:
      type: datadog_logs
      inputs:
        - logs_finish_ddtags
      default_api_key: "${DD_API_KEY}"
      site: "${DD_SITE}"
      compression: gzip
      buffer:
         type: disk
         max_size: 257698037760
    datadog_metrics:
      type: datadog_metrics
      inputs:
        - metrics_add_dd_tags
      default_api_key: "${DD_API_KEY}"
      site: "${DD_SITE}"
      buffer:
        type: disk
        max_size: 42949672959
