coredns/man/coredns-health.7

.\" generated with Ronn/v0.7.3
.\" http://github.com/rtomayko/ronn/tree/0.7.3
.
.TH "COREDNS\-HEALTH" "7" "August 2018" "CoreDNS" "CoreDNS plugins"
.
.SH "NAME"
\fIhealth\fR \- enables a health check endpoint\.
.
.SH "DESCRIPTION"
By enabling \fIhealth\fR any plugin that implements healt\.Healther interface \fIhttps://godoc\.org/github\.com/coredns/coredns/plugin/health#Healther\fR will be queried for it\'s health\. The combined health is exported, by default, on port 8080/health \.
.
.SH "SYNTAX"
.
.nf

health [ADDRESS]
.
.fi
.
.P
Optionally takes an address; the default is \fB:8080\fR\. The health path is fixed to \fB/health\fR\. The health endpoint returns a 200 response code and the word "OK" when this server is healthy\. It returns a 503\. \fIhealth\fR periodically (1s) polls plugins that exports health information\. If any of the plugins signals that it is unhealthy, the server will go unhealthy too\. Each plugin that supports health checks has a section "Health" in their README\.
.
.P
More options can be set with this extended syntax:
.
.IP "" 4
.
.nf

health [ADDRESS] {
    lameduck DURATION
}
.
.fi
.
.IP "" 0
.
.IP "\(bu" 4
Where \fBlameduck\fR will make the process unhealthy then \fIwait\fR for \fBDURATION\fR before the process shuts down\.
.
.IP "" 0
.
.P
If you have multiple Server Blocks and need to export health for each of the plugins, you must run health endpoints on different ports:
.
.IP "" 4
.
.nf

com {
    whoami
    health :8080
}

net {
    erratic
    health :8081
}
.
.fi
.
.IP "" 0
.
.P
Note that if you format this in one server block you will get an error on startup, that the second server can\'t setup the health plugin (on the same port)\.
.
.IP "" 4
.
.nf

com net {
    whoami
    erratic
    health :8080
}
.
.fi
.
.IP "" 0
.
.SH "PLUGINS"
Any plugin that implements the Healther interface will be used to report health\.
.
.SH "METRICS"
If monitoring is enabled (via the \fIprometheus\fR directive) then the following metric is exported:
.
.IP "\(bu" 4
\fBcoredns_health_request_duration_seconds{}\fR \- duration to process a /health query\. As this should be a local operation it should be fast\. A (large) increases in this duration indicates the CoreDNS process is having trouble keeping up with its query load\.
.
.IP "" 0
.
.P
Note that this metric \fIdoes not\fR have a \fBserver\fR label, because being overloaded is a symptom of the running process, \fInot\fR a specific server\.
.
.SH "EXAMPLES"
Run another health endpoint on http://localhost:8091\.
.
.IP "" 4
.
.nf

\&\. {
    health localhost:8091
}
.
.fi
.
.IP "" 0
.
.P
Set a lameduck duration of 1 second:
.
.IP "" 4
.
.nf

\&\. {
    health localhost:8092 {
        lameduck 1s
    }
}
.
.fi
.
.IP "" 0
.
.SH "BUGS"
When reloading, the Health handler is stopped before the new server instance is started\. If that new server fails to start, then the initial server instance is still available and DNS queries still served, but Health handler stays down\. Health will not reply HTTP request until a successful reload or a complete restart of CoreDNS\.