Понимание метрик и временных рядов

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

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

В OpenTSDB метрика называется строкой, например, http.hits. Чтобы иметь возможность хранить все различные значения для всех мест, где существует эта метрика, вы добавляете к данным одну или несколько меток при их отправке в TSD. TSD хранит временную метку, значение и метки. Когда вы хотите получить эти данные, TSD извлекает все значения для заданного вами временного интервала, необязательно с фильтром меток, которые вы предоставили, агрегирует все эти значения по своему усмотрению и отображает график этого значения во времени.

Здесь есть ряд вещей, которые мы представили до сих пор. Чтобы помочь вам понять, как работают вещи, я начну с типичного примера. Допустим, у вас есть несколько веб-серверов, и вы хотите отслеживать две вещи: количество обращений к веб-серверу и среднюю загрузку системы. Давайте придумаем имена метрик для выражения этого. Для средней загрузки назовем её proc.loadavg.1min (так как в Linux вы легко можете получить эти данные, прочитав /proc/loadavg). Для многих веб-серверов существует возможность запросить у веб-сервера счетчик, выражающий количество обращений к серверу с момента его запуска. Это удобный счетчик, который можно использовать для метрики, которую мы назовем http.hits. Я выбрал эти два примера по двум причинам. Во-первых, мы увидим, как OpenTSDB легко обрабатывает как счетчики (значения, которые увеличиваются со временем, за исключением случаев их сброса при перезапуске/перезагрузке или переполнении), так и обычные значения, которые возрастают и убывают, как средняя нагрузка. Преимущество OpenTSDB заключается в том, что вам не нужно производить какие-либо расчеты скорости ваших счетчиков. Это сделает за вас. Вторая причина заключается в том, что мы также можем показать вам, как вы можете отобразить две разные метрики с разными масштабами на одном графике, что является отличным способом сопоставить разные метрики.

Ваши первые точки данных

Не углубляясь в подробности того, как коллекторы отправляют данные в TSD, вы создаете коллектор, который периодически отправляет текущее значение этих точек данных для каждого сервера в TSD. Чтобы TSD мог агрегировать данные с нескольких хостов, вы помечаете каждое значение меткой «host». Таким образом, если у вас есть веб-серверы A, B, C и т. д., они периодически отправляют в TSD что-то вроде этого:

put http.hits 1234567890 34877 host=A
put proc.loadavg.1min 1234567890 1.35 host=A

Здесь «1234567890» — это текущее время эпохи (date +%s) в секундах. Следующее число — значение метрики в это время. Это данные с хоста A, поэтому он помечен меткой host=A. Данные с хоста B будут помечены меткой host=B, и так далее. Со временем вы получите множество временных рядов, хранящихся в OpenTSDB.

Ваш первый график

Теперь давайте вернемся к тому, о чем мы говорили в начале. Временной ряд — это последовательность точек данных некоторой конкретной метрики (и ее меток) во времени. В этом примере каждый хост отправляет в TSD два временных ряда. Если у вас было 3 устройства, каждое из которых отправляет эти два временных ряда, TSD будет собирать и хранить 6 временных рядов. Теперь, когда у вас есть данные, давайте начнем построение графиков.

Чтобы отобразить количество HTTP-запросов, просто перейдите в пользовательский интерфейс и введите http.hits в качестве имени метрики и укажите диапазон времени. Установите флажок «Скорость», так как эта метрика является счетчиком скорости, и вуаля, у вас есть график скорости HTTP-запросов к вашим веб-серверам с течением времени.

Агрегаторы

По умолчанию в пользовательском интерфейсе каждая метрика для каждого хоста агрегируется путем их суммирования. Это означает, что TSD берет три временных ряда с этой метрикой (host=A, B и C) и складывает их значения, чтобы получить общее количество обращений со всех веб-серверов в определенное время. Обратите внимание, что вам не нужно отправлять свои точки данных в точное время, TSD сам разберется. Итак, если каждый из ваших хостов обслуживал 1000 запросов в секунду в определенный момент времени, график покажет 3000. А как вы хотите показать, сколько запросов обслуживал каждый веб-сервер? Есть два способа. Если вас интересует среднее количество запросов, обслуживаемых каждым веб-сервером, просто измените метод агрегации со «суммы» на «среднее». Вы также можете попробовать другие (макс., мин.), чтобы увидеть максимальное или минимальное значение. Более функции агрегации находятся в разработке (перцентили и т. д.). Это делается на основе интервала, поэтому если в какой-то момент времени один из ваших веб-серверов обслуживал 50 QPS, а другие — 100, а позже другой веб-сервер обслуживал 50 QPS, а другие — 100, для этих двух точек значение «мин» будет 50. Другими словами, он не определяет, какой временной ряд был минимальным в целом и просто отображает график этого хоста. Другой способ увидеть, сколько запросов обслуживает каждый веб-сервер? Здесь мы смотрим на поля меток.

Обработка выборочных данных

Чтобы уменьшить количество возвращаемых точек данных, вы можете указать интервал и метод обработки выборочных данных, например, 1ч-среднее или 1д-сумма. Это также полезно (например, при использовании макс. и мин.) для определения максимальных и минимальных значений в заданный период. Обработка выборочных данных наиболее полезна для уменьшения нагрузки на фазу построения графиков и повышения читаемости, особенно при построении графиков большего количества точек данных, чем пикселей экрана.

Фильтры меток

