License utilization reporting

License utilization reporting allows you to track and share license utilization data with IBM. Utilization data helps you understand deployment scale and measure compliance with the terms of your Vault Enterprise license agreement.

Vault supports two reporting methods:

• Automated reporting (recommended): Vault sends data automatically to IBM using an outbound HTTPS API call about every 24 hours.
• Manual reporting: You retrieve the license utilization data from Vault and upload it to IBM.

Your Vault Enterprise license agreement may require you to report license utilization data at a set cadence. You must meet the requirements for automated reporting or maintain an alternative process to manually report data at the agreed cadence.

Configuration options

Vault manages reporting behavior in the reporting stanza of your configuration file. Configuration options include:

• Opting out of automated license utilization reporting.
• Changing the retention period for daily snapshots.
• Marking the cluster as a development (non-production) cluster.
• Changing the license anniversary date.

Development clusters

To differentiate between production and non-production license utilization, you can set development_cluster to true, which signals to Vault that the cluster is meant for development (non-production) use.

You must comply with the terms of your Vault Enterprise license agreement when designating a cluster as a development cluster.

reporting {
  license {
    development_cluster = true
  }
}

To avoid inconsistent reporting behaviors, you must apply the same setting on all nodes in your Vault cluster and across all nodes in any Vault cluster connected through replication.

Inconsistent settings can lead to the following behaviors:

• Reporting behavior changes after leadership elections because the cluster uses the setting on the new leader node.
• After a disaster recovery failover, DR secondary clusters may begin reporting license utilization data because they start using the setting of their leader node.
• After promotion, PR secondary clusters use their own settings instead of the settings inherited from the previous primary. Clusters that become PR secondaries to the new PR primary inherit the new settings as well.

If the development_cluster setting configured for a performance replication secondary cluster differs from the value inherited from the primary cluster, the secondary cluster logs the following error to warn about the discrepancy:

"development cluster setting in config does not match that of the primary, updating to follow the primary config setting"