Объясняем, чем TSDB отличаются от SQL/NoSQL, почему они лучше подходят для метрик и алертов, и как выбрать хранилище для наблюдаемости.
Метрики — это числовые измерения работы системы: загрузка CPU, время ответа API, количество заказов в минуту, доля ошибок 5xx. Обычно они собираются регулярно (например, каждые 10–60 секунд) и позволяют видеть поведение сервиса «в цифрах».
Мониторинг отвечает на вопрос: «Всё ли сейчас в порядке?» Он строится на текущих значениях и порогах: если ошибок стало слишком много или задержка выросла — нужен сигнал.
Наблюдаемость шире: «Почему так произошло и что делать дальше?» Она соединяет метрики с логами, трассировками и контекстом — чтобы быстро найти причину.
У метрик почти всегда есть два измерения: значение и момент времени (плюс метки/лейблы вроде service=checkout, region=eu). Поэтому базовая форма таких данных — временной ряд: последовательность точек, где важны тренды, сезонность, пики и отклонения.
В работе с метриками редко интересна «одна точка». Важнее:
Если хранить метрики «как обычные записи» в универсальной БД, быстро всплывают типичные боли: объём точек растёт лавинообразно, запросы по диапазонам времени становятся дорогими, а агрегации (например, «среднее за минуту по сервису») начинают тормозить.
Дополнительно усложняют жизнь метки: их комбинации размножают ряды, что приводит к росту данных и усложняет запросы. Без оптимизаций под временные ряды стоимость и задержки мониторинга увеличиваются.
Вы разберётесь, когда нужна TSDB, какие свойства важны для мониторинга и алертов, как избежать типичных ловушек (вроде взрывной кардинальности), и как продумать хранение: сроки retention, downsampling и запросы по времени — так, чтобы метрики помогали, а не превращались в неподъёмный расход.
TSDB (Time-Series Database) — это база данных, оптимизированная для хранения и анализа временных рядов: данных, где каждое измерение привязано ко времени.
В простом виде одно измерение — это:
service="checkout", instance="10.0.0.12", region="eu").Один и тот же показатель (например, CPU) превращается во множество рядов из‑за разных меток: CPU по каждому серверу, по каждому контейнеру и т. д.
Чаще всего это метрики мониторинга и измерения с датчиков:
Метрики — это числа во времени, удобные для графиков и агрегатов (среднее, перцентили, суммарно «за 5 минут»).
Логи — это события и сообщения (часто текст), полезные для разбора конкретного инцидента.
Трассировки показывают путь конкретного запроса через сервисы и его «спаны» (где именно потратилось время).
TSDB в первую очередь про метрики: они пишутся часто (каждые 1–60 секунд, иногда чаще) и читаются обычно агрегатами — например, «средняя задержка по сервису за последние 15 минут» или «95‑й перцентиль по endpoint’у за час». Поэтому TSDB умеют быстро принимать поток точек и так же быстро строить запросы по окнам времени.
Метрики — это особый режим работы: вы постоянно пишете новые точки и почти никогда не обновляете старые. Обычные реляционные БД и даже многие универсальные NoSQL могут хранить такие данные, но при росте нагрузки быстро упираются в стоимость записи, индексов и запросов.
Типичный мониторинг генерирует непрерывный ingest: каждую секунду/10 секунд приходят значения CPU, памяти, задержек, очередей, ошибок. Это миллионы маленьких вставок в час.
В классической БД каждая вставка может затрагивать индексы, журнал транзакций, проверки ограничений. Итог — высокие накладные расходы на одну точку и рост латентности записи. TSDB оптимизируют именно потоковую запись: группируют точки, пишут последовательными блоками и минимизируют случайные операции на диске.
Запросы к метрикам почти всегда выглядят так: «покажи за последние 15 минут/24 часа» плюс агрегации (среднее, p95, sum) и скользящие окна. В универсальных БД такие запросы часто приводят к сканированию больших объёмов и дорогим group-by.
TSDB хранят данные по времени и заранее оптимизируют range scan и агрегирование по интервалам, чтобы графики и дашборды открывались быстро даже на больших объёмах.
Метрики хорошо сжимаются: значения обычно близки друг к другу, а время идёт монотонно. TSDB раскладывают данные по временным чанкам/сегментам и применяют эффективное сжатие, уменьшая размер хранения и ускоряя чтение нужного диапазона.
Для метрик почти всегда есть «срок годности»: оперативные данные нужны детально, а старые — реже и грубее. TSDB поддерживают retention/TTL как базовую функцию: автоматически удаляют старые чанки без дорогих DELETE по строкам, что в обычных БД часто превращается в постоянную борьбу с фрагментацией и обслуживанием.
Кардинальность меток — это количество уникальных комбинаций значений меток у метрики. Чем больше комбинаций, тем больше отдельных временных рядов нужно хранить и обслуживать. Именно это чаще всего «убивает» хранение метрик: растёт объём памяти, индекс раздувается, запросы и алерты начинают тормозить.
В TSDB (и особенно в системах вроде Prometheus) отдельный временной ряд определяется именем метрики + набором меток. Если у вас 10 сервисов, 5 регионов и 3 статуса — это ещё управляемо. Но добавьте метку с тысячами/миллионами значений, и количество рядов взлетит на порядки.
Эффекты высокой кардинальности обычно выглядят так:
Метка user_id или session_id почти всегда делает кардинальность неконтролируемой: каждое новое значение рождает новый ряд. Для отладки единичных пользователей это удобно, но для мониторинга — ошибка. Такие данные лучше писать в логи/трейсы (например, через OpenTelemetry) и искать там, а в метриках держать агрегаты: количество запросов, процент ошибок, p95/p99 задержки.
TSDB строят индекс по меткам так, чтобы быстро находить нужные серии по фильтрам (например, service="api" AND status="500"). Но при высокой кардинальности сам индекс становится тяжёлым: больше уникальных значений, больше списков серий, больше операций на пересечения.
Держите метки «ограниченными» по множеству значений: service, env, region, status, endpoint (если он нормализован). Убирайте динамические идентификаторы, объединяйте похожие значения (нормализация путей), а детализацию переносите в логи/трейсы. Если нужен разрез по пользователям — делайте агрегирование заранее (топ-N, бакеты, выборки), а не храните «каждого пользователя» как отдельный ряд.
TSDB выигрывают не только на записи метрик, но и на чтении: большинство запросов к метрикам — это «что происходило в интервале времени» плюс агрегации и группировки по меткам. Под такие паттерны движки временных рядов оптимизируют хранение, индексацию и выполнение запросов.
В классической SQL-БД вы часто опираетесь на B-tree индексы по колонкам и выполняете фильтрацию строк. В TSDB данные обычно организованы как наборы точек по сериям (time series), где серия определяется метками (например, service, instance, status).
Типично:
service="api" AND status=~"5..".В результате TSDB сначала выбирает набор серий по меткам, а затем читает только нужные временные окна этих серий — вместо сканирования большой таблицы.
Запросы «за последние 15 минут/сутки/неделю» выполняются через чтение компактных временных блоков (часто сжатых и отсортированных по времени). Это снижает I/O: движок не трогает данные вне окна и может заранее пропускать целые блоки по метаданным.
Метрики почти всегда требуют вычислений «на лету»:
sum/avg/min/max, перцентили (p95) по гистограммам;group by по меткам (например, по service или region);rate()/increase() для счётчиков.TSDB держат данные так, чтобы эти операции выполнялись потоково по отсортированному времени и с минимальной распаковкой.
Если вы регулярно строите тяжёлые дашборды (например, p95 по всем сервисам за 30 дней с разрезом по нескольким меткам), выгодно заранее хранить «сводки» — downsampled ряды или материализованные агрегации. Это ускоряет запросы и делает стоимость предсказуемой, особенно при росте кардинальности.
Метрики почти всегда «текут» непрерывно: каждую секунду, 10 секунд или минуту. Если хранить сырые точки (raw) годами, объём растёт очень быстро, а запросы по длинным периодам становятся дорогими. Поэтому в TSDB обычно разделяют два решения: retention (сколько хранить) и downsampling/rollups (в каком разрешении хранить со временем).
Downsampling — это агрегирование данных в более крупные интервалы: например, из 10-секундных значений сделать минутные, а затем часовые. Для дашбордов за неделю или месяц редко нужна секундная точность — важнее тренд и стабильное время ответа.
Пример типичных агрегатов для rollup:
Практика — держать несколько уровней детализации:
Так графики за год строятся быстро: TSDB читает уже агрегированные серии, а не миллиарды точек.
Цена downsampling — потеря деталей. Усреднение может скрыть короткие всплески, поэтому важно сохранять минимум/максимум или перцентили. Хорошее правило: если метрика используется для алерта по пику, убедитесь, что пик не исчезнет на этапе агрегации.
Задайте политики по важности:
Так вы контролируете стоимость без потери ключевой аналитики и сохраняете предсказуемую производительность при росте объёма данных.
Когда метрики используются для алертов, TSDB перестаёт быть «просто хранилищем». Она становится частью контура принятия решений: вовремя ли мы увидим проблему, не будет ли ложных срабатываний, переживёт ли система всплеск нагрузки.
Задержка данных (latency). Для on-call критично понимать, через сколько секунд после события метрика окажется доступной для вычисления правила. Источники задержек — сбор (scrape/ingest), сеть, запись, компакция, запрос. TSDB должна стабильно обслуживать «свежие» данные, а не только исторические.
Точность и согласованность. Алерты часто строятся на производных величинах (p95 latency, error rate). Если TSDB теряет точки, «склеивает» интервалы или по-разному агрегирует при повторных запросах, вы получаете прыгающие графики и нестабильные правила.
Устойчивость. В момент инцидента обычно растёт нагрузка на всю систему, включая мониторинг. Важно, чтобы TSDB держала высокий ingestion и частые запросы от дашбордов и алерт-менеджера, а при деградации — хотя бы сохраняла базовую функциональность.
Чтобы не пересчитывать тяжёлые запросы каждую минуту, используют заранее подготовленные ряды (recording rules): например, error_rate_5m, p95_latency_1m. Хорошая TSDB и экосистема вокруг неё позволяют:
Для стабильных алертов важны окна (например, 5–10 минут), гистерезис порогов и корректная обработка «нет данных». Отсутствие метрики может означать и норму (нет трафика), и проблему (сломался сбор). TSDB должна давать инструменты отличать эти случаи, иначе алерт будет то молчать, то «флапать».
Плохие метрики превращают дежурство в угадайку: много шума, мало сигнала, сложно найти первопричину. Чёткие имена, предсказуемые метки, понятные единицы измерения и стабильная кардинальность — это прямое снижение времени реакции и усталости команды.
TSDB редко живёт «сама по себе». Она становится центральным хранилищем метрик, вокруг которого строятся сбор, обработка, визуализация и алерты. Чем яснее вы понимаете весь путь метрики, тем проще избежать сюрпризов с задержками, потерями данных и расходами.
Практический контекст: чем быстрее вы выпускаете новые версии и добавляете интеграции, тем важнее заранее заложить наблюдаемость. Например, в TakProsto.AI — платформе vibe-coding для быстрого создания веб-, серверных и мобильных приложений через чат — команды часто ускоряют цикл изменений в разы, и стабильные метрики (ошибки, задержки, насыщение ресурсов) помогают не потерять контроль над качеством при росте скорости релизов.
На практике чаще всего работает такая схема:
агент/экспортер → сборщик → TSDB → визуализация.
Экспортеры снимают показатели (CPU, задержки, ошибки) с приложений и инфраструктуры. Сборщик (например, Prometheus или OTel Collector) отвечает за приём, первичную обработку (фильтрация, переименование, агрегация) и доставку в хранилище. TSDB оптимизирована под частые записи и запросы «по времени», а система визуализации (часто Grafana) — под дашборды и исследование.
Prometheus исторически работает по pull-модели: он сам опрашивает цели по расписанию. Это упрощает контроль (кто и как часто собирает), но повышает требования к сетевой доступности целей.
Когда метрик много или нужен длительный retention, Prometheus обычно дополняют удалённым хранилищем (remote write / remote read). В такой связке Prometheus остаётся «двигателем» сбора и алертов, а TSDB берёт на себя масштабируемое хранение и быстрые запросы по большим периодам.
OpenTelemetry помогает унифицировать сбор телеметрии: метрик, логов и трассировок. Частый паттерн — отправлять метрики через OTel Collector в TSDB, сохраняя совместимость с существующими источниками и минимизируя «зоопарк» агентов.
End-to-end наблюдаемость появляется, когда данные можно «склеить» по общим атрибутам: service.name, env, region, instance, deployment, trace_id (где уместно). Хорошая практика — договориться о единой таксономии тегов (меток) и применять её во всех сигналах.
Важно: добавляйте только те теги, которые действительно нужны для диагностики. Лишние измерения резко увеличивают кардинальность и делают стек дороже и медленнее.
TSDB часто начинают «на одном сервере», пока метрик мало. Проблемы появляются внезапно: поток записи растёт, кардинальность меток увеличивается, и одна машина упирается в CPU/диск/память. Поэтому лучше заранее понимать, как выбранная система ведёт себя при росте.
Один узел проще: меньше компонентов, проще обновления и отладка. Но он же — единая точка отказа. Если мониторинг критичен, заранее продумайте отказоустойчивость.
В кластере важны два механизма:
Уточните, что происходит при падении узла: продолжает ли кластер принимать запись, как быстро перестраиваются шарды, есть ли «дырки» в данных и как они закрываются.
Для свежих данных (последние часы/дни) обычно нужен быстрый диск (SSD): именно по ним чаще всего строятся графики и срабатывают алерты.
Для долгого retention выгоднее многоуровневое хранение: горячий слой на SSD и холодный слой в более дешёвом хранилище, часто — объектном. Проверьте, поддерживает ли ваша TSDB такой режим нативно и как это влияет на задержку запросов по «старым» периодам.
Бэкап в TSDB — не «галочка». Заранее проверьте:
Хорошая практика — периодически прогонять тестовое восстановление в отдельном окружении.
Типичные «упоры» — индекс по меткам, компактация сегментов, лимиты на количество активных серий и стоимость сложных запросов с высокой кардинальностью. Полезно заранее настроить лимиты и наблюдать за самой TSDB (задержка записи, время ответа запросов, очередь компактации), чтобы рост метрик не превратился в падение мониторинга.
Хорошо смоделированные метрики экономят деньги на хранении и часы на разбор инцидентов. Плохо смоделированные — раздувают кардинальность, ломают алерты и делают дашборды «шумными». Ниже — практические правила, которые удобно применять независимо от того, используете ли вы Prometheus, совместимую TSDB или сбор через OpenTelemetry.
Начните с трёх базовых решений: что измеряем, в каких единицах, какие измерения допустимы.
http_requests_total (счётчик), http_request_duration_seconds (гистограмма/саммари), memory_working_set_bytes (gauge)._seconds, _bytes, _ratio, _total.service, env, region, method, status, endpoint (если список стабилен).Правило: если значение метки потенциально уникально (user_id, order_id, trace_id, IP, полный URL с параметрами) — это почти всегда путь к взрывной кардинальности меток. Такие данные лучше писать в логи/трейсы, а в метриках оставлять агрегаты.
Частота сбора влияет на объём почти линейно. До того как повышать разрешение, ответьте на вопрос: какую минимальную длительность события вы хотите уверенно увидеть.
Практика:
Модель метрик считается удачной, если она легко отвечает на типовые вопросы:
Перед продакшном соберите 3–5 эталонных панелей и проверьте:
Зафиксируйте соглашения: имена, единицы, список разрешённых меток.
В пилоте ограничьте метки (allowlist) и включите мониторинг кардинальности.
Проверьте стоимость: объём записей в сутки, рост при добавлении новых сервисов.
Добавьте «охранные» алерты: резкий рост новых рядов, рост ошибок парсинга/экспорта, пропуски скрейпа.
Только после этого расширяйте покрытие и подключайте новые источники (например, метрики из OpenTelemetry), сохраняя те же правила моделирования.
Выбор TSDB обычно упирается не в «какая лучше», а в то, как вы собираете метрики, кто ими пользуется и какие требования к задержке, стоимости и эксплуатации. Ниже — короткий чек-лист, который помогает быстро сузить варианты.
Спросите себя: сколько метрик в секунду вы пишете сейчас и что будет через год? Важно оценить:
Если у решения дешёвое хранение, но дорогие запросы по диапазонам — вы заплатите временем аналитиков и медленными дашбордами.
Проверьте, насколько естественно TSDB встраивается в ваш стек:
Если у вас уже есть Prometheus-экосистема, цена миграции часто ниже у решений, которые «говорят на PromQL» без сюрпризов.
Даже небольшим компаниям быстро становятся важны базовые ожидания:
TSDB не всегда обязательна. Обычная БД может подойти, если метрик мало, запросы редкие, а хранение — недолгое. Лог-хранилище лучше, если вам важнее полнотекстовый поиск и расследования по событиям, а не быстрые агрегации по времени.
Практика: начните с пилота на реальных метриках и дашбордах — и сравните стоимость/задержки на «ваших» запросах, а не на бенчмарках.
Взрыв кардинальности меток — самый частый способ незаметно превратить мониторинг в дорогую и медленную систему. Типичный сценарий: добавить в метку user_id, полный URL, order-id или любой другой почти уникальный идентификатор. В результате количество временных рядов растёт лавинообразно, TSDB начинает тратить память и диск на «мусорные» комбинации, а запросы и алерты тормозят.
Нет чёткой политики retention. Если не определить сроки хранения (например, 14–30 дней «сырых» данных и дольше — агрегаты), объём будет расти бесконечно. Потом придётся срочно «резать» данные, переносить хранилища и объяснять, почему исторические графики пропали.
Слишком много алертов. Когда алертят все метрики подряд, команда быстро перестаёт реагировать. Итог — реальная проблема тонет в шуме. Хорошее правило: алерты должны быть про влияние на пользователей и SLO, а не про «интересные» колебания.
Метрики «из коробки» полезны для старта (CPU, память, задержки). Но зрелая система начинается там, где вы отвечаете на вопросы: что такое “плохо” для пользователя и как это измерить. Выберите 2–3 ключевых SLI (например, доля успешных запросов и p95 задержки) и стройте алерты вокруг них. Остальные метрики пусть работают как диагностика.
Система метрик тоже должна быть наблюдаемой: задержка доставки, пропуски данных, ошибки записи, использование диска, состояние ретеншена. Иначе вы узнаете о сбое мониторинга в момент, когда он больше всего нужен.
Соберите базовые дашборды (SLO, трафик, ошибки, насыщение ресурсов), проведите ревизию меток на кардинальность и зафиксируйте retention/downsampling правила.
Если вы выбираете платформу или планируете рост нагрузки — сравните варианты и стоимость на /pricing. Для углубления в практики — посмотрите тематические материалы в /blog.
Отдельно имеет смысл заранее продумать наблюдаемость для приложений, которые вы собираете «ускоренными» процессами разработки. В TakProsto.AI, где можно быстро создавать приложения (React на вебе, Go + PostgreSQL на бэкенде, Flutter на мобильных) и разворачивать их с хостингом, снапшотами и откатом, метрики и TSDB помогают безопасно масштабировать изменения: от первых прототипов на free-уровне до production-нагрузок на business/enterprise. Дополнительный плюс для российского рынка — инфраструктура в России и работа с локализованными моделями, что упрощает требования к размещению данных и контуру мониторинга.
TSDB (Time-Series Database) нужна, когда у вас постоянный поток метрик (ingest) и типовые запросы выглядят как «за последние 15 минут/24 часа» + агрегации (avg, sum, rate, p95). Если метрик становится много, универсальная БД обычно начинает проигрывать по:
Временной ряд — это последовательность точек, где у каждой точки есть:
service="checkout", region="eu".Один «показатель» (например, CPU) превращается в множество отдельных рядов из-за разных комбинаций меток: по , , и т. д.
Потому что на практике почти никогда не важна «одна точка». Важны тренды и изменения:
rate/increase);Мониторинг и алерты почти всегда работают с окнами времени, а не с единичными значениями.
Метрики — это числа во времени, удобные для графиков и агрегатов.
Логи — это события/сообщения (часто текст), лучше подходят для расследования конкретного случая.
Трассировки — это путь конкретного запроса через сервисы (спаны), помогают понять, где потеряно время.
Практика: метриками находят «что сломалось и насколько», а логи/трейсы отвечают на «почему» и «где именно».
Кардинальность — это количество уникальных комбинаций значений меток у метрики. Чем больше комбинаций, тем больше отдельных рядов надо хранить и индексировать.
Высокая кардинальность обычно приводит к:
Почти всегда ошибкой являются метки с потенциально уникальными значениями:
user_id, session_id, order_id;trace_id;Вместо этого:
Нормализуйте endpoint: уберите динамические части пути и параметры, чтобы список значений был ограниченным.
Примеры:
/users/123/profile → /users/:id/profile/orders/987?debug=true → /orders/:idТак вы сохраняете полезный разрез по API, но не создаёте миллионы рядов из-за уникальных URL.
Downsampling (rollups) — это хранение агрегатов в более крупном интервале (например, из 10 секунд сделать 1 минуту, затем 1 час).
Обычно хранят:
avg для тренда;min/max, чтобы не потерять пики;p95/p99 для задержек;Retention — это политика «сколько хранить». Для метрик почти всегда нужен срок годности.
Практический подход:
И отдельно задайте разные сроки для классов метрик: SLO/ошибки/задержки — дольше, «шумные»/экспериментальные — короче.
Для алертов критичны три вещи:
Практика: используйте заранее рассчитанные ряды (recording rules), окна 5–10 минут, и продумайте поведение при «нет данных» (это может быть и норма, и поломка сбора).
instancepodservicecount/sumПрактика: raw-данные держат недолго для расследований, а rollups — дольше для недель/месяцев.