What Does This Do

This makes the tracer's agent supervisor in Azure App Service recover from overlapping restarts, and makes its lifecycle readable in default-level logs. It's stacked on #12898, so the diff here is the 6 commits on top of that branch. Each commit message has the details.

1. ProcessSupervisor logs each agent start, exit (exit code and run time), and stop at info, with the tracer PID and, on Java 9+, the agent PID. It also logs when it uses an agent that another process started, when that agent disappears, and when shutdown leaves an agent running. After repeated quick failures these lines drop to debug until the agent stays up.
2. Restarts back off from 2 s, doubling to a 60 s cap, and never stop. The fault count resets only after the agent has stayed up for 60 s.
3. While an agent this tracer started is running, the supervisor health-checks it every 10 s and restarts it after 3 failed checks in a row. It never starts a second copy while its own is still running.
4. A pipe whose instances are all busy counts as present.
5. The trace agent health check sends GET /info over a pipe handle of its own, with tracing muted, and waits at most 2 s.
6. In App Service, each JVM writes its own log file, <name>-<pid>.<ext>, which rolls over at DD_MAX_LOGFILE_SIZE (10 MB by default). At startup a background thread deletes this tracer's own per-process files older than DD_TRACE_LOGFILE_RETENTION_DAYS (32 by default, 0 turns cleanup off). These match the .NET tracer's settings.

Motivation

On Azure App Service (Windows), an overlapped IIS recycle leaves Java apps without telemetry until someone restarts them (SVLS-9057, escalation SLES-2826). The old and new worker run at the same time, and both tracers supervise datadog-trace-agent.exe and dogstatsd.exe on the same install-wide named pipes.

We reproduced the overlap in App Service. Before these changes:

• The default logs couldn't show what happened. Starts, exits, exit codes, and use of another worker's agent were debug-only or not logged.
• A new JVM truncated the shared tracer log file from 3,522 bytes to 0, so the old JVM's last lines, including its shutdown, were lost. This is likely why customer logs never cover an outage.
• Each worker start runs several JVMs in a row through JavaBootstrapper, four in our runs, and each one starts and stops its own agents.
• ProcessSupervisor reset its fault count on every start, so an agent that kept exiting restarted every 2 s forever, while a start that kept throwing stopped retrying after 5 attempts. Once it started an agent, it blocked in waitFor(), so a hung agent was never checked.

With these commits and the StatsD commits from #12898 in a repro build, both agents failed one health check while starting and then passed, with no restart. When the old worker's agents exited, a JVM in the new worker restarted both within 1 s. Traces came back about 2 min 27 s after the recycle started, and about 1 min 50 s of that was JVM restarts in the new worker. In a run with the per-process log file, the old JVM's file was still there after the recycle.

Additional Notes

Design choices and known gaps:

• The per-process log file changes how tracer logging works in App Service. It's the last commit, so it can come out on its own if the Java tracer team wants a different approach.
• It gets the PID through ProcessHandle by reflection, with a JMX fallback on Java 8, because PidHelper can't be used safely during logging startup. Its cleanup runs on a plain daemon thread.
• It fails checkConfigurations: it calls EnvironmentVariables.get directly, and DD_MAX_LOGFILE_SIZE and DD_TRACE_LOGFILE_RETENTION_DAYS aren't in metadata/supported-configurations.json. If the team wants the log file, this gets fixed here. Registering the keys now would add public configuration ahead of review.
• AasPerProcessLogFile is left out of agent-logging's instruction coverage rule. Its PID lookup has separate Java 8 and Java 9+ paths, and no single JVM runs both. The branch rule still applies to it. If reviewers prefer, the PID lookup can move into its own small class, and only that class would be excluded.
• Busy pipes are recognized by the English text of the open error.
• Any HTTP status from /info counts as healthy.
• A slow /info from an agent that another worker started causes one duplicate start. The duplicate loses the pipe race and exits.
• Pipe reads can't time out, so an /info request to a hung agent stays blocked until that agent exits. Later checks fail without sending another request.
• The supervisor restarts only an agent it started, and never kills one it didn't. If an adopted trace agent hangs while holding the pipe, the tracer logs it once and keeps retrying on the capped backoff, but traces stay down until that agent exits.
• On Java 8 the logs omit the child agent's PID, because Java 8 has no public API for it.

Tests: ProcessSupervisorTest covers the backoff, the fault-count reset, restarting after failed health checks, adopting an agent it didn't start, and not starting a second agent while one won't stop. AasPerProcessLogFileTest covers the file name, rollover, and retention cleanup. The pipe health checks and the busy-pipe check ran in the App Service repro on Windows and have no unit tests. Per-process pipe names, so that overlapping workers never share agents, are the planned follow-up and aren't in this PR.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: SVLS-9057