Русский
Русский
English
Статистика
Реклама

Профилирование. Отслеживаем состояние боевого окружения с помощью Redis, ClickHouse и Grafana


прим. latency/time.

Наверное перед каждым возникает задача профилирования кода в продакшене. С этой задачей хорошо справляется xhprof от Facebook. Вы профилируете, к примеру, 1/1000 запросов и видите картину на текущий момент. После каждого релиза прибегает продакт и говорит до релиза было лучше и быстрее. Исторических данных у вас нет и доказать вы ничего не можете. А что если бы могли?

Не так давно, переписывали проблемный участок кода и ожидали сильный прирост производительности. Написали юнит-тесты, провели нагрузочное тестирование, но как код поведет себя под живой нагрузкой? Ведь мы знаем, нагрузочное тестирование не всегда отображает реальные данные, а после деплоя необходимо быстро получить обратную связь от вашего кода. Если вы собираете данные, то, после релиза, вам достаточно 10-15 минут чтобы понять обстановку в боевом окружении.


прим. latency/time. (1) деплой, (2) откат

Стек


Для своей задачи мы взяли колоночную базу данных ClickHouse (сокр. кх). Скорость, линейная масштабируемость, сжатие данных и отсутствие deadlock стали главными причинами такого выбора. Сейчас это одна из основных баз в проекте.

В первой версии мы писали сообщения в очередь, а уже консьюмерами записывали в ClickHouse. Задержка достигала 3-4 часа (да, ClickHouse медленный на вставку по одной записи). Время шло и надо было что-то менять. Реагировать на оповещения с такой задержкой не было смысла. Тогда мы написали крон-команду, которая выбирала из очереди необходимое количество сообщений и отправляла пачку в базу, после, помечала их обработанными в очереди. Первые пару месяцев все было хорошо, пока и тут не начались в проблемы. Событий стало слишком много, начали появляться дубли данных в базе, очереди использовались не по-прямому назначению (стали базой данных), а крон-команда перестала справляться с записью в ClickHouse. За это время в проект добавилось ещё пара десятков таблиц, которые необходимо было писать пачками в кх. Скорость обработки упала. Необходимо было максимально простое и быстрое решение. Это подтолкнуло нас к написанию кода с помощью списков на redis. Идея такая: записываем сообщения в конец списка, крон-командой формируем пачку и отправляем её в очередь. Дальше консьюмеры разбирают очередь и записывают пачку сообщений в кх.

Имеем: ClickHouse, Redis и очередь (любую rabbitmq, kafka, beanstalkd)

Redis и списки


До определенного времени, Redis использовался как кэш, но всё меняется. База имеет огромный функционал, а для нашей задачи необходимы всего 3 команды: rpush, lrange и ltrim.

С помощью команды rpush будем записывать данные в конец списка. В крон-команде читать данные с помощью lrange и отправлять в очередь, если нам удалось отправить в очередь, то необходимо удалить выбранные данные с помощью ltrim.

От теории к практике. Создаем простой список.



У нас есть список из трех сообщений, добавим ещё немного



Новые сообщения добавляются в конец списка. С помощью команды lrange выбираем пачку (пусть будет =5 сообщений).



Далее пачку отправляем в очередь. Теперь необходимо удалить эту пачку из Redis, чтобы не отправить её повторно.



Алгоритм есть, приступим к реализации.

Реализация


Начнем с таблицы ClickHouse. Не стал сильно заморачиваться и определил всё в тип String.

