日志内容和cephadm

https://docs.ceph.com/en/reef/cephadm/operations/

上面是ceph18的cephadm的操作

感觉日志路径改不了了，空间不够就单独一个盘

bootstrap的时候，加上 --log-to-file 就会自动开启所有的日志开关

王先生，结论先说清楚：

ceph tell ... config set ... 不是持久化（默认不持久化） ：它把配置注入到正在运行的那个/那些 daemon 的内存里，通常用于临时调试（例如临时提高 debug 级别）。重启 daemon 后一般会丢失。
ceph config set ... 是持久化 ：它把配置写入 Ceph 的 config database（集中配置库），会在 daemon 启动/重启时继续生效，并能自动下发到匹配的 daemon。

两者关系可以理解为：
tell config set = 临时"热改"某个进程 ；config set = 写入集群配置库的"权威配置"。

1) `ceph tell ... config set` 到底做了什么？

它调用目标 daemon 的 admin socket/内部接口，把 name=value 直接设置到该 daemon 运行时配置中。常见用法：

bash 复制代码

ceph tell osd.* config set debug_osd 10/10

用途：快速排障、临时增大日志、临时开关某个行为。

特点：立刻生效 ，但一般 不保证重启后还在。

你可以用下面方式验证它是"落在进程里"的：

bash 复制代码

ceph tell osd.0 config get debug_osd

2) `ceph config set` 做了什么？

它把配置写入集群的 config database（等价于"集中配置中心"），例如：

bash 复制代码

ceph config set global debug_osd 10/10
ceph config set osd debug_osd 10/10
ceph config set osd.0 debug_osd 10/10

特点：

持久化（写入配置库）
能按层级生效：global / mon / osd / osd.0 / client.rgw... 等
daemon 重启后会再次从 config db 获取并生效

查看持久化结果：

bash 复制代码

ceph config dump | grep debug_osd
# 或
ceph config get osd debug_osd

3) 两者同时用时，谁"赢"？

经验规则（排障时很重要）：

ceph config set 提供的是 持久化基线（daemon 启动会加载）
ceph tell ... config set 是 对某个正在跑的进程做 runtime override

如果你先 config set 设成 A，再对某个 daemon 用 tell 设成 B，通常该 daemon 当前会表现为 B；但 一旦它重启，会回到 config db 的 A（除非你也把 B 写入了 config db）。

所以：临时调试用 tell；确认要长期生效再用 config set。

4) 推荐的实战用法（你在 cephadm/docker 场景很常用）

临时把 OSD debug 拉高 10 分钟排查：

bash 复制代码

ceph tell osd.* config set debug_osd 10/10
# 排查完再调回去
ceph tell osd.* config set debug_osd 1/5

要长期保留（例如某个环境一直需要更高日志）：
bash 复制代码
```
ceph config set osd debug_osd 1/5
```

如果你想我帮你判断"你现在看到的某个参数到底是 runtime 临时值还是 config db 持久值"，你贴一下这三条输出我就能帮你对比：

bash 复制代码

ceph config dump | grep <param>
ceph config get <who> <param>
ceph tell <daemon> config get <param>

王先生，你这个现象在 cephadm + Docker 部署里很常见：Ceph daemon 默认把日志打到 stderr/stdout → 被容器运行时收集 → 进 journald ；而很多发行版会把 journald 再转发给 rsyslog ，最终就落到了 /var/log/messages （或 /var/log/syslog）。Ceph 官方也明确说：cephadm 场景下 daemon 日志默认进 journald 。(docs.ceph.com)

下面给你"为什么会进 /var/log/messages"以及"怎么解决/怎么让它不要进去"的可选方案。

1) 为什么部分日志会出现在 `/var/log/messages`

最常见有两条链路（两条都可能同时存在）：

链路 A：Ceph → journald → rsyslog → /var/log/messages

cephadm 下 Ceph daemon 默认日志进 journald。(docs.ceph.com)
如果你的系统启用了 journald 转 syslog（ForwardToSyslog），或者 rsyslog 通过 imjournal 读取 journal，那么 journal 里的内容会被写进 /var/log/messages。这也是很多系统出现"journal 和 messages 双份日志"的根因。(bugzilla.redhat.com)

