Como dimensionar Cloud Server para OpenTelemetry

Resposta direta

Um Cloud Server para OpenTelemetry em produção deve ser dimensionado pelo volume de spans, métricas e logs processados por segundo, não apenas pelo número de aplicações monitoradas. Para uma operação pequena, um OpenTelemetry Collector com 2 vCPUs, 4 GB de RAM e 40 GB de SSD costuma ser um ponto inicial seguro. Ambientes com vários serviços, picos de telemetria ou processamento adicional podem exigir 4 vCPUs e 8 GB de RAM por instância, além de dois Collectors atrás de um balanceador. O disco local tem papel secundário quando os dados são enviados diretamente a um backend remoto, mas passa a ser relevante ao usar filas persistentes. Antes de ampliar o servidor, monitore uso de memória, consumo de CPU, itens recusados, falhas de exportação, tamanho das filas e latência do backend.

Resumo rápido

• Comece com 2 vCPUs e 4 GB de RAM para uma carga pequena, mas valide o tamanho por meio de teste controlado.
• Separe, sempre que possível, o OpenTelemetry Collector do backend que armazena métricas, logs e traces.
• Configure memory_limiter antes do batch para reduzir o risco de encerramento por falta de memória.
• Use dois Collectors em produção quando a perda temporária de telemetria afetar alertas, auditoria ou investigação de incidentes.
• Calcule a rede pelo volume ingerido, pelos picos e pelo número de cópias enviadas a backends diferentes.
• Ative TLS e autenticação no receptor OTLP exposto fora de uma rede privada.
• Monitore o próprio Collector por meio de métricas internas, logs e alertas de fila, recusas e falhas de exportação.

Como funciona uma arquitetura OpenTelemetry em produção

OpenTelemetry é um conjunto de APIs, SDKs, convenções semânticas e componentes para coletar telemetria. O OpenTelemetry Collector recebe, processa e exporta métricas, logs e traces, mas não deve ser tratado automaticamente como o banco de dados desses sinais. Prometheus, Grafana Mimir, Loki, Tempo, Jaeger, Elasticsearch e serviços gerenciados cumprem funções diferentes de armazenamento, consulta e retenção. Essa separação muda completamente o dimensionamento do Cloud Server.

Agente, gateway e backend

No modo agente, um Collector roda perto da aplicação, normalmente como DaemonSet no Kubernetes, sidecar ou serviço instalado em cada host. Ele pode receber OTLP na porta 4317 para gRPC e 4318 para HTTP, aplicar um lote pequeno e encaminhar os dados. Um agente com 1 vCPU e 512 MB a 1 GB de RAM pode atender cargas moderadas, desde que não execute transformações pesadas nem mantenha uma fila grande.

No modo gateway, aplicações e agentes enviam a telemetria para um conjunto central de Collectors. O gateway concentra autenticação, amostragem, enriquecimento de atributos e exportação. Um exemplo prático seria um ambiente com 20 microsserviços, 500 spans por segundo e 50 mil pontos de métricas por minuto. Dois gateways com 2 vCPUs e 4 GB de RAM cada oferecem redundância inicial, mas esse número precisa ser confirmado com teste de carga e métricas internas.

Onde o Cloud Server entra

O Cloud Server pode hospedar apenas o gateway, o gateway junto de um balanceador ou toda a pilha de observabilidade. A primeira opção é mais previsível. Misturar Collector, Prometheus, Loki e Grafana em uma única máquina economiza no laboratório, porém cria competição por RAM, CPU e I/O durante incidentes, justamente quando a telemetria cresce.

Se a equipe pretende manter Prometheus e Grafana no mesmo projeto, o artigo sobre monitoramento com Grafana e Prometheus ajuda a dimensionar a camada de métricas. Para logs, a arquitetura descrita em logs centralizados com Loki mostra por que retenção e indexação precisam de planejamento próprio. Na prática, um Collector central pode usar poucos gigabytes, enquanto o backend consome centenas de gigabytes de disco.

Como dimensionar CPU, RAM e capacidade do Collector

Não existe uma relação fixa entre quantidade de serviços e tamanho do servidor. Dez APIs com amostragem agressiva podem produzir menos telemetria do que uma única aplicação que registra cada requisição, consulta SQL e corpo de erro. O cálculo deve considerar itens por segundo, tamanho médio do payload, processadores ativados, número de exportadores e comportamento nos picos.

Perfis iniciais de recursos

A tabela abaixo serve como ponto de partida para um Collector em gateway. Os valores não representam garantia de desempenho, pois SDKs, atributos, cardinalidade e latência do backend alteram o consumo.

