Убактылуу катарды сактоо

1) Эмне үчүн убактылуу катар үчүн өзүнчө архитектура

• Жогорку ылдамдык (ingest) жана мезгилдүүлүк.
• Убакыт диапазондору боюнча окуулар (scan + агрегаттар/терезе функциялары).
• Тегтердин айкалышынан улам жарылуучу кардиналдуулук.
• retenshna зарылдыгы (сактоо мөөнөтү боюнча чектөөлөр) жана downsampling (убакыт кысуу).
• Бул жерде - атайын сактоо модели, кысуу форматтары жана суроо протоколдору.

2) Маалыматтар модели жана контракт метриктер

2. 1 аталышы жана теги

metric_name: жалгыз фигура/зат ('http _ requests _ total', 'cpu _ usage _ seconds _ total').
labels: ачкыч атрибуттары ('job', 'instance', 'dc', 'pod', 'status', 'method').
Инварианттар: аты-жөнүнүн семантикасын өзгөртпөө, туура келбеген өзгөрүүлөрдө ('metric _ v2') версияларын кошуу.

2. 2 Катар түрлөрү

Gauge (Сүрөт), Counter (өсүү натыйжасы), Histogram/Summary (бөлүштүрүү/quantiles), Event/Span (соода чекиттери).
Финансы/тыгыздыктар үчүн - өлчөө бирдиктерин жана агрегаттуулугун белгилөө (жалпыланган/орточо алынган).

2. 3 Retenshn жана Rollap саясаты

ысык деталдаштыруу (секунд/1-10 мин) → жылуу агрегаттар (5m/1h) → муздак (1d/1w).
counter үчүн - rate/deriv агрегаттарды сактоо.

3) Жазуу жолу: кабыл алуу, буферизация, компакт

3. 1 Ингест-Пайплайн

Scrape (pull, Prometheus) же push (OTLP/StatsD/Graphite), көбүнчө gateway/agent аркылуу.
WAL (write-ahead log) буферизациялоо, андан кийин сегменттерге/блокторго (LSM-окшош архитектура) топтоо.
Batching жана убакыт сорттоо кысуу жана ылдамдыгын жогорулатуу.

3. 2 Out-of-order жана дубль иштетүү

уруксат терезе (мисалы, 5-15 мин) + саясат: 'drop | upsert | keep-last'.
'(series_id, timestamp)' чыгаруу же "акыркы жазуу утуп".

3. 3 кысуу

Delta-Delta убакыт белгилери үчүн, Gorilla/XOR үчүн float, RLE жана varint үчүн бүтүн, тегтер үчүн dictionary.
оптималдуу блок көлөмү ("Чанк") 1-8К чекиттер - IOPS жана CPU ортосундагы компромисс.

4) сактоо схемалар: TSDB vs SQL/мамычалар

4. 1 Адистештирилген TSDB

Prometheus (жергиликтүү, кыска retenshn, PromQL, remote_write).
VictoriaMetrics/M3/InfluxDB - горизонталдык масштабдоо, узак retenshn, remote read.
Блоктордун форматтары range scan + тендердик агрегациялар үчүн оптималдаштырылган.

4. 2 Реляциялык/колонка кыймылдаткычтары

TimescaleDB (PostgreSQL): hypertablitz, убакыт/мейкиндик, continuous aggregates.
ClickHouse: MergeTree/TTL/материалдык көрүнүшү, мыкты кысуу жана убакыт топтоо.
Тандоо - суроо экосистемасы (SQL vs PromQL), join/BI талаптары жана команданын иштөө көндүмдөрү боюнча.

5) Схема жана мисалдар

5. 1 TimescaleDB: гипертония + continuous aggregate

sql
CREATE TABLE metrics_cpu(
ts timestamptz NOT NULL,
host text NOT NULL,
dc text NOT NULL,
usage double precision NOT NULL,
PRIMARY KEY (ts, host, dc)
);
SELECT create_hypertable('metrics_cpu', by_range('ts'), chunk_time_interval => interval '1 day');

-- Continuous unit (5 minutes)
CREATE MATERIALIZED VIEW cpu_5m
WITH (timescaledb. continuous) AS
SELECT time_bucket('5 minutes', ts) AS ts5m, host, dc, avg(usage) AS avg_usage
FROM metrics_cpu GROUP BY 1,2,3;

-- Politicians
SELECT add_retention_policy('metrics_cpu', INTERVAL '14 days');
SELECT add_retention_policy('cpu_5m',   INTERVAL '180 days');

