Observabilidade na hospedagem: Por que razão a monitorização, por si só, já não é suficiente

Distinguir claramente entre monitorização e observabilidade

Monitorização responde, sobretudo, a questões operacionais já conhecidas. Verifica, por exemplo, se um site está acessível, se um certificado TLS está prestes a expirar, se o espaço de armazenamento está a esgotar-se ou se a percentagem de respostas HTTP 5xx excede um valor definido. Essas verificações proporcionam fiabilidade no dia a dia, pois transformam desvios esperados em alertas concretos.

A observabilidade não substitui estes controlos, mas complementa-os em casos de erros não identificados. Se a página inicial responder com um código HTTP 200, mas alguns processos de checkout demorarem um tempo suspeitamente longo, a questão decisiva não é apenas saber se o serviço está a funcionar. O que importa é saber o que aconteceu exatamente ao longo dessa solicitação, qual o componente que demorou mais tempo e qual o contexto que explica esse desvio.

A diferença é, portanto, prática e não conceptual: um alarme relativo ao aumento das taxas de erro revela um sintoma relevante para o utilizador. No entanto, a análise subsequente requer frequentemente mais contexto do que uma única curva pode fornecer. Boas Observabilidade Por isso, associa sinais, em vez de considerar precipitadamente um valor de medição isolado como a causa.

Os três níveis de telemetria no alojamento

Na hospedagem, surgem sinais relevantes em três níveis. A infraestrutura inclui a CPU, a memória RAM, os dispositivos de armazenamento, a rede, bem como os recursos das máquinas virtuais (VMs) ou dos contentores. Acima disso, encontra-se a camada de tráfego, com ligações, tempos de resposta, códigos de estado, TLS e o comportamento do proxy inverso ou do servidor web. O terceiro nível é constituído pela aplicação e pelas suas dependências: por exemplo, PHP, base de dados, cache, fila ou um serviço de pagamentos externo.

Valores de host discretos não são sinónimo de uma boa experiência do utilizador. Uma consulta à base de dados, um armazenamento de sessões que bloqueia ou uma chamada à API lenta podem atrasar páginas específicas, mesmo que a CPU e a RAM apresentem reservas suficientes. Por outro lado, uma elevada utilização da CPU durante uma campanha não constitui automaticamente uma falha, desde que os pedidos sejam processados com sucesso e rapidez, dentro dos limites esperados.

A camada de tráfego liga ambas as perspetivas. No NGINX, o tempo de pedido documentado abrange o processamento desde a receção do primeiro byte do pedido até ao envio do último byte da resposta. Se este valor aumentar, isso não significa necessariamente que se saiba se a responsabilidade recai sobre o servidor web, a aplicação ou o upstream. No entanto, indica de forma útil quais os pedidos e períodos que devem ser analisados com mais detalhe.

Do ponto de vista da organização operacional, isto implica uma separação de funções. Alarmes baseados nos sintomas centra-se na disponibilidade, na taxa de erros ou na latência percetível e alerta quando é necessário intervir. Por outro lado, as métricas de recursos, os tempos de upstream e as filas internas apoiam o diagnóstico em painéis de controlo ou na resolução de problemas. O Prometheus recomenda esta separação para que as equipas de disponibilidade não sejam sobrecarregadas com meros indicadores de causa.

Ligar métricas, registos e rastreios

Ao analisar um único pedido HTTP, os três sinais de telemetria oferecem diferentes perspetivas. Métricas agregam muitos processos em padrões baseados no tempo, como a latência, o tráfego ou a taxa de erros. Os registos registam eventos individuais, como, por exemplo, um tempo limite esgotado acompanhado de uma mensagem de erro. Os traços, por outro lado, mapeiam o percurso dessa solicitação específica através do servidor Web, da aplicação, da cache, da base de dados e dos serviços externos.

Um trace é composto por spans. Cada span representa uma etapa de trabalho, como a execução do controlador, o acesso à cache, uma operação SQL ou uma chamada de API de saída, e contém dados temporais, bem como atributos de classificação. Um identificador de rastreio liga as etapas da solicitação global; um identificador de span distingue a respetiva suboperação. Isto permite identificar onde ocorreu o consumo de tempo, sem ter de deduzir uma causa a partir de uma única métrica.

Os registos tornam-se particularmente reveladores quando estão estruturados e incluem o contexto do trace e do span. Nesse caso, uma equipa pode passar diretamente de um trace lento para mensagens de erro, indicações de nova tentativa ou eventos de tempo limite da mesma solicitação. O contexto ativo pode enriquecer os registos existentes; no entanto, antes da sua utilização, é necessário verificar quais os campos que o ambiente de execução concreto exporta efetivamente.

