ELK元数据管理规范

ELK数据接入

元数据管理规范

版本历史

目录

1概述5

1.1文档目的 5

1.2文档范围 5

1.3读者对象 5

1.4术语及定义5

2原始数据规范 6

2.1数据格式定义 6

2.2业务文档化6

3数据传输 7

3.1Filebeat传输规范 7

3.1.1数据格式 7

3.1.2配置规范 7

3.2Logstash传输规范7

3.2.1数据格式 7

3.2.2配置规范 7

3.3Kafka消息中间件数据规范7

4数据存储 7

4.1ES存储规范7

4.1.1索引格式 7

4.2HDFS存储规范8

4.3MySQL存储规范8

5附录8

1.概述

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: log

enabled: true

paths:

- /home/elk/logs/test/test.log

processors:

- decode_json_fields:

fields: ["message"]

max_depth: 3

target: ""

overwrite_keys: true

- drop_fields:

fields: ["message", "beat", "input_type"]

output.kafka:

enabled: true

hosts: ["192.168.30.93:9092","192.168.30.93:9093","192.168.30.93:9094"]

topic: test

b.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 => 3

auto_offset_reset => "earliest"

codec => json

}

}

filter {

json {

source => "message"

}

ruby {

code => '

time = Time.now

event.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 Reference

Logstash Reference

Elasticsearch Reference