Observability of Multi-Agent AI Systems with OpenTelemetry, Microsoft Agent Framework, and Azure Monitor

Dieser Blogbeitrag ist Teil der Community-Initiative Agentic Azure Insights von Nicholas Chang. Werfen Sie einen Blick auf andere Sitzungen, die Teil der Veranstaltung sind.

Intelligente Multi-Agent-Anwendungen mit Python, Microsoft Foundry und Azure erstellen, nachverfolgen, überwachen und Fehler beheben.

Einen KI-Agenten zu bauen, der auf einen Prompt reagiert, ist vergleichsweise unkompliziert. Eine produktionsreife Multi-Agent-Anwendung zu entwickeln ist eine völlig andere Herausforderung.

Da sich KI-Systeme von einzelnen Agenten zu kollaborativen Architekturen weiterentwickeln, wird es zunehmend schwierig, ihr Verhalten zu verstehen.

Stellen Sie sich eine Anwendung vor, in der mehrere spezialisierte KI-Agenten zusammenarbeiten, um eine Kundenserviceanfrage zu bearbeiten. Ein Agent ruft Kundeninformationen ab, ein weiterer bewertet Geschäftsrichtlinien und ein dritter erstellt die endgültige Lösung.

Was passiert, wenn die Anwendung langsam wird? Wie können wir feststellen, welcher Agent die Verzögerung verursacht hat? Was ist, wenn alle Agenten erfolgreich ausgeführt werden, aber die endgültige Entscheidung falsch ist?

Traditionelle Anwendungslogs liefern einige Antworten, reichen jedoch häufig nicht aus, um komplexe, verteilte KI-Workflows nachzuvollziehen.

An dieser Stelle erweisen sich OpenTelemetry, Microsoft Agent Framework und Azure Monitor als wertvoll.

In diesem Tutorial bauen wir eine beobachtbare Multi-Agent-Anwendung, die zeigt, wie man:

Das Wichtigste dabei: Wir untersuchen tatsächliche Szenarien, in denen etwas schiefgeht.

Im Tutorial verwendete Technologien: Python, FastAPI, Microsoft Agent Framework, Microsoft Foundry, OpenTelemetry, Azure Monitor, Application Insights, KQL, Azure Container Apps, Bicep und Azure Developer CLI.

Observability ist die Fähigkeit, das interne Verhalten eines Systems zu verstehen, indem man die von ihm erzeugten Signale analysiert.

In traditionellen verteilten Anwendungen stützt sich Observability auf drei grundlegende Säulen:

Für agentische KI-Anwendungen werden diese Fähigkeiten noch wichtiger.

Ein Multi-Agent-Workflow kann mehrere Modellaufrufe, externe APIs, Datenbankabfragen und Entscheidungen umfassen, die auf Informationen basieren, die von anderen Agenten erzeugt wurden.

Eine einzelne Benutzeranfrage kann Dutzende von Operationen über verschiedene Komponenten hinweg auslösen.

Ohne verteiltes Tracing wird es schwierig, den Ausführungspfad nachzuvollziehen.

OpenTelemetry bietet ein herstellerneutrales Framework zum Erzeugen, Sammeln und Exportieren von Telemetrie.

Sein Tracing-Modell ist besonders nützlich für Multi-Agent-Systeme.

Ein Trace repräsentiert eine End-to-End-Operation, während ein Span eine einzelne Arbeitseinheit innerhalb dieser Operation darstellt.

Betrachten Sie zum Beispiel die folgende Ausführung:

Jeder Span enthält Informationen wie den Namen seiner Operation, die Ausführungszeit, den Status, Attribute und die Beziehung zu anderen Spans.

Alle Spans innerhalb derselben verteilten Operation teilen sich eine Trace-ID.

Auf diese Weise können wir nachvollziehen, wie die Anwendung ein bestimmtes Ergebnis erzeugt hat.

Bauen wir eine kleine Multi-Agent-Anwendung, die Kundenanfragen zu Rückerstattungen untersucht.

Die Architektur umfasst einen Koordinator und drei spezialisierte Agenten.

CustomerAgent analysiert Kundeninformationen, einschließlich Konto-Stufe und Kaufhistorie.

PolicyAgent prüft die Belege zur Rückerstattungsrichtlinie und bestimmt, ob die verfügbaren Informationen eine Rückerstattung unterstützen.

ResolutionAgent kombiniert die Ergebnisse und erstellt eine empfohlene Lösung.

