Observability agentów AI z OpenTelemetry bez wycieku danych

Observability agentów AI musi pokazać, jak cel użytkownika zamienił się w wywołania narzędzi i skutki. OpenTelemetry definiuje konwencje GenAI dla operacji takich jak invoke_agent, invoke_workflow, execute_tool i retrieval.

Struktura trace

Root span reprezentuje zadanie. Dzieci obejmują wywołanie modelu, retrieval, decyzję polityki i tool call. Koreluj sesję, użytkownika, agenta, wersję promptu, model oraz środowisko.

Nie umieszczaj identyfikatora użytkownika ani promptu w nazwie spana — powoduje wysoką kardynalność i wyciek.

Treść jest wrażliwa

Argumenty oraz wyniki narzędzi mogą zawierać sekrety i PII; OpenTelemetry wprost ostrzega o tym przy atrybutach GenAI. Domyślnie zbieraj typ narzędzia, status, czas, tokeny i decyzję. Pełną treść włączaj tylko dla kontrolowanej próbki z redakcją i retencją.

Alerty

Wykrywaj nowe narzędzie, nową domenę, wzrost denied actions, nietypowy scope, pętlę retry, skok kosztu i zmianę proporcji approval. Powiąż alert z wersją modelu i deployem.

Telemetry musi być odporna na manipulację przez agenta. Wysyłaj zdarzenia z middleware i executora, nie z tekstu generowanego przez model. Dane zasilają playbook reagowania na incydenty AI.

Trace całego zadania

Utwórz span nadrzędny dla zadania, a pod nim osobne spany dla wywołania modelu, pobrania kontekstu, decyzji polityki i wykonania narzędzia. Łącz je stabilnym identyfikatorem zadania oraz tenantu, nie treścią promptu. Atrybuty powinny opisywać dostawcę, model, wersję, nazwę narzędzia, status, latencję i zużycie, o ile nie ujawnia to danych wrażliwych.

OpenTelemetry publikuje konwencje semantyczne dla systemów generatywnej AI, ale implementacja musi uwzględniać ich aktualny status i wersję. Nie twórz własnych nazw dla pól, które mają standardowy odpowiednik; własne atrybuty umieść w przestrzeni organizacji i dokumentuj ich znaczenie.

Prywatność i integralność logów

Domyślnie nie zapisuj pełnych promptów, odpowiedzi, dokumentów RAG ani argumentów zawierających sekrety. Zamiast tego używaj klasyfikacji, długości, skrótu kontrolnego, identyfikatora datasetu i jawnej flagi zgody na rozszerzone logowanie. Retencja debug nie powinna automatycznie dziedziczyć okresu audytu.

Agent nie raportuje sam sobie sukcesu. Status wywołania, decyzję allow/deny, rzeczywisty adres docelowy i kod odpowiedzi emituje infrastruktura. Logi przesyłaj poza środowisko wykonawcze i kontroluj dostęp, aby zainfekowany agent nie mógł ich przepisać.

Detekcje oparte na sekwencji

Pojedyncza metryka kosztu ma ograniczony kontekst. Większą wartość daje sekwencja: niezaufany dokument, odrzucona próba nowej domeny, kilka retry i próba użycia narzędzia z wyższym scope. Buduj alerty na relacji spanów i porównuj zachowanie z wersją modelu, polityki oraz ostatnim wdrożeniem.

Regularnie testuj kompletność telemetry przez kontrolowane naruszenie polityki. Zespół powinien potrafić odtworzyć kto zainicjował zadanie, jakie dane zostały pobrane, które decyzje zapadły i czy jakakolwiek akcja osiągnęła system zewnętrzny.

Metryki SLO dla agentów

Oprócz latencji i błędów mierz odsetek zadań zakończonych bez eskalacji, liczbę wywołań narzędzi na zadanie, denied actions, udział fallbacku i koszt. Rozbijaj dane według przypadku użycia, ponieważ agent badawczy i agent wykonujący transakcje mają inny profil ryzyka.

Nie optymalizuj jednej metryki w izolacji. Spadek liczby odmów może oznaczać lepszą precyzję, ale także osłabioną politykę. Wzrost skuteczności zadania może wynikać z nadmiernego scope. Każdą zmianę porównuj z wynikami testów bezpieczeństwa.

Praktyka reagowania

Przygotuj zapisane zapytania dla wycieku danych, tool abuse, pętli retry i cross-tenant access. Alert powinien prowadzić do trace, wersji wdrożenia i procedury unieważnienia tożsamości. Dostęp do szczegółowych logów ogranicz do osób obsługujących incydent.

W ćwiczeniu tabletop zasymuluj skażony dokument i sprawdź, czy zespół znajdzie wszystkie zadania, które go pobrały, oraz działania zależne. Jeśli telemetry nie pozwala odpowiedzieć w rozsądnym czasie, brakujące powiązanie jest wymaganiem architektonicznym, nie tylko problemem dashboardu.

Ustal budżet kardynalności dla atrybutów. Identyfikator użytkownika, pełny URL lub losowy tekst w etykiecie metryki może zwiększyć koszt i utrudnić zapytania. Dane o wysokiej kardynalności zachowuj w trace lub logu, a metryki buduj z kontrolowanych, niskokardynalnych wymiarów.

Dokumentuj, które pola są obowiązkowe dla dochodzenia. Test w CI lub środowisku staging powinien wykryć zniknięcie identyfikatora zadania, decyzji polityki albo wyniku executora przed wdrożeniem zmiany telemetry.

Próbkuj zwykły ruch ostrożnie, ale zachowuj kompletne zdarzenia odmowy i akcji wysokiego wpływu. Reguła próbkowania musi być znana zespołowi dochodzeniowemu, aby brak spanów nie został błędnie uznany za brak aktywności.

Źródła: OpenTelemetry GenAI Attributes, OpenTelemetry Semantic Conventions.