Comments 6
Мне кажется, основное назначение healthcheck в докере - это управление последовательностью старта контейнеров, когда контейнеры ждут, когда подтвердится healthy статус контейнера, от которого они зависят (напр. БД). То есть это больше внутренний инструмент compose, нежели метрика. Мне бы не пришло в голову это выводить в графану.
Если бы это было единственное назначение, докеру бы не было смысла продолжать делать проверки после того, как все сервисы запустились.
В референсе к докерфайлам тоже явно написано:
The HEALTHCHECK instruction tells Docker how to test a container to check that it's still working.
Не "started working" и не "becomes ready".
К тому же, контейнер можно запустить и без compose.
Алерты нужны, чтобы кто-то в ночи проснулся и побежал на машину поднимать сервисы руками. Однако сочетание compose, healthchecks и продакшена - странное сочетание:
Healthckecks нужны, чтобы оркестратор попытался "перезапустить" unhealthy сервис через остановку текущего и запуск нового контейнера. Compose так не умеет.
В продакшене нужны удобные способы монтировать в контейнер секреты. Compose так не умеет.
Посмотрите в сторону Swarm, возможно он станет альтернативной экспортеру.
Это справедливое замечание, если говорить про идеальный мир, где оркестратор сам реагирует на проблемы, перезапускает контейнеры и снимает с человека ручную работу.
Но на практике все выглядит иначе:
Во-первых, docker-compose всё ещё активно используется в продакшене, например на выделенных серверах для бэкофис сервисов, где Kubernetes или даже Swarm избыточны по сложности и операционным затратам. Это не вопрос как правильно надо делать, а вопрос того, что реально эксплуатируется.
Во-вторых, алерты нужны не только для сценария, где кто-то проснулся и пошёл руками поднимать сервис. Они нужны, чтобы:
увидеть деградацию раньше пользователей;
понять, что автоматический рестарт не помог;
иметь историю: когда именно сервис начал вести себя нестабильно.
Healthcheck в этом случае не механизм восстановления, а сигнал состояния, и он полезен независимо от того, умеет ли оркестратор автоматически реагировать на него.
Поэтому экспортер не попытка заменить оркестратор, а инструмент наблюдаемости для тех случаев, где compose уже используется и будет использоваться дальше. Он не решает всех проблем продакшена, но делает одну конкретную вещь: даёт понятную картину состояния сервисов, а это сильно лучше, чем просто контейнер запущен.
В этом смысле экспортер и оркестратор не конкуренты, а решения для разных уровней зрелости инфраструктуры.
кажется кому-то нужен дистриб минимального кубера типа k0s и перестать пытаться сделать из докера то, для чего он не предназначен
Docker Healthcheck Exporter: как перестать дёргать Docker API на каждый scrape и наконец мониторить HEALTHCHECK