Gerenciamento de nuvem e infraestrutura: visibilidade completa

Gerenciamento de nuvem e infraestrutura reúne servidor, contêiner, cluster Kubernetes, banco de dados, fila e rede em uma visão correlacionada. Na plataforma Dynatrace, o OneAgent descobre a stack e o Smartscape liga cada recurso à transação de negócio, o que sustenta previsão de capacidade sobre consumo medido e detecção de gargalo antes do impacto no usuário.

Descobrir qual serviço provocou o consumo de memória de um servidor, quais transações de negócio dependem dele e em quanto tempo o recurso restante se esgota exige que a camada física e a camada virtual apareçam na mesma visão correlacionada. Esse é o escopo do gerenciamento de nuvem e infraestrutura dentro de observabilidade.

Entram nessa visão sete grupos de componentes: servidor físico e máquina virtual, contêiner, cluster Kubernetes, banco de dados, fila de mensagens, rede e serviço gerenciado de nuvem. O escopo cobre nuvem pública, datacenter próprio e o arranjo híbrido entre os dois.

A distância entre essa camada e o monitoramento tradicional de recursos aparece no tipo de pergunta que cada abordagem consegue responder. Monitoramento tradicional informa que um servidor consome quase toda a memória disponível. A camada de infraestrutura em observabilidade informa qual serviço provocou esse consumo, quais transações dependem daquele serviço e em quanto tempo o recurso restante se esgota no ritmo atual. Sem correlação entre consumo de recurso e transação de negócio, a equipe de operações administra números soltos.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

O que compõe a camada de infraestrutura

Os sete grupos de componentes precisam aparecer na mesma tela porque cada um falha de um jeito próprio e produz um tipo diferente de evidência. Observados em separado, produzem sete relatórios que ninguém concilia no meio de um incidente.

O primeiro grupo reúne servidor físico e máquina virtual, conhecida pela sigla VM, base do inventário. A VM é um computador emulado por software sobre um servidor real, com processador, memória e disco delimitados. Nesse nível interessam processador, memória, disco, espera de entrada e saída e tempo de atividade contínua.

Contêiner é o segundo grupo, e muda a natureza da medição. Um contêiner empacota a aplicação com suas bibliotecas, sobe em segundos, vive pouco tempo e desaparece sem aviso. Métrica coletada por endereço de host perde sentido quando o objeto medido dura quinze minutos.

Cluster Kubernetes acrescenta a camada de orquestração sobre os contêineres. O cluster decide onde cada carga roda, reinicia o que falhou e redistribui trabalho entre nós. A observação aqui recai sobre limite de recurso por contêiner, reinício repetido, nó sob pressão de memória e trabalho pendente na fila de agendamento.

Banco de dados costuma ser o componente mais silencioso e o mais determinante. Conexões em uso, consultas lentas, bloqueio entre transações, crescimento de tabela e tempo de replicação explicam boa parte da lentidão que a aplicação exibe.

Fila de mensagens revela desequilíbrio antes de qualquer outro sinal. Quando o volume produzido supera o volume consumido, a fila acumula, e o atraso acumulado se transforma em dado desatualizado na tela do usuário.

Rede entra com latência entre serviços, perda de pacote, retransmissão e saturação de enlace. Rede lenta se disfarça de aplicação lenta, e o chamado costuma chegar ao time errado.

Serviço gerenciado de nuvem fecha a lista e traz uma restrição prática: a organização consome o serviço sem acesso ao sistema operacional que o sustenta. A observação depende das métricas expostas pelo provedor e do comportamento medido do lado de quem chama.

Por que visões separadas falham

O inventário de consoles de um parque grande cresce por herança de projeto. Cada equipe implantou o painel que resolvia o problema dela no ano em que aquele problema apareceu. O time de servidores adota um painel, o time de banco de dados adota outro, o time de nuvem usa o console do provedor e o time de aplicação instala uma ferramenta de Application Performance Monitoring, ou APM.

Cada console funciona bem no escopo dele. O problema aparece quando o incidente atravessa escopos.

O diagnóstico de parque que a Rike IS executa antes de qualquer implantação encontra sempre o mesmo padrão. O mesmo objeto aparece em três consoles, com nome diferente em cada um, e nenhum dos três registra que os outros dois medem a mesma coisa. O que falta ali é o vínculo entre os registros, e o vínculo é justamente o que nenhum console consegue produzir sozinho. Coleta sobra nesses parques.