Perfil	Carga de referência	vCPU	RAM	Disco local	Topologia sugerida
Laboratório	Até 100 itens por segundo	1	2 GB	20 GB SSD	1 Collector
Produção pequena	100 a 1.000 itens por segundo	2	4 GB	40 GB SSD	1 ou 2 Collectors
Produção intermediária	1.000 a 5.000 itens por segundo	4	8 GB	80 GB SSD	2 Collectors e balanceador
Carga elevada	Acima de 5.000 itens por segundo	8 ou mais	16 GB ou mais	Conforme fila e cache	Escala horizontal validada por teste

CPU tende a crescer com processamento. Filtros, transformações OTTL, conversões de formato, compressão e tail_sampling custam mais do que um pipeline que apenas agrupa e exporta. Por exemplo, receber OTLP, aplicar batch e enviar para um backend costuma ser mais leve do que examinar todos os spans de uma trace antes de decidir se ela será mantida.

A memória precisa comportar picos, lotes e filas. Em uma instância com 4 GB, uma configuração conservadora pode limitar o Collector a aproximadamente 3 GB, deixando espaço para sistema operacional, runtime do contêiner e agentes auxiliares. Reservar toda a RAM ao processo aumenta o risco de swap, encerramento pelo kernel ou instabilidade do host.

Como medir antes de ampliar

Faça um teste de 30 a 60 minutos com tráfego semelhante ao pico real. Observe otelcol_process_memory_rss, uso de CPU, tamanho da fila, itens recusados e falhas dos exportadores. Se a CPU permanecer acima de 70% durante vários minutos, há pouco espaço para absorver incidentes. Se a memória cresce sem retornar após os lotes serem enviados, investigue filas, backend lento e cardinalidade antes de simplesmente dobrar a máquina. Em cargas variáveis, duas instâncias menores geralmente oferecem mais resiliência do que uma instância única muito grande.

Disco, rede e retenção de métricas, logs e traces

O Collector normalmente mantém dados em memória por pouco tempo. Por isso, escolher um Cloud Server com 500 GB de NVMe não resolve gargalos causados por exportadores lentos, excesso de atributos ou CPU saturada. O disco ganha importância quando a arquitetura utiliza file_storage, filas persistentes, logs locais do serviço ou um backend instalado no mesmo host.

Quando o disco local é necessário

Uma fila persistente reduz perdas durante reinícios e indisponibilidades curtas do destino. Considere um Collector que recebe 2 MB/s e precisa tolerar 30 minutos sem acesso ao backend. O volume bruto nesse intervalo é de aproximadamente 3,6 GB. Com folga para metadados, variação do payload e recuperação, reservar entre 6 e 8 GB para a fila seria mais prudente. Se a tolerância subir para quatro horas, o requisito pode passar de 28 GB antes da margem operacional.

SSD é suficiente para muitos gateways. NVMe pode ajudar quando há escrita intensa em filas persistentes ou quando Collector e backend compartilham o host, mas a melhora precisa ser demonstrada com métricas de latência e IOPS. Para retenção longa, o correto é dimensionar o armazenamento do backend. Um Loki que ingere 20 GB de logs por dia com 14 dias de retenção já parte de 280 GB brutos, sem contar replicação, índices, compactação e espaço livre.

Calculando tráfego e retenção

A conta básica de rede é volume médio por segundo multiplicado pelo tempo. Uma ingestão de 5 MB/s representa cerca de 432 GB por dia. Se o Collector envia os mesmos dados para dois destinos, o tráfego de saída pode se aproximar de 864 GB diários, antes de compressão e retransmissões. Essa diferença torna limites de transferência e cobrança de egress fatores relevantes na escolha do provedor.

Logs costumam dominar o volume. Métricas sofrem com cardinalidade, enquanto traces crescem com taxa de requisições e quantidade de spans. Uma API com 200 requisições por segundo, 12 spans por requisição e amostragem de 10% produz aproximadamente 240 spans por segundo. Se um incidente elevar temporariamente a amostragem para 100%, a carga pode aumentar dez vezes.

Quando erros de aplicação também são enviados ao Sentry, evite duplicar anexos e payloads sensíveis em vários destinos. O planejamento apresentado em Sentry self-hosted em produção ajuda a separar rastreamento distribuído, captura de exceções e retenção de eventos. Essa divisão reduz tráfego desnecessário e facilita aplicar políticas diferentes a cada sinal.

Configuração prática do OpenTelemetry Collector

