Opening this issue to track the foundational work around performance/scaling-oriented platform metrics that came up in #174 and in the load-testing threads (#168, #176, #98, #44). I proposing a high-level plan here first, but if we get too deep in the details (exact attributes, buckets, etc.), happy to open a Google Doc so we can discuss it there as well.

Scope

When we load test substrate today, we cannot really answer core operational questions with today's telemetry, e.g. is the fleet healthy under load, and where is the bottleneck?
We have three metrics total (rpc.server.call.duration, atenet.router.route.duration, atelet.snapshot.size), but nothing for lifecycle operations, pool saturation, or scheduling outcomes, and some components (ateom, atecontroller) emit no metrics at all. I think we have a good foundation in #174, so I am cleaning that up and using this to track the implementation.

1. otlp push instead of pull
2. Cardinality-wise actor, atespace, and session atrs go on traces/logs/events only, never on metric labels. Template, worker pool, sandbox class, outcome/phase, and cluster are the metric dimensions. We can add exemplars on the duration histograms, so a latency spike can be tracked back to a sampled actor trace. This can be a follow-up.
3. Actor level analytics will be covered by events (named LogRecords in OTel). This came up in Observability At-Scale #174's "are there vital metrics we should push out to logs". It needs the cgroup work first (fix(atelet): set OCI CgroupsPath so each actor gets its own cgroup #161, blocked on All actors are under the pause cgroup #288), so just mentioning this here for context for now

Initial set of metrics

ateapi emits the lifecycle/scheduler/fleet signals, atelet emits the restore/checkpoint phase information.

cc Alex Van Boxel (@alexvanboxel) Julian Gutierrez Oschmann (@juli4n), Zoe Zhao (@zoez7), Eitan Yarmush (@EItanya)