日志系统（FileBeats+elasticSearch+Kibana）
FileBeats+elasticSearch+Kibana 统一版本 7.3.2
环境：window10 64位
FileBeats
filebeat中文指南：https://elkguide.elasticsearch.cn/elasticsearch/performance/bulk.html
什么是FileBeats？
轻量级的日志处理工具
在你的服务器上安装客户端后，filebeat会监控日志目录或者指定的日志文件，追踪读取这些文件（追踪文件的变化，不停的读），并且转发这些信息到elasticsearch或者logstarsh中存放
官方文档：elastic.co/guide/en/beats/filebeat/current/filebeat-installation.html
下载压缩包zip格式 版本7.3.2
安装步骤：
-
从下载页面下载Filebeat Windows zip文件 。
-
将zip文件的内容解压缩到
C:\Program Files。 -
将
filebeat-<version>-windows目录重命名为Filebeat。 -
windows10 自带有windows PowerShell,直接在左下角搜索框中输入PowerShell，直接打开（默认管理员权限）/以管理员身份打开PowerShell （右键单击PowerShell图标，然后选择“以管理员身份运行”）
-
在PowerShell提示符下，运行以下命令将Filebeat安装为Windows服务：
进入安装目录下：
PS > cd 'C:\Program Files\Filebeat' PS C:\Program Files\Filebeat> .\install-service-filebeat.ps1
注意：如果在系统上禁用了脚本执行，则需要为当前会话设置执行策略以允许脚本运行:
PowerShell.exe -ExecutionPolicy UnRestricted -File .\install-service-filebeat.ps1`。
filebeat.yml配置：
filebeat.inputs:
- type: log
enabled: true
#定义日志文件的路径
paths:
#默认配置位置
- D:\filebeat\var\log\*.log
#- D:\log\*.log
#- c:\programdata\elasticsearch\logs\*
此示例中的输入收集路径中的所有文件D:\filebeat\var\log\*.log，这意味着Filebeat将收集目录/var/log/结尾的所有文件.log`。
测试是否读到文件并输出到filebeat临时文件：
注意：输出文件名称是默认的，可以自己改动
加入配置：
output.file:
path: "D:/filebeat/logs/"
filename: filebeat
rotate_every_kb: 10240
number_of_files: 7
permissions: 0600
关闭连接elasticSearch的输出
#output.elasticsearch:
# Array of hosts to connect to.
# hosts: ["localhost:9200"]
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme"
注意：不能没有输出，也不能配置多个输出 否则filebeat启动不了
filebeat原理：
Filebeat包含两个主要组件：input[输入]和harvester[收割机/收集器]。这些组件一起工作以尾部文件并将事件数据发送到您指定的输出。
缺点：
filebeat官方提供的功能比较单一，往往无法满足我们的需求（比如说允许写入Redis但不允许从Reids中读出来，若需要读则需要借助logstash这样笨重的组件。不允许写到Metaq/rabbitmq一类的中间件做消息存储以缓解ES端的压力）
filebeat的性能瓶颈在publish层面。也就是write to es的效率不尽如人意。
什么是harvester？
harvester负责读取单个文件的内容。收割机逐行读取每个文件，然后将内容发送到输出。每个文件启动一个harvester。harvester负责打开和关闭文件，这意味着在harvester运行时文件描述符保持打开状态。如果在收集文件时将其删除或重命名，Filebeat将继续读取该文件。这样做的副作用是磁盘上的空间将保留，直到收割机关闭为止。默认情况下，Filebeat保持文件打开直到close_inactive到达。
关闭收割机有以下后果：
-
关闭文件处理程序，如果在收割机仍在读取文件时删除了文件，则释放了基础资源。
-
只有在
scan_frequency经过之后，才会再次开始文件的收集。 -
如果在harvester关闭时移动或删除文件，则文件的收割将不会继续。
什么是输入？
输入负责管理harvester并查找所有可读取的资源。
指定类型例如：log,则输入将在驱动器上找到与定义的全局路径匹配的所有文件，并为每个文件启动harvester。每个输入都在其自己的Go例程中运行。
如果自harvester关闭，原来文件的大小已更改，则仅拾取新行。不会再从头读取。
filebeat如何保持文件的状态？
Filebeat保留每个文件的状态，并经常将状态刷新到注册表文件中的磁盘。 该状态用于记住harvester正在读取的最后一个偏移量，并确保发送所有日志行。如果无法到达输出（例如Elasticsearch或Logstash），则Filebeat会跟踪发送的最后几行，并在输出再次变为可用时继续读取文件(重新开启输入，则会继续读取文件)。在Filebeat运行时，状态信息也保存在内存中，用于每个输入。重新启动Filebeat时，将使用注册表文件中的数据来重建状态，并且Filebeat会在最后一个已知位置继续每个harvester。
Filebeat检测文件是否被扫描：对于每个输入，Filebeat会保留找到的每个文件的状态。由于可以重命名或移动文件，因此文件名和路径不足以标识文件。对于每个文件，Filebeat都存储唯一的标识符以检测文件是否以前被收获过。
ignore_older
如果启用此选项，Filebeat将忽略在指定时间范围之前修改的所有文件。ignore_older如果长时间保留日志文件，则配置特别有用。例如，如果要启动Filebeat，但只想发送最新的文件和上周的文件，则可以配置此选项。
必须设置ignore_older为大于close_inactive
受此设置影响的文件分为两类：
-
从未收集过的文件
-
收获但未更新的文件的时间不超过 ignore_older
对于以前从未见过的文件，偏移状态设置为文件末尾。如果状态已经存在，则偏移量不会更改。如果以后再次更新文件，则在设置的偏移位置继续读取。
该ignore_older设置取决于文件的修改时间，以确定是否忽略文件。如果将行写入文件时文件的修改时间未更新（在Windows上ignore_older可能会发生），即使稍后添加了内容，此 设置也可能导致Filebeat忽略文件。
要从注册表文件中删除先前收集的文件的状态，请使用clean_inactive配置选项。
在使用Filebeat忽略文件之前，必须先关闭该文件。为确保在忽略文件时不再收集文件，您必须将ignore_older持续时间设置 为长于close_inactive。
如果当前正在收集的文件属于ignore_older，则收集器将首先完成读取文件并在close_inactive 到达后将其关闭。然后，此后，该文件将被忽略
您可以使用2h（2小时）和5m（5分钟）之类的时间字符串。默认值为0，这将禁用设置。注释掉配置与将其设置为0具有相同的效果。
如果用例涉及每天创建大量新文件，则可能会发现注册表文件变得太大？
官方推荐使用配置：
为了减小注册表文件的大小，有两个可用的配置选项：clean_removed和clean_inactive
对于您不再碰触而被忽略的旧文件（请参阅参考资料ignore_older），我们建议您使用clean_inactive。如果从磁盘中删除了旧文件，请使用该clean_removed选项。
close_*
配置选项用于之后的某一标准或时间以关闭harvester。
关闭收割机意味着关闭文件处理程序。如果在关闭harvester之后更新文件，则文件将在scan_frequency经过后再次被拾取。但是，如果在harvester关闭时移动或删除文件，Filebeat将无法再次拾取该文件，并且收割机尚未读取的任何数据都将丢失。
close_*当Filebeat尝试从文件读取时，这些设置将同步应用，这意味着如果Filebeat由于输出阻塞，完整队列或其他问题而处于阻塞状态，则本应关闭的文件保持打开状态，直到Filebeat再次尝试读取从文件中。(注:如果出现输出阻塞问题，或者是其他问题导致处于阻塞状态，则文件保持打开状态，直到再次尝试读取文件内容。)
clean_inactive
启用此选项后，如果在指定时间内未收获文件，则Filebeat将关闭文件句柄。当收获机读取了最后一条日志行时，定义周期的计数器开始计数。它不是基于文件的修改时间。如果关闭的文件再次更改，则将启动新的harvester，并且在scan_frequency经过之后将获取最新的更改 。
我们建议您将其设置close_inactive为大于最不频繁更新日志文件的值。例如，如果您的日志文件每隔几秒钟更新一次，则可以安全地设置close_inactive为1m。如果存在更新率差异很大的日志文件，则可以使用具有不同值的多种配置。
设置close_inactive较低的值意味着文件句柄将尽快关闭。但是，这样做的副作用是，如果关闭harvester，则不会实时发送新的日志行。
关闭文件的时间戳与文件的修改时间无关。而是，Filebeat使用内部时间戳记来反映上次收获文件的时间。例如，如果close_inactive设置为5分钟，则在收割机读取文件的最后一行之后，开始5分钟的倒计时。
您可以使用2h（2小时）和5m（5分钟）之类的时间字符串。默认值为5m。
close_renamed
仅当您了解数据丢失是潜在的副作用时，才使用此选项。
启用此选项后，Filebeat在重命名文件时关闭文件处理程序。例如，在旋转文件时会发生这种情况。默认情况下，harvester保持打开状态并继续读取文件，因为文件处理程序不依赖于文件名。如果close_renamed启用了该选项，并且文件的重命名或移动方式与为其指定的文件模式不再匹配，则不会再次提取该文件。Filebeat将无法完成文件读取。
WINDOWS：如果Windows日志循环系统由于无法旋转文件而显示错误，则应启用此选项。
close_removed
启用此选项后，Filebeat将在删除文件时关闭harvester。通常，仅当文件在所指定的时间内处于非活动状态后才应将其删除close_inactive。但是，如果文件过早删除而您未启用close_removed，则Filebeat会将文件保持打开状态以确保harvester已经完成。如果此设置导致文件由于过早从磁盘中删除而无法完全读取，请禁用此选项。
默认情况下启用此选项。如果禁用此选项，则还必须禁用clean_removed。
WINDOWS：如果Windows日志循环系统由于无法旋转文件而显示错误，请确保启用此选项。
close_eof
仅当您了解数据丢失是潜在的副作用时，才使用此选项。
启用此选项后，一旦到达文件末尾，Filebeat就会关闭文件。当您的文件仅写入一次且不时更新时，此功能很有用。例如，当您将每个日志事件写入新文件时，就会发生这种情况。默认情况下禁用此选项
close_timeout
仅当您了解数据丢失是潜在的副作用时，才使用此选项。另一个副作用是，多行事件可能不会在超时到期之前完全发送出去.
启用此选项后，Filebeat会为每个收割机提供预定义的生存期。无论阅读器在文件中的何处，经过close_timeout一段时间后，阅读都会停止。当您只想在文件上花费预定义的时间时，此选项对于较旧的日志文件很有用。虽然close_timeout将在预定义的超时后关闭文件，但是如果文件仍在更新中，则Filebeat将根据定义的再次启动新的收割机scan_frequency。并且此收割机的close_timeout将以超时倒数再次开始。
如果输出被阻止，此选项特别有用，这使Filebeat甚至对于从磁盘上删除的文件，也保持打开的文件处理程序。进行设置close_timeout以5m确保定期关闭文件，以便操作系统可以释放它们。
如果设置close_timeout为equal ignore_older，则在关闭收割机的情况下修改文件时将不会拾取该文件。设置的这种组合通常会导致数据丢失，并且不会发送完整的文件。
当您使用close_timeout包含多行事件的日志时，收割机可能会在多行事件的中间停止，这意味着将仅发送部分事件。如果收割机再次启动并且文件仍然存在，则仅发送事件的第二部分。
默认情况下，此选项设置为0，表示已禁用
clean_*
选项用于清除注册表文件中的状态条目。这些设置有助于减小注册表文件的大小，并可以防止潜在的inode重用问题。
clean_inactive
仅当您了解数据丢失是潜在的副作用时，才使用此选项。
启用此选项后，经过指定的非活动时间后，Filebeat会删除文件的状态。仅当Filebeat已忽略该文件（文件早于ignore_older）时，才能删除状态 。该clean_inactive设置必须大于ignore_older + scan_frequency要确保在仍在收集文件的同时不删除任何状态。否则，该设置可能导致Filebeat不断重新发送全部内容，因为 clean_inactive删除了Filebeat仍检测到的文件的状态。如果文件已更新或再次出现，则会从头开始读取文件。
该clean_inactive配置选项是有用的，以减少注册表文件的大小，特别是如果每天都在产生大量的新文件。
此配置选项对于防止因Linux上的inode重用而导致的Filebeat问题也很有用。有关更多信息，请参见Inode重用导致Filebeat跳过行。
每次重命名文件时，文件状态都会更新，计数器的计数器将clean_inactive再次从0开始。
在测试期间，您可能会注意到注册表包含应根据clean_inactive设置删除的状态条目。发生这种情况是因为Filebeat直到再次打开注册表以读取其他文件时才删除条目。如果要测试clean_inactive设置，请确保Filebeat配置为从多个文件中读取，否则文件状态永远不会从注册表中删除。
clean_removed
启用此选项后，如果在磁盘上找不到以最后一个已知名称命名的文件，则Filebeat将从注册表中清除文件。这意味着在收割机完成后重命名的文件也将被删除。默认情况下启用此选项。
如果共享驱动器在短时间内消失并再次出现，则将从头开始再次读取所有文件，因为状态已从注册表文件中删除。在这种情况下，建议您禁用该clean_removed 选项。
如果还禁用，则必须禁用此选项close_removed
scan_frequency
Filebeat多久检查一次指定用于收集的路径中的新文件。例如，如果您指定一个glob如/var/log/*，则使用所指定的频率扫描目录中的文件 scan_frequency。指定1可以尽可能频繁地扫描目录，而不会导致Filebeat频繁扫描。我们不建议设置此值<1s。
如果您需要近乎实时地发送日志行，请不要设置太低， scan_frequency而要进行调整，close_inactive以使文件处理程序保持打开状态并不断轮询文件。
默认设置为10秒。
scan.sort
此功能是试验性的，在将来的版本中可能会完全更改或删除。Elastic会尽力解决所有问题，但是实验性功能不受官方GA功能的支持SLA约束。
如果您为此设置指定了空字符串以外的其他值，则可以使用确定使用升序还是降序scan.order。可能的值为modtime和filename。要按文件修改时间排序，请使用modtime，否则请使用filename。将此选项留空可将其禁用。
如果为此设置指定一个值，则可以scan.order用来配置文件是按升序还是降序扫描。
默认设置为禁用。
scan.order
此功能是试验性的，在将来的版本中可能会完全更改或删除。Elastic会尽力解决所有问题，但是实验性功能不受官方GA功能的支持SLA约束。
scan.sort设置为无时，指定使用升序还是降序。可能的值为asc或desc。
默认设置为asc。
tail_files
如果此选项设置为true，Filebeat将在每个文件的末尾而不是开头开始读取新文件。如果将此选项与日志轮换结合使用，则可能会跳过新文件中的第一个日志条目。默认设置为false。
此选项适用于Filebeat尚未处理的文件。如果您以前运行过Filebeat，并且文件的状态已经保留，tail_files则将不适用。收获将在先前的偏移量处继续进行。若要应用于tail_files所有文件，必须停止Filebeat并删除注册表文件。请注意，这样做会删除所有以前的状态。
首次在一组日志文件上运行Filebeat时，可以使用此设置来避免索引旧的日志行。首次运行后，建议禁用此选项，否则您可能会在文件轮换期间丢失行。
symlinks
该symlinks选项允许Filebeat除常规文件外还收获符号链接。收集符号链接时，即使文件报告了符号链接的路径，Filebeat也会打开并读取原始文件。
配置用于收获的符号链接时，请确保原始路径已排除。如果将单个输入配置为同时收集符号链接和原始文件，则Filebeat将检测到该问题，并且仅处理找到的第一个文件。但是，如果配置了两个不同的输入（一个用于读取符号链接，另一个用于读取原始路径），则将同时获取两个路径，从而导致Filebeat发送重复的数据，并且输入覆盖彼此的状态。
symlinks如果指向日志文件的符号链接在文件名中包含其他元数据，并且您要在Logstash中处理元数据，则该选项很有用。例如，Kubernetes日志文件就是这种情况。
由于此选项可能会导致数据丢失，因此默认情况下它被禁用。
backoff
退避选项指定Filebeat如何主动搜索打开的文件以进行更新。在大多数情况下，您可以使用默认值。
该backoff选项定义到达EOF后Filebeat在再次检查文件之前等待的时间。默认值为1s，这意味着如果添加了新行，则每秒检查一次文件。这可以实现近实时爬网。每当文件中出现新行时，该backoff值都会重置为初始值。默认值为1s。
max_backoff
达到EOF后Filebeat等待再次检查文件的最长时间。从检查文件中退回多次之后，max_backoff无论为指定了什么 ，等待时间都不会超过backoff_factor。因为读取新行最多需要10s，所以将10s指定为max_backoff表示在最坏的情况下，如果Filebeat多次退出，则可能会将新行添加到日志文件中。默认值为10秒。
要求：设置max_backoff为大于backoff或等于scan_frequency（backoff <= max_backoff <= scan_frequency）。如果max_backoff需要更高，建议改为关闭文件处理程序，然后让Filebeat再次提取文件。
backoff_factor
此选项指定增加等待时间的速度。退避系数越大，max_backoff达到该值的速度就越快。退避因子呈指数增加。允许的最小值是1。如果将此值设置为1，则会禁用退避算法，并且该backoff值将用于等待新行。backoff每次将数值乘以backoff_factor直到max_backoff。预设值为2。
harvester_limit
该harvester_limit选项限制了针对一个输入并行启动的harvester的数量。这直接与打开的文件处理程序的最大数量有关。默认harvester_limit值为0，表示没有限制。如果要收集的文件数超过操作系统的打开文件处理程序限制，则此配置很有用。
限制收割机的数量意味着可能不会并行打开所有文件。因此，我们建议您将此选项与选项结合使用，close_*以确保更频繁地停止收割机，以便可以拾取新文件。
当前，如果可以再次启动新的收割机，则随机选择收割机。这意味着可能会启动刚刚关闭然后再次更新的文件的收集器，而不是较长时间未收集的文件的收集器。
此配置选项适用于每个输入。您可以使用此选项通过分配更高的收割机限制来间接为某些输入设置更高的优先级。
tags
Filebeat包含在tags每个已发布事件的字段中的标签列表。使用标记，可以轻松地在Kibana中选择特定事件或在Logstash中应用条件过滤。这些标签将被添加到常规配置中指定的标签列表中。
filebeat.inputs:
- type: log
. . .
tags: ["json"]
fields
您可以指定可选字段以将其他信息添加到输出中。例如，您可以添加可用于过滤日志数据的字段。字段可以是标量值，数组，字典或它们的任何嵌套组合。默认情况下，您在此处指定的字段将被分组fields到输出文档中的子词典下。要将自定义字段存储为顶级字段，请将fields_under_root选项设置为true。如果在常规配置中声明了重复字段，则其值将被此处声明的值覆盖。
filebeat.inputs:
- type: log
. . .
fields:
app_id: query_engine_12
fields_under_root
如果将此选项设置为true，则自定义 字段将作为顶级字段存储在输出文档中，而不是分组在fields子词典下。如果自定义字段名称与Filebeat添加的其他字段名称冲突，则自定义字段将覆盖其他字段
processors
应用于输入数据的处理器列表。
请参阅过滤和增强导出的数据，以获取有关在配置中指定处理器的信息。
pipeline
要为此输入生成的事件设置的接收节点管道ID。
也可以在Elasticsearch输出中配置管道ID，但是此选项通常会导致配置文件更简单。如果在输入和输出中都配置了管道，则使用输入中的选项。
filebeat.yml配置：
file beat 输出到elasticsearch集群：
setup.template.settings:
index.number_of_shards: 3 #指定索引的分片
output.elasticsearch: #输出到elasticsearch集群，没用集群就写本机或者一个就行了
hosts: ["127.0.0.1:9300","127.0.0.1:9301","127.0.0.1:9302"]
##输出到console
#output.console:
# pretty: true
# enable: true
filebeat断电异常关闭，会自动修改yml文件的 enabled: true属性为false，请注意查看
filebeat.yml详细配置：
###################### Filebeat Configuration Example #########################
# This file is an example configuration file highlighting only the most common
# options. The filebeat.reference.yml file from the same directory contains all the
# supported options with more comments. You can use it as a reference.
#
# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/filebeat/index.html
# For more available modules and options, please see the filebeat.reference.yml sample
# configuration file.
#=========================== Filebeat inputs =============================
filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
encoding: utf-8
include_lines: ['ERROR','WARN','INFO']
#输入在指定路径中检查新文件的频率
scan_frequency: "5s"
#如果tail_files设置为true, Filebeat从文件尾开始监控文件新增内容把新增的每一行文件作为一个事件依次发送而不是从文件开始处重新发送所有内容。但最后一条是不会读取的
tail_files: false
# 每 1 秒检测一次文件是否有新的一行内容需要读取
backoff: "1s"
#定义每个收割机在获取文件时使用的缓冲区大小
harvester_buffer_size: 16384 #40960000
# Paths that should be crawled and fetched. Glob based paths.
paths:
#- /var/log/*.log
#- c:\programdata\elasticsearch\logs\*
- E:\IDEA_project\logdemo\logs\*.log
# Exclude lines. A list of regular expressions to match. It drops the lines that are
# matching any regular expression from the list.
#exclude_lines: ['^DBG']
# Include lines. A list of regular expressions to match. It exports the lines that are
# matching any regular expression from the list.
#include_lines: ['^ERR', '^WARN']
# Exclude files. A list of regular expressions to match. Filebeat drops the files that
# are matching any regular expression from the list. By default, no files are dropped.
#exclude_files: ['.gz$']
# Optional additional fields. These fields can be freely picked
# to add additional information to the crawled log files for filtering
#fields:
# level: debug
# review: 1
### Multiline options
# Multiline can be used for log messages spanning multiple lines. This is common
# for Java Stack Traces or C-Line Continuation
# The regexp Pattern that has to be matched. The example pattern matches all lines starting with [
#multiline.pattern: ^\[
# Defines if the pattern set under pattern should be negated or not. Default is false.
#multiline.negate: false
# Match can be set to "after" or "before". It is used to define if lines should be append to a pattern
# that was (not) matched before or after or as long as a pattern is not matched based on negate.
# Note: After is the equivalent to previous and before is the equivalent to to next in Logstash
#multiline.match: after
#============================= Filebeat modules ===============================
filebeat.config.modules:
# Glob pattern for configuration loading
path: ${path.config}/modules.d/*.yml
# Set to true to enable config reloading
reload.enabled: false
# Period on which files under path should be checked for changes
#reload.period: 10s
#==================== Elasticsearch template setting ==========================
setup.template.settings:
index.number_of_shards: 5
#index.codec: best_compression
#_source.enabled: false
#================================ General =====================================
# The name of the shipper that publishes the network data. It can be used to group
# all the transactions sent by a single shipper in the web interface.
#name:
# The tags of the shipper are included in their own field with each
# transaction published.
#tags: ["service-X", "web-tier"]
# Optional fields that you can specify to add additional information to the
# output.
#fields:
# env: staging
#============================== Dashboards =====================================
# These settings control loading the sample dashboards to the Kibana index. Loading
# the dashboards is disabled by default and can be enabled either by setting the
# options here or by using the `setup` command.
#setup.dashboards.enabled: false
# The URL from where to download the dashboards archive. By default this URL
# has a value which is computed based on the Beat name and version. For released
# versions, this URL points to the dashboard archive on the artifacts.elastic.co
# website.
#setup.dashboards.url:
#============================== Kibana =====================================
# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
setup.kibana:
# Kibana Host
# Scheme and port can be left out and will be set to the default (http and 5601)
# In case you specify and additional path, the scheme is required: http://localhost:5601/path
# IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
#host: "localhost:5601"
#kibana 地址
host: "localhost:5601"
# Kibana Space ID
# ID of the Kibana Space into which the dashboards should be loaded. By default,
# the Default Space will be used.
#space.id:
#============================= Elastic Cloud ==================================
# These settings simplify using Filebeat with the Elastic Cloud (https://cloud.elastic.co/).
# The cloud.id setting overwrites the `output.elasticsearch.hosts` and
# `setup.kibana.host` options.
# You can find the `cloud.id` in the Elastic Cloud web UI.
#cloud.id:
# The cloud.auth setting overwrites the `output.elasticsearch.username` and
# `output.elasticsearch.password` settings. The format is `<user>:<pass>`.
#cloud.auth:
#================================ Outputs =====================================
# Configure what output to use when sending the data collected by the beat.
#-------------------------- Elasticsearch output ------------------------------
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["localhost:9200"]
#单个ElasticSearch批量API索引请求中要批量处理的最大事件数 默认50
bulk_max_size: 18000
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme"
#----------------------------- Logstash output --------------------------------
#output.logstash:
# The Logstash hosts
#hosts: ["localhost:5044"]
# Optional SSL. By default is off.
# List of root certificates for HTTPS server verifications
#ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
# Certificate for SSL client authentication
#ssl.certificate: "/etc/pki/client/cert.pem"
# Client Certificate Key
#ssl.key: "/etc/pki/client/cert.key"
#================================ Processors =====================================
# Configure processors to enhance or manipulate events generated by the beat.
processors:
- drop_fields:
fields: ["log","input","host","agent","@metadata","ecs"]
- add_host_metadata: ~
- add_cloud_metadata: ~
#================================ Logging =====================================
# Sets log level. The default log level is info.
# Available log levels are: error, warning, info, debug
#logging.level: debug
# At debug level, you can selectively enable logging only for some components.
# To enable all selectors use ["*"]. Examples of other selectors are "beat",
# "publish", "service".
#logging.selectors: ["*"]
#============================== Xpack Monitoring ===============================
# filebeat can export internal metrics to a central Elasticsearch monitoring
# cluster. This requires xpack monitoring to be enabled in Elasticsearch. The
# reporting is disabled by default.
# Set to true to enable the monitoring reporter.
#monitoring.enabled: false
# Sets the UUID of the Elasticsearch cluster under which monitoring data for this
# Filebeat instance will appear in the Stack Monitoring UI. If output.elasticsearch
# is enabled, the UUID is derived from the Elasticsearch cluster referenced by output.elasticsearch.
#monitoring.cluster_uuid:
# Uncomment to send the metrics to Elasticsearch. Most settings from the
# Elasticsearch output are accepted here as well.
# Note that the settings should point to your Elasticsearch *monitoring* cluster.
# Any setting that is not set is automatically inherited from the Elasticsearch
# output configuration, so if you have the Elasticsearch output configured such
# that it is pointing to your Elasticsearch monitoring cluster, you can simply
# uncomment the following line.
#monitoring.elasticsearch:
#================================= Migration ==================================
# This allows to enable 6.7 migration aliases
#migration.6_to_7.enabled: true
更多细节配置，请查阅官方文档：elastic.co/guide/en/beats/filebeat/current/filebeat-installation.html
出现问题：filebeat 输出到集群，加载不了默认索引模板，暂时未知，
Elasticsearch
elasticSearch中文文档：https://es.xiaoleilu.com/
官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/6.0/getting-started.html
安装参考博客：https://blog.csdn.net/dulei17816/article/details/92624185
干货：https://www.cnblogs.com/xing901022/p/4967796.html
查询参考：
https://segmentfault.com/a/1190000019446507
https://www.cnblogs.com/leeSmall/p/9215909.html
Elasticsearch是一个基于Apache Lucene(TM)的开源搜索引擎，
Lucene只是一个库，必须使用Java来作为开发语言并将其直接集成到你的应用中，
Lucene非常复杂，需要深入了解检索的相关知识来理解它是如何工作的
Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。
Elasticsearch不仅仅是Lucene和全文搜索；
-
分布式的实时文件存储，每个字段都被索引并可被搜索
-
分布式的实时分析搜索引擎
-
可以扩展到上百台服务器，处理PB级结构化或非结构化数据
所有的这些功能被集成到一个服务里面，你的应用可以通过简单的RESTful API、各种语言的客户端甚至命令行与之交互。
开箱即用（安装即可使用）。
运行cmd进入命令界面 : 进入安装目录
运行以下命令：
前端启动：
cd D:\elasticsearch-7.3.2\bin
D:\elasticsearch-7.3.2\bin>.\elasticsearch.bat
后端启动：
cd D:\elasticsearch-7.3.2\bin
D:\elasticsearch-7.3.2\bin>.\elasticsearch.bat -d
后端启动是没有信息的。
启动完成后，打开浏览器访问http://localhost:9200/
出现以下画面则启动成功
安装elastic search-head:
最简单的安装方式：charmed 插件；
在谷歌商店可以直接搜索elastic search-head进行安装，安装完成即可使用。
要有翻墙工具：安装谷歌助手之类的工具可以翻墙
REST API:
postman 工具进行发送请求：
例如创建索引：注意发送格式为application/json
test为索引名称
请求类型为：PUT
##创建索引
插入数据：
进入要插入数据的索引下：http://localhost:9200/test/log/
test为索引名称
log 为数据类型
请求类型为：POST
进入elastic search-head进行数据查看：
添加成功!
我们可以指定数据唯一标识_Id 指定之后就不会是随机字符串了，例如： http://localhost:9200/test/log/1001
示例是没有指定的，默认随机生成
update:
在elastic search中数据是不能修改的，只能通过全面覆盖的方式进行修改。
但是我们要的是局部数据更新：
这个内部就要操作四步：
1、检索出旧文档的json数据
2、修改数据
3、删除旧文档数据
4、索引新文档
示例：
发送方式：POST
http://localhost:9200/test/log/fReHa20B9aDxYvXTaFY1/_update
注意:是 _update
不能直接传递参数，需要使用doc进行包装，否在会发生400数据传输错误
{
"doc":{
"level":"error"
}
}
每次的操作 对应数据的 版本也会增加
删除一条不存在的数据，会出现404，响应解结果也会提示 not found
删除一条数据并不会马上从磁盘上删除，而是被标记成删除状态，因为内部是批量删除，也就是说会等更多的删除操作，或者时间预定时间，
查询数据：
查询指定数据根据Id查询
发送方式：GET
http://localhost:9200/test/log/fReHa20B9aDxYvXTaFY1
查询全部数据：注意 是 _search
http://localhost:9200/test/log/_search
关键字搜索：
http://localhost:9200/test/log/_search?q=age:20之类的
DSL搜索：
DSL查询(Query DSL(Domain Specific Language 特定领域语言)),允许构建更加复杂、强大的查询， 以json形式的请求体出现。
发送方式：POST
http://localhost:9200/test/log/_search
带参，json格式：
{
"query":{
"bool":{
#过滤
"filter":{
"range":{#范围
"sort":{
# gt 大于
"gt"：时间戳
}
}
},
# 必须匹配的
"must":{
"match":{ #match只是查询的一种
"level":"error"
}
}
}
}
}
高亮显示：只需要在query后面添加即可
{
"query":{
"bool":{
"must":{
"match":{
"level":"info"
}
}
}
},
"highlight":{
"fields":{
"level":{
}
}
}
}
聚合查询：
{
"aggs":{
"all_interests": {
"terms": {
"field":"level"
}
}
}
}
出现错误：
Fielddata is disabled on text fields by default. Set fielddata=true on [level] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead."
对排序和聚合等操作，用单独的数据结构(fielddata)缓存到内存里了，默认是不开启的，需要单独开启。
Fielddata可以消耗大量的堆空间，特别是在加载高基数text字段时。一旦fielddata被加载到堆中，它将在该段的生命周期中保持在那里。此外，加载fielddata是一个昂贵的过程，可以导致用户体验延迟命中。这就是为什么fielddata默认是禁用的
推荐：使用my_field.keyword字段进行聚合，排序
删除索引：
只需要进入到要删除的索引： http://localhost:9200/test/
发送类型为：DELETE
批量操作：
批量查询:
发送请求：POST
URL:http://localhost:9200/filebeat-7.3.2-2019.09.25-000001/_doc/_mget
注意：是 _mget _doc 都带有下划线
{
"ids":["R6BnZ20Bxr3L20nFhohK","SaBnZ20Bxr3L20nFhohK"]
}
_bulk操作：
Elasticsearch 中支持 批量插入，修改、删除等操作都是通过 _bulk得api操作得
请求方式：PUT
请求格式如下：
注意后面 \n
{action :{metadata}}\n
{request body}\n
{action :{metadata}}\n
{request body}\n
批量插入数据示例：
{"create":{"_index":"test","_type":"log"}}
{"type":"log","message":"你个渣渣","level":"info","date":"2019-9-27"}
最后一行要有空行
批量删除：
{"delete":{"_index":"test","_type":"log","_id":"fhdhbG0B9aDxYvXThFYe"}}
{"delete":{"_index":"test","_type":"log","_id":"gBdrbG0B9aDxYvXTJFb"}}
{"delete":{"_index":"test","_type":"log","_id":"fReHa20B9aDxYvXTaFY1"}}
同样最后回车留一行空白行
创建明确类型得索引：
发送方式：PUT
url: http://localhost:9200/test/
"analyzer":"ik_max_word" 中文分词
{
"settings":{
"index":{
"number_of_shards":"2"，
"number_of_replicas":"0"
}
},
"mappings":{
"properties":{
"name":{
"type":"text"
},
"age":{
"type":"integer"
},
"mail":{
"type":"keyword"
},
"hobby":{
"type":"text",
"analyzer":"ik_max_word"
},
"date":{
"type":"text"
}
}
}
}
查看映射：
发送GET请求，
url:http://localhost:9200/test/_mapping
注意：是 _mapping
插入数据：
_bulk操作
{"index":{"_index":"test","_type":"person"}}
{"name":"王发发","age":"120","mail":"[email protected]","hobby":"打豆豆，唱歌","date":"2019-9-27"}
{"index":{"_index":"test","_type":"person"}}
{"name":"王水水","age":"119","mail":"[email protected]","hobby":"打游戏，唱歌","date":"2019-9-27"}
结构化查询：
term主要用于精确匹配一些值，比如说 日期，数字，布尔值，或者not_analyzed的字符串（未经分析的文本数据类型）
示例：
发送POST请求
json格式
{
"query":{
"term":{
"age":"20"
}
}
}
terms查询：
与term有点类似，但是terms允许指定多个匹配条件，如果某个字段指定了多个值，那么文档需要一起去做匹配：
{
"query":{
"terms":{
"age":[20,21,23]
}
}
}
范围操作符：
gt:: 大于
gte:: 大于等于
lt:: 小于
lte:: 小于等于
示例：
{
"query":{
"range":{
"age":{
"gte": 10,
"lte": 30
}
}
}
}
exists查询：
exists 查询可以用于查找文档中是否包含指定字段或没有包含某个字段，类似于sql语句中的is_null条件
{
"query":{
"exists": {#必须包含
"field":"age"
}
}
}
match查询：
一个标准查询，不管你需要全文吧查询还是精确查询，基本上都要使用它。如果你使用match查询一个全文吧字段，它会再真正查询之前用分析器先分析match一下查询字符：
{
"query":{
"match":{
"age": 10
}
}
}
如果用match下指定一个确定值，在遇到数字、日期或者布尔值、或者not_analyzed的字符串时，它将为你搜索给定的值
bool查询：
bool查询可以用来合并多个条件查询结果的逻辑，
包含以下操作符：
must: 多个查询条件的完全匹配，相当于and
must_not:多个查询条件的相反匹配，相当于not
should: 至少有一个查询条件匹配，相当于or
这些参数可以分别继承一个查询条件或者一个查询条件的数组：
{
"query":{
"bool":{
"must":{
"hobby":"打游戏"
},
"must_not":{
"match":{
"hobby":"打豆豆"
}
}
}
}
}
过滤查询：
{
"query":{
"bool":{
"filter":{
"term":{
"age": 20
}
}
}
}
}
查询和过滤的对比：
一条过滤语句会询问每个文档的字段值是否包含特定值
查询语句会询问每个文档的字段值于特定值的匹配程度如何，一条查询语句会计算每个文档于查询语句的相关性，会给出一个相关性评分_score,并且按照相关性对匹配到的文档进行排序，这种评分方式非常适用于一个没有完全配置结果的全文搜索。
一个简单的文档列表，快速匹配运算并存入内存是十分方便的，每个文档仅需要1个字节，这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
查询语句不仅要查找相匹配的文档，还需要计算每个文档的相关性，所以一般来说查询语句比过滤语句更耗时，查询的结果也不可以缓存。
结论：在做精确匹配搜索时，最好使用过滤语句，过滤语句可以缓存数据。
加入中文分词，默认不支持中文
参考安装IKAnalyzer插件：https://blog.csdn.net/wolfcode_cn/article/details/81907220
下载对应的IKAnalyzer版本：https://github.com/medcl/elasticsearch-analysis-ik/releases
编译了的elasticsearch-analysis-ik-7.3.2.zip
在elasticsearch安装目录下的D:\elasticsearch-7.3.2\plugins里
将解压的所有文件放进去，重启就可以看到加载信息
测试：
发送方式： POST
url: http://localhost:9200/_analyze 格式：application/json
analyzer： 指定分词器名称 ik_max_word
{
"analyzer":"ik_max_word",
"text":"我是中国人"
}
结果：
{
"tokens": [
{
"token": "我",
"start_offset": 0,
"end_offset": 1,
"type": "CN_CHAR",
"position": 0
},
{
"token": "是",
"start_offset": 1,
"end_offset": 2,
"type": "CN_CHAR",
"position": 1
},
{
"token": "中国人",
"start_offset": 2,
"end_offset": 5,
"type": "CN_WORD",
"position": 2
},
{
"token": "中国",
"start_offset": 2,
"end_offset": 4,
"type": "CN_WORD",
"position": 3
},
{
"token": "国人",
"start_offset": 3,
"end_offset": 5,
"type": "CN_WORD",
"position": 4
}
]
}
效果符合预期。
全文单词搜索：
url: http://localhost:9200/test/_doc/_search
发送方式 ：POST
highlight： 高亮
{
"query":{
"match":{
"hobby":"唱歌"
}
},
"highlight":{
"fields":{
"hobby":{
}
}
}
}
过程：
1、检查字段类型： hobby 字段是一个text类型（指定Ik_max_word分词器）这意味着查询字符串本身也应被分词；比如输入 “爱打游戏” 本身也是分成 “爱 ” “打游戏”之类的
2、分析查询字符串：将查询的字符串 “音乐” 传入分词器种，输出的结果是单项 “音乐” 。以为只有一个单词项，所以match 查询执行的是单个底层term查询
3、查找匹配文档
用term查询在倒排序索引中查询 “音乐” 然后获取一组包含该项的文档，
4、为每个文档评分
用term查询计算出每个文档相关度评分_score ,这是种将 词频（term frequency，即词“音乐” 在相关文档的hobby字段中出现的频率。）和反向文档频率（inverse document frequency，即在所有文档 hobby 字段中出现的频率），以及字段的长度（字段越短相关度越高）相结合的计算方式。
全文多词搜索：
包含 “游戏” 和“唱歌”
由于版本问题，后面match不在支持"operator":"and"的方式
改用：”multi_match“
{
"query":{
"multi_match" : {
"query": "唱歌 打游戏",
"operator":"and"
}
},
"highlight":{
"fields":{
"hobby":{
}
}
}
}
可以调整匹配度： "minimum_should_match":"40%"
组合查询：
{
"query":{
"bool":{
"must":{
"match":{
"hobby":"唱歌"
}
},
"must_not":{
"match":{
"hobby":"豆豆"
}
},
"should":{
"match":{
"hobby":"游戏"
}
}
}
}
}
bool查询会为每一个文档计算相关度评分_score，再将所有匹配的must和should语句的分数 _score求和最后除以must和should语句的总数。must_not是不会影响评分，它的作用只是排除不相关的文档
默认情况下，should中的内容不是必须匹配的，如果查询语句中没有must,那么就至少会匹配其中1个，也可以通过minimum_should_match 参数进行控制，该值可以是百分比也可以是数字。
{
"query":{
"bool":{
"must":{
"match":{
"hobby":"唱歌"
}
},
"must_not":{
"match":{
"hobby":"豆豆"
}
},
"should":[
{
"match":{
"hobby":"游戏"
}
},
{
"match":{
"hobby":"唱歌"
}
}
],
"minimum_should_match":2
}
}
}
权重：
有些时候，我们可能需要对某些词增加权重来影响该条数据的得分：
如果包含”游戏“ 权重设为为10， 包含 ”豆豆“ 权重为2
{
"query": {
"bool": {
"must":{
"match":{
"hobby":"唱歌"
}
},
"must_not":{
"match":{
"hobby":"洗澡"
}
},
"should": [
{
"match": {
"hobby": {
"query": "打游戏",
"boost": 10
}
}
},
{
"match": {
"hobby": {
"query": "打豆豆",
"boost": 2
}
}
}
]
}
}
}
权重影响得分，也就是数据排在前后的原因。
集群节点：
在elasticsearch 中 ，节点的类型主要有4种：
1、master节点：
配置文件中的node.master属性为true(默认为true)，就有资格被选为master节点（注意：不是成为master节点，是候选）；master节点用于控制整个集群的操作，比如创建或删除索引，管理其他非master节点等。
2、data节点：
配置文件中node.data属性为true(默认为true)，就有资格被设置成为data节点（与master一样，只是有资格的，候选）；data节点主要用于执行数据相关操作，比如文档的crud
3、客户端节点：
配置文件中的node.master属性和node.data属性均为false。该节点不能作为master节点，也不能作为data节点。
可以作为客户端节点。用于响应用户的请求，把请求转发到其他节点。类似代理
4、部落节点：
当一个节点配置tribe.*的时候，它是一个特殊的客户端，可以连接多个集群，在所有连接的集群上执行搜索或其他操作。
配置elasticsearch集群：
建议：在Contos Linux部署
window 部署：6.5参考 https://www.cnblogs.com/ynylub/p/11299763.html
7版本更新：建议http://www.sohu.com/a/301517999_683048
此配置仅供参考，版本不一致，如有错误请查看中文文档或官方
本机搭建elastic search集群：
修改每个elasticsearch.yml文件
集群配置es-log-cluster：node1
#为群集使用描述性名称：
cluster.name: es-log-cluster
#为节点使用描述性名称：
node.name: node01
#有资格被选为master节点
node.master: true
#有资格被选为data节点
node.data: true
#将绑定地址设置为特定IP（IPv4或IPv6）：
network.host: 0.0.0.0
# 设置节点间交互的tcp端口,默认是9300｡
transport.tcp.port: 9300
为http设置自定义端口：
http.port: 9200
#在启动此节点时，传递要执行发现的主机的初始列表：
#默认主机列表为[“127.0.0.1”，“[：：1]”]
#注：这是发现广播集群的地址
discovery.seed_hosts: ["host1", "host2"，"host3"]
#使用初始的一组符合主节点条件的节点引导集群
#cluster.initial_master_nodes: ["node-1", "node-2"]
#对半设置防止脑裂 nodes/2+1 6.5版本 已删除
#discovery.zen.minimum_master_nodes:2
#在群集完全重新启动后阻止初始恢复，直到启动n个节点 7.3.2版本
cluster.initial_master_nodes: ["node-1"]
#跨域设置
http.cors.enabled: true
http.cors.allow-origin: "*"
集群配置es-log-cluster：node2
#为群集使用描述性名称：
cluster.name: es-log-cluster
#为节点使用描述性名称：
node.name: node02
#有资格被选为master节点
node.master: true
#有资格被选为data节点
node.data: true
#将绑定地址设置为特定IP（IPv4或IPv6）：
network.host: 0.0.0.0
为http设置自定义端口：
http.port: 9200
#在启动此节点时，传递要执行发现的主机的初始列表：
#默认主机列表为[“127.0.0.1”，“[：：1]”]
#注：这是发现广播集群的地址
discovery.seed_hosts: ["host1", "host2"，"host3"]
#使用初始的一组符合主节点条件的节点引导集群
cluster.initial_master_nodes: ["node-1"]
#对半设置防止脑裂 nodes/2+1 6.5版本
#discovery.zen.minimum_master_nodes:2
#在群集完全重新启动后阻止初始恢复，直到启动n个节点 7.3.2版本
#gateway.recover_after_nodes: 3
#跨域设置
http.cors.enabled: true
http.cors.allow-origin: "*"
集群配置es-log-cluster：node3
#为群集使用描述性名称：
cluster.name: es-log-cluster
#为节点使用描述性名称：
node.name: node03
#有资格被选为master节点
node.master: true
#有资格被选为data节点
node.data: true
#将绑定地址设置为特定IP（IPv4或IPv6）：
network.host: 0.0.0.0
为http设置自定义端口：
http.port: 9200
#在启动此节点时，传递要执行发现的主机的初始列表：
#默认主机列表为[“127.0.0.1”，“[：：1]”]
#注：这是发现广播集群的地址
discovery.seed_hosts: ["host1", "host2"，"host3"]
#使用初始的一组符合主节点条件的节点引导集群
cluster.initial_master_nodes: ["node-1"]
#对半设置防止脑裂 nodes/2+1 6.5版本
#discovery.zen.minimum_master_nodes:2
#在群集完全重新启动后阻止初始恢复，直到启动n个节点 7.3.2版本
#gateway.recover_after_nodes: 3
#跨域设置
http.cors.enabled: true
http.cors.allow-origin: "*"
注意：如果无法加入集群节点的问题，可能是data文件下已经有node文件，删除存放存放在data下的所有文件，重启服务即可。此方法仅供参考。
浏览器打开插件elasticsearch -head：
集群搭建成功！
node-001 为主节点 master
分片区别：
分片和副片：
为了将数据添加到Elastic search ，我们需要索引(index) —— 一个存储关联数据的地方。实际上，索引只是用来指向一个或多个分片(shards)的逻辑命名空间(logical namespace).
1、一个分片是一个最小级别”工作单元（worker unit）“它只是保存了索引中所有数据的一部分。
2、分片就是一个Lucene实例，并且它本身就是一个完整的搜索引擎，应用程序不会和它直接通信。
3、分片可以是主分片(primary shard)或者是复制分片(replica shard)也叫副片
4、索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。
5、复制分片也叫副片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求、比如搜索或者从别的shard取回文档。
6、当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。
故障转移
状态：
绿色(green)： 当前集群状态为绿色， 表示所有节点和分片都可以正常使用
黄色(yellow)：当前集群状态为黄色,表示主节点可以正常使用， 部分 副本分片不可用
红色(red)：部分主分片和副片不可用
当一个data节点故障，则会把分片复制给其他节点，直到该节点重新恢复正常，重新加入集群，健康状态就会从黄色变为绿色。
当一个master节点故障，则master节点则会重新在剩下的节点选举，
健康状态就会从黄色变为绿色，当故障节点master恢复到正常，则重新加入集群，此时故障节点已经不在是master节点，而是有资格的候选master节点的普通节点，
脑裂问题：
脑裂即为双主master节点，故障的master节点重新恢复正常，但不会加入之前集群，成为一个独立的集群。
为了防止脑裂问题，在配置参数的时候一定要加入
# nodes/2+1
discovery.zen.minimum_master_nodes:2
文档写入流程：
1、客户端给node1(master)发送新建、索引或删除请求
2、节点使用文档的_id确定文档属于分片0，转发请求到node3，分片0位于这个节点
3、node3在主分片上执行请求，如果成功，它转发请求到相应的位于node1和node2的复制节点上。当所有的复制节点返回成功，node3返回报告成功到请求的节点，请求节点在报告给客户端。
搜索文档（单个）：
顺序步骤：
1、客户端给node1发送get请求
2、节点使用文档的_id确定文档分片属于0，分片0对应的复制分片在三个几点上都有，此时它转发请求到node2。
3、node2返回文档给node1然后返回给客户端
对于读数据的请求，为了平衡负载，请求节点会为每个请求选择不同的分片———循环所有分片副本。
可能出现的情况： 一个被索引的文档已经存在于主分片上，但是还没有同步到副片，这时候副片分片会报告文档不存在，主分片会成功返回文档，当同步到了所有副片并返回成功，索引请求副片则会成功返回数据给用户，文档在主分片和副片也就都可以正常使用的。
深度分页
1、from+size 实现分页
优点：实时性好，能进行按页数进行分页，指定跳到某页
缺点：在深度分页时，会带来严重的性能问题：CPU、内存、IO、网络带宽数据量越大，越往后翻页，性能越低b)
2、scroll 深度分页
优点：适用于后台批处理任务，初始化时将所有符合搜索条件的搜索结果缓存起来，可以想象成快照，遍历时，从这个快照里取数据，也就是说，因为初始化的时候就已经固定了数据量，所以在初始化后对索引插入、删除、更新数据都不会影响遍历结果。
缺点：不适合用来做实时搜索，每次都要传参数 scroll，刷新搜索结果的缓存时间。
3、search_after
优点：search_after 提供了一个实时的光标来避免深度分页的问题，其思想是使用前一页的结果来帮助检索下一页。
缺点：需要使用一个值的字段作为排序字段，否则不能使用search_after方法，只能处理下一页，无法往上翻页，不能自由跳到一个随机页面。
使用search_after的前提是要使用一个唯一标识的字段进行排序。
例如：
POST请求：http://localhost:9200/filebeat-7.3.2-2019.10.08-000001/_doc/_search
{
"size": 2,
"query": {
"match": {
"message": "error"
}
},
"sort": [
{
"_id": {
"order": "asc"
}
},
{
"message.keyword": {
"order": "asc",
"unmapped_type":"long"
}
}
]
}
结果如下：
其中message的排序数值好像是不变的，也就是说message.keyword可有可无
但 _id的唯一标识排序是一定要的，就靠这唯一标识排序
查询全部文件:
使用”match_all“
{
"size": 5,
"query": {
"match_all": {
}
},
"sort": [
{
"_id": {
"order": "asc"
}
}
]
}
同原理拿到最后一个sort的数值
进行分页查询
{
"size": 5,
"query": {
"match_all": {
}
},
"search_after": [
"-Cupqm0Be7MT9ybOc6KM"
],
"sort": [
{
"_id": {
"order": "asc"
}
}
]
}
kibana可视化
Kibana是一个开源分析和可视化平台，旨在与Elasticsearch协同工作。
下载官方最新的版本，与elasticSearch的版本一致 避免导致一些不必要的问题。
解压完成后，确保elasticSearch成功启动。
在Kibana安装目录的config目录下找到Kibana.yml 修改
# The URLs of the Elasticsearch instances to use for all your queries.
elasticsearch.hosts: ["http://localhost:9200"]
修改完成后重新启动Kibana.bat
cd D:\kibana-7.3.2-windows-x86_64\bin
D:\kibana-7.3.2-windows-x86_64\bin>.\Kibana.bat
启动等待几秒钟，出现以下画面，启动成功！
如果出现 Error: No Living connections 意思是： error ：没有活动连接，
访问http://localhost:5601 则会出现：Kibana server is not ready yet
请检查elasticSearch是否成功启动；
请检查是否配置kibana.yml
elasticsearch.hosts: ["http://localhost:9200"]
请检查版本与elasticSearch的版本是否一致；
创建索引：
进入左侧工具栏的Management
index Management 可查看索引和生命策略
index Patterns 搜索并创建别名
创建过程中可添加过滤
成功后点击左侧工具栏DIscover 进行数据查询
生成可视化图表：
如果已经有了可视化图，则会出现如下图，也可以重新创建
已生成的可视化：
设置好可视化可以点击save进行保存。如果没保存，下次进入就没了需要重新创建。
仪表盘：
作用：将多套可视化的结果进行整合至单一页面内,而后提供搜索查询或者点击可视结果内的某元素指定过滤条件，从而实现结果过滤,表板能够帮助我们更全面地了解总体日志内容，并将各可视结果同日志关联起来。
创建仪表盘，可以直接将可视化的模板添加到仪表盘进行保存。
仪表盘看到的数据和可视化的数据是一样的。
开启安全验证：
进入安装目录下D:\elasticsearch-7.3.2\bin
执行：elasticsearch-setup-passwords interactive
#开始为保留用户Elastic、APM_系统、Kibana、Logstash_系统、Beats_系统、远程监控_用户设置密码。
#当进程进行时，系统将提示您输入密码。
#请确认是否要继续[Y/N]
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
You will be prompted to enter passwords as the process progresses.
Please confirm that you would like to continue [y/N]
#输入[弹性]的密码：
Enter password for [elastic]:
#重新输入[弹性]的密码：
Reenter password for [elastic]:
#输入[APM U系统]的密码：
Enter password for [apm_system]:
#重新输入[APM U系统]的密码：
Reenter password for [apm_system]:
#输入[Kibana]的密码：
Enter password for [kibana]:
#重新输入[Kibana]的密码：
Reenter password for [kibana]:
#输入[日志存储系统]的密码：
Enter password for [logstash_system]:
#重新输入[logstash_system]的密码：
Reenter password for [logstash_system]:
#输入[beats_system]的密码：
Enter password for [beats_system]:
#重新输入[beats_system]的密码：
Reenter password for [beats_system]:
#输入[远程监视用户]的密码：
Enter password for [remote_monitoring_user]:
#重新输入[远程监视用户]的密码：
Reenter password for [remote_monitoring_user]:
#更改了用户[APM U系统]的密码
Changed password for user [apm_system]
#更改了用户[Kibana]的密码
Changed password for user [kibana]
#更改了用户的密码[日志存储系统]
Changed password for user [logstash_system]
#更改了用户[Beats_系统]的密码
Changed password for user [beats_system]
#更改了用户[远程监视用户]的密码
Changed password for user [remote_monitoring_user]
#更改了用户的密码[弹性]
Changed password for user [elastic]
在filebeat.yml配置里面修改
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["localhost:9200"]
#单个ElasticSearch批量API索引请求中要批量处理的最大事件数 默认50
bulk_max_size: 18000
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme" #没修改就是默认密码changeme
username: "elastic"
password: "123456"
在kibana.yml中修改
#验证elastic search身份
elasticsearch.username: "elastic"
elasticsearch.password: "123456"
完成之后重启elasticsearch：
打开浏览器Chrome：点击插件Elastic Search Head
第一次会有弹出框验证用户和密码之后就不会了，除非你重启elastic search服务。
接着打开kibana也会提示验证身份
filebeat读取文件输出到elastic search有数据就成功了。
简单的安全就设置完成了。
日记框架：FileBeats+elasticSearch+Kibana
FileBeats：读取指定目录的文件
RabbitMQ：转发FileBeats读取到的日志文件的内容
Elasticsearch：存储RabbitMQ转发过来的内容
测试说明：由于是本地测试，侧重于测试数据性能。所以安全策略未开启，在配置文件的时候也就少了很多用户和证书之类的配置。
配置：
在FileBeats安装目录下的filebeat.yml 里， 设置输出到Elasticsearch
output.elasticsearch:
#Array of hosts to connect to.
hosts: ["localhost:9200"]
在elasticsearch启动成功的前提下，启动kibana可视化工具连接elasticsearch
配置config下的kibana.yml
打开注释
elasticsearch.hosts: ["http://localhost:9200"]
启动在安装目录下找到 bin\kibana.bat 点击运行即可，
打开浏览器，访问localhost:5601默认访问地址
一开始进入是没有数据的， 点击直接创建数据，不要使用推荐样本
如果file beat 读取到文件并输出到elasticsearch，那么kibana可视化中
点击左边工具栏上的 Management
可以看到你Index Management
点击 Index Lifecycle Policies 可以看到你的策略及模板
点击Index patterns 创建你的索引
在创建索引的过程中可以添加你的过滤器
创建完成后，点击Discover 开始查询
问题总结：
问题：filebeat输出到elasticsearch 能读取到日志内容，输出elasticsearch 一直回退，数据传输不了？
答: 猜测有可能是elasticsearch锁住了内存，数据写不了；建议重启elasticsearch，还是不行就重启电脑， 待定！
问题：日志Info类型的启动日志怎么过滤？比如说info级别的程序启动消息？
答：filebeat貌似可以使用参数：include_lines: ['ERROR','WARN','INFO']来采集数据，
#问题：filebeat采集idea生产的日志数据出现重复，默认配置读取未处理过的文件出现少部分数据丢失的情况。
答：filebeat文件内部出现问题，建议检查文件，或初始filebeat.yml文件，重新启动电脑是个不错的选择。
如果是Linux系统那么这个问题的根本原因在于 vim 编辑文件保存的时候会修改文件的 inode，此时 filebeat 会把它做新文件处理，所以又全部读取了一遍
第一次运行filebeat 读取已存在的日志，如果文件没有更新，则不会出现重复读取数据。
默认配置tail_files: 设置为true，防止读取已经读取过的数据。但是vim修改的文件无效。
如果是window10系统，则可以在dos命令执行echo 增加文件内容，但是或有一个乱码的问题。
建议重启电脑后，检查文件，然后重新启动filebat进行测试。
问题：filebeat 可以输出连接到rabbitmq吗？
答：官方回复暂不支持rabbitMQ, 在配置文件filebeat.reference.yml 有关于rabbitmqde 模块，暂时不知道有什么用处。
问题：filebeat采集log，每次filebeat程序断开，重新启动之后，不会继续采集log，请问是什么原因呢？为什么filebeat重启不再读取文件？
答：1、如果这个文档五分钟内没有更新的话，并且filebeat重启，这时候就不会再采集这个文件，就认为这个文件是已经不需要采集的文件，如果想要继续采集可以删除registry文件或者更新log文件，这是可能之一
2、在收割机关闭时移动或删除文件，Filebeat将无法再次拾取该文件，并且harvester尚未读取的任何数据都将丢失。
问题：为什么kibana连接elasticsearch可视化，检索不到数据？
答：如果文件读取完成，断开重新启动filebeat,如果文件没有新的改动，比如增加消息，那么filebeat也会认为这个文件不需要再采集。如果这时候，你删除了索引及全部信息，那么重新启动的时候elasticsearch不会创建新的索引，因为filebeat并没有读取文件采集信息，所以用kibana连接elasticsearch的时候检索不到信息。
问题：为什么100W的日志信息只查询出部分数据？
答：filebeat输出到elastic search 边读边存；实时更新数据。
如果数据量太大，当然就查询不到还没进入elastic search的数据，要等待file beat读取日志内容输出到elasticsearch完成后，才能查询
问题： 读取后的字段太多，能删除一些不重要的字段吗？ 比如@metadata，log等等,,,
答：filebeat配置中log、input、agent和ecs都可以去掉，@metadata和host不能被去掉
问题：为什么filebeat输出到文件 速度很快，而输出到elasticsearch却很慢？
答： filebeat输出到文件使用的是io流，对于读写文件很快，测试filebeat的时候读取大概117MB的日志，一共100W行日志，配置了文件大小
默认为1024kb，我们修改成1024000000kb, 文件数量2；filebeat可以在30-40s之内读取写入完成；但是在输出到elasticsearch进行查询时，
用的是默认的配置，会很慢，我们可以修改成批处理最大处理数为15000左右， 速度会有很大的提升
在filebeat配置文件中drop掉不重要的字段，也是可以提高那么一丢丢速度。具体参考压测结果。
elasticsearch查询效率：https://blog.csdn.net/Aria_Miazzy/article/details/88068145
问题：开启验证之后，post请求数据失败，安全验证出错 "type": "security_exception", "reason": "missing authentication credentials for REST request [/filebeat-7.3.2-2019.10.11-000001/doc/search?pretty]"
答：看报错信息就知道是安全验证没通过，开启验证之后每次请求都要加带身份验证，
命令执行：curl --user elastic:123456 XGET "http://localhost:9200/filebeat-7.3.2-2019.10.11-000001/_doc/_search?pretty"
或者转换为http网格请求：
例如postman：
如果是Java代码模拟请求,加入以下代码：
String name = "elastic";
String password = "123456";
String authString = name + ":" + password;
System.out.println("auth string: " + authString);
//Base64编码
byte[] authEncBytes = Base64.encodeBase64(authString.getBytes("utf-8"));
String authStringEnc = new String(authEncBytes);
//Authorization格式，注意“Basic ” 有个空格
conn.setRequestProperty("Authorization", "Basic " + authStringEnc);
一时间没有想到
特别感谢：简书繁天涯 转换成http网格式：https://www.jianshu.com/p/38c43b2c0b4d
压测性能：
不断产生新的日志，进行测试写入输出时间 要求：1s 10w左右
测试：100w tomcat日志消息
filebeat 直接输出到elasticsearch
默认配置
读取：11:21:26.827 1568949686
结束：11:53:52.202 1568951632
耗时： 1946s 约等于32分钟
filebeat.yml 中删除了字段
- drop_fields:
fields: ["log","input","host","agent","@metadata","ecs"]
其中host、@metadata 是不能被删除的
耗时： 1889s 约等于31分钟
结论: 删除不总要的字段是可以提高写入速度，每行字段少了，写入也就快那么一点
修改输入输出配置：
定义每个收割机在获取文件时使用的缓冲区大小 默认1681
filebeat.inputs:
harvester_buffer_size: 40960000
修改elasticsearch 最大处理数 默认50
outelasticsearch:
bulk_max_size: 15000
测试：100W tomcat日志消息
bulk_max_size: 15000 耗时： 130s左右
bulk_max_size: 18000 harvester_buffer_size: 40960000 耗时： 120s 左右
结论：修改elastic search的单次批处理的最大处理个数， 可以极大的提升性能，但要根据硬件进行测试，设置优化
本机测试： bulk_max_size: 18000 harvester_buffer_size: 40960000 平均耗时： 125s 左右
第一次启动创建索引的时候会慢10秒左右。
优化：
修改filebeat.yml 配置
- type: log
# Change to true to enable this input configuration.
enabled: true
encoding: utf-8
#exclude_lines: ['^DBG']
#include_lines: ['^ERR', '^WARN']
#输入在指定路径中检查新文件的频率
scan_frequency: "5s"
#如果tail_files设置为true, Filebeat从文件尾开始监控文件新增内容把新增的每一行文件作为一个事件依次发送而不是从文件开始处重新发送所有内容。
tail_files: false
#定义每个收割机在获取文件时使用的缓冲区大小
harvester_buffer_size: 40960000
# Paths that should be crawled and fetched. Glob based paths.
paths:
#- /var/log/*.log
#- c:\programdata\elasticsearch\logs\*
#- D:\filebeat\var\log\*
- E:\IDEA_project\logdemo\logs\*.log
setup.template.settings:
#分片 3
index.number_of_shards: 3
测试：100W tomcat日志消息
filebeat 读取 写入文件
文件设置大小：1024000000 kb ##默认配置1024 这里我们改大一些
文件数量： 2个 ### 默认文件数量 7个 范围2-1024个
开始读取时间： 2019-09-20 06:28:12.689Z
结束写入文件时间： 2019-09-20 06:28:49.417Z
耗时：37s
结论： 设置输出文件的大小会影响filebeat读取文件的速度。
elk 存在漏洞，攻破原理，以及如何防护
1、 Elasticsearch Kibana6.4.3之前版本和5.6.13之前版本中的Console插件存在严重的本地文件包含漏洞可导致拒绝服务攻击、任意文件读取攻击、配合第三方应用反弹SHELL攻击，Kibana中存在的一个关键LFI漏洞，使得攻击者能够在服务器上运行本地代码，可造成直接的危害就是拒绝服务攻击 。
具体问题是官方的node.js出现问题，官方已修复
而远程调用漏洞，按照 elasticsearch 官方处理建议, 将默认的监听 IP 设定在 127.0.0.1, 关闭动态执行脚本能力: script.disable_dynamic: true ( 均在它的配置文件中完成 )
加固：保证防火墙开启。
1、提高file beat输出到elasticsearch的速度:
需求： 关键词预警(日志出错，攻击)
使用第三方插件： ElastAlert 开源，需要搭建python环境。 麻烦
使用elastic官方kibana: Watcher 要钱 恼火
自己写：
idea java开发: 模拟发送elasticsearch的索引查询请求， 每10秒一次，
elasticsearch提供2种方式查询数据：
搜索API
ES提供了两种搜索的方式：请求参数方式 和 请求体方式。
请求参数方式
curl 'localhost:9200/bank/_search?q=*&pretty'
其中bank是查询的索引名称，q后面跟着搜索的条件：q=*表示查询所有的内容
请求体方式（推荐这种方式）
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
"query": { "match_all": {} }
}'
这种方式会把查询的内容放入body中，会造成一定的开销，但是易于理解。在平时的练习中，推荐这种方式。
ElasticSearch性能优化：
一、索引效率优化：索引优化主要是在 Elasticsearch 插入层面优化
方法：
批量提交：
当有大量数据提交的时候，建议采用批量提交。
如果在提交过程中，遇到 EsRejectedExecutionException 异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error 级别以上的日志
优化硬件：
优化硬件设备一直是最快速有效的手段。
-
在经济压力能承受的范围下， 尽量使用固态硬盘 SSD。SSD 相对于机器硬盘，无论随机写还是顺序写，都较大的提升。
-
磁盘备份采用 RAID0。因为 Elasticsearch 在自身层面通过副本，已经提供了备份的功能，所以不需要利用磁盘的备份功能，同时如果使用磁盘备份功能的话，对写入速度有较大的影响。
增加 Refresh 时间间隔：
为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒 （index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。
当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效的减少 segment 合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为 30s，减少 refresh 次数。
同时，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为 -1，数据导入成功后再打开到正常模式，比如 30s。
减少副本数量：
Elasticsearch 默认副本数量为 3 个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。
在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch 做业务搜索的时候，建议副本数目还是设置为 3 个，但是像内部 ELK 日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1 个。
二、查询效率优化
路由
当我们查询文档的时候，Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来
shard = hash(routing) % number_of_primary_shards
routing 默认值是文档的 id，也可以采用自定义值，比如用户 id。
不带 routing 查询
在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤
-
分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
-
聚合: 协调节点搜集到每个分片上查询结果，在将查询的结果进行排序，之后给用户返回结果。
带 routing 查询
查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。
向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多。
Filter VS Query
Use filter context instead of query context if possible. 尽可能使用过滤器上下文（Filter）替代查询上下文（Query
-
Query：此文档与此查询子句的匹配程度如何？
-
Filter：此文档和查询子句匹配吗？
Elasticsearch 针对 Filter 查询只需要回答「是」或者「否」，不需要像 Query 查询一下计算相关性分数，同时 Filter 结果可以缓存。
不过Query 查询计算相关性分数，可以设置优先显示的数据，具体请查看“权重”设置
大翻页
在使用 Elasticsearch 过程中，应尽量避免大翻页的出现。
正常翻页查询都是从 From 开始 Size 条数据，这样就需要在每个分片中查询打分排名在前面的 From + Size 条数据。协同节点收集每个分配的前 From + Size 条数据。协同节点一共会受到 N * （ From + Size ）条数据，然后进行排序，再将其中 From 到 From + Size 条数据返回出去。
如果 From 或者 Size 很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU 资源消耗增大。
可以通过使用 Elasticsearch scroll 和 scroll-scan 高效滚动的方式来解决这样的问题。具体写法，可以参考
Elasticsearch: 权威指南 - scroll 查询(https://www.elastic.co/guide/cn/elasticsearch/guide/cn/_fetch_phase.html)
不过scroll 查询不适合实时查询，适用于群发消息，因为scroll初始化时将所有符合搜索条件的搜索结果缓存起来，也就是已经固定了数量，遍历时，从这个缓存里取数据。所以在初始化后对索引插入、删除、更新数据都不会影响遍历结果。
我们可以使用 search_after进行替代scroll深度分页。具体请看search_after深度分页。
JVM 设置
32G 现象
Elasticsearch 默认安装后设置的堆内存是 1 GB。 对于任何一个业务部署来说， 这个设置都太小了。
比如机器有 64G 内存，那么我们是不是设置的越大越好呢？
其实不是的。
主要 Elasticsearch 底层使用 Lucene。Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene 的段是分别存储到单个文件中的。因为段是不可变的，这些文件也都不会变化，这是对缓存友好的，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
如果你把所有的内存都分配给 Elasticsearch 的堆内存，那将不会有剩余的内存交给 Lucene。 这将严重地影响全文检索的性能。
标准的建议是把 50％ 的可用内存作为 Elasticsearch 的堆内存，保留剩下的 50％。当然它也不会被浪费，Lucene 会很乐意利用起余下的内存。
同时了解过 ES 的同学都听过过「不要超过 32G」的说法。
其实主要原因是 ：JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。在 Java 中，所有的对象都分配在堆上，并通过一个指针进行引用。 普通对象指针（OOP）指向这些对象，通常为 CPU 字长 的大小：32 位或 64 位，取决于你的处理器。指针引用的就是这个 OOP 值的字节位置。
对于 32 位的系统，意味着堆内存大小最大为 4 GB。对于 64 位的系统， 可以使用更大的内存，但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。更糟糕的是， 更大的指针在主内存和各级缓存（例如 LLC，L1 等）之间移动数据的时候，会占用更多的带宽.
所以最终我们都会采用 31 G 设置(前提是你有这么大的内存，不然还是乖乖的设置一半内存)
假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene
如果你的内存只有8g（家用学习）,我建议你 设置2g就行了，集群节点不要超过3个，根据你的内存来决定启动几个，否在你的电脑将会卡到爆。
加入中间加RabbitMQ:
大部分博客使用的都是中间件kafka，那么rabbitmq应该也可以才对。官方虽然说明不支持rabbitMQ,但那是2018年8月,中间件应该是差不多的，所以我觉得rabbitMQ应也可以才对。继续研究。
注：部分为官方文档与其他不知道（忘记了）地方复制粘贴的，此文档为学习fek搭建的记录文档