Repository navigation
Conversation
Overlapping worker processes in Azure App Service run several JVMs that share one configured log file, and each new JVM truncates it, so the old JVM's last lines are lost. In an overlapped IIS recycle, a new JVM wiped the old JVM's log, including its shutdown. Copy the .NET tracer: - Write to <name>-<pid>.<ext> instead of the configured file. - Roll over at DD_MAX_LOGFILE_SIZE bytes (default 10 MB). - At startup, delete this tracer's own per-process files last written more than DD_TRACE_LOGFILE_RETENTION_DAYS ago (default 32, 0 turns cleanup off), stopping quietly at the first failure. Only active when DD_AZURE_APP_SERVICES is set.
AasPerProcessLogFile had no tests, so the agent-logging coverage check failed. The new tests check that, in Azure App Service only, the tracer writes to <name>-<pid>.<ext> next to the configured file. They also check that it falls back to standard error when that file cannot be opened, rolls over to numbered files at DD_MAX_LOGFILE_SIZE (0 turns rollover off), and appends to an existing file instead of truncating it. Cleanup is checked too: it deletes only this tracer's per-process files older than DD_TRACE_LOGFILE_RETENTION_DAYS (0 turns it off), and it stops quietly when a file cannot be deleted. The class is left out of the instruction coverage rule. Its PID lookup has one path for Java 8 and another for Java 9+, and coverage runs on only one JVM, so one path always shows as missed. The class can't use PidHelper, because PidHelper sets up an slf4j logger and this code runs while the tracer's logger is starting. The branch rule still covers the class, and both rules still cover RollingFileOutputStream.
AasPerProcessLogFile read DD_AZURE_APP_SERVICES, DD_MAX_LOGFILE_SIZE, and DD_TRACE_LOGFILE_RETENTION_DAYS with EnvironmentVariables.get, which the config inversion linter rejects. Read them through ConfigHelper.env, and add the two log file settings to supported-configurations.json with the .NET tracer's type and defaults: int, 10485760 bytes, and 32 days.
Lewis-E
added
type: bug fix
Contributor
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
Contributor
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Does This Do
In Azure App Service, each JVM writes its own tracer log file,
<name>-<pid>.<ext>, instead of sharing the configured one. The file rolls over atDD_MAX_LOGFILE_SIZE(10 MB by default). At startup a background thread deletes this tracer's own per-process files older thanDD_TRACE_LOGFILE_RETENTION_DAYS(32 by default, 0 turns cleanup off). Both settings use the .NET tracer's names and defaults. Logging to stderr or stdout, and logging outside App Service, are unchanged. Each commit message has the details.Motivation
On Azure App Service (Windows), each new JVM truncates the tracer log file that the JVMs before it wrote to (SVLS-9057, escalation SLES-2826). An overlapped IIS recycle runs the old and new worker at the same time, and each worker start runs several JVMs in a row through
JavaBootstrapper, four in our runs. In our App Service repro, a new JVM truncated the shared 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.In a repro run with this change, the old JVM's file was still there after the recycle. #12899 describes the rest of the repro.
Additional Notes
Design choices and known gaps:
ProcessHandleby reflection, with a JMX fallback on Java 8, becausePidHelpercan't be used safely during logging startup. Its cleanup runs on a plain daemon thread.DD_MAX_LOGFILE_SIZEandDD_TRACE_LOGFILE_RETENTION_DAYS, registered inmetadata/supported-configurations.jsonwith the .NET tracer's type and defaults. They're read as environment variables only, likeDD_AZURE_APP_SERVICES, because logging starts beforeConfig.AasPerProcessLogFileis 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.Tests:
AasPerProcessLogFileTestcovers the file name, rollover, appending to an existing file, falling back to stderr when the file can't be opened, and retention cleanup.Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: SVLS-9057