Um percurso típico de telemetria é o seguinte: a aplicação, o servidor Web e a infraestrutura geram dados; um coletor ou agente recebe-os, filtra-os ou enriquece-os; um backend armazena-os e visualiza-os. A partir de um alarme, a análise passa por uma métrica, conduzindo ao trace e ao log. O OpenTelemetry oferece uma estrutura aberta para este fim, mas o grau de maturidade varia: Rastreio- A especificação, a API, o SDK e o protocolo são considerados estáveis, enquanto os SDKs de métricas podem apresentar diferentes níveis de desenvolvimento consoante a linguagem.

Reduzir sistematicamente os tempos de checkout demorados

Uma verificação de disponibilidade bem-sucedida e uma página inicial com código de estado HTTP 200 apenas comprovam que esse caminho verificado está a responder neste momento. Não excluem a possibilidade de que alguns carrinhos de compras, verificações de morada ou autorizações de pagamento sejam lentos ou falhem. Por isso, para uma loja online, a latência observada no processo de checkout, juntamente com a taxa de erros, constitui um ponto de partida útil para a análise.

Em primeiro lugar, as séries temporais revelam se o problema se concentra num determinado período, num percurso ou numa classe de estado. Se, por exemplo, a latência das solicitações de checkout aumentar e se seguirem erros isolados, surge um Traço Interessante: os seus «Spans» dividem a duração total em etapas de trabalho, tais como aplicação, cache, base de dados e chamada externa. Assim, um «Trace» descreve o percurso de uma consulta concreta, mas não indica automaticamente a sua causa comprovada.

Se, por exemplo, se destacar uma chamada demorada a um serviço de pagamento, os registos estruturados correlacionados fornecem mais informações. Os identificadores de rastreio e de intervalo permitem procurar mensagens de tempo limite, tentativas de repetição ou detalhes de erros correspondentes à mesma solicitação. Os registos estruturados facilitam esta atribuição automática, desde que o contexto ativo seja efetivamente incluído nos dados de registo exportados.

A tabela descreve correlações, não uma prova de causalidade. Um intervalo de pagamento lento pode, por exemplo, ser causado pelo fornecedor, por uma falha na rede, por uma ligação esgotada ou pelo comportamento de repetição de tentativas da própria aplicação. Por isso, as dependências externas, em particular, devem ser avaliadas em conjunto com o estado, o intervalo de tempo, o texto do erro e o tratamento na aplicação.

Configurar corretamente o contexto para as consultas

Uma configuração mínima adequada não começa com o maior número possível de campos, mas sim com informações fiáveis para a classificação. Entre estes incluem-se o nome do serviço, o ambiente e a versão de implementação, bem como o método HTTP e a classe de estado. Estes atributos permitem identificar se uma degradação afeta apenas a produção, uma versão específica ou um único serviço; devem ser utilizados de forma consistente em métricas, registos e rastreios.

O contexto da solicitação tem de percorrer o caminho desde o proxy até à aplicação e, a partir daí, até à base de dados, à cache ou a serviços externos. Se esta transmissão ainda não existir na combinação utilizada de proxy, ambiente de execução e framework, é necessária instrumentação adicional. Um rastreio visível na entrada da aplicação não prova, portanto, que cada chamada a montante ou cada registo possa ser automaticamente atribuído.

Após uma atualização de um plugin ou tema, um site WordPress pode passar a responder mais lentamente, embora os recursos do servidor de alojamento não apresentem, à primeira vista, qualquer anomalia. Nesse caso, é possível comparar os dados do servidor web relativos à duração dos pedidos e aos códigos de estado com os dados da aplicação relacionados com o PHP e os tempos da base de dados. No NGINX, o tempo de pedido documentado abrange o processamento desde a leitura do primeiro byte do pedido até ao envio do último byte da resposta; por si só, este valor ainda não identifica o ponto de estrangulamento.

Na prática, isto traduz-se numa cadeia verificável: será que o tempo de resposta apenas se alterou após a nova versão de implementação, será que determinados percursos apresentam um tempo de execução mais longo, ou será que é apenas a duração das operações individuais da base de dados que está a aumentar? Quem pretender, além disso, compreender os limites estruturais de carga e escalabilidade de um CMS, pode consultar o artigo sobre Limites de escala do WordPress. A telemetria não substitui essa avaliação técnica, mas fornece os elementos concretos para a mesma.

É igualmente importante ter em conta os limites da normalização: o OpenTelemetry considera a especificação de rastreamento, a API, o SDK e o protocolo como estáveis, enquanto o grau de maturidade dos SDKs de métricas pode variar consoante a linguagem de programação. Por isso, antes de uma implementação, a equipa deve verificar, para a sua própria linguagem e biblioteca, quais os sinais, atributos e informações de contexto que estão efetivamente disponíveis.

Avaliar os objetivos de latência e os tempos de resposta da base de dados

