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）、图表、告警

1. 全局前置准备

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

2. 分节点部署清单

节点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后生效

3. 验证方式

  • 索引校验：执行curl http://es01:9200/_cat/indices?v，能看到nginx-access-*前缀索引说明写入正常

  • 调试技巧：Logstash可临时配置output { stdout { codec => rubydebug } }，直接在控制台查看解析后的日志格式。

三、覆盖的高频面试考点

🔹 ELK基础类

  1. 采集器选型逻辑

    • 物理机/虚拟机日志：优先Filebeat（轻量无JVM依赖）

    • K8s/容器日志：优先Fluentd/Fluent Bit（云原生适配性更好）

    • 无复杂解析需求的简单场景，Filebeat可直接写ES，无需经过Logstash。

  2. ES常用操作命令

    • 查看所有索引：GET /_cat/indices?v

    • 查看索引结构：GET /索引名/_mapping

    • 查询索引数据：GET /索引名/_search

  3. ES高性能核心：倒排索引

    流程：文档内容分词 → 构建「词项→所属文档ID」的映射表 → 搜索时直接通过词项定位文档，跳过全表扫描。

  4. K8s日志实战标准答法

    • 采集：用DaemonSet模式每节点部署一个采集器，读取节点/var/log目录或Pod的EmptyDir

    • 管理：索引按「业务-环境-日期」拆分，通过ILM（索引生命周期管理）策略自动清理过期数据（如保留7天）

    • 关注重点：Error级别日志、5xx状态码、操作审计日志。

🔹 Kafka（消息队列）类

问题

标准答案

为什么引入MQ？

解耦（上下游无需互相改造）、异步（降低接口响应耗时）、削峰（防止流量峰值打垮系统）

如何保证消息不丢失？

生产端开启Confirm确认机制 + MQ消息持久化存储 + 消费端手动提交ACK

如何保证消息顺序？

单队列单消费者，或对相同Key（如用户ID）的消息路由到同一队列

消息重复如何处理？

消费端做幂等设计：Redis记录已处理消息ID、数据库唯一索引、业务状态机校验

消息积压如何解决？

临时扩容消费者实例 + 批量拉取消息 + 降级非核心业务逻辑

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

# elk
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

概述（6）--操作系统引导（开机过程）

每次按下电源键，电脑都会偷偷完成一连串精密的 “接力任务”，才能让你顺利刷网页、打游戏。今天咱们就用，把开机的每一步讲明白，看完你就再也不会觉得开机是 “神秘黑盒” 啦～

avatar openEuler 社区
cover

Django 从 0 到 1 打造完整电商平台:Nginx + uWSGI 部署 Django 项目

avatar openEuler 社区

Chrony时间服务器

chrony是一个开源的自由软件，它能帮助你保持系统时钟与时钟服务器（NTP）同步，因此让你的时间保持精确。它也可以让你成为一个时间服务器，给别的客户端主机提供时间。chronyd：是一个后台运行的守护进程，用于调整内核中运行的系统时钟和时钟服务器同步。它确定计算机增减时间的比率，并对此进行补偿。同时该服务还监听udp的123端口，其他客户端可以通过该端口来同步时间。chronyc：提供了一个用户

avatar openEuler 社区