链路 B：Docker 日志驱动直接写 syslog/journald，再被落到 messages

Docker 可以配置 logging driver 为 syslog 或 journald。(Docker Documentation)
若走 journald 驱动且系统再转发给 syslog，也会进 /var/log/messages（你会看到带容器 tag 的行）。(Docker Documentation)

2) 先用 3 条命令把"到底是哪条链路"钉死

在任一出问题节点上跑：

bash 复制代码

docker info | egrep 'Logging Driver|Docker Root Dir'

看是不是 journald/syslog/json-file。(Docker Documentation)

bash 复制代码

grep -E '^\s*ForwardToSyslog' /etc/systemd/journald.conf /etc/systemd/journald.conf.d/*.conf 2>/dev/null

bash 复制代码

grep -R "imjournal" -n /etc/rsyslog.conf /etc/rsyslog.d 2>/dev/null

有了这三条输出，基本就能判定是 journald 转发导致，还是 Docker driver 直接进 syslog 导致。

3) 解决方案（按你想要的"日志归宿"选择）

方案 A：不想让 journald 再写进 `/var/log/messages`（最常用）

关闭 journald → syslog 转发（这样 Ceph 仍在 journal 里，但不再复制到 messages）：

在 /etc/systemd/journald.conf 里设置：

ini 复制代码

ForwardToSyslog=no

然后：

bash 复制代码

systemctl restart systemd-journald

这是社区/系统层面最常见的处理方式。(Stack Overflow)

方案 B：保留 syslog，但把"容器/ceph"从 rsyslog 里过滤掉

如果你还需要其他系统日志继续进 /var/log/messages，可以在 rsyslog 规则里只过滤 docker/ceph 的标识（做法取决于你 rsyslog 如何接 journal、tag 怎么写）。这属于 rsyslog 配置层面，思路是"匹配 programname/tag 后丢弃/不写 messages"。

（这块实现细节强依赖你发行版的 rsyslog 规则，我建议你按上面的 grep 把 imjournal/规则文件定位出来，再做针对性过滤。）

方案 C：让容器日志不要走 journald/syslog，改回本地文件（Docker 管）

如果你希望容器日志不再进入 journal/messages，而是落在 Docker 自己的日志文件中（并可控轮转），就把 Docker logging driver 改为 json-file 或 local，并设置 max-size/max-file。Docker 官方对驱动配置与可选项有说明。(Docker Documentation)

方案 D：你想"Ceph 只写 /var/log/ceph/ 文件"，不走 journald

Ceph 官方给的做法是：启用 file logging，并关闭 journald/stderr，避免重复记录。(docs.ceph.com)

你把这两条输出贴出来，我可以直接给你"最小改动"的落地配置

bash 复制代码

docker info | egrep 'Logging Driver|Docker Root Dir'
grep -E '^\s*ForwardToSyslog' /etc/systemd/journald.conf

我会根据你当前是 Docker driver 问题 还是 journald→syslog 转发问题 ，给你一套明确的改法（改哪个文件、加哪几行、重启哪个服务，以及如何验证不再写入 /var/log/messages）。

王先生，journald 和 /var/log/ceph/<fsid> 文件日志 在 cephadm+docker 场景里是两种不同的"日志落地通道" 。它们可能包含重叠内容，但默认不保证完全一样，也经常会出现"有的只在 A、有的只在 B"的情况。

下面按"来源---去向---是否重复"把关系讲透：

1) 它们分别接的是什么"源"？

A. journald（系统日志）

主要接的是：容器 stdout/stderr（Ceph daemon 把日志打到 stderr/stdout → 容器运行时 → journald/容器日志驱动）。
所以 journald 里通常包含：守护进程的运行日志、启动信息、以及一些运行时告警。

B. `/var/log/ceph/<fsid>/...`（Ceph 传统文件日志）

主要接的是：Ceph 自己的 file logger （也就是你开启 log_to_file/bootstrap --log-to-file 后，Ceph 额外/改为写日志文件）。
这类日志以文件形式存在，通常按 daemon 分文件（mon/osd/mgr/rgw...）。

2) 日志内容会一样吗？

不一定。

情况 1：你只走默认（不启用 log_to_file）

你基本只会在 journald/容器日志里看到 daemon 日志；
/var/log/ceph/<fsid> 可能没有、或很少。

情况 2：你启用了 `--log-to-file` / `log_to_file=true`

这时会出现三种常见组合（取决于你是否同时开着 log_to_stderr / log_to_journald）：

双写（最常见）：既写文件，又写 stderr/journald
- 结果：两边大量重复，但仍可能不完全一致（时间戳格式、前缀字段、截断、启动阶段信息等会不同）。
只写文件：关闭 stderr/journald，只留 file logging
- 结果：journald 里几乎没有 daemon 日志，主要在 /var/log/ceph/<fsid>。
只写 journald：开启 stderr/journald，关闭 file logging
- 结果：文件里基本没有，主要在 journald。

也就是说：是否"同一份日志"取决于你是否配置了双写。双写才会接近"内容一样"，但仍不保证 100% 一致。

3) 为什么会"不完全一致"？

常见原因（你可能正好遇到）：

通道不同：stderr → journald 这条链路可能有缓冲、截断或不同的格式化；文件日志是 Ceph 自己写的格式。
不同组件走不同 logger：例如某些启动脚本、容器运行时/系统组件信息会只在 journald；而 Ceph 内部的一些"cluster log/审计类"信息可能只在文件里（取决于配置项）。
你启用了 rsyslog 转发 ：journald 里的内容又被复制到 /var/log/messages，就更容易产生"多份但不完全一致"的观感。

4) 怎么判断你现在是不是"双写"？

直接查这几个关键配置即可（这决定了是否重复）：

bash 复制代码

ceph config get global log_to_file
ceph config get global log_to_stderr
ceph config get global log_to_journald

ceph config get global mon_cluster_log_to_file
ceph config get global mon_cluster_log_to_stderr
ceph config get global mon_cluster_log_to_journald

log_to_file=true 且（log_to_stderr=true 或 log_to_journald=true）→ 双写概率很高
log_to_file=true 且 log_to_stderr=false 且 log_to_journald=false → 基本只写文件
log_to_file=false 且（log_to_stderr/journald 为 true）→ 基本只写 journald

5) 实用建议（避免混乱）

你想统一由容器日志系统收集：就保持 journald/stdout 方案，别开 file logging。
你想传统文件 + logrotate ：就开 log_to_file，并把 log_to_stderr、log_to_journald 关掉，避免重复。

如果你把上面那 6 个 ceph config get 的输出贴出来，我可以直接告诉你：你当前是 哪种组合、为什么会重复/分散、以及按你的偏好给一套"最小改动"的配置。

王先生，cephadm 里的 --data-dir 不是"随便改个路径"的小参数 ，它是 cephadm 认定的 "daemon 数据根目录" （默认 /var/lib/ceph）。官方 man page 里写得很明确：--data-dir 是 base directory for daemon data ，默认 /var/lib/ceph。 (Ceph 文档)

改 `--data-dir` 会影响什么

1) cephadm "去哪找/去哪放"每个 daemon 的本地状态目录

Cephadm 的目录结构大体是（官方）：

/var/lib/ceph/<cluster-fsid>：集群 daemon 数据（不含日志）
/var/lib/ceph/<cluster-fsid>/<daemon-name>：单个 daemon 的数据
/var/lib/ceph/<cluster-fsid>/crash、removed 等目录 (Ceph 文档)

把 --data-dir 改掉，本质就是把上面这些目录从 /var/lib/ceph/... 整体换到新根目录 （例如 /data/ceph/...）。

2) cephadm 找配置/密钥的位置也会受影响

从 Pacific/Quincy 开始，cephadm 还会把 配置和 keyring 复制/存放到 /var/lib/ceph/<fsid>/config（除了 /etc/ceph 之外），并且 cephadm 自己会用这条路径来加载与分发配置。 (Ceph 文档)

所以改了 --data-dir，等价于把这个"cephadm 自己用的 config/keyring 副本目录"也改了。

另外，cephadm 的命令（比如 cephadm shell）在寻找配置时，会优先查 /var/lib/ceph/<fsid>/... 这一套路径（示例顺序在 man page 里列出）。 (Ceph 文档)

最容易踩的坑：对"已部署集群"改默认值

如果你是直接改 cephadm 脚本里默认的 --data-dir （或在某些节点上运行 cephadm 时突然改了 --data-dir），对现网的典型后果是：

cephadm 可能"找不到"原来的 daemon

因为它会去新目录里找 /new-data-dir/<fsid>/...，而旧目录还在 /var/lib/ceph/<fsid>/...，于是 cephadm ls / rm-daemon / logs / shell 等操作可能表现异常（看起来像"这台机器没 daemon"或"stray daemon"）。
重新 deploy / redeploy 时会生成一套"新路径"的 systemd unit / mount

老 daemon 仍然用旧路径，新 daemon 用新路径，导致主机上出现"同一集群两套目录布局"，排障会非常痛苦。
严重时：状态型 daemon 起不来或相当于"空数据启动"

监视器、mgr、（以及某些服务如 Prometheus）依赖本地状态目录；换根目录而没迁移数据，会导致启动失败或行为异常。官方也明确提到有些 daemon（尤其 mon、prometheus）会在 /var/lib/ceph 下存大量数据。 (Ceph 文档)

能不能改？官方态度

Ceph 的通用配置里也提到 daemon 数据目录默认在 /var/lib/ceph/...，可以 override，但不推荐 。 (Ceph 文档)

更推荐的做法：别改 cephadm 脚本默认值，改"承载目录"

如果你是为了把数据放到更大的盘上，官方在 cephadm operations 里建议：因为 /var/lib/ceph 可能会很大，把 /var/lib/ceph 移到单独的磁盘/分区/LV 。 (Ceph 文档)

工程上最稳的是 bind mount（对 cephadm/容器透明），而不是改脚本默认值。

如果你告诉我你"改 --data-dir"的目的是什么（比如：根分区不够、想迁到 /data、或者想隔离不同集群），我可以按你的目标给你一套不破坏现网的迁移/落地方案（包含：需要迁哪些目录、哪些服务要停、如何验证）。

日志内容和cephadm

1) ceph tell ... config set 到底做了什么？

2) ceph config set 做了什么？

3) 两者同时用时，谁"赢"？

4) 推荐的实战用法（你在 cephadm/docker 场景很常用）

1) 为什么部分日志会出现在 /var/log/messages

链路 A：Ceph → journald → rsyslog → /var/log/messages

链路 B：Docker 日志驱动直接写 syslog/journald，再被落到 messages

2) 先用 3 条命令把"到底是哪条链路"钉死

3) 解决方案（按你想要的"日志归宿"选择）

方案 A：不想让 journald 再写进 /var/log/messages（最常用）

方案 B：保留 syslog，但把"容器/ceph"从 rsyslog 里过滤掉

方案 C：让容器日志不要走 journald/syslog，改回本地文件（Docker 管）

方案 D：你想"Ceph 只写 /var/log/ceph/ 文件"，不走 journald

你把这两条输出贴出来，我可以直接给你"最小改动"的落地配置

1) 它们分别接的是什么"源"？

A. journald（系统日志）

B. /var/log/ceph/<fsid>/...（Ceph 传统文件日志）

2) 日志内容会一样吗？

情况 1：你只走默认（不启用 log_to_file）

情况 2：你启用了 --log-to-file / log_to_file=true

3) 为什么会"不完全一致"？

4) 怎么判断你现在是不是"双写"？

5) 实用建议（避免混乱）

改 --data-dir 会影响什么

1) cephadm "去哪找/去哪放"每个 daemon 的本地状态目录

2) cephadm 找配置/密钥的位置也会受影响

最容易踩的坑：对"已部署集群"改默认值

能不能改？官方态度

更推荐的做法：别改 cephadm 脚本默认值，改"承载目录"

1) `ceph tell ... config set` 到底做了什么？

2) `ceph config set` 做了什么？

1) 为什么部分日志会出现在 `/var/log/messages`

方案 A：不想让 journald 再写进 `/var/log/messages`（最常用）

B. `/var/log/ceph/<fsid>/...`（Ceph 传统文件日志）

情况 2：你启用了 `--log-to-file` / `log_to_file=true`

改 `--data-dir` 会影响什么