Устранение неполадок

Информация о возможных сценариях устранения неполадок
Tags:

Если нет трейсов и метрик от приложений в интерфейсе

Трейсы и метрики проходят следующий путь от приложения до отображения в интерфейсе:

Приложение > Трейсер ProtoOBP > Агент ProtoOBP > Бэкенд ProtoOBP

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

Уровень приложения

  • Убедитесь, что на приложении есть нагрузка. Трейсы генерируются только в случае наличия запросов к приложению. Если приложение запущено, но никакая работа не выполняется (нет входящих или исходящих вызовов, нет healthcheck и тд) – трейсов не будет. Для появления трейсов следует дать нагрузку на приложение, например, зайти на веб-интерфейс подключаемого приложения, отослать к нему тестовый запрос и тд.

Уровень трейсера

Трейсер может быть может быть некорректно инициализирован, может использовать некорректные адреса для отправки данных. Необходимо проверить переменные инициализации трейсера, сетевую связность с Агентом, а также логи трейсера на предмет ошибок (ошибки связи с агентом также будут в логах):

  • Убедитесь, что все необходимые переменные окружения для конфигурации трейсера установлены: 
    printenv | grep POBP
  • Обратите внимание на переменную окружения POBP_AGENT_HOST – она должна указывать на адрес Агента, доступный для трейсера
  • Проверьте сетевую связность трейсера с Агентом (выполняется из пода/контейнера с приложением, замените имя Агента на значение переменной POBP_AGENT_HOST): 
    curl http://agent-address:8126
  • В случае использования Docker – убедитесь, что контейнер Агента и контейнер приложения находятся в одной Docker сети
  • В случае, если инструментированное приложение работает в Docker контейнере, а Агент установлен как пакет на хосте (не в контейнере, а напрямую через установку MSI/DEB/RPM пакета на сервер), то установите переменную окружения с адресом Агента следующим образом: 
    POBP_AGENT_HOST=host.docker.internal
  • Проведите диагностику и проверку логов работы трейсера:
    • Добавьте переменные окружения к приложению для вывода отладочной инфинформации: 
      POBP_TRACE_STARTUP_LOGS=true
      Подробнее:

Уровень агента

  • Убедитесь, что Агент успешно установлен и подключен и появился в веб-интерфейсе системы.

  • Выполните проверку корректности работы Агента

  • Проверьте сетевую связность с бэкендом:

    • Проверьте сетевую связность сервера Агента с бэкендом (с сервера с установленным агентом): 
      curl http://backend-address
curl https://backend-address
    • Проверьте успешную отправку данных в бэкенд, в случае агента в Docker: 
      docker logs protoobp-agent 2>&1 | grep "Successfully"
      пример вывода команды: 
      2024-11-15 14:45:45 UTC | CORE | INFO | (pkg/forwarder/transaction/transaction.go:375 in internalProcess) | Successfully posted payload to "https://backend-04/intake/?api_key=***************************aa111", the agent will only log transaction success every 500 transactions
    • Проверьте успешную отправку данных в бэкенд, в случае агента в Linux: 
      grep Successfully /var/log/protoobp/agent.log
      пример вывода команды: 
      2024-11-15 09:26:56 UTC | CORE | INFO | (pkg/forwarder/transaction/transaction.go:380 in internalProcess) | Successfully posted payload to "http://backend-04/api/v1/check_run?api_key=***************************-111"
2024-11-15 09:56:21 UTC | CORE | INFO | (pkg/forwarder/transaction/transaction.go:380 in internalProcess) | Successfully posted payload to "http://backend-04/api/v1/series?api_key=***************************-111"

  • Проверьте, что в файлах конфигурации Агента указаны корректные значения адресов бэкенда:

    • адреса бэкенда должны быть указаны с префиксом http:// или https:// и без символа / в конце строки
    • если на бэкенде в переменной окружения UI_URL указано значение с префиксом http://, то на агентах также необходимо указывать http:// (без s)
    • если на бэкенде в переменной окружения UI_URL указано значение с префиксом https://, то на агентах может быть указан как префикс http://, так и https:// (обратное неверно)
    • в случае с агентом для Windows после установки нужно в любом случае изменить конфигурацию, даже если в мастере установки значения указывались (мастер установки может не все значения корректно записать в файл конфигурации)

  • Проверьте логи Агента на предмет ошибок