Der Koordinator steuert die Ausführungsreihenfolge, ruft Tools auf und stellt die Belege bereit, die jeder Agent benötigt.

Unsere Anwendung enthält außerdem zwei simulierte externe Dienste: eine Kundeninformations-API und eine Rückerstattungsrichtlinien-Nachschlage-API.

Die Anwendung unterstützt zwei Ausführungsmodi.

Im Mock-Modus sind die Agentenantworten deterministisch, sodass sich Observability demonstrieren lässt, ohne ein bereitgestelltes KI-Modell zu benötigen.

Im Foundry-Modus erstellt die Anwendung echte Microsoft Agent Framework Agenten, die mit dem Microsoft Foundry Projekt und der Modellbereitstellung verbunden sind, die im Rahmen der Azure-Bereitstellung angelegt werden. In der Standardvorlage verweist das Projekt auf eine bereitgestellte gpt-4o-mini-Bereitstellung, damit die App mit echter Modellinferenz laufen kann, ohne dass eine separate manuelle Einrichtung erforderlich ist.

Dieser Unterschied ist wichtig, weil der Mock-Modus die Instrumentierung des Workflows demonstriert, während der Foundry-Modus die echte Modellausführung und die zugehörige Telemetrie hinzufügt, sofern das installierte SDK dies unterstützt.

fastapi uvicorn opentelemetry-api opentelemetry-sdk opentelemetry-instrumentation-fastapi azure-monitor-opentelemetry azure-identity agent-framework-core agent-framework-foundry python-dotenv jinja2 Enter fullscreen mode Exit fullscreen mode Wir können die Umgebung erstellen und die Abhängigkeiten installieren:

python3 -m venv.venv source.venv/bin/activate pip install -r requirements.txt cp.env.example.env Enter fullscreen mode Exit fullscreen mode Zunächst verwenden wir die folgende Konfiguration:

MODEL_MODE = mock APPLICATIONINSIGHTS_CONNECTION_STRING = OTEL_SERVICE_NAME = multi-agent-investigator OTEL_CONSOLE = true ENABLE_SENSITIVE_DATA = false Enter fullscreen mode Exit fullscreen mode Dies ermöglicht der Anwendung den lokalen Betrieb ohne jegliche Azure-Ressourcen.

Beginnen wir mit der wichtigsten technischen Komponente: der Konfiguration des OpenTelemetry SDK.

In app/telemetry.py unterstützt unsere Implementierung sowohl lokales Console-Tracing als auch Azure Monitor.

Zuerst importieren wir die notwendigen Komponenten:

from opentelemetry import trace from opentelemetry.sdk.resources import Resource from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import ( BatchSpanProcessor, ConsoleSpanExporter ) Enter fullscreen mode Exit fullscreen mode Als Nächstes konfigurieren wir einen Tracing-Provider für die lokale Ausführung:

provider = TracerProvider ( resource = Resource. create ({ " service.name ": " multi-agent-investigator " }) ) provider. add_span_processor ( BatchSpanProcessor ( ConsoleSpanExporter ()) ) trace. set_tracer_provider ( provider ) Enter fullscreen mode Exit fullscreen mode Der TracerProvider verwaltet die Tracing-Konfiguration, während der BatchSpanProcessor die Spans verarbeitet und sie an den konfigurierten Exporter sendet.

Der ConsoleSpanExporter gibt die erzeugten Spans im Terminal aus.

Das ist besonders nützlich während der lokalen Entwicklung und bei Live-Demonstrationen.

Für Azure Monitor verwendet das Projekt einen anderen Konfigurationsweg:

from azure.monitor.opentelemetry import configure_azure_monitor configure_azure_monitor ( connection_string = connection, resource = Resource. create ({ " service.name ": service }), sampling_ratio = 1.0, logger_name = " agent_demo ", enable_live_metrics = True ) Enter fullscreen mode Exit fullscreen mode Die Anwendung wählt diese Konfiguration, wenn APPLICATIONINSIGHTS_CONNECTION_STRING vorhanden ist.

Sie kann zudem den Console-Exporter an denselben Tracing-Provider anhängen, sodass wir die Telemetrie lokal beobachten können, während sie gleichzeitig an Azure exportiert wird.

Wir konfigurieren bewusst nur einen einzigen globalen Tracing-Provider.

Nun folgt eine weitere wichtige Integration:

from agent_framework.observability import enable_instrumentation enable_instrumentation ( enable_sensitive_data = False ) Enter fullscreen mode Exit fullscreen mode Microsoft Agent Framework kann OpenTelemetry-Signale für instrumentierte Agent-Operationen erzeugen.

Dies ergänzt die benutzerdefinierten Spans, die wir für unseren Coordinator, den Workflow und die simulierten externen Tools erstellen.

Die Einstellung enable_sensitive_data=False ist besonders wichtig, da Agent-Eingaben und -Ausgaben vertrauliche oder personenbezogene Informationen enthalten können.

In Produktionsumgebungen sollte die Erfassung vollständiger Prompts, Kundendaten und Modellantworten niemals ohne geeignete Datenschutzkontrollen aktiviert werden.

In app/agents.py definieren wir die Anweisungen für jeden Spezialisten:

AGENT_INSTRUCTIONS = { " CustomerAgent ": ( " You are a customer record specialist. " " Summarize the provided account facts " " in one sentence. Do not invent additional facts. " ), " PolicyAgent ": ( " You review refund policy evidence. " " Report whether the supplied policy " " evidence allows refund. " ), " ResolutionAgent ": ( " Provide a concise support resolution " " based ONLY on the supplied customer " " and policy evidence. " ) } Enter fullscreen mode Exit fullscreen mode Wenn der Foundry-Modus aktiviert ist, initialisiert die Anwendung einen Foundry-Client:

from agent_framework import Agent from agent_framework.foundry import FoundryChatClient from azure.identity import DefaultAzureCredential client = FoundryChatClient ( project_endpoint = endpoint, model = model, credential = DefaultAzureCredential () ) Enter fullscreen mode Exit fullscreen mode Anschließend erstellen wir die spezialisierten Agenten:

agents = { name: Agent ( client = client, name = name, instructions = instructions ) for name, instructions in AGENT_INSTRUCTIONS. items () } Enter fullscreen mode Exit fullscreen mode Jeder Agent ist für eine bestimmte Aufgabe verantwortlich.

Der Coordinator liefert die Beweise und ruft die Agenten nacheinander auf.

result = await agents [ " PolicyAgent " ]. run ( policy_evidence ) Enter fullscreen mode Exit fullscreen mode Man beachte, dass unsere Orchestrierung nicht erfordert, dass die Agenten direkt miteinander kommunizieren.

Der Python-Coordinator steuert die Ausführung und den Informationsaustausch explizit.

Das macht den Workflow leichter verständlich und ermöglicht es uns, um jede Operation eigene Tracing-Grenzen zu legen.

In app/workflow.py erstellen wir einen Root-Span, der die gesamte Untersuchung repräsentiert.

with tracer (). start_as_current_span ( " workflow.investigate ", attributes = { " demo.scenario ": scenario, " demo.request_id ": request_id, " workflow.name ": " customer_investigation " } ) as root: ctx = root. get_span_context () trace_id = f " { ctx. trace_id: 032 x } " Enter fullscreen mode Exit fullscreen mode Dies ist der Ausgangspunkt unseres beobachtbaren Workflows.

Jeder untergeordnete Span, der in diesem Kontext erstellt wird, erbt den aktuellen Tracing-Kontext.

Der Code extrahiert außerdem die Trace-ID und gibt sie an die Weboberfläche zurück.

Damit hat der Nutzer eine direkte Möglichkeit, eine Anwendungsantwort mit ihrer Telemetrie zu verknüpfen.

with tracer (). start_as_current_span ( " agent.Coordinator ", attributes = { " agent.name ": " Coordinator ", " demo.scenario ": scenario } ): # Execute the workflow... Enter fullscreen mode Exit fullscreen mode Danach erstellen wir einzelne Spans für die spezialisierten Agenten:

with tracer (). start_as_current_span ( " agent.CustomerAgent ", attributes = { " agent.name ": " CustomerAgent " } ): customer_out = await runner. run ( " CustomerAgent ", customer_evidence ) Enter fullscreen mode Exit fullscreen mode Dasselbe Muster wird auf PolicyAgent und ResolutionAgent angewendet.

So können wir die Workflow-Hierarchie visualisieren und Agent-Operationen von externen Tool-Aufrufen unterscheiden.

OpenTelemetry-Spans unterstützen benutzerdefinierte Attribute, die einer Operation Kontext hinzufügen.

