0x01 前言

在写这篇文章的前几个月,Elastic已经发布了6.0版本。这篇文章内的所有内容都是以最新版本为基础进行编写的。

我之前已经写过好多篇关于elasticstack这个技术栈的文章,而今天我将这些文章做一个整合处理,将所有知识点和要点重新梳理,形成一篇elasticstack技术栈的入门文章。

更为详细的使用手册可以参考官方网站的文档:

0x02 准备

安装的过程可以参考以下文章,以便与本篇文章进行互补:

我依旧采用centos7作为底层系统,使用我家中的的镜像作为源地址,如果本地没有可用的源镜像,那么推荐使用清华大学的镜像:

在/etc/yum.repos.d目录下新建以下文件并写入内容即可:

然后先清理yum缓存再安装jdk与elasticstack套件:

再继续之前先讲解elasticstack的基础知识,首先常用的套件包含以上4个独立的软件,而这些软件都依赖java环境,所以需要安装openjdk。

其中各个软件的功用如下:

  • kibana:一个用户友好的GUI控制界面,可从elasticsearch中读取数据并生成各种酷炫的图表;
  • Beats平台:Beast都是以agent的形式存在系统中并展开监视工作,读取后的数据可以发送至logstash进行处理或发送至elasticsearch进行存储。比较典型的有Packetbeat,、Filebeat、Metricbeat和Winlogbeat:
    • Packetbeat:主要收集数据包的代理;
    • Filebeat:主要收集文本日志的代理;
    • Metricbeat:主要收集系统和软件的性能或其他指标数据的代理;
    • Winlogbeat:主要收集windows系统日志的代理。
  • logstash:一个开源的实时数据处理与收集引擎。

以上软件的工作流程如下图:

以上图片来自elastic官网

从上图可以看出Beast一侧主要工作为收集数据;收集到的数据可以发送至logstash进行分词处理再进行归档存储,也可以直接发送至elasticsearch归档存储;最终用户通过kibana从elasticsearch中搜索数据并进行可视化操作。

安装完成后需要先修改配置文件,官方推荐的配置顺序为elasticsearch–>kibana–>beast。但我更倾向于先配置kibana,然后再配置elasticsearch等。

0x03 kibana

先检查service启动文件:

可以看出可执行文件与配置文件的路径,下面先修改配置文件,请根据实际情况进行修改:

其他参数诸如elasticsearch用户名与密码,这个需要安装x-pack后才需要配置,SSL的配置将在以后文章中详细说明。完成配置后即可启动kibana:

如果一切正常,那么你将看到以下界面:

因为还没有配置elasticsearch,所以服务状态为Red,同时plugin:[email protected]存在告警:

这是因为kibana无法连接到elasticsearch,无法读取.kibana这个索引的内容。

0x04 elasticsearch

接下来配置elasticsearch,和kibana一样,elasticsearch的bin目录与配置文件路径分别如下:

elasticsearch配置文件中的内容不多,但绝大部分都需要手动配置:

数据存储的路径可以有多个值,理想情况下可以均衡负载。但我在实际使用中发现配置生效的时间必须早于索引建立的时间才有效。

多个数据存储路径的配置格式如下:

完成配置后即可通过以下命令启动elasticsearch:

如果一切正常,那么刷新kibana后即可看到以下界面:

如果还是提示无法连接elasticsearch,请重新检查kibana的配置文件与elasticsearch服务是否已经启动,必要时可以重启kibana服务。

0x05 logstash

logstash功能非常强大,不仅仅是分析传入的文本,还可以作监控与告警之用。在这里主要讲解分析的配置与使用经验。

logstash的bin目录与配置文件路径都与kibana和elasticsearch类似:

logstash的配置文件完全不需要修改:

0x05.1 输入配置

在启动之前需要先编写输入、输出和过滤的配置文件,以下是我常用的一些配置文件,不同类型的配置文件可加上数字前缀,以便区分:

如果需要与best通过公网进行通讯,建议使用SSL加密,那么输入的配置文件如下:

相关的数字证书可自行签发,签发过程可参考以下文章:

