来源类型
一、什么是来源类型(Sourcetype)
来源类型(sourcetype)是平台数据的内置字段,也是用来区分不同数据格式的重要标识。来源类型可以描述数据的切分方式、时间抽取方式、字段提取方式等重要信息。
对于Pandora 2.0来说,所有接入的数据都以数据流的形式,系统需要先将数据流转换成一个个时序事件,然后再存储到系统的存储设备上。因此,在数据真正入库前需要:
- 将数据流按照切分规则形成独立的事件
- 为每个事件抽取时间信息
不同数据格式的数据流,其划分方式以及时间识别方式各有不同,应当配置不同的事件划分方式与时间识别方式来分别处理不同的数据流。因此,来源类型标记了数据流的事件划分方式和时间识别方式。当数据入库时,Pandora识别并为其添加来源类型字段,用户可以使用来源类型来搜索所有该来源类型的数据
来源类型(sourcetype)是Pandora 2.0的默认字段之一,即每一条事件都会有对应的sourcetype字段。
将不同的数据流写入到同一个仓库里是允许的。此时,该仓库里隶属于不同数据流的事件,其内置字段sourcetype将拥有不同的值,用以互相区分。
内置来源类型
Pandora已经内置了若干来源类型,您可以为数据指定内置来源类型,或者配置自定义的来源类型。
- json:行划分为
自动
,时间戳提取为当前
。 - audit:用于系统内置的审计日志,行划分为
自动
,时间戳提取为自动
。 - _frontend_error:用于系统内置的前端错误日志,行划分为
自动
,时间戳提取为当前
。 - _collector_status:用于系统内置的采集器相关日志,行划分为
自动
,时间戳提取为自动
。
二、配置来源类型
创建来源类型
在来源类型页面进行创建,也可以在文件上传页面以交互式的方式完成来源类型的相关配置。
各种配置的含义如下:
配置 | 说明 |
---|---|
换行规则 (也称事件划分规则) |
用于定义如何将数据流划分成一个个事件 |
时间提取规则 |
用于定义如何从数据流中提取时间信息,用以将事件变成时序事件 |
其他高级配置 |
字符编码的选择,是否开启字段自动发现功能 |
更具体的,换行规则又分为:
配置细则 | 说明 |
---|---|
自动 |
按照每个事件的首行都具有时间信息来定位各个事件的第一行。这对于诸如错误栈等横跨多行的日志特别有用 |
单行 |
强制按照一行一个事件划分数据流 |
正则 |
用正则的方式表达事件分隔符。它是单行 配置的拓展版,单行 等效于在正则 里填写\r?\n 。注意,被正则匹配上的字符会被系统吞掉,不会被算在事件里。 |
时间提取规则又分为:
配置细则 | 解释 |
---|---|
自动 |
利用系统已知的各种时间格式,逐个尝试。省心但不高效,而且容易出现误识,在生成环境上,不建议使用。 |
当前 |
不尝试识别数据流中的时间,直接采用入库时的当前时间作为事件时间 |
自定义 |
指明时间字符串在数据流中的位置,并指明时间字符串的具体格式与可能的长度。配置繁琐,但处理高效且精度高 |
时间自定义
模式的配置细则:
配置细则 | 说明 |
---|---|
时区 |
用于指定时间的时区信息。如果时间字符串自带了时区信息,并且系统通过时间戳格式 识别到了该时区,那么系统会采用识别到的时区,而忽略时区 选项里的时区。 |
时间戳前缀 (选填) |
用正则定位时间字符串在数据流中的位置。例如,数据流中有意义的时间信息都紧跟在# Timestamp: 的后面。那么,就可以在该配置里填上# Timestamp: |
时间戳格式 (选填) |
采用诸如yyyy-MM-dd'T'HH:mm:ss,SSS Z 的格式来表达不同格式的时间字符串。详见下面的案例教学 |
时间戳长度上限 |
用于限定时间识别的范围。默认情况下,系统只会从时间戳前缀其后的100个字符中寻找时间信息。该限制属于用户给予系统的先验信息,利用这个信息,系统在无法找到时间信息的情况下,能够及时止损,避免不必要的系统资源浪费 |
其他高级配置:
配置细则 | 说明 |
---|---|
字符编码 |
选择合适的字符编码,默认UTF-8 |
字段自动发现 |
开启后系统会自动提取日志中键值对(形如 key=value) 作为数据字段 |
时间戳格式样例
类型 | 格式 | 样例字符串 |
---|---|---|
Apache Log | Fri Feb 01 22:03:08.318615 2019 | EEE MMM dd HH:mm:ss.SSSSSS yyyy |
W3C Extended Log | 2002-05-02 17:42:15 | yyyy-MM-dd HH:mm:ss |
Microsoft IIS Log | 03/20/01, 7:55:20 | MM/dd/yy, H:mm:ss |
NCSA Common log | 07/Apr/2004:17:39:04 -0800 | dd/MMM/yyyy:HH:mm:ss Z |
Log4j Log | 2019-07-15T17:19:46,473 | yyyy-MM-dd'T'HH:mm:ss,SSS |
Mongo Log | 2019-07-16T20:09:25.385+0800 | yyyy-MM-dd'T'HH:mm:ss.SSSZ |
JULLogger Log | Jul 15, 2019 5:19:53 PM | MMM dd, yyyy h:mm:ss a |
总结:
时间类别 | 格式表达 |
---|---|
年 | 2004 ,用yyyy 表达;04 ,用yy 表达 |
月 | 7 ,用M 表达;07 ,用MM 表达;Jul ,用MMM 表达;July ,用MMMM 表达;J ,用MMMMM 表达 |
日 | 09 ,用dd 表达;9 ,用d 表达 |
星期 | Tue ,用E 或EE 或EEE 表达;Tuesday ,用EEEE 表达;T ,用EEEEE 表达 |
12小时制 | 用小写的h 或hh 表达 |
24小时制 | 用大写的H 或HH 表达 |
分钟 | 用小写的m 或者mm 表达 |
秒 | 用小写的s 或者ss 表达 |
秒以下的精度 | 用大写的S 表达。若精确到毫秒,则用 SSS 表达;若精确到微秒,则用 SSSSSS 表达;若精确到纳秒,则用 SSSSSSSSS 表达。注意,尽管系统能够识别纳秒级时间信息,但毫秒以下的精度不会被系统采纳 |
时区 | UTC+8 ,用O 表达;UTC+08:00 ,用OOOO 或ZZZZ 表达;+0830 以及+0000 ,用Z 或ZZ 或ZZZ 表达;+08:30 以及Z ,用ZZZZZ 表达;+00:00 ,用xxx 表达 |
时间戳自定义示例
示例一
- 本示例中,没有填写时间戳前缀。此时系统默认从每一行的第一个字符开始尝试寻找时间信息。示例中,日期字符串日期前为空格,我们需要用填充字符
pp
来占位填充。
引用两个
p
表示期望有2个字符,如果不满,则用空格填充。
示例二
- 本例中,时间字符串位于message字段值的前几十个字符。因此,填写时间戳前缀为
"message":"
示例中时间字符串包含特殊字符
[
,]
,需要使用单引号包住这些特殊字符。
示例三
- 本示例中有不止一个时间字符串,计划识别13位毫秒级时间戳作为事件时间,但这种Unix Epoch时间戳无法使用诸如yyyy-MM-dd的形式来表达。我们依然可以使用时间戳前缀来定位时间字符串,在时间戳格式为空的情况下,系统仍然会尝试使用内置的时间格式去匹配时间戳前缀后面的100个字符。
示例四
- 该示例中,时间字符串包含中文字符而且还有时区缩写。我们使用
a
来表达上午
和下午
,时
、分
、秒
被视作特殊字符处理,用单引号括起来,缩写形式的时区信息,用z
表达。
示例五
- 该示例中的数据是csv格式的数据,以逗号分隔各个字段值,要识别的时间信息位于倒数第二列。我们依然可以通过正则匹配来定位到时间字符串:
([^,]*,){8}
。
三、来源类型管理
点击搜索分析->来源管理,进入来源类型管理页面,您可以在此页面进行创建、查看、删除、导入导出来源类型等操作。
- 新建来源类型:请单击页面右上方的“ 新建来源类型”按钮,打开新建来源类型页面,参数配置与上文配置来源类型一致。
- 查看来源类型:查看来源类型配置参数及绑定的解析规则。
- 删除来源类型:您不能删除预置源类型,只能删除自己创建或应用附带的源类型。
- 导出来源类型:导出来源类型为 JSON 文件。
- 导入来源类型:导入来源类型的JSON文件创建来源类型。
文档反馈
(如有产品使用问题,请 提交工单)