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

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

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

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

Решение:

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

Для создания разрешающего правила укажите в конфигурации 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)#

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

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

Решение:

1. Проверьте статус Pod в Kubernetes/Platform V DropApp:

   • Если статус ContainerCreating, то:

     1. Подождите, пока узел станет доступным.

     2. Если статус узла не меняется, обратитесь к администратору кластера.

   • Если статус crashloopbackoff, то:

     1. Проверьте логи Pod на наличие ошибок приложения.

     2. Если используете хранилище секретов, подождите загрузку необходимого секрета.

   • Если статус imagepullbackoff, то:

     1. Проверьте правильность адреса до образа в реестре Docker.

     2. Посмотрите, создан ли secret скачивания образов из разрешенного реестра Docker.

2. Проверьте, что все контейнеры перешли в статус готовности.

3. Посмотрите код состояния запросов на 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):

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