Часто встречающиеся проблемы и пути их устранения#

Контроль доступа к внешним ресурсам#

Не обнаруживается подключение к управляемой БД#

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

Решение:

Cконфигурируйте сетевые политики с помощью Service Entry (Istio).

Данное решение обеспечит контроль доступа модулей Kintsugi к внешним по отношению к service mesh ресурсам (в том числе управляемым БД).

Примечание

По умолчанию любой трафик к внешним ресурсам запрещен.

Для создания разрешающего правила укажите в конфигурации Service Entry:

IP-адрес или доменное имя хоста;
протокол;
порт.

Пример конфигурации:

kind: ServiceEntry
apiVersion: networking.istio.io/v1alpha3
metadata:
  name: kintsugi-example
spec:
  hosts:
    - <host_name> # строка
    - <ip_address> # строка
  ports:
    - name: <port_label> # строка
      number: <port> # число
      protocol: <protocol> # строка
  location: MESH_EXTERNAL
  exportTo:
    - '.'

Замените плейсхолдеры:

<host_name>: доменное имя хоста
<ip_address>: IP-адрес хоста
<port_label>: метка порта
<port>: порт хоста
<protocol>: протокол

Приведенная конфигурация создает разрешающее правило для TCP-трафика на порт port для хостов поддомена host_name и хоста с IP-адресом ip_address. Для успешного результата подставьте вместо параметров в скобках <...> параметры целевой системы.

Детальное описание конфигурации политик Service Entry можно найти на странице официальной документации Istio.

Проблемы при работе в среде Kubernetes/Platform V DropApp (K8S)#

Ошибка запуска пода#

Под не запускается либо запускается с ошибкой.

Решение:

Проверьте статус Pod в Kubernetes/Platform V DropApp:
- Если статус ContainerCreating, то:
  1. Подождите, пока узел станет доступным.
  2. Если статус узла не меняется, обратитесь к администратору кластера.
- Если статус crashloopbackoff, то:
  1. Проверьте логи Pod на наличие ошибок приложения.
  2. Если используете хранилище секретов, подождите загрузку необходимого секрета.
- Если статус imagepullbackoff, то:
  1. Проверьте правильность адреса до образа в реестре Docker.
  2. Посмотрите, создан ли secret скачивания образов из разрешенного реестра Docker.
Проверьте, что все контейнеры перешли в статус готовности.
Посмотрите код состояния запросов на readiness и liveness.

Проблемы мониторинга БД при использовании менеджеров пула соединений типа PgBouncer#

Не отображаются метрики мониторинга#

Не отображаются метрики мониторинга после успешного подключения и сбора метрик.

Причина:

Использование менеджеров пула соединений типа PgBouncer и ему подобных при работе с БД.

Решение:

При добавлении объектов мониторинга используйте порт для прямого подключения к наблюдаемым БД (без использования менеджеров пула соединений типа PgBouncer и ему подобных).

Проблемы с timeseries-хранилищем#

Не отображаются значения метрик мониторинга#

Пользователь не видит значений метрик мониторинга.

Решение:

Проверьте выполнение SQL-запросов собираемыми метриками Kintsugi согласно разделу «SQL-запросы получения метрик для панели мониторинга «Метрики»».

Проблемы выполнения запросов к Kintsugi#

Ошибка «400 Bad Request»#

При загрузке веб-интерфейса возникает ошибка «400 Bad Request: Request Header Or Cookie Too Large».

Решение:

Заголовок и/или cookie в запросе превышают максимальный размер, установленный веб-сервером. Переопределите ненужные заголовки и/или cookie на проксирующем узле.

Пример конфигурации (nginx/syngx):

proxy_set_header Cookie "";

Проблемы при работе с Kintsugi agent (DBDA)#

Интенсивные запросы к сервису хранения секретов при отсутствии доступа#

Компонент Kintsugi agent (DBDA) не имеет доступа к пути в хранилище секретов, указанному при установке. После старта агент многократно обращается к сервису хранения секретов с высокой интенсивностью.

Лог постоянно выводит ошибку:

Code: 403
permission denied

Причина:

Из-за отсутствия доступа к пути в хранилище секретов механизм аутентификации агента непрерывно пытается получить действующий сертификат, переподключаясь с минимальными интервалами.

Решение:

Увеличьте временное окно переподключения в конфигурации компонента Kintsugi agent (DBDA):

Параметр	Значение по умолчанию	Рекомендуемое значение
`min_sec_for_reconnect`	`10`	`10`
`max_sec_for_reconnect`	`180`	`180`

Максимальное допустимое значение параметра max_sec_for_reconnect — 180 секунд.

Примечание

Необходимый размер окна переподключения прямо пропорционален количеству экземпляров агентов на ландшафте.

Интенсивные запросы к SecMan за сертификатом#

При частых переподключениях или проблемах с SecMan агент может выполнять многократные запросы за сертификатом.

Решение:

Убедитесь, что сконфигурированы параметры механизмов защиты.

Описание параметров кеширования сертификата и последовательность действий приведены в сценарии «Решение проблемы с интенсивными запросами к SecMan за сертификатом».

Если проблема сохраняется, проверьте доступность SecMan и права в certificate.secman.approle.role_id.