Hi Ron.
If logs are ingested via OneAgent and a loss of connectivity scenario happens, logs that are not sent to Dynatrace are stored in the local cache. When the OneAgent cache limit is reached, it stops reading data from the source, but as soon as connectivity is back to normal, it resumes reading from the place where the last log line was ingested. In that case, the rotation of logs can be problematic. If log records that have not been sent yet are removed or deflated before the connectivity is restored, OneAgent will not be able to ingest them. This should be addressed by log producer configuration.
The cache size is not configurable by the OneAgent component owner, but in case of specific requirements or network specifics, Dynatrace support can influence this setting on given tenant-based use case details.
We constantly improve log ingest characteristics. We plan to introduce a way to ingest compressed files via OneAgent and invest further in elastic OneAgent retransmission handling to upgrade resiliency to changing connectivity characteristics.
The cache mechanism is also in use if logs are integrated via the log ingestion API exposed on Environment ActiveGate. If network issues prevent log forwarding to Dynatrace and the cache is full, the API returns error 503 Service Unavailable: Usable space limit reached so that the API client will retransmit log batches that were rejected during an outage.
Disk queue size is configurable. Please refer to the documentation:
* https://docs.dynatrace.com/docs/observe-and-explore/logs/lma-log-ingestion/lma-log-ingestion-via-api...
* https://docs.dynatrace.com/docs/setup-and-configuration/dynatrace-activegate/configuration/configure...
