Dai terabyte alle informazioni: architettura di osservabilità dell'IA nel mondo reale

Si consideri la gestione e lo sviluppo di una piattaforma di e-commerce che elabora milioni di transazioni al minuto, generando grandi quantità di dati di telemetria, inclusi parametri, log e tracce su più microservizi. Quando si verificano incidenti critici, i tecnici di turno si trovano ad affrontare il difficile compito di setacciare un oceano di dati per estrapolare segnali e informazioni rilevanti. È come cercare un ago in un pagliaio.

Questo rende l'osservabilità una fonte di frustrazione piuttosto che di insight. Per alleviare questo importante punto dolente, ho iniziato a esplorare una soluzione che utilizzasse il Model Context Protocol (MCP) per aggiungere contesto e trarre inferenze dai log e dalle tracce distribuite. In questo articolo, descriverò la mia esperienza nella creazione di una piattaforma di osservabilità basata sull'intelligenza artificiale, spiegherò l'architettura del sistema e condividerò le informazioni pratiche apprese lungo il percorso.

Nei moderni sistemi software, l'osservabilità non è un lusso; è una necessità fondamentale. La capacità di misurare e comprendere il comportamento del sistema è fondamentale per l'affidabilità, le prestazioni e la fiducia degli utenti. Come dice il proverbio, "Ciò che non puoi misurare, non puoi migliorare".

Tuttavia, raggiungere l'osservabilità nelle odierne architetture cloud-native basate su microservizi è più difficile che mai. Una singola richiesta utente può attraversare decine di microservizi, ognuno dei quali genera log, metriche e tracce. Il risultato è un'abbondanza di dati di telemetria:

• Decine di terabyte di log al giorno
• Decine di milioni di punti dati metrici e pre-aggregati
• Milioni di tracce distribuite
• Migliaia di ID di correlazione generati ogni minuto

La sfida non è solo il volume dei dati, ma anche la loro frammentazione. Secondo il rapporto sulle previsioni di osservabilità del 2023 di New Relic , il 50% delle organizzazioni segnala dati di telemetria isolati, e solo il 33% riesce a ottenere una visione unificata di metriche, log e tracce.

I log raccontano una parte della storia, le metriche un'altra, le tracce un'altra ancora. Senza un contesto coerente, gli ingegneri sono costretti a correlazioni manuali, affidandosi all'intuizione, alla conoscenza tribale e a un noioso lavoro investigativo durante gli incidenti.

A causa di questa complessità, ho iniziato a chiedermi: come può l'intelligenza artificiale aiutarci a superare i dati frammentati e offrire informazioni complete e utili? Nello specifico, possiamo rendere i dati di telemetria intrinsecamente più significativi e accessibili sia per gli esseri umani che per le macchine utilizzando un protocollo strutturato come MCP ? Le fondamenta di questo progetto sono state plasmate da questa domanda centrale.

Anthropic definisce MCP come uno standard aperto che consente agli sviluppatori di creare una connessione bidirezionale sicura tra fonti di dati e strumenti di intelligenza artificiale. Questa pipeline di dati strutturati include:

• ETL contestuale per l'intelligenza artificiale: standardizzazione dell'estrazione del contesto da più fonti di dati.
• Interfaccia di query strutturata: consente alle query di intelligenza artificiale di accedere a livelli di dati trasparenti e facilmente comprensibili.
• Arricchimento dei dati semantici: incorpora un contesto significativo direttamente nei segnali di telemetria.

Ciò potrebbe potenzialmente spostare l'osservabilità della piattaforma dalla risoluzione reattiva dei problemi a intuizioni proattive.

Prima di addentrarci nei dettagli dell'implementazione, esaminiamo l'architettura del sistema.

Nel primo livello, sviluppiamo i dati di telemetria contestuali integrando metadati standardizzati nei segnali di telemetria, come tracce distribuite, log e metriche. Quindi, nel secondo livello, i dati arricchiti vengono immessi nel server MCP per indicizzare, strutturare e fornire ai client l'accesso ai dati arricchiti in base al contesto tramite API. Infine, il motore di analisi basato sull'intelligenza artificiale utilizza i dati di telemetria strutturati e arricchiti per il rilevamento di anomalie, la correlazione e l'analisi delle cause principali, al fine di risolvere i problemi applicativi.

