While the PingDirectory server provides extensive access to monitoring information to clients or in files on the server filesystem, there is a lot of benefit to using an external mechanism for monitoring individual servers and especially for aggregating information across multiple servers.
The PingDataMetrics server collects and aggregates performance and event data from a set of PingDirectory, PingDirectoryProxy, and PingDataSync server instances. It can report the overall performance of the entire directory service, as well as of individual servers. The PingDataMetrics server normalizes and aggregates this data and makes it available through a REST API. It also generates charts for viewing the information in the server’s web interface, and both historical and current metrics are available.
The PingDirectory server offers support for StatsD endpoints that can send metrics to third-party monitoring software using a simple, well-defined protocol. Many popular monitoring products (like Splunk and DataDog) provide support for ingesting metrics using the StatsD protocol.
The PingDirectory server supports communicating with StatsD servers over TCP or UDP. It optionally supports TLS encryption when using TCP-based communication.
Java Management Extensions (JMX) is a core java framework that provides
support for publishing metrics and notifications. JMX is supported by a wide range
of monitoring software, and the
jconsole tool that is provided as
part of Java installations can also be used to interact with JMX-enabled
The PingDirectory server provides support for
publishing all monitor information as JMX MBeans. It also provides support for a JMX
alert handler that can generate a JMX notification in response to administrative
alerts that are raised within the server. The
jmx-read privilege is
required for access to monitoring data, and the
privilege is required to be able to subscribe to JMX notifications.
SNMP is another standard protocol that is widely supported by monitoring software. The PingDirectory server can act as an SNMP subagent to make selected monitoring information available for consumption by SNMP clients and monitoring software. The server can also generate SNMP traps in response to administrative alerts that are raised within the server.