De terabytes a insights: arquitetura de observabilidade de IA no mundo real

Considere manter e desenvolver uma plataforma de e-commerce que processe milhões de transações a cada minuto, gerando grandes volumes de dados de telemetria, incluindo métricas, logs e rastreamentos em múltiplos microsserviços. Quando ocorrem incidentes críticos, os engenheiros de plantão enfrentam a árdua tarefa de vasculhar um oceano de dados para desvendar sinais e insights relevantes. Isso equivale a procurar uma agulha no palheiro.

Isso torna a observabilidade uma fonte de frustração em vez de insights. Para aliviar esse grande problema, comecei a explorar uma solução para utilizar o Protocolo de Contexto do Modelo (MCP) para adicionar contexto e extrair inferências dos logs e rastros distribuídos. Neste artigo, descreverei minha experiência na construção de uma plataforma de observabilidade com tecnologia de IA, explicarei a arquitetura do sistema e compartilharei insights práticos aprendidos ao longo do caminho.

Em sistemas de software modernos, a observabilidade não é um luxo; é uma necessidade básica. A capacidade de mensurar e compreender o comportamento do sistema é fundamental para a confiabilidade, o desempenho e a confiança do usuário. Como diz o ditado, "O que você não pode medir, não pode melhorar".

No entanto, alcançar a observabilidade nas arquiteturas nativas da nuvem e baseadas em microsserviços atuais é mais difícil do que nunca. Uma única solicitação de usuário pode percorrer dezenas de microsserviços, cada um emitindo logs, métricas e rastros. O resultado é uma abundância de dados de telemetria:

• Dezenas de terabytes de logs por dia
• Dezenas de milhões de pontos de dados métricos e pré-agregados
• Milhões de rastros distribuídos
• Milhares de IDs de correlação gerados a cada minuto

O desafio não é apenas o volume de dados, mas a fragmentação dos dados. De acordo com o Relatório de Previsão de Observabilidade de 2023 da New Relic , 50% das organizações relatam dados de telemetria isolados, com apenas 33% alcançando uma visão unificada de métricas, registros e rastros.

Os registros contam uma parte da história, as métricas outra, os rastros ainda outra. Sem um fio condutor consistente de contexto, os engenheiros são forçados a recorrer à correlação manual, confiando na intuição, no conhecimento tribal e no tedioso trabalho de detetive durante os incidentes.

Devido a essa complexidade, comecei a me perguntar: como a IA pode nos ajudar a superar dados fragmentados e oferecer insights abrangentes e úteis? Especificamente, podemos tornar os dados de telemetria intrinsecamente mais significativos e acessíveis para humanos e máquinas usando um protocolo estruturado como o MCP ? A base deste projeto foi moldada por essa questão central.

A Anthropic define o MCP como um padrão aberto que permite aos desenvolvedores criar uma conexão bidirecional segura entre fontes de dados e ferramentas de IA. Este pipeline de dados estruturados inclui:

• ETL contextual para IA: padronizando a extração de contexto de múltiplas fontes de dados.
• Interface de consulta estruturada: permite que consultas de IA acessem camadas de dados transparentes e facilmente compreensíveis.
• Enriquecimento de dados semânticos: incorpora contexto significativo diretamente em sinais de telemetria.

Isso tem o potencial de mudar a observabilidade da plataforma, afastando-a da resolução reativa de problemas e aproximando-a de insights proativos.

Antes de nos aprofundarmos nos detalhes da implementação, vamos analisar a arquitetura do sistema.

Na primeira camada, desenvolvemos os dados de telemetria contextual incorporando metadados padronizados aos sinais de telemetria, como rastros distribuídos, logs e métricas. Em seguida, na segunda camada, os dados enriquecidos são alimentados no servidor MCP para indexar, adicionar estrutura e fornecer acesso do cliente aos dados enriquecidos por contexto usando APIs. Por fim, o mecanismo de análise orientado por IA utiliza os dados de telemetria estruturados e enriquecidos para detecção de anomalias, correlação e análise de causa raiz para solucionar problemas de aplicação.

