Author 晓兵

weixin: ssbandjl

公众号: 云原生云

ceph文档

MSGR2 协议（MSGR2.0 和 MSGR2.1）

这是由 SimpleMessenger 实现的遗留 Ceph 在线协议的修订版。它解决了性能和安全问题。

目标

相对于原始协议，此协议修订版有几个目标：

灵活的握手。原始协议没有足够灵活的协议协商来允许不需要的功能。
加密。我们将通过网络整合加密。
表现。我们希望提供协议功能（例如，填充），使计算和内存副本尽可能远离快速路径。
签约。我们将允许对流量进行签名（但不一定加密）。这没有实现。

定义

客户端（C）：发起（TCP）连接的一方
服务器（S）：接受（TCP）连接的一方
connection：两个进程之间的 (TCP) 连接实例。
entity：一个ceph实体实例化，例如’osd.0'。每个实体都有一个或多个唯一的 entity_addr_t’s 凭借’nonce’字段，它通常是一个 pid 或随机值。
会话：两个实体之间的有状态会话，其中消息交换是有序且无损的。如果出现中断（TCP 连接断开），一个会话可能会跨越多个连接。
frame：在对等点之间发送的离散消息。每个帧都包含一个标签（类型代码）、有效负载和（如果启用了签名或加密）一些其他字段。结构见下。
tag：与框架关联的类型代码。标签决定有效载荷的结构。

阶段

一个连接有四个不同的阶段：

横幅
认证帧交换
消息流握手帧交换
消息帧交换

横幅

客户端和服务器在连接后都会发送一条横幅：

"ceph v2\n"
__le16 banner payload length
banner payload

横幅负载具有以下形式：

__le64 peer_supported_features
__le64 peer_required_features

这是一个新的、独特的功能位命名空间 (CEPH_MSGR2_*)。目前，仅定义了 CEPH_MSGR2_FEATURE_REVISION_1。它受支持但不是必需的，以便 msgr2.0 和 msgr2.1 对等方可以相互交谈。

如果远程方宣传我们不支持的所需功能，我们可以断开连接。

帧格式

交换横幅后，所有进一步的通信都在框架中进行。帧的确切格式取决于连接模式（msgr2.0-crc、msgr2.0-secure、msgr2.1-crc 或 msgr2.1-secure）。所有连接都以 crc 模式开始（msgr2.0-crc 或 msgr2.1-crc，取决于横幅中的 peer_supported_features）。

每个帧都有一个 32 字节的前导码：

__u8 tag
__u8 number of segments
{
  __le32 segment length
  __le16 segment alignment
} * 4
__u8 flags
reserved (1 byte)
__le32 preamble crc

一个空帧有一个空段。一个非空帧可以有一到四个段，除了最后一个段之外的所有段都可以是空的。

如果少于四个段，则未使用的（尾随的）段长度和段对齐字段被清零。

### 当前支持的标志

FRAME_EARLY_DATA_COMPRESSED（请参阅压缩后帧格式）

保留字节清零。

前导码校验和为 CRC32-C。它涵盖了所有内容（28 字节），并且计算和验证与连接模式无关（即即使帧已加密）。

### msgr2.0-crc模式

msgr2.0-crc 帧具有以下形式：

preamble (32 bytes)
{
  segment payload
} * number of segments
epilogue (17 bytes)

结语是：

__u8 late_flags
{
  __le32 segment crc
} * 4

late_flags 用于帧中止。在发送前导码和第一段之后，发送方可以用零填充剩余的段并设置一个标志以指示接收方必须丢弃该帧。这允许发送方避免在正在传输的帧被撤销（即从信使中拉出）时进行额外缓冲：有效载荷缓冲区可以被取消固定并立即交还给用户，而无需复制或阻塞直到整个帧被传输。目前这仅由内核客户端使用，参见 ceph_msg_revoke()。

段校验和为 CRC32-C。对于“使用过的”空段，它被设置为 (__le32)-1。对于未使用的（尾随）段，它被归零。

计算 CRC 只是为了防止位错误。不提供真实性保证，这与 msgr1 不同，msgr1 试图通过可选地使用会话密钥对段长度和 crc 进行签名来提供一些真实性保证。

问题：

作为引入具有适用于控制帧和消息帧的可变段数的通用帧结构的一部分，msgr2.0 将消息帧第一段 (ceph_msg_header2) 的 crc 移到了结语中。

因此，在从网络上读取整个帧之前，无法再安全地解释 ceph_msg_header2。这是 msgr1 的回归，因为为了将有效负载直接分散到用户提供的缓冲区中，从而避免在接收消息帧时进行额外的缓冲和复制，ceph_msg_header2 必须提前可用——它存储用户缓冲区被键入的事务 ID在。实现必须在放弃此优化或对未验证的段采取行动之间做出选择。
late_flags 不包含在任何 crc 中。由于它存储了中止标志，因此单个位翻转可能导致已完成的帧被丢弃（导致发送方挂起等待回复），或者更糟的是，导致中止的帧中发送了垃圾段有效负载。

这是 msgr1 的情况，并被转移到 msgr2.0。

### msgr2.1-crc模式

与msgr2.0-crc的区别：

第一段的 crc 存储在第一段的末尾，而不是尾声中。Epilogue 最多存储三个 CRC，而不是最多四个。

如果第一段为空，则不生成 (__le32)-1 crc。
仅当帧具有多个段时（即第二至第四段中至少有一个不为空），才会生成结语。基本原理：如果帧只有一个段，则无法中止并且没有 crcs 可存储在结语中。
未校验和的 late_flags 被 late_status 取代，后者通过使用每个标志 4 位半字节和两个汉明距离 = 4 的代码字（而不是全零或全一）来构建位错误检测。当然，这是以只有一个保留标志为代价的。

一些示例框架：

一个 0+0+0+0 帧（空的，没有结语）：
```
preamble (32 bytes)
```

一个 20+0+0+0 帧（无尾声）：

preamble (32 bytes)
segment1 payload (20 bytes)
__le32 segment1 crc

一个0+70+0+0帧：

preamble (32 bytes)
segment2 payload (70 bytes)
epilogue (13 bytes)

一帧20+70+0+350：

preamble (32 bytes)
segment1 payload (20 bytes)
__le32 segment1 crc
segment2 payload (70 bytes)
segment4 payload (350 bytes)
epilogue (13 bytes)

结语是：

__u8 late_status
{
  __le32 segment crc
} * 3

你好

TAG_HELLO：客户端->服务器和服务器->客户端：
```
__u8 entity_type
entity_addr_t peer_socket_address
```
- 我们立即共享我们的实体类型和对等方的地址（这对于检测我们的有效 IP 地址很有用，尤其是在存在 NAT 的情况下）。

验证

TAG_AUTH_REQUEST：客户端->服务器：

__le32 method;  // CEPH_AUTH_{NONE, CEPHX, ...}
__le32 num_preferred_modes;
list<__le32> mode  // CEPH_CON_MODE_*
method specific payload

TAG_AUTH_BAD_METHOD 服务器 -> 客户端：拒绝客户端选择的身份验证方法：
```
__le32 method
__le32 negative error result code
__le32 num_methods
list<__le32> allowed_methods // CEPH_AUTH_{NONE, CEPHX, ...}
__le32 num_modes
list<__le32> allowed_modes   // CEPH_CON_MODE_*
```
- 返回尝试的身份验证方法和错误代码（-EOPNOTSUPP，如果该方法不受支持），以及允许的身份验证方法列表。
TAG_AUTH_REPLY_MORE：服务器->客户端：
```
__le32 len;
method specific payload
```
TAG_AUTH_REQUEST_MORE：客户端->服务器：
```
__le32 len;
method specific payload
```
TAG_AUTH_DONE：（服务器->客户端）：
```
__le64 global_id
__le32 connection mode // CEPH_CON_MODE_*
method specific payload
```
- 服务器是决定身份验证已完成以及最终连接模式将是什么的服务器。

客户端使用允许的认证方式时的认证阶段交互示例：

客户端首次尝试使用禁止的身份验证方法时身份验证阶段交互的示例：

授权后帧格式

根据 TAG_AUTH_DONE 协商的连接模式，连接要么保持 crc 模式，要么切换到相应的安全模式（msgr2.0-secure 或 msgr2.1-secure）。

### msgr2.0-安全模式

msgr2.0-secure 框架具有以下形式：

