UMA podmonitor logs repeat "okhttp3.internal.http2.StreamResetException: stream was reset: INTERNAL_ERROR"

Products

• DX Application Performance Management
• DX APM SaaS
• DX OI SaaS
• DX Operational Intelligence
• DX Operational Observability
• DX SaaS

Issue/Introduction

The UMA podmonitor container logs show repeating INTERNAL_ERROR messages when attempting to communicate with the autoattach endpoint on localhost:7777. This occurs even after upgrading to versions that were expected to resolve the issue.

Symptoms:

• Repeating error in podmonitor logs: [ERROR] [I.AutoAttach.API.ContainerInfoClient] error occurred while getting container info data against URL :: https://localhost:7777/autoattach/[CONTAINER_ID]/ps :: okhttp3.internal.http2.StreamResetException: stream was reset: INTERNAL_ERROR

 

• The error may be accompanied by warnings from UnixContainerLister regarding failures to get the process list.

Environment

Product: DX Application Performance Management 

Component: Universal Monitoring Agent (UMA)

 Version: 25.x, 26.x 

Cause

This error is triggered when the podmonitor service attempts to fetch process information (/ps endpoint) for a container that is no longer available, has been terminated, or is in a state where it cannot respond to the request at that specific millisecond.

Engineering has confirmed that this is a valid reporting of a communication failure with a transient or missing container. It does not indicate a functional failure of the UMA agent for other active, healthy containers.

Resolution

As of DX SaaS version 26.1 (and included in subsequent versions like 26.6), Engineering implemented a retry and skip mechanism to manage these transient errors and reduce log noise.

Behavior in Fixed Versions:

1. Retry Logic: When the INTERNAL_ERROR occurs, the agent will retry the request.
2. Graceful Skip: After three failed attempts, the agent will stop trying to attach to that specific container and log a warning: [WARN] [I.A.Discovery.UnixContainerLister] Failed to get process list for container [...] after 3 attempts: Listing process or timeout. Container will now be skipped for autoattach.
3. Functionality: Monitoring and auto-attachment for all other valid, active containers continue to function as expected.

Recommendation:

• Ignore the Error: If you are on version 26.1 or higher, these log entries can be safely ignored as they represent the agent handling unavailable resources.
• Verify Auto-Attach: Ensure that your active application pods are still successfully reporting metrics to the Enterprise Manager. If active pods are failing to attach, investigate potential network or permission issues.
• Log Level: If log volume is a concern, ensure the agent log level is not set to DEBUG unless actively troubleshooting.