Esse design em camadas garante que as equipes de IA e engenharia recebam insights práticos e baseados em contexto a partir de dados de telemetria.

Vamos explorar a implementação real da nossa plataforma de observabilidade baseada em MCP, com foco nos fluxos de dados e transformações em cada etapa.

Camada 1: Geração de dados enriquecida por contexto

Primeiro, precisamos garantir que nossos dados de telemetria contenham contexto suficiente para uma análise significativa. A ideia central é que a correlação de dados precisa ocorrer no momento da criação, não no momento da análise.

def process_checkout(user_id, cart_items, payment_method): “””Simule um processo de checkout com telemetria enriquecida por contexto.””” # Gerar id de correlação id_do_pedido = f”pedido-{uuid.uuid4().hex[:8]}” id_do_pedido = f”req-{uuid.uuid4().hex[:8]}” # Inicializar dicionário de contexto que será aplicado contexto = { “id_usuário”: id_usuário, “id_pedido”: id_pedido, “id_solicitação”: id_solicitação, “contagem_de_itens_do_carrinho”: len(itens_do_carrinho), “método_pagamento”: método_pagamento, “nome_serviço”: “finalizar compra”, “versão_serviço”: “v1.0.0” } # Iniciar rastreamento OTel com o mesmo contexto com tracer.start_as_current_span(“process_checkout”, atributos={k: str(v) para k, v em context.items()} ) como checkout_span: # Registro usando o mesmo contexto logger.info(f”Iniciando processo de checkout”, extra={“contexto”: json.dumps(contexto)}) # Propagação de Contexto com tracer.start_as_current_span(“process_payment”): # Lógica de pagamento do processo… logger.info(“Pagamento processado”, extra={“contexto”: json.dumps(contexto)})

Código 1. Enriquecimento de contexto para logs e rastros

Essa abordagem garante que cada sinal de telemetria (registros, métricas, rastros) contenha os mesmos dados contextuais principais, resolvendo o problema de correlação na fonte.

Em seguida, criei um servidor MCP que transforma telemetria bruta em uma API consultável. As principais operações de dados aqui envolvem o seguinte:

1. Indexação : Criando pesquisas eficientes em campos contextuais
2. Filtragem : Seleção de subconjuntos relevantes de dados de telemetria
3. Agregação : Computação de medidas estatísticas em janelas de tempo

@app.post(“/mcp/logs”, response_model=List[Log])def query_logs(query: LogQuery): “””Consultar logs com filtros específicos””” results = LOG_DB.copy() # Aplicar filtros contextuais se query.request_id: resultados = [log para resultados de login se log[“contexto”].get(“request_id”) == query.request_id] se query.user_id: resultados = [log para resultados de login se log[“contexto”].get(“user_id”) == query.user_id] # Aplicar filtros baseados em tempo se query.time_range: hora_de_início = datetime.fromisoformat(query.time_range[“início”]) hora_de_fim = datetime.fromisoformat(query.time_range[“fim”]) resultados = [log para resultados de login se hora_de_início <= datetime.fromisoformat(log[“carimbo_de_data_final”]) <= hora_de_fim] # Organizar por carimbo de data/hora resultados = classificados(resultados, chave=lambda x: x[“timestamp”], reverso=Verdadeiro) retornar resultados[:query.limit] se query.limit senão resultados

Código 2. Transformação de dados usando o servidor MCP

Essa camada transforma nossa telemetria de um data lake não estruturado em uma interface estruturada e otimizada para consultas, na qual um sistema de IA pode navegar com eficiência.

A camada final é um componente de IA que consome dados por meio da interface MCP, realizando:

1. Análise multidimensional : correlação de sinais em logs, métricas e rastros.
2. Detecção de anomalias : Identificação de desvios estatísticos de padrões normais.
3. Determinação da causa raiz : uso de pistas contextuais para isolar prováveis fontes de problemas.

