日志太多还在 grep？用 ELK + Kibana 搭一套可搜索、可视化、可远程访问的分析平台(1)

日志太多还在 grep？用 ELK + Kibana 搭一套可搜索、可视化、可远程访问的分析平台

前言

服务器日志真正麻烦的地方，不是文件太多，而是故障发生时很难快速把“哪台机器、哪个时间点、哪类错误”关联起来。只靠 grep 临时搜索，小规模还能应付；一旦日志来源变多、时间跨度拉长，就需要一套能持续接收、存储、查询和可视化的数据链路。ELK 的价值也正在这里：Elasticsearch 负责保存和检索数据，Logstash 负责接收与整理日志，Kibana 再把这些数据变成可搜索、可筛选、可画图的运维视图。真正有用的不是“图表多漂亮”，而是出问题以后能不能顺着日志把原因缩小到可以处理的范围。对运维来说，最怕的不是报错本身，而是数据链路中间有一层没接上，最后只能在多个服务之间来回猜。

这次按照 CentOS 7 环境把整条链拆开：先处理 Swap、用户和 Elastic 软件源，再配置 Logstash 的 Beats 输入与 Elasticsearch 输出，随后安装 Kibana 7.15.0、连接 localhost:9200，创建索引、写入测试文档、切换中文界面并制作垂直条形图。最后用 cpolar 把 Kibana 的 5601 页面提供到公网，先验证随机地址，再切换到固定二级子域名 kibanaa。过程中会特别标出 9200/9201、Kibana 配置路径、Elasticsearch 安装步骤缺口等容易混淆的位置，不把“页面能打开”直接等同于整套 ELK 已经完整跑通。

1. 先把 ELK 三个角色分开

Kibana 是 ELK 技术栈里的可视化与分析入口。

它本身不负责长期保存日志，真正的数据仍然存放在 Elasticsearch 中；Logstash 则负责接收、处理并把日志送往 Elasticsearch。

整条链更适合这样理解：

日志来源 → Logstash → Elasticsearch → Kibana

Kibana 常见用途包括：

• Discover 中按关键词、字段和时间范围查日志；
• 用图表观察错误量、请求趋势或业务分布；
• 把多个图表组成 Dashboard；
• 结合日志、指标和 APM 做进一步分析。

因此，Kibana 页面能打开，只说明可视化入口已经启动；要真正查到数据，Elasticsearch 中必须已经有可用索引和文档。

2. 部署前先处理系统环境

当前环境按 CentOS 7.6 以上、x86_64、具备 root 或 sudo 权限来准备。

资源建议里给出的范围是：

组件	最低配置	推荐配置
内存	4 GB RAM	≥ 8 GB
CPU	2 核	≥ 4 核
磁盘	20 GB 可用空间	≥ 100 GB SSD
Swap	关闭	关闭

先关闭 Swap：

# 临时关闭
sudo swapoff -a

# 永久关闭：注释 /etc/fstab 中的 swap 行
sudo sed -i '/swap/s/^/#/' /etc/fstab

这一步会同时处理当前会话和 /etc/fstab。

如果机器上还有其他依赖 Swap 的服务，实际执行前应先确认影响范围。

创建 Elasticsearch 用户

adduser elasticsearch  # 创建名为 'elasticsearch' 的新用户
passwd elasticsearch  # 为 'elasticsearch' 用户设置密码

当前后续 Kibana 目录权限也会交给这个用户，因此用户名保持：

elasticsearch

不要在中途随意换成其他名称。

3. 配置 Elasticsearch 7.x 软件源

先导入 GPG 密钥：

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

创建仓库文件：

sudo vi /etc/yum.repos.d/elasticsearch.repo 

写入：

[elasticsearch-7.x]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

这里配置的是：

Elasticsearch 7.x

软件源。

需要注意的是，到这里仅完成了软件源配置，后面的步骤已经开始使用 localhost:9200，但并没有出现 Elasticsearch 的安装、启动和服务状态命令。

所以实际执行时，继续配置 Logstash 和 Kibana 之前，应先确认 Elasticsearch 已经存在并且：

localhost:9200

确实可访问。

否则后面即使 Kibana 本身成功启动，也无法正常读取 Elasticsearch 数据。

4. 安装并配置 Logstash

安装 Logstash：

sudo yum install logstash -y

创建配置文件：

sudo vi /etc/logstash/conf.d/logstash.conf

写入：

input {
beats {
port => 5044
}
}

output {
elasticsearch {
hosts => ["localhost:9200"]
index => "logstash-%{+YYYY.MM.dd}"
}
stdout { codec => rubydebug }
}

这份配置做了两件事：

• Beats 输入监听 5044
• Elasticsearch 输出指向 localhost:9200

写入索引名为：

logstash-%{+YYYY.MM.dd}

同时还通过：

stdout { codec => rubydebug }

把事件输出到终端，方便观察当前处理结果。

