Auf dem Remote Mac tauchen Sitzungsereignisse im Netzwerk auf, obwohl niemand sicher sagen kann, ob Eingaben, Tool-Ergebnisse oder nur technische Rückmeldungen übertragen werden.
Die schnellste sichere Lösung: Lassen Sie DeepSeek Harness zunächst auf DISABLED. Wenn Sie Feedback benötigen, testen Sie zuerst FEEDBACK_ONLY; FULL kommt erst nach Datenklassifizierung, geschütztem OTLP-Endpunkt, dokumentierter Löschung und einem kontrollierten Abschalt- sowie Fehlertest infrage. Für diese DeepSeek Harness OpenTelemetry Konfiguration gilt daher die Reihenfolge: Freigabepolitik festlegen → isolierten Test-Endpunkt anschließen → Fehler, Beenden und Datenrücknahme prüfen.
Diese Anleitung ist für drei Gruppen gedacht:
- Plattformingenieure, die Fehler auf einem zentral betriebenen Remote Mac untersuchen müssen.
- Sicherheits- und Compliance-Verantwortliche, die entscheiden, welche Sitzungsinhalte die Ausführungsumgebung verlassen dürfen.
- Betriebsteams, die eine beobachtbare DeepSeek-Harness-Umgebung an andere Nutzer oder Kunden übergeben.
OpenTelemetry ist dabei kein automatisch datensparsames Protokoll. Die offizielle Dokumentation weist ausdrücklich darauf hin, dass Telemetrie personenbezogene Daten, Zugangsdaten, Sitzungskennungen oder anwendungsspezifische Inhalte erfassen kann. Welche Daten sensibel sind, muss Ihre Organisation selbst festlegen. OpenTelemetry-Leitfaden zum Umgang mit sensiblen Daten
SECTION 01 Die Zeitlinie für eine kontrollierte Aktivierung
Vor dem Einschalten: Datenbesitz statt Exporter-Konfiguration
Bevor Sie eine Variable setzen oder einen Collector starten, erstellen Sie eine kleine Freigabematrix. Sie muss nicht lang sein, aber sie darf keine unklaren Sammelbegriffe wie „technische Daten“ enthalten.
Ordnen Sie mindestens diese Bereiche einzeln zu:
- Sitzungseingaben: Prompts, Dateiinhalte, Fehlermeldungen, interne Projektnamen und eingefügte Konfigurationswerte.
- Werkzeugdaten: Shell-Befehle, Tool-Argumente, Rückgabewerte, Dateipfade, Repository-Namen und Auszüge aus Build- oder Testausgaben.
- Rückmeldungen: Statusereignisse, Fehlerklassen, Laufzeitinformationen und vom Team ausdrücklich angeforderte Feedback-Felder.
- Identifikatoren: Benutzerkennung, Sitzungskennung, Hostname, IP-Adresse, Arbeitsverzeichnis und Mandantenbezug.
- Zugangsdaten: API-Schlüssel, Authorization-Header, Cookies, SSH-Material, Signaturdaten und Werte aus
.env-Dateien.
Zu jedem Feld gehören drei Verantwortlichkeiten:
- Datenbesitzer: Wer darf die Übertragung genehmigen?
- Erlaubter Zweck: Fehleranalyse, Produktfeedback, Kapazitätsplanung oder ein anderer klarer Zweck.
- Verbotene Übertragung: Was darf unter keinen Umständen den Remote Mac verlassen?
Falls ein Datenbesitzer fehlt, der Zweck nicht dokumentiert ist oder die Feldbedeutung vom aktuellen Quellstand abweicht, bleibt der Modus DISABLED. Genau hier liegt ein häufig unterschätzter Unterschied zwischen normaler Laufzeitprotokollierung und Sitzungs-Telemetrie: Ein Fehlerlog kann bereits einen Dateipfad oder einen Tool-Rückgabewert enthalten, während eine Sitzungs-Telemetrie zusätzlich die Beziehung zwischen Eingabe, Agent-Entscheidung und Werkzeugaktion abbilden kann.
Für DSGVO- oder interne Geheimhaltungsanforderungen ist die Richtung eindeutig: Nicht erst am Collector hoffen, dass sensible Daten entfernt werden, sondern die Erfassung bereits an der Quelle begrenzen. Ein Redaction- oder Filter-Prozessor ist eine zweite Schutzschicht, keine nachträgliche Genehmigung für eine zu großzügige Datenerfassung. OpenTelemetry-Empfehlungen zur Datenminimierung und Redaction
Meilenstein 1: Nur die gemeinsame Nutzungspolitik festlegen
Die drei Modi DISABLED, FEEDBACK_ONLY und FULL sollten Sie als unterschiedliche Datenfreigaben behandeln, nicht als Regler für „wenig“, „mittel“ oder „viel“ Log-Ausführlichkeit.
- DISABLED: Keine Sitzungs-Telemetrie absichtlich nach außen geben. Das ist der richtige Ausgangspunkt für neue Versionen, ungeklärte Datenfelder und Übergabesituationen.
- FEEDBACK_ONLY: Nur die Felder freigeben, die für einen vorher definierten Rückmeldezweck erforderlich sind. Eine Freigabe für Feedback bedeutet nicht automatisch, dass Tool-Ergebnisse oder vollständige Eingaben unkritisch sind.
- FULL: Erst nach einer geprüften Feldliste, einem autorisierten Endpunkt, einer Aufbewahrungsdauer und einem dokumentierten Löschverantwortlichen erwägen.
Die wichtige Frage lautet nicht: „Welcher Modus liefert die besten Logs?“ Sie lautet: „Welche Daten darf der Empfänger für welchen Zweck erhalten?“ Die offizielle DeepSeek-Harness-Repository-Dokumentation kennzeichnet den Entwicklungsstand als Vorschau und weist auf mögliche inkompatible Änderungen hin. Das ist für eine Sicherheitsfreigabe entscheidend: Eine heute geprüfte Feldliste darf nicht ohne Versionsprüfung als dauerhaft stabil gelten.
Dokumentieren Sie außerdem, wer den Modus ändern darf. Ein lokaler Entwickler, der auf einem gemeinsam genutzten Mac kurzfristig FULL einschaltet, kann damit eine Sicherheitsentscheidung umgehen, wenn die Konfiguration nicht durch Dateirechte, Startparameter oder eine zentrale Richtlinie geschützt ist.
SECTION 02 Schritt 2: Aufbau eines isolierten OTLP-Tests
Erst wenn der Modus entschieden ist, verbinden Sie den Exporter mit einem Testsystem. Die Reihenfolge verhindert, dass Sie zuerst einen produktiven Empfänger mit unbekannten Sitzungsdaten füllen.
Für OTLP logs über HTTP prüfen Sie vier Ebenen:
- Vollständiger Endpunkt: Schema, Host, Port und signalbezogener Pfad müssen zusammenpassen.
- Authentifizierung: Verwenden Sie einen dedizierten Testwert, der widerrufen werden kann. Der echte Header oder das Token gehört weder in diesen Artikel noch in Tickets, Screenshots oder Shell-Ausgaben.
- TLS: Für produktive Übertragung verwenden Sie HTTPS und prüfen Zertifikatskette, Hostnamen und gegebenenfalls mTLS.
- Netzwerkausgang: Auf dem Remote Mac muss nachvollziehbar sein, welche Zieladresse und welcher Proxy verwendet werden.
Die OpenTelemetry-Spezifikation nennt für OTLP/HTTP den Standard-Endpunkt http://localhost:4318; signalbezogene URLs können den Pfad selbst festlegen. Für Logs ist der typische signalbezogene Pfad /v1/logs. Diese Werte sind Protokollstandards, keine Aussage darüber, welchen Endpunkt DeepSeek Harness in Ihrer Version tatsächlich verwendet. OTLP-Exporter-Spezifikation und OTLP-Konfigurationsreferenz für HTTP und Logs dienen deshalb nur als technische Referenz für das Transportformat.
Eine Konfiguration sollte daher nur Platzhalter zeigen:
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="https://otel-test.example.invalid/v1/logs"
export OTEL_EXPORTER_OTLP_LOGS_HEADERS="authorization=<REVOKABLE_TEST_VALUE>"
export OTEL_EXPORTER_OTLP_LOGS_TIMEOUT="10000"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
Der Platzhalter-Endpunkt ist absichtlich nicht erreichbar und enthält keine echten Zugangsdaten. Er dient nur dazu, die Struktur zu zeigen. Ob DeepSeek Harness diese allgemeinen Variablen direkt übernimmt oder eine eigene Konfigurationsdatei verwendet, muss anhand des aktuellen Konfigurationskatalogs und des Quellstands geprüft werden.
Starten Sie anschließend eine minimale synthetische Sitzung:
- keine echten Benutzereingaben,
- kein Zugriff auf ein vertrauliches Repository,
- kein API-Schlüssel im Prompt,
- kein Tool-Ergebnis mit Kundendaten,
- ein eindeutig erkennbarer Testwert als Sitzungsmarkierung.
Vergleichen Sie danach drei Dinge: Was der Harness lokal als Ereignis erzeugt, was den Mac verlässt und was der Empfänger tatsächlich speichert. Eine erfolgreiche HTTP-Anfrage beweist nicht, dass die Datenbegrenzung korrekt war. Sie beweist nur, dass ein Transportweg funktioniert.
SECTION 03 Schritt 3: Prüfung der exportierten Felder
Jetzt beginnt die eigentliche Sicherheitsprüfung. OpenTelemetry empfiehlt, sensible Attribute bereits an der Quelle zu vermeiden und bei Bedarf Attribute zu löschen, zu filtern oder zu transformieren. Offizielle Sicherheits- und Collector-Empfehlungen
Prüfen Sie mindestens diese Feldgruppen:
- Enthält das Ereignis den vollständigen Benutzertext oder nur eine technische Kennung?
- Werden Tool-Argumente und Tool-Rückgaben übertragen?
- Erscheinen absolute Pfade, Repository-Namen oder Branch-Bezeichnungen?
- Werden Fehlermeldungen mit eingebetteten Umgebungsvariablen exportiert?
- Enthalten URL-Felder Query-Parameter oder Zugangsinformationen?
- Lassen sich Benutzer- und Sitzungskennungen dauerhaft einem Mandanten zuordnen?
- Werden lokale Dateinamen durch einen Filter entfernt oder nur im Empfänger verborgen?
Besonders URLs verdienen Aufmerksamkeit: Die OpenTelemetry-Dokumentation weist darauf hin, dass URL-Bestandteile Sicherheitsrisiken darstellen können und sensible Werte bereinigt werden sollten. Semantische Konventionen für URL-Daten
Fehlerfall: Verhalten bei nicht erreichbarem Empfänger
Hier dürfen Sie keine Retry-Anzahl aus einer allgemeinen OpenTelemetry-Dokumentation auf DeepSeek Harness übertragen. Das Verhalten hängt von der Harness-Version, dem verwendeten Exporter und der Frage ab, ob der Export synchron oder im Hintergrund arbeitet.
Prüfen Sie deshalb in einem kontrollierten Test:
- Sitzung mit synthetischem Inhalt starten.
- Erreichbarkeit des Test-Endpunkts nach dem Start blockieren.
- Agent-Aufgabe weiterlaufen lassen.
- Agent-Fortschritt, Tool-Ausführung und Prozessstatus protokollieren.
- Lokale Exportfehler und ausstehende Daten prüfen.
- Endpunkt wieder freigeben.
- Festhalten, welche Datensätze ankamen, verspätet ankamen oder fehlten.
Die OTLP-Spezifikation beschreibt bestimmte HTTP-Statuscodes als wiederholbar, darunter 429, 502, 503 und 504; ein permanenter Fehler wie 400 soll nicht wiederholt werden. Das ist eine Protokollregel, aber noch kein Beleg für das konkrete Verhalten des Harness. OTLP-HTTP-Fehler- und Wiederholungsregeln
Für Ihre Betriebsentscheidung sind drei Ergebnisse möglich:
- Agent arbeitet weiter, Telemetrie fehlt: Beobachtbarkeit ist eingeschränkt, aber die Aufgabe wird nicht blockiert.
- Agent wartet oder wird langsam: Der Exportpfad kann die Laufzeit beeinflussen und benötigt eine klare Zeitgrenze.
- Agent bricht ab: Telemetrie ist betriebskritisch und darf nicht ohne Ausweichstrategie aktiviert werden.
Die Exporter-Dokumentation nennt für allgemeine OTLP-Konfigurationen einen Timeout von 10 Sekunden als Standardwert. Verwenden Sie diese Zahl nicht als DeepSeek-Harness-Garantie; sie ist lediglich ein Referenzpunkt für den jeweiligen OpenTelemetry-Exporter. OTLP-Exporter-Konfiguration mit Timeout-Parametern
SECTION 04 Schritt 4: Erweiterung auf den Remote Mac
Wenn der isolierte Test bestanden ist, erweitern Sie die Umgebung schrittweise. Nicht mehrere Variablen, Plugins und Netzregeln gleichzeitig ändern, sonst können Sie eine unerwartete Datenquelle nicht mehr zuordnen.
- Version festhalten: Notieren Sie Harness-Version, Commit oder Release-Tag und Konfigurationsdatei.
- Modus bestätigen: Lesen Sie den tatsächlich geladenen Wert aus; verlassen Sie sich nicht nur auf eine Startvorlage.
- Testendpunkt erneut prüfen: Zertifikat, Authentifizierung, Proxy und Zielpfad müssen zum freigegebenen Empfänger passen.
- Feldliste gegenprüfen: Wiederholen Sie die synthetische Sitzung mit einem absichtlich platzierten Testwert.
- Ein echtes, niedrig klassifiziertes Szenario wählen: Keine Kundendaten, keine Produktionsschlüssel, kein vertraulicher Quelltext.
- Fehlerfall ausführen: Endpunkt blockieren und Auswirkungen auf Agent-Aufgabe und lokale Daten beobachten.
- Aufbewahrung prüfen: Kontrollieren Sie, wie lange der Empfänger Logs hält und wer die Löschung ausführt.
- Berechtigungen einschränken: Nur benannte Rollen dürfen Modus, Endpunkt oder Credentials ändern.
Die häufigsten versteckten Kosten liegen nicht im OTLP-Transport selbst, sondern in der Governance: zusätzliche Speicherorte, längere Aufbewahrung, schwer nachvollziehbare Proxy-Logs, Sicherheitsprüfungen nach einem Credential-Leak und die Frage, ob ein Remote Mac nach der Übergabe noch mit dem alten Empfänger kommunizieren kann.
Ein zentraler Betrieb auf einem Remote Mac verschärft diese Punkte. Sie müssen nicht nur den Prozess überwachen, sondern auch Netzwerkzugang, Benutzerwechsel, lokale Konfigurationsreste und die Verantwortung für Sitzungsdaten nach Ablauf der Nutzung klären. Für die organisatorische Seite sollten Sie die VPSNIX-Datenschutzhinweise mit Ihrer internen Lösch- und Aufbewahrungsrichtlinie abgleichen.
SECTION 05 Schritt 5: Abschaltung und Übergabe
Die Abschaltung ist kein einzelner Schalter. Sie ist ein eigener Abnahmeschritt, weil ein Prozess beim Beenden noch gepufferte Daten exportieren kann.
Führen Sie vor der Übergabe oder dem Ende einer Mietperiode diese Reihenfolge aus:
- Modus auf
DISABLEDsetzen. - Harness-Prozess kontrolliert beenden.
- Prüfen, ob noch OTLP-Verbindungen oder Export-Threads aktiv sind.
- Lokale Puffer, temporäre Exportdateien und Konfigurationsreste untersuchen.
- Endpunkt-Credentials widerrufen oder rotieren.
- Empfänger über die zu löschenden Test- und Sitzungsdaten informieren.
- Löschbestätigung oder eine verantwortliche Frist dokumentieren.
- Mit einem Netzwerkmonitor bestätigen, dass kein neuer Export mehr entsteht.
- Übergabeprotokoll mit Version, Modus, Endpunktstatus und Verantwortlichem archivieren.
Ein sauberer Prozess muss auch mit einem harten Abbruch umgehen können. Beenden Sie deshalb nicht nur „normal“, sondern testen Sie zusätzlich, was bei einem Timeout oder Prozessabbruch mit noch nicht gesendeten Datensätzen geschieht. Behaupten Sie keine bestimmte Persistenz oder garantierte Zustellung, wenn die aktuelle Harness-Version dies nicht dokumentiert oder reproduzierbar bestätigt.
Wenn Sie für wiederkehrende Übergaben eine feste Vorlage benötigen, können Sie zusätzlich die VPSNIX-Hilfe für Remote-Mac-Betrieb als organisatorischen Einstieg verwenden. Entscheidend bleibt jedoch die konkrete Abnahme auf dem betroffenen System, nicht ein allgemeiner Supporttext.
SECTION 06 Entscheidungshilfe vor der Freigabe
| Prüfpunkt | DISABLED | FEEDBACK_ONLY | FULL |
|---|---|---|---|
| Datenklassifizierung abgeschlossen | Nicht erforderlich für den Start, aber weiterhin empfohlen | Muss vor Aktivierung vorliegen | Muss vollständig und versionsbezogen vorliegen |
| Erlaubter Zweck dokumentiert | Nein | Ja, eng begrenzt | Ja, einschließlich zusätzlicher Sitzungsfelder |
| OTLP-Testendpunkt validiert | Nicht erforderlich | Ja | Ja, einschließlich TLS, Authentifizierung und Netzwerkausgang |
| Tool-Ergebnisse und Pfade geprüft | Nicht übertragen | Nur nach ausdrücklicher Freigabe | Vollständig prüfen und begründen |
| Fehlerszenario getestet | Empfohlen | Pflicht | Pflicht |
| Löschverantwortung geklärt | Für lokale Daten | Für empfangene Daten | Für alle Kopien und Backups |
| Geeignet für eine neue Remote-Mac-Übergabe | Ja | Nur mit dokumentierter Abnahme | Nur bei nachgewiesener Governance |
SECTION 07 Die kurze Abnahmeliste für Ihr Team
- [ ] Datenbesitzer für Sitzungen, Tool-Ergebnisse und Feedback benannt
- [ ] Erlaubte und verbotene Felder schriftlich festgelegt
- [ ] Modusänderungen auf autorisierte Rollen beschränkt
- [ ] Startzustand auf
DISABLEDgeprüft - [ ] Synthetische Sitzung ohne vertrauliche Inhalte durchgeführt
- [ ] OTLP-HTTP-Ziel, TLS und Test-Credential separat geprüft
- [ ] Keine echten Header oder Token in Dokumentation und Tickets abgelegt
- [ ] Empfängeraufzeichnung mit lokal erzeugten Ereignissen verglichen
- [ ] Pfade, Repository-Namen, Eingaben und Tool-Rückgaben kontrolliert
- [ ] Nicht erreichbarer Endpunkt getestet
- [ ] Verhalten von Agent-Aufgabe, Exporter und lokalen Puffern dokumentiert
- [ ] Normaler Prozessstopp und ausstehende Datensätze geprüft
- [ ] Credentials vor Übergabe widerrufen oder rotiert
- [ ] Löschverantwortung beim Empfänger bestätigt
- [ ] Nach Abschaltung keine neuen Netzwerkverbindungen festgestellt
SECTION 08 Häufige Fragen zur OpenTelemetry-Konfiguration
Werden Sitzungsdaten von DeepSeek Harness automatisch übertragen?
Verlassen Sie sich nicht auf einen angenommenen Standardwert. Prüfen Sie die aktive Konfiguration, die verwendete Version und den tatsächlich geöffneten Netzwerkpfad. Wenn ein Feld oder die Default-Policy nicht eindeutig belegt ist, bleibt der Modus DISABLED. Erst die Kombination aus Quellprüfung und synthetischer Sitzung zeigt, ob Daten übertragen werden.
Worin unterscheidet sich FEEDBACK_ONLY von FULL?
FEEDBACK_ONLY und FULL sind Datenfreigabepolitiken, keine bloßen Detailstufen von Logs. Der erste Modus sollte nur die für Feedback erforderliche Teilmenge senden. FULL kann zusätzliche Sitzungs- und Ereignisdaten umfassen. Ohne Feldliste, Zweckbindung und Löschprozess sollten Sie FULL nicht aktivieren.
Wie schützen Sie Zugangsdaten für den OTLP-Endpunkt?
Verwenden Sie HTTPS, dedizierte Test-Credentials und eine Möglichkeit zum schnellen Widerruf. Vermeiden Sie echte Header in Shell-Historien, Screenshots und Tickets. Prüfen Sie außerdem Proxy- und Collector-Protokolle, weil ein korrekt geschützter Transport sonst durch nachgelagerte Logs wieder sensible Werte offenlegen kann.
Beeinflusst ein fehlgeschlagener Telemetrieversand die Agent-Aufgabe?
Das hängt vom konkreten Exportpfad ab. OpenTelemetry beschreibt allgemeine Wiederholungsregeln, aber daraus folgt nicht automatisch das Verhalten von DeepSeek Harness. Blockieren Sie den Testendpunkt kontrolliert und dokumentieren Sie, ob die Aufgabe weiterläuft, wartet, Daten puffert oder abbricht. Nur dieses Ergebnis ist für Ihre Version belastbar.
Wie deaktivieren Sie Sitzungs-Telemetrie vor der Übergabe?
Setzen Sie den Modus auf DISABLED, beenden Sie den Prozess kontrolliert, prüfen Sie offene Verbindungen und entfernen Sie lokale Reste. Danach widerrufen Sie die Endpunkt-Credentials und klären die Löschung bereits empfangener Daten. Eine Übergabe ohne diese Schritte lässt eine alte Konfiguration oder einen weiterhin gültigen Zugang zurück.
Für Ihr Team ist die Entscheidung damit nicht „OpenTelemetry ja oder nein“, sondern welche Daten unter welchen Bedingungen und bis zu welchem Übergabepunkt beobachtbar sein müssen. Die aktuelle Variante ohne Telemetrie hat zwar weniger zentrale Diagnosemöglichkeiten, vermeidet aber unbekannte Sitzungsinhalte, zusätzliche Aufbewahrungsorte und schwer prüfbare Exportpfade. Eine unkontrollierte Eigeninstallation auf einzelnen Macs erzeugt dagegen Versionsdrift, uneinheitliche Netzwerkausgänge und Credentials, die bei der Übergabe leicht vergessen werden.
Wenn Sie temporäre, zentral betreibbare Testumgebungen benötigen, kann das Mieten eines Remote Mac deshalb die bessere operative Lösung sein: Sie können Netzwerkzugang, Prozesszustand und Rückgabeablauf an einem definierten System prüfen, statt mehrere lokale Geräte nachträglich zu bereinigen. Für langfristige, dauerhaft hohe Last oder Anforderungen an physische Schnittstellen bleibt ein eigener Mac die passendere Wahl. Für zeitlich begrenzte Harness-Tests mit kontrollierter Beobachtung sollten Sie die Umgebung dagegen erst mit DISABLED übernehmen und eine Aktivierung nur nach der vollständigen Abnahmeliste freigeben. Einen passenden Einstieg für verfügbare VPSNIX-Optionen finden Sie auf der VPSNIX-Übersichtsseite für Remote-Mac-Umgebungen.