Os indicadores de serviço devem refletir uma característica percetível, como, por exemplo, pedidos de checkout bem-sucedidos num período de tempo definido ou a percentagem de respostas com erros. A partir daí, é possível definir uma meta de serviço. Assim, uma elevada utilização da CPU continua a ser um valor de diagnóstico importante, mas não desencadeia necessariamente uma escalada se os objetivos dos utilizadores continuarem a ser cumpridos.

Um valor médio pode ocultar consultas curtas e muito lentas. Um percentil responde a outra questão: o p95 refere-se ao valor abaixo do qual se situam 95 por cento dos valores observados. Não se trata nem da experiência média do utilizador nem de uma prova de que todas as restantes consultas tenham sido aceitáveis. A taxa de erro, o tráfego e o intervalo de tempo considerado fazem parte da análise.

No caso de latências agregadas ao longo de várias instâncias, são Histogramas Muitas vezes é conveniente: os buckets podem ser agregados e, a partir deles, é possível calcular quantis de forma aproximada. Por outro lado, os quantis calculados previamente a partir de resumos de várias réplicas não devem ser calculados como média, pois isso não resulta num quantil global estatisticamente significativo.

Um objetivo meramente ilustrativo poderia ser: 95 por cento das solicitações de checkout bem-sucedidas devem demorar menos de 300 milissegundos. Daí não decorre qualquer garantia de desempenho nem um valor-limite adequado para cada loja. Apenas ilustra a lógica do raciocínio: se a meta não for atingida, os traços ajudam a distribuir o tempo; os spans da base de dados podem, posteriormente, distinguir classes de consultas suspeitas da carga geral.

Para tal, não é necessário que a base de dados esteja em falha. Uma verificação de integridade bem-sucedida e valores normais da CPU não excluem a possibilidade de que algumas consultas lentas dominem um caminho crítico. Só a combinação entre a distribuição da latência, as percentagens de tempo de rastreio e o contexto de erros ou tempos de espera revela se vale a pena investigar mais a fundo um valor atípico local, um padrão crescente ou outro elemento no percurso da consulta.

Integrar os sistemas de alarme e de deteção de avarias

As regras de alarme devem, em primeiro lugar, detetar o que os utilizadores realmente notam: serviços inacessíveis, aumento das taxas de erros 5xx ou um tempo de resposta excessivamente elevado de forma prolongada. Tais alarmes orientados para os sintomas constituem um motivo claro para agir. A utilização da CPU, as filas, a capacidade disponível do sistema de ficheiros ou os tempos de upstream continuam a ser importantes, mas, muitas vezes, são mais adequados para o diagnóstico do que como único fator desencadeador de uma ação.

Assim, quando se verifica uma acumulação de respostas 502 ou 504, a investigação começa por analisar a dimensão e o momento: que percursos, hosts, regiões ou versões de implementação estão afetados? O código de estado indica apenas que a comunicação falhou numa fase do processamento ou demorou demasiado tempo. Não prova que o proxy inverso esteja a funcionar incorretamente, nem que a aplicação ou um determinado upstream seja a causa.

Na etapa seguinte, os dados do proxy, tais como a duração do pedido, a duração do upstream, a classe de estado e o número de ligações ativas, ajudam a delimitar temporalmente a ocorrência do erro. O NGINX, por exemplo, documenta o tempo da solicitação como o intervalo entre a leitura do primeiro byte da solicitação e o envio do último byte da resposta. Trata-se de uma visão útil da duração total, mas, sem dados adicionais, não permite distinguir as partes relativas à aplicação, à rede e às dependências.

Posteriormente, um trace em questão conduz desde a receção do pedido até à aplicação, à cache, à base de dados ou a um serviço externo. Os registos de aplicação estruturados, com contexto de rastreio e de intervalo, podem revelar, nesse contexto, tempos de espera, interrupções de ligação ou tentativas de repetição. Esta ligação só é possível se o contexto for transmitido através dos componentes envolvidos e se o enriquecimento dos registos tiver sido efetivamente configurado.

Para a operação, isto traduz-se num procedimento fiável: confirmar o alarme com base no sintoma, delimitar as solicitações afetadas e o intervalo de tempo, comparar os valores do proxy e dos recursos, analisar um trace representativo e, por fim, aceder aos registos correspondentes. Sinais relacionados com a causa agilizam a pesquisa, mas não substituem a verificação de alterações, dependências e mensagens de erro. A correlação mostra quais observações ocorrem em simultâneo; não constitui, por si só, uma prova de causalidade.

Uma elevada carga no servidor durante uma campanha pode ser normal, enquanto um único acesso lento à base de dados, mesmo com a CPU a funcionar normalmente, pode prejudicar o processo de checkout. Por isso, os painéis de controlo devem apresentar tanto o objetivo do utilizador como a cadeia de diagnóstico. Desta forma, a monitorização fica responsável pelas variações previsíveis, enquanto a telemetria correlacionada apoia a investigação de um cenário de erro específico.

