Funktioniert Honeycomb in China? Telemetrie-Data-Residency, PIPL & Distributed Traces
Honeycomb betreibt keine Region innerhalb Festlandchinas — es speichert Telemetrie in AWS us-east-1 (US) oder eu-west-1 (EU) —, die High-Cardinality-Events und Distributed Traces, die es von chinesischen Nutzern aufnimmt, werden also offshore verschifft, ein grenzüberschreitender Transfer personenbezogener Information nach PIPL. Ein Blick zuerst auf die Compliance, auf die Data-Residency-Tür und den ICP-beian-pflichtigen, inländischen Pfad, der Ihren Stack genau dort hält, wo er bereits läuft.
Funktioniert Honeycomb in China?
Ja — Honeycomb lädt und nimmt aus Festlandchina auf, aber das ist die leichte Hälfte. Honeycomb betreibt nur zwei Datenstandorte, einen in den USA und einen in der EU, und keinen innerhalb des Festlands, jedes Event und jeder Distributed Trace, den Sie in China sammeln, wird also auf einem Honeycomb-Backend offshore gespeichert — ein grenzüberschreitender Transfer personenbezogener Information, kein Geschwindigkeitsproblem.
Honeycombs eigener Support-Artikel gibt an, dass „Honeycomb has US-based and EU-based data residency“ und dass „Customer data can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland)“. Keine Region ist in Festlandchina, und es gibt keinen Festland-Standort zur Wahl. High-Cardinality-Telemetrie ist per Design personenbezogen: Ihre Spans und Events tragen Nutzer-IDs, Client-IPs und welche Request-Felder Ihre Instrumentierung auch anhängt, und Honeycomb merkt an, es „only has access to the telemetry data that customers send“ — der Inhalt und die Pflicht dafür sind also Ihre. Von Festland-Nutzern gesammelt und an ein US- oder EU-Backend verschifft, ist diese personenbezogene Information ein grenzüberschreitender Transfer, den PIPL regelt (Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus, Artikel 38–40), und für einen CIIO oder Handler mit großem Volumen muss sie in China gespeichert werden (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)). Die Tabelle auf der Seite ist Honeycombs eigener Wortlaut und die China-Regel, die jede Zeile auslöst.
Dies ist eine Risikokarte, kein Urteil — was gilt, hängt davon ab, was Ihre Spans tragen, wie viel davon personenbezogen ist und wer Ihre Nutzer sind. Unser China-Team kann Ihre Exponierung mit Ihnen kartieren →
Compliance-Momentaufnahme
- ! Keine Festlandchina-Region — Honeycomb speichert in AWS us-east-1 (US) oder eu-west-1 (EU), Ihre China-Telemetrie kommt also offshore zur Ruhe
- ! High-Cardinality-Events und Distributed Traces tragen Nutzer-IDs, Client-IPs und Request-Felder über die Grenze
- ! Diese Telemetrie ist personenbezogene Information — ein grenzüberschreitender Transfer nach PIPL (Mitteilung, gesonderte Einwilligung, ein Mechanismus)
- ✕ Keine inländische Region, die Residency-Pflicht eines CIIO oder Handlers mit großem Volumen kann also auf Honeycomb allein nicht erfüllt werden
- ✓ Erreichbarkeit ist nicht das Problem — und ein rechtmäßiger inländischer Pfad kann vor Honeycomb sitzen, unverändert
Was die offizielle Honeycomb-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Honeycomb betreibt keine Region innerhalb Festlandchinas. Honeycombs eigener Support-Artikel „Where is Honeycomb's data stored?“ gibt an, dass „Honeycomb has US-based and EU-based data residency“ und dass „Customer data can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland)“. Sie wählen bei der Anmeldung einen Standort; es gibt keine Festlandchina-Option, die Events und Traces, die Sie in China sammeln, werden also auf einem Honeycomb-Backend außerhalb des Festlands gespeichert. | Honeycomb Support — Where is Honeycomb's data stored? (support.honeycomb.io), abgerufen 2026-10-09 |
| Die Events und Traces, die Honeycomb aufnimmt, sind personenbezogene Information. Hohe Kardinalität ist der Zweck des Produkts: Jedes Event und jeder Span trägt die Attribute, die Ihre Instrumentierung anhängt — Nutzer-IDs, Client-IPs, Request-Felder und mehr. Honeycombs Datenschutz-Dokumentation merkt an, dass „Unlike some other vendors, Honeycomb only has access to the telemetry data that customers send“ — der Inhalt und die Verantwortung dafür sind also die des Kunden. Von Festland-Nutzern gesammelt und an ein US- oder EU-Backend verschifft, ist das ein grenzüberschreitender Transfer personenbezogener Information nach PIPL — Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus (Artikel 38–40); ungesäuberte Attribute können zudem sensible personenbezogene Information nach Artikel 28 tragen. | Honeycomb Docs — Compliance & Data Privacy (docs.honeycomb.io), abgerufen 2026-10-09; PIPL Artikel 28, 38–40 |
| Honeycomb bietet keinen Weg, die Daten im Festland zu halten. Honeycombs Unterauftragsverarbeiter-Seite, betitelt „Subprocessors for US and EU Honeycomb product“, listet Amazon Web Services mit Standorten „US, EU“ und merkt an, dass der „Customer may designate data residency upon signup“ — die einzigen Wahlmöglichkeiten sind die USA und die Europäische Union, beide außerhalb des Festlands. Für einen Betreiber kritischer Informationsinfrastruktur oder Handler mit großem Volumen muss in China erhobene personenbezogene Information im Festland gespeichert werden (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)) — eine Data-Residency-Pflicht, die Honeycombs US- und EU-Regionen nicht erfüllen können. | Honeycomb — Subprocessors for US and EU Honeycomb product (honeycomb.io/subprocessors), abgerufen 2026-10-09; PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) |
| Erreichbarkeit ist die leichte Hälfte — Honeycomb ist ein Backend, keine gehostete Site. Honeycombs Exporter und UI erreichen es aus China, die Exponierung ist also nicht, ob es sich verbindet, sondern wo die Telemetrie, die es aufnimmt, zur Ruhe kommt. Die ICP-Beian-Frage (Staatsrat-Erlass Nr. 292; MIIT-Erlass Nr. 33) haftet am öffentlichen Festland-Dashboard oder der App, die Sie betreiben, nicht an Honeycomb als Backend-Dienst — während die PIPL-Grenztransfer- und Data-Residency-Pflichten an den Events und Traces haften, die Honeycomb offshore speichert. | Honeycomb-Dokumentation, abgerufen 2026-10-09; Staatsrat-Erlass Nr. 292; MIIT-Erlass Nr. 33 |
Quellen vom 21YunBox Compliance-Team am 9. Oktober 2026 geprüft.
Für ein Festlandchina-Team ist die Frage zu Honeycomb fast nie, ob die UI öffnet oder ob ein Exporter den Ingest-Endpunkt erreichen kann — beides funktioniert meist. Die eigentliche Frage ist, wo die Telemetrie, die es sammelt, zur Ruhe kommen darf. Honeycomb beantwortet das klar in seiner eigenen Dokumentation: Es betreibt zwei Datenstandorte, einen in den USA und einen in der Europäischen Union, und keinen innerhalb Festlandchinas. Die Events und Distributed Traces, die Ihre Dienste in China emittieren, werden also aufgenommen und dann auf einem Honeycomb-Backend offshore gespeichert. Weil High-Cardinality-Telemetrie routinemäßig personenbezogene Information trägt — Client-IP-Adressen, Nutzer-IDs und welche Request-Felder Ihre Instrumentierung auch anhängt —, ist es ein Transfer, den Chinas Recht regelt, sie über die Grenze auszuführen. Das Dashboard, das lädt, ist die leichte Hälfte; wo die Traces landen, ist die Exponierung.
Honeycomb in China auf einen Blick
| Worüber es entscheidet | In Honeycombs eigenen Worten — und Chinas Recht |
|---|---|
| Wo die Daten zur Ruhe kommen | Honeycomb bietet „US-based and EU-based data residency“; Kundendaten werden in AWS us-east-1 (US) oder eu-west-1 (Irland) gespeichert. Es gibt keinen Festlandchina-Standort zur Wahl, in China gesammelte Telemetrie kommt also offshore zur Ruhe. |
| Was die Telemetrie enthält | High-Cardinality-Events und Distributed Traces tragen, was Ihre Instrumentierung auch anhängt — Nutzer-IDs, Client-IPs, Request-Pfade und -Felder. Honeycomb „only has access to the telemetry data that customers send“, was die Grenze überschreitet, ist also genau das, was Ihre Spans tragen. |
| Können Sie es in China halten | Nein. Die einzigen Standorte sind die USA und die EU; keiner ist im Festland, die inländische Speicherpflicht eines CIIO oder Handlers mit großem Volumen kann also auf Honeycomb allein nicht erfüllt werden. |
| Die Daten Ihrer China-Nutzer | Im Festland gesammelt und an ein US- oder EU-Backend verschifft, ist es ein grenzüberschreitender Transfer, den PIPL regelt — Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus (Artikel 38–40); ungesäuberte Attribute können sensible personenbezogene Information nach Artikel 28 tragen. |
| Ist es erreichbar? | Ja — Exporter und die UI verbinden sich aus China. Erreichbarkeit ist nicht die Achse; wo die Events und Traces gespeichert werden, ist es. |
Keine Festland-Region, Ihre Telemetrie kommt also offshore zur Ruhe
Honeycomb bietet zwei Datenstandorte, und Sie wählen einen bei der Anmeldung. Seine Support-Dokumentation gibt an, dass „Honeycomb has US-based and EU-based data residency“ und dass „Customer data can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland)“. Der US-Standort antwortet unter api.honeycomb.io und der EU-Standort unter api.eu1.honeycomb.io. Keiner sitzt in Festlandchina, und es gibt keinen Festland-Standort zur Wahl. Die OpenTelemetry-Collectoren und SDKs, die auf Ihren Festland-Diensten laufen, exportieren ihre Spans und Events also an eines dieser beiden offshore gelegenen Backends, auf dem Ihr Team ist. Sich mit Honeycomb zu verbinden war nie das Hindernis; die Telemetrie, die es aufnimmt, im Land zu halten, ist es.
Die Events und Traces, die Honeycomb aufnimmt, sind personenbezogene Information
Observability-Daten sind von Natur aus nicht anonym — eher das Gegenteil. Hohe Kardinalität ist der ganze Sinn von Honeycomb: Sie hängen so viele Attribute wie möglich an jedes Event und jeden Span an, damit Sie später nach jedem davon schneiden können. Diese Attribute umfassen routinemäßig eine Nutzer-ID, eine Client-IP, einen Account-Identifikator, einen Request-Pfad, Header und beliebige Felder, die Ihre Entwickler hinzufügen. Honeycomb merkt an, dass „Unlike some other vendors, Honeycomb only has access to the telemetry data that customers send“ — was den Inhalt und die Verantwortung dafür klar auf Sie legt: Was die Grenze überschreitet, ist genau das, was Ihre Instrumentierung emittiert. Die Client-IP eines einzelnen Festland-Nutzers ist bereits personenbezogene Information, und nach Chinas Gesetz zum Schutz personenbezogener Daten ist es ein grenzüberschreitender Transfer, sie an ein US- oder EU-Backend zu senden. Der Handler — Sie, nicht Honeycomb — muss Mitteilung geben, eine gesonderte Einwilligung für den Auslandstransfer einholen und einen Transfermechanismus absolvieren: eine Datenausfuhr-Sicherheitsbewertung, den CAC-Standardvertrag oder Zertifizierung (PIPL Artikel 38–40).
Ihre Spans zu trimmen verengt, was weggeht — es schließt die Tür nicht
Weil Honeycomb nur hält, was Sie senden, haben Sie echte Kontrolle über den Inhalt: Sie können Felder in Ihrer Collector-Pipeline fallen lassen oder hashen, Client-IPs weglassen und sensible Werte aus Span-Attributen heraushalten, bevor irgendetwas exportiert wird. Das ist es wert, getan zu werden. Aber Trimmen ändert, was die Grenze überschreitet, nicht die Tatsache, dass es sie überschreitet, und es tut nichts für Residency. Attribute, die nicht gesäubert werden, können zudem sensible personenbezogene Information tragen — präziser Standort oder Finanz- und Gesundheitsidentifikatoren —, die PIPL Artikel 28 für strengere Handhabung und eine eigene Einwilligung heraushebt. Und wenn Sie ein Betreiber kritischer Informationsinfrastruktur oder ein Handler mit großem Volumen sind, muss in China gesammelte personenbezogene Information im Festland gespeichert werden (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) — die Datenlokalisierungsanforderung, umnummeriert durch die Novelle von 2025, die am 1. Januar 2026 in Kraft trat), eine Pflicht, die weder der US- noch der EU-Honeycomb-Standort erfüllen kann. Getrennt davon haftet eine ICP-Beian (Staatsrat-Erlass Nr. 292; MIIT-Erlass Nr. 33) an jedem öffentlichen Dashboard oder jeder App, die Sie tatsächlich Festland-Besuchern aus China heraus bedienen — eine andere Tür als Honeycomb-das-Backend, und eine, die nicht mit Ihrem Honeycomb-Konto mitreist.
Dies ist eine Risikokarte, kein Urteil: Ob Sie eine gesonderte Einwilligung, einen Transfermechanismus, inländische Speicherung, eine ICP-Beian oder eine Mischung davon schulden, hängt davon ab, was Ihre Spans tragen, wie viel davon personenbezogen ist und wer Ihre Nutzer sind — es lohnt sich, das mit Rechtsbeistand zu klären, bevor Sie Ihre Collectoren an ein offshore gelegenes Backend verdrahten.
Wo 21YunBox hineinpasst — eine rechtskonforme Overlay, keine Migration
Sie betreiben Honeycomb weiter. Was ein Observability-Backend mit nur US- und EU-Standorten Ihnen nicht geben kann, ist ein rechtmäßiges Zuhause innerhalb Chinas für die personenbezogenen Daten, die Ihre Collectoren und SDKs dort sammeln. Das ist das Stück, das 21YunBox hinzufügt. Wir kartieren die PIPL-Grenztransfer- und Data-Residency-Pflichten, die an die Events und Traces anhaften, die Honeycomb aufnimmt — gegen Ihre Rechtsperson, Ihre Datenmengen und wer Ihre Nutzer sind. Wo Telemetrie nicht rechtmäßig weggehen kann, lokalisieren wir sie auf ein eingewilligtes, inländisches Verarbeitungs-und-Speicher-Muster, das diese Daten im Festland hält. Und wir liefern die öffentliche, China-gerichtete Seite auf ICP-beian-pflichtiger, inländischer Infrastruktur aus — dem 21YunBox Optimizer — vor den Stack gesetzt, den Sie bereits betreiben, ohne Neuaufbau, ohne zweite Codebasis und ohne Wegzug von Honeycomb für die Telemetrie, die rechtmäßig überschreiten darf. 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art; der Sinn ist ein Setup, das für Ihre Nutzer in China legal und rechtskonform läuft.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Datenausfuhr-Sicherheitsbewertungs-Maßnahmen
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- So erhalten Sie eine ICP-Beian für China
Häufige Fragen
Hat Honeycomb ein Rechenzentrum oder eine Region in Festlandchina?
Nein. Honeycombs Support-Artikel darüber, wo seine Daten gespeichert werden, sagt, es habe „US-based and EU-based data residency“ und dass Kundendaten „can be stored and processed in AWS us-east-1 (US East - USA) or AWS eu-west-1 (Europe - Ireland)“. Sie wählen bei der Anmeldung einen dieser beiden Standorte; keiner ist in Festlandchina, die Events und Distributed Traces, die Sie von chinesischen Nutzern und Diensten sammeln, werden also auf einem Honeycomb-Backend offshore gespeichert.
Ist es ein Problem, dass unsere Honeycomb-Telemetrie China verlässt?
Behandeln Sie es als ein mit Rechtsbeistand einzuschätzendes Risiko, kein pauschales Ja oder Nein. Honeycomb nimmt High-Cardinality-Events und -Traces auf, die personenbezogene Information tragen — Client-IP-Adressen, Nutzer-IDs und die Request-Felder, die Ihre Instrumentierung anhängt —, und speichert sie in den USA oder der EU. Nach PIPL ist das ein grenzüberschreitender Transfer, der Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus verlangt, und für einen CIIO oder Handler mit großem Volumen müssen die Daten im Festland gespeichert werden. Weil Honeycomb nur hält, was Sie senden, verengt das Trimmen von Feldern in Ihrem Collector, was die Grenze überschreitet — aber es entfernt nicht die Überschreitung oder die Residency-Frage.
Kann 21YunBox helfen, unser Honeycomb-Setup in China rechtskonform zu machen?
Ja. Unser China-Team kann Ihre PIPL-Grenztransfer- und Data-Residency-Exponierung für Ihre Rechtsperson, Ihre Datenmengen und Ihre Nutzer kartieren, die Daten, die nicht rechtmäßig weg können, auf ein eingewilligtes inländisches Muster lokalisieren und die ICP-beian-pflichtige, inländische Auslieferung aufstellen, die eine rechtskonforme China-Präsenz braucht — vor dem Stack, den Sie bereits betreiben, sodass Sie Honeycomb für die Telemetrie behalten, die rechtmäßig überschreiten darf. Kontaktieren Sie uns, um Ihren konkreten Fall durchzugehen.