Уровень бэкенда

  • Проверьте логи компонента proto-nginx.

    • Через веб-интерфейс ProtoOBP. Перейдите в раздел Диагностика Логи бэкенда > proto-nginx.

    • или через терминал, на сервере бэкенда введите:

      docker logs proto-nginx

      Проверьте, есть ли какие-то ошибки в логе.
      Ошибки доступа к эндпоинту POST /api/v0.2/stats HTTP/1.1 можно игнорировать.

  • Проверьте логи компонента proto-trace-processor.

    • Через веб-интерфейс ProtoOBP. Перейдите в раздел Диагностика Логи бэкенда > proto-trace-processor.

    • или через терминал, на сервере бэкенда выполните:

      docker logs proto-trace-processor

      Проверьте, есть ли какие-то ошибки в логе. Например, ошибка активации лицензии или ошибки обработки.

  • Проверьте доступное место на диске.

    • В веб-интерфейсе ProtoOBP зайдите в раздел Инфраструктура > Хосты, выберите хост, на котором размещается компонент proto-storage, перейдите на вкладку Диски.

    • Или в терминале на том сервере, на котором расположен компонент proto-storage, выполните:

      df -h

      Если на диске, на котором хранятся данные, осталось меньше 10% свободного места – трейсы записываться не будут.

  • Проверьте значение метрики consumer lag с тегом protoobp-consumer в дашборде Инфраструктура > Kafka > хост бэкенда.

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

Сбор логов для передачи в техническую поддержку вендора

В случае запроса логов вендором, создайте скрипт:

vim collect-logs.sh

Добавьте содержимое:

#!/usr/bin/env bash
set -euo pipefail

COMPOSE_FILE="docker-compose-198.yaml"

# Опционально:  --since 1h или --tail 1000 и тд.
LOG_OPTS="${*:-}"

STAMP="$(date +%Y%m%d_%H%M%S)"
HOST="$(hostname -s)"   
WORKDIR="logs_${HOST}_${STAMP}"
ARCHIVE="${WORKDIR}.tar.gz"

mkdir -p "$WORKDIR"

containers="$(docker compose -f "$COMPOSE_FILE" ps -q || true)"
if [ -z "$containers" ]; then
  echo "No containers found for compose file: $COMPOSE_FILE"
  exit 1
fi

echo "Collecting logs into $WORKDIR (options: ${LOG_OPTS:-none})"

for cid in $containers; do
  name="$(docker inspect --format '{{.Name}}' "$cid" | sed 's|/||')"
  echo "→ $name"
  docker logs $LOG_OPTS "$cid" >"${WORKDIR}/${name}.log" 2>&1 || true
done

docker compose -f "$COMPOSE_FILE" config > "${WORKDIR}/compose_effective.yaml" 2>/dev/null || true

tar -czf "$ARCHIVE" "$WORKDIR"
echo "✅ Logs archived: $ARCHIVE"

rm -rf "$WORKDIR"

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

chmod +x collect-logs.sh

## сбор всех логов контейнеров
./collect-logs.sh

## сбор логов контейнеров за последние сутки
./collect-logs.sh --since 24h

Запустите скрипт на каждом сервере, где размещены компоненты Proto Observability Platform и передайте в техническую поддержку вендора или интегратора созданные в ходе исполнения скрипта файлы архивов.

Сбор диагностической информации

В случае запроса диагностической информации вендором, в папке продукта (обычно это /opt/protoobp/) на основном сервере c ролью proto-compute создайте скрипт:

vim collect-debug.sh

Добавьте содержимое:

#!/bin/bash

set -e

if [ -z "$1" ]; then
  echo "Период сбора диагностики не указан."
  echo "Использование: $0 <время_в_секундах>"
  exit 1
fi

duration=$1

if [ -f "docker-compose-198.yaml" ]; then
  compose_file="docker-compose-198.yaml"
elif [ -f "docker-compose.yaml" ]; then
  compose_file="docker-compose.yaml"
else
  echo "Файл docker-compose.yaml или docker-compose-198.yaml не найдены в текущей директории."
  echo "Запустите скрипт из директории, в которой находится один из этих файлов (обычно /opt/protoobp)."
  echo "Скрипт завершен."
  exit 1
