Наблюдаемость и резервные копии

Две темы в одном уроке, потому что обе про одно: что делать, когда что-то пошло не так, — и что вы успели подготовить заранее.

Метрики и журналы

Стек здесь не тот, который ожидают по привычке, и это любимая ловушка экзамена.

Ни Prometheus, ни Loki, ни Elasticsearch в платформе нет. VictoriaMetrics при этом понимает язык запросов PromQL — то есть привычные запросы работают, а хранилище другое: компактнее и дешевле на больших объёмах.

Собирает метрики агент vmagent, который живёт рядом с нагрузкой и отправляет собранное в хранилище. Само хранилище развёрнуто как VMCluster (VMCluster) — кластерная установка VictoriaMetrics под управлением оператора. Журналы собирает fluent-bit — та же роль, только для текста.

Цепочка оповещений короткая, и порядок в ней спрашивают: VMAlert проверяет правила по метрикам в VictoriaMetrics → Alerta сводит срабатывания в одно место, убирает дубликаты и маршрутизирует их → почта, SMS, мессенджеры. Alerta нужна затем, чтобы одна авария не приходила восемью письмами из восьми источников.

Grafana приезжает с готовыми дашбордами, и экзамен спрашивает их по названиям групп: Cluster Overview — здоровье кластера целиком, Node Metrics — процессор, память, диск и сеть по узлам, ETCD — состояние хранилища etcd, Storage — здоровье LINSTOR и SeaweedFS, Tenant Applications — нагрузки и управляемые приложения по тенантам. Есть ещё дашборды по трафику точки входа и по управляемым базам данных.

Про наследование помните из второго урока: тенант без своего мониторинга шлёт метрики родительскому. А вот включать сбор задним числом бесполезно — записей за прошлое взять неоткуда, и это стоит решать при создании кластера, а не когда график понадобился.

Резервные копии

Здесь два разных механизма, и путать их — верный способ ошибиться в вопросе.

Копии управляемых сервисов (backup). Здесь работают четыре объекта, и путать их — верный способ ошибиться:

Ключевая пара — Plan и BackupJob. Нужна копия каждую ночь — это Plan. Нужна копия прямо сейчас, перед обновлением — это BackupJob. Восстановление — отдельный объект, RestoreJob.

Начиная с версии 1.5 в платформе есть готовый cozy-default — класс копий, который работает сразу, без настройки хранилища.

Velero. Уровнем выше: копирует объекты самого кластера и тома. Это про восстановление платформы, а не отдельной базы. С версии 1.5 он не опция, а штатный компонент — ставится по умолчанию.

Настраивают его два объекта: BackupStorageLocation — куда складывать копии, и VolumeSnapshotLocation — где хранить снимки томов. Кластеру Kubernetes внутри тенанта Velero включают одним полем: spec.addons.velero.enabled.

Где проходит граница

Самое ценное в этой теме — понимать, чего резервные копии не делают.

Копия управляемого приложения берёт только данные. В неё не попадают ни HelmRelease приложения, ни объект CR, который вы завели в каталоге, ни секреты, созданные оператором базы.

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

Инкрементальных копий виртуальных машин нет: отслеживания изменённых блоков в платформе не делают, каждая копия полная. Если за спиной привычка к цепочкам инкрементов, окна копирования и объём хранилища придётся пересчитать.

Копии — не отказоустойчивость. Реплики спасают от падения узла, копии — от удалённых данных. Это разные беды, и одно другое не заменяет.

Копия, которую ни разу не разворачивали, — не копия, а надежда. Восстановление надо пробовать, пока оно не понадобилось.

И главное: копия хранится в объектном хранилище. Если оно живёт в том же кластере, что и данные, то от потери кластера целиком она не спасёт. Для настоящей защиты хранилище должно быть снаружи.

Мы разобрали, из чего платформа сделана и что она умеет. Остался последний вопрос — почему она устроена именно так.

Подробнее: мониторинг · сервисы кластера