A platform engineering team is sizing a Cassandra cluster for an Instana self-hosted deployment monitoring 300 hosts. According to Instana sizing guidelines, which factor most directly determines the disk capacity required for the Cassandra cluster?
Select an answer to reveal the explanation.
Short Explanation and Infographic
In Instana sizing, Cassandra disk requirements scale primarily with the number of monitored hosts (which determines the volume of metric data points generated per second) and the retention period configured for that metrics data. More hosts and longer retention periods result in proportionally larger disk requirements and must both be factored into initial capacity planning. Administrative settings like dashboards or user accounts have negligible impact on datastore storage capacity.
Full explanation below image
Full Explanation
In Instana sizing, Cassandra disk requirements scale primarily with the number of monitored hosts (which determines the volume of metric data points generated per second) and the retention period configured for that metrics data. More hosts and longer retention periods result in proportionally larger disk requirements and must both be factored into initial capacity planning. Administrative settings like dashboards or user accounts have negligible impact on datastore storage capacity. The correct answer is 'The number of monitored hosts combined with the configured metrics retention period'. The incorrect options — 'The number of custom dashboards and saved queries configured by end users', 'The number of active Instana user accounts and API token holders', 'The number of alert channels and integration webhooks configured' — are wrong because they do not align with IBM Instana's architecture or recommended practices for this scenario. Understanding this concept is essential for the Domain 5: Planning domain of the IBM Instana Observability certification.