Uma reclamação de lentidão chega ao atendimento. A equipe de operações abre o painel de servidores e encontra consumo dentro do normal. Abre o console de nuvem e encontra o serviço gerenciado respondendo. Abre o painel de banco e encontra uma consulta lenta, sem saber qual aplicação a disparou nem quantos usuários foram afetados. A correlação passa a ser feita por pessoas, em reunião, comparando horários.

Reunião de comparação de horários é o pior lugar possível para descobrir a causa raiz.

A correlação feita por pessoas consome a parte mais cara do tempo médio de resolução, ou MTTR. A causa raiz existia desde o primeiro minuto, registrada em quatro sistemas diferentes, e o que faltou foi o vínculo entre os registros.

Na plataforma Dynatrace, o Smartscape sustenta esse vínculo. O Smartscape é o mapa de dependências em tempo real da plataforma, e registra qual processo roda em qual host, qual serviço chama qual serviço, qual aplicação depende de qual banco e como esses relacionamentos mudaram ao longo do tempo. A construção vem da descoberta automática do OneAgent, o agente unificado que identifica a stack em execução sem configuração manual por componente.

Com o mapa disponível, a pergunta muda de forma. Em vez de perguntar qual servidor está lento, a equipe pergunta quais serviços dependem daquele disco saturado e quantos usuários estão no caminho de impacto. O tempo de diagnóstico deixa de depender de quem está de sobreaviso naquela madrugada.

Datacenter próprio e nuvem pública na mesma plataforma

A maior parte das organizações de grande porte opera em arranjo híbrido, com parte da carga em nuvem pública e parte em datacenter próprio. Sistemas legados que sustentam operação crítica permanecem no ambiente local por política interna de dados, por contrato de suporte ou por custo de reescrita.

O arranjo híbrido cria três problemas de medição que precisam ser resolvidos na implantação.

O primeiro é a unidade de medida. No datacenter próprio, capacidade é um ativo comprado e amortizado, medido em núcleos e em gigabytes instalados. Na nuvem pública, capacidade é consumo faturado por hora, medido em instância ativa e em volume trafegado. Comparar os dois exige normalizar a unidade antes de somar qualquer coisa.

O segundo é a cobertura da coleta. Servidores e VMs aceitam agente instalado, e o OneAgent cobre esse caso com descoberta automática da stack. Serviço gerenciado de nuvem e equipamento de rede não aceitam agente. A coleta desses objetos depende da interface de métricas do fornecedor ou de OpenTelemetry, padrão aberto e vendor-neutral da CNCF para gerar telemetria, que funciona como o padrão USB-C da telemetria.

O terceiro é o vínculo entre os dois mundos. Uma transação de negócio nasce em um aplicativo, atravessa um balanceador em nuvem, chega a um serviço em contêiner e termina em um banco de dados hospedado no datacenter próprio. Sem propagação de contexto, esse percurso vira quatro registros isolados. A propagação de contexto funciona como o carimbo no passaporte, que acompanha o viajante e permite reconstruir o trajeto inteiro depois.

A decisão de arquitetura, nesse ponto, tem três caminhos possíveis dentro do que a plataforma Dynatrace suporta. O primeiro é OneAgent em tudo que aceita agente, com o máximo de descoberta automática. O segundo é OpenTelemetry para o que não aceita agente, com convenção semântica definida antes da primeira ingestão. O terceiro é o modelo híbrido, que combina os dois e concentra a análise no mesmo repositório.

O modelo híbrido é o mais comum em ambiente misto, porque parque uniforme é exceção.

A ordem dessa implantação tem consequência prática, e a Rike IS trabalha sempre na mesma sequência. Primeiro entra o agente onde ele entra, porque cobertura rápida devolve o mapa de dependências ainda na primeira semana. Depois entra a instrumentação aberta, já com o mapa disponível para conferir se o atributo novo casa com o objeto que a plataforma Dynatrace descobriu sozinha. Invertida a ordem, a equipe define convenção de nomes sem enxergar o parque que precisa nomear, e paga o retrabalho na instrumentação.

A escolha entre agente, instrumentação aberta e modelo híbrido determina previsibilidade de custo e de prazo. Agente cobre rápido e reduz esforço de manutenção. Instrumentação aberta exige governança de atributos desde o começo, sob pena de ingestão que cresce sem retorno proporcional.

Previsão de capacidade a partir de consumo real

Previsão de capacidade é o exercício de responder quando o recurso disponível se esgota, com base no consumo medido e não em estimativa de planilha.

A prática comum trabalha ao contrário. A equipe olha o pico do mês passado, aplica uma folga arbitrária, pede o dobro do que precisa e trata o excedente como seguro. O ambiente cresce por acúmulo de folgas, e a conta cresce junto.

