ELK元数据管理规范

  • 格式:docx
  • 大小:26.30 KB
  • 文档页数:8

ELK数据接入元数据管理规范版本历史目录1概述51.1文档目的 51.2文档范围 51.3读者对象 51.4术语及定义52原始数据规范 62.1数据格式定义 62.2业务文档化63数据传输 73.1Filebeat传输规范 73.1.1数据格式 73.1.2配置规范 73.2Logstash传输规范73.2.1数据格式 73.2.2配置规范 73.3Kafka消息中间件数据规范74数据存储 74.1ES存储规范74.1.1索引格式 74.2HDFS存储规范84.3MySQL存储规范85附录81.概述a.文档目的本文档针对所有接入ELK平台的元数据进行约束,从数据接入方式和格式,到数据传输和存储制定标准规范,为开发者对数据的操作和二次开发提供参考。

b.文档范围此文档包含原始数据格式规范,数据传输配置参考,以及数据最终落地和存储规范。

c.读者对象此文档对所有内部开发人员提供元数据操作和管理约束。

d.术语及定义ELK:Elasticsearch、Logstash和Kibana的简称。

ES:Elasticsearch的缩写。

2.原始数据规范a.数据格式定义所有原始数据要求能从接入处体现其关联业务,因此需要对涉及到的业务进行编号,编号规则暂定如下:i.编号由字母和数字组成,数字长度一般为4位。

ii.字母为业务名称缩写,数字为业务对应的工作编号,如lens0001。

接入数据分为日志文件和HTTP实时数据两种。

对于日志文件,业务编号需在文件名中体现出来。

HTTP接口接入方式则根据数据的输入输出对其配置,一般来说,使用Logstash接入需保证pipeline的ID与业务编号一致,如果数据流向kafka消息中间件,对应topic的名称则为业务编号。

b.业务文档化所有业务和对应编号信息需由统一文档进行管理,以方便查询。

每个新的业务和数据接入展开时,也要求及时更新文档,备注更新日期和开发者姓名。

文档必需提供的信息包括:●业务编号●业务名称●业务简介●业务开始时间●数据接入方式●数据接入路径(包括配置文件路径等)●更新日期●开发者姓名3.数据传输a.Filebeat传输规范i.数据格式Filebeat主要用于数据收集和传输,它可以读取任何格式的数据并作简单的处理,我们在使用中读取的数据格式主要是json格式。

ii.配置规范Filebeat配置文件后缀为.yml,配置内容包括prospectors、processors和output三个部分。

每一个配置文件的命名为filebeat-加上对应的业务名称,如filebeat-lens0001.yml。

Prospectors部分用来指定要传输的文件所在路径,这里我们只对文件进行读取收集,因此只要配置文件路径就行。

output部分指定数据输出信息,可配置的输出端有kafka,logstash和Elasticsearch等。

processors部分只有在需要对数据进行简单处理的时候才定义,常用的设置包括对json格式解析和字段的增减等。

下面示例是读取Jason格式文件解析后传入kafka的配置:filebeat.prospectors:- type: logenabled: truepaths:- /home/elk/logs/test/test.logprocessors:- decode_json_fields:fields: ["message"]max_depth: 3target: ""overwrite_keys: true- drop_fields:fields: ["message", "beat", "input_type"]output.kafka:enabled: truehosts: ["192.168.30.93:9092","192.168.30.93:9093","192.168.30.93:9094"]topic: testb.Logstash传输规范i.数据格式Logstash可接收来自日志文件、Filebeat、Kafka等几十种不同来源的数据,在目前的架构场景中,最频繁接入的是来自Kafka和HTTP接口的数据。

对于业务产生的数据,无论从哪种来源接入,均严格要求符合标准Json格式。

ii.配置规范Logstash的配置分为三部分:Input、output和Filter,每一部分相当于组件所带的插件。

Input插件指定Logstash读取的数据源,一个Logstash进程可以有多个输入源,所以原则上一个Logstash进程可以应付一台服务器上所有日志,但在实际应用中,对于不同业务应配置不同Logstash进程。

Output插件和Input插件一样允许配置多个输出源。

我们把数据从输入到输出的完整配置称为一个事件管道(Event Pipeline),对于每个Pipeline需定义唯一ID,ID名需包含所对应的业务编号。

Logstash最强大的功能在于它的Filter插件,Logstash提供丰富的内置功能,并且集成ruby语言,让我们可以随心所欲地使用该插件对数据进行清洗、转换和过滤。

在配置filter插件时,应尽量避免重复操作,尽可能地提高数据处理的效率。

下面示例为Logstash从Kafka接收Json数据并清洗过滤后写入ES的配置:input {kafka {bootstrap_servers => ["192.168.30.93:9092,192.168.30.93:9093"]topics => ["test"]group_id => "test"client_id => "test01"consumer_threads => 3auto_offset_reset => "earliest"codec => json}}filter {json {source => "message"}ruby {code => 'time = Time.nowevent.set("ds",time.strftime("%Y-%m-%d"))event.get("header").each {|k, v| event.set(k, v)} //内部字段合并到外层'}split {field => "[body][app]"target => "app"}mutate {remove_field => ["@timestamp", "@version", "body", "header"]}}output {elasticsearch{hosts => ["192.168.30.93:9201","192.168.30.93:9202"]index => "kafka2es-%{+YYYY.MM.dd}"}}c.Kafka使用规范数据接入Kafka时应根据不同业务使用不同Topic来接收,Topic的命名需与业务编号一致,并且每条数据应遵守标准json格式。

因为partition数量在创建后只能增加不能减少,所以在创建Topic时应根据需求指定partition数量,建议consumer线程数(消费者个数)设置为partition 数目。

4.数据存储a.ES存储规范数据输出到ES应遵守统一的索引命名规则和mapping定义标准,具体规范如下:i.索引名索引名称需以项目编号为前缀,后缀应根据数据存储周期添加写入日期,如lens1001-20180601。

ii.Mapping结构首次导入数据时需提前创建字段对应Mapping结构,避免由ES自动生成。

日志常见字段格式中,时间字段需使用date类型,IP地址使用ipv4类型,经纬度使用geo-point类型。

只索引需要被搜索的字段,其余字段可只存储不加入索引以减少内存占用,。

iii.其他规范ES中的每个文档为一个json对象,所以往ES写入的数据时应为Json格式。

过期或不使用的数据应及时清除,HDFS存储规范数据存储到HDFS时,需按照规范存储到指定路径,文件名需包含业务编号,并根据需要对其进行分区存储,所有数据对应业务存储信息应文档化说明。

在使用Hive建立HDFS对应的外部表时,表名和业务文件名一致,对于临时表应在使用结束后删除,日志数据也需按存储周期定时更新。

b.MySQL存储规范对于存储到MySQL的数据需文档化说明业务对应的所有表信息及数据字典等。

表名以业务编号为前缀,建表语句中需对表和所有字段进行注释,每张表必须包含创建时间(create_time)和更新时间(update_time)两个字段。

5.附录Filebeat ReferenceLogstash ReferenceElasticsearch Reference。