While 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.
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. PingDataMetrics Server normalizes and aggregates this data and makes it available through a REST API. It also generates charts for viewing the information in PingDataMetrics Server’s web interface, and both historical and current metrics are available.
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.
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
jmx-notify privilege is required to be
able to subscribe to JMX notifications.
SNMP is another standard protocol that is widely supported by monitoring software. 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.