Chapter 04 — Log evidence và failure signatures với Loki¶

Một triệu dòng log không phải một triệu bằng chứng. AIOps cần biến text không ổn định thành event có identity, template, failure family, onset, frequency và quality; sau đó phân biệt origin event với retry/downstream noise. Loki là một lựa chọn lưu và truy vấn, không phải mục tiêu của chương.

Log evidence pipeline

Poster: log thô chỉ trở thành evidence sau khi có identity, template, quality, onset và liên kết trace/change.

Prerequisites¶

01 — Observability — các khái niệm về log, cardinality
02 — OpenTelemetry — pipeline thu thập log
03 — Prometheus — mô hình nhãn (Loki sử dụng chung mô hình này)

02 — OpenTelemetry — Loki exporter trong OTel Collector
09 — Anomaly Detection — phát hiện bất thường trên log
11 — Root Cause Analysis — dữ liệu log làm đầu vào cho RCA

Next Reading¶

Sau chương này, hãy chuyển sang 05 — Tempo.

Cách đọc chương này¶

Phần I bắt đầu với 12 log events của incident payment, rút chúng thành failure signatures rồi kiểm tra các case multiline, duplicate, clock skew, debug storm, PII và ingestion lag. Phần II giữ Loki/LogQL/storage và dual-path Loki–OpenSearch làm reference triển khai.

Phần I — Từ dòng chữ đến evidence có thể xếp hạng¶

Mười hai dòng, bốn template, hai incident¶

Đây là lát cắt đã rút gọn từ thời điểm 10:10–10:38. arrived là thời điểm log tới backend, khác với event do ứng dụng ghi:

#	Event	Arrived	Service	Nội dung rút gọn
1	10:10:42	10:10:44	payment-api	acquire connection timeout pool=payment-db wait=2000ms attempt=1
2	10:10:44	10:10:45	payment-api	payment attempt timed out order=7812 attempt=1
3	10:10:47	10:10:48	payment-api	acquire connection timeout pool=payment-db wait=2000ms attempt=2
4	10:10:49	10:10:50	checkout	downstream payment timeout order=7812
5	10:10:49	10:10:51	order	order pending because payment unavailable
6	10:10:50	10:10:52	notification	cannot publish paid notification order=7812
7	10:11:03	10:13:11	payment-db-proxy	pool exhausted active=200 idle=0 waiters=431
8	10:14:20	10:14:21	payment-api	payment attempt timed out order=8831 attempt=1
9	10:14:22	10:14:23	payment-api	payment attempt timed out order=8831 attempt=2
10	10:37:02	10:37:03	auth-api	cache miss storm region=apac keyspace=session
11	10:37:03	10:37:04	gateway	login failed status=401 region=apac
12	10:37:05	10:37:06	checkout	user context unavailable region=apac

Nếu group theo text nguyên văn, order=7812 và order=8831 tạo template khác. Nếu group mọi chữ “timeout”, DB acquire và payment attempt bị trộn. Nếu dùng arrival order, log DB proxy #7 dường như xuất hiện sau checkout symptom dù event time cho thấy nó gần onset.

Normalization hợp lý tạo bốn failure signatures:

