Проверка работы кластера в Lens

Для диагностики и устранения ошибок системы откройте приложение Lens:

В приложении доступно:

• просмотр объёма потребления системных ресурсов контейнерами;

• проверка работы подов на каждом узле кластера и аудит их логов;

• проверка доступа к источнику данных;

• проверка событий кластера.

Просмотр объёма потребления системных ресурсов контейнерами

Для просмотра объёма потребления ресурсов центрального процессора (CPU) и оперативной памяти (RAM) контейнерами откройте подраздел «Workloads > Pods» и нажмите на наименование пода. По умолчанию будет отображён график потребления ресурсов CPU подом:

Для отображения графика потребления ресурсов RAM подом нажмите кнопку «Memory» на панели инструментов, расположенной над графиком:

Для отображения графиков потребления ресурсов CPU и RAM контейнерами пода откройте раздел «Containers»:

Для отображения графиков потребления ресурсов CPU и RAM рабочим узлом кластера откройте раздел «Nodes» и нажмите на наименование рабочего узла:

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

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

1. Откройте подраздел «Workloads > Pods»:

В таблице отображается список подов кластера с системными характеристиками.

2. Проанализируйте работу подов по параметрам (столбцам):

• Status. Текущее состояние пода:

• Running. Выполнение процессов;

• Completed. Процессы выполнены;

• Error. Ошибка;

• Pending. Ожидание;

• Container. Количество запущенных контейнеров.

Работа пода считается некорректной:

• если состояние пода «Running», но запущены не все контейнеры;

• если состояние пода «Error» или «Pending».

3. Перезапустите под при обнаружении некорректной работы.

Если после перезапуска пода сохраняется некорректное поведение, то проведите аудит логов пода.

Для аудита логов пода:

1. Щёлкните по наименованию пода в столбце «Name» для детализации данных по конкретному поду.

Совет. Рекомендуется проверить следующие поды: fmp-api, fmp-auth, fmp-dashboard, fmp-rpc, fmp-web.

2. Нажмите кнопку «Logs»:

После чего будет отображён список логов пода:

3. Отсортируйте логи пода по времени их выполнения с помощью команды:

kubectl logs <наименование пода> -n <пространство имён сервера мобильной платформы> | sort -k 23

После чего будет выведен список логов, отсортированный по времени выполнения процессов от самых быстрых до самых долгих.

4. Проанализируйте логи пода. Пример логов, которые указывают на корректную работу контейнеров пода fmp-api (также актуально для fmp-auth, fmp-dashboard, fmp-rpc, fmp-web):

{"timestamp": "[20/Feb/2026:09:52:54 +0000]", "response_status": 200, "response_time": 1.193320, "ip": "10.0.1.227", "x_forwarded_for": "10.0.0.82", "http_method: "GET", "URN": "/api/swagger-ui/", "query_string": "", "response_length": 1820, "request_id": "497befa639165acb02dc15d9f9309705"}

Расшифровка примера:

{"timestamp": "<время отправки ответа клиенту>", "response_status": <статус ответа>, "response_time":  <время обработки ответа>, "ip": "<IP-адрес клиента>", "x_forwarded_for": "<значение заголовка X-Forwarded-For>", "http_method: "<HTTP-метод запроса>", "URN": "<URN>", "query_string": "<значения GET-параметров>", "response_length": <длина ответа>, "request_id": "<идентификатор запроса>"}

Логи, отличные от примера, могут указывать на некорректную работу пода. Если после анализа логов пода не выявлена причина проблемы, то проверьте доступ к источнику данных.

Если с сервера мобильной платформы возвращается ответ с кодом ошибки 502, то проанализируйте логи пода fmp-nginx, характеризующие работу прокси-сервиса nginx.

Проверка доступа к источнику данных

Для проверки доступа к источнику данных отправьте тестовый запрос к серверу мобильной платформы:

• с мобильного устройства;

• с помощью инструмента curl.

Если тестовый запрос к серверу мобильной платформы не выполняется, то отправьте запрос к источнику данных:

• из контейнера. Рассмотрим отправку запроса к источнику данных на примере API-метода rpc, для этого:

1. Откройте подраздел «Workloads > Pods».

2. Щёлкните по наименованию пода в столбце «Name» для детализации данных по конкретному поду.

3. Нажмите кнопку «Shell»:

После чего будет открыт терминал:

4. Отправьте запрос к источнику данных и сравните результат с ожидаемым.

• с сервера мобильной платформы.

Примечание. Если запрос выполняется только из контейнера, то возможно прокси-сервисы (nginx, ingres кластера и другие) работают некорректно. Для выявления такого сервиса отправьте запрос к каждому из уровней проксирования. Если запрос не выполняется из контейнера, то проверьте таймауты.

Таймауты, указанные на прокси-сервере и фреймворке, должны соответствовать реальному времени выполнения запроса. Проверьте установленные таймауты на прокси-сервере до кластера, на кластере (Ingress Controller) и на источнике данных. Если таймауты указаны корректно, то проверьте события кластера.

Проверка событий кластера

Для проверки и анализа событий кластера выполните одно из действий:

• откройте раздел «Events»:

• выполните команду:

kubectl get events -n <пространство имён сервера мобильной платформы>

После выполнения действия будет получена информация о событиях кластера.