OTLP

Server obligations

The MUSTs that name the server. If you operate an OTLP endpoint, this is the list you are judged against.

• MUSTBad Data

  If the processing of the request fails because the request contains data that cannot be decoded or is otherwise invalid and such failure is permanent, then the server MUST respond with HTTP 400 Bad Request.

• MUSTBinary Protobuf Encoding

  The client and the server MUST set "Content-Type: application/x-protobuf" request and response headers when sending binary Protobuf encoded payload.

• MUSTFailures

  If the processing of the request fails, the server MUST respond with appropriate HTTP 4xx or HTTP 5xx status code.

• MUSTFull Success

  On success, the server response MUST be a Export\<signal>ServiceResponse message (ExportTraceServiceResponse for traces, ExportMetricsServiceResponse for metrics, ExportLogsServiceResponse for logs and ExportProfilesServiceResponse for profiles).

• MUSTFull Success

  The server MUST leave the partial_success field unset in case of a successful response.

• MUSTFull Success

  On success, the server MUST respond with HTTP 200 OK.

• MUSTFull Success

  The server MUST leave the partial_success field unset in case of a successful response.

• MUSTJSON Protobuf Encoding

  The client and the server MUST set "Content-Type: application/json" request and response headers when sending JSON Protobuf encoded payload.

• MUSTOTLP/gRPC Request

  The server MUST enforce a message size limit when receiving the request, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious client sending an oversized request.

• MUSTOTLP/gRPC Request

  If the limit is exceeded, the gRPC server implementations MUST report a RESOURCE_EXHAUSTED code as a non-retryable error.

• MUSTOTLP/gRPC Response

  The client MUST enforce a message size limit when receiving the response, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious server. gRPC client implementations typically enforce a default incoming message size limit of 4 MiB, which is acceptable to use.

• MUSTOTLP/gRPC Response

  The server MUST limit the size of the response message, including before compression, to avoid overwhelming the client.

• MUSTOTLP/gRPC Response

  If the response still cannot fit within the limit, the server MUST fail the request with the RESOURCE_EXHAUSTED code as a non-retryable error.

• MUSTOTLP/gRPC Throttling

  The client MUST then throttle itself to avoid overwhelming the server.

• MUSTOTLP/HTTP Request

  The server MUST limit the size of the request body when parsing it, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious client sending an oversized request.

• MUSTOTLP/HTTP Request

  If the limit is exceeded, the server MUST respond with HTTP 413 Content Too Large.

• MUSTOTLP/HTTP Response

  The client MUST limit the size of the response body when parsing it, including after decompression, to mitigate possible excessive memory usage caused by a misconfigured or malicious server.

• MUSTOTLP/HTTP Response

  The server MUST limit the size of the response body, including before compression, to avoid overwhelming the client.

• MUSTOTLP/HTTP Response

  If the response still cannot fit within the limit, the server MUST fail the request with HTTP 500 Internal Server Error.

• MUSTOTLP/HTTP Response

  The server MUST set "Content-Type: application/x-protobuf" header if the response body is binary-encoded Protobuf payload.

• MUSTOTLP/HTTP Response

  The server MUST set "Content-Type: application/json" if the response is JSON-encoded Protobuf payload.

• MUSTOTLP/HTTP Response

  The server MUST use the same "Content-Type" in the response as it received in the request.

• MUSTPartial Success

  If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server response MUST be the same Export\<signal>ServiceResponse message as in the Full Success case.

• MUSTPartial Success

  Additionally, the server MUST initialize the partialsuccess field (ExportTracePartialSuccess message for traces, ExportMetricsPartialSuccess message for metrics, ExportLogsPartialSuccess message for logs and ExportProfilesPartialSuccess for profiles), and it MUST set the respective rejectedspans, rejecteddatapoints, rejectedlogrecords or rejected_profiles field with the number of spans/data points/log records/profiles it rejected.

• MUSTPartial Success

  If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server MUST respond with HTTP 200 OK.

• MUSTPartial Success

  Additionally, the server MUST initialize the partialsuccess field (ExportTracePartialSuccess message for traces, ExportMetricsPartialSuccess message for metrics, ExportLogsPartialSuccess message for logs and ExportProfilesPartialSuccess for profiles), and it MUST set the respective rejectedspans, rejecteddatapoints, rejectedlogrecords or rejected_profiles field with the number of spans/data points/log records it rejected.

• MUSTProtocol Details

  All server components MUST support the following transport compression options:

Wire definitions