Conservazione serie temporali

1) Perché un'architettura separata per le serie temporali

• Alta velocità di record (ingest) e frequenza.
• Letture per intervalli di tempo (scan + aggregati/finestre).
• Una radicalità esplosiva dovuta alle combinazioni di tag.
• Necessità di ritensh (limiti di conservazione) e downsampling (compressione temporale).
• Da qui un modello di storage speciale, formati di compressione e protocolli di query.

2) Modello di dati e contratto di metriche

2. 1 Denominazione e tag

metric _ name: verbo/sostantivo nell'unico numero ('http _ sollests _ total', 'cpu _ usage _ seconds _ total').
labels: chiavi-attributo (job, instance, dc, pod, status, method).
Invarianti: non modificare la semantica del nome, né aggiungere versioni ('metric _ v2') in caso di modifiche incompatibili.

2. 2 Tipi di serie

Gauge (immagine), counter (risultato crescente), Historogram/Summary (distribuzione/quantili), Event/Span (punti trace).
Per finanza/densità: fissa unità e aggregabilità (sommata/media).

2. 3 Politica di retensching e rollup

Dettagli caldi (secondi/1-10 min) → unità calde (5m/1h) → freddo (1d/1w).
Per il counter, memorizzare unità rate/deriv.

3) Percorso di scrittura: ricezione, buffering, CD

3. 1 Ingest-pipeline

Scrape (pull, prometheus) o push (OTLP/StatsD/Graphite), spesso tramite gateway/agente.
Buffering in WAL (write-ahead log), quindi compattazione in segmenti/blocchi (LSM-simile architettura).
Batching e ordinamento in base al tempo aumentano la compressione e la velocità.

3. 2 Elaborazione out-of-order e riprese

Finestra di tolleranza (lateness window, ad esempio 5-15 min) + criterio: 'drop | upsert | keep-last'.
Deduplicazione per '(serie _ id, timestamp)' con versioni o «ultimo record vince».

3. 3 Compressione

Delta-of-delta per etichette temporali, Gorilla/XOR per float, RLE e varint per interi, dictionary per tag.
Le dimensioni ottimali di un blocco (chanca) 1-8K di punti sono un compromesso tra IOPS e CPU.

4) Diagrammi di storage: TSDB vs SQL/Collevere

4. 1 TSDB specializzati

Prometheus (locale, breve, PromQL, remote _ write).
VictoriaMetrics/M3/InfluxDB - ridimensionamento orizzontale, ritocco lungo, remote read.
I formati di blocco sono ottimizzati con range scan + aggregazioni di offerta.

4. 2 Motori relazionali/invertebrati

TimescaleDB (PostgreSQL) - ipertabliti, cianfrusaglie in termini di tempo/spazio, continuous aggregates.
ClickHouse: MergeTree/TTL/rappresentazioni materializzate, compressione eccellente e aggregazioni temporali.
Selezione per ecosistema di query (SQL vs), requisiti di join/BI e competenze operative del team.

5) Schema e esempi

5. 1 TimescaleDB: ipertablica + 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 di aggregazione

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) Cardinalità: come non «far esplodere» il caveau

6. 1 Regole

Limitare label cardinality (numero di valori univoci). Non attivare «user _ id», «sollest _ id», «trace _ id».
Regolate i tag multi-conteggio (categorie di codici).
Usate i tipi LowCardinality (in CH), i dizionari/gli alberi delle etichette (in TSDB).

6. 2 Controllo e alerti

Metriche: «series _ count», «label _ values {label}», serie «costose» top-n.
Criteri di non scrittura quando si supera il limite di radicalità per tenant/job.

6. 3 Storie/istogrammi

Per l'high-cardinality è meglio conservare unità (historogram buckets) e pre-rollup; Quantili calcolare online sui dispositivi.

7) Retenschn, downsampling e tiered-storage

7. 1 Criteri

Hot: 3-30 giorni di dettagli secondi/minuti.
Warm: 90-365 giorni di unità 5m/1h.
Cold: anni di aggregazioni diurne, archivio in archivio oggetti (S3/Glacier) con Parquet.

7. 2 Tecnici

Continuous aggregates (Timescale), rappresentazioni materializzate (CH), retention + rollup tasks (Victoria/M3/Influx).
Tiered storage: blocchi caldi localmente, freddi in un oggetto con cache locale.

8) Richieste e lingue

8. 1 PromQL (esempio)

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

Cerchiamo il tasso di errore di API 5xx.

8. 2 unità SQL per finestre

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 Anomalie (sketch)

Z-score/ESD per statistica finestra, scomposizione STL stagionale; memorizzare i risultati in una singola serie dì anataly = 1/0 '.

