Анализ логов Object Storage при помощи DataLens



Как настроить экспорт логов из Yandex Object Storage и наглядно их анализировать при помощи интерактивных графиков в Yandex DataLens.

Логи
Для начала нам нужно включить экспорт логов Object Storage. Для этого нужно сделать запрос в API сервиса, потому что в UI пока этой опции нет. Запрос можно сделать любым способом, но удобнее всего для этого использовать утилиту aws-cli.

Если у вас не настроена эта утилита, то инструкцию по настройке можно найти в документации.
Чтобы включить логирование запросов для бакета, нужно выполнить следующую команду:
aws s3api put-bucket-logging \
  --endpoint-url=https://storage.yandexcloud.net\
  --bucket $BUCKET \
  --bucket-logging-status file://log-config.json

где вместо $BUCKET вам нужно подставить имя вашего бакета, а файл log-config.json должен содержать следующее:
{
  "LoggingEnabled": {
    "TargetBucket": "$LOGS_BUCKET",
    "TargetPrefix": "s3-logs/"
  }
}

Соответственно, $LOGS_BUCKET нужно заменить на имя бакета, куда будут складываться логи.

ClickHouse
Вторым этапом будет создание кластера Managed Service for ClickHouse. Он будет выступать источником данных для DataLens.

Для наших целей нам подойдет самый маленький кластер burstable-типа. Создание кластера может занять значительное время.


Когда кластер будет создан, необходимо поправить настройки пользователя. Выставить для поля Date time input format значение best_effort.

В ClickHouse реализованы разные движки таблиц. В нашем случае нам пригодится S3.
CREATE TABLE db1.s3logs
(
    bucket String,              -- Имя бакета.
    bytes_received Int64,       -- Размер запроса в байтах.
    bytes_send Int64,           -- Размер ответа в байтах.
    handler String,             -- Метод запроса в формате REST.<HTTP-метод>.<субъект>.
    http_referer String,        -- URL-адрес источника запроса.
    ip String,                  -- IP-адрес пользователя.
    method String,              -- Метод HTTP-запроса.
    object_key String,          -- Ключ объекта, закодированный методом URL-кодировки.
    protocol String,            -- Версия протокола передачи данных.
    range String,               -- HTTP-заголовок, который определяет диапазон байт для загрузки из объекта.
    requester String,           -- Идентификатор пользователя.
    request_args String,        -- Аргументы URL-запроса.
    request_id String,          -- Идентификатор запроса.
    request_path String,        -- Полный путь запроса.
    request_time Int64,         -- Время обработки запроса, в миллисекундах.
    scheme String,              -- Тип протокола передачи данных.
                                -- Возможные значения:
                                -- * http — протокол прикладного уровня передачи данных.
                                -- * https — протокол прикладного уровня передачи данных с поддержкой шифрования.
    ssl_protocol String,        -- Протокол обеспечения безопасности.
    status Int64,               -- HTTP-код ответа.
    storage_class String,       -- Класс хранилища объекта.
    timestamp DateTime,         -- Дата и время операции с бакетом, в формате ГГГГ-ММ-ДДTЧЧ:ММ:ССZ.
    user_agent String,          -- Клиентское приложение (User Agent), которое выполнило запрос.
    version_id String,          -- Версия объекта.
    vhost String                -- Виртуальный хост запроса.
                                -- Возможные значения:
                                -- * storage.yandexcloud.net.
                                -- * <имя бакета>.storage.yandexcloud.net.
                                -- * website.yandexcloud.net.
                                -- * <имя бакета>.website.yandexcloud.net.
)
ENGINE = S3(
       'https://storage.yandexcloud.net/<BUCKET_NAME>/<PREFIX>/*',
       '<ACCESS_KEY>',
       '<SECRET_KEY>',
       'JSONEachRow'
    );

<ACCESS_KEY> и <SECRET_KEY> следует заменить на значения статического ключа доступа в Object Storage. Инструкция по созданию ключа доступа в документации.
<BUCKET_NAME> и нужно заменить на значения, которые указывали в log-config.json, ведь именно туда будут складываться ваши логи и именно оттуда их и будем вычитывать в ClickHouse.
Теперь можно убедиться, что все работает, перейдя в базу db1 и открыв просмотр таблицы s3logs.


DataLens
Подключение

После того как кластер ClickHouse будет создан, можно перейти на вкладку DataLens и сразу создать подключение.



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

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

Теперь можно сохранить датасет. И приступить к созданию чартов на основе этого датасета.

Пример диаграммы количества запросов по методу. Так как это тестовый бакет, GET-запросов оказалось даже меньше, чем PUT.

В датасет можно добавить вычисляемые поля. Например, добавим file_type. Рассчитывать это значение будем по формуле SPLIT([object_key], ‘.’, -1).

Далее мы можем использовать это значение наравне с другими в построении чартов.


