lekss361/gendesign

Fork 0

Poincare не отвечает с 00:41 МСК — продукты лежат девять часов, и об этом никто не узнал #3119

New issue

Closed

opened 2026-08-27 06:58:51 +00:00 by lekss361 · 2 comments

lekss361 commented

2026-08-27 06:58:51 +00:00

Owner

Обнаружено 27.08 в 09:57 МСК при плановой проверке. Требуется владелец: восстановление идёт через панель Selectel (OTP на почту), доступа у меня нет.

Что происходит

gendsgn.ru и meraocenka.ru не отвечают — таймаут, не ошибка. Инфраструктура на Beget (git, errors, metrics) работает нормально.

Когда именно

Событие	Время
Последняя строка лога с хоста	26.08 00:37:27 МСК
Последняя метрика с хоста	26.08 00:41:00 МСК
Обнаружено	27.08 09:57 МСК
Простой на момент записи	9 часов 16 минут

Хост не «закрыт снаружи» — он замолчал целиком

Это главное отличие от #3110, где адрес был недоступен российским операторам, но машина работала.

Агент Alloy на Poincare отправляет метрики и логи исходящим соединением на Beget. Если бы машина работала, а был отрезан только вход, поток продолжал бы идти. Он оборвался ровно в ту же минуту, что и всё остальное.

Проверено с Beget (не с моей машины — чтобы исключить местный маршрут):

ping 188.246.224.93   → 4 пакета, 100 % потерь
TCP 22                → недоступен
HTTPS до продуктов    → таймаут

