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

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

Об ошибках при применении конфигурационных ресурсов сообщается в логе пода 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`).

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

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

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

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

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

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

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

Посмотрите метрику `Scheduler keys convergence` на дашборде [Checklist](../130_monitoring_system/030_monitoring_reference.md), а также логи пода global_scheduler. Если значение метрики равно нулю, то приватный ключ планировщика и публичный ключ в БД системы различаются, в логе пода должны быть отображены соответствующие публичные ключи. Для синхронизации ключей или генерации и применении новой пары, обратитесь к [инструкции](../045_scheduler-setup/030_scheduler_setup_kubernetes.md#конфигурация-globalscheduler-в-kubernetes).

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

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

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

Скорее всего это говорит о ненастроенном JGroups. Читайте подробнее [здесь](./100_jgroups.md).

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

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

1. Указали корректный адрес Prometheus из kube-prometheus-stack.
2. В `profile.zip` нет переопределений файлов `otel-*.config`.
3. Активировали серверную телеметрию в Global. <!-- TODO: уточнить -->