Questa progettazione a strati garantisce che i team di intelligenza artificiale e di ingegneria ricevano informazioni fruibili e basate sul contesto dai dati di telemetria.

Esploriamo l'implementazione effettiva della nostra piattaforma di osservabilità basata su MCP, concentrandoci sui flussi di dati e sulle trasformazioni in ogni fase.

Livello 1: generazione di dati arricchiti dal contesto

Innanzitutto, dobbiamo assicurarci che i nostri dati di telemetria contengano un contesto sufficiente per un'analisi significativa. L'idea fondamentale è che la correlazione dei dati deve avvenire al momento della creazione, non al momento dell'analisi.

def process_checkout(user_id, cart_items, payment_method): “””Simula un processo di pagamento con telemetria arricchita dal contesto.””” # Genera ID correlazione order_id = f”order-{uuid.uuid4().hex[:8]}” request_id = f”req-{uuid.uuid4().hex[:8]}” # Inizializza il dizionario di contesto che verrà applicato contesto = { “user_id”: user_id, “order_id”: order_id, “request_id”: request_id, “cart_item_count”: len(cart_items), “payment_method”: payment_method, “service_name”: “checkout”, “service_version”: “v1.0.0” } # Avvia la traccia OTel con lo stesso contesto con tracer.start_as_current_span( “process_checkout”, attributes={k: str(v) per k, v in context.items()} ) come checkout_span: # Registrazione utilizzando lo stesso contesto logger.info(f”Avvio del processo di pagamento”, extra={“context”: json.dumps(context)}) # Propagazione del contesto con tracer.start_as_current_span(“process_payment”): # Elabora la logica di pagamento… logger.info(“Pagamento elaborato”, extra={“contesto”: json.dumps(contesto)})

Codice 1. Arricchimento del contesto per log e tracce

Questo approccio garantisce che ogni segnale di telemetria (registri, metriche, tracce) contenga gli stessi dati contestuali di base, risolvendo il problema di correlazione alla fonte.

Successivamente, ho creato un server MCP che trasforma i dati di telemetria grezzi in un'API interrogabile. Le operazioni principali sui dati qui includono quanto segue:

1. Indicizzazione : creazione di ricerche efficienti nei campi contestuali
2. Filtraggio : selezione di sottoinsiemi rilevanti di dati di telemetria
3. Aggregazione : calcolo di misure statistiche attraverso finestre temporali

@app.post(“/mcp/logs”, response_model=List[Log])def query_logs(query: LogQuery): “””Esegui query sui log con filtri specifici””” results = LOG_DB.copy() # Applica filtri contestuali if query.request_id: results = [log per i risultati di accesso if log[“context”].get(“request_id”) == query.request_id] if query.user_id: results = [log per i risultati di accesso if log[“context”].get(“user_id”) == query.user_id] # Applica filtri basati sul tempo if query.time_range: start_time = datetime.fromisoformat(query.time_range[“start”]) end_time = datetime.fromisoformat(query.time_range[“end”]) results = [log per i risultati di accesso if start_time <= datetime.fromisoformat(log[“timestamp”]) <= end_time] # Ordinare per marca temporale risultati = ordinati(risultati, chiave=lambda x: x[“timestamp”], inverso=True) restituisce risultati[:query.limit] se query.limit altrimenti risultati

Codice 2. Trasformazione dei dati tramite il server MCP

Questo livello trasforma la nostra telemetria da un data lake non strutturato in un'interfaccia strutturata e ottimizzata per le query, che un sistema di intelligenza artificiale può gestire in modo efficiente.

Il livello finale è un componente AI che consuma dati tramite l'interfaccia MCP, eseguendo:

1. Analisi multidimensionale : correlazione dei segnali tra registri, metriche e tracce.
2. Rilevamento delle anomalie : identificazione delle deviazioni statistiche dai modelli normali.
3. Determinazione della causa principale : utilizzo di indizi contestuali per isolare le probabili fonti dei problemi.

