LogoLogo
2.0.0
2.0.0
  • Welcome
  • Getting Started
  • Downloads
  • VerneMQ / MQTT Introduction
  • Installing VerneMQ
    • Installing on Debian and Ubuntu
    • Installing on CentOS and RHEL
    • Running VerneMQ using Docker
  • Configuring VerneMQ
    • Introduction
    • The VerneMQ conf file
    • Schema Files
    • Auth using files
    • Auth using a database
    • MQTT Options
    • MQTT Listeners
    • HTTP Listeners
    • Non-standard MQTT options
    • Websockets
    • Logging
    • Consumer session balancing
    • Plugins
    • Shared subscriptions
    • Advanced Options
    • Storage
    • MQTT Bridge
    • REST Publisher
  • VerneMQ Clustering
    • Introduction
    • Inter-node Communication
    • Dealing with Netsplits
  • Live Administration
    • Introduction
    • Inspecting and managing sessions
    • Retained messages
    • Live reconfiguration
    • Managing Listeners
    • Certificate Management
    • HTTP API
    • Tracing
    • Output Format
  • Monitoring
    • Introduction
    • $SYSTree
    • Graphite
    • Netdata
    • Prometheus
    • Health Checker
    • Status Page
  • Plugin Development
    • Introduction
    • Session lifecycle
    • Subscribe Flow
    • Publish Flow
    • Enhanced Auth Flow
    • Erlang Boilerplate
    • Lua Scripting Support
    • Webhooks
  • Misc
    • Loadtesting VerneMQ
    • Not a tuning guide
    • Change Open File Limits
  • Guides
    • A typical VerneMQ deployment
    • VerneMQ on Kubernetes
    • Loadtesting VerneMQ
    • Clustering during development
    • Not a tuning guide
    • Change Open File Limits
    • Migrating to 2.0
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Monitoring

Health Checker

The VerneMQ health checker

PreviousPrometheusNextStatus Page

Last updated 27 days ago

Was this helpful?

A simple way to gauge the health of a VerneMQ cluster is to query the /health path on the .

The health check will return 200 when VerneMQ is accepting connections and is joined with the cluster (for clustered setups). 503 will be returned in case any of those two conditions are not met. In addition to the simple /health path, the following options are available as well

  • /health/ping: Cowboy (ie. Verne) is up.

  • /health/listeners: will fail if any of the configured listeners is down or suspended

  • /health/listeners_full_cluster: will fail if any listener is down or any of the cluster nodes is offline. (you probably don't want to use this to base automated actions on the status)

With the ping or listeners option, you can configure a health check for a single node, even if it is part of a cluster.

If you want to configure any automated actions based on the health check results, you need to chose an appropriate health check path. For example, you should not use the /health check (checking for full cluster consistency) to automatically restart a single node. This is of special importance for Kubernetes deployments.

HTTP listener