Od terabajtów do spostrzeżeń: architektura obserwacji sztucznej inteligencji w świecie rzeczywistym

Rozważ utrzymanie i rozwój platformy e-commerce, która przetwarza miliony transakcji na minutę, generując ogromne ilości danych telemetrycznych, w tym metryki, logi i ślady w wielu mikrousługach. W przypadku wystąpienia incydentów krytycznych, dyżurni inżynierowie stają przed trudnym zadaniem przeszukiwania oceanu danych w celu wydobycia istotnych sygnałów i spostrzeżeń. To jak szukanie igły w stogu siana.

To sprawia, że obserwowalność staje się źródłem frustracji, a nie wglądu. Aby złagodzić ten poważny problem, zacząłem szukać rozwiązania wykorzystującego protokół Model Context Protocol (MCP) do dodawania kontekstu i wyciągania wniosków z logów i rozproszonych śladów. W tym artykule przedstawię moje doświadczenia z budowaniem platformy obserwowalności opartej na sztucznej inteligencji, wyjaśnię architekturę systemu i podzielę się praktycznymi wnioskami zdobytymi w toku prac.

W nowoczesnych systemach oprogramowania obserwowalność nie jest luksusem, lecz podstawową koniecznością. Możliwość pomiaru i zrozumienia zachowania systemu jest fundamentem niezawodności, wydajności i zaufania użytkowników. Jak głosi przysłowie: „Czego nie da się zmierzyć, tego nie da się ulepszyć”.

Jednak osiągnięcie obserwowalności w dzisiejszych natywnych dla chmury architekturach opartych na mikrousługach jest trudniejsze niż kiedykolwiek. Pojedyncze żądanie użytkownika może obejmować dziesiątki mikrousług, z których każda generuje logi, metryki i ślady. Rezultatem jest mnóstwo danych telemetrycznych:

• Dziesiątki terabajtów logów dziennie
• Dziesiątki milionów punktów danych metrycznych i wstępnych agregatów
• Miliony rozproszonych śladów
• Tysiące identyfikatorów korelacji generowanych co minutę

Wyzwaniem jest nie tylko wolumen danych, ale także ich fragmentacja. Według raportu New Relic „Observability Forecast Report 2023” , 50% organizacji zgłasza odizolowane dane telemetryczne, a jedynie 33% osiąga ujednolicony widok metryk, logów i śladów.

Logi przedstawiają jedną część historii, metryki inną, a ślady jeszcze inną. Bez spójnego kontekstu inżynierowie są zmuszeni do ręcznej korelacji, polegając na intuicji, wiedzy plemiennej i żmudnej pracy detektywistycznej podczas incydentów.

Z uwagi na tę złożoność zacząłem się zastanawiać: w jaki sposób sztuczna inteligencja może pomóc nam wyjść poza fragmentaryczne dane i zaoferować kompleksowe, przydatne spostrzeżenia? Czy możemy sprawić, by dane telemetryczne stały się bardziej znaczące i dostępne zarówno dla ludzi, jak i maszyn, wykorzystując ustrukturyzowany protokół, taki jak MCP ? To centralne pytanie ukształtowało podwaliny tego projektu.

Anthropic definiuje MCP jako otwarty standard, który umożliwia programistom tworzenie bezpiecznego, dwukierunkowego połączenia między źródłami danych a narzędziami AI. Ten ustrukturyzowany przepływ danych obejmuje:

• Kontekstowe ETL dla sztucznej inteligencji: standaryzacja ekstrakcji kontekstu z wielu źródeł danych.
• Ustrukturyzowany interfejs zapytań: umożliwia zapytaniom AI dostęp do warstw danych, które są przejrzyste i łatwe do zrozumienia.
• Wzbogacanie danych semantycznych: osadza znaczący kontekst bezpośrednio w sygnałach telemetrycznych.

Ma to potencjał, aby przesunąć punkt ciężkości obserwacji platformy z reaktywnego rozwiązywania problemów w stronę proaktywnych wniosków.

Zanim przejdziemy do szczegółów implementacji, przyjrzyjmy się architekturze systemu.

W pierwszej warstwie opracowujemy kontekstowe dane telemetryczne, osadzając w sygnałach telemetrycznych standardowe metadane, takie jak rozproszone ślady, logi i metryki. Następnie, w drugiej warstwie, wzbogacone dane są przesyłane do serwera MCP w celu indeksowania, nadania struktury i zapewnienia klientom dostępu do danych wzbogaconych kontekstowo za pomocą interfejsów API. Na koniec, oparty na sztucznej inteligencji mechanizm analizy wykorzystuje ustrukturyzowane i wzbogacone dane telemetryczne do wykrywania anomalii, korelacji i analizy przyczyn źródłowych w celu rozwiązywania problemów z aplikacjami.

