日志中心实践-日志模型设计

该文定义了一种数据模型,用于标准化日志记录,包括操作系统、第三方应用和自身应用的日志。模型要求能保持日志格式的语义,支持高效序列化,并包含如时间戳、严重性级别、TraceId等关键字段。日志记录分为命名顶级字段和任意值的Map,以适应不同类型的日志源和事件。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

此数据模型定义了独立日志记录是什么,需要记录、传输、存储和解释那些数据。

1 设计思路

数据模型的设计满足以下要求:

(1)应该能够明确地将现有日志格式映射到此数据模型。理想情况下将日志数据从任意日志格式转换到此数据模型,然后再转换回来,应该得到相同的数据。

(2)数据模型必须保留现有日志格式的特定元素的语义,其他日志格式到此数据模型的映射应该在语义上有意义。

(3)将日志数据从任意日志格式A转换为此数据模型,然后从数据模型转换为另一种日志格式B,理想情况下,必须产生有意义的日志数据转换,其效果不差于将日志格式A合理地直接转换为日志格式B。

(4)在需要存储或传输数据的具体实现中有效地表示数据模型,主要关心效率的两个方面:序列化/反序列化的CPU使用量和序列化形式的空间需求。这是一个间接的需求,它受数据模型的具体表示而不是数据模型本身的影响。

数据模型旨在成功地表示3种类型的日志和事件:

(1)操作系统生成的日志和事件,我们无法控制它们——我们不能改变格式或影响包含的信息(除非数据是由我们可以修改的应用程序生成的)。系统格式的一个例子是Syslog。

(2)第三方应用程序。这些是由第三方应用程序生成的。我们可能对包含的信息有一定的控制,例如自定义格式。例如Apache日志文件。

(3)自身的应用程序。这些是开发的应用程序,可以在一定程度上控制如何生成日志和事件,以及在日志中包含哪些信息。如果需要,可能会修改应用程序的源代码。

此数据模型为日志记录定义了一个逻辑模型(与记录的物理格式和编码无关)。每条记录包含2种字段:

(1)具有特定类型和含义的命名顶级字段。

该字段需要对所有记录都是强制性的,如时间戳,TraceId等。

(2)map,可以包含不同类型的任意值。允许使用该字段的所有各方对数据有相同的解释。参见附录A中资源和属性字段的语义约定和示例。

2 具体设计

2.1 概述

字段名称

描述

Timestamp

事件发生时间

可能为空

ObservedTimestamp

事件被观测到的时间

必填

TraceId

Request trace id.

可选

SpanId

Request span id.

可选

TraceFlags

W3C trace flag.

可选

SeverityText

日志级别(如:info,error,warn等)

必填

SeverityNumber

日志级别,例如数字来代指日志级别

必填

Body

日志内容

必填

Resource

描述日志的源。来自同一事件源的多个事件可以在不同时间发生,并且它们都具有相同的Resource值

可选

InstrumentationScope

表示事件发生的所属领域,如logger name

Attributes

附加信息。

可选

2.2 字段详述

字段名称:Timestamp

类型:Timestamp, uint64 nanoseconds since Unix epoch.

描述:事件发生的时间。这个字段是可选的,如果源时间戳未知,它可能会丢失。

字段名称:ObservedTimestamp

类型: Timestamp, uint64 nanoseconds since Unix epoch.

描述:采集时间。

字段名称:TraceId

类型:byte sequence.

描述:在W3C跟踪上下文中定义的请求跟踪id(调用链)。可以为作为请求处理的一部分并具有指定跟踪id的日志设置。该字段可选。

字段名称:SpanId

类型:byte sequence.

描述:在W3C跟踪上下文中定义的spanid(调用链)。该字段可选。

字段名称:TraceFlags

类型:byte.

描述:W3C跟踪上下文规范中定义的跟踪标志。在编写规范时定义了一个标志——SAMPLED标志,表示trace是不是被采样了。该字段可选。

字段名称:SeverityText

类型:string

描述:日志级别,这是严重程度的原始字符串表示形式,因为它在源代码中是已知的。如果该字段缺失且存在SeverityNumber,则可以使用与SeverityNumber对应的短名称[1]作为替代。该字段可选。

字段名称:SeverityNumber

类型:num

描述:日志级别的数值,标准化为本文档中描述的值。该字段可选。

SeverityNumber为整数。较小的数值对应较不严重的事件(如调试事件),较大的数值对应较严重的事件(如错误和关键事件)。SeverityNumber值含义如下表所示:

数字范围

范围名称

含义

1-4

TRACE

细粒度调试事件。通常在默认配置中禁用。

5-8

DEBUG

一个debugging事件.

9-12

INFO

指代一个信息事件的发生,表示一个一般情况的发生。

13-16

WARN

警告事件。不是错误,但可能比信息事件更重要。

17-20

ERROR

错误事件

21-24

FATAL

致命错误,如应用程序或系统崩溃。

在每个范围中,数值越小,事件就越不重要(不那么严重)。每个范围的数值越大,表示事件越重要(越严重)。例如,SeverityNumber=17描述的错误比SeverityNumber=20的错误更严重。

字段名称:Body

类型:any

包含日志记录主体的值(请参阅上面任何类型的描述)。例如,可以是可读的字符串消息(包括多行),以自由形式描述事件,也可以是由数组和其他值的映射组成的结构化数据。应用程序应该使用字符串消息。但是,应该使用结构化主体来保存第三方应用程序发出的结构化日志的语义。来自同一来源的事件的每次发生都可能有所不同。该字段可选。

字段名称:Resource

类型:map

描述日志的源。来自同一事件源的多个事件可以在不同时间发生,并且它们都具有相同的Resource值。例如,可以包含关于发出记录的应用程序的信息,或者关于运行应用程序的基础设施的信息。表示此数据模型的数据格式可以设计为允许Resource字段仅记录来自同一源的每批日志记录一次。该字段可选。参考resource的定义

字段名称:InstrumentationScope

类型:(Name,Version) tuple of strings.

表示事件发生的所属领域,如logger name

字段名称:Attributes

类型:map.

附加信息。不同于Resource字段(针对特定源是固定的),Attributes可以根据来自同一源的事件的每次发生而变化。可以包含关于请求上下文的信息(除了TraceId/SpanId)。

附录:

[1] SeverityNumber对应的短名称

SeverityNumber

Short Name

1

TRACE

2

TRACE2

3

TRACE3

4

TRACE4

5

DEBUG

6

DEBUG2

7

DEBUG3

8

DEBUG4

9

INFO

10

INFO2

11

INFO3

12

INFO4

13

WARN

14

WARN2

15

WARN3

16

WARN4

17

ERROR

18

ERROR2

19

ERROR3

20

ERROR4

21

FATAL

22

FATAL2

23

FATAL3

24

FATAL4

参考:

[1] https://opentelemetry.io/docs/reference/specification/logs/data-model/

[2] https://www.bilibili.com/read/cv18609680?from=search&spm_id_from=333.337.0.0

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值