This page describes log delivery and reliability when logs flow through the following three components:
Each component has its own buffering behavior and limits.
Other log ingest paths—including cloud log forwarding, the Dynatrace OpenTelemetry Collector, Dynatrace Extensions, and third-party edge components that connect to the Log ingestion API—are out of scope for this page. For the full list of ingest options, see Log ingestion.
Understanding the full delivery path helps you design a log collection that is both resilient and within platform limits. This page describes how each component handles log ingestion, queuing, and failure recovery.
A log record is dropped at ingest if its timestamp is older than the accepted time range. This means that even with a strong queuing mechanism, logs held in a queue beyond this window are dropped. For the exact range, see Log Management and Analytics default limits.
Grail and its supporting components include scaling mechanisms to handle sudden ingest spikes, for example due to queues that need to be ingested after connectivity issues.
There is no hard limit on the number of log records that can be sent to Grail within a given period. For more information about platform-wide limits, see Log Management and Analytics default limits.
For details about how OneAgent reads, buffers, and delivers logs—including polling intervals, buffering layers, and connectivity, see OneAgent Log module.
Environment ActiveGate allows for several log sources. Each has a different queuing logic.
Logs received from OneAgent are immediately forwarded to your Dynatrace environment. The Environment ActiveGate does not queue them locally. If the Dynatrace environment is unreachable, logs are not retained on the Environment ActiveGate for later delivery.
The reliability mechanism operates on the OneAgent side: OneAgent waits for an ACK from the Environment ActiveGate and resends if the ACK is not received in time. Deduplication and crash-recovery techniques prevent data loss or duplication if OneAgent restarts during transmission.
Limits and data loss scenarios
ACK within 24 hours, the message is dropped.Logs received on the /api/v2/logs/ingest and /api/v2/otlp/v1/logs endpoints are queued on disk on the Environment ActiveGate.
By default, the disk queue is stored in the system-wide temporary folder and is capped at 300 MB. You can override both with the disk_queue_path and disk_queue_max_size_mb properties in the [generic_ingest] section of the ActiveGate configuration. See ActiveGate configuration properties and parameters for details.
The queue uses compression; for text-based logs the typical compression ratio is approximately 10:1, so a 300 MB queue can effectively hold around 3 GB of uncompressed log data.
When the disk queue reaches capacity, the Environment ActiveGate returns an HTTP 503 error. See Log Monitoring API v2 ingest response codes for details.
The retry mechanism between Dynatrace components does not implement a backoff strategy. When the Environment ActiveGate retries queued messages after a Grail outage, it may generate a burst of traffic that coincides with new incoming messages. Plan your capacity accordingly.
Logs received within extensions (for example, Syslog) are managed by the Extension Execution Controller (EEC), which has a default buffer size of 1.5 GB. This limit is configurable.
The default resend behavior on the EEC side is:
Both intervals are configurable. For sizing guidance, see Hardware and system requirements for ActiveGates on Linux.
Network zones are Dynatrace entities that reflect your network topology and enable efficient traffic routing by minimizing cross-region data transfer. When deploying OneAgent alongside an Environment ActiveGate, configuring network zones is recommended for production environments.
See Network zones, OneAgent connectivity in network zones, and ActiveGate connectivity in network zones for details.
If a network proxy is positioned between OneAgent and an Environment ActiveGate, configure the proxy URL on the Environment ActiveGate to ensure OneAgents can route their traffic through it. See Set up a reverse proxy for OneAgent for details.
OneAgent automatically selects an available Environment ActiveGate for communication. When network zones are configured, OneAgent prioritizes an ActiveGate in the same zone. When you scale the number of ActiveGates up or down, OneAgents automatically redistribute traffic across the active set—including during ActiveGate maintenance, failure, or temporary unavailability. See OneAgent connectivity in network zones for details about the connectivity algorithm.
Dynatrace does not provide built-in load balancing for log ingest via the REST API on Environment ActiveGates. To ensure high availability and balanced traffic distribution, configure DNS-based load balancing or deploy a hardware load balancer in front of your ActiveGate deployment.
The Environment ActiveGate process is continuously monitored by a dedicated watchdog process. If the Environment ActiveGate crashes or becomes unresponsive, the watchdog automatically restarts it. See Configure ActiveGate for a full list of configuration options.