Taka wielowarstwowa konstrukcja gwarantuje, że zespoły ds. sztucznej inteligencji i inżynierii otrzymują kontekstowe i przydatne informacje z danych telemetrycznych.

Przyjrzyjmy się rzeczywistej implementacji naszej platformy obserwacyjnej opartej na MCP, skupiając się na przepływach danych i transformacjach na każdym kroku.

Warstwa 1: Generowanie danych wzbogaconych o kontekst

Po pierwsze, musimy upewnić się, że nasze dane telemetryczne zawierają wystarczający kontekst, aby przeprowadzić sensowną analizę. Kluczowe jest to, że korelacja danych musi nastąpić w momencie ich tworzenia, a nie analizy.

def process_checkout(user_id, cart_items, payment_method): “””Symuluj proces realizacji transakcji z wykorzystaniem telemetrii wzbogaconej o kontekst.””” # Wygeneruj identyfikator korelacji order_id = f”order-{uuid.uuid4().hex[:8]}” request_id = f”req-{uuid.uuid4().hex[:8]}” # Zainicjuj słownik kontekstowy, który zostanie zastosowany kontekst = { „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” } # Rozpocznij śledzenie OTel z tym samym kontekstem z tracer.start_as_current_span( “process_checkout”, attributes={k: str(v) dla k, v w context.items()} ) jako checkout_span: # Rejestrowanie przy użyciu tego samego kontekstu logger.info(f”Rozpoczęcie procesu realizacji zamówienia”, extra={“context”: json.dumps(context)}) # Propagacja kontekstu z tracer.start_as_current_span(“process_payment”): # Logika przetwarzania płatności… logger.info(“Płatność przetworzona”, extra={“kontekst”: json.dumps(kontekst)})

Kod 1. Wzbogacanie kontekstu dla logów i śladów

Takie podejście gwarantuje, że każdy sygnał telemetryczny (logi, metryki, ślady) zawiera te same podstawowe dane kontekstowe, rozwiązując problem korelacji u źródła.

Następnie zbudowałem serwer MCP, który przekształca surowe dane telemetryczne w API z możliwością zapytań. Podstawowe operacje na danych obejmują:

1. Indeksowanie : Tworzenie efektywnych wyszukiwań w polach kontekstowych
2. Filtrowanie : Wybieranie odpowiednich podzbiorów danych telemetrycznych
3. Agregacja : Obliczanie miar statystycznych w przedziałach czasowych

@app.post(“/mcp/logs”, response_model=List[Log])def query_logs(query: LogQuery): “””Zapytaj logi ze specyficznymi filtrami””” results = LOG_DB.copy() # Zastosuj filtry kontekstowe if query.request_id: results = [loguj wyniki logowania if log[“context”].get(“request_id”) == query.request_id] if query.user_id: results = [loguj wyniki logowania if log[“context”].get(“user_id”) == query.user_id] # Zastosuj filtry oparte na czasie if query.time_range: start_time = datetime.fromisoformat(query.time_range[“start”]) end_time = datetime.fromisoformat(query.time_range[“end”]) results = [loguj wyniki logowania if start_time <= datetime.fromisoformat(log[“timestamp”]) <= end_time] # Sort według znacznika czasu wyniki = posortowane(wyniki, klucz=lambda x: x[„znacznik czasu”], odwrotność=prawda) zwróć wyniki[:query.limit] jeśli query.limit w przeciwnym razie wyniki

Kod 2. Transformacja danych z wykorzystaniem serwera MCP

Ta warstwa przekształca nasze dane telemetryczne z niestrukturyzowanego jeziora danych w ustrukturyzowany interfejs zoptymalizowany pod kątem zapytań, po którym system sztucznej inteligencji może sprawnie poruszać się.

Ostatnią warstwą jest komponent AI, który pobiera dane przez interfejs MCP, wykonując:

1. Analiza wielowymiarowa : korelacja sygnałów w logach, metrykach i śladach.
2. Wykrywanie anomalii : identyfikacja statystycznych odchyleń od normalnych wzorców.
3. Określanie przyczyn źródłowych : korzystanie ze wskazówek kontekstowych w celu wyizolowania prawdopodobnych źródeł problemów.

