使用集群日志

（注意：这些内容不适用于本地“dout”日志。这是关于我们通过mon守护进程发送的集群日志）

严重性

在集群因某种原因无法执行其任务的情况下，使用ERR。例如：我们尝试写入，但它返回了错误，或者我们尝试读取某些内容，但它已损坏所以我们无法读取，或者我们清理了PG，但数据不一致所以我们无法恢复。

使用WRN表示集群可以处理但存在异常/负面方面的事件，例如服务的临时降级或意外的内部值。例如，可以自动修复的元数据错误或缓慢的操作。

使用INFO表示不会指示Ceph错误的普通集群操作。特别是，INFO级别消息必须措辞清晰，不会引起混淆或恐慌。

频率

所有级别的消息不应过于频繁。消费者可能正在使用一个包含所有级别消息的旋转日志缓冲区，因此如果DEBUG消息过于频繁，可能会干扰最新INFO消息的正确显示。

请记住，如果你处于不良状态（相对于事件而言），健康检查就是为此而设——不要向集群日志中充斥表示持续不健康状态的信息。

不要为与客户端数量或系统活动级别成正比的扩展事件，或为在正常操作中定期发生的事件发出集群日志消息。例如，对于每个新连接的客户端发出INFO消息（与客户端数量成正比）是不恰当的，或者对于每个CephFS子树迁移发出INFO消息（定期发生）也是不恰当的。

语言和格式

（注意：这些指南对DEBUG级别消息的重要性远不如对INFO及以上级别消息的重要性。集中精力使INFO/WRN/ERR消息尽可能易读。）: for INFO and above. Concentrate your efforts on making INFO/WRN/ERR messages as readable as possible.)

使用被动语态。例如，使用“对象xyz无法读取”，而不是“我无法读取对象xyz”。

将长/大标识符（如inode编号）作为十六进制打印，并加上0x前缀，以便用户可以识别它是十六进制。我们这样做是因为0x使其无歧义（十进制没有等效项），并且十六进制形式更有可能适合屏幕显示。

将大小数量作为人类可读的MB/GB等打印，包括数字末尾的单位。例外：如果你指定偏移量，其中精度对意义至关重要，那么你可以用字节指定值（但打印为十六进制）。

尽最大努力使你的消息适应单行。这不必保证，但至少通常应该是这样。这意味着，通常情况下，除非列表中只有几个项目，否则不打印列表。

使用对用户有意义的名词，并在文档中定义。常见的缩写词是可以接受的——不要浪费屏幕空间输入“Rados对象网关”而不是RGW。不要使用内部类名，如“MDCache”或“Objecter”。如果消息的直接主题是内部结构，可以提及内部结构，例如在损坏的情况下，但使用普通英语。

尽可能描述对系统可用性的后果，而不仅仅是描述底层状态。例如，不要说“MDS myfs.0正在重放”，而要说“myfs正在降级，等待myfs.0完成启动”。

虽然常见的缩写词是可以接受的，但不要随意截断单词。这不是“dir ino”，而是“目录inode”。

如果你记录的是“永远不会发生”的事情，即断言的情况，但我们友好地没有崩溃，那么在语言中明确这一点——这可能不是用户可以自行解决的问题。

避免UNIX/程序员行话。例如，不要说“errno”，而要说“错误”（或者最好给出比数字更描述性的内容！）

除非它们对消息的意义至关重要，否则不要提及集群映射纪元。例如，“OSDMap纪元123已损坏”是可以的（纪元是消息的点），但说“OSD 123在OSDMap纪元456下线”是不可以的（osdmap和纪元概念是实现细节，OSD的下线才是真正的消息）。可以自由地将额外细节发送到守护进程的本地日志（通过derr）dout/derr).

如果你记录了一个可能在未来消失的问题，请确保在它消失时也记录下来。无论你最初以什么优先级记录了原始消息，都要以INFO的优先级记录“消失”消息。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.