App Metrics for Tanzu 2.2

Size App Metrics

Last Updated October 22, 2024

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.

SizePurposeApproximate number of app instances
SmallTest use100
MediumProduction use5,000
LargeProduction use15,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.