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



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

Именно тут MDD (Metric-driven Development) приходится как нельзя кстати. MDD — это методология разработки, основанная на измерении всего — от производительности до дохода. Она была представлена в 2012 году на дне DevOps в Риме, и применяется в таких компаниях как Spotify, StackEngine и во многих других, использующих философию Lean Startup.

Принципы MDD

1. Мониторинг — это часть кода

Кастомные метрики должны быть встроены прямо в код. Например, счётчик или таймер на важном участке кода:

$ts = microtime(true);
facebook_get_photos($user_id);
track_time('api.facebook.photos_fetch', microtime(true) - $ts)

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

$_SESSION['user_id'] = $user_id;
track('user.signin');

if ( !$has_photo )
{
    $ask_for_upload = true;
    track('user.has_no_photo');
}

2. Более эффективный дебаг

MDD — это не серебряная пуля, ошибки могут и будут появляться в продакшне. MDD предоставляет хорошую основу для отлавливания ошибок, которые тяжело или невозможно проверить лабораторным путем.

Допустим, программист Пётр, тимлид, ведет приложение для составления тренировок используя технику TDD (test-driven development). Приложение готово и выходит в продакшн, все тесты работают. Но попав к новым пользователям, обнаруживается баг — при синхронизации с Google календарем, часть тренировок пропадает. В данном случае TDD не помог избежать бага. Да и никакая методика не помогла бы. Но MDD позволит быстрее найти и сам баг и его причину:

$calendar_events = [];
track('api.calendar.try');

$google_events = call_google_api($user_id);
if ( $google_events ) track('api.calendar.success');

3. Мерять нужно много, но не все

Часто, начав использовать MDD, команда начинает следовать анти-паттерну — «мониторить все подряд». Хороший способ проверить полезность метрики — это спросить себя, зачем эта метрика может понадобиться.

Итеративное направление MDD основывается на постоянном добавлении новых метрик и удалении устаревших. Неиспользованные метрики не только занимают место в коде, но и требуют дополнительных ресурсов.

Предположим, необходимо отследить все запросы к внешнему сервису. Для этого не нужно каждое обращение к этому сервису оборачивать в счётчик — выйдет не код, а вермишель. Лучше посчитать успешность группы событий. Добавление метрик «а может пригодится» не оправдает себя:

track('uploads.started');
$file = $_FILES['file']['tmp_name'];
if ( $file ) track('uploads.uploaded');

$name = $some_random . '.jpg';
if ( move_uploaded_file($file, $name) ) track('uploads.moved');

exec('convert - strip ' . $name . ' ' . $name, $o, $r);
if ( !$r ) track('uploads.converted');
else unlink($name);

if ( is_file($name) ) track('uploads.finished');

Очевидно, что для проверки этого кода будет достаточно первой и последней метрики.

4. Системные и бизнес метрики в одном месте

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



Не смотря на банальность, этот пункт важен для достижения эффективности при реагировании на проблемы. Допустим у Вас просела конверсия с 14:45 до 15:15. Чтобы найти причину Вам нужно проверить ряд гипотез — сломалось что-то? Может это новая функция? Может нагрузка выросла? А может отпал важный маркетинговый канал? Если все эти метрики будут находиться в пределах одной платформы, ответы можно будет получить быстрее (и даже автоматически, с помощью обнаружения корреляций).

5. Дашборды и алерты

Дашборды — это важная часть MDD. При работе над какой-то частью продукта выбираются релевантные метрики и выводятся на монитор. Это позволяет постоянно быть в курсе и сразу понимать влияние изменений. Нормальная практика — это создание новых дашбордов каждые несколько дней.

Алерты помогут следить за важными показателями без необходимости постоянно проверять их руками. На начальном этапе у Вас будет 10 метрик, но уже скоро их станет 100, потом 1000 и так далее. Сольем небольшой инсайт — на одном из крупных русских социальных ресурсов их 17 тысяч. За таким количеством метрик уследить невозможно. Настройте правила и попросите Вашу систему анализа проверять метрики за Вас.

Некоторые инструменты

Graphite

Opensource система Graphite хранит данные и рендерит их по запросу. Поддерживает разную «математику» и очень прост в использовании:

echo "test.bash.stats 42 `date +%s`" | nc graphite.example.com 2003

t.onthe.io

Сервис t.onthe.io — что-то вроде облачного Графита. Основные фичи тут — это автоматическое обнаружение аномалий и корреляций. Поддерживает протокол statsd.

$api_id = 1;
$api_key = "aslkdj";
$metric = "users.payment";
$track_url = "https://tapi.onthe.io/?k={$api_id}:{$metric}&s=" .
             md5("{$api_id}:{$metric}{$api_key}";
file_get_contents($track_url);

Librato

Librato ориентирован на мониторинг — в пакете уже есть плагины для различных сервисов:

<?php
use Services\Librato\Metrics\Metric;
$metric = new Metric('counter');
$metric->value = 1;
?>

Метрики добавляются через дашборд. Подробнее об API в документации.

StatHat

Stathat умеет строить прогнозы, очень удобно для ответа на вопрос — «когда нужно будет ставить новый сервер»:

stathat_ez_count('info@stathat.com', 'queue.pushed', 1);

Конспект

1. MDD — крутая методология разработки основанная на метриках.
2. Мерить нужно много, но далеко не все.
3. Удобные инструменты: librato, StatHat, Graphite и t.