Час до этого тот же замер с той же машины давал RTT 17.5 мс и 0 % потерь (см. #3032).

Провайдер при этом доступен — дело в самой виртуалке

s3.ru-1.storage.selcloud.ru → 403 за 0.16 с

Хранилище Selectel в том же регионе ru-1 отвечает с Beget мгновенно. Значит, это не «Selectel недоступен из России» и не повтор #3110, а отказ конкретной машины.

Последние слова: обрыв на полуслове

Логи за минуты до пропажи совершенно здоровые — /health 200 OK, штатный чекпоинт Postgres, celery-задачи по расписанию, обычный шум [UFW BLOCK] от сканеров.

Поиск по всему окну (21:00–07:00 UTC) не нашёл ни одной строки со shutdown, reboot, panic, OOM, systemd Stopping. Машина не выключалась и не была убита нехваткой памяти — она оборвалась мгновенно. Так выглядит пропажа питания, падение гипервизора или отключение от сети на его стороне.

Почему никто не узнал — и это отдельный вывод

Проверил цепочку оповещения, ни одно звено не работает:

Звено	Состояние
Задание uptime в кроне (`ops/uptime-healthcheck.sh`)	не заведено ни у `gendesign`, ни у `root`
`/etc/default/gendesign-uptime`	файла нет
Отдельный сервис слежения за доступностью	нет
Alertmanager	не запущен — профиль `alerts` выключен, ждёт секретов Telegram (#3078)
`notify()` в бэкап-скриптах	no-op: `TELEGRAM_BOT_TOKEN`/`CHAT_ID` не заданы ни в одном из env-файлов (#2203)

Правила в Prometheus есть, метрики собираются, простой в них виден идеально — но вердикту некуда уйти. Мониторинг увидел аварию и промолчал.

Ровно этот разрыв я описал вчера в #2203 как «механизм есть, доставки нет». Он перестал быть теоретическим через несколько часов.

Что нужно от владельца

Панель Selectel — состояние виртуальной машины, консоль, при необходимости перезапуск. Это единственный путь: SSH недоступен.
Если машина не поднимается — обращение в поддержку; заодно вопрос о замене адреса из #3110 закрывается сам собой.

Что можно сделать, чтобы это не повторилось молча

Поднять Alertmanager: нужны METRICS_TELEGRAM_BOT_TOKEN и METRICS_TELEGRAM_CHAT_ID в секретах Actions (#3078). Правило «хост не шлёт метрики N минут» — то самое, что сработало бы здесь.
Завести проверку доступности вне обоих хостов: сегодня наблюдатель на Beget, и он аварию увидел, но сказать не смог.
Заполнить TELEGRAM_* в /etc/default/gendesign-backup — оживит и бэкапные оповещения (#2203).

Данные для разбора

Метрики и логи Poincare сохранились на Beget до последней секунды — Loki и Prometheus переживают отказ наблюдаемого хоста, ровно как задумывалось при выборе площадки для мониторинга (#3078). Разбор возможен даже если машина не вернётся.

Refs #3110, #3078, #2203, #2989

Обнаружено 27.08 в 09:57 МСК при плановой проверке. **Требуется владелец: восстановление идёт через панель Selectel (OTP на почту), доступа у меня нет.** ## Что происходит `gendsgn.ru` и `meraocenka.ru` не отвечают — таймаут, не ошибка. Инфраструктура на Beget (`git`, `errors`, `metrics`) работает нормально. ## Когда именно | Событие | Время | |---|---| | Последняя строка лога с хоста | **26.08 00:37:27 МСК** | | Последняя метрика с хоста | **26.08 00:41:00 МСК** | | Обнаружено | 27.08 09:57 МСК | | Простой на момент записи | **9 часов 16 минут** | ## Хост не «закрыт снаружи» — он замолчал целиком Это главное отличие от #3110, где адрес был недоступен российским операторам, но машина работала. Агент Alloy на Poincare отправляет метрики и логи **исходящим** соединением на Beget. Если бы машина работала, а был отрезан только вход, поток продолжал бы идти. Он оборвался ровно в ту же минуту, что и всё остальное. Проверено с Beget (не с моей машины — чтобы исключить местный маршрут): ``` ping 188.246.224.93 → 4 пакета, 100 % потерь TCP 22 → недоступен HTTPS до продуктов → таймаут ``` Час до этого тот же замер с той же машины давал RTT 17.5 мс и 0 % потерь (см. #3032). ## Провайдер при этом доступен — дело в самой виртуалке ``` s3.ru-1.storage.selcloud.ru → 403 за 0.16 с ``` Хранилище Selectel в том же регионе `ru-1` отвечает с Beget мгновенно. Значит, это не «Selectel недоступен из России» и не повтор #3110, а отказ конкретной машины. ## Последние слова: обрыв на полуслове Логи за минуты до пропажи совершенно здоровые — `/health 200 OK`, штатный чекпоинт Postgres, celery-задачи по расписанию, обычный шум `[UFW BLOCK]` от сканеров. Поиск по всему окну (21:00–07:00 UTC) не нашёл **ни одной** строки со `shutdown`, `reboot`, `panic`, `OOM`, `systemd Stopping`. Машина не выключалась и не была убита нехваткой памяти — она оборвалась мгновенно. Так выглядит пропажа питания, падение гипервизора или отключение от сети на его стороне. ## Почему никто не узнал — и это отдельный вывод Проверил цепочку оповещения, ни одно звено не работает: | Звено | Состояние | |---|---| | Задание uptime в кроне (`ops/uptime-healthcheck.sh`) | **не заведено** ни у `gendesign`, ни у `root` | | `/etc/default/gendesign-uptime` | файла нет | | Отдельный сервис слежения за доступностью | нет | | Alertmanager | **не запущен** — профиль `alerts` выключен, ждёт секретов Telegram (#3078) | | `notify()` в бэкап-скриптах | no-op: `TELEGRAM_BOT_TOKEN`/`CHAT_ID` не заданы ни в одном из env-файлов (#2203) | Правила в Prometheus есть, метрики собираются, простой в них виден идеально — но вердикту некуда уйти. Мониторинг увидел аварию и промолчал. Ровно этот разрыв я описал вчера в #2203 как «механизм есть, доставки нет». Он перестал быть теоретическим через несколько часов. ## Что нужно от владельца 1. **Панель Selectel** — состояние виртуальной машины, консоль, при необходимости перезапуск. Это единственный путь: SSH недоступен. 2. Если машина не поднимается — обращение в поддержку; заодно вопрос о замене адреса из #3110 закрывается сам собой. ## Что можно сделать, чтобы это не повторилось молча - Поднять Alertmanager: нужны `METRICS_TELEGRAM_BOT_TOKEN` и `METRICS_TELEGRAM_CHAT_ID` в секретах Actions (#3078). Правило «хост не шлёт метрики N минут» — то самое, что сработало бы здесь. - Завести проверку доступности **вне** обоих хостов: сегодня наблюдатель на Beget, и он аварию увидел, но сказать не смог. - Заполнить `TELEGRAM_*` в `/etc/default/gendesign-backup` — оживит и бэкапные оповещения (#2203). ## Данные для разбора Метрики и логи Poincare **сохранились на Beget** до последней секунды — Loki и Prometheus переживают отказ наблюдаемого хоста, ровно как задумывалось при выборе площадки для мониторинга (#3078). Разбор возможен даже если машина не вернётся. Refs #3110, #3078, #2203, #2989

lekss361 commented

2026-08-27 07:02:11 +00:00

Author

Owner

Причина установлена: это не отказ машины, а замена адреса в 00:37 — ОС о ней не знает

Поддержка Selectel прислала новый адрес, и время сообщения — 00:37 — совпадает с моментом, когда хост замолчал (последняя строка лога 00:37:27 МСК). Совпадение до минуты, случайностью быть не может.

Шлюз по умолчанию     – 188.124.37.1
Маска подсети         – 255.255.255.0
Широковещательный     – 188.124.37.255
Адрес подсети         – 188.124.37.140/32
VRRP                  – 188.124.37.254, 188.124.37.253

Версию «упало питание / рухнул гипервизор» из шапки снимаю: обрыв на полуслове без единой строки о выключении объясняется проще — у машины сменили адрес на стороне провайдера, а внутри ОС остался прежний.

Замер, который это доказывает

С Beget по новой подсети:

Адрес	Ответ
`188.124.37.254` (VRRP)	отвечает, 0 % потерь
`188.124.37.10` (сосед)	отвечает, 0 % потерь
`188.124.37.100` (сосед)	отвечает, 0 % потерь
`188.124.37.140` (наш новый)	молчит, 100 % потерь
`188.246.224.93` (наш старый)	молчит, 100 % потерь

Новый сегмент жив и маршрутизируется — отвечают и VRRP, и соседи. Не отвечает ровно один адрес: наш. То есть порт переключён в новую подсеть, а сетевая настройка внутри системы по-прежнему держит 188.246.224.93 — адрес, которого на этом порту больше нет. Машина работает, но говорить ей нечем: пакеты уходят с адреса, который сегменту чужой.

Это же объясняет и то, что оборвался исходящий поток метрик, и отсутствие следов выключения в журнале.

Что нужно сделать — и почему только владелец

SSH недоступен по определению: чинить нужно ровно ту связность, через которую мы бы подключались. Остаётся консоль в панели Selectel (VNC/KVM), а это OTP на почту.

Шаг 1. Консоль → прописать новый адрес. Интерфейс eth0 (подтверждён по журналу). Основной вариант — по присланной маске:

network:
  version: 2
  ethernets:
    eth0:
      addresses: [188.124.37.140/24]
      routes:
        - to: default
          via: 188.124.37.1

Если шлюз так не заработает, вариант Selectel для «одиночного» адреса — 188.124.37.140/32 плюс on-link: true у маршрута по умолчанию. DNS-серверы оставить прежние.

Шаг 2. Проверка — с Beget пингом и curl по --resolve, до правки DNS. Скажу сразу, как адрес отзовётся.

Шаг 3. DNS. Сейчас все пять записей смотрят на старый адрес:

gendsgn.ru · www.gendsgn.ru · meraocenka.ru · merahome.ru · meraotsenka.ru → 188.246.224.93

Менять на 188.124.37.140 в панели Beget (зона на ns1/ns2.beget.com). TTL уже 300 секунд — распространение займёт минуты, специально понижать ничего не нужно. Задача #3027 про понижение TTL этим фактически закрыта.

После подъёма — не забыть

mobileproxy.space: в кабинете привязан egress-IP 46.173.16.127, но при переезде браузерного скрапинга туда поедет новый адрес (#3059).
Секрет DEPLOY_HOST в Actions — если в нём адрес, а не имя.
Правила ufw и fail2ban на Beget, знающие старый адрес.
Проба НСПД и ДОМ.РФ: смена адреса с высокой вероятностью снимает оба бана (#2956, #2443) — но с брейкером, как договаривались.

Вывод о молчании остаётся в силе

Замена адреса была ожидаемой и согласованной, но продукты пролежали девять с лишним часов без единого сигнала. Ни uptime-проверки, ни Alertmanager'а, ни доставки в Telegram — раздел «Почему никто не узнал» в шапке не теряет актуальности от того, что причина оказалась безобидной.

## Причина установлена: это не отказ машины, а замена адреса в 00:37 — ОС о ней не знает Поддержка Selectel прислала новый адрес, и время сообщения — **00:37** — совпадает с моментом, когда хост замолчал (последняя строка лога **00:37:27 МСК**). Совпадение до минуты, случайностью быть не может. ``` Шлюз по умолчанию – 188.124.37.1 Маска подсети – 255.255.255.0 Широковещательный – 188.124.37.255 Адрес подсети – 188.124.37.140/32 VRRP – 188.124.37.254, 188.124.37.253 ``` Версию «упало питание / рухнул гипервизор» из шапки **снимаю**: обрыв на полуслове без единой строки о выключении объясняется проще — у машины сменили адрес на стороне провайдера, а внутри ОС остался прежний. ### Замер, который это доказывает С Beget по новой подсети: | Адрес | Ответ | |---|---| | `188.124.37.254` (VRRP) | **отвечает**, 0 % потерь | | `188.124.37.10` (сосед) | **отвечает**, 0 % потерь | | `188.124.37.100` (сосед) | **отвечает**, 0 % потерь | | **`188.124.37.140` (наш новый)** | **молчит**, 100 % потерь | | `188.246.224.93` (наш старый) | молчит, 100 % потерь | Новый сегмент жив и маршрутизируется — отвечают и VRRP, и соседи. Не отвечает ровно один адрес: наш. То есть порт переключён в новую подсеть, а сетевая настройка внутри системы по-прежнему держит `188.246.224.93` — адрес, которого на этом порту больше нет. Машина работает, но говорить ей нечем: пакеты уходят с адреса, который сегменту чужой. Это же объясняет и то, что оборвался исходящий поток метрик, и отсутствие следов выключения в журнале. ### Что нужно сделать — и почему только владелец SSH недоступен по определению: чинить нужно ровно ту связность, через которую мы бы подключались. Остаётся **консоль в панели Selectel** (VNC/KVM), а это OTP на почту. **Шаг 1. Консоль → прописать новый адрес.** Интерфейс `eth0` (подтверждён по журналу). Основной вариант — по присланной маске: ```yaml network: version: 2 ethernets: eth0: addresses: [188.124.37.140/24] routes: - to: default via: 188.124.37.1 ``` Если шлюз так не заработает, вариант Selectel для «одиночного» адреса — `188.124.37.140/32` плюс `on-link: true` у маршрута по умолчанию. DNS-серверы оставить прежние. **Шаг 2. Проверка** — с Beget пингом и `curl` по `--resolve`, до правки DNS. Скажу сразу, как адрес отзовётся. **Шаг 3. DNS.** Сейчас все пять записей смотрят на старый адрес: ``` gendsgn.ru · www.gendsgn.ru · meraocenka.ru · merahome.ru · meraotsenka.ru → 188.246.224.93 ``` Менять на `188.124.37.140` в панели Beget (зона на `ns1/ns2.beget.com`). **TTL уже 300 секунд** — распространение займёт минуты, специально понижать ничего не нужно. Задача #3027 про понижение TTL этим фактически закрыта. ### После подъёма — не забыть - `mobileproxy.space`: в кабинете привязан egress-IP `46.173.16.127`, но при переезде браузерного скрапинга туда поедет новый адрес (#3059). - Секрет `DEPLOY_HOST` в Actions — если в нём адрес, а не имя. - Правила ufw и fail2ban на Beget, знающие старый адрес. - Проба НСПД и ДОМ.РФ: смена адреса с высокой вероятностью снимает оба бана (#2956, #2443) — но с брейкером, как договаривались. ### Вывод о молчании остаётся в силе Замена адреса была ожидаемой и согласованной, но продукты пролежали **девять с лишним часов** без единого сигнала. Ни uptime-проверки, ни Alertmanager'а, ни доставки в Telegram — раздел «Почему никто не узнал» в шапке не теряет актуальности от того, что причина оказалась безобидной.

lekss361 commented

2026-08-27 08:18:21 +00:00

Author

Owner

Восстановлено. Простой — 10 ч 15 мин, данные целы

Причина подтвердилась полностью: Selectel переключил порт в новую подсеть, в ОС остался прежний адрес. Чинилось ровно тем способом, который назвала поддержка — режимом Rescue, без переустановки.

Что сделано

Rescue. В панели: шаблон загрузки Boot to Rescue, публичный IP 188.124.37.140, перезагрузка. Rescue поднялся на новом адресе за ~2.5 минуты (17.8 мс с Beget, потерь нет).
Диагноз подтверждён глазами. /etc/netplan/50-cloud-init.yaml на смонтированном корне держал 188.246.224.93/24 и шлюз 188.246.224.1. Сам rescue при этом жил на 188.124.37.140/24 — отсюда же и подтверждение, что маска именно /24, а не /32 из письма.
Правка. RAID1 (md127, 925 ГБ) собрался сам, смонтирован, файл переписан на новый адрес и шлюз, старый сохранён рядом как .bak-20260827. Дополнительно network: {config: disabled} в cloud.cfg.d — иначе cloud-init мог вернуть старое значение на ближайшей загрузке.
Проверка ДО перезагрузки. netplan generate в chroot отработал без ошибок и выдал корректный юнит networkd (Address=188.124.37.140/24, Gateway=188.124.37.1, привязка по MAC сохранена). Это и был смысл шага: синтаксическая ошибка стоила бы второго круга rescue.
Чистое размонтирование, возврат на Boot default, перезагрузка.

Состояние после подъёма

Проверка	Результат
Контейнеры	21 из 21 подняты, ни одного упавшего
Postgres (оба кластера)	`healthy` — журнал отыгран без потерь
Домены продуктов	отвечают все пять
С машины владельца (российский провайдер)	открываются, страницы по 70 КБ
Инфраструктура на Beget	не пострадала

DNS переведён на новый адрес у всех пяти записей продуктов; git, errors, metrics, obsidian, garmin намеренно оставлены на 46.173.16.127.

Побочный итог: #3110 закрывается сам

Старый адрес был недоступен российским операторам — ровно из-за этого и заказывали замену. Новый адрес фильтрации не имеет: сайты открываются напрямую с машины владельца, без VPN. Проверено после переключения DNS.

Что осталось

Пароль root светился в панели и в рабочей переписке — после переезда его стоит сбросить (парольный вход в боевой ОС и так выключен, но гигиена).
ops/selectel-ci-access.sh:171 — дефолт HOST_IP всё ещё старый адрес; поправлю отдельным PR вместе с комментариями в caddy/sites/*.caddy и docker-compose.prod.yml.
mobileproxy.space: egress-IP в кабинете по-прежнему привязан к Beget (#3059).
Проба НСПД и ДОМ.РФ на новом адресе — с брейкером, как договаривались (#2956, #2443).

Раздел «Почему никто не узнал» остаётся открытым вопросом и вынесен в #3078/#2203: авария была штатной по причине, но десять часов молчания — нет.

## Восстановлено. Простой — 10 ч 15 мин, данные целы Причина подтвердилась полностью: Selectel переключил порт в новую подсеть, в ОС остался прежний адрес. Чинилось ровно тем способом, который назвала поддержка — режимом Rescue, без переустановки. ### Что сделано 1. **Rescue.** В панели: шаблон загрузки `Boot to Rescue`, публичный IP `188.124.37.140`, перезагрузка. Rescue поднялся на новом адресе за ~2.5 минуты (17.8 мс с Beget, потерь нет). 2. **Диагноз подтверждён глазами.** `/etc/netplan/50-cloud-init.yaml` на смонтированном корне держал `188.246.224.93/24` и шлюз `188.246.224.1`. Сам rescue при этом жил на `188.124.37.140/24` — отсюда же и подтверждение, что маска именно `/24`, а не `/32` из письма. 3. **Правка.** RAID1 (`md127`, 925 ГБ) собрался сам, смонтирован, файл переписан на новый адрес и шлюз, старый сохранён рядом как `.bak-20260827`. Дополнительно `network: {config: disabled}` в `cloud.cfg.d` — иначе cloud-init мог вернуть старое значение на ближайшей загрузке. 4. **Проверка ДО перезагрузки.** `netplan generate` в chroot отработал без ошибок и выдал корректный юнит networkd (`Address=188.124.37.140/24`, `Gateway=188.124.37.1`, привязка по MAC сохранена). Это и был смысл шага: синтаксическая ошибка стоила бы второго круга rescue. 5. Чистое размонтирование, возврат на `Boot default`, перезагрузка. ### Состояние после подъёма | Проверка | Результат | |---|---| | Контейнеры | **21 из 21 подняты**, ни одного упавшего | | Postgres (оба кластера) | `healthy` — журнал отыгран без потерь | | Домены продуктов | отвечают все пять | | С машины владельца (российский провайдер) | **открываются**, страницы по 70 КБ | | Инфраструктура на Beget | не пострадала | DNS переведён на новый адрес у всех пяти записей продуктов; `git`, `errors`, `metrics`, `obsidian`, `garmin` намеренно оставлены на `46.173.16.127`. ### Побочный итог: #3110 закрывается сам Старый адрес был недоступен российским операторам — ровно из-за этого и заказывали замену. **Новый адрес фильтрации не имеет**: сайты открываются напрямую с машины владельца, без VPN. Проверено после переключения DNS. ### Что осталось - Пароль root светился в панели и в рабочей переписке — после переезда его стоит сбросить (парольный вход в боевой ОС и так выключен, но гигиена). - `ops/selectel-ci-access.sh:171` — дефолт `HOST_IP` всё ещё старый адрес; поправлю отдельным PR вместе с комментариями в `caddy/sites/*.caddy` и `docker-compose.prod.yml`. - `mobileproxy.space`: egress-IP в кабинете по-прежнему привязан к Beget (#3059). - Проба НСПД и ДОМ.РФ на новом адресе — с брейкером, как договаривались (#2956, #2443). **Раздел «Почему никто не узнал» остаётся открытым вопросом** и вынесен в #3078/#2203: авария была штатной по причине, но десять часов молчания — нет.