Uma configuração de produção deve limitar memória, agrupar envios, controlar tentativas e expor telemetria interna. Também precisa falhar de forma previsível. Um arquivo enorme com dezenas de processadores dificulta descobrir qual etapa está descartando dados, então comece com um pipeline pequeno e adicione transformações após medir seu custo.

Pipeline OTLP com proteção de memória

O exemplo abaixo recebe OTLP por gRPC e HTTP, limita o uso de memória, cria lotes e exporta por OTLP HTTP. A credencial vem de variável de ambiente, nunca de uma chave gravada no arquivo.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 3072
    spike_limit_mib: 512
  batch:
    send_batch_size: 1024
    timeout: 5s

exporters:
  otlphttp:
    endpoint: ${env:OTEL_EXPORTER_OTLP_ENDPOINT}
    headers:
      authorization: ${env:OTEL_EXPORTER_AUTHORIZATION}
    sending_queue:
      enabled: true
      queue_size: 5000
    retry_on_failure:
      enabled: true
      max_elapsed_time: 300s

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp]

Em um servidor com 4 GB, o limite de 3.072 MiB deixa cerca de 1 GB para o sistema. Ele ainda precisa ser ajustado se Docker, proxy reverso ou agentes de segurança estiverem no mesmo host. A fila de 5.000 itens não equivale a 5.000 eventos individuais em todas as situações, pois o tamanho depende dos lotes e do componente. Monitore seu consumo real.

Limites do serviço e execução em contêiner

Ao executar o Collector em Docker, defina limites coerentes com o memory_limiter. Um contêiner limitado a 4 GB não deve ter o processador configurado para 5 GB. Também evite expor 4317 e 4318 diretamente à internet. Use rede privada, firewall ou proxy com TLS e autenticação.

Um teste prático consiste em interromper o backend por cinco minutos, manter a carga e verificar se a fila cresce sem provocar descarte ou reinício. Depois, restaure o destino e meça o tempo de drenagem. Outro teste útil é aumentar temporariamente a taxa de traces em três vezes. O Collector deve manter memória controlada e registrar recusas de forma visível caso o limite seja alcançado.

Escalabilidade, alta disponibilidade e troubleshooting

Escalar o OpenTelemetry Collector não significa apenas clonar uma máquina. Alguns pipelines podem ser distribuídos livremente, enquanto outros exigem afinidade. Recepção OTLP, processamento batch e exportação simples funcionam bem atrás de um balanceador. Já tail_sampling precisa analisar os spans relacionados a uma trace, o que exige encaminhamento consistente ou uma camada própria para que spans da mesma trace cheguem ao mesmo grupo de processamento.

Escala horizontal sem duplicar telemetria

Para uma produção pequena, use dois Collectors em zonas ou hosts distintos e um balanceador com verificação de saúde. Aplicações enviam OTLP ao endereço virtual, e cada Collector exporta ao mesmo backend. O balanceador deve distribuir conexões sem replicar cada requisição para os dois destinos. Replicação indevida duplica métricas, logs e spans, eleva custos e pode distorcer alertas.

No Kubernetes, agentes em DaemonSet podem encaminhar dados a gateways em Deployment. Um exemplo seria três réplicas de gateway, cada uma com solicitação de 2 vCPUs e 4 GB de RAM. O autoscaling pode observar CPU, mas uma métrica de fila ou taxa de itens recebidos costuma representar melhor a pressão real. Defina um mínimo de duas réplicas para não perder redundância durante atualizações.

Sinais de saturação

A primeira pista de problema nem sempre é CPU alta. Exportadores podem falhar porque o backend está lento, DNS não responde ou o certificado expirou. A fila cresce, a memória sobe e somente depois o processo fica instável. Crie alertas para itens recusados, falhas de exportação, ocupação de fila, reinícios e latência de envio.

Se houver descarte, reduza temporariamente a taxa de amostragem, remova atributos grandes e verifique o destino. Se a CPU estiver alta sem filas, inspecione transformações, regex e tail_sampling. Se a memória oscilar violentamente, diminua lotes e confirme a ordem dos processadores. Em outro cenário comum, a rede atinge o limite enquanto CPU e RAM permanecem baixas. Nesse caso, compressão, proximidade regional e redução de duplicidade podem ajudar mais do que aumentar vCPUs.

Faça atualizações com estratégia gradual. Suba uma instância com a nova versão, direcione parte do tráfego e compare recusas, memória e latência por pelo menos um ciclo de pico. Uma troca simultânea de todos os gateways dificulta reversão e pode interromper métricas usadas para detectar o próprio problema.

Segurança, backup e operação diária

