elk数据存储位置

① elk为什么会丢日志

elk会丢日志原因：增加日志目录的大小，将日志压缩保存。

elk现在的集群所需要解决的问题不仅仅是高性能、高可靠性、高可扩展性,还需要面对易维护性以及数据平台内部的数据共享性等诸多挑战。

elk系统运维数据既能实现数据平台各组件的集中式管理,方便系统运维人员,提升运维效率,又能反馈系统运行状态给系统开发人员。

elk分卷压缩：

在WinRAR中也集成了分卷压缩的功能，而且它并不像WinZip那样必须在软盘的支持下才可以使用这个功能，在制作的时候能够将某个大文件分卷压缩存放在任意指定的盘符中，所以这也大大的方便了我们的使用。

elk分卷压缩的文件或者是文件夹，在弹出的菜单中选择“添加到压缩包”选项。压缩包名称”对话框中确定文件存放的路径和名称，这时就可以将分卷压缩之后的文件存放在硬盘中的任何一个文件夹中。

elk同时在“压缩方式”下拉列表中选择采用何种方式进行压缩，建议大家采用“最好”方式，这样能够让WinRAR最大程度的压缩文件。

② ELK应用之Filebeat

Filebeat是本地文件的日志数据采集器，可监控日志目录或特定日志文件（tail file），并将它们转发给Elasticsearch或Logstatsh进行索引、kafka等。带有内部模块（auditd，Apache，Nginx，System和MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。

官方网址: https://www.elastic.co/guide/en/beats/filebeat/current/index.html

Filebeat涉及两个组件：查找器prospector和采集器harvester，来读取文件(tail file)并将事件数据发送到指定的输出。

启动Filebeat时，它会启动一个或多个查找器，查看你为日志文件指定的本地路径。对于prospector所在的每个日志文件，prospector启动harvester。每个harvester都会为新内容读取单个日志文件，并将新日志数据发送到libbeat，后者将聚合事件并将聚合数据发送到你为Filebeat配置的输出。

当发送数据到Logstash或Elasticsearch时，Filebeat使用一个反压力敏感(backpressure-sensitive)的协议来解释高负荷的数据量。当Logstash数据处理繁忙时，Filebeat放慢它的读取速度。一旦压力解除，Filebeat将恢复到原来的速度，继续传输数据。

Harvester负责读取单个文件的内容。读取每个文件，并将内容发送到the output，每个文件启动一个harvester, harvester负责打开和关闭文件，这意味着在运行时文件描述符保持打开状态。

如果文件在读取时被删除或重命名，Filebeat将继续读取文件。这有副作用，即在harvester关闭之前，磁盘上的空间被保留。默认情况下，Filebeat将文件保持打开状态，直到达到close_inactive状态

关闭harvester会产生以下结果：

1）如果在harvester仍在读取文件时文件被删除，则关闭文件句柄，释放底层资源。

2）文件的采集只会在scan_frequency过后重新开始。

3）如果在harvester关闭的情况下移动或移除文件，则不会继续处理文件。

要控制收割机何时关闭，请使用close_ *配置选项

Prospector负责管理harvester并找到所有要读取的文件来源。如果输入类型为日志，则查找器将查找路径匹配的所有文件，并为每个文件启动一个harvester。每个prospector都在自己的Go协程中运行。

Filebeat目前支持两种prospector类型：log和stdin。每个prospector类型可以定义多次。日志prospector检查每个文件来查看harvester是否需要启动，是否已经运行，或者该文件是否可以被忽略（请参阅ignore_older）。

只有在harvester关闭后文件的大小发生了变化，才会读取到新行。

注：Filebeat prospector只能读取本地文件，没有功能可以连接到远程主机来读取存储的文件或日志。

配置文件：$FILEBEAT_HOME/filebeat.yml。Filebeat可以一次读取某个文件夹下的所有后缀名为log的文件，也可以读取指定的某一个后缀名为log的文件。

配置文件详解（ http://blog.51cto.com/michaelkang/1864225 ）

（1）字段解释

