注意
本文档适用于 Ceph 的开发版本。
使用集群日志
（注意：以下内容不适用于本地“dout”日志记录。这指的是我们通过监视器守护进程发送的集群日志）
严重性
在集群因某种原因无法完成其工作的情况下使用 ERR。例如：我们尝试执行写入，但返回错误，或者我们尝试读取某些内容，但它已损坏无法读取，或者我们擦洗了一个 PG 但数据不一致无法恢复。
在集群可以处理但存在异常/负面方面（例如服务临时降级或意外内部值）的事件中使用 WRN。例如，可以自动修复的元数据错误或缓慢的操作。
对于不表示 Ceph 故障的普通集群操作使用 INFO。特别重要的是，INFO 级别消息措辞清晰，不会引起混淆或警报。
频率
重要的是，所有严重性级别的消息都不要过于频繁。消费者可能正在使用包含所有严重性级别消息的循环日志缓冲区，因此即使 DEBUG 消息过于频繁，也可能干扰最新 INFO 消息的正确显示。
请记住，如果您处于不良状态（而不是事件），那正是健康检查的作用——不要为了指示持续不健康状态而滥发集群日志。
不要针对随客户端数量或系统活动级别而变化的事件，或在正常操作中定期发生的事件发出集群日志消息。例如，针对每个新连接的客户端（随客户端数量变化）发出 INFO 消息是不合适的，或者针对每个 CephFS 子树迁移（定期发生）发出 INFO 消息也是不合适的。
语言和格式
- （注意：这些指南对于 DEBUG 级别消息的重要性远低于
INFO 及以上级别。请集中精力使 INFO/WRN/ERR 消息尽可能易读。）
使用被动语态。例如，使用“对象 xyz 无法读取”，而不是“我无法读取对象 xyz”。
打印长/大标识符（例如 inode 号）时，使用十六进制，并加上 0x 前缀，以便用户知道它是十六进制。我们这样做是因为 0x 使其明确（十进制没有等效项），并且十六进制形式更可能在屏幕上显示完整。
以人类可读的 MB/GB/等形式打印大小数量，并在数字末尾包含单位。例外：如果您指定偏移量，其中精度对含义至关重要，则可以以字节为单位指定值（但以十六进制打印）。
真诚地努力使您的消息在一行中显示。这不一定是保证的，但通常应该如此。这意味着，通常情况下，除非列表中只有几个项目，否则不要打印列表。
使用对用户有意义且在文档中定义的名词。常用缩写可以接受——不要浪费屏幕空间输入“Rados Object Gateway”而不是 RGW。不要使用“MDCache”或“Objecter”等内部类名。如果内部结构是消息的直接主题，例如在损坏中，则可以提及，但请使用简单的英语。示例：不要说“Objecter requests”，而要说“OSD client requests”。示例：在“Corrupt session table”的上下文中提及内部结构是可以的（但不要说“Corrupt SessionTable”）
在可能的情况下，描述对系统可用性的影响，而不仅仅描述底层状态。例如，不要说“MDS myfs.0 正在重播”，而要说“myfs 已降级，正在等待 myfs.0 完成启动”。
虽然常用缩写可以接受，但不要随意截断单词。不是“dir ino”，而是“directory inode”。
如果您记录了“永远不应该发生”的事情，即本应是断言但我们却友好地没有崩溃的情况，那么请在语言中明确说明这一点——这可能不是用户可以自行补救的情况。
避免使用 UNIX/程序员的术语。不要说“errno”，而要说“错误”（或者最好提供比数字更具描述性的内容！）
除非集群映射纪元对消息的含义至关重要，否则不要提及它们。例如，“OSDMap epoch 123 is corrupt”是可以的（纪元是消息的重点），但说“OSD 123 is down in OSDMap epoch 456”则不行（osdmap 和纪元概念是实现细节，OSD 的停机状态才是真实消息）。请随意将更多详细信息发送到守护进程的本地日志（通过 dout/derr）。
如果您记录了一个将来可能会消失的问题，请确保在它消失时也进行记录。无论您最初记录消息的优先级如何，都将“消失”消息记录为 INFO 级别。