Gerir o volume de dados, a proteção de dados e a cardinalidade

Com o aumento do tráfego, raramente faz sentido guardar permanentemente cada pedido como um registo completo. Amostragem limita o volume de dados e os custos, sem abdicar totalmente da análise. A seleção deve estar de acordo com o risco: erros, transações invulgarmente lentas e percursos críticos de consultas são, na maioria das vezes, mais valiosos do que um conjunto aleatório e homogéneo de traços pouco significativos.

Na amostragem de cauda (Tail Sampling), a decisão só é tomada quando um traço está completo ou quase completo. Isto permite, por exemplo, dar prioridade a traços com estado de erro ou de longa duração. Como para tal são necessários o estado e o buffer, o componente de telemetria deve ter dimensões suficientes; uma sobrecarga pode levar à rejeição de dados e à falta precisamente dos traços relevantes.

O coletor, o agente e a rota de exportação devem, por isso, ser incluídos na monitorização. São determinantes, por exemplo, os erros de receção e de exportação, as filas de espera, os atrasos e os dados rejeitados. Se estes sinais falharem ou se a perda de dados aumentar, um painel vazio não deve ser considerado prova de que o serviço está a funcionar corretamente. O pipeline de telemetria é uma dependência operacional e necessita de limites bem definidos.

A minimização de dados começa antes da exportação: selecionar atributos de forma seletiva, verificar regularmente os dados introduzidos e remover valores sensíveis através de filtros, expurgação ou etapas de transformação. Em particular, os cabeçalhos, os cookies, os corpos completos e os identificadores merecem uma verificação explícita de autorização. Mesmo campos aparentemente técnicos podem conter dados pessoais ou confidenciais.

No que diz respeito às métricas, é importante ter em conta também a cardinalidade Fundamental: cada nova combinação de valores de etiqueta gera mais uma série temporal. Por conseguinte, os identificadores de utilizador, de sessão ou de encomenda não são rótulos adequados. O Prometheus recomenda que, caso existam cerca de 100 valores possíveis ou se estes estejam a crescer rapidamente, se considere a adoção de um modelo de dados diferente. Para casos específicos, são mais adequados os traços ou os registos estruturados com um período de retenção limitado.

Implementar a observabilidade de forma adequada e gradual

A abordagem adequada depende da arquitetura e do risco, e não do maior conjunto possível de funcionalidades. Um pequeno site estático beneficia principalmente de verificações de acessibilidade, monitorização da validade do TLS, estados HTTP e recursos básicos. O rastreio completo da aplicação acaba muitas vezes por representar um esforço adicional sem proporcionar os conhecimentos correspondentes.

Num CMS ou numa loja online, a visão básica é geralmente seguida pela correlação entre o servidor web, a aplicação e a base de dados. Só quando vários serviços ou contentores interagem é que a transmissão consistente do contexto se torna particularmente importante para os percursos críticos. A AWS recomenda que a observabilidade seja considerada em toda a aplicação e nas suas dependências, e que os indicadores técnicos sejam associados aos objetivos empresariais e dos utilizadores.

Os serviços CDN, DNS, de pagamento, de envio ou de e-mail fazem parte do percurso real da solicitação, mas a sua capacidade de controlo é limitada. Os próprios «spans» e os indicadores de latência ou de erros podem revelar quando houve uma dependência envolvida. Isso não implica uma atribuição automática de culpa: as condições da rede, as tentativas de repetição, a configuração do tempo limite e o estado do serviço devem ser avaliados em conjunto. Para questões de disponibilidade e encaminhamento, o artigo sobre Estratégias de multi-CDN na hospedagem a análise no que diz respeito aos aspetos de seleção e failover.

Uma implementação pragmática define, numa primeira fase, alguns objetivos orientados para o utilizador e os sinais correspondentes. Em seguida, os campos de dados, o período de conservação e os direitos de acesso são limitados, antes de se introduzir gradualmente o rastreio para os processos críticos para o negócio. A amostragem não constitui, neste contexto, uma lacuna, mas sim uma decisão controlada, desde que os casos de erro e de latência sejam mantidos de forma seletiva e que o processo de seleção seja gerido de forma transparente.

A observabilidade não substitui uma arquitetura robusta, nem os testes, as cópias de segurança ou um processo de gestão de incidentes. Ela proporciona contexto propício à tomada de decisões Para estas tarefas: as equipas conseguem identificar melhor quais os percursos dos utilizadores que são afetados, quais os componentes que devem ser analisados e quais as hipóteses que são corroboradas pelos dados. O benefício aumenta com perguntas claras e telemetria cuidadosamente delimitada, e não com uma recolha tão vasta quanto possível de dados brutos.