При работе со стекло хост возникают ситуации, когда стандартные настройки не дают ожидаемого результата: запросы висят, сертификаты не валидируются, балансировка распределяет нагрузку неравномерно. Цена ошибки здесь — недоступность сервиса для пользователей и потеря данных в очереди. Ожидаемый результат — стабильная маршрутизация трафика, корректная терминация TLS и предсказуемое поведение при пиковых нагрузках.
Частая ловушка — попытка применить рецепты от классических веб-серверов без учёта архитектуры стекло хост: там иная модель потоков, иное управление соединениями, иные таймауты. Необходимо сначала зафиксировать наблюдаемые симптомы, затем сопоставить их с известными паттернами поведения этой платформы, и только потом выбирать действие.
В этом справочнике собраны диагностические признаки, протоколы проверки и критерии принятия решений, применимые к типичным сценариям эксплуатации. Границы применимости — среды, где стекло хост выступает входной точкой для HTTP/HTTPS-трафика и управляет сертификатами, проксированием и балансировкой.
Распознавание ситуации: ключевые симптомы
Первый шаг — отделить симптомы платформы от симптомов приложения. Стекло хост пишет свои логи доступа и ошибок в раздел access и error соответственно; приложение пишет в свои потоки. Если в логах платформы фиксируются коды 502/503/504 — проблема в проксировании или апстримах. Если 200, но контент неверный — проблема за прокси.
Наблюдаемые признаки невалидного сертификата: браузер показывает NET::ERR_CERT_AUTHORITY_INVALID или NET::ERR_CERT_DATE_INVALID; в логах платформы — записи tls: failed to verify certificate или acme: error. Признаки таймаутов: клиент получает 504 Gateway Timeout, в логах — context deadline exceeded или upstream timeout при зафиксированном keepalive.
Признаки неравномерной балансировки: один апстрим получает 80% запросов при настроенном round-robin; в метриках — рост latency p99 на конкретном узле. Признаки перегрузки очереди: возрастает queue_depth, появляются отброшенные соединения connection refused на уровне платформы.
Дифференциальная диагностика частых симптомов
| Симптом | Причина | Что сделать |
|---|---|---|
| 502 Bad Gateway при наличии работающего апстрима | Несовпадение протокола (HTTP/1.1 vs h2c) или неверный Host-заголовок при проксировании | Проверьте настройку transport.proto и proxy_preserve_host; включите debug-лог одного запроса |
| 504 Gateway Timeout при низкой нагрузке | Keepalive на фронтенде больше, чем idle timeout на бэкенде | Выровняйте timeout.idle и keepalive_timeout; добавьте healthcheck с интервалом меньше таймаута |
| Сертификат не обновляется автоматически | ACME-челлендж не проходит из-за блокировки порта 80 или неверного DNS | Проверьте доступность .well-known/acme-challenge извне; убедитесь, что A/AAAA записи указывают на этот хост |
| Резкий скачок latency p99 на одном узле | Апстрим ушёл в GC/stop-the-world или исчерпал файловые дескрипторы | Сравните метрики GOGC/ulimit -n; настройте graceful shutdown и connection drain |
Протокол первичной проверки
Выполните действия по порядку, фиксируя результат каждого шага. Не переходите к следующему, пока не подтвердите контрольную точку.
Первичная диагностика за 5 минут
- 01Откройте логи платформы за последние 10 минут: grep -E "(502|503|504|tls|acme)" /var/log/glasshost/*.logКонтроль: Есть ли записи с кодами 5xx или ошибками TLS/ACME
- 02Проверьте статус сертификатов: glasshost cert list --expired --expiringКонтроль: Список пуст или показывает только валидные сертификаты
- 03Выполните curl -v -H "Host: ваш.домен" http://127.0.0.1:порт/healthКонтроль: Возвращается 200 OK и корректный JSON healthcheck
- 04Проверьте доступность ACME-челленджа: curl http://ваш.домен/.well-known/acme-challenge/testКонтроль: Возвращается 404 (путь существует) или токен, но не 403/500/timeout
- 05Сравните таймауты: glasshost config show | grep -E "timeout|keepalive"Контроль: frontend.idle >= backend.idle + запас 5-10 секунд
Выбор действия по наблюдаемым условиям
После первичной проверки у вас есть набор фактов. Используйте их для выбора ветки решения. Не полагайтесь на предположения — действуйте только по зафиксированным данным.
Дерево решений после первичной проверки
- В логах есть ошибки ACME / сертификаты в списке expiredЗапустите принудительное обновление: glasshost cert renew --force --domain ваш.домен; проверьте DNS и порт 80
- 504 при нормальной нагрузке, таймауты не выровненыУстановите frontend.read_timeout = backend.read_timeout + 10s; frontend.idle_timeout = backend.idle_timeout + 10s; перезагрузите конфиг
- 502 при рабочем апстриме, в логах "protocol mismatch"Явно задайте transport.proto = "h2c" или "http1.1" в соответствии с возможностями апстрима
- Неравномерная нагрузка при round-robinВключите least_conn или least_req; проверьте healthcheck interval < backend.idle_timeout
- Все проверки чистые, но клиенты жалуются на ошибкиПроблема в приложении за прокси — переключитесь на логи и метрики бэкенда
Настройка таймаутов и keepalive: причинно-следственные связи
Несовпадение таймаутов — самая частая причина 504 при низкой нагрузке. Фронтенд держит соединение открытым дольше, чем бэкенд считает его живым. Бэкенд закрывает простаивающее соединение, фронтенд пытается использовать его для нового запроса — получает RST, возвращает 504. Решение: frontend.idle_timeout должен быть строго меньше backend.idle_timeout (или равняться ему с запасом на сетевую латентность).
Аналогично для read/write таймаутов: если фронтенд ждёт ответа дольше, чем бэкенд готов ждать запроса, разрыв происходит на границе. Настройте frontend.read_timeout = backend.read_timeout + сетевой запас. Для HTTP/2 (h2c) учитывайте SETTINGS_INITIAL_WINDOW_SIZE и flow control — они влияют на эффективный таймаут передачи больших тел.
При изменении таймаутов всегда проверяйте healthcheck interval: он должен быть меньше минимального из idle_timeout, иначе healthcheck не успеет детектировать мёртвое соединение до того, как клиент попадёт на него.
Рекомендуемые соотношения таймаутов (ориентиры, проверяйте под нагрузкой)
- frontend.idle_timeout
- backend.idle_timeout - 5..10sДля HTTP/1.1 keepalive; для h2c учитывайте GOAWAY
- frontend.read_timeout
- backend.read_timeout + 5..15sЗависит от размера запросов и латентности сети
- healthcheck.interval
- < min(frontend.idle, backend.idle) / 2Чтобы детектировать разрыв до клиента
- connection_drain
- >= max(request_duration_p99) * 2Время на завершение в-flight запросов при перезагрузке
Работа с сертификатами: ACME и ручное управление
Встроенный ACME-клиент стекло хост использует HTTP-01 челлендж на порту 80. Если порт 80 заблокирован фаерволом или занят другим процессом — обновление не пройдёт. Проверьте: ss -ltnp | grep :80 должен показывать процесс стекло хост. DNS A/AAAA записи должны разрешаться в IP, на котором слушает этот процесс.
Для wildcard-сертификатов требуется DNS-01 челлендж. Платформа поддерживает провайдеров через переменные окружения (например, CLOUDFLARE_API_TOKEN). Если провайдер не настроен — wildcard не выдастся. Ручной импорт: glasshost cert import --cert /path/fullchain.pem --key /path/privkey.pem --domain \"*.example.com\". После импорта перезагрузка конфига не требуется — платформа подхватит изменения при следующем ресолве.
Отзыв сертификата: glasshost cert revoke --domain example.com --reason keycompromise. После отзыва обязательно запустите renew для получения нового. Не удаляйте файлы сертификата вручную — платформа управляет хранилищем сама.
Балансировка и healthchecks: критерии выбора стратегии
Round-robin подходит для однородных апстримов с одинаковой производительностью. Least_conn — когда апстримы разные по мощности или некоторые запросы тяжелее других. Least_req (power of two choices) — лучший компромисс для гетерогенных кластеров: выбирает два случайных узла и отправляет туда, где меньше активных запросов.
Healthcheck должен проверять не просто TCP-соединение, а бизнес-логику: эндпоинт /health, возвращающий 200 только при готовности к трафику (подключена БД, кэш прогрет, миграции применены). Интервал healthcheck — компромисс между скоростью детекта и нагрузкой на апстримы. Рекомендуемый старт: interval=10s, timeout=3s, healthy_threshold=2, unhealthy_threshold=3.
При включении connection_drain платформа перестаёт слать новые запросы на помеченный для удаления апстрим, но дожидается завершения текущих. Время дожидания задаётся параметром drain_timeout. Если запросы долгие (загрузка файлов, стриминг) — увеличьте до максимума ожидаемой длительности.
Проверка результата после изменений
После применения конфигурации или обновления сертификатов выполните контрольные измерения. Не ограничивайтесь «страница открылась» — проверяйте метрики и логи под нагрузкой.
Критерии успешного результата
- В логах платформы за 5 минут нет кодов 5xx и ошибок tls/acme
- p99 latency на /health эндпоинте не превышает базового + 20%
- Распределение запросов по апстримам соответствует выбранной стратегии (round-robin ~равно, least_conn ~пропорционально мощности)
- Сертификат валиден: openssl s_client -connect домен:443 -servername домен показывает notAfter > сейчас + 30 дней
- ACME-челлендж доступен: curl -I http://домен/.well-known/acme-challenge/ возвращает 404 (путь существует)
- При graceful reload (SIGHUP) нет разрывов активных соединений: connection_drain отработал без ошибок в логах
Эксплуатация в продакшене: рутины и триггеры эскалации
Настройте алерты на: рост 5xx > 1% за 5 минут; p99 latency > порог SLA; certificate expiry < 14 дней; queue_depth > 80% лимита; healthcheck failures > 0 на любом апстриме. Логи ротируйте ежедневно с сохранением 14 дней — достаточно для постмортема.
Плановые работы: обновление платформы — только через blue/green или canary с drain_timeout. Обновление конфига — всегда через glasshost config test и glasshost reload (graceful), никогда не перезапускайте процесс через systemctl restart без drain. Резервное копирование: экспортируйте конфиг glasshost config export > backup.yaml и хранилище сертификатов /var/lib/glasshost/certs ежедневно.
Момент прекращения самостоятельных действий: если после всех проверок 5xx не уходит, а в логах платформы нет ошибок — проблема в бэкенде или сети. Эскалируйте к команде приложения или сетевым инженерам с собранными доказательствами (логи, метрики, pcap при необходимости). Не пытайтесь «подкрутить» таймауты вслепую — это маскирует корневую причину.
FAQ
Как проверить, что ACME-челлендж проходит, не дожидаясь обновления?
Создайте временный файл в веб-руте или используйте команду glasshost acme test --domain ваш.домен — она симулирует запрос к .well-known/acme-challenge и покажет ответ сервера. Если вернётся 200/404 (путь существует) — челлендж пройдёт. 403/500/timeout — устраняйте препятствие.
Можно ли использовать стекло хост для TCP-проксирования без TLS?
Да, через раздел tcp_routes в конфиге. Укажите listen_port, upstream_address и при необходимости PROXY protocol v1/v2. Healthcheck для TCP — только connect-check. TLS passthrough также настраивается здесь: платформа не терминирует TLS, а пробрасывает SNI к апстриму.
Почему после изменения конфига reload не подхватывает новые апстримы?
Проверьте glasshost config test — если есть ошибки синтаксиса, reload их проигнорирует и продолжит работать со старой конфигураей. Логи reload пишутся в error-лог с префиксом config reload. Исправьте ошибки, снова тест, потом reload.
Как мигрировать сертификаты с другого сервера без простоя?
Импортируйте сертификаты и ключи на новом хосте командой cert import до переключения DNS. Проверьте cert list — сертификаты должны появиться со статусом valid. Переключите DNS. После распространения записей старый сервер можно выключить. ACME-аккаунт (регистрация) переносить не обязательно — платформа создаст новый при первом обновлении.
Что делать, если healthcheck проходит, но клиенты получают 502?
Healthcheck проверяет только доступность эндпоинта. 502 означает, что апстрим принял соединение, но не смог обработать запрос (упал в процессе, вернул некорректный HTTP, закрыл соединение до отправки заголовков). Включите debug-лог для одного запроса: glasshost debug request --id $(uuidgen) — он покажет полный обмен с апстримом.
Как ограничить скорость выдачи сертификатов, чтобы не попасть под rate limit Let's Encrypt?
Платформа соблюдает лимиты автоматически: не более 50 сертификатов на зарегистрированный домен в неделю, не более 5 неудачных попыток в час. Если вы управляете множеством поддоменов — используйте wildcard через DNS-01. Для тестов используйте staging ACME: glasshost config set acme.server staging — лимиты там выше, сертификаты недоверенные браузерами.
Итог: решение и границы
Алгоритм работы со стекло хост: фиксируете симптомы в логах платформы → запускаете первичный протокол за 5 минут → по результатам выбираете ветку решения через дерево решений → применяете изменение с выровненными таймаутами и проверенными сертификатами → подтверждаете результат чек-листом. Границы: не лечим сетевые проблемы, код приложения, отсутствие WAF-функционала и кластерного service discovery. В этих случаях собирайте доказательства и эскалируете к ответственным командам.