paths： 指定要监控的日志，目前按照Go语言的glob函数处理。没有对配置目录做递归处理，比如配置的如果是：

/var/log/* /*.log

则只会去/var/log目录的所有子目录中寻找以".log"结尾的文件，而不会寻找/var/log目录下以".log"结尾的文件。

encoding： 指定被监控的文件的编码类型，使用plain和utf-8都是可以处理中文日志的。

input_type： 指定文件的输入类型log(默认)或者stdin。

exclude_lines： 在输入中排除符合正则表达式列表的那些行。

include_lines： 包含输入中符合正则表达式列表的那些行（默认包含所有行），include_lines执行完毕之后会执行exclude_lines。

exclude_files： 忽略掉符合正则表达式列表的文件（默认为每一个符合paths定义的文件都创建一个harvester）。

fields： 向输出的每一条日志添加额外的信息，比如"level:debug"，方便后续对日志进行分组统计。默认情况下，会在输出信息的fields子目录下以指定的新增fields建立子目录，

fields_under_root： 如果该选项设置为true，则新增fields成为顶级目录，而不是将其放在fields目录下。自定义的field会覆盖filebeat默认的field。

ignore_older： 可以指定Filebeat忽略指定时间段以外修改的日志内容，比如2h（两个小时）或者5m(5分钟)。

close_older： 如果一个文件在某个时间段内没有发生过更新，则关闭监控的文件handle。默认1h。

force_close_files： Filebeat会在没有到达close_older之前一直保持文件的handle，如果在这个时间窗内删除文件会有问题，所以可以把force_close_files设置为true，只要filebeat检测到文件名字发生变化，就会关掉这个handle。

scan_frequency： Filebeat以多快的频率去prospector指定的目录下面检测文件更新（比如是否有新增文件），如果设置为0s，则Filebeat会尽可能快地感知更新（占用的CPU会变高）。默认是10s。

document_type： 设定Elasticsearch输出时的document的type字段，也可以用来给日志进行分类。

harvester_buffer_size： 每个harvester监控文件时，使用的buffer的大小。

max_bytes： 日志文件中增加一行算一个日志事件，max_bytes限制在一次日志事件中最多上传的字节数，多出的字节会被丢弃。默认是10MB。

multiline： 适用于日志中每一条日志占据多行的情况，比如各种语言的报错信息调用栈。这个配置的下面包含如下配置：

pattern： 多行日志开始的那一行匹配的pattern

negate： 是否需要对pattern条件转置使用，不翻转设为true，反转设置为false。

match： 匹配pattern后，与前面（before）还是后面（after）的内容合并为一条日志

max_lines： 合并的最多行数（包含匹配pattern的那一行），默认为500行。

timeout： 到了timeout之后，即使没有匹配一个新的pattern（发生一个新的事件），也把已经匹配的日志事件发送出去

tail_files： 如果设置为true，Filebeat从文件尾开始监控文件新增内容，把新增的每一行文件作为一个事件依次发送，而不是从文件开始处重新发送所有内容。

backoff： Filebeat检测到某个文件到了EOF之后，每次等待多久再去检测文件是否有更新，默认为1s。

max_backoff： Filebeat检测到某个文件到了EOF之后，等待检测文件更新的最大时间，默认是10秒。

backoff_factor： 定义到达max_backoff的速度，默认因子是2，到达max_backoff后，变成每次等待max_backoff那么长的时间才backoff一次，直到文件有更新才会重置为backoff。比如： 

如果设置成1，意味着去使能了退避算法，每隔backoff那么长的时间退避一次。

spool_size: spooler的大小，spooler中的事件数量超过这个阈值的时候会清空发送出去（不论是否到达超时时间），默认1MB。

idle_timeout: spooler的超时时间，如果到了超时时间，spooler也会清空发送出去（不论是否到达容量的阈值），默认1s。

registry_file: 记录filebeat处理日志文件的位置的文件

config_dir: 如果要在本配置文件中引入其他位置的配置文件，可以写在这里（需要写完整路径），但是只处理prospector的部分。

publish_async： 是否采用异步发送模式（实验功能）。

具体的一个yml采集配置样例如下：该配置文件是filebeat采集数据的依据，并根据需求添加必要配置，filebeat收集日志后发往logstash，配置如下：

cd FILEBEAT_HOME

 nohup ./bin/filebeat -f config/test.conf >>/FILEBEAT_HOME/logs/filebeat.log &

后台启动filebeat，配置对应的参数

启动多个filebeat配置，新建一个目录（conf）存放多个filebeat的配置文件，

#nohup ./bin/filebeat -f conf/* >>/FILEBEAT_HOME/logs/filebeat.log &

 注意：一台服务器只能启动一个filebeat进程。

ps -ef |grep filebeat

kill -9 $pid

注意： 非紧急情况下，杀掉进程只能用优雅方式。

A、filebeat运行不成功

问题：配置文件格式有问题，配置文件遵循yml文件格式， 多或少一个空格 都会导致启动问题，可以使用cmd命令窗口到filebeat安装路径下，使用filebeat.exe –c filebeat.yml 查看报错，也可以看filebeat路径下的log文件夹中的filebeat文件

B、 filebeat第一次运行成功无数据

问题：a、路径有问题

b、运行条件设置有问题（例如只采集某个条件下的数据，文件中没有符合条件的数据，这种情况下先注释掉采集条件测试一下）

C、filebeat运行成功第一次运行后有数据，第二次无数据

问题：filebeat读取文件后会生成一个registry文件，注意windows机器中这个文件在手动启动的情况下会在filebeat安装目录下的data文件夹中，服务注册启动的情况下会在C盘下隐藏文件夹C:\ProgramData\filebeat中，删除掉这个就可以了

D、filebeat运行成功有数据，但是新添加数据不读取问题

问题：filebeat传输存在反压机制，在数据量特别大或者传输通道不通的情况下，filebeat会进行反压，暂停发送，等到数据量稳定或者数据传输通道正常的之后才会发送

Filebeat 保存每个文件的状态并经常将状态刷新到磁盘上的注册文件中。该状态用于记住harvester正在读取的最后偏移量，并确保发送所有日志行。如果输出（例如Elasticsearch或Logstash）无法访问，Filebeat会跟踪最后发送的行，并在输出再次可用时继续读取文件。

在Filebeat运行时，每个prospector内存中也会保存文件状态信息，当重新启动Filebeat时，将使用注册文件的数据来重建文件状态，Filebeat将每个harvester在从保存的最后偏移量继续读取。

每个prospector为它找到的每个文件保留一个状态。由于文件可以被重命名或移动，因此文件名和路径不足以识别文件。对于每个文件，Filebeat存储唯一标识符以检测文件是否先前已被采集过。

如果你使用的案例涉及每天创建大量新文件，你可能会发现注册文件增长过大。请参阅注册表文件太大？编辑有关你可以设置以解决此问题的配置选项的详细信息。

Filebeat保证事件至少会被传送到配置的输出一次，并且不会丢失数据。 Filebeat能够实现此行为，因为它将每个事件的传递状态存储在注册文件中。

在输出阻塞或未确认所有事件的情况下，Filebeat将继续尝试发送事件，直到接收端确认已收到。如果Filebeat在发送事件的过程中关闭，它不会等待输出确认所有收到事件。

发送到输出但在Filebeat关闭前未确认的任何事件在重新启动Filebeat时会再次发送。这可以确保每个事件至少发送一次，但最终会将重复事件发送到输出。

也可以通过设置shutdown_timeout选项来配置Filebeat以在关闭之前等待特定时间。

注意：Filebeat的至少一次交付保证包括日志轮换和删除旧文件的限制。如果将日志文件写入磁盘并且写入速度超过Filebeat可以处理的速度，或者在输出不可用时删除了文件，则可能会丢失数据。

在linux上，Filebeat也可能因inode重用而跳过行。有关inode重用问题的更多详细信息，请参阅filebeat常见问题解答。

Logback日志切割用的是JDK里File#renameTo()方法。如果该方法失败，就再尝试使用复制数据的方式切割日志。查找该方法相关资料得知，只有当源文件和目标目录处于同一个文件系统、同volumn(即windows下的C, D盘)下该方法才会成功，切不会为重命名的后的文件分配新的inode值。也就是说，如果程序里一直保存着该文件的描述符，那么当程序再写日志时，就会向重命名后的文件中写。那么问题来了，filebeat是会一直打开并保存文件描述符的，那么它是怎么得知日志被切割这件事的呢？

如果只用当前文件描述符一路监控到天黑的话，那么当logback把日志重命名后，filebeat仍然会监控重命名后的日志，新创建的日志文件就看不到了。实际上，filebeat是通过close_inactive和scan_frequency两个参数(机制)来应对这种情况的：

(1)close_inactive

该参数指定当被监控的文件多长时间没有变化后就关闭文件句柄(file handle)。官方建议将这个参数设置为一个比文件最大更新间隔大的值。比如文件最长5s更新一次，那就设置成1min。默认值为5min。

(2)scan_frequency

该参数指定Filebeat搜索新文件的频率(时间间隔)。当发现新的文件被创建时， Filebeat会为它再启动一个 harvester 进行监控，默认为10s。

综合以上两个机制，当logback完成日志切割后(即重命名)，此时老的harvester仍然在监控重命名后的日志文件，但是由于该文件不会再更新，因此会在close_inactive时间后关闭这个文件的 harvester。当scan_frequency时间过后，Filebeat会发现目录中出现了新文件，于是为该文件启动 harvester 进行监控。这样就保证了切割日志时也能不丢不重的传输数据。(不重是通过为每个日志文件保存offset实现的)

③ eplan中的elk包含不完整的数据

卸掉重新安装时选择英文即可。
常规的EPLAN项目由edb和elk组成。edb是个文件夹，其内包含子文件夹，这里存储着EPLAN的项目数据，elk是一个链接文件，当双击它时，会启动EPLAN并打开此项目。
选择项目模板建立一个Eplan项目后，软件会选择符合项目模板标准的符号库、图框、表格等系统主数据复制到项目数据中，如果有一个项目中的项目数据和系统主数据有不一样的符号、图框、表格等数据时，可以通过工具—主数据—同步主数据功能，将不同数据同步到系统主数据中。

④ elk用于解决hadoop什么问题

elk用于解决hadoopHadoop实现了一个分布式文件系统，设计用来部署在低廉的硬件上；而且提供高吞吐量来访问应用程序的数据，适合那些有着超大数据集的应用程序。

但是由于“大数据”和“Hadoop”这两个热门词，即使很多人实际上不需要Hadoop，他们也愿意穿上“紧身衣”。 一、如果我的数据量是几百兆，Excel可能没法加载它 对于Excel软件来说的“很大的数据”并非大数据，其实还有其它极好的工具可以使用。

核心架构：

Hadoop 由许多元素构成。其最底部是 Hadoop Distributed File System（HDFS），它存储 Hadoop 集群中所有存储节点上的文件。HDFS的上一层是MapRece引擎，该引擎由 JobTrackers 和 TaskTrackers 组成。

通过对Hadoop分布式计算平台最核心的分布式文件系统HDFS、MapRece处理过程，以及数据仓库工具Hive和分布式数据库Hbase的介绍，基本涵盖了Hadoop分布式平台的所有技术核心。

⑤ ELK日志分析系统初体验

ELK

logstash

elasticsearch

kibana

ELK技术栈要点总结

官方文档之安装教程

Mac第三方工具安装

$ brew install logstash

********启动命令********

$ bin/logstash -f logstash-example.conf

Logstash根据logstash-example.conf配置文件对数据源进行数据读取和清洗，并将清洗结果写入指定的目标文件。

logstash命令除了可以使用“-f”指定配置文件外，还可以指定其他参数，具体说明可以参见 官方文档之Command Flags 。

Logstash除了通过命令行参数进行配置外，还可以在logstash.yml等setting文件中进行设置，具体说明参见 官方文档之Setting files

配置文件

配置文件结构清晰，但所涉及的插件种类繁多，而且在插件使用过程中还涉及 环境变量使用 和 条件语句使用 等内容。用户可根据需要选择适当的插件和语法实现数据收集和清洗的目标。

##1.2 Elasticsearch****技术

****Cluster****与****Node****

****Index****、****Type****与****Document****

****Shards****与****Replicas****

********启动命令********

$ bin/elasticsearch 前端方式启动
$ bin/elasticsearch -d 守护进程方式启动
elasticsearch启动比较简单，也额外创建配置文件，它将收集的数据重新编排存储，以支持数据的全文检索。检索是Elasticsearch最为重要的功能，也是最为复杂的语法。

********需要注意的是：********elasticsearch不支持在root用户下启动，因此，在启动前，用户需要创建非root用户，并为该用户赋予elasticsearch目录的操作权限，详情参见 https://my.oschina.net/topeagle/blog/591451?fromerr=mzOr2qzZ

********配置管理********
Elasticsearch一般不需额外配置，但是为了提高Elasticsearch性能可以通过elasticsearch.yml文件修改配置参数。当然，也可以根据用户系统配置降低配置参数，如jvm.heapsize。Elasticsearch默认占用2G内存，对于系统配置较低的服务器，很可能带来负载过大的问题，因此需要适当减少jvm.heapsize。

Elasticsearch提供大量的API支持检索服务，用户甚至可以根据需要定制化 分析器 、 映射器 .

##1.3 Kibana****技术

********安装********
参见 官方教程 ，值得注意的是Kibana与Elasticsearch版本要保持一致。

********启动********

********配置********
Kibana配置可以通过命令行参数或配置文件 kibana.yml 。Kibana应用的默认地址为localhost，无法从远程访问Kibana，因此，用户需要修改配置文件的server.host属性。

********数据检索********

（1）时间筛选：限定检索的时间范围

（2）index pattern：限定检索的数据范围
（3）字段筛选：限定特殊字段以及特殊字段值
（4）搜索框：采用Elasticsearch检索语法查询

********数据分析********
数据分析是Elasticsearch与Kibana的核心模块，Elasticsearch提供分析功能，kibana提供图形渲染功能。

数据分析需要涉及Elasticsearch的 Aggregation 、 Mapping 、 Analysis 和Kibana的 Visualize 和 Dashboard 等模块，内容相对比较复杂，用户可根据实际需要适当选择。

Kibana的Visualize是基于Elasticsearch聚合结果进行图形化展示，支持AreaChart、DataTable、PieChart等图表结构。Dashboard则是将多个visualize综合展示，并配注markdown记录，形成完整的数据分析报告。

#2 ****日志分析系统
##2.1 ****基于阿里云****NAS****的日志分析系统架构设计

********日志生成：********对于java和Node应用，分别采用Logback与winston日志框架生成日志，注意，日志采用json格式单行存储（一行json对应一条日志）

********日志存储：********分布式应用的日志采用NAS统一存储，减少因日志分散保存而带来数据收集的高复杂度。

********日志收集与清洗：********基于Logback的Pipeline功能，从NAS读取日志数据，并通过 filter插件进行日志的格式化清洗，并将清洗结果传送到Elasticsearch。

********日志重排与存储：********Elasticsearch将收集的数据进行重排，以支持符合elasticsearch检索语法。并将重排数据予以保存，同事可以通过集群、分片（Shards、Replicas）等进行冗余存储。

********日志分析与检索：********通过Elasticsearch Search API即可检索与分析数据，但基于命令行的分析可视化不够，借助Kibana可以将日志分析与检索采用图形化、列表化的方式予以展现，提高数据的可读性。

##2.2 ****日志收集

********（****1****）**** Input****部分********

采用file插件收集NAS日志收据，path指定日志存放地址，采用通配符指定多个文件。

为了便于日志的Archive，以及标识产生日志的应用容器，日志文件采用“log+hostname”方式命名，因此，同一类日志可能会存在多个日志文件。

start_position指定从日志文件Start位置开始收集，file插件默认从End位置收集，只会收集Logstash启动后生成的日志。

type标识日志类型，对于微服务应用，我们借助type区分应用类型，以方便日后检索与问题定位。

********（****2****）**** Filter****部分********

filter的配置需要根据日志格式和清洗目标按需定制，在我们的项目中，日志采用json格式，其中message key对应的value又是json对象的字符串，因此在提取json key-value时需要做两次json过滤。

Logstash默认每条日志为message key的value，因此第一个json是对一条完整日志进行筛选，将json转换为一个个键值对。转换后，并不能将日志message字段对应的json对象拆分提取，因此需要再使用json插件过滤。由于完整日志对应的message key与日志内message key，二次使用json时Logstash会认为对完整日志进行过滤，为此需要对 message进行重命名，这时采用mutate插件完成。

********注意：********filter插件比较多，也比较复杂，用户可以根据自己需要按需选择。
##2.3 ****日志分析（检索）

（1）时间范围：按照日、周、月、年度分别统计分析
（2）应用比较：各类应用的使用频繁程度比较，结合监控数据判断每类应用耗用资源情况等
（3）API分析：各类请求接口的使用情况分析，哪类API使用频繁，各API的响应时间如何

⑥ elk是什么

“ELK”是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana。Elasticsearch 是一个搜索和分析引擎。Logstash 是服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如 Elasticsearch 等“存储库”中。Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。

⑦ ELK是用来做什么的

大数据日志分析

⑧ “SpringCloud”（三十八）搭建ELK日志采集与分析系统

 一套好的日志分析系统可以详细记录系统的运行情况，方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式，那么日志记录下来，相关人员就需要对日志数据进行处理与分析，基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。

  作为微服务集群，必须要考虑当微服务访问量暴增时的高并发场景，此时系统的日志数据同样是爆发式增长，我们需要通过消息队列做流量削峰处理，Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列，但其各项功能显示不如单一实现的消息队列，所以通常情况下并不使用它的消息队列功能；Kafka的性能要优于RabbitMQ，通常在日志采集，数据采集时使用较多，所以这里我们采用Kafka实现消息队列功能。
  ELK日志分析系统中，数据传输、数据保存、数据展示、流量削峰功能都有了，还少一个组件，就是日志数据的采集，虽然log4j2可以将日志数据发送到Kafka，甚至可以将日志直接输入到Logstash，但是基于系统设计解耦的考虑，业务系统运行不会影响到日志分析系统，同时日志分析系统也不会影响到业务系统，所以，业务只需将日志记录下来，然后由日志分析系统去采集分析即可，Filebeat是ELK日志系统中常用的日志采集器，它是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。

软件下载：

  因经常遇到在内网搭建环境的问题，所以这里习惯使用下载软件包的方式进行安装，虽没有使用Yum、Docker等安装方便，但是可以对软件目录、配置信息等有更深的了解，在后续采用Yum、Docker等方式安装时，也能清楚安装了哪些东西，安装配置的文件是怎样的，即使出现问题，也可以快速的定位解决。

Elastic Stack全家桶下载主页： https://www.elastic.co/cn/downloads/

我们选择如下版本：

Kafka下载：

  安装前先准备好三台CentOS7服务器用于集群安装，这是IP地址为：172.16.20.220、172.16.20.221、172.16.20.222，然后将上面下载的软件包上传至三台服务器的/usr/local目录。因服务器资源有限，这里所有的软件都安装在这三台集群服务器上，在实际生产环境中，请根据业务需求设计规划进行安装。
  在集群搭建时，如果能够编写shell安装脚本就会很方便，如果不能编写，就需要在每台服务器上执行安装命令，多数ssh客户端提供了多会话同时输入的功能，这里一些通用安装命令可以选择启用该功能。

新建/usr/local/java目录

将下载的jdk软件包jdk-8u64-linux-x64.tar.gz上传到/usr/local/java目录，然后解压

配置环境变量/etc/profile

在底部添加以下内容

使环境变量生效

备注：后续可通过此命令停止elasticsearch运行

  新建kafka的日志目录和zookeeper数据目录，因为这两项默认放在tmp目录，而tmp目录中内容会随重启而丢失,所以我们自定义以下目录:

修改如下：

在data文件夹中新建myid文件，myid文件的内容为1（一句话创建：echo 1 > myid）

kafka启动时先启动zookeeper，再启动kafka；关闭时相反，先关闭kafka，再关闭zookeeper。
1、zookeeper启动命令

后台运行启动命令：

或者

查看集群状态：

2、kafka启动命令

后台运行启动命令：

或者

3、创建topic，最新版本已经不需要使用zookeeper参数创建。

参数解释:
复制两份
--replication-factor 2
创建1个分区
--partitions 1
topic 名称
--topic test

4、查看已经存在的topic（三台设备都执行时可以看到）

5、启动生产者：

6、启动消费者：

添加参数 --from-beginning 从开始位置消费，不是从最新消息

7、测试：在生产者输入test，可以在消费者的两台服务器上看到同样的字符test，说明Kafka服务器集群已搭建成功。

Logstash没有提供集群安装方式，相互之间并没有交互，但是我们可以配置同属一个Kafka消费者组，来实现统一消息只消费一次的功能。

  Filebeat用于安装在业务软件运行服务器，收集业务产生的日志，并推送到我们配置的Kafka、Redis、RabbitMQ等消息中间件，或者直接保存到Elasticsearch，下面来讲解如何安装配置：

1、进入到/usr/local目录，执行解压命令

2、编辑配置filebeat.yml
  配置文件中默认是输出到elasticsearch，这里我们改为kafka，同文件目录下的filebeat.reference.yml文件是所有配置的实例，可以直接将kafka的配置复制到filebeat.yml

后台启动命令

停止命令

2、测试logstash是消费Kafka的日志主题，并将日志内容存入Elasticsearch

自动新增的两个index，规则是logstash中配置的

数据浏览页可以看到Elasticsearch中存储的日志数据内容，说明我们的配置已经生效。

Gitee: GitEgg: GitEgg 是一款开源免费的企业级微服务应用开发框架，旨在整合目前主流稳定的开源技术框架，集成常用的最佳项目解决方案，实现可直接使用的微服务快速开发框架。
GitHub: https://github.com/wmz1930/GitEgg

⑨ 日志怎么文本 数据库 elk

日志怎么文本 数据库 elk
1、假设已经安装了MinGW，安装目录：C:/MinGW，将C:/MinGW/bin添加到系统环境变量中。如果闲下载安装MinGW麻烦，可以直接下载一个Dev-CPP或许Code::Blocks开发环境，这两个IDE中都是自带MinGW的。
2、下载eclipse-cpp-helios-SR2-win32.zip
3、安装opencv，假设安装目录为：C:/OpenCV
4、解压eclipse-cpp-helios-SR2-win32.zip，启动eclipse.exe
新建C++项目->可执行程序->Hello World C++ Project
5、添加头文件和库文件
右键项目选择“属性”->C/C++ Build->Settings。
Tool Settings 标签页，GCC C++ Compiler->Includes中添加OpenCV的头文件目录，MinGW C++ Linker->Libraries中添加OpenCV的库文件目录以及相应的库文件名称（注意：这里的库文件不加后缀名）

⑩ SpringBoot 整合 elk

一、elk 简介

二、elk的安装

我们采用的 docker 镜像安装。

由于sebp/elk中logstash的input的方式默认是filebeat,首先们需要进入elk容器中修改input方式。logstash默认会将etc/logstash/conf.d/中的配置文件进行整合然后启动。

修改 02-beats-input.conf 文件，修改如下：

保存后，我们使用 control + P + Q 退出容器。然后重启容器，让我们的配置生效。

我们访问http://127.0.0.1:5601

三、创建工程

创建工程springboot-elk ，并使用logback 记录日志。

1. pom.xml

2. 启动类

3. logback-spring.xml

启动工程，日志会存入elasticsearch中，通过Kibana 的web界面，配置后，我们就可看到，下面我简单的修改下配置。

三、配置 pattern

配置 pattern 输入*，匹配所有数据。

选择时间@timestamp，这样数据展示会以时间排序

好了 ，点击discover，就可以看到我们springboot-elk项目的日志信息了。