Create semantic conventions for API Gateway #183
Description
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