Scality Blog | Object storage, AI data infrastructure & cyber resilience

Storage telemetry: Can logs cross data boundaries?

Written by Joshua Silvia | Sep 18, 2026, 5:54:14 PM

A storage platform can hold every byte inside a single jurisdiction and still send a steady stream of information about that data somewhere else. Metrics, logs, traces, crash dumps and support bundles are produced by the same systems that enforce residency, but they travel on different paths, under different contracts, and with far less scrutiny. The bytes stay home. The description of the bytes frequently does not.

The usual answer is that telemetry is operational data and therefore out of scope. That holds only while telemetry is genuinely anonymous, and most of it is not. One access log line can carry a bucket name that identifies a customer, an object key that describes a case file, a tenant identifier that maps to a named organization, and the address of the workstation that issued it. None of that is object payload, and all of it describes identifiable subjects.

Telemetry is also never one pipeline. A cluster emits metrics to one system, access logs to another, traces to a third, and support bundles to a vendor portal by a route opened by hand during an incident. Each path has its own destination, retention period and set of readers.

What telemetry usually contains

Metrics are the least sensitive category in principle and the most underestimated in practice. The numeric series are harmless. The labels attached to them are not. A per-bucket capacity gauge carries bucket names, a per-tenant request rate carries account identifiers, and a per-endpoint latency series describes site topology. High-cardinality labels get added because operators want to slice by customer, which is the property that turns a metrics database into a customer list.

Access logs are the richest source. A line generally includes the bucket, the object key, the operation, the requester identity, the remote address, the user agent, the status and byte counts. Keys are the part that surprises people, since applications routinely encode patient identifiers, contract numbers or employee names directly into key paths. These are the same object names and bucket names that make up a namespace, and they disclose more than the byte counts beside them.

Traces sit between the two, since span attributes often copy request paths, query strings and headers verbatim. Crash dumps are the extreme case, because a core file is a snapshot of process memory and may hold buffered payload, session tokens and key material that was resident at the moment of the fault.

Where telemetry goes once it leaves the cluster

The destination list is longer than most architecture diagrams show. Hosted observability platforms, error trackers, hosted log search, vendor call-home services, license checks, drive phone-home agents, and the ticketing system holding whatever is attached to a case. Each is a separate processor with its own locations and subcontractors, and the storage vendor is often not the operator of the backend where its own telemetry lands.

Regional configuration deserves verification rather than assumption. Observability vendors commonly offer regional ingest endpoints, but the default is the vendor's primary region, picked up from a configuration file nobody revisited after the pilot. Even where ingest is regional, support access to that tenant and backups of the index may not be.

Vendor support paths are the least controlled. A bundle produced during a severity one incident is generated under time pressure, reviewed by nobody, and attached to a ticket read by staff in several countries. The same applies when an engineer opens a remote session into the environment, which places a person rather than a file across the boundary.

Support bundles as a category of their own

A support bundle is not a log file. It is built to answer any question an engineer might ask later, so it tends to include configuration files, policy documents, account and user lists, certificate subjects, network topology and recent log excerpts. The collection script is written for diagnostic completeness, and completeness is the opposite of minimization.

Bundles therefore need review before upload, which is only possible if someone has read the collection script. Extracting a bundle in a staging area and deciding in advance which sections may leave the boundary turns an incident-time judgment call into an agreed procedure.

Telemetry typeWhat it typically carriesWhat to check before it leaves
Metric seriesBucket, tenant, account and host labels attached to otherwise neutral countersLabel allowlist; whether per-tenant series are aggregated locally
S3 access logsObject keys, bucket names, requester identity, source address, user agentWhether keys are hashed or truncated, and whether raw logs stay local
Distributed tracesRequest paths, query strings, headers and error strings copied into span attributesAttribute allowlist rather than denylist; sampling rate; header capture
Crash dumps and core filesProcess memory, including buffered payload, tokens and key materialWhether dumps are written at all, where they land, who may move them
Support bundlesConfiguration, policy documents, user lists, topology, log excerptsContents of the collection script; approval step and upload destination
Vendor call-homeVersion, capacity, alert state, serial numbers, sometimes configurationWhether it can be disabled or pointed at a local collector; a payload sample

Scoping and redaction without losing the signal

Redaction works best at the point of emission. Filtering at a central collector means the field already crossed the network, and collector rules are easy to bypass with a new exporter. Configuring the agents to omit or transform fields before transmission keeps the guarantee close to the source and makes it testable with a local sink.

For object keys, a keyed hash preserves the ability to correlate repeated access to the same object without disclosing what it is, provided the hash key stays inside the boundary. Prefix truncation is weaker but useful, since the first path segment usually identifies the application while later segments identify the subject. For traces, an attribute allowlist is the only approach that survives a library upgrade, because a denylist quietly stops covering fields that new instrumentation adds.

A two-tier model resolves most of the tension. Raw telemetry stays in a local store with short retention and local access control, giving operators full fidelity during incidents. A derived stream of aggregates, redacted logs and sampled traces feeds whatever shared system the organization uses for dashboards. Most of the metrics that reveal trouble early are rates, error ratios and queue depths, none of which need identifying labels.

Where Scality RING fits

RING is software-defined object and file storage deployed on standard x86 servers in the customer's own facility. Because the software runs on the operator's hardware inside the operator's network, the operator determines whether telemetry leaves at all, where collectors sit, and which outbound paths are permitted. The operational metrics and logs the system emits can be kept entirely local and scraped by an in-boundary monitoring stack.

Multi-tenancy in RING is expressed through accounts, users, buckets and IAM-style policies, which is also the structure that appears in telemetry labels and log lines. Knowing that account and bucket identifiers are the join keys makes it possible to decide which of them may appear in an exported series.

What to check on a schedule

Write down every outbound destination the storage platform and its agents can reach, including observability endpoints, license servers, call-home targets, package repositories and the support portal. Record the processing location, the retention period and who at the receiving organization can read it. Review the list after every agent upgrade, since new default endpoints arrive with releases.

Capture a real sample from each stream quarterly rather than trusting documentation. Take a hundred access log lines, a trace with full attributes, a metrics scrape and a fresh bundle, and read them as an outsider would, noting every field that identifies a person, customer, project or site. That sampling is the evidence an audit will ask for.

Test the failure mode as well. Block the outbound telemetry path in a maintenance window and confirm that the service keeps serving requests, that agents buffer rather than block, and that local dashboards still answer what an operator needs. A pipeline that cannot be switched off without degrading the data path is not a configuration choice, it is a dependency.