Operational Telemetry Collection¶
ARTESCA continuously collects operational telemetry data from your deployment and sends it to Scality. This telemetry is enabled by default in all ARTESCA installations starting 4.3.0. If this telemetry stops working for any reason, the ARTESCA deployment will continue to function normally. The data collected is strictly limited to operational and infrastructure metrics that describe the health, capacity, and performance of your ARTESCA deployment.
Scality never collects or shares personal data, user-identifying information, or customer content. Scality uses this telemetry to monitor deployment health, improve the product, and power Scality Guardian, the AI-assisted support agent.
Why Scality Collects Telemetry¶
Telemetry serves two purposes:
It helps Scality improve support efficiency and quality when assisting customers. Operational data collected across the installed base gives engineering teams a clear picture of how the product behaves in real-world conditions, across a wide variety of hardware configurations and workloads. This data provide information on performance improvements, capacity planning guidance, and roadmap priorities.
It powers Scality Guardian, the AI-assisted support agent. Scality Guardian uses the telemetry context of your deployment to provide relevant and accurate answers rather than generic guidance. Guardian correlates what it observes in your environment with known issues, identifies early warning signs, and suggests remediation steps tailored to your situation.
What Data Is Collected¶
ARTESCA collects two categories of metrics: deployment-level metrics that describe the overall state of the deployment, and node-level metrics collected individually for each node.
Deployment Level Metrics¶
These metrics describe the overall state of your ARTESCA deployment, collected from Kubernetes, AlertManager, and Prometheus.
Metric |
Description |
Source |
|---|---|---|
Software version |
Currently installed version of ARTESCA |
Kubernetes ConfigMap |
Overall health status |
Aggregate health state: ok, warning, critical, or unknown |
AlertManager |
Number of managed storage volumes |
Count of storage volumes under ARTESCA management |
Kubernetes Custom Resource |
Total number of nodes |
Total count of nodes in the deployment |
Kubernetes API |
Used capacity |
Sum of protected and stored data across the deployment, in bytes |
Prometheus |
Total raw disk capacity |
Total raw disk capacity across all nodes, in bytes |
Prometheus |
Free capacity |
Raw disk capacity still free across all nodes, in bytes |
Prometheus |
Monthly peak protected data |
Maximum protected data over the 30-day window starting on the 1st of the current month, in bytes |
Prometheus |
Rolling 30-day peak protected data |
Maximum protected data over the most recent rolling 30-day period, in bytes |
Prometheus |
Number of stored objects |
Total count of objects stored across the deployment |
Prometheus |
S3 read and write throughput |
Rate of data read from and written to the S3 service, averaged over the last five minutes, in bytes per second |
Prometheus |
S3 read and write request rate |
Rate of S3 read (GET, HEAD) and write (PUT, POST, DELETE) requests served, averaged over the last five minutes, in requests per second |
Prometheus |
S3 read and write latency |
Mean duration of S3 read and write requests over the last five minutes, in milliseconds |
Prometheus |
Storage used per account |
Bytes stored, per account and per storage location. Account names are not transmitted. |
ARTESCA management API |
Network repair outcome |
Cumulative amount of data repaired over the network, and cumulative amount of data whose network repair failed, across the deployment, in bytes |
Prometheus |
Active S3 endpoints |
Array of hostnames for currently active S3 endpoints |
Kubernetes Ingress |
Active critical alerts |
Count of alerts currently firing at critical severity |
AlertManager |
Active warning alerts |
Count of alerts currently firing at warning severity |
AlertManager |
Node-Level Metrics¶
ARTESCA collects these metrics individually for each node. Network metrics are
collected per network interface, excluding Calico virtual interfaces. Disk
metrics are collected per physical block device, excluding shm and tmpfs mounts.
The following network metrics are collected for each interface.
Metric |
Description |
|---|---|
Incoming and outgoing bandwidth |
Rate of inbound and outbound traffic, in bytes per second |
Dropped packets (in and out) |
Rate of dropped packets, in packets per second |
Packet errors (in and out) |
Rate of packet errors, in errors per second |
The following CPU metrics are collected for each node.
Metric |
Description |
|---|---|
CPU usage |
Percentage of CPU capacity currently in use |
CPU load |
CPU load average as a percentage |
The following memory metrics are collected for each node.
Metric |
Description |
|---|---|
Total memory |
Total physical memory available on the node, in bytes |
Used memory |
Physical memory currently in use, in bytes |
The following disk metrics are collected for each physical block device.
Metric |
Description |
|---|---|
Used and total disk capacity |
Disk space in use and available on the device, in bytes |
Read and write latency |
Average operation latency, in microseconds |
Read and write IOPS |
Input/output operations per second (IOPS) |
Read and write throughput |
Data transfer rate, in bytes per second |
Device errors |
Number of filesystems on the device reporting a device error |
Device utilization |
Fraction of time the device spent performing I/O, as a ratio |
The following storage service metrics are collected for each node.
Metric |
Description |
|---|---|
Data format migration |
Number of data groups still in the previous on-disk format, and number of data groups already in the current format |
Network repair backlog |
Parts and bytes waiting to be rebuilt over the network, parts and bytes waiting to be deleted rather than rebuilt, and parts and bytes that cannot currently be rebuilt |
Network repair progress |
Cumulative parts and bytes rebuilt over the network, and cumulative parts and bytes deleted rather than rebuilt |
Local repair |
Estimated bytes waiting for local repair, cumulative bytes repaired locally and bytes whose local repair failed, and the 95th-percentile duration of a local repair over the last hour, in milliseconds |
Repairs during reads |
Cumulative number of local repairs triggered and completed while serving a read |
Reclaimable space |
Space released by deletions and not yet returned as free space, in bytes |
Relocation |
Data groups waiting for relocation, cumulative data groups relocated and data groups that failed to relocate, cumulative bytes moved, and estimated cumulative bytes returned as free space |
What Is Not Collected¶
Scality collects only the operational metrics necessary to support your deployment and improve the product. Scality does not collect the following categories of data:
Customer data and object content: The content of objects stored in ARTESCA, including file data, application metadata, and object names, is never read or transmitted.
Personal data: Scality collects no names, email addresses, end-user IP addresses, authentication credentials, access keys, or any other personally identifiable information.
S3 access logs or request logs: Scality does not collect individual S3 API calls, request payloads, or response bodies.
Application-level metadata: Scality does not transmit bucket names, object keys, tags, user-defined metadata, or access control lists (ACLs).
Network payload content: Scality collects only traffic volume and error rate statistics. Packet content is never inspected or transmitted.
Kubernetes secrets and credentials: Scality does not collect the contents of Kubernetes Secrets, application configuration values, or any credentials stored in the deployment.
User account information: Scality does not collect ARTESCA user accounts, group memberships, IAM policies, or role assignments.
Data Transmission and Security¶
A telemetry agent running within your ARTESCA deployment collects the metrics and sends them to the Scality ingestion infrastructure using the OpenTelemetry Protocol (OTLP). All transmissions occur over an encrypted HTTPS connection. The TLS version used for encryption is TLS 1.3 or higher. No unencrypted channel is used.
Once received, telemetry data is stored on the Scality infrastructure and encrypted at rest. No plaintext metric data is stored outside of this encrypted store.
A unique ARTESCA Instance ID identifies each deployment. This identifier is not linked to any customer name, email address, or personal information. Agent identifiers are stored as derived hashes; no original identifiers are stored in plaintext.
The telemetry agent requires outbound HTTPS connectivity to https://telemetry.scality.com, the Scality
telemetry endpoint. If your deployment operates behind an outbound proxy or
firewall, you must allowlist this endpoint. When traffic leaves through a proxy,
the proxy must allow HTTPS CONNECT to telemetry.scality.com:443.
Sending Telemetry Through an Outbound Proxy¶
If your network policy requires all outbound traffic to leave through a proxy, configure it from the ARTESCA UI. A Platform Admin opens the user menu, then Maestro > External connections > Outbound proxy > Edit.
The form has these fields:
Proxy URL: the proxy address, including host and port. Supported schemes are
http://,https://,socks5://, andsocks5h://. Do not put credentials in the URL.Username and Password: optional. Leave both empty for an unauthenticated proxy.
Bypass proxy for: a comma-separated list of destinations to reach directly. Entries may be hostnames, domain suffixes such as
.corp.example.com, or CIDRs such as10.0.0.0/8. Matching is by name: a destination reached by bare IP must be listed by IP or CIDR. In-cluster destinations are always excluded.
Save applies immediately; the agent does not restart. Guardian status on the same page reflects the result within about a minute. If the proxy refuses the connection, the status reads Proxy rejected the connection and names the proxy.
Reset to startup default, in the same form, removes the UI setting.
Note
The setting is stored in the Kubernetes Secret
artesca-maestro-egress-proxy in the maestro-agent namespace. The
password is stored there in the clear, like other Secrets, and is never
returned by the UI or the API. Anyone allowed to read Secrets in that
namespace can read it.
Privacy and Compliance¶
ARTESCA telemetry does not collect personal data as defined under the General Data Protection Regulation (GDPR). Because the metrics collected are exclusively operational and infrastructure data, Scality does not act as a data processor of personal data with respect to telemetry. If your organization has specific GDPR compliance requirements, contact your Scality account team.
For more information, refer to the Privacy Policy of Scality page.
