Thomas Eizinger

> > I might be wrong but I did not find any docs about managed Prometheus for non Kubernetes environments, eg. [cloud.google.com/stackdriver/docs/managed-prometheus/setup-managed](https://cloud.google.com/stackdriver/docs/managed-prometheus/setup-managed). > > The docs are a bit convoluted...

It is not unfortunately. Depends on https://github.com/open-telemetry/opentelemetry-rust-contrib/issues/10.

https://github.com/firezone/firezone/pull/2050 adds and configures an OTLP exporter for traces for the relay. Let's see if that works will with the ops agent side-car.

> I think @AndrewDryga implemented some version of this? Can this be closed? I am not aware that we export any metrics at the moment.

We actually are recording metrics! https://console.cloud.google.com/monitoring/metrics-management?referrer=search&project=firezone-staging&pageState=(%22metricsTableFilter%22:(%22p%22:12))

Thanks! I'd hold off on changing this for now until we revisit, how want to do fallback, redundancy etc.

> Can this be closed? We can close it for now. Eventually, we should make a (backwards-compatible) change to the message to remove some cruft in the clients.

> I would prefer first trying to devise a scheme to do this within our own WireGuard tunnel. We have the peers already connected, we would just need to agree...

> > we are limited to protocols that do their own retransmission > > Open a tcp socket and receive JSON That would mean doing holepunching for TCP which requires...

> I would love to go all-in on QUIC, but we need more real-world data about how it behaves globally on networks that don't honor the same net neutrality laws...