Инструкции по траблшутингу#

Нет совершенного программного обеспечения, которое работало бы без сбоев или не имело бы ограничений по максимальной нагрузке. Для предотвращения проблем необходимо обеспечить систему рядом мер для быстрого определения проблемы или же отката системы до нужного состояния.

Обратите внимание.

Перед внесением изменений в критичную конфигурацию стенда, или же в бизнес логику библиотек или ресурсов, которые создают массовую нагрузку и используются в зависимых объектах, следует:

  • Обеспечить версионирование при внесении изменений в конфигурацию отличную от дистрибутива, и возможность хранения версий в системе управления версиями (например, GitLab или Atlassian BitBucket).

  • Обеспечить возможность незамедлительного отката всех изменений, проведенных в рамках релиза или обновления критичных компонентов.

  • Обеспечить прозрачность действий при важном обновлении компонентов системы (подготовить план изменения, расписать все компоненты, которые будут изменяться, согласовать данный план, и внедрять в соответсвии с регламентом организации).

  • Обеспечить стенды средствами мониторинга (метрики именно приложения, а не среды оркестрации контейнеризированных приложений, которые обобщены и показывают не точную нагрузку приложения бизнес-логикой, а суммарную нагрузку от всех компонентов инсталляции, что не отражает точную картину происходящего и не позволяет быстро установить причину недоступности).

  • Обеспечить стенды системой сбора и хранения логов (для анализа проблем на контейнерах, которые уже перезагружены и более не существуют, в системе хранения логов останутся запси о произошедших событиях).

Инструкции#

Для выявления и анализа проблем можно воспользоваться следующими методами и инструментами:

Сообщения об ошибке в окне пользовательского интерфейса#

IDMX имеет довольно подробную систему сообщений об ошибках. В дополнение к текстовому сообщению, всплывающие сообщения об ошибках содержат гораздо больше информации.

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

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

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

После этого можно переходить к следующим шагам анализа.

Сообщения об ошибке в журнале логов#

Следующим шагом в устранении неполадок должно стать ознакомление с лог файлами.

Лог файлы IDM регистрируют активность idmx-engine на нескольких уровнях. Все ошибки и предупреждения должны регистрироваться там по умолчанию. Обычно это должно содержать достаточно информации, чтобы помочь в устранении серьезных неправильных настроек или других серьезных проблем.

Файлы журналов по умолчанию размещаются в директории /app/idmx-engine/var/log.

Повышение уровня логирования#

Конфигурацией ведения журнала можно управлять на странице с System > Logging. Диалоговое окно позволяет задать множество параметров ведения журнала. Для устранения неполадок можно применить следующее правило:

  • Уровни FATAL, ERROR, WARNING и INFO предназначены для включения при нормальной работе системы. Их можно безопасно включить для любого компонента. Здесь должно быть достаточно информации, чтобы примерно определить местонахождение любой проблемы.

  • Уровень DEBUG предназначен для устранения неполадок от неправильных настроек и подобных проблем. Это должно предоставить администратору IDM достаточно информации, чтобы понять, в чем ошибка. Этот уровень логирования предоставляет много информации и не должен быть включен постоянно. Даже при поиске неисправности рекомендуется включать DEBUG только для нескольких компонентов, чтобы снизить уровень шума в логах.

  • Уровень TRACE предназначен для разработчиков: либо разработчиков IDM, либо разработчиков плагинов IDM. На уровне TRACE используется сленг разработчиков программного обеспечения, названия классов и прочая back-end информация. Если системному администратору необходимо углубиться до TRACE уровня, значит, что-то не так с настройкой ведения журнала логирования.

ВНИМАНИЕ!

Для PROD стендов высокий уровень логирования приведет к падению производительности!

Если нет явных причин и ошибок в логах#

Если анализ журнала логов не привел к результату, то можно снять HeapDump и ThreadDump или JFR (Java Flight Recorder, запись runtime событий ожидания процессором внутри JVM).

  • Команда для снятия ThreadDump:

    Рекомендуется делать, когда вы наблюдаете рост потребления CPU (предварительно командой JCMD узнайте PID вашего Java процесса).

    jstack 525(PID вашего Java процесса) > /tmp/threaddump-engine-0.txt

  • Команда для снятия HeapDump:

    Рекомендуется делать, когда вы наблюдаете рост потребления RAM (предварительно командой JCMD узнайте PID вашего Java процесса).

    jcmd 525(PID вашего Java процесса) GC.heap_dump /tmp/dump

  • Команда для снятия JFR:

    Рекомендуется делать, когда вы наблюдаете таймауты к каким то системам или ресурсам.

    jcmd 525(PID вашего Java процесса) JFR.start duration=300s filename=/tmp/engine-1.jfr

Недоступность БД: как проверить и на что обращать внимание#

