search

open-telemetry / semantic-conventions

Defines standards for generating consistent, accessible telemetry across a variety of domains
Apache License 2.0
246 stars 158 forks source link

Create semantic conventions for API Gateway #183

Open SonjaChevre opened 1 year ago

SonjaChevre commented 1 year ago

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:

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: https://github.com/open-telemetry/semantic-conventions/issues/182

Oberon00 commented 1 year ago

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 commented 6 months ago

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