5. 2 ClickHouse: чогултуу сактоо

sql
CREATE TABLE metrics_cpu (
ts DateTime,
host LowCardinality(String),
dc LowCardinality(String),
usage Float32
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (host, dc, ts)
TTL ts + INTERVAL 14 DAY
SETTINGS index_granularity = 8192;

-- Rollup in hourly detail
CREATE MATERIALIZED VIEW cpu_1h
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (host, dc, ts)
POPULATE AS
SELECT toStartOfHour(ts) AS ts, host, dc, avg(usage) AS usage
FROM metrics_cpu GROUP BY ts, host, dc;

5. 3 Prometheus/VictoriaMetrics: remote_write

yaml global:
scrape_interval: 15s remote_write:
- url: http://vminsert:8480/insert/0/prometheus/api/v1/write

6) кардиналдуулук: кантип "жардыруу" сактоо

6. 1 Эрежелер

label cardinality (уникалдуу маанилердин саны) чектөө. 'user _ id', 'request _ id', 'trace _ id' дегендерди киргизбеңиз.
нормалдаштыруу "көп маанилүү" теги (категориялар → коддору).
LowCardinality түрлөрүн колдонуу (CH), сөздүктөр/дарактар (TSDB).

6. 2 Контролдоо жана Алерт

Метрика: 'series _ count', 'label _ values {label}', top-N "кымбат" катар.
per tenant/job.

6. 3 Окуялар/гистограммалар

жогорку-cardinality жакшы агрегаттарды сактоо үчүн (histogram buckets) жана pre-rollup; quantiles агрегаттар боюнча онлайн эсептөө.

7) Retenshn, downsampling жана tiered-storage

7. 1 Саясат

Hot: 3-30 күн секунд/мүнөт деталдаштыруу.
Warm: 90-365 күн 5m/1h бирдиги.
Cold: күндүзгү агрегаттар жыл, объект сактоо боюнча архив (S3/Glacier) менен Parquet.

7. 2 Техника

Continuous aggregates (Timescale), материалдык көрүнүшү (CH), retention + rollub tasks (Victoria/M3/Influx).
Tiered storage: "ысык блоктор" жергиликтүү, "муздак" жергиликтүү кэш менен объект.

8) суроолор жана тилдер

8. 1 PromQL (мисал)

promql rate(http_requests_total{job="api",status=~"5.."}[5m])

Биз API боюнча 5xx ката ылдамдыгын издеп жатабыз.

8. 2 SQL-агрегаттар терезелер боюнча

sql
SELECT time_bucket('1h', ts) AS hour,
dc, avg(usage) AS avg, max(usage) AS pmax
FROM metrics_cpu
WHERE ts >= now() - interval '24 hours'
GROUP BY 1,2 ORDER BY 1;

8. 3 Аномалиялар (эскиз)

Z-score/ESD терезе статистикасы боюнча, STL-сезондук декомпозиция; натыйжаларды өзүнчө 'anomaly = 1/0' катарында сактоо.

9) Интеграция жана протоколдор

OTLP (OpenTelemetry): метриктер/соодагерлер/Логи, агент экспорттоочулар (hotel-collector) → TSDB/кликхаус/объект.
StatsD/Graphite: жөнөкөй эсептегичтер/таймерлер; edge боюнча прокси, андан ары - бирдиктүү форматка конверсия.
Kafka/NATS: ingest буфери, backfill үчүн replayer; консумерлер батчалар менен жазышат.

text kafka(topic=metrics) -> stream processor (normalize/tags) -> CH INSERT INTO metrics_cpu FORMAT RowBinary

10) Жеткиликтүүлүк, HA жана Киргизия

Replica/HA-жуп TSDB же Prometheus Киргизия (аймак → дүйнөлүк деңгээл).
Узак мөөнөттүү сактоо жана борборлоштурулган дашборддор үчүн Remote read/write.
Shard-by-label/time: бирдей бөлүштүрүү ingest, locality боюнча 'dc/tenant'.

11) сактоо өзү байкоо

11. 1 Метрика

Ingest: `samples/sec`, `append_latency`, `wal_fsync_ms`.
Хранение: `blocks_count`, `compaction_queue_len`, `chunk_compression_ratio`.
Запросы: `query_qps`, `scan_bytes`, `p95/p99_latency`, `alloc_bytes`.
кардиналдуулугу: 'series _ count', top-labels.

11. 2 SLO

