OpenTelemetry w GitHub Copilot: co widzi monitoring agenta?

Tak skonfigurowana aplikacja GitHub Copilot może wysyłać dane o pracy agenta do wskazanego przez administratora systemu monitoringu. Ślady pokazują kolejność działań agenta, w tym wywołania modeli i narzędzi. Metryki mogą zawierać między innymi liczbę tokenów wejściowych i wyjściowych, a zdarzenia rejestrować pojedyncze działania, takie jak przyjęcie lub odrzucenie edycji. Domyślnie telemetria nie zawiera treści promptów, odpowiedzi ani argumentów narzędzi. Włączenie przechwytywania treści zmienia ten zakres i może ujawnić kod, zawartość plików lub polecenia użytkownika. GitHub ogłosił obsługę OpenTelemetry w aplikacji 22 września 2026 r. Dokumentacja opisuje rodzaje danych i domyślne wyłączenia.

W skrócie

• Przy wyłączonym przechwytywaniu treści widać przebieg sesji, wywołania modeli i narzędzi oraz metadane, takie jak zużycie tokenów.
• Promptów, odpowiedzi i argumentów narzędzi nie ma w telemetrii domyślnie.
• Ustawienie captureContent może dołączyć treść do eksportu. lockCaptureContent pozwala administratorowi zablokować tę decyzję.
• Przed szerokim wdrożeniem sprawdź na testowej sesji, jakie dane rzeczywiście odbiera twój kolektor.

Co trafia do monitoringu bez treści promptów?

OpenTelemetry, w skrócie OTel, to standardowy sposób zbierania i eksportowania danych obserwowalności. Dokumentacja GitHubu wyróżnia trzy rodzaje sygnałów: ślady, metryki i zdarzenia. GitHub opisuje je w dokumentacji monitorowania agentów.

Ślad, czyli trace, łączy operacje wykonane w trakcie sesji. Można dzięki niemu zobaczyć, że agent wywołał model, użył na przykład narzędzia readFile, a następnie ponownie skontaktował się z modelem. Metryki są liczbami przydatnymi do obserwowania trendów, na przykład liczby tokenów wejściowych i wyjściowych. Zdarzenia zapisują konkretne działania, między innymi to, czy użytkownik zaakceptował, czy odrzucił edycję agenta. Dokumentacja GitHubu podaje te przykłady sygnałów.

Taki eksport pomaga prześledzić kolejność działań i sprawdzić, z jakich narzędzi agent korzystał. Nie jest jednak domyślnie zapisem rozmowy w formie tekstowej. To rozróżnienie ma znaczenie: z metadanych można obserwować sposób działania agenta, ale bez przechwytywania treści nie zobaczy się pełnego promptu ani odpowiedzi.

Kiedy monitoring przechwytuje wrażliwe treści?

Domyślna konfiguracja wyklucza prompty, odpowiedzi i argumenty narzędzi. Administrator może włączyć przechwytywanie treści, ale wtedy do eksportu mogą trafić informacje wrażliwe, takie jak fragmenty kodu, zawartość plików lub prompty użytkowników. GitHub wyraźnie zaleca sprawdzenie ustawień przechwytywania przed ich włączeniem. Dokumentacja ustawień wymienia captureContent jako przełącznik treści promptów i odpowiedzi, a lockCaptureContent jako sposób na uniemożliwienie użytkownikom zmiany tej wartości. Referencja ustawień zarządzanych GitHub Copilot

Warto pamiętać, że wyłączenie przechwytywania treści dotyczy zawartości eksportowanej w telemetrii. Nie należy traktować go jako mechanizmu, który wyłącza same wywołania modelu albo pracę narzędzi. To osobna decyzja dotycząca tego, jakie dane o sesji trafią do systemu monitoringu.

Moja rekomendacja dla środowiska firmowego: zacznij od captureContent: false i zablokuj tę wartość przez lockCaptureContent: true. Jeśli potrzebujesz treści do diagnozy, ogranicz taki eksperyment do kontrolowanego środowiska i sprawdź uprawnienia dostępu oraz retencję po stronie backendu. Włączenie przechwytywania całej zawartości dla wszystkich użytkowników może zmienić monitoring w dodatkowe miejsce przechowywania promptów i danych z repozytoriów.

Jak administrator może skonfigurować eksport?

GitHub wskazuje, że ustawienie telemetry w pliku managed-settings.json służy do włączenia eksportu i podania docelowego punktu końcowego. Referencja ustawień opisuje opcje takie jak enabled, endpoint, protocol, captureContent, lockCaptureContent, serviceName, resourceAttributes i headers. Dopuszczone protokoły to http/json oraz http/protobuf. Zobacz referencję ustawień zarządzanych.

Przykładowa konfiguracja może wyglądać tak:

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "copilot",
    "resourceAttributes": {
      "deployment.environment": "production"
    }
  }
}

Docelowy system musi obsługiwać OTLP. Jeśli backend nie przyjmuje danych bezpośrednio, GitHub zaleca użycie OpenTelemetry Collectora, który może odbierać, przetwarzać i przekazywać telemetrię dalej. Instrukcje konfiguracji opisują oba warianty.

Przy wdrożeniu polecam najpierw wskazać kontrolowany kolektor, włączyć eksport bez treści i uruchomić nieszkodliwą sesję testową. Sprawdź, czy ślad pokazuje oczekiwane wywołania modeli i narzędzi, a jednocześnie nie zawiera tekstu promptu ani argumentów. Ustal też, kto ma dostęp do backendu i jak długo dane będą przechowywane. Jeśli konfigurujesz nagłówki uwierzytelniające, traktuj je jak sekrety i zadbaj o bezpieczne zarządzanie nimi.

Ważna uwaga przed wdrożeniem w całym enterprise

Jest rozbieżność w dokumentacji, którą administrator powinien uwzględnić. Changelog z 22 września mówi wprost o obsłudze OpenTelemetry przez aplikację GitHub Copilot i konfiguracji przez ustawienia zarządzane. Z kolei bieżąca sekcja telemetry w referencji ustawień wymienia obsługę dla Copilot CLI i VS Code, ale nie aplikacji. Ogłoszenie o aplikacji i referencja ustawień nie opisują więc zakresu klientów w ten sam sposób.

Nie unieważnia to ogłoszenia o funkcji, ale przed szerokim rolloutem sprawdziłbym konfigurację na rzeczywistym kliencie aplikacji i zweryfikował eksport w kolektorze. W razie niejasności warto poprosić GitHub o potwierdzenie, które ustawienia i wersje aplikacji są objęte wsparciem. Dla administratora najważniejsze pozostaje proste rozdzielenie: ślady i metryki pokazują, jak agent pracuje, a dopiero osobna decyzja o przechwytywaniu treści może przesłać do monitoringu zawartość rozmowy lub wywołań narzędzi.