PingAccess

Liveliness and responsiveness

One of the simpler methods for monitoring the performance of a PingAccess deployment is determining whether the PingAccess server is available and responsive. To help you identify the status of a server, PingAccess provides a heartbeat request endpoint.

Using the heartbeat endpoint

When the PingAccess server is running, sending a request to the /pa/heartbeat.ping endpoint (or /<Application Context Root>/pa/heartbeat.ping if you have the Use context root as reserved resource base path checkbox enabled on your PingAccess application) should return an 200 OK message. If the request times out or takes a long time to complete, the server might be overloaded or experiencing other difficulties.

We recommend that you develop a baseline for the desired response time by testing the heartbeat endpoint of your deployment at various times. This endpoint can be useful when load balancing a cluster of PingAccess server instances. Some load balancers can alter the number of requests that are sent to a particular server based on the response code received, or the responsiveness of requests that are made to the heartbeat endpoint.

Modifying the heartbeat message

You can modify the output of the heartbeat to provide performance-related information, such as CPU and memory usage, along with response times. The response metrics can help you make better auto-scaling decisions. The map size metrics can help you recognize performance issues. Learn more in Customizing the heartbeat message.

Example

The following example demonstrates the JSON response data returned after changing the heartbeat.page.json template file to show the memory, CPU, and response time.

This example contains PingAccess server metrics available from the heartbeat endpoint. You can find more information about these metrics in the Server metrics table.
Example JSON response data 
{
  "items": [
    {
      "response.statistics.window.seconds": "5",
      "response.statistics.count": "1",
      "response.time.statistics.90.percentile": "129",
      "response.time.statistics.mean": "129",
      "response.time.statistics.max":"129",
      "response.time.statistics.min": "129",
      "response.concurrency.statistics.90.percentile": "1",
      "response.concurrency.statistics.mean": "1",
      "response.concurrency.statistics.max": "1",
      "response.concurrency.statistics.min": "1",
      "cpu.load": "15.53",
      "total.jvm.memory": "500.695 MB",
      "free.jvm.memory": "215.339 MB",
      "used.jvm.memory": "285.356 MB",
      "total.physical.system.memory": "17.18 GB",
      "total.free.physical.system.memory": "278.45 MB",
      "total.used.physical.system.memory": "16.901 GB",
      "number.of.cpus": "8",
      "hostname": "jdasilva-r",
      "open.client.connections": "1",
      "number.of.applications": "11",
      "number.of.virtual.hosts": "6",
      "last.refresh.time": "1969-12-31T18:00:00.000Z"
    }
  ]
}

Server metrics table

The following table describes all the PingAccess server metrics available from the heartbeat endpoint.

In the following table, for server metrics that end in .90.percentile, the current 90 value is determined by the function calling the ProcessingStatistics.getResponseTimePercentileMs(p, '###.##') line in the heartbeat.page.json file. 90 is the default value.

You can find more information on how to edit this value in step 4 of Customizing the heartbeat message.
Server metrics
Server metrics Description

response.statistics.window.seconds

The time interval, in seconds, for the statistics report.

This is an echo of the pa.statistics.window.seconds property’s value. It provides context for the concurrency and time statistics.

response.statistics.count

The number of items considered in the heartbeat report for the time and concurrency statistics.

response.time.statistics.90.percentile

The 90th percentile response time, in milliseconds, during the statistics window.

For example, if this value is 168, then 90% of the report samples had response times below 168 milliseconds.

response.time.statistics.mean

The mean time, in milliseconds, that the PingAccess server took to respond during the statistics window.

response.time.statistics.max

The longest time, in milliseconds, that the PingAccess server took to respond during the statistics window.

response.time.statistics.min

The shortest time, in milliseconds, that the PingAccess server took to respond during the statistics window.

response.concurrency.statistics.90.percentile

The 90th percentile response concurrency during the statistics window.

For example, if this value is 124, then 90% of the report samples had response concurrency values below 124.

response.concurrency.statistics.mean

The mean number of HTTP requests that the PingAccess server processed concurrently during the statistics window.

response.concurrency.statistics.max

The maximum number of HTTP requests that the PingAccess server processed concurrently during the statistics window.

response.concurrency.statistics.min

The minimum number of HTTP requests that the PingAccess server processed concurrently during the statistics window.

cpu.load

The load on the PingAccess server’s cores as a percentage of total capacity.

total.jvm.memory

The total memory of the Java Virtual Machine (JVM).

free.jvm.memory

The free memory of the JVM.

used.jvm.memory

The used memory of the JVM.

total.physical.system.memory

The total system memory.

total.free.physical.system.memory

The free system memory.

total.used.physical.system.memory

The used system memory.

number.of.cpus

The number of cores on the PingAccess server.

hostname

The host name of the system running PingAccess.

open.client.connections

The number of clients connected to PingAccess.

number.of.applications

The number of configured applications in PingAccess.

number.of.virtual.hosts

The number of configured virtual hosts in PingAccess.

last.refresh.time

Returns the time that the PingAccess configuration was last refreshed, in ISO 8601 date format.

As indicated in the table, the values of some metrics are calculated over a configurable time window. The default statistics window is zero seconds.

To customize the statistics window period, change the value of the pa.statistics.window.seconds property in the <PA_HOME>/conf/run.properties file. Learn more in the monitoring section of the Configuration file reference.

Logging response times

By default, the audit logs record the processing time for each transaction. You can enable audit logging to identify the speed at which PingAccess processes web and API application transactions.

Depending on your logging configuration, audit logging might not log any transactions.

Example

The following example shows an entry from the default audit log, specifically the included processing times:

2019-12-15T17:23:12,192|GRmozOujPDDFct8RbtnfJw|tid:wUu9F0vDd9pZPKe4Oc5Ym_-RFCc..9r72.v8c0Y2CUA5qSpvcxKHgd7QoCp|
81 ms | 50 ms | 0 ms| servapp.ext.wal-ping.com [] /SimpleWebApi /*:3000| joe| Cookie| 127.0.0.1| GET| /SimpleWebApi/web/web.jsp| 200| | | Web-API| Root Resource| /*

Processing times are as follows:

  • Total round trip: 81 ms.

    Learn more in the AUDIT.roundTripMS audit log element.

  • Proxy round trip: 50 ms.

    Learn more in the AUDIT.proxyRoundTripMS audit log element.

  • UserInfo round trip: 0 ms.

    The total number of milliseconds PingAccess spent making a backchannel call to the OIDC UserInfo endpoint and waiting for a response. A value of 0 ms indicates that a call wasn’t made. Calls might be omitted on subsequent log entries.

You can find more information about logging in Log configuration and the elements of a log entry in Security audit logging.