nemo_gym.telemetry.startup
nemo_gym.telemetry.startup
Where server startup time goes, per server, exported through nemo-lens.
Startup is split between two kinds of process, and neither can see all of it.
The supervisor is the process running gym env start or gym eval run.
It knows when it spawned each server and when that server first answered a health probe, but not what happened in between.
Each server knows what it did after its interpreter started.
It cannot see the venv setup that ran before the server process existed.
The two halves meet through environment variables set when the supervisor spawns a server.
The supervisor sets the spawn time and a W3C traceparent that names its span for that server.
The launch shell adds the time venv setup finished.
The server turns those into its first two stages, venv_setup and interpreter_start, and times the rest itself.
When the server starts accepting connections, it exports its stages as spans under the supervisor’s span, so one startup is one trace.
The Uvicorn workers of a multi-worker server are separate processes that import the server again, and each reports its own stages the same way.
Each call to StageTimeline.mark closes the stage that began at the previous call.
Stages are therefore contiguous and add up to the process’s total, and call sites need no extra indentation.
Spans are created after the fact with explicit timestamps, because telemetry is only initialised partway through startup.
Nothing here may fail a server or the supervisor. Every telemetry step is guarded, and with telemetry off every method returns without exporting anything.
Module Contents
Classes
Functions
Data
API
Bases: StageTimeline
A server process’s own startup stages.
A multi-worker server runs run_webserver in its main process and again in every Uvicorn worker.
The main process times the stages up to the hand-off to Uvicorn.
Each worker times its own spawn, import, and setup.
Each process reports its own spans and metrics, with worker telling them apart.
A process that serves requests reports when the app’s lifespan startup finishes.
Its last stage, uvicorn_startup, therefore ends when it starts accepting connections.
Stamp the hand-off to Uvicorn into the environment for the workers it is about to spawn.
Emit spans and metrics once.
Later calls do nothing.
Report when app’s startup finishes, adding the uvicorn_startup stage.
This wraps the app’s lifespan, so a lifespan the server already set keeps running inside it. The stage ends after that lifespan’s startup, so work the app does there is part of the stage.
One contiguous slice of startup, in wall-clock nanoseconds.
Contiguous stages: each mark closes the stage that began at the previous mark.
Record a stage measured elsewhere and move the cursor to its end.
End the current stage here and name it.
A repeated name adds a second stage.
Bases: StageTimeline
The supervisor’s view of one startup.
It records the supervisor’s own stages and, for each server, when it was spawned and when it first answered a health probe.
Close every open startup span after a startup that did not finish, so the failed run is still exported.
OpenTelemetry exports only spans that have ended.
Without this, a startup that times out or fails would export no gym.startup span, and the spans servers already reported would point at a parent that was never exported.
Each server that was not ready yet gets outcome too, and every closed span gets an error status.
The supervisor stage that was running when startup ended is recorded as unfinished, so the stages still cover the whole startup.
Open the gym.startup span.
Call this once telemetry has been initialised.
Close the gym.startup span with the supervisor’s own stages beneath it, after every server is ready.
Return the environment for one server about to be spawned.
This also records the server’s spawn time.
Record that server_name first answered a health probe.
Later calls for the same server are ignored.