Telemetria pode conter URLs internas, nomes de clientes, identificadores, consultas de banco e trechos de erros. Um Collector é parte da superfície de segurança, não apenas um roteador neutro. O desenho deve começar com rede privada entre aplicações e gateways. Quando isso não for possível, proteja OTLP com TLS, autenticação e regras de firewall que aceitem somente origens conhecidas.

TLS, autenticação e isolamento

Evite enviar tokens como atributos de spans. A filtragem no Collector ajuda, mas o SDK da aplicação deveria remover segredos antes da transmissão. Um processador pode excluir cabeçalhos como authorization, cookie e set-cookie, enquanto regras de transformação mascaram e-mails ou identificadores. Teste essas regras com amostras controladas, pois uma expressão ampla demais pode eliminar dados necessários à investigação.

Execute o processo com usuário sem privilégios, sistema atualizado e portas administrativas restritas. O endpoint de métricas internas não precisa ficar público. Em um cenário simples, 4317 e 4318 ficam acessíveis apenas pela sub-rede das aplicações, enquanto a porta usada para métricas é liberada somente ao Prometheus. O acesso SSH deve usar chaves, bloqueio de login direto como root e limitação por firewall ou VPN.

A autenticação do exportador deve vir de secret manager, variável protegida ou arquivo montado com permissões mínimas. Não coloque chaves em imagens Docker, repositórios Git ou exemplos de documentação. Faça rotação periódica e confirme que a versão anterior deixa de funcionar.

O que realmente precisa de backup

Um Collector sem estado não precisa de backup tradicional dos lotes em memória. Preserve sua configuração versionada, arquivos de certificado, definições de serviço e automação de implantação. Se houver file_storage, a fila persistente pode ajudar na recuperação local, mas não substitui backup do backend. Restaurar uma fila antiga também pode reenviar dados e gerar duplicidade.

Teste a reconstrução em vez de confiar apenas em snapshots. Um procedimento aceitável deve criar um novo servidor, instalar a mesma versão, recuperar a configuração de um repositório privado e voltar a receber tráfego em poucos minutos. Backups de Prometheus, Loki, Tempo ou outro armazenamento exigem estratégia específica, incluindo consistência, retenção e teste de restauração. Snapshot do Cloud Server pode complementar esse processo, mas sua disponibilidade e cobrança variam por provedor e plano.

Recomendações por perfil

O melhor desenho depende do impacto de perder telemetria. Um ambiente de desenvolvimento tolera interrupções que seriam inaceitáveis em pagamentos, saúde ou operações com exigência de auditoria. As configurações abaixo são pontos iniciais, não substitutos para teste com a carga real.

Dev solo e laboratório

Para estudar instrumentação ou observar uma aplicação pequena, comece com 1 a 2 vCPUs, 2 GB de RAM e 20 a 40 GB de SSD. Um único Cloud Server pode executar Collector, Prometheus, Grafana e um backend simples de traces, desde que a retenção seja curta e o volume de logs permaneça baixo. Limite a memória de cada contêiner e mantenha pelo menos 20% do disco livre. Use amostragem de traces entre 5% e 20% se a aplicação gerar muitas requisições. Essa topologia não oferece alta disponibilidade, então não a trate como base para alertas críticos.

Time pequeno com serviços em produção

Uma equipe com 5 a 20 serviços pode iniciar com dois Collectors, cada um com 2 vCPUs e 4 GB de RAM, atrás de um balanceador. Mantenha os backends em servidores separados ou use um serviço gerenciado. Configure memory_limiter, batch, fila de envio, TLS e alertas para recusas. Se a ingestão alcançar milhares de itens por segundo ou o tail_sampling for ativado, teste 4 vCPUs e 8 GB por gateway. Faça uma simulação de backend indisponível por dez minutos para verificar memória, fila e recuperação antes de considerar o ambiente pronto.

Produção crítica e múltiplos clusters

Para várias regiões, clusters Kubernetes ou sistemas sujeitos a auditoria, use agentes locais e gateways regionais com no mínimo duas réplicas por domínio de falha. Comece os gateways com 4 vCPUs e 8 GB de RAM, mas dimensione a partir de benchmarks internos. Separe pipelines quando logs volumosos puderem prejudicar métricas e traces críticos. Controle cardinalidade, adote amostragem baseada em regras e mantenha capacidade para um pico de pelo menos duas a três vezes a média observada. Registre versões, alterações de configuração e testes de restauração. Antes de contratar o Cloud Server, confirme região, limites de rede, cobrança de tráfego, snapshots, tipo de disco e opções de balanceamento na documentação oficial do provedor.