Unahifadhi vipi log events milioni 100 kwa siku?

Question

IT Interview Practice · Accepted Answer

Jenga **append-only pipeline: agents → Kafka → tiered storage (hot katika ClickHouse/ELK, cold katika object storage)** yenye retention policy inayoweka index data ya hivi karibuni na kuhifadhi kwa bei nafuu iliyobaki. Events milioni 100/siku ni wastani wa ~1,200/sekunde (spikes za juu zaidi) na GB kadhaa hadi mia kwa siku — unaoptimize kwa writes nafuu na gharama ya query yenye mipaka, si semantic za OLTP.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Append pipeline

Logs huandikwa mara moja, hazibadilishwi kamwe — hivyo njia ya ingest ni **append**. Agents kama **Fluent Bit / Vector** husafirisha lines kwenda **Kafka**, ambayo hubuffer bursts na kutenganisha producers na storage. Ikiwa ClickHouse imezimwa kwa matengenezo, events hujaa kwenye Kafka na kufanya replay — hupotezi logs. Batch writes (maelfu ya rows kwa insert) kwa sababu per-row inserts huharibu throughput kwenye columnar stores.

## Hot store: index kwa search

Logs za hivi karibuni zinahitaji search ya haraka ("errors saa iliyopita kwa service X"). **ClickHouse** (columnar, hucompress mara 10, huscan rows bilioni/sekunde) au **ELK stack** (Elasticsearch inverted index) hutumikia hili. Partition kwa siku/service ili queries zipunguzie hadi partitions chache. Tier hii ni ghali kwa GB, hivyo iweke ndogo — siku 7–30 za mwisho tu.

## Cold store: object storage + tiering

Logs za zamani huhamia **S3 kama Parquet** — nafuu, durable, zinazoweza kuqueryiwa on demand kupitia Athena/Trino. **Lifecycle policy** huhamisha S3 → Glacier → deletion kwenye kikomo chako cha retention (mfano mwaka 1). *Tiering* hii ndiyo lever kuu ya gharama: hot storage inaweza kuwa mara 50 ya bei ya archival.

## Mtazamo wa mahojiano

Wahojiwa huchunguza **index-vs-cost trade-off**: kuweka index kila kitu hutoa search nzuri lakini hupasua bajeti; kutoweka index chochote ni nafuu lakini hakiwezi kuqueryiwa. Nzuri: "tumia ELK." Bora sana: unafanya tier — weka index slice ya hot ya hivi karibuni, hifadhi iliyobaki cold — na kutaja Kafka kama buffer inayofanya ingestion iwe imara dhidi ya kukatika kwa downstream.

**Mtego wa kawaida:** kuweka logs zote katika Elasticsearch milele. Ni chaguo ghali zaidi na cluster yake huanguka kwenye cardinality/retention usiyoipanga.

## Maelewano na aina za hitilafu

- **Retention vs gharama:** retention ndefu = ukuaji wa storage wa linear; tier kwa ukali.
- **Kafka backpressure:** ikiwa consumers watachelewa, disk hujaa — pima retention na ufuatilie lag.
- **Cardinality explosion:** fields za high-cardinality (user_id) huvimbisha ES indexes; sample au zidondoshe.
- **Gharama ya query kwenye cold data:** Athena huscan kwa gharama kwa TB — partition Parquet kwa date/service ili scans zibaki na mipaka.
- **At-least-once dupes:** dedup kwa event id ikiwa hesabu kamili ni muhimu.

Append pipeline

Hot store: index kwa search

Cold store: object storage + tiering

Mtazamo wa mahojiano

Maelewano na aina za hitilafu

Maswali yanayohusiana