ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

日志太多还在 grep?用 ELK + Kibana 搭一套可搜索、可视化、可远程访问的分析平台 日志太多还在 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 → KibanaKibana 常见用途包括Discover 中按关键词、字段和时间范围查日志用图表观察错误量、请求趋势或业务分布把多个图表组成 Dashboard结合日志、指标和 APM 做进一步分析。因此Kibana 页面能打开只说明可视化入口已经启动要真正查到数据Elasticsearch 中必须已经有可用索引和文档。2. 部署前先处理系统环境当前环境按 CentOS 7.6 以上、x86_64、具备root或sudo权限来准备。资源建议里给出的范围是组件最低配置推荐配置内存4 GB RAM≥ 8 GBCPU2 核≥ 4 核磁盘20 GB 可用空间≥ 100 GB SSDSwap关闭关闭先关闭 Swap# 临时关闭sudoswapoff-a# 永久关闭注释 /etc/fstab 中的 swap 行sudosed-i/swap/s/^/#//etc/fstab这一步会同时处理当前会话和/etc/fstab。如果机器上还有其他依赖 Swap 的服务实际执行前应先确认影响范围。创建 Elasticsearch 用户adduser elasticsearch# 创建名为 elasticsearch 的新用户passwdelasticsearch# 为 elasticsearch 用户设置密码当前后续 Kibana 目录权限也会交给这个用户因此用户名保持elasticsearch不要在中途随意换成其他名称。3. 配置 Elasticsearch 7.x 软件源先导入 GPG 密钥sudorpm--importhttps://artifacts.elastic.co/GPG-KEY-elasticsearch创建仓库文件sudovi/etc/yum.repos.d/elasticsearch.repo写入[elasticsearch-7.x]nameElasticsearch repositoryfor7.x packagesbaseurlhttps://artifacts.elastic.co/packages/7.x/yumgpgcheck1gpgkeyhttps://artifacts.elastic.co/GPG-KEY-elasticsearchenabled1autorefresh1typerpm-md这里配置的是Elasticsearch 7.x软件源。需要注意的是到这里仅完成了软件源配置后面的步骤已经开始使用localhost:9200但并没有出现 Elasticsearch 的安装、启动和服务状态命令。所以实际执行时继续配置 Logstash 和 Kibana 之前应先确认 Elasticsearch 已经存在并且localhost:9200确实可访问。否则后面即使 Kibana 本身成功启动也无法正常读取 Elasticsearch 数据。4. 安装并配置 Logstash安装 Logstashsudoyuminstalllogstash-y创建配置文件sudovi/etc/logstash/conf.d/logstash.conf写入input{beats{port5044}}output{elasticsearch{hosts[localhost:9200]indexlogstash-%{YYYY.MM.dd}}stdout{codecrubydebug}}这份配置做了两件事Beats 输入监听5044Elasticsearch 输出指向localhost:9200写入索引名为logstash-%{YYYY.MM.dd}同时还通过stdout { codec rubydebug }把事件输出到终端方便观察当前处理结果。启动并启用 Logstashsudosystemctlenablelogstashsudosystemctl start logstash到这里Logstash 已经有了接收 Beats 数据和写入 Elasticsearch 的基础配置。5. 安装 Kibana 7.15.0先检查当前 iptables 规则并下载 Kibanaiptables-nvL# 显示当前iptables规则wgethttps://artifacts.elastic.co/downloads/kibana/kibana-7.15.0-linux-x86_64.tar.gz当前下载文件是kibana-7.15.0-linux-x86_64.tar.gz解压并修改权限tar-zxvfkibana-7.15.0-linux-x86_64.tar.gz# 解压Kibana存档chown-Relasticsearch kibana-7.15.0-linux-x86_64# 将Kibana文件的所有权更改为 elasticsearch 用户再把目录改名为kibanamvkibana-7.15.0-linux-x86_64/ kibanachown-Relasticsearch kibana继续复制到elasticsearch用户主目录cp-relasticsearch /home/elasticsearch/# 将Elasticsearch文件复制到 elasticsearch 用户的主目录cp-rkibana /home/elasticsearch/# 将Kibana文件复制到 elasticsearch 用户的主目录cd/home/elasticsearch/# 移动到 elasticsearch 用户的主目录chown-Relasticsearch kibana/chown-Relasticsearch elasticsearch/这里还有一个路径关系要提前看清。Kibana 是通过 tar.gz 解压出来并被移动到/home/elasticsearch/kibana但后面编辑配置时使用的是/etc/kibana/kibana.yml所以执行前应先确认当前环境里这个配置文件是否真实存在以及最终启动的 Kibana 实际读取的是哪一份配置。命令本身保持不变不在这里擅自替换路径。6. 配置 Kibana 连接 Elasticsearch编辑sudovi/etc/kibana/kibana.yml配置server.host:0.0.0.0elasticsearch.hosts:[http://localhost:9200]这里两个关键值分别是server.host: 0.0.0.0elasticsearch.hosts: [http://localhost:9200]也就是说Kibana 允许从非本机地址访问同时它自己连接的 Elasticsearch 端口是9200然后启动 Kibana./bin/kibana浏览器访问http://localhost:5601/页面出现以后可以继续测试索引和查询。7. 用测试数据确认 Kibana 能看到 Elasticsearch先创建一个pro索引并写入文档xcurl-XPOSThttp://localhost:9201/pro/_doc\-HContent-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-XGEThttp://localhost:9201/products/_search?qname:iphonepretty这里继续使用localhost:9201与前面 Kibana 配置中的localhost:9200不一致。如果这台环境里确实做了额外端口映射那么应该以实际监听为准如果没有则需要先排查端口是否写错。创建索引curl-XPUThttp://localhost:9201/xinke?pretty向xinke写入一条文档curl-XPOSThttp://localhost:9201/xinke/_doc\-HContent-Type: application/json\-d{ name: iPhone 15, price: 7999, category: phone }当前测试数据包含name:iPhone 15price:7999category:phone这组数据只是用于验证索引、文档写入和后续可视化链路。10. 用 Kibana 做第一张可视化图表进入VisualizeKibana 页面里提供多种图表类型。这里选择垂直条形图随后配置 X 轴和 Y 轴。执行后可以看到图表结果。保存以后继续查看。做到这里真正验证的是Elasticsearch 中有数据 → Kibana 能读取 → 可视化页面能把查询结果变成图表。这比只看到 Kibana 首页更接近“日志分析系统已经可用”。11. 远程查看 Kibana需要解决的是 5601 的访问路径Kibana 默认从5601提供 Web 页面。如果团队成员不在当前局域网或者临时需要从外部设备查看日志就需要给这个页面补一个外部访问入口。这里使用 cpolar。它在这套链路里只负责把 Kibana 的5601Web 页面提供到公网。cpolar 不负责采集日志不存 Elasticsearch 数据也不生成 Kibana 图表。12. 安装 cpolar执行sudocurlhttps://get.cpolar.sh|sh安装完成后查看服务状态sudosystemctl status cpolar服务正常以后通过主机 IP 9200进入 cpolar Web UI。页面中的入口写成http://ip:9200实际超链接目标为http://localhost:9200/这里又出现了一个很容易混淆的端口Elasticsearch 示例使用过9200cpolar Web UI 也使用9200但它们是不同服务、不同上下文。如果部署在同一台主机上实际是否会发生端口冲突必须结合当前运行方式和真实监听情况确认。13. 先给 Kibana 创建随机公网地址进入隧道管理 → 创建隧道参数为隧道名称kibana协议http本地地址5601域名类型随机域名地区China Top创建以后进入在线隧道列表。复制生成的公网地址从其他设备访问。Kibana 页面可以正常打开。这一层验证的是Kibana5601→ 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 仓库 → Logstash5044→ Elasticsearch9200→ 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 只负责 Kibana5601的公网入口不负责日志采集、索引、查询和告警固定二级子域名示例继续使用kibanaa地区是China Top。把这些边界核对清楚以后ELK 才真正从“装了三个组件”变成一条能持续接收数据、查询问题、画出趋势并从外部查看的日志分析链路。真正有价值的也不是图表本身而是故障发生时能更快从日志里找到可以行动的线索。
返回列表