如果需要监听514端口,则logstash需要以root用户启动,请手动修改以下文件:

如果需要监听其他TCP或UDP端口,可以参考以下配置:

logstash还支持多种输入方式,具体请参考官方的说明:

0x05.2 输出配置

logstash可以在上层配置一个负载均衡器实现集群,在实际应用中,logstash服务需要处理多种不同类型的日志或数据,处理后的日志或数据需要存放在不同的elasticsearch集群或索引中,那么就需要对日志进行分门别类。

更多相关的信息可以参考官方的文档:

而我的logstash服务节点只有一个,需要处理多达6种不同类型的日志,所以我的输出配置如下:

通过在output配置中设定判断语句,将处理后的数据存放到不同的索引中。而这个tags的添加有以下三种途径:

  1. 在filebeat读取数据后,向logstash发送前添加到数据中;
  2. logstash处理日志的时候,向tags标签添加自定义内容;
  3. 在logstash接收传入数据时,向tags标签添加自定义内容。

在这里先说明第3中情况:

从上面的输入配置文件中可以看出,在logstash接收到从TCP或UDP 8017端口传入的数据时,随机在tags标签加上自定义的win32_log标签。

这个操作除非在后续处理处理数据的时候手动将其删除,否则将永久存在该数据中。

elasticsearch字段中的各参数的意义如下:

  • hosts:指定elasticsearch地址,如有多个节点可用,可以设为array模式,可实现负载均衡;
  • manage_template:如果该索引没有合适的模板可用,默认情况下将由默认的模板进行管理;
  • index:指定存储数据的索引

0x05.3 筛选处理

输入和输出在logstash配置中是很简单的一步,而对数据进行匹配处理则显得异常复杂。匹配当行日志是入门水平需要掌握的,而多行甚至不规则的日志则可能需要ruby的协助。

更多的信息请关注官方的文档:

在这里我主要展示使用grok这个插件,你可以浏览以下文章,和此文章进行互补:

以下是我nginx的access日志格式:

以下是该日志的grok捕获语法:

相关的语法可以参考以下GitHub页面:

在编写grok捕获规则时,可以使用以下网站进行辅助:

如果语法没问题,那么会显示以下界面:

我nginx日志完整的筛选处理配置文件如下:

在filter段内的第一行是判断语句,如果server_ngx_access_log这个自定义字符在tags内则使用grok段内的语句对日志进行处理。

  • geoip:使用GeoIP数据库对client_ip字段的IP地址进行解析,可得出该IP的经纬度、国家与城市等信息,但精确度不高,这主要依赖于GeoIP数据库;
  • date:默认情况下,elasticsearch内记录的date字段是elasticsearch接收到该日志的时间,但在实际应用中需要修改为日志中所记录的时间。这时候则需要指定记录时间的字段并指定时间格式。如果匹配成功,则会将日志的时间替换至date字段中。
  • useragent:这个主要为web app提供的解析,可以解析目前常见的一些useragent。

在防火墙、IDS或IPS应用环境中经常或遇到两组公网IP的情况,这时候的GeoIP配置可以类似以下这样进行设定:

通过以上配置解析出来的日志格式如下:

最后请注意配置文件grok字段中add_tag的配置,这个配置正是“0x05.2 输出配置”中所说的第2点情况:logstash处理日志的时候,向tags标签添加自定义内容。

完成后即可启动logstash服务,需要注意的是logstash启动时间较长,请耐心等待:

在每次修改配置文件之后都需要重新启动logstash服务,为了减少downtime,建议先通过以下命令检查配置文件是否有效:

0x06 filebeat

filebeat的相关文件路径与之前相差无几,先修改配置文件:

