TimescaleDB extension → Grafana Alerts

Когда «сырые» события Bitrix24 превращаются в миллион строк в день. PostgreSQL 16 легко жонглирует транзакциями CRM, но плохо чувствует себя, когда десятки датчиков-ботов и менеджеров хотят построить графики «среднее ⟨NER-скорость сделки⟩ за 5-минутку» — индексы пухнут, GROUP BY греет процессор. TimescaleDB 2.20 добавляет слой hypertable-шардинга и сжимает свежие даты на лету: время выборки за годовую историю падает с минут до секунд, а дополнительный continuous aggregate сам обновляет «окно» последних 30 минут (docs.timescale.com).

Сигнал «не трогали сделку X дней» должен прилетать сам, а не после F5. В Grafana 11 alert-движок выполняет те же SQL-запросы, что и ваши панели: задаём SELECT … HAVING max(age)>3 days, ставим pending period 5 m и получаем Slack-пинг, когда лимит сработал (grafana.com, grafana.com). В связке всё просто: Timescale расширяет Postgres, Grafana читает hypertable напрямую, а Superset и Power BI продолжают брать витрины из обычных схем, не замечая волшебства.

Компоненты и роли

Подготовка окружения

1. Устанавливаем ПО

2. Мини-Docker-compose (DEV)

version: "3.9"
services:
  postgres:
    image: timescale/timescaledb-postgis:2.20.0-pg16
    environment:
      POSTGRES_USER: etl
      POSTGRES_PASSWORD: etl_pwd
      POSTGRES_DB: datamart
    ports: ["5432:5432"]

  grafana:
    image: grafana/grafana:11.2.0
    ports: ["3000:3000"]
    depends_on: [postgres]

  superset:
    image: apache/superset:5.1.0rc0
    env_file: superset.env
    depends_on: [postgres]
    ports: ["8088:8088"]

docker compose up -d

— через минуту Postgres уже поддерживает команды CREATE EXTENSION timescaledb;.

3. Производственные параметры

shared_preload_libraries = 'timescaledb'
max_worker_processes     = 32        # параллелим continuous aggregate
timescaledb.max_background_workers = 16
timescaledb.telemetry_level = 'off'  # корпоративная политика

Настройка потоков данных

1. Импорт Bitrix24 → hypertable

CREATE SCHEMA raw;

CREATE TABLE raw.deal_activity (
  id           bigint,
  deal_id      bigint,
  action       text,          -- UPDATE / COMMENT / CALL / …
  payload      jsonb,
  dt_event     timestamptz    -- оригинальный штамп CRM
);

SELECT create_hypertable('raw.deal_activity', 'dt_event',
                         chunk_time_interval => INTERVAL '1 day');

API-шаг: в n8n или Airbyte шлём crm.deal.list раз в 5 мин и делаем INSERT … ON CONFLICT.

2. Continuous Aggregate «последняя активность сделки»

CREATE MATERIALIZED VIEW metrics.deal_last_touch
WITH (timescaledb.continuous) AS
SELECT
  deal_id,
  max(dt_event) AS last_touch
FROM raw.deal_activity
GROUP BY deal_id
WITH NO DATA;              -- загружаем CAGG позже

CALL refresh_continuous_aggregate('metrics.deal_last_touch',
                                  now() - INTERVAL '30 days', now());

Политика авто-обновления:

SELECT add_continuous_aggregate_policy('metrics.deal_last_touch',
    start_offset => INTERVAL '30 days',
    end_offset   => INTERVAL '1 h',
    schedule_interval => INTERVAL '15 min');

3. Индекс для «потерянных» сделок

CREATE INDEX ON metrics.deal_last_touch (last_touch);

Запрос «все сделки без апдейта ≥ 3 дней» теперь выполняется < 100 мс.

Трансформации и моделирование

dbt-пример витрины

{{ config(materialized = 'table') }}

SELECT
    d.deal_id,
    s.stage_name,
    l.last_touch,
    d.amount
FROM mart.dim_deal d
LEFT JOIN metrics.deal_last_touch l USING (deal_id)
LEFT JOIN mart.dim_stage s ON d.stage_id = s.stage_id;

Визуализация

Grafana

1. Data Source → PostgreSQL → SSL, Timescale-mode ON.

2. Dashboard «Deal Activity»:

   • Panel 1. Bar: count(id) by $__interval → активность в минуту.
   • Panel 2. Table: SELECT deal_id, last_touch FROM metrics.deal_last_touch WHERE last_touch < now() - '3 days'::interval.

3. Alert Rule «Stale deals > 10»:

   • Query: число строк предыдущего запроса.
   • Condition: IS ABOVE 10.
   • Evaluation: каждые 5m, pending =10m (grafana.com).
   • Notification: Slack channel #crm-alerts.

Superset

Datasource → Postgres (schema mart). Чарт: Time Series Line по count(distinct deal_id) из raw.deal_activity. RLS-policy «sales_rep = current_user».

Power BI

Get Data → PostgreSQL (Import). Incremental Refresh:

• RangeStart/RangeEnd → dt_event.
• Store 60 months, Refresh 2 days.

Мониторинг и автоматизация

Типичные ошибки и лайфхаки

1. ERROR: create_hypertable … already a hypertable — удалили таблицу без drop_chunks(); чисто пересоздайте схему.
2. Алёрт дублируется каждые 5 м — в Grafana включите Keep firing for = 0 m + No Data → OK.
3. CAGG не пересчитал прошлый год — запустите CALL refresh_continuous_aggregate() нужным диапазоном.
4. Power BI медленно тянет 30 М строк — переключитесь на DirectQuery + Aggregations из CAGG.
5. Timescale extension «requires update» после apt-upgrade — ALTER EXTENSION timescaledb UPDATE;, затем перезапустите Grafana-pod чтобы пересканировать типы.

Заключение

Связка TimescaleDB → Grafana Alerts шаг за шагом дарит Postgres super-силы time-series без миграции:

Когда масштабировать

• 1 млн точек/мин — включите compression + two-node PG replica.

• Реaltime < 1 с — Kafka + Timescale live ingest (доступно с 21 марта 2025 г.) (docs.timescale.com).
• AI-поиск событий — добавьте расширение pgvector + Grafana LLM-panel.

Полезные ссылки

• Timescale hypertables
• Continuous aggregates
• Alert rule evaluation
• Grafana managed rules

Теперь сделка, которую забыли на 4 дня, сама «кричит» в Slack, а Postgres больше не просит добавку индекс-RAM. Данные живут, аналитики довольны, бизнес спит спокойно.