Resource and hardware requirements
Make sure that you meet the following resource and hardware requirements for your configuration size before installing ITRS Analytics.
The required size by ITRS Analytics depends mainly on the message rate it needs to handle.
| T-shirt sizing | Message rate | ITRS Analytics entities | Indicative server range |
|---|---|---|---|
| Large | 100,000 | 250,000 | 3,000-9,000 |
| Medium | 50,000 | 125,000 | 900-3,000 |
| Small | 10,000 | 25,000 | 300-900 |
Warning
Beginning with ITRS Analytics 2.10.x,Microis intended for development use only and is not suitable for production environments.
For current Geneos customers, you can find the message rate generated by any Gateway (version 5.14.0 and later) by configuring ITRS Analytics publishing in statistics-only mode. To determine the total required message rate, add up the message rates from all Gateways that share an ITRS Analytics instance.
If you do not have these statistics, you can initially reference the sizing guidelines provided. The estimated range of the number of servers that ITRS Analytics can handle are based on certain assumptions (see below) and an analysis of existing customer Gateways.
| Indicative server range | Computation |
|---|---|
| Lower estimate | The following conservative assumptions were used:
|
| Upper estimate | Actual message rates from various customer Gateways were used. Most of these Gateways use 20-second sampling and a wide range of plugins. |
You may use these estimates as a starting point, but validate it with actual statistics from your Gateways as soon as possible, since message rates can vary significantly between different plugins.
T-shirt sizing for HA-enabled Copied
Large Copied
| Specification | Minimum requirement |
|---|---|
| ITRS Analytics entities | 250,000 |
| Messages per second limit | 100,000 |
| Messages per second target range | 50-100K |
| Indicative server range | 3,000-9,000 |
| Operating system | Linux |
| CPU |
|
| RAM |
|
| Throughput |
|
| Disks (total estimate) | SSD required. See Sample configuration for AWS EC2 handling 100k metrics/sec (large). |
Note
The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.
Medium Copied
| Specification | Minimum requirement |
|---|---|
| ITRS Analytics entities | 125,000 |
| Messages per second limit | 50,000 |
| Messages per second target range | 10-50K |
| Indicative server range | 900 - 3,000 |
| Operating system | Linux |
| CPU |
|
| RAM |
|
| Throughput |
|
| Disks (total estimate) | SSD required. See Sample configuration for AWS EC2 handling 50k metrics/sec (medium). |
Note
The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.
Small Copied
| Specification | Minimum requirement |
|---|---|
| ITRS Analytics entities | 25,000 |
| Messages per second limit | 10,000 |
| Messages per second target range | 0-10K |
| Indicative server range | 300-900 |
| Operating system | Linux |
| CPU | 34 cores |
| RAM | 80 GiB memory |
| Throughput | 3000 IOPs / 125Mbps |
| Disks (total estimate) | SSD required. See Sample configuration for AWS EC2 handling 10k metrics/sec (small). |
Note
The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.
T-shirt sizing for Non-HA Copied
Warning
Beginning with ITRS Analytics 2.10.x,Microis intended for development use only and is not suitable for production environments.
Small Copied
| Specification | Minimum requirement |
|---|---|
| ITRS Analytics entities | 25,000 |
| Messages per second limit | 10,000 |
| Messages per second target range | 0-10K |
| Indicative server range | 300-900 |
| Operating system | Linux |
| CPU | 34 cores |
| RAM | 80 GiB memory |
| Throughput | 3000 IOPs / 125Mbps |
Note
The minimum resource and hardware requirements refer to the total requested amounts across all resources. However, the preflight checks verify total resource limits to ensure they are sufficient. For more information, see Kubernetes Limits vs. Requests.
Storage considerations Copied
App installs Copied
Important
Before installing the FIX Monitor app, consider the potential storage impact and ensure that sufficient storage is provisioned. Large session volumes can lead to a significant increase in PVC size, especially in a single-node setup where PVCs share the same storage.
Embedded cluster installs Copied
The /var/lib/embedded-cluster directory, used for installation and data storage, should have at least three times the size of the airgap bundle or a minimum of 40Gi of free space for online installations. Additionally, it should not exceed 80% capacity.
Note that PVCs are stored in the /var/lib/embedded-cluster/openebs/local subdirectory, which does not reserve a specific amount of space upfront. The folder will initially use close to no space until files are actually added even when there is allocated storage space. Make sure that the total volume of your PVCs will fit within this subdirectory. For example, if you have PVCs for Timescale (100 GB) and Kafka (100 GB), the directory needs to be at least 200 GB.
When installing on an embedded cluster with limited space, you can relocate the data directory by passing the --data-dir flag with the install command. You need to specify the desired directory path using the --data-dir flag, since symlinks are currently not supported.
For example:
sudo ./[itrs-analytics] install --license license.yaml --data-dir /log/lib/obcerv-data
Once the cluster is installed, you cannot change the data directory anymore.
Additional preflight checks before Embedded Cluster installation Copied
To ensure a smooth and successful deployment of the ITRS Analytics Embedded Cluster, you can perform the following additional pre-flight checks before running the actual installation.
These checks help validate that your environment meets the required system and Kubernetes-level prerequisites.
-
Run the following command to perform a preflight validation:
sudo ./itrs-analytics install run-preflights --license license.yamlThis command validates system readiness such as network configuration, disk space, CPU/memory availability, and dependency checks.
If you are installing in an air-gapped environment, append the
--airgap-bundleflag:sudo ./itrs-analytics install run-preflights --license license.yaml --airgap-bundle itrs-analytics.airgap -
After completing the preflight, you can generate a support bundle to collect diagnostic and environment information. Run the following command:
sudo /var/lib/embedded-cluster/bin/kubectl-support_bundle /var/lib/embedded-cluster/support/host-support-bundle.yaml --v=5Note
If you used the--data-dirflag during preflight checks, replace/var/lib/embedded-clusterwith the custom path (--data-dir) you specified.
Expected errors during support bundle collection Copied
At this stage, the Embedded Cluster has not yet been installed, so some errors and warnings in the support bundle output are expected. These may include messages about missing Kubernetes resources, pods, or services.
Common expected messages:
failed to connect to Kubernetes APInamespace not foundno cluster components detected
These messages simply indicate that the cluster components are not yet deployed and can be safely ignored during this stage.
Tip
It is recommended to document these expected messages internally or in your runbook so that operators are aware and do not misinterpret them as failures.
Preflight checks for Trident-based storage Copied
This ensures that the assigned storage class meets best practices and avoids potential issues that could impact stability and performance.
-
Check the storage class associated with each workload. If the provisioner is
csi.trident.netapp.io, validate the parameters for the presence of any of the identified issues. -
The
backendTypeis set toontap-nas-economy. According to Trident documentation,ontap-nas-economyis not recommended for production. -
The
provisioningTypeis set tothin. When configured asthin, there is no strict guarantee that the requested storage will always be available. -
The
snapshotsparameter must be set tofalse. If set totrue, this setting can lead to rapid disk utilization increases, potentially reaching 100% due to snapshot storage. -
Recommended actions:
- If any of these issues are detected, update the storage class parameters accordingly.
- Consult Trident documentation for best practices on configuring backend storage.
- Monitor storage utilization closely, especially when enabling snapshots.
Preflight checks for Disk I/O performance Copied
The preflight Disk I/O performance check is designed to validate the performance of all configured storage classes using the fio (Flexible I/O Tester) benchmarking tool. The objective is to identify latency, throughput, or stability issues before they impact application workloads.
Note
This preflight check test usesfioto measure disk sync latency and IOPS (Input/Output Operations Per Second) by creating short-lived PVCs for each configured storage class. Enabling the Disk I/O Performance test can considerably extend the overall runtime of the preflight checks.
For each storage class, the test suite runs four predefined fio profiles, designed to simulate a broad range of I/O workloads:
- Random reads
- Random writes
- Single-path access patterns
- Multi-path access patterns
Each fio profile is configured to run for 60 seconds, resulting in a minimum test duration of 4 minutes per storage class (for example, 4 tests × 60 seconds x number of storage classes). The total runtime of the preflight check scales linearly with the number of configured storage classes in the environment.
Each storage class is evaluated against the following key Disk I/O performance metrics, along with their associated thresholds and severity levels.
| Metric | Warning Threshold | Error Threshold | Interpretation |
|---|---|---|---|
| Data Sync Latency (99th percentile) | > 10 ms | > 100 ms | High latency indicates potential queuing or slow disk response |
| IOPS (Read/Write Average) | < 3000 | < 2500 | Lower IOPS values suggest inadequate throughput |
| Coefficient of Variation (IOPS) | ≥ 10% | ≥ 20% | High CV suggests unstable or erratic disk performance |
Non-strict preflight mode Copied
Preflight checks for both Warning and Error levels are currently configured in a non-strict mode. This means they will not block the installation process, allowing for greater flexibility during deployment.
Enabled by default Copied
This check is enabled by default but can be optionally disabled using a flag in Advanced Settings > Preflight Settings in the KOTS Admin Console.