Observabilidade muda a base do cálculo, porque substitui a estimativa por série histórica correlacionada. Quatro dados sustentam essa mudança, na ordem em que aparecem na análise.

O primeiro dado é a distância entre alocado e consumido. Contêineres com limite de memória muito acima do uso real reservam capacidade que o cluster não pode entregar a mais ninguém, e o desperdício só aparece quando os dois números ficam lado a lado.

O segundo dado é a curva de tendência por componente. Um banco de dados que cresce em volume de tabela a cada fechamento contábil tem comportamento previsível, e a própria série projeta a data de saturação do disco.

O terceiro dado é a sazonalidade real do negócio. Folha de pagamento, período de declaração fiscal, campanha de vendas e prazo regulatório produzem picos recorrentes que a média mensal dissolve por completo.

O quarto dado é o comportamento sob pressão. Saber que o processador entrou em faixa de saturação importa menos do que saber o que aconteceu com a latência das transações naquele mesmo instante.

Os quatro dados dependem de histórico preservado com consulta rápida. Na plataforma Dynatrace, o Grail retém métricas, logs, traces e eventos em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, mantendo a consulta viável sobre todo o acervo. O Dynatrace Query Language, ou DQL, é a linguagem que interroga esse histórico quando a pergunta de capacidade aparece.

Davis, que dentro do Dynatrace Intelligence é responsável pela análise causal da plataforma Dynatrace, opera sobre essa base correlacionada e sobre o mapa de dependências. A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais. A leitura causal de Davis é o que a disciplina de Artificial Intelligence for IT Operations, ou AIOps, aplica sobre a camada de infraestrutura.

Previsão baseada em consumo real transforma o pedido de orçamento em argumento verificável. Em vez de solicitar expansão genérica, a área apresenta a data projetada de saturação, o componente responsável e a alternativa de reequilíbrio antes da compra. Em ambiente híbrido, com parte do parque faturada por hora e parte amortizada em contrato, essa medição precisa estar consistente antes da conversa de orçamento, e a Rike IS a monta na implantação e a mantém na governança de performance que vem depois.

Como detectar gargalo antes que chegue ao usuário

Indisponibilidade quase nunca começa como indisponibilidade. Ela começa como saturação de um recurso específico, que degrada devagar até cruzar o ponto em que a aplicação deixa de responder. Existe janela entre o primeiro sinal e a percepção do usuário.

Aproveitar essa janela depende de observar quatro sinais precoces, cada um em uma parte diferente da camada de infraestrutura. Nenhum deles aparece no indicador de disponibilidade, porque nesse momento o sistema ainda responde.

O primeiro sinal é fila de espera de disco. Quando as operações de leitura e escrita passam a aguardar, o tempo adicional se propaga para cada consulta que toca aquele volume, e a aplicação fica lenta sem que o processador registre anomalia.

O segundo sinal é esgotamento de pool de conexões. Um banco de dados que responde mais devagar mantém conexões ocupadas por mais tempo, o pool satura, e requisições novas passam a aguardar conexão livre em vez de aguardar o banco.

O terceiro sinal é limitação de processador em contêiner. O cluster Kubernetes restringe o contêiner que ultrapassa o limite configurado, o contêiner passa a esperar ciclos de processamento, e a latência sobe enquanto o painel de host continua verde.

O quarto sinal é atraso acumulado em fila de mensagens. Consumidor mais lento que produtor gera acúmulo crescente, e o usuário recebe informação correta em relação ao processamento e desatualizada em relação ao mundo real.

Os quatro sinais compartilham o mesmo padrão de origem. A saturação nasce em um componente de infraestrutura e se manifesta como problema de aplicação, longe do ponto onde a equipe poderia corrigi-la.

Quem não observa os quatro sinais recebe o aviso pela disciplina de Digital Experience Monitoring, ou DEM, já com a lentidão sentida pela pessoa do outro lado da tela. O aviso chega correto e chega tarde.

A detecção automática depende de linha de base aprendida por componente, e não de limite fixo digitado por um analista. Um servidor de processamento noturno que sobe o consumo na madrugada opera dentro do esperado, e o mesmo consumo no meio do expediente indica anomalia. Limite fixo dispara alerta nos dois casos e ensina a equipe a ignorar o alerta.

O que muda para cada time e por onde começar

A mesma camada de infraestrutura observada produz quatro efeitos distintos dentro da organização, e cada efeito justifica o investimento por um caminho próprio.

