修改详情

为了及时发现各类服务中断（例如20250328夜间发现znuny异常），你组应该有一个状态监测服务。 虽然为了避免DNS基础设施、前端反代、CDN层甚至服务器的流量路由层之类的爆炸导致监测服务自身不可用，我们应该使用一个单独的域名，但是考虑到你组的经济水平显然不太现实。 == 托管 == * 方案1：直接在nuremberg上部署。优点是，简单。缺点是，容易一起爆炸。 * 方案2：在~~Toolforge~~Cloud VPS上部署。优点是，不容易炸，而且有独立的域名。 * 方案3：在 @xtex 的服务器上部署。 == 架构 == 1. 在服务器和各服务上部署OpenTelemetry receivers和OTel Collector以收集和转发数据 2. 在Cloud VPS部署OTel Collector和Prometheus以处理和保存数据 3. 在Cloud VPS部署Grafana OSS以可视化数据和发送警告 4. 在Toolforge捏个更简单的前端（大概？）

为了及时发现各类服务中断（例如20250328夜间发现znuny异常），你组应该有一个状态监测服务。 虽然为了避免DNS基础设施、前端反代、CDN层甚至服务器的流量路由层之类的爆炸导致监测服务自身不可用，我们应该使用一个单独的域名，但是考虑到你组的经济水平显然不太现实。 == 托管 == * 方案1：直接在nuremberg上部署。优点是，简单。缺点是，容易一起爆炸。 * 方案2：在~~Toolforge~~Cloud VPS上部署。优点是，不容易炸，而且有独立的域名。 * 方案3：在 @xtex 的服务器上部署。 == 架构（OTel + TSDB） == 1. 在服务器和各服务上部署OpenTelemetry receivers和OTel Collector以收集和转发数据 2. 在Cloud VPS部署OTel Collector和Prometheus以处理和保存数据 3. 在Cloud VPS部署Grafana OSS以可视化数据和发送警告 4. 在Toolforge捏个更简单的前端（大概？） == 架构（Uptime Kuma/Gatus） == 直接用Uptime Kuma或者Gatus或者Upptime。

为了及时发现各类服务中断（例如20250328夜间发现znuny异常），你组应该有一个状态监测服务。 虽然为了避免DNS基础设施、前端反代、CDN层甚至服务器的流量路由层之类的爆炸导致监测服务自身不可用，我们应该使用一个单独的域名，但是考虑到你组的经济水平显然不太现实。 == 托管 == * 方案1：直接在nuremberg上部署。优点是，简单。缺点是，容易一起爆炸。 * 方案2：在~~Toolforge~~Cloud VPS上部署。优点是，不容易炸，而且有独立的域名。 * 方案3：在 @xtex 的服务器上部署。 == 架构（OTel + TSDB） == 1. 在服务器和各服务上部署OpenTelemetry receivers和OTel Collector以收集和转发数据 2. 在Cloud VPS部署OTel Collector和Prometheus以处理和保存数据 3. 在Cloud VPS部署Grafana OSS以可视化数据和发送警告 4. 在Toolforge捏个更简单的前端（大概？） == 架构（Uptime Kuma/Gatus） == 直接用Uptime Kuma或者Gatus或者Upptime。