In unserer Anwendung verwenden wir Attribute wie:

demo.scenario demo.request_id agent.name tool.name demo.outcome demo.policy_version demo.answer_quality Enter fullscreen mode Exit fullscreen mode Diese Attribute sind besonders nützlich, wenn man Telemetriedaten in Azure Monitor analysiert.

Statt sich durch unstrukturierte Logmeldungen zu suchen, können wir Operationen nach ihrer fachlichen Bedeutung filtern.

Beispielsweise können wir nur die Ausführungen untersuchen, bei denen die Policy-Version veraltet war oder der Workflow ein unerwartetes Ergebnis lieferte.

Um die Demo interaktiv zu machen, verwenden wir FastAPI und Bootstrap.

Die Webanwendung stellt einen Endpunkt bereit, um ein ausgewähltes Szenario auszuführen:

@app.post ( " /api/scenarios/{scenario} " ) async def run_scenario ( scenario: str ): if scenario not in VALID_SCENARIOS: raise HTTPException ( status_code = 404, detail = " Unknown scenario " ) return await investigate ( scenario, app. state. runner ) Enter fullscreen mode Exit fullscreen mode Das vollständige Projekt bietet zudem einen Health-Endpunkt und eine HTML-Oberfläche.

Nach der Ausführung eines Szenarios zeigt die Webanwendung die abschließende Empfehlung, die Zwischenergebnisse der Agenten, die Ausführungsdauer, die Request-ID und die Trace-ID an.

Die Trace-ID ist besonders wertvoll, weil wir sie direkt in unsere KQL-Abfragen übernehmen können.

Fuehren wir zunaechst das gesunde Szenario aus.

Dafuer koennen wir die Weboberflaeche nutzen oder die API aufrufen:

curl -X POST \ http://localhost:9001/api/scenarios/healthy Enter fullscreen mode Exit fullscreen mode Der Coordinator fuehrt die folgenden Operationen aus:

Der simulierte Kunde ist ein Premium-Kunde, dessen Kauf 12 Tage zurueckliegt.

Die Erstattungsrichtlinie erlaubt es Premium-Kunden, innerhalb von 30 Tagen eine Rückerstattung zu beantragen.

Folglich lautet die erwartete Empfehlung, die Rückerstattung zu genehmigen.

Der Console Exporter erzeugt Spans für den Workflow, den Coordinator, die Tools und die Agents.

Diese Spans teilen sich dieselbe Trace ID und enthalten Timing-Informationen.

Im Foundry-Modus fuegt die unterstuetzte automatische Agent-Instrumentierung Details zur Modellausfuehrung hinzu.

Die zentrale Erkenntnis ist, dass wir nun viel mehr verstehen als nur die endgueltige Antwort.

Wir koennen die Ausfuehrungsreihenfolge rekonstruieren und sehen, wo Zeit verbracht wurde.

Dies ist die Basislinie, mit der wir die naechsten Szenarien vergleichen werden.

Stellen wir uns vor, dass Kunden ueber langsame Antworten unserer KI-Anwendung berichten.

Die erste Annahme waere moeglicherweise, dass das Modell zu lange fuer die Antwort benoetigt.

Das eigentliche Problem koennte jedoch ein externer Dienst sein.

Um dies zu demonstrieren, injizieren wir Latenz in die Kundenabruf-Operation.

async def _customer_tool ( scenario: str ): with tracer (). start_as_current_span ( " tool.get_customer ", attributes = { " tool.name ": " get_customer ", " demo.scenario ": scenario } ): if scenario == " slow_api ": await asyncio. sleep ( 2.5 ) else: await asyncio. sleep ( 0.08 ) return { " customer_id ": " C-1001 ", " tier ": " premium ", " order_id ": " O-2048 ", " days_since_order ": 12 } Enter fullscreen mode Exit fullscreen mode Fuehren wir das Szenario aus:

curl -X POST \ http://localhost:9001/api/scenarios/slow_api Enter fullscreen mode Exit fullscreen mode Der Workflow liefert weiterhin die erwartete Antwort, aber seine Gesamtdauer steigt.

Der Trace ermoeglicht es, die Quelle dieser Latenz zu identifizieren.

Statt dem Modell die Schuld zu geben, koennen wir erkennen, dass tool.get_customer etwa 2,5 Sekunden verbraucht hat.

Leistungsprobleme in agentischen Anwendungen sind nicht zwingend Modellprobleme.

