Поиск контейнеров в Marathon перестал отвечать или возвращает пустой результат. Причина почти всегда кроется в одном из трёх компонентов: правах доступа к хранилищу ядер (ZooKeeper), несовместимости версий Marathon и Mesos, либо устаревшем внутреннем кэше. Реже проблема на стороне сети или целостности данных в ZooKeeper. Ниже разобраны конкретные шаги диагностики и команды для восстановления работоспособности поиска.
Этот материал дополняет руководство по диагностике через метрики и шпаргалку по сетевым проблемам в контейнерах. Используйте их для комплексной проверки кластера.
Быстрая диагностика: с чего начать, если Marathon не видит контейнеры
Первичная диагностика строится на трёх контрольных точках: логи Marathon, состояние ZooKeeper и сетевая связность между компонентами. Идите по этому списку последовательно, чтобы не тратить время на догадки.
Проверка логов Marathon и Mesos
Логи содержат прямые указания на ошибку. Если Marathon запущен как системный сервис, используйте journalctl:
journalctl -u marathon -n 100 --no-pagerДля контейнеризированной установки получите логи через docker:
docker logs <marathon-container-id> --tail 100Ищите записи с кодами ответа 403 (Forbidden), сообщения о недоступности ZooKeeper или ошибки десериализации данных. Пример характерной записи при проблемах с правами:
ERROR Could not read data from ZooKeeper: KeeperErrorCode = NoAuthОшибка вида ConnectionLoss или SessionExpired указывает на сетевой разрыв между Marathon и ZooKeeper. Проверьте, что порт 2181 открыт на хосте с ZooKeeper и не блокируется файрволом. Для быстрой проверки сетевой доступности выполните с хоста Marathon:
nc -zv <zookeeper-host> 2181Диагностика хранилища ядер: доступность и целостность
ZooKeeper хранит состояние всех приложений и контейнеров Marathon. Если хранилище недоступно или данные повреждены, поиск не работает. Проверьте, жив ли ZooKeeper:
echo stat | nc localhost 2181Ответ должен содержать Mode: leader или Mode: follower. Отсутствие ответа означает, что ZooKeeper не принимает соединения. Дальше проверьте целостность данных. Подключитесь к ZooKeeper CLI и выведите корневые узлы Marathon:
zkCli.sh -server localhost:2181
ls /marathonОжидаемый вывод: узлы [state, leader, apps, tasks]. Отсутствие узла apps или tasks говорит о повреждении данных или неполной инициализации Marathon. В этом случае восстановите состояние из бэкапа ZooKeeper или переинициализируйте Marathon с чистым хранилищем.
Права доступа: как недостаток привилегий ломает поиск контейнеров
Ошибка доступа возникает, когда Marathon использует аутентификацию в ZooKeeper, но учётные данные неверны или ACL-правила запрещают чтение нужных узлов. Симптом: поиск в GUI возвращает пустой список, а в логах фиксируется KeeperErrorCode = NoAuth.
Настройка ACL в ZooKeeper для Marathon
Проверьте текущие права на корневом узле Marathon. В zkCli выполните:
getAcl /marathonВывод покажет схему аутентификации и список разрешённых субъектов. Для digest-аутентификации Marathon должен предъявлять логин и пароль, совпадающие с заданными в ACL. Пример установки минимальных прав для сервисного аккаунта marathon с паролем secret:
addauth digest marathon:secret
setAcl /marathon auth:marathon:cdrwaПрава cdrwa дают создание, удаление, чтение, запись и администрирование дочерних узлов. Для продакшена ограничьте права до rw на конкретных подузлах, если сервис-аккаунт не должен создавать новые ветки. После изменения ACL перезапустите Marathon, чтобы он переподключился с новыми учётными данными.
Если используется Kerberos, проверьте корректность keytab-файла и наличие действующего тикета. Команда klist -kt /path/to/marathon.keytab покажет принципалов в keytab. Убедитесь, что принципал совпадает с указанным в конфигурации Marathon.
Несовместимость версий: когда Marathon и хранилище ядер говорят на разных языках
Разные версии Marathon и Mesos используют разные протоколы взаимодействия с ZooKeeper. Marathon 1.5+ требует Mesos 1.4+ и ZooKeeper 3.4.8+. Установка Marathon 1.6 поверх Mesos 1.3 приведёт к ошибкам сериализации при чтении данных о контейнерах, и поиск перестанет работать.
Проверка текущих версий и план обновления
Получите версии компонентов:
marathon --version
mesos-master --versionСверьтесь с таблицей совместимости:
| Версия Marathon | Минимальная версия Mesos | Минимальная версия ZooKeeper |
|---|---|---|
| 1.4.x | 1.1.x | 3.4.6 |
| 1.5.x | 1.4.x | 3.4.8 |
| 1.6.x | 1.5.x | 3.4.10 |
| 1.7.x | 1.6.x | 3.5.5 |
Порядок обновления критичен: сначала ZooKeeper, затем Mesos-мастера и агенты, и только потом Marathon. Нарушение порядка оставляет кластер в рассогласованном состоянии. Перед обновлением сделайте снапшот ZooKeeper и дамп состояния Marathon через API:
curl -X GET http://marathon:8080/v2/apps > marathon-backup.jsonПосле обновления всех компонентов проверьте, что поиск контейнеров работает, и сверьте список приложений с бэкапом.
Кэш Marathon: почему сброс решает проблему поиска
Marathon кэширует ответы от ZooKeeper для снижения нагрузки на хранилище ядер. Кэш инвалидируется при изменениях в ZooKeeper, но при сетевых сбоях или аварийном переподключении может остаться устаревшая копия. Поиск обращается к кэшу, получает неактуальные данные и возвращает неполный или пустой результат.
Сбросьте кэш через API:
curl -X POST http://marathon:8080/v2/cache/resetОперация принудительно очищает все закэшированные записи и инициирует полную перезагрузку данных из ZooKeeper. В течение 10-30 секунд после сброса время ответа API может возрасти, так как Marathon заново наполняет кэш. Это штатное поведение, не прерывайте процесс.
Если сброс не помог, проверьте параметры кэширования в конфигурации Marathon. Опция --zk_session_timeout управляет таймаутом сессии с ZooKeeper. Слишком маленькое значение (меньше 10 секунд) приводит к частым переподключениям и рассинхронизации кэша. Рекомендуемое значение для продакшена: 20-30 секунд.
Альтернативные методы поиска: когда GUI не помощник
Пока основная проблема не решена, используйте Marathon REST API для поиска контейнеров. API работает напрямую с данными ZooKeeper, минуя GUI-слой и его кэш.
Использование Marathon API для поиска контейнеров
Базовый запрос на получение всех приложений:
curl -s http://marathon:8080/v2/apps | jq '.apps[] | {id: .id, instances: .instances, status: .tasks[].state}'Фильтрация по идентификатору приложения:
curl -s "http://marathon:8080/v2/apps?cmd=nginx" | jq '.apps[].id'Поиск по меткам (labels) - самый гибкий инструмент. Запрос возвращает все приложения с меткой environment=production:
curl -s "http://marathon:8080/v2/apps?label=environment%3Dproduction" | jq '.apps[].id'Для поиска остановленных контейнеров используйте эндпоинт задач с фильтром по статусу. Подробнее эта тема раскрыта в статье поиск и анализ остановленных контейнеров в хранилище ядер Marathon. Комбинируйте API-запросы с утилитой jq для построения сложных выборок без GUI.
API возвращает JSON. Ключевые поля для поиска: id (идентификатор приложения), cmd (команда запуска), labels (пользовательские метки), tasks[].state (статус контейнера). Используйте эти поля в параметрах запроса для точной фильтрации.
Профилактика: как избежать повторения ошибок поиска контейнеров
Настройте мониторинг логов Marathon на предмет ошибок аутентификации и потери соединения с ZooKeeper. Prometheus-экспортер Marathon отдаёт метрику marathon_zookeeper_errors_total - алерт на её рост предупредит о проблеме до того, как поиск сломается.
Создайте healthcheck-скрипт, который раз в минуту выполняет поисковый запрос через API и проверяет, что ответ содержит ожидаемое количество приложений. Пример скрипта:
#!/bin/bash
EXPECTED=12
ACTUAL=$(curl -s http://marathon:8080/v2/apps | jq '.apps | length')
if [ "$ACTUAL" -lt "$EXPECTED" ]; then
echo "Marathon search may be broken: expected $EXPECTED apps, got $ACTUAL"
exit 1
fiДокументируйте конфигурацию Marathon и ZooKeeper в системе управления конфигурациями. Фиксируйте версии компонентов, параметры подключения и ACL-правила. При аварии документация сокращает время восстановления с часов до минут. Для углублённой диагностики сетевых сбоев используйте руководство по отладке маршрутизации и шпаргалку по управлению контейнерами Docker.
Размещение Marathon на облачной инфраструктуре с гарантированной сетевой связностью снижает вероятность сбоев. Timeweb Cloud предоставляет VDS и управляемый Kubernetes с предсказуемой задержкой между узлами кластера.