def analyze_incident(self, request_id=None, user_id=None, timeframe_minutes=30): “””Analizza i dati di telemetria per determinare la causa principale e le raccomandazioni.””” # Definisci la finestra temporale dell'analisi end_time = datetime.now() start_time = end_time – timedelta(minuti=minuti_intervallo_di_tempo) time_range = {“start”: start_time.isoformat(), “end”: end_time.isoformat()} # Recupera la telemetria pertinente in base al contesto logs = self.fetch_logs(request_id=request_id, user_id=user_id, time_range=time_range) # Estrarre i servizi menzionati nei log per analisi metriche mirate servizi = set(log.get(“servizio”, “sconosciuto”) per i log di accesso) # Ottieni metriche per quei servizi metrics_by_service = {} per il servizio in servizi: per metric_name in ["latenza", "error_rate", "throughput"]: metric_data = self.fetch_metrics(servizio, metric_name, time_range) # Calcola le proprietà statistiche valori = [punto[“valore”] per punto in metric_data[“data_points”]] metrics_by_service[f”{service}.{metric_name}”] = { “media”: statistics.mean(valori) se valori altrimenti 0, “mediana”: statistics.median(valori) se valori altrimenti 0, “dev.st”: statistics.stdev(valori) se len(valori) > 1 altrimenti 0, “min”: min(valori) se valori altrimenti 0, “max”: max(valori) se valori altrimenti 0 } # Identificare le anomalie utilizzando lo z-score anomalie = [] per metric_name, statistiche in metrics_by_service.items(): if stats[“stdev”] > 0: # Evita la divisione per zero z_score = (stats[“max”] – stats[“mean”]) / stats[“stdev”] if z_score > 2: # Più di 2 deviazioni standard 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 }

Codice 3. Metodo di analisi degli incidenti, rilevamento delle anomalie e inferenza

L'integrazione di MCP con piattaforme di osservabilità potrebbe migliorare la gestione e la comprensione di dati di telemetria complessi. I potenziali vantaggi includono:

• Rilevamento più rapido delle anomalie, con conseguente riduzione del tempo minimo di rilevamento (MTTD) e del tempo minimo di risoluzione (MTTR).
• Identificazione più semplice delle cause profonde dei problemi.
• Meno rumore e meno avvisi non attivabili, riducendo così l'affaticamento da avvisi e migliorando la produttività degli sviluppatori.
• Minori interruzioni e cambi di contesto durante la risoluzione degli incidenti, con conseguente miglioramento dell'efficienza operativa per un team di ingegneri.

Ecco alcuni spunti chiave tratti da questo progetto che aiuteranno i team a definire la loro strategia di osservabilità.

• I metadati contestuali dovrebbero essere incorporati nelle fasi iniziali del processo di generazione della telemetria per facilitare la correlazione a valle.
• Interfacce dati strutturati creare livelli di query strutturati e basati su API per rendere la telemetria più accessibile.
• IA contestuale concentra l'analisi su dati ricchi di contesto per migliorare l'accuratezza e la pertinenza.
• I metodi di arricchimento del contesto e di intelligenza artificiale dovrebbero essere perfezionati regolarmente utilizzando un feedback operativo pratico.

L'integrazione di pipeline di dati strutturati e intelligenza artificiale promette enormi vantaggi in termini di osservabilità. Possiamo trasformare enormi quantità di dati di telemetria in informazioni fruibili sfruttando protocolli strutturati come MCP e analisi basate sull'intelligenza artificiale, dando vita a sistemi proattivi anziché reattivi. Lumigo identifica tre pilastri essenziali dell'osservabilità: log , metriche e tracce . Senza integrazione, gli ingegneri sono costretti a correlare manualmente diverse fonti di dati, rallentando la risposta agli incidenti.

Il modo in cui generiamo la telemetria richiede cambiamenti strutturali e tecniche analitiche per estrarne il significato.

Pronnoy Goswami è uno scienziato dei dati e dell'intelligenza artificiale con oltre un decennio di esperienza nel settore.