{
  preamble (32 bytes)
  {
    segment payload
    zero padding (out to 16 bytes)
  } * number of segments
  epilogue (16 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

结语是：

__u8 late_flags
zero padding (15 bytes)

late_flags 与 msgr2.0-crc 模式中的含义相同。

每个段和结语都用零填充到 16 个字节。从技术上讲，GCM 不需要任何填充，因为计数器模式（GCM 中的 C）本质上是将块密码转换为流密码。但是，如果总输入长度不是 16 字节的倍数，一些隐式零填充将在内部发生，因为 GCM 用于生成 auth 标签的 GHASH 函数仅适用于 16 字节块。

问题：

发件人使用单个随机数加密整个帧并生成单个身份验证标签。因为段长度存储在前导码中，接收方别无选择，只能在不验证 auth 标签的情况下解密和解释前导码——否则它甚至无法判断要从线路上读取多少才能获得 auth 标签！这创建了一个解密预言机，它与计数器模式的延展性相结合，可能导致敏感信息的恢复。

此问题也扩展到消息帧的第一段。与在 msgr2.0-crc 模式下一样，ceph_msg_header2 在整个帧被离线读取之前不能被安全地解释。
使用具有 4 字节计数器字段后跟 8 字节固定字段的确定性随机数构造。初始值取自连接秘密——在身份验证阶段生成的随机字节串。由于计数器字段只有四个字节长，它可以在不到一天的时间内包装然后重复，导致 GCM 随机数重用，因此可能完全丧失连接的真实性和机密性。此问题已通过在计数器重复之前断开连接来解决 (CVE-2020-1759)。

### msgr2.1-安全模式

与msgr2.0-secure的区别：

前导码、第一段和帧的其余部分分别加密，使用单独的随机数并生成单独的身份验证标签。这摆脱了未经验证的明文使用，并使 msgr2.1-secure 模式接近 msgr2.1-crc 模式，允许实现以类似的方式接收消息帧（几乎没有缓冲，相同的分散/收集逻辑等）。

为了减少每帧的加密/解密操作数，前导码由固定大小的内联缓冲区（48 字节）增长，第一个段全部或部分内联到该缓冲区中。preamble auth 标签覆盖了 preamble 和 inline buffer，所以如果第一个段足够小可以完全内联，它在一次解密操作后就可用了。
与 msgr2.1-crc 模式一样，仅当帧具有多个段时才会生成结语。理由更加充分，因为它需要额外的加密/解密操作。
为了与 msgr2.1-crc 模式保持一致，late_flags 被替换为 late_status（在安全模式下实际上不需要内置位错误检测）。
根据GCM 的 NIST 建议，使用具有 4 字节固定字段后跟 8 字节计数器字段的确定性随机数构造。一个 8 字节的计数器字段不应重复，但为 msgr2.0-secure 模式设置的随机数重用保护仍然存在。

初始值与 msgr2.0-secure 模式相同。

与在 msgr2.0-secure 模式中一样，每个段都被零填充为 16 个字节。如果第一个段是完全内联的，它的填充将进入内联缓冲区。否则，填充位于其余部分。其推论是内联缓冲区以 16 字节块的形式消耗。

内联缓冲区未使用的部分被清零。

一些示例框架：

一个 0+0+0+0 帧（空的，没有内联的，没有结语）：

{
  preamble (32 bytes)
  zero padding (48 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

一个 20+0+0+0 帧（第一段完全内联，没有尾声）：

{
  preamble (32 bytes)
  segment1 payload (20 bytes)
  zero padding (28 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

一个 0+70+0+0 帧（没有内联）：

{
  preamble (32 bytes)
  zero padding (48 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)
{
  segment2 payload (70 bytes)
  zero padding (10 bytes)
  epilogue (16 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

一个 20+70+0+350 帧（第一段完全内联）：

{
  preamble (32 bytes)
  segment1 payload (20 bytes)
  zero padding (28 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)
{
  segment2 payload (70 bytes)
  zero padding (10 bytes)
  segment4 payload (350 bytes)
  zero padding (2 bytes)
  epilogue (16 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

一个 105+0+0+0 帧（第一段部分内联，没有尾声）：

{
  preamble (32 bytes)
  segment1 payload (48 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)
{
  segment1 payload remainder (57 bytes)
  zero padding (7 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

一个 105+70+0+350 帧（第一段部分内联）：

{
  preamble (32 bytes)
  segment1 payload (48 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)
{
  segment1 payload remainder (57 bytes)
  zero padding (7 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)
{
  segment2 payload (70 bytes)
  zero padding (10 bytes)
  segment4 payload (350 bytes)
  zero padding (2 bytes)
  epilogue (16 bytes)
} ^ AES-128-GCM cipher
auth tag (16 bytes)

结语是：

__u8 late_status
zero padding (15 bytes)

late_status 与 msgr2.1-crc 模式中的含义相同。

压缩

压缩握手是使用基于 msgr2 功能的握手实现的。在此阶段，除了支持的压缩方法列表之外，客户端还会向服务器指示是否可以使用在线压缩进行消息传输。如果客户端和服务器都启用了在线压缩，则服务器将根据客户端的请求和自己的偏好选择一种压缩方法。握手完成后，双方都设置了他们的压缩处理程序（如果需要）。

TAG_COMPRESSION_REQUEST (client->server)：声明压缩能力和要求：
```
bool  is_compress
std::vector<uint32_t> preferred_methods
```
- 如果客户端确定两个对等点都支持压缩功能，则它会发起握手。
- is_compress 标志指示客户端的配置是否使用压缩。
- preferred_methods 是客户端支持的压缩算法列表。
TAG_COMPRESSION_DONE (server->client) ：确定压缩设置：
```
bool is_compress
uint32_t  method
```
- 服务器根据其配置确定是否可以进行压缩。
- 如果可能，它将选择客户端也支持的最优先压缩方法。
- 如果不存在，它将确定将在不压缩的情况下处理对等点之间的会话。

# msgr2.x-安全模式

将压缩与加密相结合会带来安全隐患。使用安全模式时将无法进行压缩，除非由管理员专门配置。

压缩后帧格式

根据 TAG_COMPRESSION_DONE 协商的连接模式，连接能够接受/发送压缩帧或将所有帧处理为解压缩。

# msgr2.x-强制模式

如果满足压缩要求（例如，帧大小），将压缩通过连接发送的所有后续帧。

对于压缩帧，发送方将启用 FRAME_EARLY_DATA_COMPRESSED 标志，从而允许接受方检测它并解压缩帧。

# msgr2.x-无模式

FRAME_EARLY_DATA_COMPRESSED 标志将在序言中被禁用。

消息流握手

在此阶段，对等点相互识别并（如果需要）重新连接到已建立的会话。

TAG_CLIENT_IDENT（客户端->服务器）：识别我们自己：
```
__le32 num_addrs
entity_addrvec_t*num_addrs entity addrs
entity_addr_t target entity addr
__le64 gid (numeric part of osd.0, client.123456, ...)
__le64 global_seq
__le64 features supported (CEPH_FEATURE_* bitmask)
__le64 features required (CEPH_FEATURE_* bitmask)
__le64 flags (CEPH_MSG_CONNECT_* bitmask)
__le64 cookie
```
- 客户端将首先发送，服务器将以相同的方式回复。如果这是一个新会话，客户端和服务器可以继续进行消息交换。
- 目标地址是客户端试图连接的人*，*这样如果客户端与错误的守护进程通信，服务器端可以关闭连接。
- type.gid (entity_name_t) 在此处设置，通过将 hello 框架中共享的类型与此处的 gid 组合在一起。这意味着我们不需要在每条消息的标题中使用它。这也意味着我们无法“从”其他 entity_name_t 发送消息。当前的实现将其设置在 _send_message 等的顶部，因此这不应破坏任何现有功能。实现可能希望根据经过身份验证的凭据允许的内容来掩盖这一点。
- cookie 是用于标识会话的客户端 cookie，可用于重新连接到现有会话。
- 我们从 msgr1 中删除了“protocol_version”字段
TAG_IDENT_MISSING_FEATURES (server->client)：抱怨 TAG_IDENT 的特征太少：
```
__le64 features we require that the peer didn't advertise
```

TAG_SERVER_IDENT (server->client)：接受客户端身份并识别服务器：

__le32 num_addrs
entity_addrvec_t*num_addrs entity addrs
__le64 gid (numeric part of osd.0, client.123456, ...)
__le64 global_seq
__le64 features supported (CEPH_FEATURE_* bitmask)
__le64 features required (CEPH_FEATURE_* bitmask)
__le64 flags (CEPH_MSG_CONNECT_* bitmask)
__le64 cookie

如果客户端稍后断开连接并想要重新连接并恢复会话，则客户端可以使用服务器 cookie。

TAG_RECONNECT（客户端->服务器）：重新连接到已建立的会话：

__le32 num_addrs
entity_addr_t * num_addrs
__le64 client_cookie
__le64 server_cookie
__le64 global_seq
__le64 connect_seq
__le64 msg_seq (the last msg seq received)

TAG_RECONNECT_OK（服务器->客户端）：确认重新连接尝试：
```
__le64 msg_seq (last msg seq received)
```
- 一旦客户端收到此消息，客户端就可以继续进行消息交换。
- 服务器发送此消息后，服务器可以继续进行消息交换。
TAG_RECONNECT_RETRY_SESSION（仅限服务器）：由于陈旧的 connect_seq 而无法重新连接
TAG_RECONNECT_RETRY_GLOBAL（仅限服务器）：由于陈旧的 global_seq 而无法重新连接
TAG_RECONNECT_WAIT（仅限服务器）：由于连接竞争导致重新连接失败。
- 指示服务器已经连接到客户端，并且该方向应该赢得比赛。客户端应等待该连接完成。
TAG_RESET_SESSION（仅限服务器）：要求客户端重置会话：
```
__u8 full
```
- full 标志指示对等方是否应该进行完全重置，即丢弃消息队列。

故障场景示例：

首先客户端的 client_ident 消息丢失，然后客户端重新连接。

服务器的 server_ident 消息丢失，然后客户端重新连接。

服务器的 server_ident 消息丢失，然后服务器重新连接。

会话建立后连接失败，然后客户端重新连接。

建立会话后连接失败，因为服务器重置，然后客户端重新连接。

RC*表示reset session full标志依赖于连接的policy.resetcheck。

建立会话后连接失败，因为客户端重置，然后客户端重新连接。

消息交换

一旦建立了会话，我们就可以交换消息。

TAG_MSG：一条消息：
```
ceph_msg_header2
front
middle
data_pre_padding
data
```
- - ceph_msg_header2 由 ceph_msg_header 修改而来：
    
    包含一个 ack_seq。这避免了大多数时候需要 TAG_ACK 消息。删除我们现在从消息流握手 (TAG_IDENT) 中获得的 src 字段。指定data_pre_padding 长度，可用于调整数据负载的对齐方式。（注意：这有用吗？）
TAG_ACK：确认收到消息：
```
__le64 seq
```
- 这仅用于有状态会话。
TAG_KEEPALIVE2：检查连接活跃度：
```
ceph_timespec stamp
```
- 时间戳是发件人本地的。
TAG_KEEPALIVE2_ACK：回复一个keepalive2：
```
ceph_timestamp stamp
```
- 时间戳来自我们正在响应的 TAG_KEEPALIVE2。
TAG_CLOSE：终止连接

指示应终止连接。这相当于挂断或重置（即应触发 ms_handle_reset）。这不是绝对必要或有用的，因为我们可以断开 TCP 连接。

协议交互 (WIP) 示例

客户端状态机

服务器端状态机

以前的下一个

网络编码

这描述了用于序列化数据的编码。它不涵盖特定的对象/消息，而是侧重于基本类型。

这些类型不以任何方式自我记录。除非您知道它们是什么，否则无法解码它们。

惯例

整数

使用的整数类型将被命名{signed}{size}{endian}。例如， u16le一个无符号的 16 位整数以小端字节顺序编码，而s64be一个有符号的 64 位整数以大端字节序编码。此外，u8 ands8将分别代表有符号和无符号字节。有符号整数使用二进制补码编码。

复杂类型

本文档将使用类似 C 的语法来描述结构。该结构表示将通过网络传输的数据。元素之间不会有填充，元素将按照它们出现的顺序发送。例如：

struct foo {
        u8    tag;
        u32le data;
}

对值进行编码时0x05，和0x12345678将分别作为.05 78 56 34 12

变量数组

与 c 不同，长度数组可以在结构中的任何地方使用，并且将在协议中内联。此外，可以使用结构中较早的项目来描述长度。

struct blob {
        u32le size;
        u8    data[size];
        u32le checksum;
}

此结构被编码为 32 位大小，后跟size数据字节，然后是 32 位校验和。

原始别名

这些类型只是原始类型的别名。

// From /src/include/types.h

typedef u32le epoch_t;
typedef u32le ceph_seq_t;
typedef u64le ceph_tid_t;
typedef u64le version_t;

结构

这些是结构的编码方式。请注意，这些结构实际上并不存在于源代码中，而是不同类型的编码方式。

选修的

Optionals 表示为一个存在字节，如果它存在，后面跟着项目。

struct ceph_optional<T> {
        u8 present;
        T  element[present? 1 : 0]; // Only if present is non-zero.
}

boost::optional自从将 C++17 引入 Ceph 以来，Optionals 用于编码， std::optional.

一对

对只是第一项，然后是第二项。

struct ceph_pair<A,B> {
        A a;
        B b;
}

对用于编码std::pair。

三倍

三元组只是一个接一个的树元素。

struct ceph_triple<A,B,C> {
        A a;
        B b;
        C c;
}

三元组用于编码ceph::triple。

列表

列表表示为元素计数后跟那么多元素。

struct ceph_list<T> {
        u32le length;
        T     elements[length];
}

笔记

列表中元素的大小不一定统一。

列表用于对std::list、std::vector、std::deque和 std::set进行编码ceph::unordered_set。

斑点

Blob 只是一个字节列表。

struct ceph_string {
        ceph_list<u8>;
}

// AKA

struct ceph_string {
        u32le size;
        u8    data[size];
}

Blob 用于对std::string,和进行编码。const char *``bufferlist

笔记

Blob 的内容是任意二进制数据。

地图

地图是成对的列表。

struct ceph_map<K,V> {
        ceph_list<ceph_pair<K,V>>;
}

// AKA

struct ceph_map<K,V> {
        u32le length;
        ceph_pair<K,V> entries[length];
}

地图用于编码std::map,std::multimap和 ceph::unordered_map.

复杂类型

这些在源代码中并不难找到，但为方便起见，此处列出了常见的。

UTIME_T

// From /src/include/utime.h
struct utime_t {
        u32le tv_sec;  // Seconds since epoch.
        u32le tv_nsec; // Nanoseconds since the last second.
}

CEPH_ENTITY_NAME

// From /src/include/msgr.h
struct ceph_entity_name {
        u8    type; // CEPH_ENTITY_TYPE_*
        u64le num;
}

// CEPH_ENTITY_TYPE_* defined in /src/include/msgr.h

以前的下一个

网络协议

该文件描述了 Ceph 使用的网络协议。为了理解结构的定义方式，建议先阅读网络编码的介绍。

你好

该协议以握手开始，确认两个节点都在与 ceph 通信并共享一些基本信息。

横幅

第一个动作是服务器向客户端发送横幅。横幅在CEPH_BANNERfrom中定义src/include/msgr.h。接下来是服务器的客户端地址，每个地址都编码为entity_addr_t.

一旦客户端验证服务器横幅与它自己的相匹配，它就会回复它的横幅和它的地址。

连接

一旦横幅得到验证并交换了地址，连接协商就开始了。首先，客户端发送一个ceph_msg_connect包含其信息的结构。

// From src/include/msgr.h
struct ceph_msg_connect {
        u64le features;            // Supported features (CEPH_FEATURE_*)
        u32le host_type;           // CEPH_ENTITY_TYPE_*
        u32le global_seq;          // Number of connections initiated by this host.
        u32le connect_seq;         // Number of connections initiated in this session.
        u32le protocol_version;
        u32le authorizer_protocol;
        u32le authorizer_len;
        u8    flags;               // CEPH_MSG_CONNECT_*
        u8    authorizer[authorizer_len];
}

连接回复

一旦发送了连接，连接就有效地打开了，但是服务器发送的第一条消息必须是连接回复消息。

struct ceph_msg_connect_reply {
        u8    tag; // Tag indicating response code.
        u64le features;
        u32le global_seq;
        u32le connect_seq;
        u32le protocol_version;
        u32le authorizer_len;
        u8    flags;
        u8    authorizer[authorizer_len];
}

MSGR协议

这是传递消息的低级协议。此级别的消息由一个标记字节组成，标识消息类型，后跟消息数据。

// Virtual structure.
struct {
        u8 tag; // CEPH_MSGR_TAG_*
        u8 data[]; // Length depends on tag and data.
}

的长度data由标记字节决定，并通过数组本身的信息取决于消息类型data。

笔记

如果您不了解消息的类型，则无法确定消息的长度。

消息标签在中定义src/include/msgr.h，下面列出了当前的标签以及它们包含的数据。请注意，定义的结构在源代码中不存在，仅用于表示协议。

CEPH_MSGR_TAG_CLOSE (0X06)

struct ceph_msgr_close {
        u8 tag = 0x06;
        u8 data[0]; // No data.
}

关闭消息表示连接正在关闭。

CEPH_MSGR_TAG_MSG (0X07)

struct ceph_msgr_msg {
        u8 tag = 0x07;
        ceph_msg_header header;
        u8 front [header.front_len ];
        u8 middle[header.middle_len];
        u8 data  [header.data_len  ];
        ceph_msg_footer footer;
}

// From src/include/msgr.h
struct ceph_msg_header {
        u64le seq;       // Sequence number.
        u64le tid;       // Transaction ID.
        u16le type;      // Message type (CEPH_MSG_* or MSG_*).
        u16le priority;  // Priority (higher is more important).
        u16le version;   // Version of message encoding.

        u32le front_len;  // The size of the front section.
        u32le middle_len; // The size of the middle section.
        u32le data_len;   // The size of the data section.
        u16le data_off;   // The way data should be aligned by the receiver.

        ceph_entity_name src; // Information about the sender.

        u16le compat_version; // Oldest compatible encoding version.
        u16le reserved;       // Unused.
        u32le crc;            // CRC of header.
}

// From src/include/msgr.h
struct ceph_msg_footer {
        u32le front_crc;  // Checksums of the various sections.
        u32le middle_crc; //
        u32le data_crc;   //
        u64le sig; // Crypographic signature.
        u8    flags;
}

消息是 Ceph 的业务逻辑。它们用于在节点之间发送数据和请求。消息头包含消息的长度，因此可以优雅地处理未知消息。

消息类型常量有两个名称CEPH_MSG_*和MSG_*。两者之间的唯一区别是前者被视为“公共”，而后者仅供内部使用。没有协议级别的差异。

CEPH_MSGR_TAG_ACK (0X08)

struct ceph_msgr_ack {
        u8    tag = 0x08;
        u64le seq; // The sequence number of the message being acknowledged.
}

CEPH_MSGR_TAG_KEEPALIVE (0X09)

struct ceph_msgr_keepalive {
        u8 tag = 0x09;
        u8 data[0]; // No data.
}

CEPH_MSGR_TAG_KEEPALIVE2 (0X0E)

struct ceph_msgr_keepalive2 {
        u8      tag = 0x0E;
        utime_t timestamp;
}

CEPH_MSGR_TAG_KEEPALIVE2_ACK (0X0F)

struct ceph_msgr_keepalive2_ack {
        u8      tag = 0x0F;
        utime_t timestamp;
}

以前的下一个

CEPH 仪表板

概述

Ceph Dashboard 是一个内置的基于 Web 的 Ceph 管理和监控应用程序，您可以通过它检查和管理集群中的各个方面和资源。它作为Ceph Manager Daemon模块实现。

Ceph Luminous 附带的原始 Ceph Dashboard 最初是一个简单的只读视图，用于查看 Ceph 集群的运行时信息和性能数据。它使用了一个非常简单的架构来实现最初的目标。然而，对更丰富的基于 Web 的管理功能的需求不断增长，以便让喜欢 WebUI 而不是 CLI 的用户更容易管理 Ceph。

新的Ceph Dashboard模块为 Ceph Manager 添加了基于 Web 的监控和管理。这个新模块的架构和功能源自openATTIC Ceph 管理和监控工具并受到其启发。开发由SUSE的 openATTIC 团队积极推动，并得到Red Hat和 Ceph 社区成员等公司的支持。

仪表板模块的后端代码使用 CherryPy 框架并实现自定义 REST API。WebUI 实现基于 Angular/TypeScript，包括原始仪表板的功能和最初为独立版本的 openATTIC 开发的新功能。Ceph Dashboard 模块是作为一个应用程序实现的，它通过由托管的 Web 服务器提供信息和统计数据的图形表示ceph-mgr。

功能概述

仪表板提供以下功能：

多用户和角色管理：仪表板支持具有不同权限（角色）的多个用户帐户。可以通过命令行和 WebUI 管理用户帐户和角色。仪表板支持多种增强密码安全性的方法。可以配置密码复杂性规则，要求用户在首次登录后或可配置的时间段后更改密码。有关详细信息，请参阅用户和角色管理。
单点登录 (SSO)：仪表板支持使用 SAML 2.0 协议通过外部身份提供者进行身份验证。有关详细信息，请参阅启用单点登录 (SSO)。
SSL/TLS 支持：Web 浏览器和仪表板之间的所有 HTTP 通信都通过 SSL 进行保护。可以使用内置命令创建自签名证书，但也可以导入由 CA 签名和颁发的自定义证书。有关详细信息，请参阅SSL/TLS 支持。
审计：仪表板后端可以配置为在 Ceph 审计日志中记录所有和 API 请求PUT。有关如何启用此功能的说明，请参阅审核 API 请求。POST``DELETE
国际化 (I18N)：可以在运行时选择用于仪表板文本的语言。

Ceph Dashboard 提供以下监控和管理功能：

Overall cluster health：显示性能和容量指标以及集群状态。
嵌入式 Grafana 仪表板：Ceph 仪表板 Grafana仪表板可以嵌入到外部应用程序和网页中，以显示Prometheus 模块模块收集的信息和性能指标。有关如何配置此功能的详细信息，请参阅启用 Grafana 仪表板的嵌入。
集群日志：显示集群事件和审计日志文件的最新更新。日志条目可以按优先级、日期或关键字进行过滤。
Hosts：显示所有集群主机及其存储驱动器、正在运行的服务以及安装的 Ceph 版本的列表。
性能计数器：显示每个正在运行的服务的详细服务特定统计信息。
Monitors：列出所有 Mons、他们的仲裁状态和打开的会话。
监控：启用 Prometheus 静默的创建、重新创建、编辑和过期，列出警报配置以及所有已配置和触发的警报。显示触发警报的通知。
配置编辑器：显示所有可用的配置选项、它们的描述、类型、默认值和当前设置值。这些也可以编辑。
池：列出 Ceph 池及其详细信息（例如应用程序、pg-autoscaling、归置组、复制大小、EC 配置文件、CRUSH 规则、配额等）
OSD：列出 OSD、它们的状态和使用情况统计信息以及详细信息，例如属性（OSD 映射）、元数据、性能计数器和读/写操作的使用直方图。标记 OSD up/down/out、清除和重新加权 OSD、执行清理操作、修改各种与清理相关的配置选项、选择配置文件以调整回填活动的级别。列出与 OSD 关联的所有驱动器。设置和更改 OSD 的设备类别，按设备类别显示和排序 OSD。在新驱动器和主机上部署 OSD。
设备管理：列出协调器已知的所有主机。列出连接到主机的所有驱动器及其属性。显示驱动器健康预测和 SMART 数据。闪烁外壳 LED。
iSCSI：列出所有运行 TCMU runner 服务的主机，显示所有图像及其性能特征（读/写操作、流量）。创建、修改和删除 iSCSI 目标（通过ceph-iscsi）。显示 iSCSI 网关状态和有关活动启动器的信息。有关如何配置此功能的说明，请参阅启用 iSCSI 管理。
RBD：列出所有 RBD 图像及其属性（大小、对象、特征）。创建、复制、修改和删除 RBD 映像（包括快照）并管理 RBD 命名空间。在全局、每个池或每个图像级别定义各种 I/O 或带宽限制设置。创建、删除和回滚所选图像的快照，保护/取消保护这些快照不被修改。复制或克隆快照，展平克隆图像。
RBD 镜像：启用并配置 RBD 镜像到远程 Ceph 服务器。列出活动守护进程及其状态、池和 RBD 映像，包括同步进度。
CephFS：列出活动的文件系统客户端和关联的池，包括使用统计信息。驱逐活跃的 CephFS 客户端。管理 CephFS 配额和快照。浏览 CephFS 目录结构。
对象网关：列出所有活动的对象网关及其性能计数器。显示和管理（添加/编辑/删除）对象网关用户及其详细信息（例如配额）以及用户的存储桶及其详细信息（例如放置目标、所有者、配额、版本控制、多因素身份验证）。有关配置说明，请参阅启用对象网关管理前端。
NFS：通过 NFS Ganesha 管理 CephFS 文件系统和 RGW S3 存储桶的 NFS 导出。有关如何启用此功能的详细信息，请参阅NFS-Ganesha 管理。
Ceph 管理器模块：启用和禁用 Ceph 管理器模块，管理特定于模块的配置设置。

仪表板着陆页概述

Ceph Dashboard 的登录页面作为主页，具有集群整体状态、性能和容量等指标。它提供有关集群中任何更改的实时更新，并允许快速访问仪表板的其他部分。

../../_images/dashboard-landing-page.png

笔记

您可以将登录页面更改为以前的版本：。编辑该选项会将着陆页从一种视图更改为另一种视图。Cluster >> Manager Modules >> Dashboard >> Edit``FEATURE_TOGGLE_DASHBOARD

请注意，以前版本的着陆页将在未来的版本中被禁用。

细节

提供集群配置的概述，显示集群的各个关键方面。

../../_images/details-card.png

地位

提供集群健康状况的视觉指示，并显示按严重性分组的集群警报。

../../_images/status-card-open.png

容量

Used：显示存储节点（OSD）提供的总物理容量中的已用容量
Warning：显示OSD 的nearfull阈值
危险：显示OSD 的完整阈值

../../_images/容量卡.png

存货

集群内所有资产的清单。提供从此卡的每个项目直接访问仪表板的子页面。

../../_images/库存卡.png

集群利用率

Used Capacity：集群使用的总容量。图表的最大值是集群的最大容量。
IOPS（每秒输入/输出操作数）：读写操作数。
延迟：处理读取或写入请求所需的时间量。
客户端吞吐量：客户端读取或写入集群的数据量。
恢复吞吐量：客户端读取或写入集群的恢复数据量。

../../_images/cluster-utilization-card.png

支持的浏览器

Ceph Dashboard 主要使用以下 Web 浏览器进行测试和开发：

浏览器	版本
Chrome和基于Chromium的浏览器	最新的 2 个主要版本
火狐	最新的 2 个主要版本
火狐 ESR	最新的主要版本

虽然 Ceph Dashboard 可能适用于较旧的浏览器，但我们不能保证兼容性并建议您使浏览器保持最新状态。

启用

如果您是ceph-mgr-dashboard从分发包安装的，包管理系统应该负责安装所有必需的依赖项。

如果您从源代码构建 Ceph 并希望从您的开发环境启动仪表板，请查看源目录中的文件README.rst和。HACKING.rst``src/pybind/mgr/dashboard

在一个正在运行的 Ceph 集群中，Ceph Dashboard 启用了：

ceph mgr module enable dashboard

配置

SSL/TLS 支持

默认情况下，与仪表板的所有 HTTP 连接都使用 SSL/TLS 进行保护。

要快速启动和运行仪表板，您可以生成并安装自签名证书：

ceph dashboard create-self-signed-cert

请注意，大多数 Web 浏览器会抱怨自签名证书，并在与仪表板建立安全连接之前需要明确确认。

要正确保护部署并消除警告，应使用证书颁发机构 (CA) 颁发的证书。

例如，可以使用类似于以下的命令生成密钥对：

openssl req -new -nodes -x509 \
-subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
-keyout dashboard.key -out dashboard.crt -extensions v3_ca

然后该dashboard.crt文件应由 CA 签名。完成后，您可以通过运行以下命令为 Ceph 管理器实例启用它：

ceph dashboard set-ssl-certificate -i dashboard.crt
ceph dashboard set-ssl-certificate-key -i dashboard.key

如果每个管理器实例都需要唯一的证书，可以按如下方式包含实例的名称（其中$name是实例的名称ceph-mgr，通常是主机名）：

ceph dashboard set-ssl-certificate $name -i dashboard.crt
ceph dashboard set-ssl-certificate-key $name -i dashboard.key

也可以通过设置此配置值来禁用 SSL：

ceph config set mgr mgr/dashboard/ssl false

如果仪表板将在其上游服务器不支持 SSL 的代理后面运行，或者在不需要或不需要 SSL 的其他情况下运行，这可能很有用。有关详细信息，请参阅代理配置。

警告

禁用 SSL 时要小心，因为用户名和密码将以未加密的方式发送到仪表板。

笔记

更改 SSL 证书和密钥后，您必须重新启动 Ceph 管理器进程。这可以通过运行或禁用并重新启用仪表板模块（这也会触发管理器重新生成自身）来完成：ceph mgr fail mgr

ceph mgr module disable dashboard
ceph mgr module enable dashboard

主机名和端口

与大多数 Web 应用程序一样，仪表板绑定到 TCP/IP 地址和 TCP 端口。

默认情况下，ceph-mgr托管仪表板的守护程序（即当前活动的管理器）将在禁用 SSL 时绑定到 TCP 端口 8443 或 8080。

如果未配置特定地址，Web 应用程序将绑定到::，它对应于所有可用的 IPv4 和 IPv6 地址。

这些默认值可以通过集群范围级别的配置密钥工具进行更改（因此它们适用于所有管理器实例），如下所示：

ceph config set mgr mgr/dashboard/server_addr $IP
ceph config set mgr mgr/dashboard/server_port $PORT
ceph config set mgr mgr/dashboard/ssl_server_port $PORT

由于每个ceph-mgr主机都有自己的仪表板实例，因此可能需要单独配置它们。可以使用以下命令更改特定管理器实例的 IP 地址和端口：

ceph config set mgr mgr/dashboard/$name/server_addr $IP
ceph config set mgr mgr/dashboard/$name/server_port $PORT
ceph config set mgr mgr/dashboard/$name/ssl_server_port $PORT

替换$name为托管仪表板的 ceph-mgr 实例的 ID。

笔记

该命令将向您显示当前配置的所有端点。查找密钥以获取用于访问仪表板的 URL。ceph mgr services``dashboard

用户名和密码

为了能够登录，您需要创建一个用户帐户并将其与至少一个角色相关联。我们提供了一组您可以使用的预定义*系统角色。*有关详细信息，请参阅用户和角色管理部分。

要创建具有管理员角色的用户，您可以使用以下命令：

ceph dashboard ac-user-create <username> -i <file-containing-password> administrator

帐户锁定

如果用户多次重复输入错误的凭据，它会禁用用户帐户。默认情况下启用它以防止暴力或字典攻击。用户可以分别使用以下命令获取或设置默认的锁定尝试次数：

ceph dashboard get-account-lockout-attempts
ceph dashboard set-account-lockout-attempts <value:int>

警告

可以通过将默认的锁定尝试次数设置为 0 来禁用此功能。但是，通过禁用此功能，帐户更容易受到基于暴力或字典的攻击。这可以通过以下方式禁用：

ceph dashboard set-account-lockout-attempts 0

启用锁定用户

如果用户帐户因多次无效登录尝试而被禁用，则需要由管理员手动启用。这可以通过以下命令完成：

ceph dashboard ac-user-enable <username>

访问仪表板

您现在可以使用您的（启用 JavaScript 的）Web 浏览器访问仪表板，方法是将其指向任何主机名或 IP 地址以及运行管理器实例的选定 TCP 端口：例如，http(s)://<$IP>:<$PORT>/.

仪表板页面显示并请求先前定义的用户名和密码。

启用对象网关管理前端

当使用 cephadm 部署 RGW 时，将自动配置仪表板使用的 RGW 凭据。您还可以手动强制设置凭据：

ceph dashboard set-rgw-credentials

dashboard这将为系统中的每个领域创建一个具有 uid 的 RGW 用户。

如果您在 RGW 管理 API 中配置了自定义“管理”资源，您也应该在此处进行设置：

ceph dashboard set-rgw-api-admin-resource <admin_resource>

如果您在对象网关设置中使用自签名证书，则应在仪表板中禁用证书验证以避免连接被拒绝，例如由未知 CA 签名的证书或与主机名不匹配引起的连接：

ceph dashboard set-rgw-api-ssl-verify False

如果对象网关处理请求的时间太长并且仪表板超时，您可以根据需要设置超时值：

ceph dashboard set-rest-requests-timeout <seconds>

默认值为 45 秒。

启用 ISCSI 管理

Ceph Dashboard 可以使用 Ceph iSCSI 网关rbd-target-api服务提供的 REST API 来管理 iSCSI 目标。请确保已在 iSCSI 网关上安装并启用它。

笔记

Ceph Dashboard 的 iSCSI 管理功能依赖于ceph-iscsi项目的最新版本 3 。确保您的操作系统提供正确的版本，否则仪表板将无法启用管理功能。

如果ceph-iscsiREST API 配置为 HTTPS 模式且使用自签名证书，则需要配置 dashboard 在访问 ceph-iscsi API 时避免 SSL 证书验证。

要禁用 API SSL 验证，请运行以下命令：

ceph dashboard set-iscsi-api-ssl-verification false

必须使用以下命令定义可用的 iSCSI 网关：

ceph dashboard iscsi-gateway-list
# Gateway URL format for a new gateway: <scheme>://<username>:<password>@<host>[:port]
ceph dashboard iscsi-gateway-add -i <file-containing-gateway-url> [<gateway_name>]
ceph dashboard iscsi-gateway-rm <gateway_name>

启用 GRAFANA 仪表板的嵌入

Grafana从 Prometheus中提取数据。尽管 Grafana 可以使用其他数据源，但我们提供的 Grafana 仪表板包含特定于 Prometheus 的查询。因此，我们的 Grafana 仪表板需要 Prometheus 作为数据源。Ceph Prometheus Module 模块以 Prometheus 说明格式导出其数据。这些 Grafana 仪表板依赖于来自 Prometheus 模块和节点导出器的指标名称。节点导出器是一个单独的应用程序，提供机器指标。

笔记

Prometheus 的安全模型假定不受信任的用户可以访问 Prometheus HTTP 端点和日志。不受信任的用户可以访问 Prometheus 收集的包含在数据库中的所有（元）数据，以及各种操作和调试信息。

但是，Prometheus 的 HTTP API 仅限于只读操作。无法使用 API 更改配置，也不会暴露机密。此外，Prometheus 有一些内置的措施来减轻拒绝服务攻击的影响。

请参阅Prometheus 的安全模型 https://prometheus.io/docs/operating/security/了解更多详细信息。

使用 CEPHADM 安装和配置

可以使用Cephadm安装 Grafana 和 Prometheus 。它们将由自动配置cephadm。有关如何用于安装和配置 Prometheus 和 Grafana 的更多详细信息，请参阅监控服务cephadm文档。

手动安装和配置

以下过程描述了如何手动配置 Grafana 和 Prometheus。在适当的主机上安装 Prometheus、Grafana 和 Node exporter 后，继续执行以下步骤。

通过运行以下命令启用作为 Ceph Manager 模块的 Ceph Exporter：
```
ceph mgr module enable prometheus
```
可以在Prometheus Module的文档中找到更多详细信息。
在 Prometheus 中添加相应的 scrape 配置。这可能看起来像：
```
global:
  scrape_interval: 5s
   
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'ceph'
    static_configs:
      - targets: ['localhost:9283']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['localhost:9100']
```
笔记

请注意，在上面的示例中，Prometheus 配置为从自身（端口 9090）、导出 Ceph 内部数据的 Ceph 管理器模块 prometheus（端口 9283）和提供操作系统和服务的节点导出器（端口 9100）中抓取数据每个主机的硬件指标。

根据您的配置，您可能需要更改节点导出器的主机名或添加其他配置条目。您不太可能需要更改默认的 TCP 端口。

此外，您不需要为Ceph 特定数据设置多个目标，由prometheus mgr 模块提供。但建议将 Prometheus 配置为从所有现有 Ceph 管理器中抓取 Ceph 特定数据。这启用了内置的高可用性机制，因此如果一个 Ceph 管理器出现故障，在管理器主机上运行的服务将在另一台管理器主机上自动重启。
使用 Grafana Web UI将 Prometheus 作为数据源添加到 Grafana 。

重要的

数据源必须命名为“Dashboard1”。

使用以下命令安装vonage-status-panel 和 grafana-piechart-panel插件：

grafana-cli plugins install vonage-status-panel
grafana-cli plugins install grafana-piechart-panel

将仪表板添加到 Grafana：

可以通过导入仪表板 JSON 文件将仪表板添加到 Grafana。使用以下命令下载 JSON 文件：
```
wget https://raw.githubusercontent.com/ceph/ceph/main/monitoring/ceph-mixin/dashboards_out/<Dashboard-name>.json
```
您可以在此处找到各种仪表板 JSON 文件。

例如，对于 ceph 集群概述，您可以使用：
```
wget https://raw.githubusercontent.com/ceph/ceph/main/monitoring/ceph-mixin/dashboards_out/ceph-cluster.json
```
您也可以编写自己的仪表板。
配置匿名模式/etc/grafana/grafana.ini：
```
[auth.anonymous]
enabled = true
org_name = Main Org.
org_role = Viewer
```
在较新版本的 Grafana（从 6.2.0-beta1 开始）中， allow_embedding引入了一个名为的新设置。此设置必须显式设置true为 Ceph Dashboard 中的 Grafana 集成才能正常工作，因为默认值为false。
```
[security]
allow_embedding = true
```

启用 RBD-IMAGE 监控

默认情况下禁用 RBD 图像的监视，因为它会显着影响性能。有关更多信息，请参阅Ceph 健康检查。禁用后，概览和详细信息仪表板在 Grafana 中将为空，并且指标在 Prometheus 中不可见。

配置仪表板

设置好 Grafana 和 Prometheus 后，您需要配置 Ceph Dashboard 用于访问 Grafana 的连接信息。

您需要告诉仪表板 Grafana 实例在哪个 URL 上运行/部署：

ceph dashboard set-grafana-api-url <grafana-server-url>  # default: ''

URL 的格式：://:

笔记

Ceph 仪表板通过iframeHTML 元素嵌入 Grafana 仪表板。如果在不支持 SSL/TLS 的情况下配置 Grafana，如果为仪表板启用了 SSL 支持（这是默认设置），大多数浏览器将阻止嵌入不安全的内容。如果在如上所述启用嵌入式 Grafana 仪表板后看不到它们，请查看浏览器的文档以了解如何取消阻止混合内容。或者，考虑在 Grafana 中启用 SSL/TLS 支持。

如果您为 Grafana 使用自签名证书，请在仪表板中禁用证书验证以避免连接被拒绝，这可能是由于未知 CA 签署的证书或与主机名不匹配的结果：

ceph dashboard set-grafana-api-ssl-verify False

您还可以直接访问 Grafana 以监控您的集群。

笔记

Ceph Dashboard 配置信息也可以取消设置。例如，要清除我们上面配置的 Grafana API URL：

ceph dashboard reset-grafana-api-url

浏览器的替代 URL

Ceph 仪表板后端需要 Grafana URL 才能在前端加载它们之前验证 Grafana 仪表板的存在。由于 Grafana 在 Ceph Dashboard 中的实现方式的性质，这意味着需要两个工作连接才能在 Ceph Dashboard 中看到 Grafana 图：

后端（Ceph Mgr 模块）需要验证请求的图是否存在。如果此请求成功，它会让前端知道它可以安全地访问 Grafana。
然后，前端使用 iframe 直接从用户的浏览器请求 Grafana 图表。通过 Ceph Dashboard 直接访问 Grafana 实例，不走任何弯路。

现在，您的环境可能会导致用户浏览器难以直接访问在 Ceph Dashboard 中配置的 URL。为了解决这个问题，可以配置一个单独的 URL，它只用于告诉前端（用户的浏览器）应该使用哪个 URL 来访问 Grafana。此设置永远不会自动更改，这与Cephadm设置的 GRAFANA_API_URL 不同（仅当 cephadm 用于部署监控服务时）。

要更改返回到前端的 URL，请发出以下命令：

ceph dashboard set-grafana-frontend-api-url <grafana-server-url>

如果没有为该选项设置值，它将简单地回退到 GRAFANA_API_URL 选项的值。如果设置，它将指示浏览器使用此 URL 访问 Grafana。

启用单点登录 (SSO)

Ceph Dashboard 支持通过 SAML 2.0协议对用户进行外部身份验证。您需要首先创建用户帐户并将它们与所需的角色相关联，因为授权是由仪表板执行的。但是，身份验证过程可以由现有身份提供者 (IdP) 执行。

笔记

Ceph Dashboard SSO 支持依赖于 onelogin 的 python-saml库。请确保此库已安装在您的系统上，方法是使用您的发行版的包管理或通过 Python 的pip安装程序。

要在 Ceph Dashboard 上配置 SSO，您应该使用以下命令：

ceph dashboard sso setup saml2 <ceph_dashboard_base_url> <idp_metadata> {<idp_username_attribute>} {<idp_entity_id>} {<sp_x_509_cert>} {<sp_private_key>}

参数：

<ceph_dashboard_base_url>：可访问 Ceph Dashboard 的基本 URL（例如https://cephdashboard.local）
<idp_metadata>：指向远程（http://、https://）或本地（file://）路径或 IdP 元数据 XML 内容的 URL（例如，https://myidp/metadata、file:///家/我的用户/元数据.xml）。
<idp_username_attribute> （可选）：应该用于从身份验证响应中获取用户名的属性。默认为uid。
<idp_entity_id> （可选）：当 IdP 元数据中存在多个实体 ID 时使用此选项。
<sp_x_509_cert> / <sp_private_key> （可选）：Ceph Dashboard（服务提供商）用于签名和加密的证书文件路径（这些文件路径应该可以从活动的 ceph-mgr 实例访问）。

笔记

SAML 请求的颁发者值将遵循以下模式： <ceph_dashboard_base_url> /auth/saml2/metadata

要显示当前的 SAML 2.0 配置，请使用以下命令：

ceph dashboard sso show saml2

笔记

有关onelogin_settings的更多信息，请查看onelogin 文档。

要禁用 SSO：

ceph dashboard sso disable

检查 SSO 是否启用：

ceph dashboard sso status

要启用 SSO：

ceph dashboard sso enable saml2

启用普罗米修斯警报

要使用 Prometheus 进行警报，您必须定义警报规则。这些由Alertmanager管理。如果您还没有使用 Alertmanager，请在它接收和管理来自 Prometheus 的警报时安装它。

仪表板可以通过三种不同的方式使用 Alertmanager 功能：

使用仪表板的通知接收器。
使用普罗米修斯警报管理器 API。
同时使用两个来源。

所有三种方法都会通知您有关警报的信息。如果您同时使用这两个来源，您将不会收到两次通知，但您至少需要使用 Alertmanager API 才能管理静默。

使用仪表板的通知接收器

这允许您按照 Alertmanager 的配置获取通知。发送通知后，您将在仪表板内收到通知，但您无法管理警报。

将仪表板接收器和新路由添加到您的 Alertmanager 配置中。这应该是这样的：
route:
  receiver: 'ceph-dashboard'
...
receivers:
  - name: 'ceph-dashboard'
    webhook_configs:
    - url: '<url-to-dashboard>/api/prometheus_receiver'
确保 Alertmanager 在仪表板方面认为您的 SSL 证书有效。有关正确配置的更多信息，请查看文档。

使用 Prometheus 的 API 和 Alertmanager

这允许您管理警报和静音，并将启用“活动警报”、“所有警报”以及“集群”菜单项的“监控”部分中的“静音”选项卡。

警报可以按名称、工作、严重性、状态和开始时间排序。不幸的是，无法知道警报何时通过警报管理器根据您的配置发出通知，这就是为什么仪表板将通知用户警报的任何可见更改并将通知更改的警报。

沉默可以按 id、创建者、状态、开始、更新和结束时间排序。可以通过多种方式创建静音，也可以使它们过期。

从头开始创建

基于选定的警报

从过期的沉默中重建

更新静默（这将重新创建并使其过期（默认的 Alertmanager 行为））

要使用它，请指定 Alertmanager 服务器的主机和端口：
ceph dashboard set-alertmanager-api-host <alertmanager-host:port>  # default: ''
例如：
ceph dashboard set-alertmanager-api-host 'http://localhost:9093'
为了能够查看所有配置的警报，您需要配置 Prometheus API 的 URL。使用此 API，UI 还将帮助您验证新的静音是否与相应的警报相匹配。
ceph dashboard set-prometheus-api-host <prometheus-host:port>  # default: ''
例如：
ceph dashboard set-prometheus-api-host 'http://localhost:9090'
设置主机后，刷新浏览器的仪表板窗口或选项卡。

两种方法都用

这两种方法的行为都以它们不应相互干扰的方式配置，因为可能会弹出烦人的重复通知。

如果您在 Prometheus 或 Alertmanager 设置中使用自签名证书，则应在仪表板中禁用证书验证，以避免由未知 CA 签名的证书或与主机名不匹配的证书导致拒绝连接。

对于普罗米修斯：

ceph dashboard set-prometheus-api-ssl-verify False

对于警报管理器：

ceph dashboard set-alertmanager-api-ssl-verify False

用户和角色管理

密码政策

默认情况下启用密码策略功能，其中包括以下检查：

密码是否超过 N 个字符？
旧密码和新密码一样吗？

密码策略功能可以完全打开或关闭：

ceph dashboard set-pwd-policy-enabled <true|false>

还可以打开或关闭以下个别检查：

ceph dashboard set-pwd-policy-check-length-enabled <true|false>
ceph dashboard set-pwd-policy-check-oldpwd-enabled <true|false>
ceph dashboard set-pwd-policy-check-username-enabled <true|false>
ceph dashboard set-pwd-policy-check-exclusion-list-enabled <true|false>
ceph dashboard set-pwd-policy-check-complexity-enabled <true|false>
ceph dashboard set-pwd-policy-check-sequential-chars-enabled <true|false>
ceph dashboard set-pwd-policy-check-repetitive-chars-enabled <true|false>

此外，以下选项可用于配置密码策略。

最小密码长度（默认为 8）：

ceph dashboard set-pwd-policy-min-length <N>

最小密码复杂性（默认为 10）：
```
ceph dashboard set-pwd-policy-min-complexity <N>
```
密码复杂度是通过对密码中的每个字符进行分类来计算的。复杂性计数从 0 开始。字符按给定顺序按照以下规则进行评级。
- 如果字符是数字，则增加 1。
- 如果字符是小写 ASCII 字符，则增加 1。
- 如果字符是大写 ASCII 字符，则增加 2。
- 如果字符是特殊字符，如，则增加 3 !"#$%&'()*+,-./:;<=>?@[\]^_{|}~`。
- 如果角色没有被前面的规则之一分类，则增加 5。

不允许在密码中使用的逗号分隔词列表：

ceph dashboard set-pwd-policy-exclusion-list <word>[,...]

用户帐户

Ceph Dashboard 支持多个用户帐户。每个用户帐户都包含一个用户名、一个密码（使用以加密形式存储bcrypt）、一个可选的名称和一个可选的电子邮件地址。

如果通过 Web UI 创建新用户，则可以设置用户在首次登录时必须分配新密码的选项。

用户帐户存储在监视器的配置数据库中，并且可供所有ceph-mgr实例使用。

我们提供了一组 CLI 命令来管理用户帐户：

显示用户：

ceph dashboard ac-user-show [<username>]

创建用户：

ceph dashboard ac-user-create [--enabled] [--force-password] [--pwd_update_required] <username> -i <file-containing-password> [<rolename>] [<name>] [<email>] [<pwd_expiration_date>]

要绕过密码策略检查，请使用force-password选项。添加选项pwd_update_required以便新创建的用户在首次登录后必须更改其密码。

删除用户：

ceph dashboard ac-user-delete <username>

更改密码：

ceph dashboard ac-user-set-password [--force-password] <username> -i <file-containing-password>

更改密码哈希：
```
ceph dashboard ac-user-set-password-hash <username> -i <file-containing-password-hash>
```
散列必须是 bcrypt 散列和盐，例如$2b$12$Pt3Vq/rDt2y9glTPSV.VFegiLkQeIpddtkhoFetNApYmIJOY8gau2. 这可用于从外部数据库导入用户。

修改用户（姓名和电子邮件）：

ceph dashboard ac-user-set-info <username> <name> <email>

禁用用户：

ceph dashboard ac-user-disable <username>

启用用户：

ceph dashboard ac-user-enable <username>

用户角色和权限

用户帐户与一组定义可以访问哪些仪表板功能的角色相关联。

仪表板功能/模块在安全范围内分组。安全范围是预定义的和静态的。当前可用的安全范围是：

hosts：包括与菜单条目相关的所有功能Hosts。
config-opt：包括与 Ceph 配置选项管理相关的所有功能。
pool：包括与池管理相关的所有功能。
osd：包括与 OSD 管理相关的所有功能。
monitor：包括与监视器管理相关的所有功能。
rbd-image：包括与 RBD 图像管理相关的所有功能。
rbd-mirroring：包括与 RBD 镜像管理相关的所有功能。
iscsi：包括与 iSCSI 管理相关的所有功能。
rgw：包括与 RADOS 网关 (RGW) 管理相关的所有功能。
cephfs：包括与 CephFS 管理相关的所有功能。
nfs-ganesha：包括与 NFS Ganesha 管理相关的所有功能。
manager：包括与 Ceph Manager 管理相关的所有功能。
log：包括与 Ceph 日志管理相关的所有功能。
grafana：包括与 Grafana 代理相关的所有功能。
prometheus：包括与 Prometheus 警报管理相关的所有功能。
dashboard-settings：允许更改仪表板设置。

角色指定安全范围和**权限集之间的一组映射。有四种类型的权限：

读
创造
更新
删除

请参阅下面的 Python 字典形式的角色规范示例：

# example of a role
{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

上述角色表示用户对池管理相关特性具有读取和创建权限，对RBD镜像管理相关特性具有完全权限。

Dashboard 提供了一组预定义的角色，我们称之为 系统角色，新安装的 Ceph Dashboard 可以立即使用这些角色。

系统角色列表如下：

administrator：允许所有安全范围的完全权限。
只读：允许对除仪表板设置之外的所有安全范围的读取权限。
block-manager ：允许对rbd-image、 rbd-mirroring和iscsi范围的完全权限。
rgw-manager ：允许对rgw范围的完全权限
cluster-manager ：允许对hosts、osd、 monitor、manager和config-opt范围的完全权限。
pool-manager ：允许池范围的完全权限。
cephfs-manager ：允许对cephfs范围的完全权限。

可以使用以下命令检索可用角色列表：

ceph dashboard ac-role-show [<rolename>]

您还可以使用 CLI 创建新角色。可用的命令如下：

创建角色：

ceph dashboard ac-role-create <rolename> [<description>]

删除角色：

ceph dashboard ac-role-delete <rolename>

将范围权限添加到角色：

ceph dashboard ac-role-add-scope-perms <rolename> <scopename> <permission> [<permission>...]

从角色中删除范围权限：

ceph dashboard ac-role-del-scope-perms <rolename> <scopename>

要为用户分配角色，可以使用以下命令：

设置用户角色：

ceph dashboard ac-user-set-roles <username> <rolename> [<rolename>...]

为用户添加角色：

ceph dashboard ac-user-add-roles <username> <rolename> [<rolename>...]

从用户中删除角色：

ceph dashboard ac-user-del-roles <username> <rolename> [<rolename>...]

用户和自定义角色创建示例

在本节中，我们将展示创建用户帐户的命令的完整示例，该用户帐户可以管理 RBD 映像、查看和创建 Ceph 池，并对其他范围具有只读访问权限。

创建用户：

ceph dashboard ac-user-create bob -i <file-containing-password>

创建角色并指定范围权限：

ceph dashboard ac-role-create rbd/pool-manager
ceph dashboard ac-role-add-scope-perms rbd/pool-manager rbd-image read create update delete
ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

将角色关联到用户：

ceph dashboard ac-user-set-roles bob rbd/pool-manager read-only

代理配置

在具有多个实例的 Ceph 集群中ceph-mgr，只有在当前活动的守护进程上运行的仪表板ceph-mgr才会处理传入的请求。与备用实例上仪表板的 TCP 端口的连接ceph-mgr将接收到活动管理器的仪表板 URL 的 HTTP 重定向 (303)。这使您能够将浏览器指向任何ceph-mgr实例以访问仪表板。

如果你想建立一个固定的 URL 来访问仪表板，或者如果你不想允许直接连接到管理器节点，你可以设置一个代理，自动将传入的请求转发到活动实例ceph-mgr 。

配置 URL 前缀

如果您通过反向代理访问仪表板，您可能希望在 URL 前缀下提供服务。要让仪表板使用包含您的前缀的超链接，您可以设置以下 url_prefix设置：

ceph config set mgr mgr/dashboard/url_prefix $PREFIX

这样您就可以访问仪表板了http://$IP:$PORT/$PREFIX/。

禁用重定向

如果仪表板位于负载平衡代理（如HAProxy）之后，您可能希望禁用重定向以防止将内部（无法解析的）URL 发布到前端客户端的情况。使用以下命令让仪表板响应 HTTP 错误（默认为 500），而不是重定向到活动仪表板：

ceph config set mgr mgr/dashboard/standby_behaviour "error"

要将设置重置为默认重定向，请使用以下命令：

ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

配置错误状态码

禁用重定向后，您可能希望自定义备用仪表板的 HTTP 状态代码。为此，您需要运行以下命令：

ceph config set mgr mgr/dashboard/standby_error_status_code 503

重定向前将 IP 地址解析为主机名

从备用仪表板到活动仪表板的重定向是通过 IP 地址完成的。这样做是因为在容器化环境中将 IP 地址解析为主机名很容易出错。这也是默认情况下禁用该选项的原因。但是，在某些情况下，通过主机名重定向可能会有所帮助。例如，如果配置的 TLS 证书仅匹配主机名。要通过主机名激活重定向，请运行以下命令：

$ ceph config set mgr mgr/dashboard/redirect_resolve_ip_addr True

您可以通过以下方式再次禁用它：

$ ceph config set mgr mgr/dashboard/redirect_resolve_ip_addr False

HAPROXY 示例配置

您将在下面找到使用HAProxy进行 SSL/TLS 直通的示例配置。

请注意，此配置在以下条件下有效。如果仪表板故障转移，前端客户端可能会收到 HTTP 重定向 (303) 响应，并将被重定向到无法解析的主机。当两次 HAProxy 健康检查之间发生故障转移时，就会发生这种情况。在这种情况下，先前活动的仪表板节点现在将使用指向新活动节点的 303 进行响应。为防止出现这种情况，您应该考虑在备用节点上禁用重定向。

defaults
  log global
  option log-health-checks
  timeout connect 5s
  timeout client 50s
  timeout server 450s

frontend dashboard_front
  mode http
  bind *:80
  option httplog
  redirect scheme https code 301 if !{ ssl_fc }

frontend dashboard_front_ssl
  mode tcp
  bind *:443
  option tcplog
  default_backend dashboard_back_ssl

backend dashboard_back_ssl
  mode tcp
  option httpchk GET /
  http-check expect status 200
  server x <HOST>:<PORT> ssl check verify none
  server y <HOST>:<PORT> ssl check verify none
  server z <HOST>:<PORT> ssl check verify none

审计 API 请求

REST API 可以将 PUT、POST 和 DELETE 请求记录到 Ceph 审计日志中。默认情况下禁用此功能，但可以使用以下命令启用：

ceph dashboard set-audit-api-enabled <true|false>

如果启用，则每个请求都会记录以下参数：

from - 请求的来源，例如[https://::1]:44410
path - REST API 路径，例如 /api/auth
方法 - 例如 PUT、POST 或 DELETE
user - 用户名，否则为“无”

默认情况下启用请求有效负载（参数及其值）的日志记录。执行以下命令以禁用此行为：

ceph dashboard set-audit-api-log-payload <true|false>

日志条目可能如下所示：

2018-10-22 15:27:01.302514 mgr.x [INF] [DASHBOARD] from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/klaus' method='PUT' user='admin' params='{"max_buckets": "1000", "display_name": "Klaus Mustermann", "uid": "klaus", "suspended": "0", "email": "klaus.mustermann@ceph.com"}'

NFS-象头神管理

仪表板需要启用 NFS 模块，该模块将用于管理 NFS 集群和 NFS 导出。有关更多信息，请查看通过 NFS 的 CephFS 和 RGW 导出。

插件

插件以模块化和松散耦合的方式扩展 Ceph Dashboard 的功能。

功能切换

此插件允许按需启用或禁用 Ceph Dashboard 中的某些功能。当功能被禁用时：

它的前端元素（网页、菜单条目、图表等）将被隐藏。
其关联的 REST API 端点将拒绝任何进一步的请求（404，未找到错误）。

该插件的主要目的是允许对仪表板公开的工作流进行临时定制。此外，它还允许以最小的配置负担动态启用实验性功能，并且不会影响服务。

可以启用/禁用的功能列表是：

- 块（RBD）：
  
  图像管理：rbd镜像：mirroringiSCSI：iscsi
文件系统（Cephfs）：cephfs
对象（RGW）：（rgw包括守护进程、用户和桶管理）。
NFS：nfs-ganesha出口。

默认情况下，所有功能都已启用。

要检索功能列表及其当前状态：

ceph dashboard feature status
Feature 'cephfs': 'enabled'
Feature 'iscsi': 'enabled'
Feature 'mirroring': 'enabled'
Feature 'rbd': 'enabled'
Feature 'rgw': 'enabled'
Feature 'nfs': 'enabled'

要启用或禁用单个或多个功能的状态：

ceph dashboard feature disable iscsi mirroring
Feature 'iscsi': disabled
Feature 'mirroring': disabled

功能状态发生变化后，API REST 端点会立即响应该变化，而对于前端 UI 元素，最多可能需要 20 秒才能反映出来。

调试

此插件允许根据调试模式自定义仪表板的行为。可以使用以下命令启用、禁用或检查它：

ceph dashboard debug status
Debug: 'disabled'
ceph dashboard debug enable
Debug: 'enabled'
ceph dashboard debug disable
Debug: 'disabled'

默认情况下，它是禁用的。这是生产部署的推荐设置。如果需要，无需重新启动即可启用调试模式。目前，禁用调试模式等于 CherryPyproduction环境，而启用时，它使用test_suite默认值（请参阅 CherryPy 环境以获取更多详细信息）。

它还unique_id在不支持此功能的版本上将请求 uuid ( ) 添加到 Cherrypy。它还打印unique_id错误响应和日志消息。

今日消息 (MOTD)

在 Ceph 仪表板的顶部显示当天的配置消息。

MOTD 的重要性可以通过其严重性进行配置，即 info、warning或danger。MOTD 可以在给定时间后过期，这意味着它不会再显示在 UI 中。使用以下语法指定到期时间：Ns|m|h|d|w表示秒、分钟、小时、天和周。如果 MOTD 应在 2 小时后到期，请使用2 小时或5 周，持续 5 周。使用0配置不会过期的 MOTD。

要配置 MOTD，请运行以下命令：

ceph dashboard motd set <severity:info|warning|danger> <expires> <message>

显示配置的 MOTD：

ceph dashboard motd get

要清除配置的 MOTD 运行：

ceph dashboard motd clear

具有信息或警告严重性的 MOTD可以由用户关闭。在清除本地存储 cookie 或显示具有不同严重性的新 MOTD 之前，不再显示信息 MOTD 。具有“警告”严重性的 MOTD 将在新会话中再次显示。

仪表板故障排除

定位仪表板

如果您不确定 Ceph Dashboard 的位置，请运行以下命令：

ceph mgr services | jq .dashboard
"https://host:port"

该命令返回 Ceph Dashboard 所在的 URL：https://<host>:<port>/

笔记

许多 Ceph 工具以 JSON 格式返回结果。我们建议您安装jq命令行实用程序以方便处理 JSON 数据。

访问仪表板

如果您无法访问 Ceph Dashboard，请运行以下命令：

验证 Ceph Dashboard 模块是否已启用：
```
ceph mgr module ls | jq .enabled_modules
```
确保命令的返回值中列出了 Ceph Dashboard 模块。上面命令的示例输出：
```
[
  "dashboard",
  "iostat",
  "restful"
]
```
如果未列出，请使用以下命令激活模块：
```
ceph mgr module enable dashboard
```
检查 Ceph 仪表板和/或ceph-mgr日志文件是否有任何错误。
- 通过以下方式检查ceph-mgr日志消息是否写入文件：
```
ceph config get mgr log_to_file
```
```
true
```
- 获取日志文件的位置（/var/log/ceph/<cluster-name>-<daemon-name>.log 默认情况下）：
```
ceph config get mgr log_file
```
```
/var/log/ceph/$cluster-$name.log
```
确保正确配置 SSL/TSL 支持：
- 检查是否启用了 SSL/TSL 支持：
```
ceph config get mgr mgr/dashboard/ssl
```
- 如果命令返回true，请通过以下方式验证证书是否存在：
```
ceph config-key get mgr/dashboard/crt
```
  和：
```
ceph config-key get mgr/dashboard/key
```
- 如果没有返回true，请运行以下命令生成自签名证书或按照 SSL/TLS 支持中概述的说明进行操作：
```
ceph dashboard create-self-signed-cert
```

登录仪表板时遇到问题

如果您无法登录 Ceph 仪表板并收到以下错误，请执行以下程序检查：

../../_images/invalid-credentials.png

检查您的用户凭据是否正确。如果您在尝试登录 Ceph Dashboard 时看到上面的通知消息，很可能是您使用了错误的凭据。仔细检查您的用户名和密码，并确保您的键盘的大写锁定不是意外启用的。
如果您的用户凭据正确，但您遇到同样的错误，请检查用户帐户是否存在：
```
ceph dashboard ac-user-show <username>
```
此命令返回您的用户数据。如果用户不存在，它将打印：
```
Error ENOENT: User <username> does not exist
```
检查用户是否启用：
```
ceph dashboard ac-user-show <username> | jq .enabled
```
```
true
```
检查是否为您的用户enabled设置为。true如果不是用户未启用，请运行：
```
ceph dashboard ac-user-enable <username>
```

有关详细信息，请参阅用户和角色管理。

仪表板功能不工作

当后端发生错误时，您通常会在前端收到错误通知。通过以下场景进行调试。

检查 Ceph 仪表板和ceph-mgr日志文件是否有任何错误。这些可以通过搜索关键字找到，例如500 Internal Server Error，然后是traceback。回溯的末尾包含有关发生的确切错误的更多详细信息。
检查您的网络浏览器的 Javascript 控制台是否有任何错误。

CEPH 仪表板日志

仪表板调试标志

启用此标志后，错误回溯将包含在后端响应中。

要通过 Ceph 仪表板启用此标志，请从Cluster导航到Manager modules。选择仪表板模块并单击编辑按钮。单击调试复选框并更新。

要通过 CLI 启用它，请运行以下命令：

ceph dashboard debug enable

设置仪表板模块的日志记录级别

将日志记录级别设置为调试会使日志更加详细并有助于调试。

提高管理器守护进程的日志记录级别：
```
ceph tell mgr config set debug_mgr 20
```
通过 Dashboard 或 CLI 调整 Ceph Dashboard 模块的日志级别：
- 从集群导航到管理器模块。选择仪表板模块 并单击编辑按钮。修改log_level配置。
- 要通过 CLI 对其进行调整，请运行以下命令：
```
bin/ceph config set mgr mgr/dashboard/log_level debug
```

\3. 高日志级别会导致相当大的日志量，很容易填满您的文件系统。为未来的一小时、一天或一周设置日历提醒，以恢复此临时日志记录增加。这看起来像这样：

ceph config log
...
--- 11 --- 2020-11-07 11:11:11.960659 --- mgr.x/dashboard/log_level = debug ---
...
ceph config reset 11

在仪表板中启用集中日志记录

要了解有关集中式日志记录的更多信息，请参阅Ceph 中的集中式日志记录

使用“创建服务”选项在任何特定主机上创建 Loki 服务。
类似地创建将默认部署在所有正在运行的主机上的 Promtail 服务。
要查看调试级消息和信息级事件，请通过 CLI 运行以下命令：
```
ceph config set mgr mgr/cephadm/log_to_cluster_level debug
```

要启用文件日志记录，请通过 CLI 运行以下命令：

ceph config set global log_to_file true
ceph config set global mon_cluster_log_to_file true

单击 Cluster -> Logs 下的 Daemon Logs 选项卡。
您可以在单击日志浏览器按钮时找到一些预定义的标签，例如文件名、作业等，可以帮助您一次性查询日志。
您可以使用 LogQL 查询日志以进行高级搜索并执行一些计算 - https://grafana.com/docs/loki/latest/logql/。

从仪表板报告问题

Ceph-Dashboard 提供了两种在 Ceph Issue Tracker 中创建问题的方法，使用 Ceph 命令行界面或使用 Ceph Dashboard 用户界面。

要在 Ceph Issue Tracker 中创建问题，用户需要在问题跟踪器上拥有一个帐户。在 Ceph Issue Tracker 的选项卡下，用户可以看到他们的 API 访问密钥。创建新问题时，此密钥用于身份验证。要存储 Ceph API 访问密钥，请在 CLI 中运行：my account

``ceph dashboard set-issue-tracker-api-key -i <file-containing-key>``

然后在成功更新后，您可以使用以下方法创建问题：

``ceph dashboard create issue <project> <tracker_type> <subject> <description>``

可用于创建问题的项目是：#。仪表板＃。堵塞＃。目的＃。文件系统＃。ceph_manager#。协调器#。ceph_volume #。core_ceph

可用的跟踪器类型是：#。漏洞＃。特征

然后由用户设置主题和描述。

用户还可以使用仪表板用户界面创建问题。导航栏右上角的设置图标下拉菜单有选项。单击它时，将打开一个模态对话框，其中可以选择从各自的下拉菜单中选择项目和跟踪器。主题和多行描述由用户添加。然后用户可以提交问题。Raise an issue

以前的下一个

文章目录

Author 晓兵

weixin: ssbandjl

公众号: 云原生云

ceph文档

MSGR2 协议（MSGR2.0 和 MSGR2.1）

目标

定义

阶段

横幅

帧格式

你好

验证

授权后帧格式

压缩

压缩后帧格式

消息流握手

消息交换

协议交互 (WIP) 示例

网络编码

惯例

整数

复杂类型

变量数组

原始别名

结构

选修的

一对

三倍

列表

斑点

地图

复杂类型

UTIME_T

CEPH_ENTITY_NAME

网络协议

你好

横幅

连接

连接回复

MSGR协议

CEPH_MSGR_TAG_CLOSE (0X06)

CEPH_MSGR_TAG_MSG (0X07)

CEPH_MSGR_TAG_ACK (0X08)

CEPH_MSGR_TAG_KEEPALIVE (0X09)

CEPH_MSGR_TAG_KEEPALIVE2 (0X0E)

CEPH_MSGR_TAG_KEEPALIVE2_ACK (0X0F)

CEPH 仪表板

概述

功能概述

仪表板着陆页概述

细节

地位

容量

存货

集群利用率

支持的浏览器

启用

配置

SSL/TLS 支持

主机名和端口

用户名和密码

帐户锁定

启用锁定用户

访问仪表板

启用对象网关管理前端

启用 ISCSI 管理

启用 GRAFANA 仪表板的嵌入

使用 CEPHADM 安装和配置

手动安装和配置

启用 RBD-IMAGE 监控

配置仪表板

浏览器的替代 URL

启用单点登录 (SSO)

启用普罗米修斯警报

用户和角色管理

密码政策

用户帐户

用户角色和权限

用户和自定义角色创建示例