启动并启用 Logstash：

sudo systemctl enable logstash
sudo systemctl start logstash

到这里，Logstash 已经有了接收 Beats 数据和写入 Elasticsearch 的基础配置。

5. 安装 Kibana 7.15.0

先检查当前 iptables 规则，并下载 Kibana：

iptables -nvL  # 显示当前iptables规则
wget https://artifacts.elastic.co/downloads/kibana/kibana-7.15.0-linux-x86_64.tar.gz

当前下载文件是：

kibana-7.15.0-linux-x86_64.tar.gz

解压并修改权限：

tar -zxvf kibana-7.15.0-linux-x86_64.tar.gz  # 解压Kibana存档
chown -R elasticsearch kibana-7.15.0-linux-x86_64  # 将Kibana文件的所有权更改为 'elasticsearch' 用户

再把目录改名为：

kibana

mv kibana-7.15.0-linux-x86_64/ kibana
chown -R elasticsearch kibana

继续复制到 elasticsearch 用户主目录：

cp -r elasticsearch /home/elasticsearch/  # 将Elasticsearch文件复制到 'elasticsearch' 用户的主目录
cp -r kibana /home/elasticsearch/  # 将Kibana文件复制到 'elasticsearch' 用户的主目录
cd /home/elasticsearch/  # 移动到 'elasticsearch' 用户的主目录
chown -R elasticsearch kibana/
chown -R elasticsearch elasticsearch/

这里还有一个路径关系要提前看清。

Kibana 是通过 tar.gz 解压出来并被移动到：

/home/elasticsearch/kibana

但后面编辑配置时使用的是：

/etc/kibana/kibana.yml

所以执行前应先确认当前环境里这个配置文件是否真实存在，以及最终启动的 Kibana 实际读取的是哪一份配置。

命令本身保持不变，不在这里擅自替换路径。

6. 配置 Kibana 连接 Elasticsearch

编辑：

sudo vi /etc/kibana/kibana.yml

配置：

server.host: "0.0.0.0"
elasticsearch.hosts: ["http://localhost:9200"]

这里两个关键值分别是：

• server.host: "0.0.0.0"
• elasticsearch.hosts: ["http://localhost:9200"]

也就是说：

Kibana 允许从非本机地址访问，同时它自己连接的 Elasticsearch 端口是：

9200

然后启动 Kibana：

./bin/kibana

浏览器访问：

http://localhost:5601/

页面出现以后，可以继续测试索引和查询。

7. 用测试数据确认 Kibana 能看到 Elasticsearch

先创建一个 pro 索引并写入文档：

x curl -X POST "http://localhost:9201/pro/_doc" \-H "Content-Type: application/json" \-d '{  "name": "iPhone 15",  "price": 7999,  "category": "phone"}'

这里有两点需要单独留意。

第一，这条命令开头保留了：

x curl

第二，地址使用的是：

localhost:9201

而前面的 Logstash 输出和 Kibana 配置都明确使用：

localhost:9200

所以如果执行时出现连接失败，应先确认：

Elasticsearch 在当前机器实际监听 9200 还是 9201，以及命令前面的 x 是否符合当前终端环境。

不要直接把问题归到 Kibana。

页面刷新以后可以看到新建数据。

接着创建和管理索引模式。

还可以继续查看字段及其类型、搜索属性和映射信息。

8. 把 Kibana 界面切换成中文

在 config/kibana.yml 中加入：

i18n.locale: "zh-CN"

重新启动以后生效。

这里又出现了一个配置路径差异：

前面修改的是：

/etc/kibana/kibana.yml

这里写的是：

config/kibana.yml

实际使用时，应确认当前启动的 Kibana 最终读取哪一份配置文件，再决定修改位置。

9. 在开发工具里继续验证查询和写入

先做一个查询：

curl -X GET "http://localhost:9201/products/_search?q=name:iphone&pretty"

这里继续使用：

localhost:9201

与前面 Kibana 配置中的 localhost:9200 不一致。

如果这台环境里确实做了额外端口映射，那么应该以实际监听为准；如果没有，则需要先排查端口是否写错。

创建索引：

curl -X PUT "http://localhost:9201/xinke?pretty"

向 xinke 写入一条文档：

curl -X POST "http://localhost:9201/xinke/_doc" \
-H "Content-Type: application/json" \
-d '{
  "name": "iPhone 15",
  "price": 7999,
  "category": "phone"
}'

当前测试数据包含：

• name: iPhone 15
• price: 7999
• category: phone

这组数据只是用于验证索引、文档写入和后续可视化链路。

10. 用 Kibana 做第一张可视化图表

进入：

Visualize

Kibana 页面里提供多种图表类型。

这里选择：

垂直条形图

随后配置 X 轴和 Y 轴。

执行后可以看到图表结果。

保存以后继续查看。

做到这里，真正验证的是：

