建议的警报阈值

关于建议的警报阈值

你可以配置外部监控系统，以便提醒你可能导致你的 GitHub Enterprise Server 实例出现问题的存储、CPU 和内存使用情况。

有关 OpenTelemetry 指标的详细信息，请参阅关于 OpenTelemetry 指标。

有关收集的指标的详细信息，请参阅关于 Collectd 指标。

有关监视仪表板的详细信息，请参阅关于监控仪表板。

建议您同时对根存储设备和用户存储设备进行监视，并为警报配置合适的值，在可用磁盘空间不足时提供足够长的响应时间。

严重性	阈值

          **警告** | 可用磁盘空间已超过总可用空间的 60% |

| 危急 | 磁盘使用率超过总可用大小的 75% |

您可以根据分配的总存储空间、历史增长模式和预期响应时间调整这些值。我们建议多分配一些存储资源，以便考虑增长情况并避免因分配额外存储空间而需要停机。

虽然 CPU 利用率随资源密集型 Git 操作上下波动属于正常情况，但我们建议配置警报来监视异常增高的 CPU 利用率，因为 CPU 利用率长时间处于高水平可能说明实例配置不足。此外，我们建议在实例处于正常状态时在正常工作周内监视 CPU 利用率，以建立可用作参考的基线。

严重性	阈值

          **警告** | 高于基线 20% |

| 危急 | 高于基线 40% |

我们还建议监视虚拟化“盗取”时间，以确保在同一主机系统上运行的虚拟机不会用掉所有实例资源。

分配给你的 GitHub Enterprise Server 实例的物理内存大小对整体性能和应用程序响应能力有着极大的影响。系统设计为通过大量使用内核磁盘缓存来加快 Git 操作速度。建议将分配给进程的物理内存量设置在最高使用量时总可用 RAM 的 50% 之内。

严重性	阈值

          **警告**  | 持续内存使用量超出总可用内存大小的 50% |

| 危急 | 持续内存使用量超出总可用内存大小的 70% |

然而，对于群集安装，建议遵循类似的 CPU 监视方法：建立一个定义正常使用情况的基线，并相应地设置阈值。此阈值也可能因角色而异。

如果内存已耗尽，内核 OOM 终止程序将尝试终止占用 RAM 较多的应用程序进程以释放内存资源，这样可能导致服务中断。建议为虚拟机分配的内存大小应大于正常操作过程所需的内存。