Дашборд
Все получившиеся чарты вы можете сгруппировать на дашборд.

Например, такой демо-дашборд для тестового бакета.

Управляемые базы данных. ClickHouse



В 2009 году Яндекс для мгновенного построения отчетов по неагрегированным логам в режиме реального времени разработал первый прототип своей аналитической системы управления базами данных — ClickHouse. Сейчас эта СУБД может применяться в различных сферах для задач, где требуется огромная скорость обработки постоянно поступающей информации.

Зачем понадобились колоночные (столбцовые) системы управления базами данных
Универсальные СУБД при достаточно большой нагрузке либо становятся очень медленными, либо начинают потреблять большое количество серверных мощностей. Например, классическая проблема любой традиционной реляционной базы данных, которая хранит все в строках, — это очень медленная работа сложных аналитических запросов, если количество записей достигает нескольких миллиардов строк. При создании отчетов таким СУБД приходится анализировать множество лишней связанной информации. На скорость построения выборок из такого количества записей не влияет даже оптимизация — правильно настроенные ключи и индексы.

Чтобы ускорить построение отчетов, были придуманы колоночные СУБД, которые, как можно догадаться, изначально хранят данные в колонках. Если один столбец содержит единственный набор значений, то становится гораздо проще строить отчеты по каким-либо показателям. Колоночные СУБД лучше всего подходят для OLAP сценариев работы — обработки аналитических запросов в режиме онлайн. Для таких задач характерны следующие факторы:
  • подавляющее большинство запросов идет на чтение;
  • данные добавляются и обновляются достаточно большими пачками (> 1000 строк), а не по одной строке, или не добавляются и не обновляются вообще;
  • данные добавляются в базу данных, но не изменяются;
  • при чтении используется достаточно большое количество строк из базы данных, но только небольшое подмножество столбцов.

Если вы попытаетесь использовать для аналитики классические СУБД, то получите очень низкую производительность по сравнению с OLAP-СУБД. Это проще продемонстрировать визуально:



ClickHouse
Колоночная СУБД ClickHouse разрабатывалась, чтобы можно было в интерактивном режиме строить отчеты по неагрегированным логам пользовательских действий. Но этим возможности системы не ограничиваются. Со временем к ClickHouse была написана подробная документация, и базу данных стали активно использовать в других продуктах Яндекса — Директе, Маркете, Почте, ADFOX, Вебмастере, в мониторинге и бизнес-аналитике. Например, сервис нагрузочного тестирования Яндекс.Танк использует ClickHouse для хранения данных телеметрии. СУБД позволяла решать задачи, для которых раньше не было подходящих инструментов, или же с ней получалось это делать намного эффективнее, чем с другими системами.

Вот лишь некоторые архитектурные особенности ClickHouse:
  • столбцовое хранение данных — данные считываются только из нужных колонок, и однотипная информация эффективно сжимается;
  • поддержка приближенных вычислений на части выборки — снижается число обращений к жесткому диску, что еще больше повышает скорость обработки данных;
  • физическая сортировка данных по первичному ключу — можно быстро получить конкретные значения или диапазоны;
  • векторные вычисления по кусочкам столбцов — снижаются издержки на диспетчеризацию, эффективно используется CPU;
  • распараллеливание операций как в пределах одного сервера на несколько процессорных ядер, так и в рамках распределенных вычислений на кластере за счет механизма шардирования;
  • линейная масштабируемость — есть возможность построить кластер очень большого размера;
  • работа с жесткими дисками — ClickHouse достаточно эффективно работает, когда данные не попадают в кеш памяти целиком. Дополнительно это снижает стоимость эксплуатации системы, так как жесткие диски дешевле RAM;
  • отказоустойчивость — система представляет собой кластер шардов, где каждый шард — это группа реплик.

ClickHouse поддерживает клиенты для подключения к базе данных: консольный клиент, HTTP API, ряд wrapper’ов на Python, PHP, Node.js, Perl, Ruby, R и многие другие. Также для ClickHouse есть JDBC- и Golang-драйверы.



Где можно применять ClickHouse
За рамки внутренних проектов ClickHouse вышла в 2013 году, когда ее начали применять для анализа метаданных о событиях эксперимента LHCb в CERN. Базу данных могли бы использовать более широко, но в то время мешал закрытый статус. Однако уже в июне 2016 года исходный код ClickHouse был выложен в open source под лицензией Apache 2.0. Это позволило взять ее на вооружение IT-департаментам множества отечественных и зарубежных компаний. В их числе Cloudflare, Bloomberg, ВКонтакте, «Тинькофф банк», Avito, онлайн-кинотеатр ivi.ru, интернет-порталы Mail.ru и Rambler. Например, социальная сеть VK использует нашу СУБД для хранения и чтения отладочных логов. Аналогично делают и другие компании, сгружая в базы данных логи микросервисов и приложений за большой период, а затем быстро возвращаясь к ним для анализа.

