ELK（1） - 技术栈

ELK核心架构（从数据产生到可视化的全链路）

这是最基础的经典链路：App/Filebeat → Logstash → Elasticsearch → Kibana

环节	核心作用	关键特性
应用（App）	日志源头，输出访问/错误/业务日志，常见形式是本地文件、容器stdout	无
Filebeat	轻量采集器，部署在应用服务器上，负责「可靠把日志拿过来」	Go语言开发、资源占用极低；支持断点续传（记录inode+offset）；可以直接发ES/Logstash/Kafka
Logstash	数据处理ETL，负责「让日志变得可查可用」	三大模块：Input（接数据）→ Filter（grok解析、字段提取、GeoIP补全、丢弃无效日志）→ Output（写ES/Kafka/文件）
Elasticsearch	存储+检索引擎，负责「存日志、快查、做统计」	分布式、近实时（1s左右可查）、倒排索引、天然适合时序日志数据，支持水平扩展
Kibana	可视化平台，负责「让人能方便看日志、分析问题」	功能覆盖日志检索（Discover）、仪表盘（Dashboard）、图表、告警

所有机器执行：关闭防火墙systemctl stop firewalld、临时/永久关闭SELinux、配置主机名（es01/es02/kibana）、安装JDK 1.8（java-1.8.0-openjdk-devel）。

节点IP	部署组件	核心配置&注意事项
192.168.222.131（es01）	Elasticsearch + Logstash + Nginx + elasticsearch-head	✅ ES配置：集群名`my-es-cluster`、监听0.0.0.0、集群发现节点配`["es01","es02"]` ✅ elasticsearch-head依赖Node.js、PhantomJS，用于可视化ES集群状态 ✅ Logstash示例：采集Nginx访问日志，输出索引按`nginx-access-%{+YYYY.MM.dd}`拆分 ❗ 旧版本Logstash的路径警告为默认值提示，不影响正常运行
192.168.222.132（es02）	Elasticsearch	配置与es01保持一致，加入同一集群即可
192.168.222.133（kibana）	Kibana	✅ 配置：监听端口5601、绑定0.0.0.0、ES地址指向两台ES节点 ❗ 出现`Kibana server is not ready yet`通常为ES未完全启动、或ES地址配置错误
（补充Filebeat实操）	Filebeat	❗ Logstash未监听5044端口时，需检查是否配置Beats输入：`input { beats { port => 5044 } }`，重启Logstash后生效

采集器选型逻辑
- 物理机/虚拟机日志：优先Filebeat（轻量无JVM依赖）
- K8s/容器日志：优先Fluentd/Fluent Bit（云原生适配性更好）
- 无复杂解析需求的简单场景，Filebeat可直接写ES，无需经过Logstash。
ES常用操作命令
- 查看所有索引：GET /_cat/indices?v
- 查看索引结构：GET /索引名/_mapping
- 查询索引数据：GET /索引名/_search
ES高性能核心：倒排索引

流程：文档内容分词 → 构建「词项→所属文档ID」的映射表 → 搜索时直接通过词项定位文档，跳过全表扫描。
K8s日志实战标准答法
- 采集：用DaemonSet模式每节点部署一个采集器，读取节点/var/log目录或Pod的EmptyDir
- 管理：索引按「业务-环境-日期」拆分，通过ILM（索引生命周期管理）策略自动清理过期数据（如保留7天）
- 关注重点：Error级别日志、5xx状态码、操作审计日志。

问题	标准答案
为什么引入MQ？	解耦（上下游无需互相改造）、异步（降低接口响应耗时）、削峰（防止流量峰值打垮系统）
如何保证消息不丢失？	生产端开启Confirm确认机制 + MQ消息持久化存储 + 消费端手动提交ACK
如何保证消息顺序？	单队列单消费者，或对相同Key（如用户ID）的消息路由到同一队列
消息重复如何处理？	消费端做幂等设计：Redis记录已处理消息ID、数据库唯一索引、业务状态机校验
消息积压如何解决？	临时扩容消费者实例 + 批量拉取消息 + 降级非核心业务逻辑

如需对某部分（如Logstash Grok语法、ES索引生命周期配置、K8s日志采集细节）进一步展开，可随时说明需求。