4）ELK
使用 ELK（Elasticsearch+Logstash+Kibana）或 Prometheus+Grafana 集中存储和可视化。
非常好，这两个组合方案是当前最常见的监控与日志可视化体系，分别偏重于 日志收集分析（ELK）和 系统指标监控告警（Prometheus+Grafana）。我们来用类比 + 五问五答的方式，把它讲清楚。
✅ 类比思维：
想象你是管理一座“工厂”（系统）的大管家：
- 🔍 你要知道机器出了什么问题（日志）→ ELK 来帮你“看录像回放”
- 📈 你要知道机器运行状态是否健康（CPU、内存、请求数）→ Prometheus+Grafana 是你的“体检监控仪”
📦 一、ELK Stack（Elasticsearch + Logstash + Kibana）
📌 1）是什么？
ELK 是一整套日志集中处理平台：
| 组件 | 作用 | 类比 |
|---|---|---|
| Elasticsearch | 用于存储和检索日志 | 数据仓库 |
| Logstash | 日志收集与清洗 | 清洗工人 |
| Kibana | 日志可视化与查询分析 | 可视化仪表盘 |
可接收来自 Nginx、应用服务、系统日志、Docker 等来源的日志。
⚙️ 2）原理简述：
- 日志通过 Logstash/Filebeat 被采集；
- 清洗、格式化后发送到 Elasticsearch；
- Kibana 用来查询、展示日志内容。
🎯 3）适用场景：
- 查看应用报错日志、慢日志、异常信息
- 调试服务运行状态
- 安全审计与访问记录
- 多服务集中查询日志，快速定位问题
✅ 4）优势：
- 日志集中存储查询，避免 SSH 登入每台机器
- 支持全文检索 + 多维聚合查询
- 灵活可视化，支持图表、地图等展示
- 可与告警系统联动（如 ElastAlert）
🛠️ 5）实践建议：
- 使用 Filebeat 替代 Logstash 作为轻量采集器
- 结构化日志输出（如 JSON）更利于索引查询
- 给日志设置索引生命周期（防爆磁盘）
- Kibana 设置仪表盘 + 定期审查指标异常
📈 二、Prometheus + Grafana
📌 1）是什么？
Prometheus 是一套开源的指标监控系统，Grafana 是可视化仪表盘。
| 组件 | 作用 |
|---|---|
| Prometheus | 收集、存储、处理系统/服务指标 |
| Grafana | 图形化展示、配置告警规则 |
⚙️ 2）原理简述：
- 应用通过 Prometheus exporter（或 SDK）暴露指标接口；
- Prometheus 定时拉取（pull）这些指标；
- 存储在时序数据库中；
- Grafana 读取数据绘图、设置告警规则。
🎯 3）适用场景：
- 查看系统资源使用情况（CPU、内存、磁盘）
- 分析接口响应时间、QPS、错误率
- 服务 SLA 评估、异常波动告警
- Kubernetes 容器监控、数据库监控等
✅ 4）优势：
- 数据采集轻量（HTTP 拉取）
- 高性能时序数据库，适合高频采集
- 可设置告警规则（集成 Alertmanager）
- Grafana 可展示多个来源（Prometheus、MySQL、Elastic）
🛠️ 5）实践建议：
- 每个服务暴露
/metrics接口（支持 Go、Java、Node 等语言） - 使用 Exporter 收集常用组件指标（如 MySQL、Redis、Node Exporter）
- 设置 P95/P99 延迟、QPS、异常率等关键指标
- 配合 Alertmanager 邮件/钉钉/飞书/微信推送告警
✅ 总结对比表：
| 特性 | ELK | Prometheus + Grafana |
|---|---|---|
| 关注点 | 日志（离线文本） | 指标（时间序列） |
| 数据结构 | 文本结构化/非结构化 | 数值型指标 |
| 数据采集 | Logstash/Filebeat（推） | Prometheus 拉 |
| 存储形式 | Elasticsearch 文档索引 | Prometheus 时序数据库 |
| 可视化 | Kibana | Grafana |
| 通用性 | 日志处理/搜索强 | 实时监控、告警强 |
🔧 实战部署建议：
- 小型团队： 可单机部署 ELK 与 Prometheus，轻量级上手
- 中大型系统：
- 日志系统：ELK + Filebeat（多节点日志统一收集）
- 监控系统：Prometheus + Grafana + Alertmanager
- 配合 Loki（Prometheus 的日志系统）替代 ELK 亦可
✅ 面试结构设计（中高级 ELK 应聘者）
一、核心五问（含深入追问）
🔹 问题 1：你在实际项目中 ELK 是如何部署的？
考察点：
- 是否理解分布式部署
- 是否考虑性能与高可用
- 是否了解部署工具（Docker / K8s / 手动部署）
深入追问：
- 你如何避免 Logstash 单点故障？
- Elasticsearch 是如何实现数据副本的？副本数如何设置？
- 是否做过 ILM（Index Lifecycle Management）？
🔹 问题 2：你如何做日志结构化和清洗？Logstash 如何配置？
考察点：
- 是否熟悉 Logstash 的 pipeline 概念
- 对 grok、mutate、date 等插件熟悉程度
- 是否理解日志格式变化对处理的影响
深入追问：
- grok 匹配失败你怎么排查？
- 多种日志格式如何统一处理？
- 是否用过 Logstash 的条件判断？
🔹 问题 3：Elasticsearch 的性能调优做过哪些？遇到过什么问题？
考察点：
- 数据写入优化能力
- 索引设计合理性
- 查询慢的分析与优化能力
深入追问：
- mapping 设置你会手动定义吗？为什么不能全靠动态 mapping？
- 你如何设计索引：是按天还是按服务？
- 怎么防止字段爆炸？（field explosion）
🔹 问题 4：你如何借助 Kibana 快速定位线上故障？
考察点：
- 实战中的分析路径
- 对字段筛选、聚合分析的理解
- 是否使用过 traceId / log level / userId 辅助分析
深入追问：
- 有 traceId 情况下，如何完整还原请求链路？
- 有没有做过告警配置（Watchers 或 ElastAlert）？
- 多服务日志合并后，如何按服务维度筛选？
🔹 问题 5：ELK 中遇到哪些典型“坑”？你是怎么解决的？
考察点：
- 是否具备日志平台稳定性思维
- 是否考虑过安全性、合规性、可维护性
- 是否有优化与总结能力
深入追问：
- 有无处理过“日志洪峰”？如何限流或隔离？
- 有没有做过日志脱敏处理？
- 如何解决日志重复、丢失、乱序等问题？
二、案例分析题（任选其一）
🔸 案例 1：线上出现 Nginx 大量 502 错误，如何用 ELK 快速排查？
考察重点：日志结构、时间序列分析、服务之间的逻辑关联
期望步骤：
- Kibana → Discover 查看 Nginx 502 日志，筛选出时间段、IP、URL
- 追溯后端服务日志（如 Java 应用）→ traceId 串联链路
- 分析错误字段（如 Timeout、Connection reset）
- 使用 Kibana 的聚合功能，统计异常 URL、主机、接口占比
🔸 案例 2：日志暴增，Elasticsearch 索引写入异常，查询非常慢，你如何分析？
考察重点：对 ES 写入、存储、查询机制的理解
可能解法：
- 检查是否因 mapping 自动扩展导致 field explosion
- 查询 ES 索引大小、主分片数是否不均
- 检查是否存在慢查询字段（使用 text 而不是 keyword）
- 是否启用了聚合排序导致 heap 爆掉
- 是否考虑了冷热数据分层存储
🔧 Bonus：你可以用这些追问“压一压”候选人：
| 问题 | 目的 |
|---|---|
| ES 是如何存储文档的？Lucene 是怎么用的？ | 理解底层存储结构 |
| Filebeat、Logstash、Kafka 怎么组合抗压？ | 架构能力验证 |
| ES 索引分片策略你会怎么设计？ | 实战部署经验 |