Skip to main content

Usage telemetry

Otterize OSS components report anonymous usage information back to the Otterize team, to help the team understand how the software is used in the community and what aspects users find useful. No personal or organizational identifying information is transmitted in these metrics: they only reflect patterns of usage. You may opt out at any time through a single configuration flag.

What information is collected?

The information reported by Otterize OSS is defined in the GraphQL schema of the telemetry source code; this is the GraphQL schema shared with the Otterize incoming-telemetry GraphQL endpoint. Usage information is sent as events, each containing the event type, sometimes also a count, and some identifiers to allow correlating multiple events in order to understand usage.

Identifiers

IdentifierValue
componentTypeWhich Otterize OSS component sent the event: one of INTENTS_OPERATOR, CREDENTIALS_OPERATOR, NETWORK_MAPPER or CLI.
componentInstanceIdA randomly-generated UUID identifying the installed instance of the component, to allow correlating its events.
contextIdA hash (for anonymity) of an identifier of the context in which the component is installed. For example, for components running in a Kubernetes cluster, this is a hash of the UUID of the kube-system namespace in the cluster.
versionThe version of the Otterize OSS component.
cloudClientIdIf connected to Otterize Cloud: the client id used to connect with Otterize Cloud, to allow correlating events with Cloud usage info.

Events

Event typeMeaning
INTENTS_DELETEDHow many intents were deleted.
INTENTS_APPLIEDHow many declared intents were applied.
INTENTS_APPLIED_KAFKAHow many intents were applied with Kafka type.
INTENTS_APPLIED_HTTPHow many intents were applied with HTTP type.
INTENTS_APPLIED_DATABASEHow many intents were applied with Database type.
INTENTS_DISCOVEREDHow many intents were discovered by the network mapper.
INTENTS_DISCOVERED_SOCKET_SCANHow many intents were discovered by the network watcher ("sniffer") via scanning for open sockets.
INTENTS_DISCOVERED_CAPTUREHow many intents were discovered by the network watcher ("sniffer") via reading DNS query responses.
INTENTS_DISCOVERED_TCPHow many intents were discovered by the network watcher ("sniffer") via reading TCP-SYN packets.
INTENTS_DISCOVERED_KAFKAHow many intents were discovered by the Kafka watcher.
INTENTS_DISCOVERED_ISTIOHow many intents were discovered by the Istio watcher.
MAPPER_EXPORT How many intents from the network mapper were exported by the CLI: otterize mapper export....
MAPPER_VISUALIZEHow many intents from the network mapper were visualized by the CLI: otterize mapper visualize....
KAFKA_SERVER_CONFIG_APPLIEDA Kafka Server Config was applied (i.e. the intents operator will recognize it as a Kafka broker).
KAFKA_SERVER_CONFIG_DELETEDA Kafka Server Config was deleted.
NETWORK_POLICIES_CREATEDHow many network policies were created by the intents operator.
NETWORK_POLICIES_DELETEDHow many network policies were deleted by the intents operator.
KAFKA_ACLS_CREATEDHow many Kafka ACLs were created by the intents operator.
KAFKA_ACLS_DELETEDHow many Kafka ACLs were deleted by the intents operator.
ISTIO_POLICIES_CREATEDHow many Istio authorization policies were created by the intents operator.
ISTIO_POLICIES_DELETEDHow many Istio authorization policies were deleted by the intents operator.
STARTEDThe operator was started.
ACTIVESent periodically to indicate that the component is still running.
SERVICE_DISCOVEREDHow many services were discovered by the network mapper.
NAMESPACE_DISCOVEREDHow many namespaces were discovered by the network mapper.
PROTECTED_SERVICE_APPLIEDHow many protected services were applied.
PROTECTED_SERVICE_DELETEDHow many protected services were deleted.

CLI Commands

For the CLI, the reported events correspond simply to the commands invoked.

Most CLI commands are of the form otterize <noun> <verb> where the <noun> is the type of object (e.g. intents, clusters) and the <verb> is the operation being performed. Otterize OSS telemetry for CLI commands only reports what <noun> and <verb> were used, never what specific identifier was used in the command, nor what was the response. For example, otterize clusters get <cluster-id> would report that clusters and get were used, without reporting <cluster-id> nor the response about that cluster. In some cases, modifiers are also reported, to clarify which specific action was taken.

FieldMeaning
<noun>The type of object on which the operation (<verb>) is being performed.
<verb>The operation performed on <noun>.
MODIFIERSIf applicable, a list of modifiers to clarify the specific operation. For example, otterize env update add-labels would report add-labels as the modifier.

Configuring whether to report usage information

To configure whether to report usage information to the Otterize team, use the telemetry flag in the installation/configuration of Otterize OSS. By default, telemetry is enabled.

To disable only the sending of usage information:

  • Via the Otterize OSS Helm chart: --set global.telemetry.usage.enabled=false.
  • Via an environment variable: OTTERIZE_TELEMETRY_USAGE_ENABLED=false.
  • If running an operator directly: telemetry-usage-enabled=false.

To disable sending any telemetry information, including both usage information and error information:

  • Via the Otterize OSS Helm chart: --set global.telemetry.enabled=false.
  • Via an environment variable: OTTERIZE_TELEMETRY_ENABLED=false.
  • If running an operator directly: telemetry-enabled=false.

If the telemetry flag is omitted or set to true, telemetry will be enabled: usage information will be reported.