333 Telemetry collection is configurable down to the Python module level

On the topic of snapshots.

A snapshot is not intended to be “like a log(), but for telemetry()”. “Like a log(), but for telemetry” I would think would be log() or emit(). What I mean by “snapshot” is very specifically a fourth thing, outside the big three of (logs, metrics, traces) that don’t have a good industry standard name, but these are things like buffers, frames, snapshots, scrapes, etc.

This is why in my example above, I used telemetry.emit(...) and not telemetry.snapshot(...), because it is a telemetry event being emitted and not what meets the definition of snapshot:

telemetry.emit(
        level=telemetry.INFO
        event=LearningModuleTerminalState(
            kind="LearningModuleTerminalState",
            id=self.learning_module_id,
            terminal_state=TerminalState.MATCH
        )
    )

For a snapshot, I think it’d be something like:

telemetry.snapshot(
    level=telemetry.TRACE,
    event=SensorRGBA(
        kind="SensorRGBA",
        id=self.sensor_module_id,
        image=observation["rgba"] # <-- this data field makes it
        # a snapshot instead of just another telemetry event
    )
)

# likely wrapped to avoid extra data work
if telemetry.isEnabledFor(telemetry.TRACE):
    telemetry.snapshot(
        level=telemetry.TRACE,
        event=SensorRGBA(
            kind="SensorRGBA",
            id=self.sensor_module_id,
            image=observation["rgba"]
        ) 
    )    

For something like a PostEpisodeTelemetry event, unless it has large data buffers in it, I would still classify it as an “event” (it’s just a big/“wide” one) and not as a “snapshot.”

Another heuristic for discriminating between “event” and “snapshot” would be that snapshots are always telemetry.TRACE level and probably contain binary or blob data.

1 Like