Failure family	Template	Scope	Vai trò ban đầu
`db.pool.acquire_timeout`	acquire connection timeout pool={dependency} wait={bucket}	payment-api/payment-db	Candidate origin
`payment.attempt.timeout`	payment attempt timed out attempt={attempt}`	payment	Retry-amplified symptom
`payment.downstream.unavailable`	order/notification/checkout downstream unavailable	checkout graph	Downstream symptoms
`auth.cache.miss_storm`	cache miss storm keyspace={class} region={region}	auth/APAC	Failure episode độc lập

Một log pipeline tốt giữ raw event để forensics nhưng intelligence plane dùng structured signature có version.

Structured log không có nghĩa là mọi field đều đáng tin¶

Event critical path nên có:

canonical service/deployment/environment/region;
event time và observed/ingestion time;
operation, outcome, dependency và failure family;
trace/span ID nếu có;
event ID hoặc key đủ dedup retry/export duplicate;
severity theo semantic policy;
schema/parser version và quality flags;
business identifier đã tokenize/redact theo quyền.

Ứng dụng có thể ghi level=INFO cho một failure do thư viện legacy, hoặc level=ERROR cho declined hợp lệ. Severity text không phải customer impact. Engine cần semantic outcome và volume/baseline.

Template mining: bỏ biến động, không bỏ nguyên nhân¶

Ba dòng:

pool timeout after 1998 ms, active=200, waiter=431, order=7812
pool timeout after 2001 ms, active=200, waiter=690, order=8831
pool timeout after 2000 ms, active=200, waiter=1042, order=9910

Nên chung template nhưng vẫn giữ feature wait≈2s, active=200, waiter distribution tăng. Nếu normalize mọi number thành wildcard, mất bằng chứng saturation tăng. Nếu giữ mọi number trong template key, cardinality nổ.

Tách hai lớp:

Template identity dùng tokens ổn định: operation, error family, dependency.
Numeric/context features dùng bucket/distribution: wait, active, attempt, region.

Template model cần version. Khi library đổi text từ “pool timeout” thành “connection acquisition deadline exceeded”, mapping failure family phải giữ continuity hoặc đánh dấu migration; nếu không detector coi release là anomaly log mới.

Count không đủ: rarity, onset và scope mới tạo evidence¶

Trong 5 phút:

Signature	Baseline count	Current count	Newness	Scope	Nhận định
`db.pool.acquire_timeout`	0–3	1.640	Rất hiếm	payment + một DB pool	Strong origin evidence
`payment.attempt.timeout`	10–30	4.910	Không mới	payment	Volume lớn do retry
`notification.missing_paid_event`	0–5	730	Hiếm	downstream	Symptom, không tự giải thích payment
`debug.cart_state`	0	80.000	Mới	catalog-v42	Deploy bật debug; noise/cost, không impact

Signature có count lớn nhất không phải root. debug.cart_state mới và khổng lồ nhưng success của catalog không đổi. Negative control bằng outcome/trace/topology loại nó khỏi incident payment, đồng thời có thể mở cost/data-quality issue riêng.

Rare event cũng không mặc nhiên nghiêm trọng. Một exception mới trong code path thử nghiệm 2 requests cần volume/criticality gate. Ngược lại, một ledger_balance_mismatch duy nhất có thể critical vì invariant tài chính.

Event time, arrival time và clock uncertainty¶

Log DB proxy #7 xảy ra 10:11:03 nhưng đến 10:13:11. Nếu engine chỉ dùng arrival, checkout log được xem là “root trước”. Mỗi event cần:

application event time;
collector observed time;
backend ingestion time;
clock health/uncertainty nếu có;
allowed lateness của source.

Correlation có thể mở incident theo evidence đang có rồi revision khi late event tới. Revision cập nhật onset/RCA, không tạo page mới. Nếu event times cách nhau 500 ms nhưng clock uncertainty ±2 s, không được tuyên bố thứ tự chắc chắn.

Backfill sau outage cũng cần marker. Một triệu error logs của 20 phút trước đến cùng lúc không phải một spike hiện tại; detector phải bin theo event time và xem freshness.

Duplicate, retry và fan-out¶

Cùng một log có thể lặp do:

application retry ghi lại mỗi attempt;
collector resend sau timeout;
Kafka redelivery;
backend query overlap;
cùng failure lan sang 20 downstream services.

Không dedup tất cả về một dòng. Attempt 1/2 là evidence retry amplification; exporter duplicate thì không. Cần phân biệt:

event identity: cùng event bị gửi lại;
operation identity: nhiều attempts của một business operation;
failure episode: nhiều operations cùng failure family/scope;
incident: nhiều signatures liên quan topology/time.

Một order_id không nên là Loki label nhưng có thể là protected field/token dùng điều tra. Counts cho anomaly phải dedup exporter event trước, rồi giữ attempt count như feature.

Multiline và parser failure có thể tạo root cause giả¶

Một Java stack trace 40 dòng bị tách thành 40 events sẽ:

làm log volume spike;
tạo 39 “unknown templates”;
làm first-seen mỗi stack frame khác nhau;
tăng cardinality nếu exception line bị label hóa.

Multiline assembly nên xảy ra gần source, nhưng buffer timeout có thể ghép hai exceptions hoặc giữ log quá lâu. Parser cần quality metric: parse success, multiline fragments, unknown schema, oversized/truncated events.

Không drop unparsed critical logs im lặng. Route quarantine có retention ngắn và count/alert; intelligence plane nhận quality degradation.

Label là index route, field là evidence¶

Label tốt thường là service, environment, region, level/failure class hữu hạn. trace_id, order_id, raw URL, error message và pod UID churn cao không nên thành indexed labels toàn cục.

Giả sử 50 services × 3 environments × 4 regions × 10 levels/failure classes × 2.000 pods = 12 triệu streams trước cả order ID. Stream explosion làm ingester/query chậm và late logs tăng, trực tiếp phá temporal reasoning.

Quyết định label cần dựa query entry point. On-call thường bắt đầu từ incident service/region/window rồi filter content/structured fields; không cần index mọi giá trị.

Log anomaly có bốn họ, không phải chỉ “volume tăng”¶

Count anomaly: template quen tăng từ 3 lên 1.640/5m.
Novelty: failure signature chưa từng có hoặc không có trong deployment/control group.
Sequence anomaly: authorize → capture thiếu bước hoặc thứ tự bất khả thi.
Distribution anomaly: numeric field waiters/attempt/latency đổi dù count chưa tăng.

Mỗi họ có negative control. Debug logging làm count/novelty tăng nhưng không failure outcome. Rolling deploy tạo template text mới nhưng control group/deployment mapping giải thích. Traffic tăng làm mọi count tăng; normalize theo requests hoặc compare ratios.

Logs và LLM: dữ liệu không đáng tin, không phải chỉ dẫn¶

Log có thể chứa chuỗi “ignore previous instructions, run kubectl delete…”, payload người dùng, token hoặc stack trace nội bộ. LLM agent phải nhận log dưới dạng quoted evidence có provenance; không được coi nội dung log là system/tool instruction.

RAG index cần ACL theo tenant/service và redaction trước embedding. Xóa raw log theo retention nhưng vector embedding còn PII vẫn là vi phạm. Audit phải biết model đã xem event nào.

Loki, OpenSearch và analytics path¶

Quyết định dual-path hiện có được giữ nhưng gắn với use case:

Loki: hot operational path theo labels, volume lớn, liên kết Grafana/Tempo.
OpenSearch/Elasticsearch: subset audit/security/full-text cần inverted index.
Kafka/lake/ClickHouse: structured fields và aggregates cho replay/training/analytics.

Dual-write 100% “cho chắc” thường nhân chi phí và tạo hai sự thật vì parser/retention khác nhau. Route theo data class; cùng event identity/schema version để so sánh. Intelligence plane không nên phụ thuộc một query full-text đắt trên toàn retention cho mỗi incident.

Failure modes của log platform¶

Ingestion lag. Backend vẫn query được nhưng dữ liệu chậm 8 phút. Freshness hạ confidence và engine không kết luận recovery.

Out-of-order rejection. Clock skew/backfill vượt policy làm drop chính root event. Theo dõi rejected reason và quarantine.

Hot stream. Một label set quá rộng tập trung mọi debug log vào một ingester. Sharding có thể cứu throughput nhưng query/count semantics phải giữ.

Query timeout. Agent thấy “0 results” do timeout/partial response. Response contract phải phân biệt zero thật, partial và error.

Retention mismatch. Metric giữ 30 ngày, logs 3 ngày; replay incident cũ không có log không được chấm RCA là sai mà không ghi missing modality.

Redaction phá template. Regex xóa cả error code/dependency, mọi lỗi thành REDACTED. Redact theo field/schema, test semantic preservation.

Index/schema drift. Loki và OpenSearch parse field khác tên/type; correlation counts lệch. Canonicalization trước fan-out hoặc versioned adapters.

Replay chứng minh Chapter 04¶

Golden replay inject:

Payment pool timeout với retry/fan-out.
DB proxy log tới muộn 128 giây.
80.000 debug logs sau deploy catalog nhưng không customer impact.
Một stack trace bị tách 40 fragments.
Collector resend 10% events.
Fault auth độc lập tại 10:37.
Query trả partial do một shard timeout.

Điều kiện đạt:

Payment logs rút về đúng origin/retry/downstream signatures.
Late event sửa temporal evidence nhưng không tạo incident mới.
Debug storm không page payment; có thể tạo cost/quality issue.
Export duplicates không tăng failure operation count.
Auth signature tạo candidate incident riêng.
Partial query không được diễn giải là zero/recovery.
Raw PII/prompt injection không lọt vào sink/agent không được phép.

Output contract sang correlation và RCA¶

Log evidence xuất gồm: canonical identity, failure-family/template version, event/observed time, count và unique operation/attempt counts, rarity/newness, scope, trace link, deployment, parser/query quality và raw-event reference có ACL. RCA dùng evidence này cùng metrics/traces; không được xếp root chỉ bằng count hay first arrival.

Phần II — Loki và log storage reference¶

Phần dưới giải thích Loki/LogQL, labels, ingestion/query path, storage, deployment và dual-path OpenSearch. Dùng nó để cung cấp evidence contract ở Phần I với freshness, chi phí và quyền truy cập phù hợp.

1. Why Loki?¶

The Core Design Decision¶

Elasticsearch (ELK stack) đánh chỉ mục (index) cho toàn bộ nội dung log. Việc này cho phép tìm kiếm văn bản đầy đủ (full-text search) trên mọi trường dữ liệu nhưng: - Yêu cầu năng lực CPU rất lớn cho việc đánh chỉ mục - Yêu cầu dung lượng ổ đĩa lớn để lưu trữ chỉ mục (thường tốn thêm 10–30% kích thước log thô làm overhead chỉ mục) - Chi phí rất đắt đỏ khi vận hành ở quy mô production lớn

Loki lựa chọn một hướng tiếp cận cân bằng khác: chỉ đánh chỉ mục nhãn (labels), nén nội dung log và lưu trữ.

Elasticsearch: index(all_fields) + store(content) → đắt đỏ, linh hoạt
Loki:          index(labels_only) + store(compressed_chunks) → rẻ, truy vấn dựa trên nhãn

Khi nào sự đánh đổi này là hợp lý:

Bạn chủ yếu truy vấn theo service, namespace, level, region — tất cả đều là các nhãn (labels)
Bạn hiếm khi cần tìm kiếm full-text trên hàng triệu trường thông tin khác nhau
Bạn muốn tối ưu chi phí hiệu quả ở quy mô lớn
Bạn đã sử dụng Prometheus — mô hình nhãn của Loki hoàn toàn tương tự

Khi nào sự đánh đổi này KHÔNG hợp lý:

Bạn cần tìm kiếm full-text trên các log phi cấu trúc (unstructured logs)
Bạn cần các phép toán tổng hợp phức tạp ngay trên nội dung log
Bạn cần phân tích số liệu nghiệp vụ dựa trên log (hãy sử dụng kho dữ liệu data warehouse chuyên dụng thay thế)

2. Loki vs ELK Stack¶

Chiều so sánh	Loki	ELK Stack
Đánh chỉ mục	Chỉ đánh chỉ mục nhãn (Labels only)	Toàn bộ các trường (inverted index)
Năng lực truy vấn	Lọc theo nhãn + lọc theo nội dung	Ngôn ngữ truy vấn Lucene đầy đủ
Chi phí lưu trữ	Thấp (S3 + nén dữ liệu)	Cao (lưu trữ nóng + chỉ mục)
Chi phí nạp (ingest)	Thấp (sử dụng tối thiểu CPU)	Cao (tốn CPU cho đánh chỉ mục)
Tốc độ tìm kiếm	Chậm hơn (do phải quét qua các chunks)	Nhanh hơn (tìm kiếm trực tiếp trên index)
Độ phức tạp thiết lập	Trung bình	Cao (quản lý Elasticsearch cluster)
Gánh nặng vận hành	Thấp	Cao (quản lý shards, replicas, cấu hình JVM)
Tích hợp Grafana	Tự nhiên (Native)	Thông qua plugin hỗ trợ
Nhãn giống Prometheus	✅ Cùng mô hình nhãn	❌ Khác mô hình
Tương quan Log-to-trace	✅ Tích hợp tự nhiên	❌ Cần thiết lập thêm
Khả năng mở rộng	Theo chiều ngang (S3)	Theo chiều ngang (Elasticsearch)
Giấy phép bản quyền	AGPLv3	Elastic License (BSL)
AWS Managed	Không có (sử dụng Grafana Cloud)	OpenSearch (AWS fork)

Nhận định chung:

Đội ngũ đang sử dụng Grafana + Prometheus → Loki (cùng mô hình nhãn, tích hợp tự nhiên)
Đội ngũ cần tìm kiếm full-text, phân tích phức tạp → Elasticsearch / OpenSearch
Đội ngũ cần tối ưu chi phí ở quy mô lớn → Loki (thường rẻ hơn từ 10–20 lần)

2.1 Dual-path: Loki + OpenSearch/Elasticsearch cho AIOps¶

Ý TƯỞNG

Loki và Elasticsearch đều là log store, nhưng tối ưu trục ngược nhau: $/GB + kỷ luật label vs full-text + aggregation linh hoạt. Nhiều AIOps production chạy cả hai — không vì thích tốn tiền, mà vì một tool không thắng mọi kiểu query.

Đường	Store	Ghi gì	Đọc cho
Hot ops / AIOps default	Loki	Log app & infra volume cao, label chặt	On-call LogQL, label→trace, retention rẻ
Search / IR / compliance	OpenSearch / Elasticsearch	Audit, security, subset app log, text ticket	Full-text, boolean phức tạp, legal search dài
Analytics / feature (tuỳ chọn)	ClickHouse hoặc lake (Parquet)	Field đã parse, aggregate	Aggregate nặng, export train

Khi dual-write đáng

Security / IR phải grep chuỗi tuỳ ý 90+ ngày
Compliance cần pattern query label Loki không rẻ
LLM investigation cần index full-text nhỏ log liên quan incident, không 100% debug

Khi dual-write lãng phí

100% volume sang ES “cho chắc” → bom chi phí cổ điển
Dùng ES làm metric store hoặc feature store AIOps duy nhất
Không owner ILM, shard, mapping explosion

Pattern AIOps khuyến nghị:
  Mọi log → Fluent Bit / OTel → Loki (default)
  Subset (audit, auth, payment, security) → OpenSearch
  Field structured đã parse → Kafka → Flink/features (không dùng ES làm stream processor)

	Loki	Elasticsearch / OpenSearch
Ưu cho AIOps	Hot path rẻ; label kiểu Prom; Grafana/Tempo native	Search tuỳ ý nhanh; tooling IR chín
Nhược cho AIOps	Yếu “google đống log”; scan content đắt	RAM index; mapping drift; field cardinality
Prefer khi	SLO/debug theo service/ns/level	Forensics, full-text RCA, legal hold

Warning

Đừng xếp Flink hay Fluent Bit cùng bucket so sánh với Elasticsearch. Shipper thu thập; Flink transform trên bus; ES/Loki lưu và query. Xem 02 — collection agents và 06 — stream processors.

3. Internal Architecture¶

Distributed Mode Components¶

graph TD
    subgraph Ingest["Write Path"]
        DIST[Distributor\nvalidate · hash · replicate]
        ING1[Ingester 1\nWAL + chunks in memory]
        ING2[Ingester 2]
        ING3[Ingester 3]
    end

    subgraph Query["Read Path"]
        QF[Query Frontend\ncache · split · schedule]
        QS[Query Scheduler\nwork queue]
        QUER[Querier\nfan-out to ingesters + store]
    end

    subgraph Storage["Storage"]
        INDEX[(Index\nBoltDB-shipper / tsdb)]
        CHUNKS[(Chunks\nAWS S3)]
        CACHE[Cache\nMemcached / Redis]
    end

    subgraph Compaction["Background"]
        COMP[Compactor\nmerge · dedup · retention]
        RULER[Ruler\nalert · recording rules]
    end

    CLIENT[Log Source\nGrafana Alloy\nOTel Collector] -->|HTTP POST /loki/api/v1/push| DIST
    DIST -->|consistent hash ring| ING1
    DIST -->|consistent hash ring| ING2
    DIST -->|consistent hash ring| ING3

    ING1 -->|flush| CHUNKS
    ING1 -->|flush| INDEX
    ING2 -->|flush| CHUNKS
    ING3 -->|flush| CHUNKS

    CLIENT2[Grafana] -->|LogQL| QF
    QF -->|split by time| QS
    QS -->|schedule| QUER
    QUER -->|recent logs| ING1
    QUER -->|recent logs| ING2
    QUER -->|old logs| CHUNKS
    QUER -->|old logs| INDEX
    QUER -->|cache hit| CACHE

    COMP -->|merge small chunks| CHUNKS
    COMP -->|enforce retention| CHUNKS

    style Ingest fill:#dbeafe,color:#1e293b
    style Query fill:#dcfce7,color:#1e293b
    style Storage fill:#f3e8ff,color:#1e293b
    style Compaction fill:#ffedd5,color:#1e293b

Component Responsibilities¶

Thành phần	Vai trò	Có trạng thái (Stateful)?	Hướng mở rộng (Scale)
Distributor	Xác thực, phân tách luồng băm (hash stream), phân phối tới ingesters	Không (No)	Chiều ngang
Ingester	Bộ đệm ghi trên memory + WAL, đẩy dữ liệu (flush) lên S3	Có (Yes)	Chiều ngang (hash ring)
Query Frontend	Nhận truy vấn, chia tách theo thời gian, lên lịch, lưu cache	Không (No)	Chiều ngang
Query Scheduler	Hàng đợi công việc giữa frontend và các queriers	Không (No)	Chiều ngang
Querier	Thực thi LogQL đối với ingesters + S3	Không (No)	Chiều ngang
Compactor	Gộp các chunks nhỏ, thực thi chính sách retention	Có (Yes) (chạy singleton)	Chiều dọc
Ruler	Đánh giá các quy tắc cảnh báo/recording rules	Không (No)	Chiều ngang
Index Gateway	Phục vụ các truy vấn chỉ mục (dành cho tsdb index)	Không (No)	Chiều ngang

4. Data Flow — Ingestion Path¶

sequenceDiagram
    participant Agent as Grafana Alloy / OTel Collector
    participant DIST as Distributor
    participant ING as Ingester (×3)
    participant WAL as Ingester WAL
    participant S3 as AWS S3

    Agent->>DIST: POST /loki/api/v1/push\n{streams: [{stream: {labels}, values: [[ts, line]]}]}
    DIST->>DIST: Kiểm tra nhãn (cardinality check)
    DIST->>DIST: Băm nhãn stream → chọn các ingesters (replication_factor=3)
    DIST->>ING: Chuyển tiếp các log entries (tới 3 ingesters)
    ING->>WAL: Ghi nối đuôi vào WAL (đảm bảo độ bền dữ liệu)
    ING->>ING: Đệm dữ liệu trên memory (compressed chunk)
    ING-->>DIST: Đồng thuận Quorum (2/3 ingesters xác nhận)
    DIST-->>Agent: 204 No Content

    Note over ING: Mỗi khi đạt chunk_target_size (1.5MB) hoặc chunk_idle_period (30m)...
    ING->>S3: Upload chunk đã nén
    ING->>S3: Ghi thông tin index (stream → vị trí lưu chunk)

Push API Format¶

Endpoint: POST /loki/api/v1/push

Content-Type: application/json hoặc application/x-protobuf (snappy-compressed)

{
  "streams": [
    {
      "stream": {
        "service": "order-service",
        "namespace": "production",
        "level": "ERROR",
        "region": "us-east-1"
      },
      "values": [
        ["1705329825123456789", "{\"ts\":\"2024-01-15T14:23:45.123Z\",\"level\":\"ERROR\",\"message\":\"Order processing failed\",\"trace_id\":\"4bf92f35\",\"order_id\":\"ord-123\"}"],
        ["1705329825234567890", "{\"ts\":\"2024-01-15T14:23:45.234Z\",\"level\":\"ERROR\",\"message\":\"Payment gateway timeout\",\"trace_id\":\"4bf92f35\"}"]
      ]
    }
  ]
}

Định dạng Value: [timestamp_nanoseconds_string, log_line_string]

5. Data Flow — Query Path¶

sequenceDiagram
    participant Grafana
    participant QF as Query Frontend
    participant QS as Query Scheduler
    participant QR as Querier (×N)
    participant ING as Ingester
    participant S3 as AWS S3
    participant Cache as Memcached

    Grafana->>QF: GET /loki/api/v1/query_range?query={...}&start=...&end=...
    QF->>Cache: Kiểm tra bộ nhớ đệm (bằng mã băm truy vấn + khoảng thời gian)
    Cache-->>QF: Cache bị hụt (Cache miss)

    QF->>QF: Phân chia khoảng thời gian thành các truy vấn con (split_queries_by_interval=24h)
    QF->>QS: Đưa các truy vấn con vào hàng đợi

    loop Cho mỗi truy vấn con
        QS->>QR: Giao truy vấn con
        QR->>ING: Truy vấn các chunks gần đây (trong 2h qua)
        QR->>S3: Truy vấn index → lấy vị trí các chunks
        QR->>S3: Tải về và giải nén các chunks
        QR->>QR: Lọc dữ liệu + tổng hợp
        QR-->>QS: Trả về kết quả
    end

    QS-->>QF: Gộp kết quả
    QF->>Cache: Lưu kết quả vào bộ nhớ đệm
    QF-->>Grafana: Trả về kết quả LogQL đã gộp

Key API Endpoints¶

Endpoint	Method	Mô tả
`/loki/api/v1/push`	POST	Nạp (ingest) logs
`/loki/api/v1/query`	GET	Truy vấn tức thời (tại một thời điểm đơn lẻ)
`/loki/api/v1/query_range`	GET	Truy vấn theo khoảng thời gian (cho dashboards)
`/loki/api/v1/series`	GET	Liệt kê các streams khớp với bộ lọc (selector)
`/loki/api/v1/labels`	GET	Liệt kê toàn bộ tên các nhãn
`/loki/api/v1/label/{name}/values`	GET	Liệt kê các giá trị của một nhãn cụ thể
`/loki/api/v1/tail`	GET (WebSocket)	Xem log trực tiếp thời gian thực (Live tail)
`/loki/api/v1/index/stats`	GET	Thống kê chỉ mục (độ cardinality)
`/loki/api/v1/index/volume`	GET	Dung lượng log theo nhãn
`/ready`	GET	Kiểm tra tính sẵn sàng
`/metrics`	GET	Các metrics Prometheus

6. LogQL Deep Dive¶

LogQL là ngôn ngữ truy vấn của Loki. Nó bao gồm hai phần: 1. Log stream selector (luôn luôn bắt buộc, tương tự bộ lọc nhãn của Prometheus) 2. Pipeline expressions (các biểu thức lọc, biến đổi, tổng hợp)

Stream Selectors¶

# Lọc toàn bộ logs từ order-service trong môi trường production
{service="order-service", namespace="production"}

# Regex khớp nhãn
{service=~"order.*|payment.*", namespace="production"}

# Lọc phủ định
{service="order-service", level!="DEBUG"}

# Phải khớp tối thiểu một nhãn (về hiệu năng: hãy khai báo càng nhiều nhãn càng tốt)
{namespace="production"}

Log Pipeline — Filter Expressions¶

# Chứa chuỗi (phân biệt chữ hoa/thường)
{service="order-service"} |= "ERROR"

# Chứa chuỗi (không phân biệt chữ hoa/thường)
{service="order-service"} |~ "(?i)error"

# Regex khớp nội dung
{service="order-service"} |~ "order_id=\"[0-9]+\""

# Phủ định (KHÔNG chứa chuỗi)
{service="order-service"} != "health check"

# Lọc nhiều điều kiện (logic AND)
{service="order-service"} |= "ERROR" |= "payment"

Log Pipeline — Parser Expressions¶

# Phân tích log line định dạng JSON
{service="order-service"} | json

# Phân tích JSON, sau đó lọc theo trường trích xuất được
{service="order-service"} | json | level="ERROR"

# Chỉ trích xuất một số trường cụ thể từ JSON
{service="order-service"} | json event, order_id, duration_ms

# Phân tích định dạng logfmt (định dạng key=value)
{service="order-service"} | logfmt | level="error"

# Phân tích theo mẫu (định danh các trường)
{service="nginx"} | pattern `<ip> - <user> [<ts>] "<method> <path> <proto>" <status> <size>`

# Phân tích theo biểu thức chính quy (Regexp parser)
{service="order-service"} | regexp `order_id=(?P<order_id>[0-9]+)`

Metric Queries (Log-derived Metrics)¶

# Đếm số lượng dòng log mỗi phút theo từng service
sum by (service) (
  count_over_time({namespace="production"}[1m])
)

# Tần suất lỗi (logs/phút)
sum by (service) (
  count_over_time({namespace="production"} |= "ERROR" [1m])
)

# Trích xuất giá trị số từ log và tính toán rate
sum by (service) (
  rate({service="order-service"} | json | unwrap duration_ms [1m])
)

# Phân vị 99 của trường duration trích xuất từ logs
quantile_over_time(0.99,
  {service="order-service"} | json | unwrap duration_ms [5m]
) by (service)

# Dung lượng log (bytes) trên mỗi giây
sum by (service) (
  bytes_rate({namespace="production"}[1m])
)

Practical Production Queries¶

# Tìm toàn bộ lỗi trong giờ qua kèm theo thông tin trace ID
{namespace="production"} |= "ERROR" | json
  | line_format "{{.ts}} [{{.service}}] {{.message}} trace={{.trace_id}}"

# Phát hiện các pod bị khởi động lại (do OOMKilled)
{namespace="production"} |= "OOMKilled"

# Tìm các yêu cầu xử lý chậm (> 1000ms trích xuất từ log có cấu trúc)
{service="order-service"} | json | duration_ms > 1000

# Đếm số lượng lỗi theo từng loại lỗi (error type)
sum by (error_type) (
  count_over_time({namespace="production"} | json | level="ERROR" [5m])
)

# Tìm logs cho một trace ID cụ thể (tương quan metric → trace → log)
{namespace="production"} |= "4bf92f3577b34da6a"

7. Label Design¶

Thiết kế nhãn là quyết định kiến trúc quan trọng nhất ảnh hưởng trực tiếp đến hiệu năng của Loki.

Principles¶

Nhãn được đánh chỉ mục — sử dụng cho các truy vấn có độ chọn lọc cao (service, namespace, level)
Nội dung log không được đánh chỉ mục — thực hiện lọc bằng biểu thức |= (quét toàn bộ các chunks khớp nhãn)
Yêu cầu cardinality nhãn thấp — mỗi tổ hợp nhãn duy nhất tạo ra một stream riêng biệt

Good Label Schema¶

# Các nhãn tiêu chuẩn áp dụng cho tất cả dịch vụ
labels:
  # Metadata Kubernetes (luôn bao gồm)
  namespace: production          # ~10 giá trị khác nhau
  cluster: prod-us-east-1        # ~5 giá trị khác nhau

  # Định danh dịch vụ
  service: order-service         # ~50-200 giá trị khác nhau

  # Cấp độ log (sử dụng hạn chế — vì tạo thêm luồng stream riêng cho từng cấp độ)
  level: ERROR                   # INFO, WARN, ERROR, CRITICAL

  # Vùng địa lý
  region: us-east-1              # ~5 giá trị khác nhau

# Tổng cardinality nhãn ước tính: 10 × 5 × 200 × 4 × 5 = 200,000 streams
# Mức này là hoàn toàn chấp nhận được (giới hạn an toàn: ~1M streams trên mỗi Loki)

Bad Label Schema (Các thói quen xấu - Anti-Patterns)¶

# KHÔNG BAO GIỜ đưa các thông tin này vào nhãn:
bad_labels:
  trace_id: "4bf92f35..."       # Duy nhất trên mỗi yêu cầu → tạo ra vô số streams
  user_id: "user-789"           # Hàng triệu giá trị duy nhất
  request_id: "req-abc123"      # Duy nhất trên mỗi yêu cầu
  pod: "order-svc-abc123-xyz"   # Giá trị thay đổi liên tục khi khởi động lại pod
  timestamp: "2024-01-15"       # Tăng trưởng không giới hạn

# Các thông tin này nên nằm trong LOG BODY (các trường JSON), không đưa vào nhãn.
# Truy vấn chúng bằng biểu thức: | json | trace_id = "4bf92f35"

Dynamic Labels với Grafana Alloy¶

// Cấu hình Grafana Alloy (thay thế cho Promtail)
// Tự động trích xuất namespace và pod làm nhãn từ Kubernetes
loki.source.kubernetes "pods" {
  targets    = discovery.kubernetes.pods.targets
  forward_to = [loki.process.add_labels.receiver]
}

loki.process "add_labels" {
  stage.static_labels {
    values = {
      cluster = "prod-us-east-1",
      region  = "us-east-1",
    }
  }

  stage.kubernetes {}   // Tự động thêm các nhãn: namespace, pod, container, node

  // Phân tích log body dạng JSON và trích xuất trường level
  stage.json {
    expressions = {
      level = "level",
    }
  }

  stage.labels {
    values = {
      level = "",   // Đẩy trường trích xuất được thành nhãn
    }
  }

  // Loại bỏ logs DEBUG trước khi gửi tới Loki (để tiết kiệm chi phí)
  stage.drop {
    expression  = ".*"
    drop_counter_reason = "debug_dropped"
    stages {
      stage.match {
        selector = "{level=\"DEBUG\"}"
        action   = "drop"
      }
    }
  }

  forward_to = [loki.write.default.receiver]
}

loki.write "default" {
  endpoint {
    url = "http://loki-distributor.observability.svc.cluster.local:3100/loki/api/v1/push"
    tenant_id = "production"
  }
}

8. Ingestion Methods¶

Phương pháp	Công cụ sử dụng	Khi nào sử dụng
Kubernetes pod logs	Grafana Alloy (DaemonSet)	Thu thập toàn bộ pod logs qua thư mục `/var/log/pods`
Gửi trực tiếp từ ứng dụng	OTel Collector Loki Exporter	logs có cấu trúc từ các dịch vụ đã được thiết lập mã nguồn
AWS CloudWatch Logs	CloudWatch → Kinesis → Lambda → Loki	logs từ các dịch vụ AWS
Syslog	Grafana Alloy syslog receiver	logs hệ thống/thiết bị mạng
Docker logs	Grafana Alloy Docker discovery	Môi trường Docker Compose
Kafka	Grafana Alloy Kafka consumer	Các sự kiện log truyền từ Kafka topics
Gửi qua HTTP trực tiếp	Mã nguồn tùy chỉnh của ứng dụng	Các luồng ghi log đơn giản, lượng tải thấp

Grafana Alloy vs Promtail¶

Tính năng	Grafana Alloy	Promtail
Trạng thái	Hiện tại, đang được phát triển tích cực	Đã EOL từ ngày 02/03/2026; không dùng cho triển khai mới
Cấu hình	Ngôn ngữ River	YAML
Đa tín hiệu	Hỗ trợ Metrics + Logs + Traces	Chỉ hỗ trợ Logs
Tương thích OTel	✅ Có hỗ trợ tự nhiên	❌ Không
Mức tiêu thụ tài nguyên	Cao hơn một chút	Thấp hơn

Khuyến nghị: Sử dụng Grafana Alloy cho triển khai mới và chuyển cấu hình Promtail hiện có sang Alloy. Không giữ Promtail chỉ vì file YAML cũ: sau EOL, đó là một dependency không còn được hỗ trợ.

9. Storage Backend¶

Index Storage¶

Loại Index	Mô tả	Khi nào sử dụng
tsdb (mặc định, Loki 2.8+)	Chỉ mục định dạng Prometheus TSDB, lưu trữ trên object storage	Môi trường Production (khuyến nghị)
boltdb-shipper	Các file BoltDB được đẩy lên S3	Đã cũ, đang dần bị loại bỏ
cassandra	Cluster Cassandra	Quy mô cực kỳ lớn (>10M streams)
bigtable	Google Bigtable	Triển khai trên môi trường GCP

Chunk Storage¶

Bộ lưu trữ	Mô tả	Khi nào sử dụng
AWS S3	Lựa chọn tiêu chuẩn phổ biến	Hầu hết các triển khai production
GCS	Google Cloud Storage	Môi trường GCP
Azure Blob	Azure Blob Storage	Môi trường Azure
Filesystem	Lưu trên ổ cứng cục bộ	Chỉ dùng cho mục đích phát triển/thử nghiệm

S3 Configuration¶

storage_config:
  aws:
    s3: s3://us-east-1/loki-chunks-prod
    region: us-east-1
    # Sử dụng IAM role (IRSA) - không bao giờ dùng static credentials thô

  tsdb_shipper:
    active_index_directory: /loki/tsdb-index-active
    cache_location: /loki/tsdb-cache

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: s3
      schema: v13          # Phiên bản schema mới nhất
      index:
        prefix: loki_index_
        period: 24h        # Phân chia index files theo từng ngày

Chunk Compression¶

Loki nén các log chunks trước khi tải lên S3:

Codec	Tỷ lệ nén	Tốc độ	Trạng thái mặc định
snappy	Xấp xỉ ~3:1	Nhanh	Mặc định trên Loki <2.8
gzip	Xấp xỉ ~5:1	Chậm hơn	Lựa chọn thay thế
lz4	Xấp xỉ ~2:1	Rất nhanh	Dành cho throughput cao
zstd	Xấp xỉ ~6:1	Nhanh	Khuyến nghị để tối ưu chi phí

chunk_store_config:
  chunk_cache_config:
    enable_fifocache: true
    fifocache:
      max_size_bytes: 500MB

ingester:
  chunk_encoding: zstd    # Cho tỷ lệ nén tốt nhất với tốc độ chấp nhận được
  chunk_target_size: 1572864  # Kích cỡ đích 1.5MB cho mỗi chunk (có thể tinh chỉnh)
  chunk_idle_period: 30m      # Thực hiện đẩy dữ liệu (flush) sau khi không hoạt động 30m
  chunk_retain_period: 5m     # Giữ lại trên memory sau khi flush (phục vụ các truy vấn nhanh)

10. Deployment Modes¶

Single Binary (Cho môi trường phát triển/thử nghiệm)¶

# Toàn bộ các thành phần chạy chung trong một tiến trình duy nhất
loki -config.file=loki-config.yaml -target=all

Simple Scalable (Production quy mô nhỏ)¶

# Phân chia làm 3 deployments: write, backend, read
loki -target=write    # Distributors + Ingesters
loki -target=backend  # Compactor + Ruler + Index Gateway
loki -target=read     # Query Frontend + Scheduler + Querier

Microservices (Production quy mô lớn)¶

Mỗi thành phần được triển khai chạy độc lập. Đạt khả năng mở rộng tối đa. Độ phức tạp cấu hình cao nhất.

targets:
  distributor: 3 replicas
  ingester: 6 replicas (chạy dưới dạng StatefulSet)
  query-frontend: 2 replicas
  query-scheduler: 2 replicas
  querier: 4 replicas
  compactor: 1 replica (chạy duy nhất dạng singleton!)
  ruler: 2 replicas
  index-gateway: 2 replicas

11. Kubernetes Deployment¶

Helm Installation¶

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# Triển khai Loki ở chế độ simple-scalable
helm install loki grafana/loki \
  --namespace observability \
  --values loki-values.yaml

Production Helm Values¶

# loki-values.yaml
loki:
  # Chế độ Simple scalable (tách biệt luồng read/write/backend)
  deployment_mode: SimpleScalable

  auth_enabled: true    # Bật tính năng đa người thuê (Multi-tenant)

  commonConfig:
    replication_factor: 3

  storage:
    type: s3
    s3:
      region: us-east-1
      bucketNames:
        chunks: loki-chunks-prod
        ruler: loki-ruler-prod
        admin: loki-admin-prod
      # Xác thực bằng cơ chế IRSA

  limits_config:
    # Các giới hạn mặc định toàn cục (có thể ghi đè riêng cho từng tenant)
    retention_period: 744h         # Thời gian lưu giữ 31 ngày
    ingestion_rate_mb: 50          # Giới hạn nạp dữ liệu 50MB/s cho mỗi tenant
    ingestion_burst_size_mb: 100
    max_streams_per_user: 100000   # Số lượng stream tối đa của một tenant
    max_line_size: 65536           # Độ dài dòng log tối đa 64KB
    max_label_names_per_series: 30 # Số lượng nhãn tối đa trên mỗi stream
    max_label_value_length: 2048

    # Các giới hạn truy vấn
    max_query_series: 5000
    max_query_lookback: 0          # Không giới hạn thời gian truy vấn ngược (tuân theo retention)
    max_entries_limit_per_query: 50000

  schemaConfig:
    configs:
      - from: "2024-01-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: "loki_index_"
          period: "24h"

  structuredConfig:
    ingester:
      chunk_encoding: zstd
      chunk_target_size: 1572864
      chunk_idle_period: 30m

    query_scheduler:
      max_outstanding_requests_per_tenant: 2048

    frontend:
      compress_responses: true
      max_outstanding_per_tenant: 2048

# Luồng ghi (Write path)
write:
  replicas: 3
  resources:
    requests:
      cpu: "1"
      memory: "2Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  persistence:
    enabled: true
    size: 10Gi    # Bộ lưu trữ WAL

# Luồng đọc (Read path)  
read:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "1Gi"
    limits:
      cpu: "2"
      memory: "4Gi"

# Các dịch vụ nền (Backend)
backend:
  replicas: 2
  persistence:
    enabled: true
    size: 10Gi

# Không triển khai chung Agent thu thập ở đây
grafana-agent:
  enabled: false    # Triển khai riêng biệt dưới dạng DaemonSet

minio:
  enabled: false    # Sử dụng trực tiếp AWS S3 thay thế

12. Production Configuration¶

Multi-Tenancy¶

# loki-config.yaml
auth_enabled: true    # Bắt buộc phải truyền header X-Scope-OrgID khi gọi API

# Cấu hình ghi đè giới hạn cho từng tenant
limits_config:
  per_tenant_override_config: /etc/loki/overrides.yaml

# overrides.yaml
overrides:
  production_team_a:
    ingestion_rate_mb: 100
    max_streams_per_user: 200000
    retention_period: 720h    # Lưu giữ dữ liệu trong 30 ngày

  production_team_b:
    ingestion_rate_mb: 20
    max_streams_per_user: 50000
    retention_period: 168h    # Lưu giữ dữ liệu trong 7 ngày

  development:
    ingestion_rate_mb: 5
    retention_period: 48h     # Chỉ lưu giữ dữ liệu trong 2 ngày

Alerting and Recording Rules trong Loki¶

# Cấu hình Loki ruler
ruler:
  storage:
    type: s3
    s3:
      buckets_name: loki-ruler-prod
      region: us-east-1

  rule_path: /tmp/loki-rules
  ring:
    kvstore:
      store: memberlist

  enable_api: true
  enable_alertmanager_v2: true

  alertmanager_url: http://alertmanager.observability.svc.cluster.local:9093

# File định nghĩa quy tắc (được lưu trữ trên bộ lưu trữ của Loki ruler)
groups:
  - name: log-alerts
    interval: 1m
    rules:
      - alert: HighErrorLogRate
        expr: |
          sum by (service) (
            rate({namespace="production"} |= "ERROR" [5m])
          ) > 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High ERROR log rate in {{ $labels.service }}"

      - record: service:log_error_rate:rate5m
        expr: |
          sum by (service) (
            rate({namespace="production"} |= "ERROR" [5m])
          )

13. Common Mistakes¶

Sai lầm phổ biến	Triệu chứng	Khắc phục
Khai báo nhãn có Cardinality cao (trace_id, user_id)	Xuất hiện lỗi "Too many streams", Loki bị OOM crash	Đưa các thông tin này vào log body. Thực hiện truy vấn qua biểu thức lọc: `\\| json \\| trace_id="..."`
Không sử dụng định dạng logs có cấu trúc	Các câu lệnh truy vấn dạng `\\|=` buộc phải quét qua toàn bộ dữ liệu	Chuyển đổi dữ liệu sang dạng JSON. Sử dụng bộ phân tích cú pháp `\\| json`.
Thiếu nhãn định danh namespace/service	Không thể lọc tìm log theo từng service cụ thể	Bắt buộc áp đặt bộ nhãn tối thiểu khi cấu hình Alloy
Chọn sai khoảng thời gian truy vấn	Thực hiện truy vấn trên 30 ngày log mà không có nhãn lọc giới hạn	Luôn sử dụng bộ lọc nhãn stream selector kết hợp giới hạn khoảng thời gian ngắn
Không cấu hình các giới hạn truy vấn	Một truy vấn quá nặng của một người dùng có thể kéo sập toàn bộ Loki	Thiết lập cấu hình giới hạn truy vấn riêng cho mỗi tenant
Chạy nhiều hơn một instance Compactor	Gây ra lỗi hỏng chỉ mục (index corruption)	Chỉ cấu hình duy nhất đúng 1 replica cho compactor
Không giám sát độ trễ nạp dữ liệu (ingest lag)	Gây ra lỗi mất mát dữ liệu ngầm	Cài đặt cảnh báo giám sát độ trễ đẩy dữ liệu (push latency) của distributor
Cấu hình hệ số bản sao Replication factor = 1	Mất mát dữ liệu khi một ingester bị lỗi	Luôn thiết lập hệ số `replication_factor=3` trong production
Lưu trữ log trên ổ đĩa cục bộ của node	Gây mất mát dữ liệu và không thể mở rộng quy mô	Sử dụng bộ lưu trữ S3 ngoài làm lưu trữ duy nhất
Thiếu chính sách cấu hình thời gian lưu giữ (retention)	Bộ lưu trữ tăng trưởng không giới hạn làm phát sinh chi phí	Thiết lập thời gian `retention_period` phù hợp cho mỗi tenant

14. Monitoring Loki¶

# Sức khỏe luồng nạp dữ liệu (Ingestion health)
rate(loki_distributor_bytes_received_total[5m])          # Lưu lượng nạp (bytes/giây)
rate(loki_distributor_lines_received_total[5m])          # Số lượng dòng log/giây
rate(loki_ingester_chunk_store_persisted_errors[5m])     # Số lượng lỗi khi đẩy dữ liệu lên S3

# Sức khỏe của Ingester (Ingester health)
loki_ingester_chunks_count                               # Chunks đang lưu trên memory
loki_ingester_streams_created_total                      # Tần suất tạo stream mới/giây
loki_ingester_memory_streams                             # Số lượng streams đang đệm trên memory
loki_ingester_wal_records_logged_total                   # Tần suất ghi log vào WAL/giây

# Hiệu năng truy vấn (Query performance)
loki_request_duration_seconds{route="/loki/api/v1/query_range", quantile="0.99"}
loki_query_frontend_retries_total                        # Số lần thử lại của Scheduler
loki_querier_tail_active                                 # Số lượng kết nối tail logs đang hoạt động

# Bộ lưu trữ (Storage)
loki_boltdb_shipper_compact_tables_operation_duration_seconds
rate(loki_chunk_store_series_rejected_requests_total[5m]) # Các yêu cầu ghi dữ liệu bị từ chối

Critical Alerts¶

- alert: LokiIngestionRateHigh
  expr: |
    sum(rate(loki_distributor_bytes_received_total[1m])) > 100e6  # Vượt quá >100MB/s
  for: 5m
  labels:
    severity: warning

- alert: LokiIngesterNotFlushing
  expr: |
    rate(loki_ingester_chunks_flushed_total[5m]) == 0
  for: 15m
  labels:
    severity: critical

- alert: LokiQueryDurationHigh
  expr: |
    histogram_quantile(0.99,
      rate(loki_request_duration_seconds_bucket{route=~"/loki/api/v1/query.*"}[5m])
    ) > 30
  for: 5m
  labels:
    severity: warning

15. Scaling¶

Write Path Scaling¶

Điểm nghẽn	Metric giám sát	Khắc phục
CPU của Distributor	Chỉ số `loki_distributor_bytes_received_total` tăng cao	Bổ sung thêm các replicas cho distributor
Memory của Ingester	Chỉ số `loki_ingester_memory_streams` tăng cao	Bổ sung thêm các replicas cho ingester (hash ring sẽ tự động tái phân bổ tải)
Tốc độ đẩy dữ liệu lên S3	Chỉ số `loki_ingester_chunk_store_persist_duration` tăng cao	Tinh chỉnh lại kích cỡ chunk, bổ sung thêm ingesters

Read Path Scaling¶

Điểm nghẽn	Metric giám sát	Khắc phục
Độ trễ truy vấn (Query latency)	Latency P99 của truy vấn tăng cao	Bổ sung thêm các replicas cho querier
Hết thời gian truy vấn (Timeout)	Chỉ số `loki_query_frontend_retries_total` tăng dần	Thiết lập phân tách truy vấn theo thời gian, bổ sung query scheduler
Tỷ lệ hụt cache	Tỷ lệ cache miss của Memcached tăng cao	Tăng dung lượng memory cấp phát cho Memcached

Querier Autoscaling¶

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: loki-querier-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: loki-querier
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: loki_querier_queue_length
        target:
          type: AverageValue
          averageValue: "10"

16. Security¶

mTLS Between Components¶

# loki-config.yaml
server:
  grpc_tls_config:
    cert_file: /certs/loki.crt
    key_file: /certs/loki.key
    client_ca_file: /certs/ca.crt
    client_auth_type: RequireAndVerifyClientCert

Multi-Tenant Access Control¶

# Sử dụng NGINX hoặc Grafana làm cổng xác thực (auth proxy)
# Mỗi team gửi kèm header X-Scope-OrgID chứa thông tin tenant ID của họ
# Loki lưu trữ phân tách dữ liệu hoàn toàn độc lập cho mỗi tenant

# Ví dụ: Cấu hình Grafana data source cho mỗi team
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasource-loki
data:
  loki.yaml: |
    datasources:
      - name: Loki-Production
        type: loki
        url: http://loki-gateway.observability.svc.cluster.local:3100
        jsonData:
          httpHeaderName1: X-Scope-OrgID
        secureJsonData:
          httpHeaderValue1: production

IRSA for S3 Access¶

# ServiceAccount gán kèm annotation của IRSA
apiVersion: v1
kind: ServiceAccount
metadata:
  name: loki
  namespace: observability
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/loki-s3-role

# IAM chính sách gán cho Loki
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::loki-chunks-prod/*",
        "arn:aws:s3:::loki-chunks-prod"
      ]
    }
  ]
}

17. Cost¶

Storage Cost Calculation¶

Lưu lượng nạp log: 100MB/phút (trước khi nén)
Tỷ lệ nén thực tế (zstd): 6:1
Tốc độ sau khi nén: 100/6 = 16.7MB/phút = 24GB/ngày

Chi phí lưu trữ S3:
- Thời gian lưu giữ 30 ngày: 30 × 24GB = 720GB
- Phí lưu trữ S3 Standard: 720GB × $0.023/GB = $16.56/tháng

Chi phí truyền tải dữ liệu (Data transfer):
- Truy vấn index: rất nhỏ
- Tải chunks về để đọc: Ước tính bằng 10% dung lượng lưu trữ = 72GB × $0.09/GB = $6.48/tháng

Tổng chi phí S3: ~$23/tháng cho luồng nạp 100MB/phút

Compute Cost (EKS)¶

Thành phần	Số lượng Replica	Loại Instance sử dụng	Chi phí hàng tháng
Distributor	3	t3.medium	$90
Ingester	6	m6i.xlarge (4 CPU, 16GB)	$720
Querier	4	m6i.large	$240
Query Frontend	2	t3.medium	$60
Backend	2	m6i.large	$240
Tổng chi phí compute			~$1,350/tháng

Tối ưu hóa chi phí:

Sử dụng Spot instances cho queriers (giúp tiết kiệm -60% chi phí phần này)
Thành phần Ingesters bắt buộc phải chạy trên On-Demand instances (do có trạng thái ghi đệm dữ liệu, không được phép mất WAL)
Tổng chi phí sau khi tối ưu Spot cho queriers: khoảng ~$1,100/tháng

ELK Stack Comparison¶

Chi phí hạ tầng ELK stack (Elasticsearch + Logstash + Kibana) tương đương cho cùng một lượng tải log trên: - 3× Elasticsearch master nodes: r6i.2xlarge = $870/tháng - 6× Elasticsearch data nodes: r6i.4xlarge (128GB RAM mỗi node) = $3,500/tháng - Dung lượng lưu trữ: 720GB × 3 replicas = 2.16TB EBS gp3 = $210/tháng - Tổng chi phí ELK: ~$4,580/tháng

Loki giúp tiết kiệm khoảng ~$3,230/tháng so với ELK cho cùng khối lượng công việc.

18. Tư duy problem-solving trong production¶

Ý TƯỞNG

Loki thắng khi bạn tôn trọng thiết kế index-labels-only. Loki thua khi team dùng nó như Elasticsearch (mọi field là index) hoặc khi LogQL trở thành ngôn ngữ chỉ 2 người trong công ty đọc được. Production thinking: stream cardinality, tenant fairness, schema migration.

18.1 Vì sao chỉ index labels — đây là trade-off có chủ đích¶

Loki lấy cảm hứng Prometheus:

Labels → xác định stream (index nhỏ, rẻ, RAM-sensitive).
Nội dung log line → lưu chunk (object storage), filter lúc query.

Nếu bạn...	Hệ quả
Thêm `user_id` vào label	Stream nổ → ingester RAM chết
Để `user_id` trong JSON line	Query chậm hơn chút nhưng scale được
Query không có stream selector	Quét rộng → timeout / công bằng tenant vỡ
Có quá ít labels	Khó thu hẹp → cũng chậm

Vì sao

Elasticsearch index full-text mua linh hoạt query bằng chi phí RAM/cluster. Loki mua $/GB rẻ bằng kỷ luật label + thói quen LogQL. AIOps team phải thiết kế schema log trước, không "index tất cả rồi tính sau".

18.2 LogQL cognitive load — ngôn ngữ mạnh, dễ viết query tự hại¶

LogQL kết hợp:

Stream selector {app="api"} — bắt buộc tư duy index.
Line filters |=, !=, |~ — rẻ hơn parser nếu đủ.
Parsers | json, | logfmt, | regexp — CPU query path.
Label filters sau parse | level="error" — trên kết quả parse.
Metric queries rate, topk — biến log thành time series.

Tư duy giảm tải nhận thức:

Viết LogQL như pipeline tối ưu:
  hẹp stream → lọc line rẻ → parse → filter field → aggregate
Không:
  parse tất cả 7 ngày rồi filter app (nhầm thứ tự / thiếu selector)

Edge

Query "tìm string toàn cluster 24h" có thể DOSS chính Loki và hàng xóm tenant. Cần limits, timeout, và văn hóa query có selector.

18.3 Noisy neighbor tenants — đa thuê là dao hai lưỡi¶

Multi-tenant tách bằng X-Scope-OrgID (hoặc auth gateway). Noisy neighbor:

Tenant A stream cardinality cao → ingester shared pressure.
Tenant B query quét khủng → querier/scheduler bão.
Tenant C retention/volume billing mù → cost surprise.

Tư duy fairness:

Mặt phẳng	Bảo vệ
Ingest	per-tenant rate limits, max streams
Query	max query length, parallelism, timeout
Storage	retention per tenant
Ops	separate ruler/alert budgets

18.4 Structured logging migration pain¶

Chuyển từ plain text → JSON không chỉ là "đổi format":

Dual-write / dual-parse giai chuyển (cũ và mới cùng sống).
Field name drift (msg vs message, ts vs time).
Dashboard & alert LogQL gãy hàng loạt.
Collector transform phải normalize trước Loki.
App libraries không đồng nhất (Java/Python/Node).

Ý TƯỞNG

Migration thành công khi có schema contract + enforce tại collector + canary service, không khi "gửi email nhờ anh em log JSON giùm".

18.5 Vòng problem-solving Loki¶

Ingest path:  agent → distributor → ingester → storage
Query path:   querier → ingester (recent) + store (old) → frontend

Symptom split:
  - mất log mới? → ingest/limits/auth tenant
  - query chậm? → selector/cardinality/cache/compactor
  - cost cao? → volume + retention + churn streams
  - sai log? → label design / parser / multi-tenant mix

19. Edge cases thực tế¶

EC-01 — Label `request_id` trên stream¶


Triệu chứng	Ingester OOM; `memory_streams` tăng thẳng đứng.
Nguyên nhân	Mỗi request một stream.
Phát hiện	Stream count per tenant; top label values.
Phòng	Label policy; reject high-card labels tại gateway/alloy.

EC-02 — Query không stream selector¶


Triệu chứng	UI timeout; querier CPU 100%.
Nguyên nhân	`{job=~".+"} \|= "error"` trên quá rộng.
Phát hiện	Query frontend logs; slow query log.
Phòng	Enforce required labels; max query series/timeout; training.

EC-03 — json parse trên log không phải JSON¶


Triệu chứng	Metric query từ log = 0 oan; dashboard trống.
Nguyên nhân	30% line plain text; `\| json` fail silent trong pipeline.
Phát hiện	Sample lines; `\| json \| __error__!=""` patterns.
Phòng	Normalize tại collector; stage migration flags.

EC-04 — Noisy tenant query storm¶


Triệu chứng	Tenant khác query chậm dù volume nhỏ.
Nguyên nhân	Shared queriers; không fair scheduling limits.
Phát hiện	Per-tenant query metrics; scheduler queue.
Phòng	Per-tenant max concurrency; separate priority; rate limit.

EC-05 — Out-of-order / timestamp skew drops¶


Triệu chứng	Thiếu log quanh NTP issues / batch late.
Nguyên nhân	Ingester reject out-of-order vượt cửa sổ.
Phát hiện	Discard metrics; agent clock.
Phòng	clock sync; configure acceptable window; prefer agent timestamp policy rõ.

EC-06 — Structured migration: field rename gãy alert¶


Triệu chứng	Alert `level="ERROR"` im; production đang lỗi.
Nguyên nhân	App đổi `level` → `severity`.
Phát hiện	Compare parse success ratio; canary alerts.
Phòng	Schema version field; collector map aliases; contract tests.

EC-07 — Cardinality từ `pod` + `path` + `status` ...¶


Triệu chứng	Stream limit hit; ingest 429.
Nguyên nhân	Quá nhiều label dims dù từng cái "có vẻ bounded".
Phát hiện	Stream growth after deploy.
Phòng	Budget combinations; drop pod from labels if app label đủ.

EC-08 — Cache miss storm sau deploy querier¶


Triệu chứng	S3 GET nổ; bill tăng; latency query.
Nguyên nhân	Cold cache; không memcached; parallel heavy.
Phát hiện	Cache hit ratio; S3 metrics.
Phòng	Chunk/index cache; warm critical dashboards; limit fanout.

EC-09 — Compactor/retention xóa nhầm kỳ vọng pháp lý¶


Triệu chứng	Audit log biến mất trước hạn.
Nguyên nhân	Global retention; tenant audit không tách.
Phát hiện	Retention config vs compliance matrix.
Phòng	Tenant retention overrides; separate stream for audit.

EC-10 — Multiline stacktrace bị vỡ dòng¶


Triệu chứng	Java exception không search được full.
Nguyên nhân	Agent split lines; không multiline config.
Phát hiện	Visual sample; compare app file vs Loki.
Phòng	Multiline stage Alloy/Promtail; JSON log 1-line exceptions.

EC-11 — Ruler LogQL metric spam eval¶


Triệu chứng	Ruler CPU cao; alert trễ.
Nguyên nhân	Rules quét rộng interval ngắn.
Phát hiện	Ruler metrics; rule group duration.
Phòng	Recording-like narrow selectors; interval hợp lý; split groups.

EC-12 — Auth gateway default tenant¶


Triệu chứng	Logs "mất" — thực ra vào tenant `fake`/default.
Nguyên nhân	Thiếu OrgID; multi-tenant mode on.
Phát hiện	Query đúng tenant; distributor labels.
Phòng	Reject missing tenant; dashboards có tenant var; integration tests.

20. Decision trees¶

20.1 Field mới: label hay nội dung log?¶

flowchart TD
    A[Field mới cần quan sát] --> B{Bounded low cardinality?}
    B -->|Không| C[JSON body / structured line]
    B -->|Có| D{Dùng để thu hẹp hầu hết query?}
    D -->|Có| E[Cân nhắc label — kiểm budget tổ hợp]
    D -->|Không| C
    E --> F{Tổ hợp labels vượt budget?}
    F -->|Có| G[Bỏ label ít giá trị nhất → body]
    F -->|Không| H[Add label + monitor streams]

20.2 Query chậm¶

flowchart TD
    A[LogQL timeout] --> B{Có stream selector hẹp?}
    B -->|Không| C[Thêm app/env/namespace]
    B -->|Có| D{Time range quá rộng?}
    D -->|Có| E[Thu hẹp + dùng metric query nếu cần]
    D -->|Không| F{Parse nặng trên volume lớn?}
    F -->|Có| G[Line filter trước parse; chuẩn hóa schema]
    F -->|Không| H[Cache / querier scale / hot streams?]

20.3 Noisy neighbor¶

flowchart TD
    A[Tenant khác bị chậm] --> B{Ingest hay query path?}
    B -->|Ingest| C[Streams/rate limit tenant A]
    B -->|Query| D[Concurrency limit + timeout tenant A]
    C --> E[Liên hệ owner + cardinality fix]
    D --> E
    E --> F{Tách cluster/dedicated?}
    F -->|Enterprise large| G[Shard tenants / cell architecture]
    F -->|Chưa| H[Giữ shared + hard limits]

20.4 Migration structured logging¶

1. Chốt schema (field names, levels, trace_id)
2. Collector normalize (cả legacy)
3. Canary 1 service → dashboards/alerts
4. Dual support N weeks
5. Enforce drop non-compliant (hoặc quarantine tenant)
6. Remove legacy parsers

21. Bài học từ Big Tech / public incidents¶

21.1 Logging cost as SEV¶

Nhiều org công bố logging là một trong những bill cloud lớn. Chuyển ELK → Loki/tương đương thường vì economics, nhưng fail nếu không đổi văn hóa label/query.

Bài học: cost dashboards per tenant/service; sampling debug logs; retention tiering.

21.2 Multi-tenant fairness¶

SaaS observability vendors build hard isolation vì một customer có thể query-of-death. Self-host Loki multi-team = mini-SaaS — cần limits giống vendor.

21.3 Schema without governance¶

Postmortems nội bộ hay thấy: sau 1 năm, 5 tên field cho "message" → MTTR tăng. Platform thắng nhờ central transform hơn là tin developer discipline thuần.

21.4 Index everything hangover¶

Team từ ELK mang thói quen index mọi field → stream explosion. Bài học change management: training + linter + reject.

21.5 Map Ch13 / Ch15¶

Bài học	Loki chapter	Sang
Economics of logs	Cost section	Ch15, Ch01
Tenant isolation	Multi-tenancy	Ch12 production
Schema for AIOps	Structured logs	Ch08/09/10
Query as capacity	LogQL + scaling	Ch13 platform patterns

22. Câu hỏi Socratic cho on-call¶

22.1 Mất log / thiếu log¶

Tenant ID bạn query có đúng với ingest không?
Mất ở tail (mới) hay history (cũ) — path nào?
Agent có ship không? Distributor từ chối vì limit?
Label set có đổi sau deploy (stream mới) không?
Out-of-order discard có tăng không?

22.2 Query & LogQL¶

Selector có hẹp nhất có thể không?
Bạn parse trước khi filter line rẻ — có cần không?
Time range có lớn hơn nhu cầu IR không?
Query này có thể giết hàng xóm không?
Có slow query log / example tối ưu không?

22.3 Cardinality & tenants¶

Stream count tenant có trong budget không?
Label nào tăng sau release?
Limits đang punish innocent tenants chứ?
Ruler rules có selector an toàn không?
Compliance retention có bị global policy đè không?

22.4 Sau sự cố / migration¶

Schema field có contract test không?
Collector đã normalize alias chưa?
Cần thêm cache hay bớt query thói quen?
Experiment 30 ngày giảm volume DEBUG?
Log đã đủ structured cho correlation TraceID (Ch01) chưa?

23. Improvement experiments (30/60/90 ngày)¶

30 ngày — Discipline foundation¶

Experiment	Cách làm	Success metric
Label policy	Allowlist + examples	0 high-card labels mới
Stream inventory	Top tenants by streams	Owners identified
Query education	Workshop + cheat sheet	Slow queries ↓ 30%
Tenant limits	Rate + concurrency	Noisy incident giảm
TraceID field audit	% logs có trace_id	Baseline số

Deliverables: label policy; tenant limit values documented.

60 ngày — Schema & performance¶

Experiment	Cách làm	Success metric
Collector normalize	`message`/`level` aliases	Parse error rate ↓
Cache layer	Memcached chunk/index	Query p95 ↓
Multiline fix	Java services	Stacktraces searchable
Ruler hygiene	Narrow selectors	Ruler CPU ↓
Volume sampling	DEBUG sample 1–5%	GB/day ↓ without IR pain

90 ngày — Platform & AIOps¶

Experiment	Cách làm	Success metric
Structured mandate tier-1	Enforce	100% tier-1 JSON
Cost chargeback	Per namespace/tenant	Teams self-optimize
Query governance	Audit top queries	Kill/optimize top 10
Dedicated path audit logs	Separate retention	Compliance OK
Export patterns to Ch08/10	Stable fields	Downstream consumers OK

North-star:
  - Streams per tenant within budget
  - p95 query latency for standard IR queries
  - % logs with trace_id + level + service
  - $/GB ingested and retained
  - Noisy-neighbor incidents per quarter

Vì sao

Loki trả giá rẻ chỉ khi org trả bằng kỷ luật. 30/60/90 xây kỷ luật đó thành thói quen đo được — không phải slide architecture.

24. Production Review¶

Principal Engineer Assessment¶

Các vấn đề phát hiện được:

Ingesters chạy dưới dạng StatefulSet với WAL lưu cục bộ: Nếu một pod ingester bị tắt đột ngột và PVC đi kèm bị mất (do lỗi phần cứng node), dữ liệu nằm trong WAL sẽ bị mất. Biện pháp giảm thiểu: Thiết lập tham số cấu hình replication_factor=3 kết hợp cơ chế phân bố replica tránh chạy trên cùng Availability Zone (inter-zone spreading) để đảm bảo dữ liệu luôn có 3 bản sao nằm trên các AZs khác nhau.
Cấu hình kích cỡ bộ đệm chunk cache: Nếu không sử dụng bộ đệm chunk caching (Memcached), các truy vấn lặp lại trên cùng một khoảng thời gian sẽ buộc phải tải dữ liệu từ S3 về nhiều lần. Ở quy mô truy vấn lớn trong production, chi phí gọi lệnh S3 GET có thể tăng vọt và chiếm tỷ lệ lớn. Hãy cấu hình Memcached để lưu lại các chunks được truy cập thường xuyên trong vòng 24 giờ qua.
Tính chất Singleton của Compactor: Tiến trình compactor bắt buộc chỉ được chạy duy nhất một instance. Khi sử dụng Helm charts với cấu hình số lượng replica của backend replicas > 1, cần đảm bảo compactor chỉ được bật chạy trên một instance duy nhất. Việc sử dụng cờ cấu hình target=backend sẽ tự động xử lý vấn đề này ở mức nội bộ.
Thiếu quy định bắt buộc về cấu trúc log (log schema): Loki cho phép nhận bất kỳ định dạng dòng log thô nào. Nếu không áp đặt định dạng cấu trúc thống nhất, các dịch vụ khác nhau sẽ sử dụng các trường dữ liệu tùy tiện khác nhau (ví dụ: chỗ dùng msg, chỗ dùng message; chỗ dùng ts, chỗ dùng timestamp). Điều này làm hỏng các câu lệnh truy vấn phân tích LogQL. Biện pháp khắc phục: Bắt buộc áp đặt định dạng cấu trúc log (log schema) ngay tại processor biến đổi của OTel Collector trước khi chuyển log tới Loki.

Chapter Scores¶

Tiêu chí	Điểm số	Ghi chú
Technical Accuracy	9.7/10	Cấu trúc dữ liệu Push API, cú pháp LogQL, cấu hình lưu trữ đã được xác thực
Production Readiness	9.6/10	Có tính năng đa người thuê, chính sách retention, cấu hình HA
Depth	9.7/10	Mô tả luồng nạp + luồng truy vấn, các toán tử LogQL đầy đủ
Practical Value	9.7/10	Có cấu hình Helm values, cấu hình River, ví dụ đầy đủ
Architecture Quality	9.6/10	Kiến trúc phân tán đầy đủ kèm biểu đồ mô tả
Observability	9.6/10	Có các câu lệnh PromQL và cảnh báo quan trọng cho Loki
Security	9.7/10	Có cấu hình mTLS, phân quyền IRSA, kiểm soát truy cập đa thuê
Scalability	9.6/10	Phân tích điểm nghẽn cho từng thành phần và cấu hình HPA
Cost Awareness	9.8/10	Có con số cụ thể kết hợp so sánh chi phí với ELK
Diagram Quality	9.6/10	Có đầy đủ biểu đồ tuần tự cho cả luồng ghi và luồng đọc

References¶

Acceptance contract của chapter¶

Chapter này tuân theo Acceptance Template chung: capability chỉ được coi là hoàn tất khi có scope, input quality, timeline scenario, expected output, negative control, hard gates, thresholds và evidence artifact tái tạo được. Checklist hoặc demo không thay thế benchmark/replay.

Chapter 04 — Log evidence và failure signatures với Loki¶

Prerequisites¶

Related Documents¶

Next Reading¶

Cách đọc chương này¶

Phần I — Từ dòng chữ đến evidence có thể xếp hạng¶

Mười hai dòng, bốn template, hai incident¶

Structured log không có nghĩa là mọi field đều đáng tin¶

Template mining: bỏ biến động, không bỏ nguyên nhân¶

Count không đủ: rarity, onset và scope mới tạo evidence¶

Event time, arrival time và clock uncertainty¶

Duplicate, retry và fan-out¶

Multiline và parser failure có thể tạo root cause giả¶

Label là index route, field là evidence¶

Log anomaly có bốn họ, không phải chỉ “volume tăng”¶

Logs và LLM: dữ liệu không đáng tin, không phải chỉ dẫn¶

Loki, OpenSearch và analytics path¶

Failure modes của log platform¶

Replay chứng minh Chapter 04¶

Output contract sang correlation và RCA¶

Phần II — Loki và log storage reference¶

1. Why Loki?¶

The Core Design Decision¶

2. Loki vs ELK Stack¶

2.1 Dual-path: Loki + OpenSearch/Elasticsearch cho AIOps¶

3. Internal Architecture¶

Distributed Mode Components¶

Component Responsibilities¶

4. Data Flow — Ingestion Path¶

Push API Format¶

5. Data Flow — Query Path¶

Key API Endpoints¶

6. LogQL Deep Dive¶

Stream Selectors¶

Log Pipeline — Filter Expressions¶

Log Pipeline — Parser Expressions¶

Metric Queries (Log-derived Metrics)¶

Practical Production Queries¶

7. Label Design¶

Principles¶

Good Label Schema¶

Bad Label Schema (Các thói quen xấu - Anti-Patterns)¶

Dynamic Labels với Grafana Alloy¶

8. Ingestion Methods¶

Grafana Alloy vs Promtail¶

9. Storage Backend¶

Index Storage¶

Chunk Storage¶

S3 Configuration¶

Chunk Compression¶

10. Deployment Modes¶

Single Binary (Cho môi trường phát triển/thử nghiệm)¶

Simple Scalable (Production quy mô nhỏ)¶

Microservices (Production quy mô lớn)¶

11. Kubernetes Deployment¶

Helm Installation¶

Production Helm Values¶

12. Production Configuration¶

Multi-Tenancy¶

Alerting and Recording Rules trong Loki¶

13. Common Mistakes¶

14. Monitoring Loki¶

Critical Alerts¶

15. Scaling¶

Write Path Scaling¶

Read Path Scaling¶

Querier Autoscaling¶

16. Security¶

mTLS Between Components¶

Multi-Tenant Access Control¶

IRSA for S3 Access¶

17. Cost¶

Storage Cost Calculation¶

Compute Cost (EKS)¶

ELK Stack Comparison¶

18. Tư duy problem-solving trong production¶

18.1 Vì sao chỉ index labels — đây là trade-off có chủ đích¶

18.2 LogQL cognitive load — ngôn ngữ mạnh, dễ viết query tự hại¶

18.3 Noisy neighbor tenants — đa thuê là dao hai lưỡi¶

18.4 Structured logging migration pain¶

EC-01 — Label `request_id` trên stream¶

EC-07 — Cardinality từ `pod` + `path` + `status` ...¶