def analyze_incident(self, request_id=None, user_id=None, timeframe_minutes=30): “””Analise dados de telemetria para determinar a causa raiz e recomendações.””” # Definir janela de tempo de análise tempo_final = datetime.now() tempo_início = tempo_final – timedelta(minutos=minutos_do_período_de_tempo) intervalo_de_tempo = {“início”: tempo_início.isoformato(), “fim”: tempo_final.isoformato()} # Buscar telemetria relevante com base no contexto logs = self.fetch_logs(id_solicitação=id_solicitação, id_usuário=id_usuário, intervalo_de_tempo=intervalo_de_tempo) # Extrair serviços mencionados em logs para análise de métricas direcionadas serviços = set(log.get(“serviço”, “desconhecido”) para logar em logs) # Obtenha métricas para esses serviços metrics_by_service = {} para serviço em serviços: para metric_name em [“latência”, “taxa de erro”, “taxa de transferência”]: metric_data = self.fetch_metrics(serviço, nome_da_métrica, intervalo_de_tempo) # Calcular propriedades estatísticas valores = [ponto[“valor”] para ponto em metric_data[“pontos_de_dados”]] metrics_by_service[f”{service}.{nome_da_métrica}”] = { “média”: estatísticas.média(valores) se valores senão 0, “mediana”: estatísticas.mediana(valores) se valores senão 0, “desvio-padrão”: estatísticas.desvio-padrão(valores) se len(valores) > 1 senão 0, “mín”: mín(valores) se valores senão 0, “máx”: máx(valores) se valores senão 0 } # Identificar anomalias usando z-score anomalias = [] para metric_name, estatísticas em metrics_by_service.items(): if stats[“stdev”] > 0: # Evite divisão por zero z_score = (stats[“max”] – stats[“mean”]) / stats[“stdev”] if z_score > 2: # Mais de 2 desvios padrão anomalies.append({ “metric”: metric_name, “z_score”: z_score, “severity”: “high” if z_score > 3 else “medium” }) return { “summary”: ai_summary, “anomalies”: anomalies, “impacted_services”: list(services), “recommendation”: ai_recommendation }

Código 3. Análise de incidentes, detecção de anomalias e método de inferência

A integração do MCP com plataformas de observabilidade pode aprimorar o gerenciamento e a compreensão de dados telemétricos complexos. Os potenciais benefícios incluem:

• Detecção mais rápida de anomalias, resultando em redução do tempo mínimo de detecção (MTTD) e do tempo mínimo de resolução (MTTR).
• Identificação mais fácil das causas raiz dos problemas.
• Menos ruído e menos alertas não acionáveis, reduzindo assim a fadiga de alertas e melhorando a produtividade do desenvolvedor.
• Menos interrupções e trocas de contexto durante a resolução de incidentes, resultando em melhor eficiência operacional para uma equipe de engenharia.

Aqui estão alguns insights importantes deste projeto que ajudarão as equipes com sua estratégia de observabilidade.

• Metadados contextuais devem ser incorporados no início do processo de geração de telemetria para facilitar a correlação posterior.
• Interfaces de dados estruturados crie camadas de consulta estruturadas e orientadas por API para tornar a telemetria mais acessível.
• IA sensível ao contexto concentra a análise em dados ricos em contexto para melhorar a precisão e a relevância.
• O enriquecimento de contexto e os métodos de IA devem ser refinados regularmente usando feedback operacional prático.

A fusão de pipelines de dados estruturados e IA é extremamente promissora para a observabilidade. Podemos transformar vastos dados de telemetria em insights acionáveis, aproveitando protocolos estruturados como MCP e análises orientadas por IA, resultando em sistemas proativos em vez de reativos. A Lumigo identifica três pilares da observabilidade — logs , métricas e rastros — que são essenciais. Sem integração, os engenheiros são forçados a correlacionar manualmente fontes de dados díspares, retardando a resposta a incidentes.

A maneira como geramos telemetria exige mudanças estruturais, bem como técnicas analíticas para extrair significado.

Pronnoy Goswami é um cientista de IA e dados com mais de uma década de experiência na área.