Skip to main content

Styra DAS Telemetry

The Self-Hosted Styra DAS installation includes an optional service (called "inspector") to report non-sensitive, high-level telemetry data to Styra about the DAS installation. Telemetry reporting to Styra is enabled by default but can be disabled during the installation or upgrade process.

Hourly telemetry data collected by the inspector service includes high-level information about the Styra DAS installation, such as workspace-level features enabled, the number and types of systems and stacks in use, as well as system- and stack-level feature status and usage patterns. To meet customer privacy requirements, reported data is stripped of sensitive information before leaving the customer's environment and is stored in a dedicated Styra reporting environment with encryption (in-transit and at-rest), audit logging, and access controls limiting access to select Styra team members for debugging and analysis purposes.

Purpose of telemetry data​

The primary purpose for the telemetry data is to enable the Styra customer support team to provide faster and more relevant responses to support requests for Self-Hosted Styra DAS installations. The additional context this data provides when triaging support tickets reduces the amount of follow-up information customer support team members request from customers during troubleshooting and decreases the total time to ticket resolution.

Additionally, telemetry data provides Styra with an understanding of the product configuration and usage patterns, which can be used to proactively alert customers of possible issues, to identify customers for feedback on development of specific features, and to notify customers of product changes relevant to their configuration and usage.

Configuring telemetry reporting​

By default, telemetry data reported by the inspector service is not directly associated with a customer and is instead associated with the date and time of the Styra DAS installation or upgrade. For customers to receive the above benefits from telemetry reporting, add the following to your Styra DAS Helm chart values.yaml file:

telemetry:
  enabled: true
  customer: customer_name_environment

Ensure the customer parameter value clearly identifies your organization and environment (e.g., acme_production). If your organization includes multiple Self-Hosted Styra DAS installations, include a team name and environment identifier in addition to your organization name in the customer parameter value (e.g., acme_iam_team_staging).

To completely disable sharing of telemetry data with Styra for a Self-Hosted Styra DAS installation, set the enabled parameter in the telemetry section to false.

Styra telemetry endpoint​

The inspector service sends collected data on an hourly basis to the Styra telemetry endpoint: https://telemetry.styra.com:443.

For Styra DAS installation in environments which limit egress connections, the Styra telemetry endpoint will need to be whitelisted to allow the HTTP request to Styra's servers. In cases where telemetry reporting is enabled but a connection cannot be made to the Styra telemetry endpoint, the inspector service will log an internal error.

Telemetry data collected​

The hourly telemetry data collected and stripped of sensitive details by the inspector service includes:

  • Workspace-level:
    • Created and last modified timestamps
    • Number of SSO providers configured
    • Number of users assigned to each role
    • Number of active API tokens
    • Git configuration status
    • Number of active OPA and Enterprise OPA agents
    • Terraform Cloud/Enterprise run task integration configuration
    • Number of systems
    • Number of stacks
    • Number of libraries
    • Reporting errors
  • System-level:
    • ID, name, and description
    • Type and version
    • Created and last modified timestamps
    • System status (active, warning, error)
    • Git configuration status
    • Number of active OPA and Enterprise OPA agents
    • Configured minimum OPA version
    • Node count (Kubernetes systems only)
    • Decision log count, rate, and latency
    • Number of compliance violations (Kubernetes and Terraform only)
    • Number of allow, deny, enforce, monitor, ignore, notify, and test rules
    • Matching stack IDs
    • Number of active API tokens
    • Reporting errors
  • Stack-level:
    • ID, name, and description
    • Type and version
    • Created and last modified timestamps
    • Git configuration status
    • Decision log count, rate, and latency
    • Number of compliance violations (Kubernetes and Terraform only)
    • Number of allow, deny, enforce, monitor, ignore, notify, and test rules
    • Matching system IDs
    • Number of active API tokens
    • Reporting errors