LK 是三款开源组件的组合：Elasticsearch + Logstash + Kibana，现在官方改称 Elastic Stack。 主要用于日志收集、存储、检索、可视化，也可做简单指标检索，信贷、后端研发、运维排查日志非常常用。

各组件职责

1. Elasticsearch（ES）

分布式搜索引擎，底层基于 Lucene。

• 
  核心：存储数据，提供全文检索、条件查询、聚合统计能力
  


• 
  数据以文档(JSON)存储，擅长模糊检索、按关键词快速查日志
  


• 
  不是关系数据库，不适合承担核心业务交易库；适合日志、链路、审计日志。
  

2. Logstash

数据管道，负责数据采集、过滤转换。

• 
  输入源：文件日志、TCP、Kafka、数据库等
  


• 
  transform：过滤、字段提取、脱敏、时间格式化、丢弃脏数据
  


• 
  输出：写入 Elasticsearch，也可以输出到文件、Kafka
  

缺点：Logstash JVM开销大；生产环境经常用 Filebeat 替代它做采集。

3. Kibana

可视化 Web UI。

• 
  查询ES的数据，做检索、画图、仪表盘、告警
  


• 
  开发运维用来查系统错误日志、接口报错、监控大盘。
  

Filebeat（生产必提，属于Elastic Stack）

轻量级采集代理，部署在业务机器上，替代Logstash做日志采集

• 
  轻量，占用资源很小，逐行读取应用日志文件
  


• 
  发给 Kafka / Logstash / Elasticsearch
  

生产标准链路： 业务服务输出日志文件 → Filebeat采集 → Kafka消息队列 → Logstash做清洗转换 → Elasticsearch存储 → Kibana查看

为什么加Kafka：削峰。日志流量突增时保护ES，避免ES被打崩。

典型使用场景

1. 
   应用日志排查：信贷服务、API报错、异常堆栈，按traceId检索整条调用链路日志
   


2. 
   系统审计日志、ASR日志、请求payload日志存储检索
   


3. 
   简单指标聚合，做监控仪表盘
   


4. 
   安全：收集访问日志，识别异常访问
   

❗不适合：海量离线数仓（这个是Hive的领域）；不适合高吞吐在线事务业务。

ELK vs Hive 简单对比

项目	ELK(Elasticsearch)	Hive
定位	实时检索、日志查询	离线数仓，海量ETL统计
数据延迟	秒级	分钟‑小时级T+1
擅长	关键词检索、traceId链路查询	大表Join、复杂聚合、风控样本加工
存储	ES索引	HDFS/对象存储
典型用途	查报错、排查线上问题	日终报表、特征加工

生产常见坑

1. 
   ES 内存、磁盘压力大；日志量巨大容易集群爆；需要做索引生命周期管理，旧日志自动删除/归档。
   


2. 
   不要把ES当做MySQL使用，不适合高频更新事务数据。
   


3. 
   直接用Logstash采集日志性能差，线上务必搭配Filebeat。
   


4. 
   索引分片副本规划不合理，查询慢或者资源浪费。
   

信贷研发场景举例

信贷服务打印大量日志：放款请求、账务日志、报错堆栈。Filebeat收集日志进ES；开发在Kibana输入traceId，快速定位某一笔放款请求完整链路日志，排查线上故障。

一句话速记

ELK = Elasticsearch(存储检索) + Logstash(清洗管道) + Kibana(可视化)；现在生产一般搭配Filebeat做轻量采集；主要用于日志收集检索排查问题，不是离线数仓，不能替代Hive。