Design A Log Collection And Analysis System - System Design

System requirements

Functional:

system health, performance issues, and security threats.

real-time processing and alerting

scalable storage for log data

analysis tools

monitoring

multi-tenancy

user data retention and archiving policy

alert and monitoring

Non-Functional:

scalability

高可用性：支持故障恢复，99.99% SLA

可扩展性：支持百万级 QPS 读写

低延迟：写入 10ms ~ 100 ms(for message queue)，查询 50~ 500ms

数据一致性：支持最终一致性，部分查询支持强一致性

安全：日志加密存储，访问控制，审计日志

Capacity estimation

10K services, each 1MB logs per minutes = 17KB per sec, each log is 1KB

qps:

write:

17 * 10K = 170K qps

peak hour * 3 = 510K

read:

5 per service = 50K QPS

peak hour * 3 = 150K

Network:

average:

170M per sec

peak:

170 * 3 = 510M per sec

data storage:

170M * 3600 * 24 = 15Million * M = 15T per day

storage 3 years with replica 3 = 49PB

API design

日志写入

POST /logs
{
  "service_id": "abc123",
  "timestamp": 1700000000,
  "log_level": "ERROR",
  "message": "Database connection failed"
}

日志查询

GET /logs?service_id=abc123&start=1700000000&end=1700001000&level=ERROR

告警

POST /alerts
{
  "rule": "error_rate > 5%",
  "action": "notify",
  "threshold": 5
}

Database design

日志存储

使用 Elasticsearch 或 ClickHouse 存储，支持全文搜索和分析。

sql
CopyEdit
CREATE TABLE logs (
  service_id STRING,
  timestamp TIMESTAMP,
  log_level STRING,
  message TEXT
) ENGINE = MergeTree ORDER BY (service_id, timestamp);

索引

service_id, timestamp 组合索引，提高查询效率
使用 时间分区表 (partition by day) 便于管理

数据分片

Sharding by Service ID，避免单点瓶颈
Partitioning by Date，快速删除过期数据

High-level design

Log Ingestion (日志收集)
- 使用 Fluent Bit、Vector、Logstash 等轻量级 Agent 进行日志采集。
- 通过 Kafka 作为日志缓冲队列，支持高吞吐写入（170K QPS，峰值 510K QPS）。
- 支持 gRPC / HTTP API 直接上报日志。
Storage (日志存储)
- 采用 Elasticsearch / OpenSearch 进行索引存储，支持高效查询。
- 采用 S3 + Parquet 进行长期存储，降低存储成本。
- 冷热分层存储，1 个月内的热数据存入 Elasticsearch，老数据归档到 S3。
Indexing (索引)
- Elasticsearch/OpenSearch 进行索引，使用 sharding + replication 提高查询性能。
- 结合 Apache Druid 进行 OLAP 分析，提供高效查询能力。
Processing & Analysis (分析和告警)
- Flink/Spark Streaming 进行 实时日志分析，检测异常模式、性能问题和安全威胁。
- 结合 Prometheus / Grafana 进行可视化监控。
- 触发 Webhook / Slack / PagerDuty 进行告警通知。
Query (查询)
- Elasticsearch API 提供全文搜索和结构化查询。
- Presto / Trino + S3 提供长期存储查询能力。
- 用户多租户隔离，通过 Elasticsearch Role-Based Access Control（RBAC） 限制权限。
Multi-Tenancy & Retention (多租户和数据保留)
- 每个租户拥有独立的索引 （Index per tenant 或 Field-based access control）。
- 数据保留策略：
  - 近 1 个月热存储（Elasticsearch）
  - 1 年内 Warm（S3+Parquet）
  - 3 年 Cold（Glacier）
  - 自动删除超期数据

数据加密：TLS 传输加密，AES-256 存储加密

访问控制：RBAC + OAuth

审计日志：所有查询/变更记录

DDoS 防护：WAF + 速率限制

系统健康监控：Prometheus + Grafana
异常检测：AI/ML 预测异常
日志查询性能：ES Query Latency 监测

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices


Kafka vs Pulsar	Kafka 成熟、生态好	Pulsar 原生多租户、支持存储分层
Elasticsearch vs ClickHouse	ES 强搜索能力	ClickHouse 查询吞吐高
SQL vs NoSQL	SQL 易用、分析强	NoSQL 低延迟、可扩展
S3 vs HDFS	S3 低成本	HDFS 低延迟

Failure scenarios/bottlenecks

日志丢失：

Kafka 3 副本确保持久化
Elasticsearch / ClickHouse 备份

查询延迟高：

使用 索引 + 分片
热数据放 Redis / Memcached

存储压力：

S3 归档旧数据
采用 冷热数据分层存储

系统崩溃：

多 AZ 部署
Leader-Follower 机制

Future improvements

引入 AI/ML 进行智能日志分析

支持更多数据格式（JSON, Protobuf）

分布式查询优化 采用 Presto/Flink