Sie koennen aus Datenbanken, Tool-Servern, Netzwerkaufrufen, Authentifizierungsdiensten oder anderen Abhaengigkeiten entstehen.

Sobald die Telemetrie Application Insights erreicht, koennen wir die langsamsten Operationen identifizieren:

dependencies | where timestamp > ago(24h) | where name has "tool." or name has "agent." or name has "workflow." | summarize runs = count(), p50_ms = percentile(duration / 1ms, 50), p95_ms = percentile(duration / 1ms, 95), failures = countif(success == false) by name | order by p95_ms desc Enter fullscreen mode Exit fullscreen mode Diese Abfrage misst die Latenz von Operationen und deren Fehleranzahl.

Bei wiederholten Ausfuehrungen helfen Perzentile wie P95, Leistungsmuster aufzudecken, die Durchschnittswerte verbergen koennen.

Fuer diese Demonstration erwarten wir, dass die Kundenabruf-Operation im Slow-API-Szenario eine deutlich hoehere Latenz aufweist.

Dies ist wahrscheinlich das interessanteste Szenario der Demonstration.

Was passiert, wenn alle Komponenten erfolgreich ausgefuehrt werden, die endgueltige Antwort aber falsch ist?

Distributed Tracing kann uns sagen, ob eine Operation abgeschlossen wurde, aber es legt nicht automatisch fest, ob die Antwort inhaltlich korrekt ist.

Denken wir an einen Richtliniendienst fuer Rückerstattungen, der veraltete Informationen zurueckgibt.

Unsere Anwendung simuliert dieses Verhalten:

if scenario == " incorrect_decision ": span. set_attribute ( " demo.fault ", " stale_policy_data " ) return ( " REFUND_DENIED: stale cached policy " " says all refunds are disabled " ) Enter fullscreen mode Exit fullscreen mode Der Kunde hat gemaeß der aktuellen Richtlinie Anspruch auf eine Rückerstattung, doch das Tool liefert eine veraltete Regel.

Im deterministischen Mock-Modus folgt der PolicyAgent dieser Information, und der ResolutionAgent empfiehlt, die Rückerstattung abzulehnen und eine manuelle Pruefung anzufordern.

Technisch gesehen wird der Workflow ohne Ausnahmen abgeschlossen.

Um dieses Problem beobachtbar zu machen, haengt unsere Demo eigene Attribute an den Root Span an:

incorrect = scenario == " incorrect_decision " root. set_attribute ( " demo.answer_quality ", " incorrect_due_to_stale_tool " if incorrect else " expected " ) root. set_attribute ( " demo.policy_version ", " stale " if incorrect else " current " ) root. set_attribute ( " demo.outcome ", " incorrect " if incorrect else " success " ) Enter fullscreen mode Exit fullscreen mode Dadurch koennen wir technischen Erfolg vom erwarteten Geschaefstsverhalten unterscheiden.

Es gibt eine wichtige Einschraenkung: Diese Labels werden durch das bekannte Stoerungs-Injektionsszenario der Demonstration erzeugt.

Sie stellen keine automatische KI-Evaluierung dar.

Ein Produktionssystem waere auf zusaetzliche Validierung, Pruefungen der Richtlinienaktualitaet, regelbasierte Verifikation oder modellbasierte Evaluierung angewiesen, um unerwartet falsche Entscheidungen zu erkennen.

Im Foundry-Modus erkennt das Modell den Konflikt moeglicherweise sogar selbst und vermeidet die falsche Empfehlung.

dependencies | where timestamp > ago(24h) | where name has "workflow.investigate" | extend outcome = tostring( customDimensions["demo.outcome"] ), scenario = tostring( customDimensions["demo.scenario"] ), policyVersion = tostring( customDimensions["demo.policy_version"] ) | summarize runs = count(), avg_ms = avg(duration / 1ms) by scenario, outcome, policyVersion Enter fullscreen mode Exit fullscreen mode Diese Abfrage hilft dabei, Ausführungen mit absichtlich gekennzeichneten falschen Ergebnissen zu identifizieren.

Die grundlegendere Erkenntnis daraus ist, dass AI Observability die Kombination von operativer Telemetrie mit anwendungsseitigen Qualitätssignalen erfordert.

Eine erfolgreiche HTTP-Anfrage oder ein abgeschlossener Span garantiert nicht, dass eine KI-Entscheidung vertrauenswürdig ist.