def analyse_incident(self, request_id=None, user_id=None, timeframe_minutes=30): “””Analiza danych telemetrycznych w celu ustalenia przyczyny źródłowej i sformułowania zaleceń.””” # Zdefiniuj okno czasowe analizy czas_końcowy = datetime.now() czas_początkowy = czas_końcowy – delta_czasu(minuty=minuty_ramki_czasowej) zakres_czasu = {„początek”: czas_początkowy.isoformat(), „koniec”: czas_końcowy.isoformat()} # Pobierz istotne dane telemetryczne na podstawie kontekstu logi = self.fetch_logs(request_id=id_żądania, user_id=id_użytkownika, time_range=zakres_czasowy) # Wyodrębnij usługi wymienione w logach w celu przeprowadzenia ukierunkowanej analizy metrycznej usługi = set(log.get(“service”, “unknown”) dla logów logowania) # Pobierz metryki dla tych usług metrics_by_service = {} dla usługi w usługach: dla metric_name w [„latency”, „error_rate”, „throughput”]: metric_data = self.fetch_metrics(service, metric_name, time_range) # Oblicz właściwości statystyczne wartości = [punkt[“wartość”] dla punktu w metric_data[“data_points”]] metrics_by_service[f”{service}.{metric_name}”] = { “mean”: statistics.mean(wartości) jeśli wartości w przeciwnym razie 0, “median”: statistics.median(wartości) jeśli wartości w przeciwnym razie 0, “stdev”: statistics.stdev(wartości) jeśli len(wartości) > 1 w przeciwnym razie 0, “min”: min(wartości) jeśli wartości w przeciwnym razie 0, “max”: max(wartości) jeśli wartości w przeciwnym razie 0 } # Identyfikuj anomalie za pomocą wyniku z anomalie = [] dla metric_name, stats w metrics_by_service.items(): if stats[“stdev”] > 0: # Unikaj dzielenia przez zero z_score = (stats[“max”] – stats[“mean”]) / stats[“stdev”] if z_score > 2: # Więcej niż 2 odchylenia standardowe 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 }

Kod 3. Analiza incydentów, wykrywanie anomalii i metoda wnioskowania

Integracja MCP z platformami obserwacyjnymi może usprawnić zarządzanie i zrozumienie złożonych danych telemetrycznych. Potencjalne korzyści obejmują:

• Szybsze wykrywanie anomalii, skutkujące skróceniem minimalnego czasu wykrycia (MTTD) i minimalnego czasu rozwiązania (MTTR).
• Łatwiejsza identyfikacja przyczyn źródłowych problemów.
• Mniej szumu i niemożliwych do podjęcia działań alertów, co zmniejsza zmęczenie alertami i zwiększa produktywność programistów.
• Mniej przerw i zmian kontekstu podczas rozwiązywania incydentów, co przekłada się na większą wydajność operacyjną zespołu inżynieryjnego.

Poniżej przedstawiono kilka najważniejszych wniosków z tego projektu, które pomogą zespołom w opracowaniu strategii obserwowalności.

• Metadane kontekstowe należy osadzać na wczesnym etapie procesu generowania danych telemetrycznych, aby ułatwić późniejszą korelację.
• Ustrukturyzowane interfejsy danych tworzyć warstwy zapytań strukturalnych oparte na interfejsie API, aby zwiększyć dostępność danych telemetrycznych.
• Kontekstowa sztuczna inteligencja koncentruje analizę na danych bogatych w kontekst, aby zwiększyć dokładność i trafność.
• Wzbogacanie kontekstu i metody sztucznej inteligencji powinny być regularnie udoskonalane na podstawie praktycznych informacji zwrotnych dotyczących działania.

Połączenie ustrukturyzowanych przepływów danych i sztucznej inteligencji (AI) niesie ze sobą ogromne nadzieje na obserwowalność. Możemy przekształcić ogromne ilości danych telemetrycznych w praktyczne wnioski, wykorzystując ustrukturyzowane protokoły, takie jak MCP i analizy oparte na sztucznej inteligencji, co skutkuje systemami proaktywnymi, a nie reaktywnymi. Lumigo identyfikuje trzy filary obserwowalności – logi , metryki i ślady – które są niezbędne. Bez integracji inżynierowie są zmuszeni do ręcznego korelowania rozproszonych źródeł danych, co spowalnia reagowanie na incydenty.

Generowanie danych telemetrycznych wymaga zmian strukturalnych oraz stosowania technik analitycznych pozwalających na wydobycie znaczeń.

Pronnoy Goswami jest naukowcem zajmującym się sztuczną inteligencją i danymi, mającym ponad dziesięcioletnie doświadczenie w tej dziedzinie.