第1章：技术选型与架构设计 — 从ELK到自研的进化之路
大家好，我是老张。今天咱们聊聊告警管理系统升级改造中最关键的一步——技术选型与架构设计。
说实话，我见过太多团队一上来就拍脑袋选ELK，结果数据量一上来，集群直接崩了。也见过有人迷信Prometheus，觉得它能解决一切问题。嗯，这里我要泼点冷水——没有银弹。
1.1 三大方案对比：ELK vs Prometheus vs 自研
先说说我个人的选型经验。我经历过三个阶段的演变：最早用ELK，后来尝试Prometheus，最后走上了自研之路。为什么？
| 维度 | ELK | Prometheus | 自研方案 |
|---|---|---|---|
| 数据模型 | 全文检索+日志 | 时序指标 | 自定义结构化数据 |
| 存储成本 | 高（索引膨胀） | 中（本地存储） | 低（冷热分离） |
| 告警能力 | 弱（需额外插件） | 强（内置Alertmanager） | 灵活（可定制） |
| 扩展性 | 中（ES集群复杂） | 中（联邦集群） | 高（微服务化） |
| 运维成本 | 高 | 中 | 低（容器化） |
我的建议：如果团队规模小、日志量在TB级以下，ELK够用。如果主要是监控指标，Prometheus是首选。但如果你像我一样，既要处理海量日志，又要做复杂告警规则，还得支持多租户——自研是唯一出路。
1.2 分层解耦架构设计
我记得第一次设计告警系统时，把所有逻辑都塞在一个服务里。结果呢？改一个告警规则，整个系统要重启。太痛苦了。
后来我总结了一套分层解耦的架构，说白了就是「各司其职，互不干扰」。
你看这个图，从上到下四层，每层只做自己的事。数据采集层只管收数据，不管怎么处理。消息队列层只管缓冲，不管数据长什么样。这样改一层，其他层完全不受影响。
1.3 引入Kafka削峰填谷
为什么要引入Kafka？我举个例子你就明白了。
有一次双十一大促，告警量瞬间暴涨到平时的100倍。如果没有Kafka，告警系统直接被打挂，运维同学连告警都收不到。有了Kafka，数据先写到队列里，消费者慢慢处理。这就是削峰填谷。
避坑指南：我曾经把Kafka的topic分区数设得太少，导致消费者组负载不均。建议分区数至少是消费者数量的2倍，这样能保证负载均衡。
具体怎么配？看这段配置示例：
# Kafka生产者配置
bootstrap.servers=192.168.1.10:9092,192.168.1.11:9092
acks=all
retries=3
batch.size=16384
linger.ms=5
buffer.memory=33554432
# 消费者配置
group.id=alert-consumer-group
enable.auto.commit=false
max.poll.records=500
session.timeout.ms=30000这里要注意，acks=all 保证数据不丢，但会牺牲一点性能。对于告警系统来说，数据完整性比性能更重要。你想想看，丢了一条告警，可能就错过了一次故障处理时机。
1.4 自研方案的核心优势
为什么我最终选择了自研？说白了，就是「灵活」二字。
- 规则引擎可定制：ELK的告警规则写起来像在写SQL，Prometheus的PromQL学习曲线陡峭。自研的话，我可以设计一套DSL，让运维同学也能轻松写规则。
- 多租户支持：ELK和Prometheus对多租户的支持都比较弱。自研的话，租户隔离、权限控制、资源配额都能做到位。
- 成本控制：ELK的存储成本太高了，尤其是索引膨胀。自研可以用冷热分离，热数据存SSD，冷数据存对象存储，成本能降70%。
注意：自研不是万能的。如果团队没有足够的研发资源，建议还是先用开源方案。我见过太多团队自研到一半就放弃了，最后得不偿失。
1.5 架构设计的几个关键点
最后，我总结几个架构设计时必须注意的点：
- 数据不丢：Kafka的acks=all，消费者手动提交offset，确保每条告警都被处理。
- 处理不慢：规则引擎用异步非阻塞模型，避免IO阻塞。我习惯用Netty或者Vert.x。
- 扩展不难：所有组件都支持水平扩展。Kafka加分区，消费者加实例，存储加节点。
- 监控不盲：告警系统本身也要被监控。我通常会埋点，监控Kafka积压量、处理延迟、规则命中率。
嗯，这一章就到这里。记住，技术选型没有标准答案，只有最适合你场景的方案。下一章咱们聊聊具体的规则引擎设计，到时候我会分享一些踩过的坑。
公众号:蓝海资料掘金营，微信deep3321