前言
起因是因为公司监控服务突然报警，告诉我 Rancher 降级了。急急忙忙打开后台一看发现刷屏报错：
[ 5307.281824] systend-journald(539]: Failed to write entry (24 items, 581 bytes), ignoring: Input/Output Error
好家伙，不是掉盘就是盘只读了。那么为了快速恢复，我先直接强制重启了服务器，随后在开始排查问题。
systend-journald 是什么？
其实别看这名字似乎没见过，实际上随便联想一下你应该会联想到一个常用的日志命令journalctl 。这个名称就是这个命令背后的服务名，其中文可以直接称呼为系统日志。
开始排查 - Input/Output Error
那么既然知道了报错来源，那么我们就应该开始排查问题根源了。
首先最应该做的就是先看看硬盘是否满了，这是最常见的问题：
df -h通过这个命令我们能直观的看见硬盘的占用情况，但可能有的时候会被 K8S 的容器目录刷屏。这种时候你可以使用以下命令来查看根目录：
df -h /假设说你在这一步发现占用空间很大，你可以通过移除不要的内容来释放空间。
例如：
Docker 构建出来的镜像
Docker 层间缓存
各种日志文件
那么如果并不是占用空间满了导致出现这个报错，那么你就要考虑一下其他原因了，例如：
硬盘因为电源问题突然掉盘
硬盘有坏道坏区
但通常情况下这种情况也是很少见的，不过也需要经常关注一下硬盘的健康状态。
开始排查 - Read-only file system
这个是代表文件系统进入只读状态，遇到这个问题很大可能是因为硬盘损坏。
对此只有一个建议：速度备份以及换硬盘。
但如果你只是极客在自己玩，那重启就可以恢复。
开始排查 - Cannot assign requested address
这个提示是代表Unix Socket 缓冲区已满导致无法写入或读取，也可以认为就是日志文件损坏导致的该问题。
解决方式也算简单：
通过
journalctl --verify命令找到损坏的日志文件然后删除或者移动它。
最后重启服务即可。
$ journalctl --verify
13bf258: Invalid object
File corruption detected at /var/log/journal/21fbd9cf5ebc4d1ea8e83b6f1be17eaf/system.journal:13bf258 (of 25165824 bytes, 82%).
FAIL: /var/log/journal/21fbd9cf5ebc4d1ea8e83b6f1be17eaf/system.journal (Cannot assign requested address)
PASS: /run/log/journal/111bd9cf5ebc4d1ea8e83b6f1b132433/system.journal
$ mv /var/log/journal/21fbd9cf5ebc4d1ea8e83b6f1be17eaf/system.journal ~/
$ systemctl restart systemd-journald.service管理日志空间
通常系统并没有自行约束日志文件的大小或区间，基本上是从你第一次运行开始一路存到无法继续存为止。
那么这种时候就需要有人手动启动轮换策略了。
启动轮换策略
vi /etc/systemd/journald.conf 打开系统日志服务的配置文件。
[Journal]
MaxRetentionSec=1month # 日志保留时间为 1 个月
SystemMaxFileSize=200M # 每个日志文件最大 200 MB
SystemMaxUse=1G # 日志最大使用 1GB 空间修改并保存配置后，需要重启日志服务：systemctl restart systemd-journald 才能生效。
手动清理
那么如果现在确实很着急清理日志该怎么办呢？
那就是执行自带的清理参数即可，如下所示：
# 清理日志文件大于 20M 的日志
journalctl --vacuum-size=20M
# 只保留最近7天的日志，单位：d(天), h(时), m(分)
journalctl --vacuum-time=7d