Unser letztes Szenario simuliert einen Ausfall des Policy-Dienstes.

Statt eine Policy zurückzugeben, löst das Werkzeug eine Ausnahme aus.

if scenario == " tool_error ": span. set_attribute ( " demo.fault ", " upstream_timeout " ) raise TimeoutError ( " Policy service timed out " " (intentional demo fault) " ) Enter fullscreen mode Exit fullscreen mode Auf der Ebene des Workflows fangen wir die Ausnahme ab und markieren den Root-Span als fehlgeschlagen:

except Exception as exc: root. record_exception ( exc ) root. set_status ( Status ( StatusCode. ERROR, str ( exc )) ) root. set_attribute ( " demo.outcome ", " error " ) Enter fullscreen mode Exit fullscreen mode Das gibt uns diagnostische Informationen über den Fehler, einschließlich seines Zusammenhangs mit dem Workflow.

Ein interessantes Detail ist, dass die Demo eine strukturierte JSON-Antwort zurückgibt, die die fehlgeschlagene Untersuchung beschreibt.

Das bedeutet, dass der Web-Endpunkt selbst weiterhin HTTP 200 zurückgeben kann.

Folglich würde eine reine Überwachung der HTTP-Statuscodes kein vollständiges Bild der Anwendungsfehler liefern.

Explizite Fehler-Signale auf Workflow-Ebene sind unverzichtbar.

union isfuzzy=true dependencies, exceptions | where timestamp > ago(24h) | where success == false or itemType == "exception" | project timestamp, itemType, operation_Id, name, type, outerMessage, customDimensions | order by timestamp desc Enter fullscreen mode Exit fullscreen mode Damit können wir fehlgeschlagene Dependencies und Ausnahme-Telemetrie untersuchen.

Die Trace-ID verbindet das Problem mit der entsprechenden Kundenuntersuchung.

Bisher haben wir die Telemetrie lokal betrachtet.

Jetzt zentralisieren wir die Informationen in Azure.

Unsere Bicep-Infrastruktur definiert mehrere Ressourcen:

Application Insights ist mit dem Log Analytics Workspace verbunden, und die App erhält den bereitgestellten Foundry-Endpunkt sowie die Model Deployment Einstellungen als Umgebungsvariablen.

Die Container App erhält den Application Insights Connection String über ihre Umgebungskonfiguration.

Beispielsweise enthält die Bicep-Vorlage Folgendes:

resource insights 'Microsoft.Insights/components@2020-02-02' = { name: appInsightsName location: location kind: 'web' properties: { Application_Type: 'web' WorkspaceResourceId: logs.id } } Enter fullscreen mode Exit fullscreen mode Die Deployment-Konfiguration ist in azure.yaml definiert:

name: multi-agent-observability-lab infra: provider: bicep path: infra services: web: project:. language: py host: containerapp docker: path: Dockerfile Enter fullscreen mode Exit fullscreen mode Wir können die Infrastruktur mit der Azure Developer CLI bereitstellen und deployen:

az login azd auth login azd env new agent-otel-demo azd env set AZURE_LOCATION eastus2 azd up Enter fullscreen mode Exit fullscreen mode Dieser Workflow ist darauf ausgelegt, die Hosting- und Observability-Ressourcen bereitzustellen, das Container-Image zu bauen und die Anwendung zu deployen.

Die Bicep-Vorlage verwendet bei der anfänglichen Infrastrukturbereitstellung ein Platzhalter-Image, das durch das Deployment der Anwendung ersetzt werden soll.

Ein paar Überlegungen sind erwähnenswert.

Erstens stellt die Azure-Bereitstellung das Microsoft Foundry-Konto, das Projekt und das Modell gpt-4o-mini automatisch als Teil desselben Infrastruktur-Stacks bereit, sodass das Beispiel mit Live-Inferenz laufen kann, ohne dass eine separat verwaltete Foundry-Einrichtung erforderlich ist.

Zweitens wurde die Azure-Deployment-Vorlage im Rahmen dieses Tutorials nicht end-to-end gegen ein Live-Abonnement validiert. Azure-Berechtigungen, regionale Verfügbarkeit, SDK-Änderungen und das Verhalten des Container-Deployments sollten getestet werden, bevor die Demo in einem Live-Event verwendet wird.

Für eine zuverlässige Präsentation können wir die Python-Anwendung auch lokal weiterlaufen lassen, während die Telemetrie an eine bereitgestellte Application Insights-Ressource exportiert wird.

