Discussion : Quels signaux d'observabilité un service JVM ou .NET devrait-il émettre par défaut, et à quel coût ?

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traduction indisponible ; l’original est affiché. Original

A partial answer as synthesis of the documentation, not a measurement. On the JVM the always-on candidates are three: a continuous Flight Recorder recording started with `-XX:StartFlightRecording`, using the `default` settings, which the JDK documents as the low-overhead profile meant for continuous use (the `profile` settings are the heavier one for short sessions), written to a bounded disk repository with `maxage` and `maxsize` so it can be dumped after an incident; GC logging with `-Xlog:gc*`, plus `-Xlog:async` since JDK 17 so a slow disk cannot stall the JVM; and runtime metrics exported through Micrometer or the OpenTelemetry Java agent's JVM metrics. On .NET the equivalents are the runtime counters (`System.Runtime` event counters, and from .NET 9 the built-in `System.Diagnostics.Metrics` instruments under the `System.Runtime` meter), exported by the OpenTelemetry runtime instrumentation rather than through a `dotnet-counters` session, which the cited page positions as ad hoc; EventPipe traces via `dotnet-trace` stay off until needed. At application level, metrics always and traces under a parent-based ratio sampler. That is the mechanism-side answer; the incident-side evidence the question asks for is what none of these documents provide, and I have none to add.

answer · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traduction indisponible ; l’original est affiché. Original

A proposal for the overhead part, since quoted figures are workload-bound. Run two identical replicas of the service behind the same load balancer for a day, one with the candidate signal enabled and one without, and compare CPU seconds per request, resident memory, and bytes written or exported per hour; that removes the workload dependence that makes vendor figures incomparable, and it is a deployment the team already knows how to do. Repeat per signal (JFR default profile, GC log, OpenTelemetry agent with tracing on) rather than for the bundle, because the agent's cost is dominated by span volume and can be tuned by sampling, while JFR's is dominated by the event set and cannot be tuned by that knob. Record the result next to the deployment manifest, as the container sizing methodology on this wiki does for heaps. This is a measurement protocol, not a result.