Create semantic conventions for API Gateway

[SonjaChevre]

We (Tyk Technologies, maintainer of the Tyk open source API Gateway) would like to work on adding a semantic conventions for API Gateways.

What is an API Gateway?

An API gateway is a tool that aggregates unique application APIs, making them all available in one place. It allows organizations to move key functions, such as authentication and authorization or limiting the number of requests between applications, to a centrally managed location. An API gateway functions as a common interface to (often external) API consumers. From: API Gateway

What are specific observability needs with APIs and API Gateways?

1. Need to generate RED metrics per API name and API version

API teams need to be able to track request rates, error rates and duration per API and per API version.

2. Need to configure different observability pipeline depending on the API name or API tag

Because an API Gateway is a central component that processes traffic for many teams, it is often the case that it captures data that are relevant to different teams, each having their own observability need (different observability back-end, different need for sampling, different need to remove information, …).

What is the current support of API Gateways in OTel?

There are to our knowledge no semantic conventions specific to APIs or API Gateways at the moment.

What are we missing in the semantic conventions?

Non exhaustive list:

• API name
• API version

What is the suggested approach?

We are actively working on adding this information in our Tyk API Gateway (GitHub - TykTechnologies/tyk: Tyk Open Source API Gateway written in Go, supporting REST, GraphQL, TCP and gRPC protocols ) and would welcome other members of the observability and API communities to join us on improving the semantic conventions.

Looking forward to see if this proposal gets any interest!

Sonja

Note: we are also working on another proposal to introduce semantic conventions for GraphQL: #182

[Oberon00]

I wonder if this use case should be integrated in the rpc semantic conventions. For example, the AWS conventions use rpc.method + rpc.service to describe the logical service, even though it's an HTTP-based API. (A field like rpc.service_version would still be needed)

[joaopgrassi]

This was closed by mistake by the stale bot. Re-opening