So wird vermieden, dass die gesamte Demonstration von einem erfolgreichen Cloud-Deployment der Anwendung abhängt.

Eines der nützlichsten Observability-Features ist die Möglichkeit, eine vollständige Ausführung anhand eines einzelnen Bezeichners zu rekonstruieren.

Unsere Weboberfläche zeigt die vom Workflow zurückgegebene Trace-ID an.

Wir können diesen Bezeichner kopieren und die folgende Abfrage in Application Insights ausführen:

let traceId = "REPLACE_WITH_TRACE_ID"; union isfuzzy=true requests, dependencies, traces, exceptions | where operation_Id == traceId | project timestamp, itemType, name, duration, success, message, operation_Id, parentId = operation_ParentId, customDimensions | order by timestamp asc Enter fullscreen mode Exit fullscreen mode Damit werden die Telemetriedaten zusammengeführt, die zu einer einzelnen Untersuchung gehören.

Da die Vorgänge denselben Korrelationskontext teilen, können wir die Ereignisse, Spans und Fehler identifizieren, die zum selben Workflow gehören.

Das ist besonders nützlich, wenn Multi-Agent-Architekturen über eine einzige Anwendung hinauswachsen.

Beispielsweise können dieselben Prinzipien die Korrelation über HTTP-Dienste, Agent-Tools, Datenbanken und andere verteilte Komponenten hinweg unterstützen, sofern der Trace-Kontext über diese Grenzen hinweg weitergegeben wird.

Ein weiterer wichtiger Aspekt der AI Observability sind die Kosten.

Bei traditionellen Anwendungen analysieren wir typischerweise die Infrastrukturnutzung, CPU, Speicher und die Anzahl der Serviceanfragen.

Generative KI bringt zusätzliche Verbrauchskennzahlen mit sich, darunter Input-Tokens, Output-Tokens und Modellaufrufe.

Die Instrumentierung des Microsoft Agent Framework kann Informationen zur Modellnutzung bereitstellen, sofern dies von der jeweiligen SDK-Version, dem Modellanbieter und dem Exporter unterstützt wird.

Unser Projekt enthält eine Abfrage, die nach häufigen Telemetrie-Attributen für generative KI sucht:

dependencies | where timestamp > ago(24h) | extend inputTokens = tolong( customDimensions["gen_ai.usage.input_tokens"] ), outputTokens = tolong( customDimensions["gen_ai.usage.output_tokens"] ) | where isnotnull(inputTokens) or isnotnull(outputTokens) | summarize input_tokens = sum(inputTokens), output_tokens = sum(outputTokens), calls = count() by name | order by input_tokens desc Enter fullscreen mode Exit fullscreen mode Diese Abfrage ist relevant, wenn echte Modellinferenz über Foundry ausgeführt wird.

Im Mock-Modus werden keine Modellaufrufe ausgeführt, daher wird keine Token-Nutzung erzeugt.

Außerdem können sich die genauen Namen der Telemetrie-Attribute und deren Speicherorte je nach Instrumentierungs-Version und Azure Monitor Zuordnungen unterscheiden.

Bevor wir Produktions-Dashboards erstellen, sollten wir die tatsächlich exportierten Modell-Spans untersuchen und die verfügbaren Attribute überprüfen.

Sobald zuverlässige Nutzungsdaten vorliegen, können wir geschätzte Modellkosten berechnen, indem wir den Token-Verbrauch mit den Preisen der ausgewählten Modellbereitstellung kombinieren.

Das eröffnet Möglichkeiten für eine Kostenverteilung auf Agent-Ebene, Budgetüberwachung und operative Optimierung.

Unsere Demonstration konzentriert sich auf das Verständnis von Observability-Konzepten, doch produktionsreife Multi-Agent-Anwendungen erfordern zusätzliche Überlegungen.

Verteilte Kontextweitergabe: Wenn Agents und Tools über mehrere Dienste oder Prozesse hinweg ausgeführt werden, muss der Tracing-Kontext zwischen ihnen weitergegeben werden. Das Erstellen lokaler Child-Spans ist nur der Ausgangspunkt.

Sampling und Telemetrie-Volumen: Unsere Demo zeichnet alle Traces auf, um die Untersuchung zu erleichtern. Produktionsanwendungen sollten diagnostische Anforderungen, Sampling-Entscheidungen, Ingestion-Kosten und Aufbewahrungsrichtlinien gegeneinander abwägen.

