Długoterminowe archiwum metryk z indeksem na zapytania punktowe.
Prometheus po 14 dniach pęka, Thanos to operacyjny koszmar, Splunk metrics droższy niż dane.
Pakuje serie czasowe w binarne bloki .mila z Gorilla compression, archiwizuje w S3 z WORM, zapytania PromQL-compatible przez hibernowalną warstwę query — bez stałego klastra 24/7.
Każda organizacja generuje terabajty metryk dziennie. Każda chce je trzymać latami z powodu regulatora. Żadne istniejące rozwiązanie nie robi tego dobrze ekonomicznie — albo płacisz za 24/7 compute, albo masz dane bez indeksu.
Świetne narzędzie do hot search, ale dla retencji 90+ dni potrzebujesz Thanos lub Cortex — czyli Cassandra, Bigtable lub object store + zespół 3-osobowy do utrzymania. Operational cost przewyższa wartość długiej retencji.
Enterprise SaaS z sześciocyfrowym minimum rocznym, każda metryka idzie do liczników. Klient płaci za 24/7 compute za dane, których nikt nie czyta. Najgorszy ROI w kategorii observability.
Świetna kompresja, świetne queries — ale dalej musisz utrzymać klaster ciągle, bo zapytanie wymaga gorącego indeksu w pamięci. Storage cheap, compute drogi. Dla retencji wieloletniej economics się nie zgadza.
Najtańsze archiwum, ale punktowe zapytanie zajmuje godzinę. Bez indeksu po metric name i label set, każda query to pełny scan. Audytor pyta o jedną serię sprzed roku — czeka 60 minut na 4 punkty.
Format binarny zoptymalizowany pod time-series, nocny D+1 compaction, hibernowalna warstwa zapytań kompatybilna z PromQL — wszystko w jednym S3-natywnym stacku, kompatybilnym z istniejącymi narzędziami Prometheus / Grafana.
Delta-of-delta na timestampach, XOR na float64 values. Średnio 16 bajtów raw → 1.37 bajta. Typowy 10× compression ratio dla regularnych metryk. Mniej miejsca w S3, szybsze query (mniej do zdekodowania).
Per-block dictionary: unique label values mapowane na 2-bajtowy ID. Repeating labels (host, region, service) zajmują 2 bajty zamiast 50+. Wbudowane w format .mila, transparentne dla query layer.
Pojedynczy CronJob mergeuje staging z ostatnich 24h, promuje do WORM archive. Brak distributed coordination, brak race conditions, brak distributed locków. Wzorzec sprawdzony w ELSA, przeniesiony 1:1.
Zero coordinationQuery nodes scale-to-zero gdy idle 30 min. Cold start <10 s. Płacisz za storage, nie za stojący compute klaster. Audytor pyta raz w miesiącu — MILA stoi 720h × $0/h reszty czasu.
$0 idle computeSubset PromQL pokrywający 90% dashboard queries: selektory, agregacje, rate, over_time, histogram_quantile. Grafana datasource plugin: zero zmian w istniejących dashboardach.
S3 Object Lock COMPLIANCE per block, GDPR pseudonimizacja przy ingest dla PII w labelach (user_id, customer_id), audit trail z chain hash, legal hold per metric series. Wbudowane, nie doklejone.
MiFID II · HIPAA · GDPR
Kluczowa właściwość MILA: warstwa zapytań nie musi działać ciągle.
Ingestory zbierają metryki przez Prometheus remote_write. Nocny CronJob buduje bloki .mila. S3 przechowuje archiwum.
Redis metastore i pody query — są potrzebne tylko wtedy, gdy ktoś pyta. Audytor pyta raz w miesiącu, analityk pisze raport raz na kwartał, prokuratura raz w roku. Płacisz za storage, nie za klaster, który stoi.
Rzeczywiste scenariusze dla organizacji, które muszą archiwizować miliardy punktów metrycznych przez lata, z możliwością odpowiedzi na pytanie regulatora w minutach, nie godzinach.
Best execution reporting wymaga retencji tick data i metryk execution quality przez 5–7 lat. Surowy tick stream to miliony punktów na dzień na instrument. Splunk to enterprise zawał, raw Parquet to brak indeksu na pojedyncze pytanie audytora.
Operatorzy raportują KPI usług (call drop rate, throughput, latency per komórka, per usługa) do regulatorów. Wolumen: miliony serii × granulacja minutowa × 3–5 lat retencji. Klasyczny TSDB jest nieekonomiczny, raw archive nie ma indeksu.
Smart meters wysyłają pomiary co 15 minut. 1 mln urządzeń = ~100M punktów dziennie. Retencja 4–10 lat per energy regulator. To klasyczny spike use case dla long-term archiwum — wszyscy chcą trzymać dane, mało kto wie jak.
ICU monitors, wearables, medical devices generują continuous telemetry pacjenta. HIPAA wymaga 6+ lat retencji z audit trail dostępu. Klasyczny TSDB pęka pod wolumenem, klasyczny EHR nie ma indeksu na metryki.
MILA spełnia wymagania regulacyjne architekturą, nie konfiguracją na koniec projektu. Niezmienność, audit trail i pseudonimizacja PII w labelach są pierwotnymi pojęciami systemu.
Bloki .mila blokowane natychmiast po promotion ze staging. COMPLIANCE mode default (nieusuwalne), GOVERNANCE z MFA dla wybranych use cases. Retencja konfigurowalna per tenant per metric pattern.
Pseudonimizacja przy ingest (default) — labels z PII (user_id, customer_id, email_hash) hashowane HMAC-SHA256 z per-tenant secret. Tombstone fallback (opt-in) dla retroactive removal istniejących danych.
Config-driven YAML per metric pattern + regulation. MiFID II metrics 5–7 lat, HIPAA monitoring 6+ lat, internal metrics 1 rok. Audytowalne osobno — własny Object Lock dla policy changes.
Każda operacja (COMPACTION, READ, EXPORT, RETAIN, LEGAL_HOLD) logowana z kryptograficznym powiązaniem z poprzednim wpisem. Embedded AuditTrailWriter, brak circular dependencies. Wykrycie tampered audit log jest deterministyczne.
Entity-scoped hold: blokada usunięcia dla konkretnych serii (np. wszystkie metryki klienta X). System automatycznie identyfikuje dotknięte bloki, nakłada S3 Object Lock legal hold flag. Release z four-eyes i MFA.
Per-metric per-tenant cardinality budget z alertem na overflow. Sampled mode fallback chroni przed metric explosion (misconfigured klient zalewający milionami unikalnych label setów). Audytor widzi nie tylko co przechowujemy, ale też dlaczego.
Cztery warstwy bez wspólnego stanu — ingest, format, compaction i query działają niezależnie, skalują się osobno, i odtwarzają z S3 jeśli któraś się zgubi.
Prometheus remote_write v2.0, OTLP HTTP, custom HMAC POST. Per-tenant rate limiting, cardinality protection, autentykacja. Staging area lokalnie + S3 backup co 5 min.
.milaGorilla compression na float64 (delta-of-delta + XOR), dictionary encoding labels, sparse index po czasie, bloom filter (ELBF v1, shared z ELSA). Range-GET friendly.
Singleton (zero coordination overhead). K-way merge sortowany po (series_id, timestamp). Atomic upload z S3 conditional PUT. Redis metastore rebuild via Lua scripts.
Quarkus pody. Subset PromQL: selectors, aggregations, rate, over_time. Scale-to-zero przy idle 30 min. Cold start <10 s. Auto-routing do continuous aggregates.
| Komponent | Technologia | Uzasadnienie |
|---|---|---|
| Runtime | Java 21 + Quarkus | Native image, non-blocking I/O, reactive |
| Object storage | S3-compatible | AWS S3, MinIO, Ceph/RGW — identyczne jak DES/ELSA |
| Format bloku | .mila append-only | [HEADER][BLOCKS][INDEX][FOOTER] — optimized for time-series |
| Kompresja wartości | Gorilla (DoD + XOR) | 5–10× ratio · 16B raw → 1.37B per point średnio |
| Kompresja labels | Dictionary + Snappy | Repeating labels 2 bytes vs 50+ bytes raw |
| Metastore cache | Redis | Sorted sets per (tenant, metric); rebuild <5 min z S3 |
| Bloom filter | ELBF v1 | Shared z ELSA · niezależny od Guava version |
| WORM | S3 Object Lock | COMPLIANCE mode + Extended Retention Management |
| Authentication | Prometheus basic / OTLP bearer / HMAC | Wieloprotokolowy entry · per-tenant RBAC |
| Compaction | K8s CronJob (singleton) | Brak distributed locków · idempotent restart safe |
| Query | PromQL subset + Grafana plugin | Zero migration dashboards z Prometheus |
| Observability | Prometheus + Grafana | External Prometheus dla self-monitoring (no recursion) |
Skontaktuj się z nami, aby omówić wdrożenie MILA w Twojej organizacji — migrację z Prometheus / Thanos / VictoriaMetrics, integrację z Grafana, lub plan kompresji TCO dla wieloletniej retencji metryk regulacyjnych.