Para o CIO, o CTO e o CEO, o efeito é previsibilidade. Data projetada de saturação, custo de capacidade por ambiente e histórico de indisponibilidade em sistemas críticos sustentam decisão de investimento sem depender de percepção de área técnica.

Para o gerente de infraestrutura, o efeito é controle. Alocado contra consumido, tendência por componente e sazonalidade medida convertem o ciclo de expansão em decisão baseada em série histórica, com espaço para reequilibrar antes de comprar.

Para o profissional de DevOps, o efeito é feedback rápido sobre cada entrega. A regressão de consumo introduzida por uma versão nova aparece enquanto a reversão ainda é operação simples de esteira, não operação de emergência.

Para o Site Reliability Engineer, ou SRE, profissional responsável pela confiabilidade em produção, o efeito é redução do tempo médio de resolução. A equipe deixa de reconstruir em reunião o caminho que vai do sintoma na aplicação ao componente de infraestrutura saturado, e passa a ler esse caminho no mapa de dependências.

Uma implantação dessa camada avança em três decisões, tomadas nesta ordem.

A primeira decisão é o inventário real do parque. Quantos hosts, quantas VMs, quantos clusters, quais bancos, quais filas, quais serviços gerenciados de nuvem e quais equipamentos de rede entram no escopo, com dono nomeado para cada grupo.

A segunda decisão é a estratégia de coleta por tipo de objeto. OneAgent onde o agente entra, OpenTelemetry onde não entra, modelo híbrido no parque misto. A convenção de nomes precisa estar definida antes da primeira ingestão, porque nome inconsistente fragmenta painel e enfraquece a análise causal.

A terceira decisão é o critério de alerta. Linha de base aprendida por componente, alerta ligado a impacto de negócio e não a limite isolado de recurso, e revisão periódica do que gerou ruído sem gerar ação.

Essas três decisões separam a implantação que sustenta governança de performance daquela que apenas troca um painel por outro.

Perguntas frequentes

Gerenciamento de nuvem e infraestrutura é a mesma coisa que observabilidade em cloud?

São recortes diferentes. Observabilidade em cloud trata do que o modelo de nuvem esconde de quem consome serviço gerenciado, sem acesso ao que roda por baixo. Gerenciamento de nuvem e infraestrutura trata da camada inteira, com datacenter próprio e nuvem pública lado a lado. Quem opera parque só em nuvem pode ficar no primeiro recorte. Quem opera parque misto precisa do segundo.

Preciso desligar o console do provedor de nuvem depois de implantar observabilidade?

Não. O console do provedor continua sendo a fonte de faturamento, de cota de serviço e de aviso de manutenção programada, e nenhuma plataforma de observabilidade substitui esse papel contratual. O que sai de cena é o uso do console como ferramenta de diagnóstico de incidente. A regra prática é manter o console para administrar o contrato e usar a plataforma Dynatrace para investigar comportamento.

O que fazer com equipamento que não aceita agente nem exporta métrica?

Equipamento fechado, sem agente e sem interface de métricas, entra na observabilidade pelo comportamento medido de quem depende dele. A latência dos serviços que atravessam aquele equipamento vira o indicador indireto de saúde. A alternativa é tratar o objeto como caixa preta declarada no inventário, com dono nomeado e com o risco registrado, em vez de deixar o ponto cego sem responsável.

Quanto histórico é preciso ter antes de confiar em uma previsão de capacidade?

A série precisa cobrir pelo menos um ciclo completo de sazonalidade do negócio, com o pico recorrente daquele calendário dentro da amostra. Previsão feita sobre um período que nunca viu fechamento contábil, campanha de vendas ou prazo fiscal projeta um ambiente que não existe. Antes desse ciclo fechar, a série serve para detectar tendência de crescimento, e ainda não serve para datar a saturação.

Quando o problema de lentidão não está na camada de infraestrutura?

Quando os recursos permanecem na faixa normal aprendida e nenhuma fila acumula, o gargalo sai da camada de infraestrutura. Nesses casos, o código da aplicação, uma chamada externa a terceiro ou a rede do próprio usuário explicam a lentidão. A camada de infraestrutura responde a pergunta sobre recurso, e a investigação segue para a aplicação e para a experiência do usuário quando o recurso está descartado.

Observar a camada de infraestrutura inteira, com nuvem pública, datacenter próprio e o vínculo entre os dois, exige diagnóstico do parque, estratégia de coleta por tipo de objeto e operação continuada depois da entrega. A Rike IS conduz esse trabalho com consultoria, implantação, treinamento e governança de performance sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o inventário do seu parque para uma conversa com a equipe da Rike IS antes do próximo ciclo de expansão.