Pi-hole¶

DNS-блокировщик рекламы: блокирует ли он, сколько запросов обрабатывает и блокирует, насколько устарели его списки блокировки, отказывают ли его внешние резолверы, ожидает ли обновление, и сообщения собственной страницы диагностики.

DumbMonit читает REST API Pi-hole v6 (/api). Pi-hole 5 и более ранние версии не имеют такого API и не поддерживаются.

То, что идёт не так с Pi-hole, редко заметно: DNS продолжает отвечать. Блокировка поставлена на паузу «на пять минут» и не возвращается, еженедельное обновление списков блокировки (gravity) не удавалось месяц, внешний резолвер отвечает SERVFAIL, а страницу диагностики, которую никто не открывает, всё это время указывала причину.

Что отслеживается¶

Все метрики с префиксом dumbmonit_pihole_. Pi-hole считает запросы за последние 24 часа, скользящим окном, которое то растёт, то падает: эти значения — gauge-метрики с суффиксом _24h, а не счётчики.

Метрика	Что	Метки
`blocking_enabled`	1, когда блокировка включена; 0 — когда выключена, на паузе или не удалась
`blocking_timer_seconds`	время, оставшееся до того, как блокировка на паузе сама включится снова
`queries_24h`, `queries_blocked_24h`, `queries_blocked_percent`	запросы, обслуженные и блокированные за последние 24 часа
`queries_forwarded_24h`, `queries_cached_24h`, `unique_domains_24h`	запросы, отправленные вовне, ответы из кэша, уникальные домены
`queries_per_second`	среднее за последнюю минуту
`replies_servfail_24h`	ответы SERVFAIL за последние 24 часа: отказавший внешний резолвер проявляется здесь первым
`clients_active`, `clients_total`	увиденные клиенты
`gravity_domains`	домены в списках блокировки
`gravity_last_update_timestamp_seconds`, `gravity_age_seconds`	последняя пересборка списков блокировки, и сколько времени прошло
`version_info`	значение 1	`core`, `web`, `ftl`, `docker`
`update_available`	1, когда опубликована более новая версия компонента, иначе 0; отсутствует до первого ежедневного проверки Pi-hole	`component` (`core`, `web`, `ftl`, `docker`)
`updates_available`	обновления к установке: образ в Docker (core, web и FTL идут с ним), иначе каждый устаревший компонент
`messages`, `messages_by_type`	сообщения на странице диагностики	`type` (`LOAD`, `RATE_LIMIT`, `LIST`…)
`ftl_uptime_seconds`, `ftl_memory_percent`, `ftl_cpu_percent`	демон FTL
`privacy_level`	уровень приватности Pi-hole, от 0 до 3
`scrape_errors`	второстепенные вызовы API, завершившиеся ошибкой во время последней проверки

В ветке разработки Pi-hole сравнивает коммиты, а не номера версий, и DumbMonit делает то же самое.

Применяемые встроенные правила: «Блокировка Pi-hole отключена», «Списки блокировки Pi-hole устарели», «Доступно обновление Pi-hole», «Диагностические сообщения Pi-hole», плюс «Монитор недоступен».

Страница монитора¶

Панель над графиками читает то, что сохранила проверка; открытие страницы никогда не подключается к Pi-hole. Она показывает, включена ли блокировка (и когда закончится пауза), запросы и долю блокированных за последние 24 часа, размер и возраст списков блокировки, клиентов, версии с ожидающими обновлениями, и число сообщений диагностики.

Создание пароля приложения в Pi-hole¶

Требуется Pi-hole v6 или новее: версия 5 не имела REST API. У Pi-hole нет учётной записи только для чтения; ближайший аналог — пароль приложения, который не может изменить ни одну настройку.
В веб-интерфейсе Pi-hole откройте Settings → Web interface / API и переключите страницу с Basic на Expert. Нажмите Configure app password, скопируйте показанный пароль, затем нажмите Enable new app password. Pi-hole показывает его только один раз, а новый заменяет предыдущий.
Пароль приложения остаётся доступным только для чтения настроек, пока webserver.api.app_sudo равен false, что является значением по умолчанию. Проверьте это на машине с Pi-hole (в Docker добавьте к команде префикс docker exec и имя контейнера):
```
pihole-FTL --config webserver.api.app_sudo
```
В DumbMonit введите адрес Pi-hole, например «pi.hole» или «192.168.1.53», и вставьте пароль приложения. Для Pi-hole, чей веб-интерфейс не имеет пароля, выберите вместо этого No password.
DumbMonit только читает. Он никогда не ставит блокировку на паузу и никогда не меняет список, и держит одну сессию API открытой между проверками, а не открывает новую на каждую: Pi-hole допускает до 16 сессий одновременно.

Warning

Пароль приложения всё равно позволяет ставить блокировку на паузу и редактировать списки через API: держите его только для DumbMonit. Pi-hole обслуживает обычный HTTP на порту 80, и пароль пересекает сеть каждый раз при открытии сессии: в недоверенной сети используйте HTTPS на порту 443.

Пароль приложения также входит без второго фактора, когда включена двухфакторная аутентификация: для этого он и существует. Чтобы отозвать его, очистите webserver.api.app_pwhash в Settings → All settings, либо включите новый: предыдущий перестаёт работать немедленно.

Учётные данные¶

Учётные данные	Поля
Пароль приложения	Пароль, сгенерированный выше. DumbMonit обменивает его на сессию, отправляемую в заголовке `X-FTL-SID`, и повторно использует эту сессию, пока Pi-hole её держит (30 минут с последнего использования).
Без пароля	Только для Pi-hole, чей веб-интерфейс не имеет пароля.

Адрес: имя хоста или IP (pi.hole), host:port, или полный URL (https://pi.hole); путь веб-интерфейса или API, скопированный из браузера, игнорируется. Опции: протокол (по умолчанию HTTP), порт (80), проверка сертификата (для HTTPS на 443, собственный сертификат Pi-hole самоподписан) и таймаут запроса (10 с).

Если проверки не проходят с ошибкой «no free API session», все сессии Pi-hole заняты, обычно скриптом, который входит при каждом запуске без выхода. Они истекают через 30 минут; webserver.api.max_sessions поднимает лимит.