PCF Metrics v1.1

Using PCF Metrics

This topic describes how to log into, use, and interpret data from Pivotal Cloud Foundry (PCF) Metrics.

Get Started with PCF Metrics

  1. In a browser, navigate to metrics.YOUR-SYSTEM-DOMAIN and log in with your User Account and Authentication (UAA) credentials.
  2. PCF Metrics uses UAA to retrieve a list of apps that correspond to your user’s org roles, space roles, and permissions. To view metrics information for an app, enter the name of the app in the search box and select it from the dropdown menu. Search bar
  3. Select an app to display the Dashboard view. The Dashboard includes the following information:

    • The Configuration section shows the number of Instances, the Memory Limit, and the Disk Limit for the app. It also shows the URL.
    • The Recent Events section lists all events from the past day.
    • Container Metrics and Network Metrics show streaming trend lines for all metrics over the past five minutes.

    Dashboard new

  4. Select Explore from the left menu to view detailed metrics and logs. You can toggle the following:

    • Container Metrics displays CPU, memory, and disk usage.
    • Network Metrics displays HTTP requests, errors, and latency.
    • Logs displays application log data ingested from the firehose. PCF Metrics stores application log data for 24 hours.


  5. Filter your log data by entering a keyword search or selecting a log source.

  6. Determine the scope of the historical view by clicking the one minute, one hour, or one day button. Use the left and right arrow keys to navigate adjacent time slices. Metrics short

  7. Hover over either metrics graph to display a view of network and container metrics data.

    Metrics new

Interpret Metrics

PCF Metrics provides data on CPU usage, memory usage, disk usage, latency, HTTP errors, and HTTP requests. Refer to the following list for help with interpreting these metrics.

  • A spike in CPU might point to a process that is computationally heavy. Scaling app instances can relieve the immediate pressure, but investigate the app to better understand and fix the root cause.
  • A spike in memory might mean a resource leak in the code. Scaling app memory can also relieve the immediate pressure, but look for and resolve the underlying issue so that it does not occur again.
  • A spike in disk might mean the app is writing logs to files instead of STDOUT, caching data to local disk, or serializing huge sessions to disk.
  • A spike in latency means your users are waiting longer to use your app. Scaling app instances can spread that workload over more resources and result in faster response times.
  • A spike in HTTP errors means one or more 4xx or 5xx errors have occurred. Check your app logs for more information.
  • A spike in HTTP requests means more users are using your app. Scaling app instances can reduce the higher latency that may result.
Create a pull request or raise an issue on the source for this page in GitHub