fi

echo "Найден docker compose файл: $compose_file"

if [ ! -d "debug/ap" ]; then
  echo "Создаю директорию debug/ap"
  mkdir -p debug/ap
  chmod 777 debug/ap
fi

echo "Сбор диагностической информации"
echo "Изменяю файл конфигурации debug/config.yaml - включаю сбор диагностики"
echo "POBP_TRACE_PROCESSOR_DEBUG_SAVE_AP_TO_FILE: true" >> debug/config.yaml
echo "Рестартую proto-trace-processor"
docker compose -f $compose_file restart proto-trace-processor proto-nginx
echo "Ждите $duration секунд"
sleep $duration
echo "Изменяю файл конфигурации debug/config.yaml - отключаю сбор диагностики"
sed -i '$d' debug/config.yaml
echo "Рестартую proto-trace-processor"
docker compose -f $compose_file restart proto-trace-processor proto-nginx
apdate=$(date +'%Y.%m.%d-%H-%M-%S')
tar czf debug/incoming-agent-payloads-${apdate}.tar.gz debug/ap/incoming*
echo "Удаляю временные файлы"
rm -rf debug/ap/*
echo "Итоговый файл: debug/incoming-agent-payloads-${apdate}.tar.gz"

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

chmod +x collect-debug.sh

./collect-debug.sh 60

Передайте в поддержку вендора итоговый файл.

Повреждение части данных в БД из-за непланового отключения работающего сервера или ошибок файловой системы

В случае, если в логе компонента proto-database появляются ошибки вида:

Part ... is broken and needs manual correction

При этом компонент proto-trace-processor циклически рестартует с ошибками:

DB::Exception: Suspiciously big size (870 parts, 3.14 GiB in total) of all broken parts to remove while maximum allowed broken parts size is 1.00 GiB. You can change the maximum value with merge tree setting 'max_suspicious_broken_parts_bytes' in <merge_tree> configuration section or in table settings in .sql file (don't forget to return setting back to default value)

или

DB::Exception: Suspiciously many (870 parts, 3.14 GiB in total) broken parts to remove while maximum allowed broken parts count is 100. You can change the maximum value with merge tree setting 'max_suspicious_broken_parts' in <merge_tree> configuration section or in table settings in .sql file (don't forget to return setting back to default value)

Следует выполнить следующие действия:

  1. На сервере с ролью proto-database в папке с продуктом создайте файл: merge_tree_settings.xml со следующим содержанием:

    <clickhouse>
    <merge_tree>
        <max_suspicious_broken_parts>2000</max_suspicious_broken_parts>
        <max_suspicious_broken_parts_bytes>5000000000</max_suspicious_broken_parts_bytes>
    </merge_tree>
</clickhouse>

  2. На сервере с ролью proto-database в файле docker-compose-<version>>.yaml для сервиса proto-database добавьте новый volume c этим файлом со следующими настройками:

      proto-database:
    container_name: proto-database
    volumes:
      - ${POBP_DATA_DIRECTORY}/database:/var/lib/clickhouse
      - ./merge_tree_settings.xml:/etc/clickhouse-server/config.d/merge_tree_settings.xml:ro

  3. Для применения новой конфигурации на сервере с ролью proto-database в папке с продуктом выполните:

    docker compose -f docker-compose-<version>>.yaml up -d

    Контейнер proto-database будет пересоздан.

    Проверьте логи контейнера proto-database:

    docker logs -f proto-database

    Сразу после старта контейнера в логе должна быть запись о применении новой конфигурации:

    Merging configuration file '/etc/clickhouse-server/config.d/merge_tree_settings.xml'.

  4. На основном сервере c ролью proto-compute проверьте новый лог сервиса proto-trace-processor:

    docker logs -f proto-trace-processor

    Убедитесь, что лог не содержит ошибок.

  5. На сервере с ролью proto-database в файле docker-compose-<version>>.yaml для сервиса proto-database удалите ранее созданный volume с файлом ./merge_tree_settings.xml

  6. Для применения новой конфигурации на сервере с ролью proto-database в папке с продуктом выполните:

    docker compose -f docker-compose-<version>>.yaml up -d