Resource Utilization Tracking

The information refers to the Apprenda Platform’s Resource Utilization Tracking capabilities.  By default, at installation time this capability is turned off. To activate Resource Utilization Tracking, set the PhysicalHost.TrackUtilization Registry setting to True.

Also note that Resource Utilization Tracking is not automatically enabled when Resource Throttling is enabled. See more information on Resource Throttling and Resource Policies.

Resource utilization information is only available for Kubernetes workloads if Heapster has been configured an attached cluster and the URL provided to the Platform in the SOC. Additionally, Kubernetes workloads are measured in fractions of cores to more accurately reflect how Kubernetes tracks utilization.


Resource allocation and utilization tracking on the Apprenda Platform is designed to give Platform Administrators the real-time knowledge they need to make informed capacity-planning decisions based on actual resource utilization as consumed by guest applications within the structure of resource policies offered to Development Teams.  Likewise, the same metrics as seen through the lens of the Development Teams enable Developers to track and make better use of the resources they consume.  In the end, the data offered by the Apprenda Platform allows the Platform Administrator and Development Teams to jointly maximize efficient use of the Platform infrastructure.

Platform Scope

Platform-wide metrics assist the Platform Administrator with such things as capacity planning, Resource Policy creation, and troubleshooting across all applications and Development Teams.  For example, the Platform Administrator may look at data indicating that there are a large number of Sandboxed applications, and in anticipation of those application being published by Development Teams, the Admin may add resources to the Platform infrastructure.  Likewise, the Platform Administrator may use Resource Policy assignment / actual utilization differentials to recognize that applications deployed to the Platform can operate within smaller resource slices.  Armed with this information, the Platform Administrator can adjust the resource allocation policies offered to Development Teams.

Published application versions

  • Total Published application versions
  • Published applications per Development Team
  • Published frontend components (allocation, potential utilization)
  • Published web service components (allocation, potential utilization)
  • Active frontend workloads (utilization)
  • Active web service workloads (utilization)

Sandboxed application versions

  • Total Sandboxed application versions
  • Sandboxed applications per Development Team
  • Sandboxed frontend components (allocation, potential utilization)
  • Sandboxed web service components (allocation, potential utilization)
  • Active frontend workloads (utilization)
  • Active web service workloads (utilization)

Resource Assignment and Allocation

  • Platform-wide CPU assignment (potential CPU utilization) 
  • Platform-wide memory assignment (potential memory utilization)
  • Platform-wide CPU allocation (active CPU allocation)
  • Platform-wide memory allocation (active memory allocation)
  • Platform-wide CPU utilization (utilization)
  • Platform-wide memory utilization (utilization)
  • Platform-wide assignment/allocation differential
  • Platform-wide assignment/utilization differential

Error Logging

  • Total Errors
  • Errors by application version
  • Errors by server
  • Errors by code source
  • Errors by Development Team
  • Errors by Tenant (if known)  

Development Team Scope

Metrics visible to Development Teams assist Developers in making Resource Policy assignment decisions, monitoring actual resource utilization, and troubleshooting application errors.  For example, by monitoring CPU utilization of a specific application component, a Development Team may identify resource bottlenecks in their application, leading to the assignment of a larger Resource Policy allocation or code optimization resulting in smaller resource requirements.

Published application versions

  • Published web app components
  • Published web service components
  • Published web app workloads
  • Published web service workloads

Sandboxed application versions

  • Sandboxed web app components
  • Sandboxed web service components
  • Sandboxed web app workloads
  • Sandboxed web service workloads

Error Logging

  • Total Errors
  • Errors by application version
  • Errors by code source
  • Errors by Tenant (if known)

Resource Assignment and Allocation

  • Total resource assignment
  • Resource assignment to Published app components
  • Resource assignment per application version
  • Total resource allocation
  • Resource allocation to Published app workloads
  • Resource allocation per application version
  • Resource assignment / allocation differential

Resource Utilization

  • Average CPU utilization across all apps
  • Average memory utilization across all apps
  • Average CPU utilization per frontend workload
  • Average CPU utilization per web service workload
  • Average memory utilization per frontend workload
  • Average memory utilization per web service workload
  • Resource allocation / utilization differential

The Apprenda Platform Allocation Reporting API

When the Platform has workload throttling enabled, a web service called the Allocation Reporting API will provide data about the various workloads being distributed across the Platform’s servers.  This web service can be reached using SOAP or REST.  The real-time information is extremely useful to Platform Admins in scenarios where they can act on this allocation information.  For example, using the data available from this API, Platform Administrators can discover when individual application components are deployed as workloads on servers, how long they run, and when they shut down.  Using data from attached Resource Policies, this information tells Admins precisely how much of their entire Platform infrastructure is allocated for use by guest applications at any queried time.

With the information available through this API, a Platform Administrator can integrate with existing reporting systems or construct helpful external applications, such as the simplistic reporting example here:

Notice the information captured in this report:

  • Application
  • Application version
  • Developer
  • Application component (frontend or service)
  • Deployment time
  • Undeployment time
  • Attached Resource Policy
    • Memory
    • CPU
    • CPU Cores

Additionally, if chargeback costs are associated with Resource Policies, this information can be used to calculate running time for specific application components, which is helpful in calculating chargeback amounts for Development Teams.


You can find an example of the API described above on our support website.