9) Integrazioni e protocolli

OTLP ( ): metriche/roulotte/logi, esportatori su agenti (otel-detector), TSDB/clickouse/oggetto.
StatsD/Graphite: contatori/timer semplici; proxy su edge, quindi conversione in un unico formato.
Kafka/NATS: buffer per picchi ingest, replayer per backfill; I consulenti scrivono con i batch.

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

10) Accessibilità, HA e federazione

Replica/HA-coppie TSDB o Prometheus Federation.
Remote read/write per conservazione a lungo termine e dashboard centralizzati.
Shard-by-label/time: distribuzione uniforme di ingest, locality per «dc/tenant».

11) Osservabilità dello storage stesso

11. 1 Metriche

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`.
Cardinalizio: «series _ count», top labels.

11. 2 SLO

«p99 latency per l'intervallo di 1h a 200 ms».
«Ingest-drop ≤ 0. 01% a burst a X sample/sec".
«Compaction backlog < 10 min».

11. 3 Alerti

Altezza di serie _ count> %/ora.
Coda di compressione/flush> soglia.
Доля out-of-order > N%, dedup/late-drops.

12) Sicurezza e multi-tenenza

Isolamento per «tenant» (etichetta in chiave, tabelle/basi separate, quote).
Pulizia delle etichette (PI proibito), controllo delle quote/valori.
Crittografia in pace e nei trasporti, controllo dell'accesso alle metriche sensibili.

13) Pratiche operative

Riscaldamento e inizio freddo: pin «hot» nella cache, prefetch delle ultime ore N.
Backfill: singole pipline a bassa priorità, non mescolate con la linea.
Versioning diagramma - Migrazione con record parallelo (dual-write) e successivo maglionaggio.
Budget di conservazione: controlla'cost _ per _ TB _ month '+ forecast crescita della radicalità.

14) Anti-pattern

I tag ad alta cardinalità (user _ id, uuid) fanno esplodere le righe.
Le fila «eterne», senza retino, crescono senza controllo.
Registrazione senza batching/ordinamento, cattiva compressione e tempesta IOPS.
Mescolare OLTP e scene lunghe su un unico pool di dischi.
Nessuna regola out-of-order per duplicare e gonfiare.
Gli istogrammi con centinaia di → ette non servono a niente.

15) Assegno-foglio di implementazione

• Definire le metriche, i loro tipi e le loro unità. fissa il contratto dei nomi/etichette.
• Selezionare il motore (TSDB vs SQL/Colleverter) e il linguaggio query (PromQL/SQL).
• Progettare il retensch/rollap (hot/warm/cold) e le tasche ILM.
• Configura ingest: WAL/batch/order, finestre out-of-order.
• Abilita la compressione (delta-of-delta/XOR/RLE), le catene ottimali.
• Controllare la cardinalità: quote, alert, politiche di rifiuto.
• Configurare SU/federazione e remote-write/read.
• Dashboard SLO e metriche di storage (ingest/query/storage).
• Regole di sicurezza/isolamento tenente e assenza di PII nelle etichette.
• Regolare «game day»: backfill, perdita del nodo, slancio dell'ingest.

16) FAQ

Q: Cosa scegliere per il monitoraggio dell'infrastruttura: Prometheus o ClickHouse/Timescale?
A: Per monitoraggio nativo e PromQL - Prometheus + storage a lungo termine (Victoria/M3). Per gli script BI/magazzino e SQL -.

Q: Come conservare il quantili senza un summary pesante?
A: Utilizzare l'istogramma con i contenitori e calcolare il quantili quando viene richiesto; o t-digest/CKMS nelle unità.

Q: Come fare con out-of-order?
A: Immettere la finestra di tolleranza (5-15 min) e il criterio deadup definito; per la telemetria da mobile/edge - la finestra è più ampia.

Quando ti serve un rollup?
A: Sempre a ritensh> 30-90 giorni: le unità riducono le dimensioni di x 10-100 e accelerano l'analisi.

Q: È possibile miscelare fogli e metriche?
A: Memorizza separatamente (formati/query diversi). Per la correlazione, usate i Exemplar/TraceID e i dashboard, ma non mettete tutto nella stessa tabella.

17) Riepilogo

Una serie temporale efficiente è un contratto metrico + disciplina dei tag, engest (WAL/Compact), compressione e regole di retenschn/rollup. Aggiungete il controllo della cardinalità, la PA/federazione e l'osservabilità dello store stesso - e avrete un p95 prevedibile, un costo ragionevole per mesi-anni e la resistenza ai picchi.