数据模型
iLogtail 目前支持 SLS Log Protocol
和 Pipeline Event
两种数据模型,两种模型的描述和对比如下:
描述
SLS 日志的专用处理结构
可扩展的可观测性数据模型,支持Metrics、Trace、Logging、Bytes、Profile等
流水线配置版本
v1
v2
Logging 数据结构
支持
支持
Metric 数据结构
不支持
支持
Trace 数据结构
不支持
支持
ByteArray 数据结构
不支持
支持
Profile 数据结构
不支持
支持
自定义数据结构
不支持
支持
SLS Log Protocol
参考 SLS 协议
Pipeline Event
PipelineEvent
是数据处理管道中的抽象数据接口,定义如下
我们还需要引入聚合的概念 PipelineGroupEvents
,来支持部分需要对数据进行分组的操作,聚合事件也允许有独立的 meta 和 tags,一般是从数据中提取
Metric 模型
Metric模型定义如下:
主流的metrics数据有单值(eg. Prometheus)和多值(eg. influxdb)两种设计,iLogtail 中也需要支持两种不同的设计,基于此设计了 MetricValue 接口和MetricSingleValue 和 MetricMultiValue 两个不同的实现
通常情况下,对于 counter 、gauge 类型的 metric 会使用单值 ,Histogram 和 Summary 类型在不同的TSDB上可能使用单值或者多值,对于单值和多值的处理,可以使用下面的API
TypedValue 设计。MetricValue 不管是单值还是多值的value类型都是float64,在一些 TSDB 中比如 influxdb,除了数值类型,还支持string bool 等非数值类型 (influxdb field-value)[https://docs.influxdata.com/influxdb/v1.8/concepts/glossary/#field-value] 。为此,我们扩展了一个额外的 TypedValue 字段用来存储非数值的 field 值。
Trace 模型
目前主流的开源 tracing 模型有opentracing opentelemetry skywalking 等几种不同的规范。 不管在哪种 trace 模型中,trace 都是由多个 Span 组成的,(不同的是在 skywalking 和许多私有协议中,trace 和 span 中间还有一个 segment 或者 transaction 概念)。 在 Span 中,一般还会定义携带数据语义的 Tags ,和记录一些关键事件发生的 logs 或 events 。 其中zipkin jaeger 都是 opentracing 的一种实现,而opentelemetry 可以认为是在opentracing的基础上扩展的新规范和超集(兼容 w3c 和定义了明确的 OTLP 协议)。 所以我们定义的 Span 结构要兼容上面提到的几种开源协议,具体的结构如下
Log 模型
Log 模型可以兼容非结构化和结构化日志,并且预留链路信息记录的字段。
其中 Offset 记录了日志文件采集时,日志在文件中的偏移量,可选
Name 对 Log 也是可选的
SpanID 、TraceID 在数据关联时使用,可选
Contents 在日志结构化的场景使用,存储从 Body 原始日志文本分析的 KV
其中Level字段,对齐Open Telemetry Logs,支持以下等级: Trace
, Trace2
, Trace3
, Trace4
, Debug
, Debug2
, Debug3
, Debug4
, Info
, Info2
, Info3
, Info4
, Warn
, Warn2
, Warn3
, Warn4
, Error
, Error2
, Error3
, Error4
, Fatal
, Fatal2
, Fatal3
, Fatal4
, Unspecified
.
Last updated