Часто встречающиеся проблемы и пути их устранения#
Работа при недоступности Apache Kafka. При недоступности Apache Kafka в процессе работы будет отсутствовать возможность отправить метрик в хранилище. В самомониторинге будут отображаться ошибки на дашборде «Количество ошибок при работе компонента». Для восстановления работы необходимо устранить ошибки, зафиксированные в логах;
Ошибка аутентификации или недоступность сервиса аутентификации. При невозможности аутентификации пользователю может быть отказано в доступе. Для получения доступа необходимо обратиться к администратору сервиса аутентификации;
Ошибка авторизации или недоступность сервиса авторизации. При отсутствии соответствующих прав пользователю может быть отказано в доступе к ресурсам. Для получения доступа необходимо обратиться к администратору сервиса авторизации;
При недоступности сервиса проектов будет невозможен доступ к ресурсам, связанным с проектом. Для восстановления работы Единого коллектора необходимо обратиться к администраторам сервиса проектов;
При недоступности БД сервис не доступен. Он перезапускается, пытаясь повторно подключится к БД. Для восстановления работы Единого коллектора необходимо восстановить работоспособность БД или подключения к ней:
При сетевой недоступности, необходимо ее обеспечить. Компетенции для обеспечения сетевой доступности сервисов должны быть у администраторов инфраструктуры клиента;
При ошибках аутентификации или авторизации - проверить корректность настроек подключения.
6.Исчерпание подключений и невозможность дальнейшего горизонтального масштабирования при работе с задачами сбора данных с БД (Конфигурация чтения из БД, Конфигурация Osiris проверок БД) Для работы с задачами сбора данных с БД есть возможность указать - Признак использования Hikari connection pool. Указывается признак при создании DataSource.
Если признак будет включен, то для каждого экземпляра модуля Pull, где запускается задача с данным Datasource, будет выделено количество подключений к БД в зависимости от параметров -
collector_pull.ose.configmap.cote_cm_telemetry_collector_pull.datasource.pool.maximum_pool_size=10 collector_pull.ose.configmap.cote_cm_telemetry_collector_pull.datasource.pool.minimum_idle_size=0.
Если признак выключен, то будет выполняться попытка соединения с БД, если она неудачная из-за ошибки связанной с недоступностью свободного соединения (текст ошибок для разных СУБД задан в параметре -collector_pull.ose.configmap.cote_cm_telemetry_collector_pull.datasource.exception.message.whitelist=too many connections for role, many roles), будет выполнено некоторое количество попыток повторного соединения (параметрcollector_pull.ose.configmap.cote_cm_telemetry_collector_pull.datasource.retry.limit=10) через определенный интервал времени указанный в параметреcollector_pull.ose.configmap.cote_cm_telemetry_collector_pull.datasource.retry.delay=100.
При исчерпании количества попыток соединения итерация будет признана неуспешной, ошибка будет выведена в статистику работы задачи сбора данных. Сообщение об ошибке будет дополнено тестом"After " + k + " attempts." After k attempts, где k - количество использованных попыток подключения.У ранее созданных DataSource останется значение признака, которое указывалось ранее в задаче, если его не было то будет включен для обратной совместимости. Для новых DataSource по умолчанию признак выключен. При ограничении в соединениях к БД, рекомендуем создавать задачи без использования пула соединений, чтобы не резервировать лишние соединения к БД.
Стоит учесть, что флаг «Признак использования Hikari pool» применяется ко всем задачам сбора, которые используют один и тот же DataSource. При использовании Конфигурация Osiris проверок БД с выключенным признаком использования Hikari connection pool для получения соединения будут учитываться имя и пароль пользователя, схема и строка адреса подключения. Если необходимо для одного Datasource часть задач указать с включенным признаком использования Hikari connection pool, а часть с выключенным, необходимо:Создать Datasource с такими же данными для подключения.
Для необходимых задач включить признак использования Hikari connection pool и установить у них созданный Datasource. 7.Превышение утилизации на Pull Collector
Может быть вызвано инфраструктурными проблемами (связь с Kafka) или проблемами на стороне системных задач сбора данных (недостаток квот, троттлинг, некорректный статус), что в свою очередь приводит к повышенной нагрузке на Pull Collector. Для избежания такой проблемы, рекомендуется контролировать инфраструктурные проблемы и работоспособность системных задач сбора данных.
Превышение утилизации на Management Application
Может быть вызвано повышенным обращением со стороны Pull Collector/Push Collector для получения данных о задачах сбора. В случае, если задача находится в состоянии Failed, происходит обращение Push Manager при каждой отправке сообщения в такую задачу. Каждое обращение приводит к созданию объектов, что сказывается на утилизации. Для избежания такой проблемы, рекомендуется выполнять мониторинг задач сбора данных на предмет статуса FAILED.
Также проблема может возникнуть из-за значительного количества статистической информации, сохраняемой в базе данных. Чтобы справиться с подобными ситуациями, необходимо подбирать параметры очистки статистики (ротации) в базе данных в соответствии с объемами данных.
Предупреждение в логах
Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.producer:type=app-info,id=KafkaTemplate пытается зарегистрировать producer c clientId, который уже был зарегистрирован. Это приводит к появлению предупреждения, но логика работы от этого не ломается. Чаще всего это возникает в следствии инфраструктурных проблем, которые приводят к пересозданию producer.
Пример в логах:
INFO [ForkJoinPool.commonPool-worker-3] o.a.k.c.p.KafkaProducer - [Producer clientId=00000000000-1] Closing the Kafka producer with timeoutMillis = 30000 ms.
INFO [0000-000-00-00000]o.a.k.c.p.KafkaProducer - [Producer clientId=00000000000-1] Closing the Kafka producer with timeoutMillis = 30000 ms.
Ошибка в UI при создании пароля
Status 403 Forbidden: 1 error occurred: * permission denied; nested exception is org.springframework.web.client.HttpClientErrorException$Forbidden: 403 Forbidden: "("errors":["1 error occurred:\n\t* permission denied\n\n"])<EOL>Ошибка при попытке сохранить секрет в Secman, проверить доступ.Ошибки в логах Istio
GET /v1/.../credentials/RPA___ HTTP/1.1" 403 - "-" "-" 0 60 7 7 "-" "Apache-HttpClient/4.5.13 (Java/11.0.4)" "c0b3b4c0-70ae-9443-ae68-c5a639545209" "xxxx.ru:00" "00.00.0.0:0000" outbound|0000||cote-svc-egressgateway.cote.svc.cluster.local -
GET /internal/configuration/identifiable-entity/secret/111-111-11-1 HTTP/1.1" 404 - "Java/11.0.4" "xxxx-xxx-xx-x-xxxxxx" "cote-svc-telemetry-collector-management-app:0000" "000.0.0.0:0000" inbound|000|http-0000|cote-svc-telemetry-collector-management-app.svc.cluster.local
Указанные ошибки могут быть связаны с нестабильной работой или проблемами доступа к Secman. Проверить наличие доступа.
Некорректно завершается сессия при отключении/включении pod. Клиент получает ответы с кодом 500 или 503
Проверить значение таймаута для завершения работы контейнеров приложения в telemetry-collector.management-app.conf параметр:
management_app.deployment.spec.pre.stopи в telemetry-collector.collector-push.conf параметр:collector_push.deployment.spec.pre.stopПри необходимости скорректировать его.Проверить наличие политики повторных попыток на стороне Istio в telemetry-collector.istio.all.conf:
## Настройка повторных попыток для VirtualService при маршрутизации трафика в Push
# Включение политики повторных попыток
istio.ingress.virtual.service.push.retry.enable=true
# Количество повторных попыток
istio.ingress.virtual.service.push.retry.attempts=3
# Таймаут выполения запроса (включая основной запрос) в секундах (Формат 1h/1m/1s/1ms)
istio.ingress.virtual.service.push.retry.timeout=120s
# Условия при которых выполняется повторная попытка (Пример: 500,503)
istio.ingress.virtual.service.push.retry.on=5xx
При необходимости скорректировать значения.
Проверить политику обновления конфигурации pod в telemetry-collector.all.conf параметры:
## Настройка параметров политики обновления PODs
# Максимальное количество дополнительных подов (устанавливается как абсолютное числом (1), или процент от желаемого количества подов (10%))
telemetry_collector.spec.strategy.rollingParams.maxSurge=1
# Максимальное количество недоступных подов (устанавливается как абсолютное числом (1), или процент от желаемого количества подов (10%))
telemetry_collector.spec.strategy.rollingParams.maxUnavailable=1
При массовом обновлении (большие значения в параметрах политики обновления) может наблюдаться некорректное завершение сессий на стороне пользователя.