每个filebeat可以根据需求的不同拥有一个或多个prospectors,其他配置信息含义如下:

  • input_type:输入内容,主要为逐行读取的log格式与标准输入stdin
    • paths:指定需要读取日志的路径,如果路径拥有相同的结构,则可以使用通配符
    • tags:为该路径的日志添加自定义tags,这与“0x05.2 输出配置”中所说的“在filebeat读取数据后,向logstash发送前添加到数据中”意义一致
    • clean_:filebeat在这个路径有一个注册表文件:/var/lib/filebeat/registry,这个文件记录着filebeat读取过那些文件,还有已经读取的行数等信息。如果你的日志文件是定时分割,而且数量会随之增加,那么该注册表文件也会慢慢增大。随着注册表文件的增大,会导致filebeat检索的性能下降。更多该参数的含义,请先浏览官方说明:
    • close_eof:正常情况下,filebeat会认为一个文件会不断地写入。如果你的文件只写入一边,那么建议启用该配置,告诉filebeat读取完成后关闭该文件,而后无论改文件是否更改,都不读取。请注意!该参数有风险,请注意你的日志文件是否使用close_eof这个参数。具体可参考官方说明:
    • multiline.pattern:该参数适用于多行日志,如modsecurity日志,这部分内容在日后详解
    • multiline.negate:该参数适用于多行日志,如modsecurity日志,这部分内容在日后详解
    • multiline.match:该参数适用于多行日志,如modsecurity日志,这部分内容在日后详解
  • output.logstash:定义内容输出的路径,这里主要输出到elasticsearch,其他的输出方式请参考官方说明:

设定完成后先不要启动filebeat服务!

0x07 初始化配置

一旦启动filebeat,filebeat就会开始读取日志并发送至logstash进行处理,处理完成后的日志会发送至elasticsearch进行存储。

但在这里会有个问题,因为elasticsearch还没有配置索引与模板,如果直接接收logstash传入的日志,会导致后续的分析无法进行。

所以要先进行索引与模板的初始化配置,请注意!一旦索引与模板配置完成并接收数据后将无法修改字段类型与索引分片数量!

为了方便检查索引的状态与信息,建议先按照以下文章安装elasticsearch-head:

为了实现高可用,强烈建议使用别名配置索引,相关配置过程请参考以下文章:

例如“0x05.2 输出配置”中nginx日志需要输出至以下索引:

这个“public-ngx-alias”为虚拟的索引,无需创建;需要创建一个名为“public-ngx_v1”的实体索引。

请注意虚拟索引与实体索引须有结构上的区别,例如上述例子中的“-”与“_”两个符号,这是为了方便模板匹配索引。

索引的创建于链接工作可通过kibana中dev_tools进行:

别名的链接也可以使用该工具进行:

通过以下命令可以查看相关索引的信息:

完成后还需要为匹配“public-ngx_*”这个规则的实体索引配置模板,请注意!不要为虚拟索引配置模板!这是为了应对日后发生字段类型改变的情况,方便应用新的模板,并且重新匹配旧数据所设定的。具体可参考以下文章:

接下来是模板,以下是我目前匹配nginx日志的模板:

因为我系统中的日志较为简单且内容较少,所以模板也较为简单。但一般来说模板主要包含setting和mappings两部分内容。setting部分可以是以下这样的:

以上设定了该索引只有1个分片,需要注意的是,一旦分片数量设定且索引已经生成,那么该数值不可再发生改变,除非重新生成索引!更多setting字段的内容请参考官方文档:

mapping部分主要是字段类型的映射,支持的字段类型可参考官方文档:

mapping中支持的设定请参考官方文档:

需要注意的是,如果需要做算术加减,请注意选择数字类型,例如字节(byte)等,还需要注意各种类型的数值范围。如果需要使用可视化地图,则需要注意geo_point这个格式:

建立好模板后即可将其导入到elasticsearch中:

一切就绪后即可启动filebeat。

0x08 结语

接下来只需要等待filebeat读取日志并传送至logstash,经过处理后的数据再传送到elasticsearch,最终打开kibana的Management –> Index Patterns添加虚拟索引:

因为测试环境无数据,所以引用了生产环境中的一张截图

如果一切正常,那么在discover标签内看到的内容类似下图:

因上图内容较为敏感,所以做了模糊处理

elasticstack整体配置起来确实较为繁琐,尤其是logstash的部分,如果遇到多行日志则更加麻烦。如果需要处理上亿条的数据,建议建立elasticsearch集群,可加快检索速度。