Решения частых проблем и ошибок#

Изменения в конфигурационном ресурсе не применились#

Об ошибках при применении конфигурационных ресурсов сообщается в логе пода nsctl. Также о них может сообщаться в событиях ресурсов.

Если в логах пода nsctl нет записей, то необходимо связаться со специалистами вендора. Если требуется срочное решение - попробуйте удалить под nsctl и дождитесь развертывания нового.

Изменения в комплекте приложений (applib, globalserver, profile) не применились#

Для того чтобы обновить комплект приложений, необходимо:

  1. Загрузить новый комплект приложений в системное хранилище NFS (в nscli - при помощи ./appkit.sh push).

  2. Поместить хеши в конфигурационный ресурс (в nscli - при помощи ./appkit.sh switch_local или ./appkit.sh switch_remote).

  3. Вызвать обновление БД, изменив в конфигурационном ресурсе database_schema_version (в nscli - при помощи ./appkit.sh upgrade).

Примечание

Данные в «Настройки системы -> Модули» обновляются после обновления БД, поэтому они не всегда свидедетельствуют о том, что прикладное решение не изменилось. Особенно, если обновление БД завершилось с ошибкой.

Если вы все сделали, но изменения так и не применились, то посмотрите:

  1. Логи контейнера nsctl

  2. Логи контейнеров globalserver

  3. Ресурс resgroup-[название группы ресурсов] типа ConfigMap, через который nsctl передает конфигурацию подам группы.

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

Во время обновления БД возникла ошибка «Не получилось дождаться завершения процесса»#

Ошибка «Не получилось дождаться завершения процесса [название процесса]» означает, что процесс внутри пода с соответствующим названием не отпустил ресурс типа Lease и активно продлевает срок его действия. В таких случаях необходимо собрать и проанализировать логи контейнеров соответствующих подов. Поды затем можно удалить и попробовать запустить обновление еще раз.

Задачи планировщика не выполняются#

Посмотрите метрику Scheduler keys convergence на дашборде Checklist, а также логи пода global_scheduler. Если значение метрики равно нулю, то приватный ключ планировщика и публичный ключ в БД системы различаются, в логе пода должны быть отображены соответствующие публичные ключи. Для синхронизации ключей или генерации и применении новой пары, обратитесь к инструкции.

Предупреждение

Если расхождение ключей происходит регулярно, начните вести учет публичных ключей на ваших контурах. Вероятно, что есть некоторая операция, которая «перезатирает» правильные ключи. Посмотрите, когда упомянутая метрика сменила значение. Ключи в сервере приложений кешируются, поэтому изменение может не примениться сразу.

Если же ключи совпадают, то посмотрите логи планировщика в Grafana (дашборд Logs).

В «Мониторе сессий» не видно сессий с других серверов приложений#

Скорее всего это говорит о ненастроенном JGroups. Читайте подробнее здесь.

В развернутой средствами gs-ctk Grafana нет метрик#

Проверьте, что вы:

  1. Указали корректный адрес Prometheus из kube-prometheus-stack.

  2. В profile.zip нет переопределений файлов otel-*.config.

  3. Активировали серверную телеметрию в Global.