Онлайн
Alvaros
.
- Регистрация
- 14.05.16
- Сообщения
- 21.452
- Реакции
- 101
- Репутация
- 204
прим. 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 команды:
You must be registered for see links
,
You must be registered for see links
и
You must be registered for see links
.С помощью команды 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 нам нужен временной промежуток. Засекаем с помощью функции
You must be registered for see links
:$beginTime = microtime(true);
// код который необходимо отслеживать
$latency = microtime(true) - $beginTime;
Для упрощения реализации, будем использовать фреймворк laravel и библиотеку
You must be registered for see links
. Добавим модель (таблица 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
rofile_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
rofile_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:
aginate');$posts = Post::query()->paginate();
$response = view('posts', \compact('posts'));
app(ProfileLogService::class)->tick('post:
aginate');return $response;
Если все сделано верно, то данные должны находиться в Redis. Запутим крон-команду и отправим пачки в очередь, а уже консьюмер вставит их в базу.
Данные в базе. Можно строить графики.
Grafana
Теперь перейдем к графическому представлению данных, что является ключевым элементом этой статьи. Необходимо установить
You must be registered for see links
. Опустим процесс установки для debain-подобных сборок, можно воспользоваться
You must be registered for see links
. Обычно, этап установки сводится к apt install grafana.На ArchLinux установка выглядит следующим образом:
yaourt -S grafana
sudo systemctl start grafana
Сервис запустился. URL:
You must be registered for see links
Теперь необходимо установить
You must be registered for see links
: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
Готово. Теперь можем перейти в
You must be registered for see links
.Логин: admin / пароль: admin по умолчанию.
После успешной авторизации, нажмем на шестеренку. В открывшемся popup-окне выберем на Data Sources, добавим соединение с ClickHouse.
Заполняем конфигурацию кх. Нажимаем на кнопку «Save & Test», получаем сообщение об успешном соединении.
Теперь добавим новый dashboard:
Добавим панель:
Выберем базу и соответствующие колонки для работы с датами:
Перейдем к запросу:
Получили график, но хочется конкретики. Давайте выведем
You must be registered for see links
latency с
You must be registered for see links
:
Теперь на графике отображаются выбранные данные, можем ориентироваться на них. Для оповещений настроить триггеры, группировать по события и многое другое.
Профилировщик, ни в коем случае, не является заменой инструментам:
You must be registered for see links
,
You must be registered for see links
,
You must be registered for see links
. А только дополняет их.Весь исходный код находится на
You must be registered for see links
—
You must be registered for see links
,
You must be registered for see links
,
You must be registered for see links
,
You must be registered for see links
и middleware (
You must be registered for see links
,
You must be registered for see links
).Установка пакета:
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
Рекомендуется настроить
You must be registered for see links
. Конфиг (5 консьюмеров):[program:bulk_write]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/site.com/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
user=www-data
numprocs=5
redirect_stderr=true
stopwaitsecs=3600