Endpoints do OTLP
O OpenTelemetry Protocol (OTLP) é um protocolo de entrega de dados de telemetria de uso geral projetado para o OpenTelemetry. Os endpoints do CloudWatch OpenTelemetry são endpoints HTTP 1.1. Você precisa configurar o coletor do OpenTelemetry para começar a enviar dados de telemetria aberta para o CloudWatch. Para obter mais informações, consulte Introdução.
Endpoint de logs
O endpoint de logs segue o padrão https://logs.. Por exemplo, para a Região da AWS.amazonaws.com/v1/logsUS West (Oregon) (us-west-2) Region, o endpoint será https://logs.us-west-2.amazonaws.com/v1/logs. Você pode usar o endpoint acima para encaminhar logs para um LogGroup e LogStream existentes. Para obter mais informações sobre a configuração de LogGroup para ingerir dados de log, consulte Amazon CloudWatch Logs concepts.
Você deve configurar LogGroup e LogStream ao invocar o endpoint do CloudWatch Logs OpenTelemetry definindo os nomes dos cabeçalhos HTTP x-aws-log-group e x-aws-log-stream como LogGroup e LogStream, respectivamente. Para obter mais informações, consulte Introdução.
O endpoint é compatível com os métodos de autenticação a seguir:
-
Signature Version 4 (SigV4) da AWS: recomendado para workloads em execução na AWS. Usa credenciais de curto prazo por meio de perfis do IAM. Para obter mais informações, consulte AWS Signature Version 4 para solicitações de API.
-
Token do portador (chave de API): para workloads executadas fora da AWS ou ambientes que não oferecem suporte ao SDK da AWS. Requer que a autenticação do token do portador seja ativada no grupo de logs de destino. Para ter mais informações, consulte Como configurar a autenticação de token do portador para Logs.
Quando o tamanho do evento de logs excede 1 MB, o CloudWatch Logs trunca automaticamente até dez campos, começando pelos maiores. Cada campo é truncado conforme necessário para manter o tamanho total do evento o mais próximo possível de 1 MB. As partes excedentes são armazenadas como objetos de logs grandes (LLOs) e campos de referência do sistema LLO são adicionados. Opcionalmente, você pode especificar os caminhos de campo que precisam ser truncados definindo o cabeçalho HTTP x-aws-truncatable-fields . Os LLOs podem ser recuperadas e transmitidos de volta usando a API GetLogObject. Para obter mais informações, consulte GetLogObject. Compatibilidade com eventos de log com mais de 1 MB e a experiência de LLO estão disponíveis no Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Frankfurt), Ásia-Pacífico (Sydney), Ásia-Pacífico (Mumbai), Leste dos EUA (Ohio), Europa (Irlanda), Ásia-Pacífico (Tóquio) e Ásia-Pacífico (Singapura).
Endpoint de métricas
O endpoint de métricas segue o padrão https://monitoring.. Por exemplo, para a região Oeste dos EUA (Oregon) (us-west-2), o endpoint será AWS
Region.amazonaws.com/v1/metricshttps://monitoring.us-west-2.amazonaws.com/v1/metrics.
Você precisa configurar o OpenTelemetry Collector para começar a enviar métricas para o CloudWatch. O endpoint é compatível com dois métodos de autenticação:
-
Signature Version 4 (SigV4) da AWS: o método de autenticação recomendado usando credenciais de curto prazo. Para obter mais informações, consulte AWS Signature Version 4 para solicitações de API.
-
Token do portador (chave de API): para workloads executadas fora da AWS ou ambientes que não oferecem suporte ao SDK da AWS. Usa uma chave de API de longa duração passada no cabeçalho
Authorization. Para obter mais informações, consulte Configurar autenticação do token do portador para Metrics.
Endpoint de rastreamentos
O endpoint de rastreamentos segue o padrão https://xray.. Por exemplo, para a região Oeste dos EUA (Oregon) (us-west-2), o endpoint será AWS
Region.amazonaws.com/v1/traceshttps://xray.us-west-2.amazonaws.com/v1/traces.
Você precisa configurar o coletor do OpenTelemetry para começar a enviar rastreamentos para o CloudWatch. O endpoint autentica os chamadores usando a autenticação do Signature 4. Para obter mais informações, consulte AWS Signature Version 4 para solicitações de API.
Endpoint do RUM
O endpoint do RUM segue o padrão https://dataplane.rum.{AWS
Region}.amazonaws.com/v1/rum. Por exemplo, na região Oeste dos EUA (Oregon), o endpoint é https://dataplane.rum.us-west-2.amazonaws.com/v1/rum. Esse endpoint lida com os dados de telemetria do lado do cliente (somente rastros e registros de log com eventName) para aplicações do CloudWatch RUM.
Para usar esse endpoint, você deve criar um monitor de aplicação do RUM com uma plataforma móvel (Android/iOS) e usar o trecho de código gerado para instrumentar as aplicações. O trecho de código extrairá os SDKs móveis do RUM que estão configurados com esse endpoint. Você pode configurar ainda mais os SDKs para que o RUM colete telemetria adequadamente.
O endpoint é compatível com solicitações autenticadas e não autenticadas. Você pode usar o AWS Signature Version 4 (SigV4) para solicitações autenticadas ou políticas baseadas em recursos para permitir acesso não autenticado de aplicações móveis.
Para saber mais sobre os modelos de autenticação definidos nos SDKs, consulte o seguinte:
-
Aplicações iOS: SDK do AWS Distro for OpenTelemetry (ADOT) para iOS
. -
Aplicações Adroid: SDK do AWS Distro for OpenTelemetry (ADOT) para Android
.
Limites e restrições de endpoints
A tabela lista os limites e as restrições comuns de endpoints para métricas, rastreamentos e logs.
| Limite | Endpoint | Mais informações |
|---|---|---|
|
Extensão de coletor obrigatório |
Para enviar métricas, logs e rastreamentos para o endpoint do OTLP, você deve usar sigv4authextension Para os endpoints de métricas e logs, você também pode se autenticar com um token de portador usando a extensão bearertokenauth |
|
|
Protocolos compatíveis |
HTTP |
O endpoint é compatível somente com HTTP e não com gRPC |
|
Versões compatíveis com o OTLP |
OTLP 1.x |
|
|
Formato da carga |
binário, json |
O endpoint aceita solicitações usando os formatos binário e json |
|
Métodos de compactação |
gzip, none |
O endpoint é compatível apenas com os métodos de compactação gzip e none |
A tabela lista os limites e as restrições dos endpoints para rastreamentos.
| Limite | Endpoint de rastreamentos | Mais informações |
|---|---|---|
|
Máximo de solicitações e bytes não compactados |
5 MB |
O endpoint do OTLP rejeitará solicitações maiores que 5 MB quando a carga útil for descompactada. |
|
Máximo de eventos e solicitações |
10 mil extensões |
O número máximo de extensões em um lote é 10 mil. Exceder esse limite causará a rejeição da chamada de API. |
|
Tamanho individual do recurso e do escopo |
16 KB |
Cada recurso individual e seu escopo correspondente não devem exceder o tamanho de 16 KB. Exceder esse limite para qualquer recurso causará a rejeição da chamada de API inteira. |
|
Tamanho máximo individual de extensão |
200 KB |
Extensões com mais de 200 KB serão rejeitadas pelo endpoint. |
|
Carimbos de data e hora criados pela extensão |
2 horas no futuro e 14 dias no passado |
Nenhuma das extensões no lote pode durar mais de duas horas no futuro ou mais de 14 dias no passado. |
|
Intervalo de tempo máximo em eventos e solicitações |
24 horas |
A tabela lista os limites e as restrições dos endpoints para métricas.
| Limite | Endpoint de métricas | Mais informações | Código de erro |
|---|---|---|---|
Máximo de TPS |
500 |
O número máximo de solicitações por segundo permitido por conta. |
429 |
Taxa máxima de criação de novas séries |
1.000.000 |
Número máximo de novas séries que podem ser criadas em uma janela de 10 minutos. Esse limite se aplica somente à criação de novos nomes de métricas, não à ingestão de pontos de dados para métricas existentes. |
429: todas as métricas nas solicitações têm controle de utilização; 200: as métricas nas solicitações têm controle parcial de utilização |
Tamanho máximo de solicitação |
1 MB |
O tamanho máximo da solicitação não compactada. |
400 |
Contagem máxima de pontos de dados |
1.000 |
O número máximo de pontos de dados enviados em uma única solicitação. Esse número é uma soma de ResourceMetrics, ScopeMetrics e Metrics. |
400 |
Tamanho máximo dos metadados |
40 KB |
O tamanho máximo combinado de todos os rótulos e valores de rótulos aceitos para uma série por ponto de dados. |
400: todas as métricas nas solicitações são inválidas; 200: as métricas nas solicitações são parcialmente inválidas |
Contagem máxima de rótulos |
150 |
Número máximo de rótulos nos atributos de recurso/escopo/ponto de dados por ponto de dados. |
400: todas as métricas nas solicitações são inválidas; 200: as métricas nas solicitações são parcialmente inválidas |
Carimbos de data e hora criados por métricas |
10 minutos no futuro e 14 dias no passado |
As métricas podem ser criadas com um carimbo de data e hora de no máximo 10 minutos no futuro e no máximo 14 dias no passado. |
400 |
A tabela lista os limites e as restrições de endpoints para logs.
| Limite | Endpoint de logs | Mais informações |
|---|---|---|
|
Máximo de solicitações e bytes não compactados |
1 MB |
O endpoint do OTLP rejeitará solicitações maiores que 1 MB quando a carga útil for descompactada. O tamanho máximo de uma solicitação é 1.048.576 bytes após a descompactação e desserialização de dados binários serializados por buffers de protocolo. Esse tamanho é calculado como a soma de todas as mensagens de eventos em UTF-8, mais 26 bytes para cada registro de log. |
|
20 MB Disponível somente nas regiões Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Frankfurt), Ásia-Pacífico (Sydney), Ásia-Pacífico (Mumbai), Leste dos EUA (Ohio), Europa (Irlanda), Ásia-Pacífico (Tóquio) e Ásia-Pacífico (Singapura). |
O tamanho máximo da solicitação é de 20 MB (20.971.520 bytes) após a carga útil do OTLP ser descompactada e decodificada do formato JSON. Para logs de até 1 MB: esses logs têm acesso total a todos os recursos do CloudWatch Logs, incluindo consultas e live tail. Para logs maiores que 1 MB: a parte excedente é processada como objetos de logs grandes (LLOs). |
|
Solicitação por segundo |
5000 |
5 mil transações por segundo por conta por região. Você pode solicitar um aumento na cota de controle de utilização por segundo usando o serviço do Service Quotas. |
|
Tamanho individual do recurso e do escopo |
16 KB |
Cada recurso individual e seu escopo correspondente não devem exceder o tamanho de 16 KB. Exceder esse limite para qualquer recurso causará a rejeição da chamada de API inteira. |
|
Tamanho individual do LogEvent |
1 MB |
O tamanho do LogEvent é calculado como a soma dos tamanhos para cada LogRecord, Escopo e Recurso. Não é possível alterar esta cota. |
Carimbos de data e hora criados por logs |
2 horas no futuro e 14 dias no passado |
Os registros de logs no lote não precisam estar em ordem cronológica. No entanto, os registros de logs no lote não podem ser mais de 2 horas no futuro e mais de 14 dias no passado. Além disso, nenhum dos registros de logs pode ser anterior ao período de retenção do grupo de logs. |
|
Intervalo de tempo máximo em eventos e solicitações |
24 horas |
|
|
Máximo de eventos e solicitações |
10.000 logs |
O número máximo de eventos de logs em um lote é 10 mil. Exceder esse limite causará a rejeição da chamada de API. |
|
Máximo de objetos de logs grandes/solicitações |
1 registro de log Disponível nas regiões Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Frankfurt), Ásia-Pacífico (Sydney), Ásia-Pacífico (Mumbai), Leste dos EUA (Ohio), Europa (Irlanda), Ásia-Pacífico (Tóquio) e Ásia-Pacífico (Singapura). |
Para conteúdo que exceda 1 MB em um evento de logs, o conteúdo em excesso é armazenado como LLOs. Limitado a 1 registro de log por solicitação. |
|
Máximo de objetos de logs grandes/registros |
10 LLOs Disponível nas regiões Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Frankfurt), Ásia-Pacífico (Sydney), Ásia-Pacífico (Mumbai), Leste dos EUA (Ohio), Europa (Irlanda), Ásia-Pacífico (Tóquio) e Ásia-Pacífico (Singapura). |
Um único registro de log pode conter até 10 LLOs. |
nota
Os limites de logs da conta são compartilhados entre o SDK e o novo endpoint de logs.