Elasticsearch 中有数据 → Kibana 能读取 → 可视化页面能把查询结果变成图表。

这比只看到 Kibana 首页更接近“日志分析系统已经可用”。

11. 远程查看 Kibana，需要解决的是 5601 的访问路径

Kibana 默认从：

5601

提供 Web 页面。

如果团队成员不在当前局域网，或者临时需要从外部设备查看日志，就需要给这个页面补一个外部访问入口。

这里使用 cpolar。

它在这套链路里只负责：

把 Kibana 的 5601 Web 页面提供到公网。

cpolar 不负责采集日志，不存 Elasticsearch 数据，也不生成 Kibana 图表。

12. 安装 cpolar

执行：

sudo curl https://get.cpolar.sh | sh

安装完成后查看服务状态：

sudo systemctl status cpolar

服务正常以后，通过：

主机 IP + 9200

进入 cpolar Web UI。

页面中的入口写成：

http://ip:9200

实际超链接目标为：

http://localhost:9200/

这里又出现了一个很容易混淆的端口：

• Elasticsearch 示例使用过 9200
• cpolar Web UI 也使用 9200

但它们是不同服务、不同上下文。

如果部署在同一台主机上，实际是否会发生端口冲突，必须结合当前运行方式和真实监听情况确认。

13. 先给 Kibana 创建随机公网地址

进入：

隧道管理 → 创建隧道

参数为：

• 隧道名称：kibana
• 协议：http
• 本地地址：5601
• 域名类型：随机域名
• 地区：China Top

创建以后进入在线隧道列表。

复制生成的公网地址，从其他设备访问。

Kibana 页面可以正常打开。

这一层验证的是：

Kibana 5601 → cpolar HTTP 公网地址 → 外部浏览器。

14. 长期使用再换固定二级子域名

随机地址适合先确认链路。

如果 Kibana 以后需要长期远程查看，再继续配置固定二级子域名。

进入预留页面。

选择：

保留二级子域名

当前参数为：

• 地区：china Top
• 二级子域名：kibanaa

二级子域名具有唯一性，真正使用时以自己账号里实际保留成功的名称为准。

回到：

隧道管理 → 隧道列表

找到对应隧道并编辑。

修改：

• 域名类型：二级子域名
• Sub Domain：填写保留成功的名称
• 地区：China Top

然后更新。

更新以后查看在线隧道列表。

最后用固定公网地址再次访问。

Kibana 页面可以正常打开。

15. 这套 ELK 实操真正应该怎么验收

一套日志分析环境是否搭好，不适合只看“Kibana 页面能不能打开”。

至少要逐层确认：

第一层：Elasticsearch。
索引和文档能写入、能查询。

第二层：Logstash。
5044 能接收 Beats 数据，并且能写入 localhost:9200。

第三层：Kibana。
5601 能打开，索引模式、字段、查询和可视化能使用。

第四层：端口与路径。
确认 9200/9201、/etc/kibana/kibana.yml 与 config/kibana.yml 在当前机器里实际对应什么。

第五层：公网入口。
cpolar 只负责 5601 的外部可达性，不能替代 Elasticsearch、Logstash 或 Kibana 自身的权限控制。

总结

这次真正串起来的主线是：

CentOS 7 → 关闭 Swap → elasticsearch 用户 → Elasticsearch 7.x 仓库 → Logstash 5044 → Elasticsearch 9200 → Kibana 7.15.0 → 5601 → 创建索引 / 写入文档 → i18n.locale: "zh-CN" → Visualize 垂直条形图 → cpolar → 5601 随机公网 → 固定二级子域名 kibanaa。

有几处技术细节需要继续留意：

• Elasticsearch 只展示了 GPG 和 7.x 仓库配置，没有出现安装、启动命令；继续前应先确认 9200 服务真实存在；
• Logstash 和 Kibana 都配置为访问 localhost:9200，但后续 curl 示例多次使用 localhost:9201；
• 第一条写入测试数据的命令以 x curl 开头，执行前要确认命令格式；
• Kibana 通过 tar.gz 解压并移动到 /home/elasticsearch/kibana，但配置步骤又出现 /etc/kibana/kibana.yml 和 config/kibana.yml 两种路径；
• cp -r elasticsearch /home/elasticsearch/ 假设当前目录下已经存在名为 elasticsearch 的目录，实际执行前应确认来源；
• cpolar Web UI 与 Elasticsearch 示例都涉及 9200，同机部署时应确认真实监听关系；
• cpolar 只负责 Kibana 5601 的公网入口，不负责日志采集、索引、查询和告警；
• 固定二级子域名示例继续使用 kibanaa，地区是 China Top。

把这些边界核对清楚以后，ELK 才真正从“装了三个组件”变成一条能持续接收数据、查询问题、画出趋势并从外部查看的日志分析链路。真正有价值的也不是图表本身，而是故障发生时，能更快从日志里找到可以行动的线索。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_62765017/article/details/166597281