初见端倪
09/27 晚上，羊在正常睡前使用 Nokia 日常巡查 Solar Network 时发现连接问题。起初以为是 Nokia 的高级天线的问题。
晚些时候，通过访问 api.solian.app/health endpoint 得知，大部分服务已经扑街。
受制于住宿条件限制，只好在第二天另寻出路。
初步诊断
09/28 通过忙里偷闲在学校电脑上登陆 console.cloud.tencent.com 腾讯云控制台当家豪使用云端 OrcaTerm 检查服务器初步状态。
SSH 和部分运行在 NAS 上的服务工作正常。初步证明服务器没有 CPU 高的问题。试图查看容器运行状态之后发现 podman 报错未仔细查看报错之前可能认为是 podman 设计缺陷。遂重启整台服务器。
重启服务器之后 podman 报错正常提示整个服务器磁盘不可用，随后在 `sudo df -h` 时发现主磁盘又双叒叕满了。
通过运行 `sudo ncdu /var` 发现 `/var/lib/containers/storage/overlay-containers` 有高达 60G 的磁盘占用，基本确定问题直接原因。
ncdu 1.19 ~ Use the arrow keys to navigate, press ? for help
--- /var/lib/containers/storage/overlay-containers ----------------------------------------------------------------------------------
/..
10.2 GiB [###################] /b984b8be225df337732fd98320b7e70571bbb966d379d2bf30fc49dc01f189f7
9.7 GiB [################## ] /3f23b3061b3f67ff9b59beea671b6ce49c40e1e3ddac9e9ae589ae36441b1e8a
9.6 GiB [################# ] /cf174b063f55009af5940a4155eea1eeeca61e7c8459b6aa797172c0b18a4cd1
9.3 GiB [################# ] /a0cf3133f37b700cbbea9dbc9d47c5b904f78603b63952d19a1e085c07427e3e
8.8 GiB [################ ] /c091e5b1e4146835fa6a842dfe37b746b48fca607c44af33a5232f88769ea7a4
8.8 GiB [################ ] /507aae4f4fd6eafe68de57a5631ba1a5d1a46761c6523e4b81dc4e6d6b43c360
7.5 GiB [############## ] /9b0d7cfad1cf6ce4c8c81663c3f1b75228207e91af44b74035356408f2f62480初步暴力清理了一下 podman 日志，问题得到缓解，服务暂时恢复。因为不能一直在讲台上当嘉豪于是没有长时间监测是有存在 regression 或其他根本原因。
老病复发
下午时分，重新检查服务运行状态，发现 `solar-network` 和 `wattengine` 集群基本不可用，但是部分 Go 服务仍然存活。这给诊断带来了干扰因素，起初羊认为是什么 C# 服务中的共性问题造成的。
因为学校活动繁杂，晚自习前并未再有空修复相关问题。遂决定先班主任请假回家使用工作站和完全的环境进一步诊断问题。
根除病灶
回家在后，通过重新清理了服务器的日志文件让服务器基本功能恢复。通过检查之间的历史记录发现了 WattEngine 和 DysonNetwork 服务集群在抱怨
warn: DysonNetwork.Shared.EventBus.EventBusBackgroundService[0] Error handling event on subject filesystem.file.updated.v1 (retry 1/3)
System.Text.Json.JsonException: The JSON value could not be converted to System.Guid. Path: $.event_id | LineNumber: 0 | BytePositionInLine: 40.
---> System.FormatException: The JSON value is not in a supported Guid format.
at System.Text.Json.ThrowHelper.ThrowFormatException(DataType dataType) at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader) at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, T& value, JsonSerializerOptions options, ReadStack& state) --- End of inner exception stack trace --- at System.Text.Json.ThrowHelper.ReThrowWithPath(ReadStack& state, Utf8JsonReader& reader, Exception ex) at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, T& value, JsonSerializerOptions options, ReadStack& state)
at System.Text.Json.Serialization.Metadata.JsonTypeInfo`1.DeserializeAsObject(Utf8JsonReader& reader, ReadStack& state) at System.Text.Json.JsonSerializer.ReadFromSpanAsObject(ReadOnlySpan`1 json, JsonTypeInfo jsonTypeInfo)
at DysonNetwork.Shared.EventBus.EventBusBackgroundService.ProcessMessageInternalAsync(Byte[] data, NatsHeaders headers, EventSubscription subscription, CancellationToken stoppingToken) in /src/DysonNetwork.Shared/EventBus/EventBusBackgroundService.cs:line 197大量的警告日志压垮了磁盘。导致了服务中断的直接问题。但是这些警告日子是哪里来的呢？
不要在星期日推送更新
在小羊前往学校之前向服务器发送了最后一个关于文件服务器的更新，提供了 EXIF 的 Reanalysis 功能。由于是异步的，所以通过 EventBus 系统向其他服务广播。但是 DysonFS 犯了个错，使用了旧版的模型合约，导致其他服务不兼容相关的信息。警告后不处理事件，造成重播，再次出发警告，再次重播，由此往复，造成问题。
防治
不知道磁盘和我有什么仇什么怨，Solar Network 的近三次大 Outage 都是和磁盘占用满相关。说白了还是太穷了，要是磁盘够大怎么写日志都没关系。
- 设立完善的日志旋转机制；正常来说，日志就算写的再怎么多，有着完善的日志旋转机制都不算什么问题，顶多 CPU 占用高一点。但是我是用的 podman 版本的默认配置刚好差了这一点，所以人工补齐了。
- 建立完善的心跳和预警机制，在发现服务器 metric 异常时及时上报，避免问题再次出现
- 让 MaidKit 支持网页端，这样小羊在学校也能及时修复问题了
- 发板需要谨慎，至少要留一个小时的观察期才能确定该版本的服务器没有恶性问题
给小羊办走读
这个学期应该没有机会再次这样回来补救服务器的问题，我的父母非常不爽看起来（=!不过下个学期就办走读了倒也无所谓!=
Thanks for you reading, and trust in the Solar Network. :cat+rose:
相信小羊不会跑路