create table profile_logs(    hostname   String, // хост бэкэнда, отправляющего событие    project    String, // название проекта    version    String, // версия фреймворка    userId     Nullable(String),    sessionId  Nullable(String),    requestId  String, // уникальная строка для всего запроса от клиента    requestIp  String, // ip клиента    eventName  String, // имя события    target     String, // URL    latency    Float32, // время выполнения (latency=endTime - beginTime)    memoryPeak Int32,    date       Date,    created    DateTime)    engine = MergeTree(date, (date, project, eventName), 8192);


Событие будет таким:
{  "hostname": "debian-fsn1-2",  "project": "habr",  "version": "7.19.1",  "userId": null,  "sessionId": "Vv6ahLm0ZMrpOIMCZeJKEU0CTukTGM3bz0XVrM70",  "requestId": "9c73b19b973ca460",  "requestIp": "46.229.168.146",  "eventName": "app:init",  "target": "/",  "latency": 0.01384348869323730,  "memoryPeak": 2097152,  "date": "2020-07-13",  "created": "2020-07-13 13:59:02"}


Структура определена. Чтобы посчитать latency нам нужен временной промежуток. Засекаем с помощью функции microtime:
$beginTime = microtime(true);// код который необходимо отслеживать$latency = microtime(true) - $beginTime;


Для упрощения реализации, будем использовать фреймворк laravel и библиотеку laravel-entry. Добавим модель (таблица profile_logs):
class ProfileLog extends \Bavix\Entry\Models\Entry{    protected $fillable = [        'hostname',        'project',        'version',        'userId',        'sessionId',        'requestId',        'requestIp',        'eventName',        'target',        'latency',        'memoryPeak',        'date',        'created',    ];    protected $casts = [        'date' => 'date:Y-m-d',        'created' => 'datetime:Y-m-d H:i:s',    ];}


Напишем метод tick (я сделал сервис ProfileLogService), который будет записывать сообщения в Redis. Получаем текущее время (наш beginTime) и записываем его в переменную $currentTime:
$currentTime = \microtime(true);


Если тик по событию вызван впервые, то записываем его в массив тиков и завершаем метод:
 if (empty($this->ticks[$eventName])) {    $this->ticks[$eventName] = $currentTime;    return;}


Если тик вызывается повторно, то мы записываем сообщение в Redis, с помощью метода rpush:
$tickTime = $this->ticks[$eventName];unset($this->ticks[$eventName]);Redis::rpush('events:profile_logs', \json_encode([    'hostname' => \gethostname(),    'project' => 'habr',    'version' => \app()->version(),    'userId' => Auth::id(),    'sessionId' => \session()->getId(),    'requestId' => \bin2hex(\random_bytes(8)),    'requestIp' => \request()->getClientIp(),    'eventName' => $eventName,    'target' => \request()->getRequestUri(),    'latency' => $currentTime - $tickTime,    'memoryPeak' => \memory_get_usage(true),    'date' => $tickTime,    'created' => $tickTime,]));


Переменая $this->ticks не статическая. Необходимо зарегистрировать сервис как singleton.

$this->app->singleton(ProfileLogService::class);


Размер пачки ($batchSize) можно сконфигурировать, рекомендуется указывать небольшое значние (например, 10,000 элементов). При возникновении проблем (к примеру, не доступен ClickHouse), очередь начнет уходить в failed, и вам необходимо отлаживать данные.

Напишем крон-команду:
$batchSize = 10000;$key = 'events:profile_logs'do {    $bulkData = Redis::lrange($key, 0, \max($batchSize - 1, 0));    $count = \count($bulkData);    if ($count) {        // все данные храним в json, необходимо применить decode        foreach ($bulkData as $itemKey => $itemValue) {            $bulkData[$itemKey] = \json_decode($itemValue, true);        }        // отправляем в очередь для записи в ch        \dispatch(new BulkWriter($bulkData));        // удаляем пачку из redis        Redis::ltrim($key, $count, -1);    }} while ($count >= $batchSize);


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

Перейдем к написанию консьюмера:
class BulkWriter implements ShouldQueue{    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;    protected $bulkData;    public function __construct(array $bulkData)    {        $this->bulkData = $bulkData;    }    public function handle(): void    {            ProfileLog::insert($this->bulkData);        }    }}


Итак, формирование пачек, отправка в очередь и консьюмер разработаны можно приступать к профилированию:
app(ProfileLogService::class)->tick('post::paginate');$posts = Post::query()->paginate();$response = view('posts', \compact('posts'));app(ProfileLogService::class)->tick('post::paginate');return $response;


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



Данные в базе. Можно строить графики.

Grafana


Теперь перейдем к графическому представлению данных, что является ключевым элементом этой статьи. Необходимо установить grafana. Опустим процесс установки для debain-подобных сборок, можно воспользоваться ссылкой на документацию. Обычно, этап установки сводится к apt install grafana.

На ArchLinux установка выглядит следующим образом:
yaourt -S grafanasudo systemctl start grafana


Сервис запустился. URL: http://localhost:3000

Теперь необходимо установить ClickHouse datasource plugin:
sudo grafana-cli plugins install vertamedia-clickhouse-datasource


Если установили grafana 7+, то ClickHouse работать не будет. Нужно внести изменения в конфигурацию:
sudo vi /etc/grafana.ini


Найдем строку:
;allow_loading_unsigned_plugins =


Заменим её на эту:
allow_loading_unsigned_plugins=vertamedia-clickhouse-datasource


Сохраним и перезапустим сервис:
sudo systemctl restart grafana


Готово. Теперь можем перейти в grafana.
Логин: admin / пароль: admin по умолчанию.



После успешной авторизации, нажмем на шестеренку. В открывшемся popup-окне выберем на Data Sources, добавим соединение с ClickHouse.



Заполняем конфигурацию кх. Нажимаем на кнопку Save & Test, получаем сообщение об успешном соединении.

Теперь добавим новый dashboard:


Добавим панель:


Выберем базу и соответствующие колонки для работы с датами:


Перейдем к запросу:


Получили график, но хочется конкретики. Давайте выведем средний latency с округлением даты-с-временем вниз до начала пятиминутного интервала:


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


Профилировщик, ни в коем случае, не является заменой инструментам: xhprof (facebook), xhprof (tideways), liveprof от (Badoo). А только дополняет их.

Весь исходный код находится на github модель профилировщика, сервис, BulkWriteCommand, BulkWriterJob и middleware (1, 2).

Установка пакета:
composer req bavix/laravel-prof


Настройка соединений (config/database.php), добавляем clickhouse:
'bavix::clickhouse' => [    'driver' => 'bavix::clickhouse',    'host' => env('CH_HOST'),    'port' => env('CH_PORT'),    'database' => env('CH_DATABASE'),    'username' => env('CH_USERNAME'),    'password' => env('CH_PASSWORD'),],


Начало работы:
use Bavix\Prof\Services\ProfileLogService;// ...app(ProfileLogService::class)->tick('event-name');// кодapp(ProfileLogService::class)->tick('event-name');


Для отправки пачки в очередь нужно добавить команду в cron:
* * * * * php /var/www/site.com/artisan entry:bulk


Также необходимо запустить консьюмер:
php artisan queue:work --sleep=3 --tries=3

Рекомендуется настроить supervisor. Конфиг (5 консьюмеров):
[program:bulk_write]process_name=%(program_name)s_%(process_num)02dcommand=php /var/www/site.com/artisan queue:work --sleep=3 --tries=3autostart=trueautorestart=trueuser=www-datanumprocs=5redirect_stderr=truestopwaitsecs=3600


UPD:
1. ClickHouse нативно умеет тянуть данные из очереди kafka. Спасибо, sdm
Источник: habr.com
К списку статей
Опубликовано: 14.07.2020 10:11:05
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Визуализация данных

Высокая производительность

Laravel

Open source

Php

Clickhouse

Clickhouse-grafana

Redis

Queue broker

Queue

Profiling

Категории

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

© 2006-2020, personeltest.ru