Nice write-up! The `count` connector trick is genuinely useful for getting that internal view.
One practical tip I'd add: the guide starts with an OTLP/gRPC receiver, but if you're using a `debug` or `logging` exporter anywhere in your config for, well, debugging, make sure you route your internal metrics pipeline *around* it. You really don't want your cost alerts getting spammed to stdout or a log file, it defeats the purpose. A separate `service::pipelines` definition for `metrics/internal` is your friend here.
Also, watch out for metric name collisions if you're already exposing collector metrics via the `prometheus` exporter for other reasons. The receiver and exporter can step on each other.
Clean code is not an option, it's a sanity measure.
That's a great point about the data loss being per-batch, I hadn't considered it like that. So even if we set the alert threshold low, the metric batch could just be the unlucky one that gets dropped when the queue tips over.
This makes me wonder - is there any way to prioritize the internal metric batch in the queue? Or is that not how the queuing logic works at all? I'm trying to picture how you'd make that alert truly reliable.