O uso de OCI Container Instances (CI) é uma alternativa eficiente para rodar workloads containerizadas sem a complexidade operacional do gerenciamento de um cluster Kubernetes. Contudo, conforme essas aplicações evoluem de estágios de desenvolvimento para ambientes de produção, a observabilidade torna-se o principal desafio. A centralização de logs e métricas não é apenas um requisito de troubleshooting, mas um pilar crítico para a sustentabilidade da operação.
Para times de engenharia, a escolha entre utilizar o padrão sidecar ou a instrumentação direta via SDK exige uma análise técnica cuidadosa, ponderando sobre o custo de refatoração, a complexidade do pipeline de deployment e a conformidade com as políticas de governança e segurança da empresa.
Visão Geral das Soluções
O padrão sidecar collector utiliza contêineres auxiliares dedicados que monitoram arquivos de logs e métricas, encaminhando-os para o OCI Logging e OCI Monitoring.
- Prós: Desacoplamento total entre aplicação e lógica de observabilidade. Permite atualizações no stack de monitoramento sem precisar redeployar ou recompilar a aplicação.
- Contras: Aumento do footprint de recursos computacionais devido aos contêineres adicionais.
Por outro lado, o envio direto via OCI SDK elimina o sidecar, tornando a aplicação responsável por emitir os dados diretamente via APIs REST ou SDK.
- Prós: Arquitetura mais enxuta, menor overhead em runtime e integração nativa com o ecossistema OCI.
- Contras: Exige alteração no código-fonte, instrumentação específica por linguagem e responsabilidade integral por retries e backoff.
Abordagem 1: O Padrão Sidecar
Este modelo exige foco rigoroso na configuração da rede, IAM e políticas de permissão. Recomenda-se o uso de Terraform para provisionar não apenas o contêiner, mas também a infraestrutura de suporte, como VCNs, log groups e dynamic groups.
Pontos de atenção:
- IAM: Certifique-se de que os dynamic groups possuam o mínimo privilégio necessário via resource principals para evitar exposição de credenciais estáticas.
- Rotatividade: O sidecar deve ser capaz de lidar com a rotação de arquivos feita pela aplicação para não perder logs durante o processamento.
- Network: Em ambientes, garanta que egress rules permitam o tráfego para os endpoints de ingestão do OCI sem comprometer o isolamento da rede.
Abordagem 2: Instrumentação via OCI SDK
Quando a prioridade é a redução da complexidade operacional, a integração direta via SDK é mais indicada. O segredo aqui reside na qualidade da implementação do batching.
Exemplo de lógica em Java para métricas:
Datapoint point = Datapoint.builder().timestamp(now).value(123.4).count(1).build();
// ... configuração do monitoramento
Para empresas brasileiras, o uso desta abordagem deve considerar a latência e a resiliência. Implementar mecanismos de retry com exponential backoff é obrigatório para evitar falhas de visibilidade em períodos de alta carga ou instabilidades momentâneas no tráfego de rede.
Considerações Finais: Segurança e Compliance
Independente da escolha, a observabilidade não pode ser um vetor de vazamento de dados.
- Segurança: Utilize OCI Vault para gerenciar quaisquer segredos necessários.
- Governança: Mascare PII (Personally Identifiable Information) antes de enviar logs para o OCI Logging.
- Conformidade: Se houver necessidade de enviar dados para backends externos (ex: Grafana ou ELK), garanta que o tráfego esteja criptografado e em conformidade com as diretrizes internas de privacidade da sua empresa.
Artigo originalmente publicado por Kevin Liu, Harshit Patel e Haonan Zhang em cloud-infrastructure.
