Java Agent Telemetry
Telemetry and observability features are integrated into Java Agent, in order to help us better understand and analyse the performance and behavior of the product.
We collect and analyze telemetry data to provide insights into the usage patterns, performance metrics, and overall health of the Java Agent itself and the security characteristics it provides. It helps us optimize for the most common use case, as well as identify and diagnose potential issues in remote deployed scenarios. Finally, we may use the data to diagnose and troubleshoot potential issues, either proactively if we detect anomalies or reactively if you contact Support. The data is never used to train AI models.
We do not monitor the application being protected using the Java Agent, but only monitor the performance and health of the internal workings of the Java Agent itself. We only collect metrics and sanitized logs emitted by the Java Agent, and only use them to improve the agent's performance and features. We may collect information about the environment the application is running in (OS, Java version, libraries used, etc.) in order to improve our coverage of security features related to that environment. Data collected never contains any information (PII or otherwise) that your application is processing.
Telemetry data is retained only for as long as necessary to support product operation, diagnostics, and service improvement, and may be stored and processed in secure infrastructure operated by us or by authorized third-party providers. The exact storage location may vary depending on the service used and applicable deployment requirements. All telemetry is encrypted in transit using industry-standard protocols, and access is restricted to authorized personnel for operational and support purposes.
Summary of data collected
Data is collected across five key categories:
- Environment and Platform Information: Details like Agent version, Java Runtime (vendor, version, architecture), Operating System (vendor, version, architecture), and presence/version of interacting runtime libraries (e.g., logging frameworks, servlet containers).
- Application and Runtime Characteristics: Summary statistics on the monitored application, including class loading metadata (total count, origin breakdown), Java feature utilization, and high-level, anonymized resource consumption baselines (heap size, thread counts, CPU utilization).
- Agent Startup and Connectivity Diagnostics: Metrics critical for deployment diagnosis, such as startup duration (broken down by stage), anonymized configuration flags, and Portal connectivity status (success, latency, errors).
- Internal Health, Errors, and Failures: Diagnostic information for root cause analysis, including sanitized internal Agent error logs and stack traces, and snapshots of internal state at the time of error.
- Functionality Usage and Rule Application Statistics: Aggregated data on protection capability usage, including summary statistics of active ARMR applications, aggregated counts of rule triggers, and summary counts of CEF event emission.
How to opt-out from telemetry collection
Telemetry is using an open standard OpenTelemetry and is designed to be an integral part of the user experience in the Portal and Agents. Telemetry options are controlled by configuration of the Portal (Dedicated). It is currently enabled by default on the Agent side for versions 25.6.0+. This default setting ensures we have a broad and representative data set necessary for the continued improvement and security features in the Portal and Agent.
We understand that data privacy and organizational policies are paramount. If your organization prefers not to contribute telemetry data, you have the option to opt out. To request the disabling of telemetry data submission for your installation, please contact our Support team. Our team will guide you through the process to ensure your privacy preferences are respected.
How to get access to telemetry data
Agent telemetry data offers vital insights into security performance and operational status. If your organization wants to integrate these telemetry streams — including specific metrics or logs — into your existing observability stack, you should contact our support or engineering team. To facilitate this, please provide a detailed use case outlining what specific data you need (e.g., method execution times, security event counts), why you need it (e.g., performance analysis, security monitoring), and which observability tools you plan to use.
Our integration strategy is built upon industry standards, leveraging the OpenTelemetry (OTel) protocol for the robust collection, processing, and distribution of all telemetry data. This includes Metrics (time-series data like counters and gauges) and Logs (structured, detailed events). By adhering to OpenTelemetry, we ensure immediate compatibility with the vast ecosystem of modern observability tools that natively support the OTLP (OpenTelemetry Line Protocol) format. This commitment simplifies the connection process, enabling seamless integration between the Agent and your observability platform.