thorian1828i03

Gemini has been watermarking for like a year and doesn't have the same problems.

> The same thing with metric cardinality: by default, only report metrics in a fully aggregated manner. But do tell the monitoring system how they can potentially be broken up if needed (i.e., which labels to add).

How does the monitoring system have any of the context to add labels? That would only exist in application memory.

Grafana went the other way - your app exports all labels, and then you selectively aggregate on ingest: https://grafana.com/docs/grafana-cloud/observe-and-act/adapt...

> That may be prohibitively expensive in terms of CPU/network load.

In practice I've not experienced this even on quite high request rates. While it isn't free, exporting everything has been cheap enough that the real cost in dollars spent is basically marginal (it's _storing_ the data that's expensive)

One strategy do to do that is to trace everything by default and select what to sample later, e.g. https://grafana.com/docs/grafana-cloud/observe-and-act/adapt...

Not true at all! Most of the HTTP APIs, and a good chunk of the webapps, that I've worked on can be defined as a combination of an API spec that carves out valid and invalid behaviors, and a set of behavioral tests for the workflows that the client users care about. Working from a codebase which is generated from a spec document (e.g. OpenAPI or gRPC) and use of tools like https://pkg.go.dev/net/http/httptest and https://bun.com/docs/test/dom makes this a pretty achievable goal in practice.

Writing a benchmark test is about 100x to 1000x easier than writing optimizations. A benchmark test can be as simple as:

    func Benchmark(b *testing.B) {
      for range b.N {
        runCodeUnderBenchmark()
      }
    }

Actually optimizing the runCodeUnderBenchmark() function is far more difficult.