"QPS ≤ 500 боюнча 1h ≤ 200ms диапазону үчүн p99 latency".
«Ingest-drop ≤ 0. 01% бурст X samples/сек".
«Compaction backlog < 10 min».

11. 3 Алерталар

Өсүү 'series _ count'> %/саат.
Компакция кезеги/flush> босого.
Доля out-of-order > N%, dedup/late-drops.

12) Коопсуздук жана көп тенанттуулук

Изоляция 'tenant' (ачкычтардагы белги, өзүнчө таблицалар/базалар, квоталар).
этикеткаларды санитария (PII тыюу), өлчөмдөрүн/баалуулуктарын контролдоо.
"Тынч" шифрлөө жана транспорт, "сезгич" метриктерге жетүү аудити.

13) Эксплуатациялык практикалар

Жылытуу жана муздак баштоо: pin "ысык" кэш блоктору, акыркы N саат prefetch.
Backfill: төмөн артыкчылыгы менен өзүнчө бөлүштүрүү, онлайн менен аралаштырып жок.
Схеманын версиясы: параллелдүү жазуу (dual-write) жана андан кийинки түрмөк менен көчүрүү.
Сактоо бюджети: контролдоо 'cost _ per _ TB _ month' + кардиналдык өсүш forecast.

14) Анти-үлгүлөрү

Жогорку кардиналдык теги (user_id, uuid) → катар жарылуу.
Ретеншнасыз "түбөлүк" катарлар → көзөмөлсүз өсүү.
Батчинг/сорттоо жок жазуу → начар кысуу жана IOPS бороон.
АЛТП жана узун сканерлерди бир дисктердин пулуна аралаштыруу.
Жок out-of-order → дубликат саясаты жана көбүртүп.
жүздөгөн бакет менен гистограммалар → баасы × 10 пайдасыз.

15) Киргизүү чек-тизмеси

• Метрикаларды, алардын түрлөрүн жана бирдиктерин аныктоо; аты/лейблдер келишимин бекитиңиз.
• кыймылдаткыч тандоо (TSDB vs SQL/колонка) жана суроо тили (PromQL/SQL).
• Retenshn/Rollap (hot/warm/cold) жана ILM-таштарды долбоорлоо.
• Installate ingest: WAL/батчи/сорттоо, терезелер-of-order.
• кысуу (delta-delta/XOR/RLE), оптималдуу чанктар кирет.
• Контролдоо кардиналдуулугу: квота, тобокелдик, баш тартуу саясаты.
• ON/Киргизия жана remote-write/окуу.
• Dashbord SLO жана сактоо метрика (ingest/query/storage).
• Коопсуздук саясаты/Тенант-обочолонуу жана этикеткаларда PII жоктугу.
• Үзгүлтүксүз "оюн күнү": арткы, түйүн жоготуу, ingest.

16) FAQ

Q: Эмне объектилерди мониторинг үчүн тандоо: Prometheus же ClickHouse/Timescale?
A: Native мониторинг жана PromQL үчүн - Prometheus + узак сактоо (Victoria/M3). BI/кампа жагдайлар жана SQL үчүн - Timescale/ClickHouse.

Q: оор summary жок quantiles сактоо үчүн кантип?
A: кылдат бакет менен histogram колдонуу жана суроо-талап боюнча квантилин эсептөө; же агрегаттарда t-digest/CKMS.

Q: out-of-order менен эмне кылуу керек?
A: кирүү терезени (5-15 мин) жана dedup аныктоо саясатын киргизүү; мобилдик телеметрия үчүн/edge - кененирээк терезе.

Q: Rollup керек качан?
A: Дайыма retenshne> 30-90 күн: агрегаттар 10-100 × өлчөмүн азайтуу жана талдоо тездетүү.

Q: Логи жана метрика аралаштырууга болобу?
A: өзүнчө сактоо (ар кандай форматтар/суроолор). Корреляция үчүн Exemplar/TraceID жана дашборддорду колдонуңуз, бирок баарын бир таблицага салбаңыз.

17) Натыйжалары

Эффективдүү убакыт катарларын сактоо - бул метрика келишими + тегдердин дисциплинасы, компетенттүү ingest (WAL/компакция), компрессия жана ретеншн/роллап саясаты. Кардиналдуулукту көзөмөлдөөнү кошуу, NA/Федерация жана жүз байкоо - жана сиз алдын ала p95, ай-жыл үчүн акылга сыярлык наркын жана жарылууга туруктуулугун аласыз.