前言-碎碎叨叨
刚了解Elastic Stack 可能有的同学可能有点蒙，ELK耳熟能详啊，Elastic Stack是个啥。
虽然是N年前就早已推出来的产品，但是目前来讲还是比较主流的解决方案，笔者继续以《举个小栗子🌰》系列(其实才第二篇)的方式和没接触过的同学入个门。
ELK，大家都知道是一套日志收集以及展示的解决方案。
毕竟服务多了，节点多了，查个日志总不能挨个机器找吧。还真别说，我有个朋友以前就经历过，找一个bug敲碎了键盘的dockerlog加上从来都很可怜的空格。
这个朋友是我本人没错了。
回到正文
Elastic Stack和ELK什么关系？
笔者分析了一圈官网，起因大概是ElasticSearch官方新推出个产品线-Beats，与ELK集成效果更佳，非要把L(Logstash)篡位了呢，也不是不行。
这官方起名这步难住了，也寻思半天，ELKB是不是太长了，哪天再来几个产品，这帮软件工程师该背不下来了。
这就有点像十年前面试:
你java用什么框架？
ssh呗
仨字母搞定。
到了今天，项目使用技术越来越多，很多人都会改称为java相关技术栈。
所以，类似这个原因一样，Elastic Stack这个高大上的名就诞生了。
ps：故事情节为笔者个人推测，没有官方证据😊
Beats又是什么？
同事老王：Beats我贼熟啊，上下班天天戴！
没错，官方就是希望你使用ELK的时候戴个耳机，会更专心的查bug。
当然不是和Beats出联名款耳机了。
Elastic中的Beats，官方定义为轻量型数据采集器，Beats不是一个产品，是指一类产品，比如：
- Filebeat - 实时日志查看
- Packetbeat - 网络数据包分析
- Winlogbeat - windows平台事件日志分析
- Heartbeat - 关于心跳检测的基础设施
- ....
目前大概有八个种类的Beats，每一种都专门对应一项设施，非常人性化。
看来这个B，还是很厉害的，值得改一次名。
正文
开启今天的正文，本文是《举个小栗子🌰》系列之一，接下来就用个小栗子演示一下SpringCloud与ELKB Elastic Stack的集成。
目标：本地启动SpringCloud工程，通过FileBeats(也就是其中一个Beats之一，主打日志收集功能)向ELK发送日志，观察负载在两个节点的同一个接口日志情况。
笔者手头的工程注册中心是Nacos，但是代码太多了，演示略显复杂，所以还是建个超级简单的工程吧。
有多简单呢，就这么简单：
- eureka
- gateway
- producer-v
- producer-t
两个producer服务代码是一样的，负载提供服务。
环境就这样，下面Demo开始~
ELK搭建
讲道理，应该是ELK展示搭建在一台Server，FileBeats因为要收集日志，所以和业务工程放在一个Server。 笔者也尝试了一下在我的资源匮乏的服务器上跑ELK，结果不出所料....
把敲碎的dockerlog粘上又打了一遍，还被机器训了，说我太low：
还是都在本地跑吧。
首先Dockerhub有已经集成好的ELK组合的仓库, 非常方便，直接使用即可，比如笔者使用docker-compose的话，直接本地新建一个文件，文件名一般就叫docker-compose.yml。
elk:
image: sebp/elk
ports:
- "5601:5601"
- "9200:9200"
- "5044:5044"
把镜像名和对应端口指定好，就可以愉快的docker-compose up elk了
ps：这里不用docker手动安装的话，的确会稍稍麻烦，要注意处理好依赖的配置。
容器启动完成后，可以先尝试访问kibana，笔者本地对应的就是localhost:5601/，看到欢迎界面，没错就是启动完成了。
这个界面欢迎你是客套一下，其实就想问你同不同意帮助改进😊，如果你看英文不习惯，可以进入容器中找到config/kibana.yml增加一行国际化配置即可：
i18n.locale: "zh-CN"
如果你的服务半天都没有启动好，不妨也查查日志，是不是和笔者一样“太low”了😂。
FileBeats安装
FileBeats的安装相对简单，只需要去官网下载页面下载对应平台的版本即可，当然了，也可以选择docker运行。
不同平台对应不同的安装方式，官网有对应的说明，大部分直接解压即可。
安装完成后，打开主要配置文件filebeat.yml, 文件比较重要的配置有两块：
- input
- output
这个就好理解了，日志从哪来的，到哪去的，都配置好它，就会从业务服务传送到日志服务中了。
- Input的简单配置：
将type为log的开关打开，并且修改日志path为要扫描的路径。
yml写法的横线(-)大家都知道是数组元素的意思，所以path是支持多个的。
- output的简单配置：
因为logstash我还想用，所以output是到logstash上的，需要把上面输出到elasticsearch的配置注释掉，并且将下方关于logstash的注释打开。
ip和端口对应的就是笔者环境的logstash，笔者的环境上面也说了，服务器说我太low，所以我就都搭到本地了。
配置完成后，按照官方文档写好的各个平台启动方式，启动即可。
对了，笔者本次是简单测试，所以SSL没有配置，需要把容器里logstash配置文件的SSL开启状态注释掉：
否则可能会报错哦，反正我是报错了。
测试
环境杂七杂八都差不多了，启动SpringCloud套餐，准备测试，笔者的两个Producer都提供了一样的接口，如下：
传入名称，一个返回V Application前缀，一个返回T Application前缀。
负载策略是随机。
好！下面就来调戏一下我们的接口，笔者分别改了几个参数请求了几次：
http://localhost:8888/producer/demo?name=哥
http://localhost:8888/producer/demo?name=大哥
http://localhost:8888/producer/demo?name=二哥
http://localhost:8888/producer/demo?name=三个
http://localhost:8888/producer/demo?name=四哥
http://localhost:8888/producer/demo
请求结果分别负载到了不同的接口，现在就去Kibana看看日志是不是成果输出了？
回到Kibana，笔者已经加好了国际化的配置，并且重启完成，一进来便是首页。
功能齐全，如果你还没有配好日志输入进来，也可以使用系统中提供的测试数据熟悉系统。
按照计划我们进入Logs模块：
可以看到，从空的列表，已经被我们服务的日志填满， 搜搜看刚才的参数，看看是不是能很快找到笔者的日志。
那么笔者就搜一下“来啦”两个字，看看响应速度和展示结果如何。
搜索速度非常快，不愧是Elasticsearch的基本功！
日志结果也可以看到，我们命中不同服务的日志记录也都找到了。
总结
本次的小demo省略了非常多的配置，只是为了呈现一个最基本的，从服务端点到日志端点的一个传输流程。
没有用过Elastic Stack的同学，是不是也大概了解了Elastic Stack是什么，以及如何整合到我们的工程中了呢😊？
