tgoop.com/ntuzov/617
Last Update:
Из предыдущего поста выяснилось, что далеко не все понимают что это, а ведь это штука крайне важная, полезная и зачастую незаменимая. Что ж, давайте разбираться.
Первым делом, посмотрите на изображение.
Кратко: логарифмическая шкала решает проблему левого графика. Возможно, многим уже тут всё станет ясно.
А проблема заключается в том, что когда вы пытаетесь изобразить на графике набор значений с очень сильным разбросом, то близкие значения сливаются воедино.
К примеру, представьте, что у вас есть множество микросервисов, и вы хотите изобразить на общем графике их суммарный RPS, а также RPS отдельных сервисов. Конечно, суммарный RPS будет на порядки больше, поэтому остальные сольются воедино где-то около нуля. Такой график не очень наглядный, но как с этим быть?
Можно просто убрать суммарный график, и тогда масштаб выровняется (хотя, и это не гарантировано, ведь могут быть отдельные сервисы, у которых RPS на порядки больше, чем у других), но нам всё же хочется видеть их все одновременно.
Решение заключается в том, чтобы сделать логарифмическую шкалу. Посмотрите на правый график: там мы одновременно видим и общий RPS системы (~8000-9000), и промежуточный платежный сервис (~600-700), и совсем маленькие сервисы (5-35 RPS). Причём каждый из них визуально занимает достаточное пространство, что позволяет легко заметить изменения в любом из них.
Как это работает?
На обычном линейном графике одинаковые абсолютные изменения отображаются одинаковыми расстояниями на шкале:
- Разница между 10 и 20 RPS отображается так же, как между 8000 и 8010 RPS
- Рост с 20 до 40 RPS выглядит абсолютно не так, как рост с 2000 до 4000 RPS
На логарифмическом графике всё иначе:
- Одинаковые пропорциональные изменения (например, рост в 2 раза) отображаются одинаковыми расстояниями
- Рост с 10 до 100 RPS отображается так же, как рост с 1000 до 10000 RPS
- Рост с 20 до 40 RPS (в 2 раза) отображается точно так же, как рост с 4000 до 8000 RPS (тоже в 2 раза)
Математически это значит, что вместо самого значения X мы откладываем на оси log(x). Благодаря этому мультипликативные изменения (умножение на константу) превращаются в аддитивные (прибавление константы), что делает график намного информативнее.
Вспомните, как растёт график логарифма — чем дальше он идёт, тем медленнее растёт (его скорость обратная к скорости роста экспоненты, если вам так проще).
Но, ещё раз обращаю внимание, тут речь только шкалу Y — чем выше её значения, тем меньше расстояние между ними.
Когда это особенно полезно?
- При мониторинге микросервисов — как видно на нашем графике, сервисы с разной нагрузкой становятся одинаково хорошо видны
- Для метрик latency — p50, p95, p99 и p99.9 перцентили часто различаются в разы, и на линейном графике p50 и p95 сольются в линию внизу
- Для графиков памяти — утечка памяти, начинающаяся с малых значений, будет заметна сразу, а не когда уже станет критичной
- Для ошибок и падений сервисов — когда их количество мало относительно успешных запросов, но важно видеть даже малейший рост
- При анализе масштабируемости — когда изучаете, как ваша система справляется с ростом нагрузки в разы
Практический пример
Представьте, что на вашем графике:
- Общий RPS системы в норме ~8000
- Поисковый сервис в норме ~10 RPS
- Внезапно RPS поискового сервиса подскочил до 50 (в 5 раз!)
На линейном графике вы, скорее всего, вообще не заметите этого изменения — оно затеряется где-то на уровне шума. А на логарифмическом графике скачок будет виден очень чётко, и вы сразу поймёте, что с поисковым сервисом что-то не так.
Когда НЕ стоит использовать логарифмическую шкалу
- Когда в ваших данных есть нули или отрицательные значения (логарифм от них не определён). Хотя, некоторые современные системы умеют и с этим работать, но вы должны хорошо понимать как это работает.
- Когда абсолютные значения важнее относительных изменений
- Для в процентах (0-100%), где линейная шкала обычно наглядней — например, график CPU
#guide