ClickHouse в 2020 году — это полноценная СУБД, которая обладает очень широкими возможностями. Создавайте таблицы и базы данных в runtime, загружайте из разных источников данные, анализируйте их и выполняйте запросы без переконфигурирования и перезапуска сервера. ClickHouse позволяет реализовать быстрый доступ к корпоративным хранилищам данных, поддерживает декларативный язык запросов на основе SQL, во многих случаях совпадающий с SQL стандартом. СУБД можно интегрировать с такими Big Data системами, как Apache Kafka и HDFS, а также с MySQL и прочими внешними источниками данных через ODBC или JDBC.

Возможности колоночных СУБД и преимущества конкретно ClickHouse позволяют очень эффективно использовать нашу разработку в самых разных сферах. Это могут быть:
  • аналитика веб-проектов и мобильных приложений;
  • рекламные сети и real-time bidding (торги в реальном времени);
  • телекоммуникации;
  • электронная коммерция и финансы;
  • информационная безопасность;
  • бизнес-аналитика;
  • онлайн-игры;
  • интернет вещей.

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

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

Что дальше?
Мир накапливает очень много больших неструктурированных данных, к которым нужно иметь доступ в режиме реального времени. И для этого необходимо развивать и совершенствовать такие системы управления базами данных, как ClickHouse.

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

Для этого уже есть сервис Yandex Managed Service for ClickHouse, который помогает разворачивать и поддерживать в инфраструктуре Yandex.Cloud кластеры баз данных на основе ClickHouse. Вы получаете все описанные преимущества колоночных СУБД, и при этом вам не нужно покупать и настраивать железо, разбираться со сложностями в обслуживании баз данных и решать проблемы с обновлением. Кроме того, Yandex Managed Service for ClickHouse значительно повышает безопасность работы и позволяет создавать хосты кластера в разных зонах доступности.

Создайте свой первый кластер ClickHouse
console.cloud.yandex.ru/link/managed-clickhouse/

Как настроить управляемую базу ClickHouse с данными для Graphite




При развитии Яндекс.Облака мы, с одной стороны, наращиваем функциональность самой платформы, а с другой — следим, чтобы компоненты было несложно интегрировать с внешними продуктами. Graphite — пример ПО, лёгкость интеграции с которым является важным свойством баз данных Облака. Это библиотека с открытым кодом для хранения и визуализации метрик.

Graphite удобно настроить так, чтобы данные хранились в столбцовой аналитической базе ClickHouse. Специально для этого разработан один из множества движков — GraphiteMergeTree. Он лучше всего подходит для прореживания и агрегирования (либо усреднения) содержимого БД. Саму базу полезно разместить в Яндекс.Облаке через платформенный сервис Yandex Managed Service for ClickHouse. Тогда её не потребуется обслуживать и обновлять — все подобные функции сервис возьмёт на себя.

В этом посте мы опишем процесс настройки Yandex Managed Service for ClickHouse специально под Graphite.

1. Регистрация конфигурации rollup в ClickHouse
Создание конфигурации rollup в существующем кластере Managed Service for Clickhouse можно произвести через CLI или API.

CLI
Если вы выбрали интерфейс командной строки, подготовьте yaml-файл с описанием параметров rollup, например:
graphite-rollup.yaml:
          name: test_rollup
patterns:    
  - regexp: click_cost
    function: max
    retention:
      - age: 86400
        precision: 60

Указанные в файле параметры соответствуют конфигурации, описанной в документации.

Далее выполните команду, указав ID кластера ClickHouse и имя файла конфигурации, созданного на предыдущем шаге:
$ yc managed-clickhouse cluster add-graphite-rollup <CLUSTER_ID> --rollup-file-name graphite_rollup.yaml


API
Используйте метод update для кластера ClickHouse, передав в теле запроса требуемые параметры rollup:
"graphiteRollup": [
          {
            "name": "test_rollup",
            "patterns": [
              {
                "regexp": "click_cost",
                "function": "max",
                "retention": [
                  {
                    "age": "86400",
                    "precision": "60"
                  }
                ]
              }
            ]
          }
        ]


2. Создание таблицы на основе GraphiteMergeTree
Подключитесь к хосту ClickHouse и выполните запрос на создание таблицы на основе GraphiteMergeTree. В качестве параметра передайте имя секции rollup, описанной на предыдущем этапе. Вот пример:
CREATE TABLE GraphiteTable
(        
    metric String, 
    time DateTime, 
    value Int64, 
    version UInt64
)
ENGINE = GraphiteMergeTree('test_rollup')
PARTITION BY time
ORDER BY cityHash64(version, metric)

Теперь можно настроить Graphite для сохранения значений метрик на выбранном хосте ClickHouse. При этом прореживание данных будет проводиться автоматически средствами сервера ClickHouse в соответствии с параметрами, которые вы указали.