Если же в логах IDMX возникают ошибки, связанные с базой данных, (can't initialize pool, exception during sql и подобные), то можно воспользоваться следующими рекомендациями:

  • Проверьте логи БД, обычно они находятся в файле /pgerrorlogs/05/pgbouncer.log или postgresql_data.log. Анализ данных логов на ошибки может прояснить многие детали ситуации, например, неверные данные для авторизации, или же какие-либо таймауты, возникшие при выполнении операций. Все это поможет собрать необходимую фактуру для команды поддержки БД.

  • Проверьте, корректны ли настройки как самой БД так и Pgbouncer в файлах postgresql.conf и Pgbouncer.ini соответственно.

    К примеру, если IDMX эксплуатируется как кластер с большим количеством узлов, которые подключаются к одному экземпляру БД, то в pgbouncer.ini должны быть заданы соответствующие значечния в параметрах max_client_conn, max_connections, max_db_connections и max_user_connections.

Проблемы Istio#

Если при подключении к каким-либо ресурсам наблюдаются сетевые ошибки (например, connection attempt failed или же просто тайм-аут), то можно проанализировать логи Istio sidecar (envoy), а также ingress-gateway (в случае со входящим трафиком) и egress-gateway (в случае с исходящим).

Чтобы посмотреть логи Istio для конкретного контейнера, перейдете в контейнер idmx-engine, затем выберите log > контейнер istio-proxy.

В данных логах можно увидеть, через поиск по конкретному IP-адресу, отправлялся ли трафик на этот адрес, или же возникли какие то проблемы с отправкой. Если в строке с нужным IP-адресом наблюдаются ошибки UH, NR, UF, то можно посмотреть описания кодов данных ошибок в официальной документации Istio и сообщить поддержке Istio на конкретном стенде.

Также, если неизвестно, на какой контейнер придет или отправится пакет, можно посмотреть логи исходящего или входящего трафика самого egress-gateway (исходящий) или ingress-gateway (входящий).

По данным логам можно проанализировать, идут ли конкретные запросы или нет, и на каком этапе происходит ошибка.

Повышение уровня логирования (пригодится для глубокого анализа проблем с Istip и заведения задач на поддержку Service Mesh)#

  • Включить Debug уровень логирования:

    curl -X POST localhost:15000/logging?level=debug

  • Выключить Debug:

    curl -X POST localhost:15000/logging?level=info

Также можно собрать config Istio:

oc exec -it <имя_контейнера> -c istio-proxy -- curl -X POST localhost:15000/config_dump?include_eds > egress.json

Проблемы с кластером OSE#

При возникновении контейнеров в статусе Evicted c сообщением о переполнении ephemeral storage, можно воспользоваться следующей инструкцией для сбора статистики:

  1. Необходимо зайти в контейнер в статусе Evicted, затем перейти в Yaml и убедиться, что контейнер был evicted именно из-за переполения ephemeral storage (в конце лога будет сообщение, свидетельствующее об этом).

  2. Записать время перехода контейнера в статус Evicted и собраться с командой поддержки среды оркестрации контейнеризированных приложений (k8s или OSE) для анализа, что происходило в данном контейнере с его общим ephemeral storage.

    • Такое событие может также произойти, когда заканчивается место в контейнере, выделенное для всех экземпляров, и все экземпляры данного контейнера перейдут в статус Evicted.

Полезные команды, которые могут быть использованы при разборе проблем:

  • Показать размер папок в директории:

    du -s /* --block-size=MB | sort

    Определит размер каждой папки.

  • Показать большие файлы:

    find ~ -type f -size +2000k -exec ls -lh {} \; 2> /dev/null | awk '{ print $NF ": " $5 }' | sort -hrk 2,2

    Покажет крупные файлы (они могут быть так же и в узле, будьте осторожны).

Проблемы со стартом контейнера#

  • Зависание на этапе загрузки init-контейнера.

    Если контейнер завис на данном этапе и в логах отсутствуют записи, то следует сообщить администраторам OSE, возможно это инфраструктурная проблема. Сделайте скриншот, соберите время запуска, заведите инцидент и разберите проблему с администраторами стенда.

  • Зависание контейнера idmx-engine c долгими таймаутами до других контейнеров.

    Определите в логах зависшие контейнеры (которые в логах содержат такие записи, как out of memory или java heap space, или другие фатальные ошибки), и удалите данные контейнеры, чтобы они отправились в перезагрузку.

  • Зависание пода idmx-engine на подключении к БД.

    Ошибка в логах idmx-engine connection attempt failed — ошибка сетевая, нужно исследовать компоненты Istio (Synapse Service Mesh).

  • Ошибка в логах idmx-engine:

    • password authentification failed — Проверьте credentials в системе хранения секретов (например, Secman);

    • cannot initialize pool — Увеличьте конекшены на pgbouncer и БД.

    • FATAL: Peer authentication failed for user "idm" — проверьте вхождения в файле pg_hba.conf, разрешен ли пользователю idm вход в БД.