Следует ли монотонно увеличивать счетчики в телеметрии

Question

Здравствуйте,
Мне было интересно, какова стандартная передовая практика хранения значений счетчиков в базе данных временных рядов. Должно ли быть постоянно увеличивающееся значение, такое как 10, 20, 30, показывающее в каждый момент общее значение этого счетчика. Или это должно быть 10, 10, 10, показывающее значение счетчика в течение этого конкретного временного интервала и затем сброс его до 0, когда это значение было сообщено в TSDB. Проблема с первым подходом заключается в том, что при перезапуске сервера и т. Д. Это значение счетчика будет сброшено на 0, а также как некоторая точка, величина счетчика может переполняться.

Answer 1

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

Что касается недостатков, в OpenTSDB вы можете указать, что метрика является счетчиком, и сервер будет заботиться о переполнениях и сбросить на 0 для вас.

От OpenTSDB docs:

OpenTSDB 2.0 обеспечивает поддержку для специальной монотонно возрастающей обработки данных счетчика включая возможность установить «опрокидывание» значение и подавить аномальные колебания. Когда значение counterMax равно , указанному в запросе, если точка данных приближается к этому значению, а точка после меньше, чем предыдущая, максимальное значение будет использовано для , чтобы вычислить точную скорость с учетом двух точек. Например, если записывали целочисленный счетчик на 2 байта, максимальное значение было бы - 65535. Если значение при t0 равно 64000, а значение при t1 равно 1000, то результирующая скорость в секунду будет рассчитана как -63000. Однако мы знаем, что это, вероятно, счетчик перевернулась, чтобы мы могли установить максимальное до 65535, а теперь расчет будет 65535 - t0 + t1, чтобы дать нам 2535.

системы, которые отслеживают данные счетчиков часто возвращаются к 0 при перезапуске. Когда это произойдет, и мы можем получить побочный результат при использовании функции счетчика максимум . Например, если счетчик достиг 2000 в t0, а кто-то перезагружает сервер, следующее значение может быть 500 при t1. Если мы установили наш максимум 65535, результат будет 65535 - 2000 + 500, чтобы дать нам 64035. Если нормальная скорость составляет несколько точек в секунду, этот особый шипс 30 секундами между точками создаст скачок скорости из 2 134,5! Чтобы этого избежать, мы можем установить resetValue, который, когда превышает это значение, возвращает точку данных 0, чтобы избежать шипов в любом направлении. В приведенном выше примере, если мы знаем, что наша скорость почти никогда не превышает 100, мы могли бы сконфигурировать значение resetValue 100 , и когда вычисляется вышеуказанная точка данных, она вернет 0 вместо из 2,134.5. Значение по умолчанию 0 означает, что значение сброса будет проигнорировано, ставки не будут подавлены.

Answer 2

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

См Axibase Time Series Database COUNTER and DELTA examples