Semantic conventions - RPC/gRPC

[jpkrohling]

@lmolkova and @trask have volunteered to be the sponsors for this.

Project proposal: #2684

[alexvanboxel]

Would you consider OpenAPI spec also as RPC metrics?

This is because we're doing reverse mapping from Envoy Logs to OpenAPI metrics using the RPC semantics, with operationId as the method. This is for use as one of the most important signals, and it would be nice to get this formalized, if not under RPC, maybe somewhere else.

[svrnm]

@alexvanboxel can you provide some more details on your question? Many people (including myself) do not know the details of the OpenAPI spec, so a few pointers to what you are trying to accomplish can help to provide an answer

[alexvanboxel]

The OpenAPI specification defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. (copied from doc)

We load all our public and internal OpenAPI specs and build a reverse map from the URL path (discovered from the spec) toward the OperationId defined in the spec. This is then taken by an Apache Beam pipeline that creates metric (duration, bytes sent, and bytes received) histograms per 1 minute. This is then pushed into our metrics backend. This is a valuable source for operation-specific SLOs. Most enterprise software is built now with OpenAPI spec (or spec first => then generate the code, or code first => then generate the OpenAPI spec).

The metrics are close too the RPC definition (if you consider an operationId), but it's not present in the semconv.

[svrnm]

@alexvanboxel this is a question best asked via the sem conv, raise an issue there to have a proper discussion

[alexvanboxel]

I will; I'm slowly working myself in and plan to start joining the SIG meetings.