Server Health and Metrics

You can configure the TIBCO Enterprise Message Service server to service HTTP(S) GET requests for the current health and metrics of the server on a dedicated port.

This feature can be used to support the health check probes in Kubernetes. For more information refer to the Kubernetes documentation.

Configure the Monitor Listen

The monitor_listen configuration property in tibemsd.conf controls the interface and port the server will service HTTP(S) health check and Prometheus metrics requests on. If this property is not set, the server will not attempt to service these type of requests. This property cannot be set dynamically.

You can use only one monitor_listen and this listen should not conflict with other server listens.

These same restrictions apply to secondary_monitor_listen which is used by a server designated as secondary in a fault tolerant pair.

Whether a monitor listen uses HTTP or HTTPS is specified in the property itself. For information on how to configure explicit TLS properties for these monitor listens, refer to the Configure HTTPS in the Server section of the TLS Protocol chapter. If any of the corresponding properties is unset, the server attempts to use the corresponding TLS property applicable to the regular server listens in its place.

Health Check Response

A requestor can check whether the server is live or ready. An OK response to a liveness request means the server is up and running. An OK response on a readiness request means the server is in the active state while a BAD response means the server is not.

Liveness requests to the server should be HTTP(S) GET requests for the path /isLive. Readiness requests to the server should be HTTP(S) GET requests for the path /isReady.

For example: http://machine:7220/isLive and http://machine:7220/isReady.

Prometheus Metrics

You can configure TIBCO Enterprise Message Service to provide Prometheus-formatted metrics over an HTTP(S) listen port. This is the same port used to service health check responses.

  • Metrics describing overall server state and the state of all queues and topics can be monitored at the path /metrics.

  • Metrics describing the overall server state can be monitored at the path /metrics/server.

  • Metrics describing the state of all queues and topics can be monitored at the paths /metrics/queues and /metrics/topics.

  • Metrics describing individual destinations can be monitored at the paths /metrics/queues/<queue name> and /metrics/topics/<topic name>. In addition to naming an individual queue or topic, you can specify a wildcard to select metrics from a group of queues or topics. This type of request would yield the same set of individual metrics but just for the matching queues or topics. See Wildcards for more information.