You can configure App Metrics depending on your deployment size. Use the information in this topic to optimize App Metrics for high capacity, to reduce resource usage for smaller deployment sizes, and to scale your overall deployment.
If you are not familiar with App Metrics components, see App Metrics architecture before you continue with this topic.
App Metrics depends on these datastores:
- Metric Store
- Log Store
- Postgres database
The Log Store and Postgres datastores are part of the App Metrics tile, and their scaling is discussed in more detail later in this topic. Metric Store datastore is separate.
Scaling the metrics datastore
App Metrics retrieves metrics from Metric Store, which has its own configuration for resizing. For information, see the Metric Store documentation.
Currently, VMware recommends that you scale vertically rather than horizontally. See Limitations in the Metric Store documentation.
Suggested sizing by deployment size
Use the following tables as a guide to configure your resources for deployment.
Estimate the size of your deployment according to how many apps you expect to deploy.
| Size | Purpose | Approximate number of app instances |
|---|---|---|
| Small | Test use | 100 |
| Medium | Production use | 5,000 |
| Large | Production use | 15,000 |
Metrics App — App Metrics deploys the app, appmetrics. This app is responsible for serving the UI, relaying proxy requests from the browser to Metric Store and Log Store, and creating notifications for the user-created monitors.
Scale the appmetrics app to one instance.
Deployment resources for a small deployment
Use the following example resource configuration to store approximately six weeks of data for a small deployment and about 100 application instances:
| Job | Instances | Persistent Disk Type | VM Type |
|---|---|---|---|
| PostgreSQL | 1 (not configurable) | 10 GB | CPU Optimized with 4 or more CPUs and 8 GB or more memory. |
| Log Store | 3 | 200 GB | Memory Optimized with 2 or more CPUs and 16 GB or more memory. |
Deployment resources for a medium deployment
Use the following example resource configuration to store approximately six weeks of data for a medium deployment and about 5000 application instances:
| Job | Instances | Persistent Disk Type | VM Type |
|---|---|---|---|
| PostgreSQL | 1 (not configurable) | 10 GB | CPU Optimized with 8 or more CPUs and 16 GB or more memory. |
| Log Store | 3 | 500 GB | Memory Optimized with 4 or more CPUs and 32 GB or more memory. |
Deployment resources for a large deployment
Use the following example resource configuration to store approximately six weeks of data for a large deployment and about 15,000 application instances:
| Job | Instances | Persistent Disk Type | VM Type |
|---|---|---|---|
| PostgreSQL | 1 (not configurable) | 10 GB | CPU Optimized with 8 or more CPUs and 16 GB or more memory. |
| Log Store | 6 | 500 GB | Memory Optimized with 8 or more CPUs and 64 GB or more memory. |
Scaling the Log datastore
App Metrics retrieves logs from the Log Store.
By default, App Metrics ships with three extra large VMs with 500 GB of persistent disk. You configure them in App Metrics tile Resource Config.
The scaling of an individual log-store deployment is subject to many variables, including:
- Required retention time
- Replication factor
- Log ingress volume
- The average size of log messages
Horizontally scaling in Log Store currently results in data loss. To ensure the best possible results, practice vertical scaling.
Scaling considerations
Scale baseline
6x VMs at 8 core, 64 GB RAM, 500 GB persistent disk provides approximately 42 days of log retention for an environment emitting 40,000 logs per second.
Scale recommendations
Maximum ingress throughput is primarily dependent on the number of VMs, with secondary consideration of CPU and Memory resources. Retention and Replication Factor primarily depends on the size of persistent disks attached to the VMs. Abnormally high cardinality of indexed information, for example, source_id and instance_id can place pressure on VM Memory. This is possible even in the absence of high log volume.
Content feedback and comments