Сбор логов

Два типа логов в DataLens On-premises

Application Logs — логи работы приложения. Это технические логи от каждого микросервиса (ui, data_api, us и так далее), которые пишутся в stdout/stderr каждого Kubernetes-пода. Они содержат информацию о запусках, внутренних операциях, ошибках и стектрейсы. Нужны для отладки и поиска причин сбоев в работе DataLens.

Usage Tracking — логи использования. Это структурированные события о действиях пользователей: открытие дашборда, выполнение запроса, время ответа. Их собирает сервис fluent-bit и отправляет в базу данных ClickHouse. Они нужны для анализа популярности дашбордов, поиска тяжелых запросов и аудита.

Инструменты для сбора логов

Скрипт init.sh предоставляет несколько инструментов для работы с логами.

Сбор логов со всех подов

Это основная команда, когда нужна общая картина происходящего.

./init.sh --stern . -o extjson > datalens.enterprise.log
        
        # --stern .: Агрегирует логи со всех подов в пространстве имен DataLens
        # -o extjson: Вывод в структурированном JSON, который удобно парсить. Для чтения глазами можно использовать raw
        # > datalens.enterprise.log: Перенаправление вывода в файл для дальнейшего анализа или отправки в поддержку
        

Сбор логов с одного пода

Если вы знаете, какой сервис тормозит (например, auth), можно смотреть только его логи.

 ./init.sh --stern --tail 100 --no-follow pod/<имя_пода>
        

Имя пода всегда уникальное, поэтому его нужно смотреть предварительно. Это можно сделать командой:

./init.sh --kubectl get pods
        

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

Иногда проблемы возникают на уровне Kubernetes: под не может запуститься, скачать образ или получить ресурсы. В этом случае нужно смотреть не логи приложения, а события кластера.

./init.sh --kubectl get events
        

Эта команда покажет проблемы ImagePullBackoff (не удалось скачать Docker-образ),
CrashLoopBackoff (под падает и перезапускается) или нехватку ресурсов.

Продвинутые инструменты отладки

Терминальный интерфейс k9s

Для интерактивного мониторинга и управления кластером в дистрибутив встроена утилита k9s.

./init.sh --k9s
        

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

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

Доступна единая команда, которая автоматически собирает всю диагностическую информацию в один архив.

./init.sh --get-debug-info
        

Она соберет логи, конфигурацию Helm-релиза, события кластера и другую служебную информацию.

Примечание

Именно результат выполнения этой команды в первую очередь попросит у вас техническая поддержка при обращении.

Настройка Usage Tracking с использованием внешней ClickHouse

Для production лучше использовать внешнюю ClickHouse. Процесс состоит из трех шагов:

  1. Включить функцию. В values.yaml установите features.usage_tracking.enabled: true.

  2. Подготовить таблицу. В кластере ClickHouse выполните DDL-запрос из Readme.md или локальной документации (/docs), чтобы создать таблицу правильной структуры.

CREATE TABLE $CLICKHOUSE_DB_USAGE_TRACKING.$CLICKHOUSE_TABLE_USAGE_TRACKING
        ON CLUSTER '{cluster}' (
            event_time DateTime64(9),
            event_date Date,
            source_entry_id String,
            dash_id Nullable(String),
            dash_tab_id Nullable(String),
            chart_id Nullable(String),
            chart_kind Nullable(String),
            response_status_code Nullable(UInt64),
            dataset_id Nullable(String),
            user_id Nullable(String),
            request_id Nullable(String),
            query Nullable(String),
            source Nullable(String),
            connection_id Nullable(String),
            dataset_mode Nullable(String),
            username Nullable(String),
            execution_time Int64,
            status Nullable(String),
            error Nullable(String),
            connection_type Nullable(String),
            host Nullable(String),
            cluster Nullable(String),
            clique_alias Nullable(String),
            cache_used UInt8,
            cache_full_hit UInt8,
            endpoint_code Nullable(String),
            query_type Nullable(String),
            err_code Nullable(String),
            workbook_id Nullable(String)
        ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/$CLICKHOUSE_DB_USAGE_TRACKING.$CLICKHOUSE_TABLE_USAGE_TRACKING', '{replica}')
        PARTITION BY toYYYYMM(event_date)
        ORDER BY (toStartOfHour(event_time), connection_id, dash_id, dataset_id, chart_id, user_id, event_time)
        TTL event_date + toIntervalMonth(6)
        SETTINGS index_granularity = 8192, allow_nullable_key = 1;
        
  1. Настроить DataLens. В values.yaml отключите встроенный кластер ClickHouse (infra.clickhouse.enabled: false) и укажите параметры подключения к вашему кластеру.

    clickhouse:
              CLICKHOUSE_HOST: 'your-ch.db.internal'
              # ...
              CLICKHOUSE_DB_USAGE_TRACKING: 'your_db_name'
              CLICKHOUSE_TABLE_USAGE_TRACKING: 'your_table_name'
            

Кейс

Пользователи жалуются, что интерфейс DataLens не загружается. Вы смотрите на поды и видите, что под datalens-enterprise-ui-... находится в состоянии ImagePullBackoff. Куда вы в первую очередь посмотрите, чтобы понять причину?

  • В логи пода datalens-enterprise-ui с помощью stern
  • В события кластера с помощью ./init.sh --kubectl get events
  • В логи Usage Tracking в ClickHouse
  • В интерфейс k9s
Узнать ответ
  • В логи пода datalens-enterprise-ui с помощью stern

    Неверно. Логи приложения еще не генерируются, так как контейнер даже не может запуститься.

  • В события кластера с помощью ./init.sh --kubectl get events

    Верно! Именно в событиях кластера будет детальная информация об ошибке ImagePullBackoff, например: «неверный адрес registry» или «ошибка аутентификации в registry».

  • В логи Usage Tracking в ClickHouse

    Неверно. Usage Tracking фиксирует действия в уже работающем приложении, а в кейсе приложение не может стартовать.

  • В интерфейс k9s

    Фидбэк: В k9s вы увидите статус ImagePullBackoff, но детали ошибки все равно нужно смотреть в описании пода или в events. Так что просмотр событий — более прямой путь.

Практика

Подключитесь к вашей ВМ, на которой установлен DataLens, и выполните диагностические команды.

  1. Посмотрите события кластера: ./init.sh --kubectl get events. Есть ли там что-то подозрительное?

  2. Получите последние 10 строк логов от сервиса ui:

./init.sh --stern --tail 10 deployment/datalens-enterprise-ui
        
  1. Запустите k9s (./init.sh --k9s) и изучите интерфейс. Попробуйте выбрать под и нажать l, чтобы посмотреть его логи. Выход из k9s — :q или Ctrl + C.

Итоги

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