Sizing guide for Dynatrace ActiveGates in the Kubernetes monitoring use-case

• Reference
• 5-min read
• Updated on Jan 26, 2026

Setting appropriate resource requests (and limits, when needed) keeps Dynatrace ActiveGate instances stable and predictable. This guide details sizing methods based on scale and workload.

A stable, healthy ActiveGate ensures continuous gap‑free monitoring data.

Understanding the sizing drivers

Actual required resources increase with:

Signs of an unhealthy ActiveGate

These symptoms indicate exhausted resources and potential data loss.

Gaps in monitoring data

ActiveGate collects different types of data independently (for example, Prometheus metrics, Kubernetes events, entities). If one collection task takes longer than 1 minute, only that data type experiences a gap for that window. Other collection tasks continue operating normally.

Heavy CPU throttling

Sustained high throttling means insufficient CPU. Heavy throttling can cause gaps. Minor throttling is usually harmless. If the throttling affects the pod serving the monitoring ActiveGate this can cause data gaps.

Out‑of‑memory restarts

If the ActiveGate is OOM-killed, data becomes unavailable until it restarts. After a restart, repeated OOM kills are likely to occur.

Monitoring and validation

The following indicators can be tracked to understand if the ActiveGate is in a healthy operational state.

Increasing resources

Start with the recommended values below.

Using a dedicated ActiveGate for Kubernetes platform monitoring

Splitting ActiveGate responsibilities into two groups is recommended: One group handling everything related to Kubernetes platform monitoring, including KSPM, and the other managing Agent traffic routing, telemetry ingest, and extensions. This separation provides several advantages:

Sizing ActiveGate

Scenarios are established based on the number of pods that are monitored by a single ActiveGate. The necessary resources can be taken from the following tables.

Secondary factors

Node count

As the number of nodes in your Kubernetes cluster increases, the ActiveGate needs more CPU and memory resources to handle the extra monitoring workload. This includes processing data from node-level system components and events, which adds up proportionally. We group node counts into these categories for sizing guidance:

If your cluster has more than 100 nodes, you'll need to adjust the resource allocations upward to account for the additional demands, ensuring stable and gap-free monitoring. For clusters beyond 500 nodes, consult Dynatrace Support for tailored recommendations.

Amount of Prometheus metrics scraped

Dynatrace supports up to 1000 pod exporters, with each exporter able to provide up to 1000 metrics. If your environment approaches these limits, you'll need to increase the resources allocated to the ActiveGate to ensure reliable performance.

ActiveGate for Kubernetes platform monitoring

All the following use cases have actually the same requirements on the ActiveGate taking over the Kubernetes platform monitoring part.

ActiveGate for OneAgent traffic routing and proxying

The second ActiveGate does not actively participate in Kubernetes platform monitoring but is instead used as a router/proxy on behalf of data streams originating from the OneAgent. We recommend to use separate ActiveGates for traffic forwarding and platform monitoring. Traffic forwarding scales horizontally by adding replicas. Kubernetes monitoring itself does not scale horizontally; instead increase resources.

This setup is required in the following use-cases:

Getting started

The following examples apply the reasoning of splitting the ActiveGates into units with separate concerns. One ActiveGate is responsible for Kubernetes platform monitoring and Kubernetes security posture management, whereas the 2nd ActiveGate is then responsible for agent traffic routing, telemetry ingest and extensions. Adjust requests (and limits if required) to fit your environment.

Kubernetes platform monitoring

This Dynakube resource declares the ActiveGate that is used for the Kubernetes platform monitoring.

apiVersion: dynatrace.com/v1beta5
kind: DynaKube
metadata:
  name: k8s-monitoring
  namespace: dynatrace
  annotations:
    feature.dynatrace.com/k8s-app-enabled: "true"
spec:
  apiUrl: https://ENVIRONMENTID.live.dynatrace.com/api
  tokens: <SECRET NAME>
  metadataEnrichment:
    enabled: true
  # Link to api reference for further information: https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/dynakube-parameters
  activeGate:
    capabilities:
      - kubernetes-monitoring
    resources:
      requests:
        cpu: 1000m
        memory: 10Gi
      limits:
        # cpu: 2000m
        memory: 10Gi
  #kspm:
    #mappedHostPaths:
      #- /boot
      #- /etc
      #- /proc/sys/kernel
      #- /sys/fs
      #- /sys/kernel/security/apparmor
      #- /usr/lib/systemd/system
      #- /var/lib
  #templates:
    #kspmNodeConfigurationCollector:
      #imageRef:
        #repository: public.ecr.aws/dynatrace/dynatrace-k8s-node-config-collector
        #tag: 1.5.2

OneAgent, telemetry ingest and other features

This Dynakube resource declares the ActiveGate that is taking over the OneAgent traffic routing function and other features (except Kubernetes platform monitoring and KSPM).

apiVersion: dynatrace.com/v1beta5
kind: DynaKube
metadata:
  name: agents
  namespace: dynatrace
# Link to api reference for further information: https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/dynakube-parameters
spec:
  apiUrl: https://ENVIRONMENTID.live.dynatrace.com/api
  tokens: <SECRET NAME>
  metadataEnrichment:
    enabled: true
  oneAgent:
    applicationMonitoring: {}
  activeGate:
    capabilities:
      - routing
      - debugging
    resources:
      requests:
        cpu: 1000m
        memory: 6Gi
      limits:
        # cpu: 4000m
        memory: 6Gi
      replicas: 6
    #customProperties:
      #value: |
      #[otlp_ingest]
      #otlp_ingest_enabled = true
  #logMonitoring: {}
  #extensions: {}
  #telemetryIngest:
    #protocols:
      #- jaeger
      #- otlp
      #- statsd
      #- zipkin
    #serviceName: telemetry-ingest
  templates:
    #logMonitoring:
      #imageRef:
        #repository: public.ecr.aws/dynatrace/dynatrace-logmodule
        #tag: <>
    #tolerations:
        #- effect: NoSchedule
        #  key: node-role.kubernetes.io/master
        #  operator: Exists
        #- effect: NoSchedule
        #  key: node-role.kubernetes.io/control-plane
        #  operator: Exists
    #extensionExecutionController:
      #imageRef:
        #repository: <ENVIRONMENTID>/dynatrace/linux/dynatrace-eec
        #tag: latest
    #otelCollector:
        #replicas: 1
        #imageRef:
          #repository: public.ecr.aws/dynatrace/dynatrace-otel-collector
          #tag: <tag>