Sicherheit und Datenschutz: Telemetrie darf nicht wahllos Nutzer-Prompts, vertrauliche Dokumente, Zugangsdaten oder persönliche Informationen erfassen.

Automatisierte Anomalieerkennung: KQL-Abfragen und Azure Monitor-Warnregeln können Muster wie erhöhte Fehlerraten, ungewöhnliche Latenz oder unerwartete Nutzung erkennen.

KI-Evaluation: Operatives Tracing sollte durch Evaluationstechniken ergänzt werden, die Genauigkeit, Fundiertheit, Richtlinienkonformität und andere anwendungsspezifische Qualitätsdimensionen bewerten.

Kostengovernance: Token-Nutzung, Modellaufrufe, Infrastrukturverbrauch und Telemetrie-Ingestion sollten in die nicht-funktionalen Anforderungen und operativen Budgets der Anwendung einbezogen werden.

Observability ist nicht einfach nur eine Debugging-Funktion. Sie ist Teil des verantwortungsvollen Betriebs von KI-Systemen im großen Maßstab.

Fassen wir die empfohlene Ausführungsreihenfolge zusammen.

python -m uvicorn app.main:app --reload Enter fullscreen mode Exit fullscreen mode Öffne:

Führe dann die Szenarien in dieser Reihenfolge aus:

Untersuche bei jedem Szenario die Konsolen-Traces, kopiere die Trace-ID und führe die entsprechenden KQL-Abfragen in Azure Monitor aus.

Wenn die Application Insights-Telemetrie nicht sofort sichtbar ist, nutze den lokalen Console Exporter, während die Ingestion abgeschlossen wird.

Wechsle abschließend in den Foundry-Modus, um echte Agent-Ausführung und modellbezogene Telemetrie zu demonstrieren.

Die Standard-Azure-Bereitstellung erstellt bereits den Projekt-Endpoint und das gpt-4o-mini Modell, sodass die App auf die bereitgestellten Werte verweisen kann, ohne dass eine manuelle Azure AI Einrichtung erforderlich ist. Wenn du sie manuell überschreiben möchtest, lauten die Umgebungsvariablen:

MODEL_MODE = foundry FOUNDRY_PROJECT_ENDPOINT = https://YOUR-PROJECT.services.ai.azure.com FOUNDRY_MODEL_DEPLOYMENT = YOUR_MODEL_DEPLOYMENT Enter fullscreen mode Exit fullscreen mode Authentifiziere dich bei Azure und stelle sicher, dass deine Identität über die erforderlichen Berechtigungen verfügt, um das bereitgestellte Modell aufzurufen.

Starte die Anwendung neu und führe dieselben Szenarien aus.

Nun verwenden die Agents anstelle von deterministischen Mock-Antworten die von der Infrastruktur bereitgestellte Microsoft Foundry-Bereitstellung.

Multi-Agent-KI-Anwendungen bringen neue operative Herausforderungen mit sich, da ihr Verhalten von mehreren Agents, Modellen, Tools und externen Diensten abhängt.

Eine finale Antwort zeigt uns, was die Anwendung erzeugt hat, erklärt aber selten den vollständigen Ausführungspfad, der zu ihr geführt hat.

OpenTelemetry bietet die Tracing-Grundlage, die zum Verstehen dieses Ausführungspfads erforderlich ist, während Microsoft Agent Framework Instrumentierung für Agent-Operationen bereitstellt und Azure Monitor eine zentralisierte Analyse ermöglicht.

Anhand unserer vier Demo-Szenarien haben wir gelernt, wie man einen Performance-Engpass identifiziert, Fehler korreliert, fehlerhafte Entscheidungen untersucht und die Modellnutzung auswertet.

Die vielleicht wichtigste Erkenntnis ist, dass Observability und Evaluation komplementäre Probleme lösen.

Observability hilft uns zu verstehen, was im System passiert ist. Evaluation hilft uns festzustellen, ob das Verhalten und die Ergebnisse angemessen waren.

Die Kombination beider Fähigkeiten ist entscheidend für den Aufbau zuverlässiger, erklärbbarer und operativ beherrschbarer agenter KI-Systeme.

Vergiss nicht, dir auch die übrigen Community-Sessions von Agentic Azure Insights anzusehen.

Danke fürs Lesen, bis zum nächsten Mal! Luis