В пользовательском интерфейсе вы увидите, что TSD заполнил одну или несколько «меток», первая из которых — host. Это означает, что TSD в этом временном диапазоне видит, что данные были помечены меткой host. Вы можете отфильтровать график, чтобы он отображал только значение одного хоста. Если вы введете A в строку host, вы отобразите значения хоста A с течением времени. Если вы хотите отобразить список хостов, введите список хостов, разделенных символом «|», например, A|B. Это даст вам два графика вместо одного, один для A и один для B. Наконец, вы также можете указать специальный символ *, который означает построение линии для каждого хоста.

Добавление дополнительных метрик

Итак, теперь у вас есть график ваших веб-обращений. Как это коррелируется со средней нагрузкой? На этом же графике щелкните вкладку «+», чтобы добавить новую метрику к существующему графику. Введите proc.loadavg.1min в качестве метрики и нажмите «Правая ось», чтобы масштаб оси Y был отделен и его метки были справа. Убедитесь, что флажок «Скорость» не установлен, так как средняя нагрузка не является метрикой скорости. Вуаля! Теперь вы можете увидеть, как изменения в скорости веб-обращений влияют на среднюю загрузку вашей системы.

Усложнение

Представьте, что на каждом из ваших серверов работают два веб-сервера, скажем, один для статического контента и один для динамического контента. Вместо создания другой метрики просто добавьте метку к метрике http.hits с указанием экземпляра сервера. Попросите ваш коллектор отправлять данные, например:

put http.hits 1234567890 34877 host=A webserver=static put http.hits 1234567890 4357 host=A webserver=dynamic put proc.loadavg.1min 1234567890 1.35 host=A

Почему это делается вместо создания другой метрики? Что если вам иногда нужно отображать общее количество HTTP-обращений, а иногда вам нужно разбить статические и динамические обращения? С меткой это легко. С этой новой меткой в пользовательском интерфейсе при отображении этой метрики появится метка веб-сервера. Вы можете оставить ее пустой, и она будет агрегировать оба значения в один график (в соответствии с вашим параметром агрегации), и вы увидите общее количество обращений, или вы можете использовать webserver=* для того, чтобы отобразить, сколько в совокупности выполняют ваши статические и динамические экземпляры на ваших веб-серверах. Вы можете даже углубиться и указать webserver=* и host=* для полного разбиения.

Рекомендации по созданию метрик

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

Метки против метрик

Метрика должна представлять собой что-то конкретное, например, «пакеты Ethernet», но не должно быть разбито по конкретному экземпляру вещи. Как правило, вам не следует собирать метрики, такие как net.bytes.eth0, net.bytes.eth1 и т. д. Собирайте net.bytes и помечайте точки данных eth0 меткой iface=eth0 и т. д. Не стоит создавать отдельные метрики «вход» и «выход». Добавьте метку direction=in или direction=out. Таким образом, вы можете легко увидеть общий сетевой трафик для данного устройства, не имея необходимость отображать множество метрик. Это по-прежнему позволяет вам детализировать и отображать активность только для определенного интерфейса или только для определенного направления.

Счетчики и скорости

Если что-то является счетчиком или по своей природе является скоростью, не преобразовывайте его в скорость перед отправкой в TSD. Для этого есть две основные причины. Во-первых, выполнение собственных расчетов скорости, обработка сброса/переполнения и т. д. — это пустая трата времени, поскольку TSD может сделать это за вас. Вам также не нужно беспокоиться о правильности расчета скорости в единицах в секунду на основе слегка неточного или меняющегося интервала выборки. Во-вторых, если произойдет ситуация, когда вы потеряете одну или несколько точек данных, если вы отправляете текущее значение счетчика, вы не потеряете данные, а только разрешение этих данных. Золотое правило в TSD заключается в том, что если ваши исходные данные являются счетчиком (некоторый счетчик из /proc или SNMP), оставьте их такими. Не преобразуйте их. Если вы пишете собственного коллектора (например, тот, который считает, как часто появляется определенное сообщение об ошибке в tail -f журнала), не сбрасывайте свой счетчик в каждом интервале выборки. Позвольте TSD сделать эту работу.

Метки — ваши помощники

В любой среде, кроме очень небольшой, у вас, вероятно, есть кластеры или группы машин, выполняющих одно и то же. Однако со временем они меняются. Это нормально. Просто используйте метку при отправке данных в TSD, чтобы передать информацию о кластере. Добавьте что-то вроде cluster=webserver ко всем точкам данных, отправляемым с каждого из ваших веб-серверов, и cluster=db для всех ваших баз данных и т. д.

Теперь, когда вы отображаете активность процессора для кластера веб-серверов, вы видите все их агрегированные в одном графике. Затем, допустим, вы добавляете веб-сервер или даже изменяете его с веб-сервера на базу данных. Все, что вам нужно сделать, это убедиться, что правильная метка отправляется, когда меняется его роль, и теперь активность процессора этого устройства учитывается в правильном кластере. Более того, все ваши исторические данные остаются корректными! В этом и заключается настоящая сила OpenTSDB. Вы не только никогда не теряете разрешение своих точек данных с течением времени, как в системах на основе RRD, но и исторические данные не теряются, когда ваши устройства перегруппировываются. Вам также не нужно добавлять логику кластеризации или группировки в свои панели мониторинга.

Точность метрик и меток

Максимальное количество меток, разрешенных для точки данных, определяется константой (Const.MAX_NUM_TAGS), которая на момент написания составляет 8. Имена метрик, имена меток и значения меток должны состоять из буквенно-цифровых символов, дефиса «-», подчеркивания «_», точки «.» и косой черты «/», как это проверяет пакетная функция Tags.validateString.