监视器

确保您的服务对用户可用且可访问非常重要。为了监控这一点，SUSE Observability设置了一个检查，以验证服务是否至少有一个可用的端点。端点是网络地址，使分布式系统中不同组件之间能够通信，服务正常运行需要这些端点可用。 如果在过去10分钟内没有可用的端点，监控器将保持偏离状态，表明服务可能存在需要解决的问题。 允许 覆盖监控器参数

用户在名称空间中创建资源（如Pod、服务等），配额系统跟踪使用情况，以确保不超过在ResourceQuota中定义的CPU硬资源限制。当名称空间中的总CPU限制达到配额设定的90%或更多时，监控器将发出警报。名称空间中的每个 resourcequota 产生一个监控健康状态。

用户在名称空间中创建资源（如Pod、服务等），配额系统跟踪使用情况，以确保不超过在ResourceQuota中定义的CPU硬资源请求。当名称空间中的总CPU请求达到配额设定的90%或更多时，监控器将发出警报。名称空间中的每个 resourcequota 产生一个监控健康状态。

确保Daemonset的期望副本数得到满足非常重要。Daemonsets用于管理需要在集群中所有或部分节点上运行的一组Pod，确保在满足指定条件的每个节点上都有一个Pod副本在运行。这对于记录、监控以及需要在集群中每个节点上执行的其他集群级任务非常有用。

为了监控这一点，SUSE Observability 设置了一个检查，以验证可用副本是否与所需副本数量匹配。此检查仅适用于所需副本数量大于零的 DaemonSets。

要了解完整的监控定义，请查看详细信息。

监控您 Kubernetes 集群中持久卷声明 (PVC) 的使用情况是非常重要的。PVCs 用于存储需要在容器生命周期之外持久化的数据，确保它们有足够的空间来存储数据至关重要。 为了跟踪这一点，我们设置了一个检查，使用线性预测来预测 Kubernetes 卷使用趋势，时间跨度为 4 天。如果趋势表明 PVCs 在此时间范围内将用尽空间，您将收到通知，以便您采取措施防止数据丢失或停机。

监控您 Kubernetes 集群中持久卷声明 (PVCs) 的使用情况是非常重要的。PVCs 用于存储需要在容器生命周期之外持久化的数据，确保它们有足够的空间来存储数据至关重要。为了跟踪这一点，我们设置了一个检查，使用线性预测来预测 Kubernetes 卷使用趋势，时间跨度为 12 小时。如果趋势表明 PVC 在此时间范围内将用尽空间，您将收到通知，以便您采取措施防止数据丢失或停机。

确保部署的所需副本数量得到满足是非常重要的。部署用于管理 Kubernetes 集群中一组相同 Pods 的部署和扩展。通过确保所需副本数量正在运行并可用，部署可以帮助维护 Kubernetes 应用程序或服务的可用性和可靠性。为了监控这一点，SUSE Observability 设置了一个检查，以验证可用副本是否与所需副本数量匹配。

此检查仅适用于所需副本数量大于零的部署。

要了解完整的监控定义，请查看详细信息。

HTTP 响应状态码在 5xx 范围内表示服务器端错误，例如配置错误、过载或内部服务器错误。 为了确保良好的用户体验，5xx 响应的比例应低于总 HTTP 响应的 5%。

因为确切的阈值和严重性可能依赖于应用程序，因此可以通过 Kubernetes 注释在服务上 覆盖 阈值。例如，要覆盖预配置的偏差阈值，而只在 6% 时设置一个关键阈值，请在您的服务上添加以下注释：

省略此 JSON 片段中的偏差阈值将使其保持在配置的 5%，而关键阈值为 6%，这意味着监控器仅在错误比例在 5% 和 6% 之间时才会导致偏差状态。

跟踪 Kubernetes 服务的第 95 百分位数 (Q95) HTTP 响应时间有助于您发现可能影响用户的慢请求和性能异常。如果 Q95 响应时间在指定时间窗口内超过 3 秒，监控器将以偏差状态提醒您。

您可以通过 覆盖默认设置 来根据应用程序的需求定制此监控器，例如时间窗口、阈值或分位数，使用 Kubernetes 注释在您的服务上。这种灵活性在您的服务具有独特性能要求时非常有用。例如，长轮询服务。

要自定义监控器，请在您的服务上添加如下注释，并根据需要调整值：

监控您 Kubernetes 集群中持久卷声明 (PVCs) 的使用情况是非常重要的。PVCs 用于存储需要在容器生命周期之外持久化的数据，确保它们有足够的空间来存储数据至关重要。为了跟踪这一点，SUSE Observability 设置了一个检查，使用线性预测来预测 Kubernetes 卷在 12 小时内的使用趋势。如果趋势表明 PVCs 在此时间范围内将用尽空间，您将收到通知，以便您采取措施防止数据丢失或停机。

监控您 Kubernetes 集群中持久卷声明 (PVCs) 的使用情况是非常重要的。PVCs 用于存储需要在容器生命周期之外持久化的数据，确保它们有足够的空间来存储数据至关重要。 为了跟踪这一点，SUSE Observability 设置了一个检查，使用线性预测来预测 Kubernetes 在 4 天内的存储使用趋势。如果趋势表明 PVCs 在此时间范围内将用尽空间，您将收到通知，以便您采取措施防止数据丢失或停机。

用户在名称空间中创建资源（如 pods、服务等），配额系统跟踪使用情况，以确保不超过在 ResourceQuota 中定义的内存硬性资源限制。当名称空间中的总内存限制达到配额设定的 90% 或更多时，监控器将发出警报。名称空间中的每个 resourcequota 产生一个监控健康状态。

用户在名称空间中创建资源（如 pods、服务等），配额系统跟踪使用情况，以确保不超过在 ResourceQuota 中定义的内存硬性资源请求。当名称空间中的总内存请求达到配额设定的 90% 或更多时，监控器将发出警报。名称空间中的每个 resourcequota 产生一个监控健康状态。

节点磁盘压力是指连接到节点的磁盘承受过重负载的情况。尽管由于 Kubernetes 内置的预防措施，节点磁盘压力的发生概率较低，但仍有可能偶尔出现。节点磁盘压力可能产生的主要原因有两个。第一个原因与 Kubernetes 未能清理未使用的镜像有关。在正常情况下，Kubernetes 会定期检查并删除任何未使用的镜像。因此，这并不是节点磁盘压力的常见原因，但应予以重视。更可能的问题是日志的积累。在 Kubernetes 中，日志通常在两种情况下保存：当容器正在运行时，以及当最近退出的容器的日志被保留用于故障排除时。这种方法旨在在保留重要日志和随着时间推移丢弃不必要日志之间取得平衡。然而，如果一个长时间运行的容器生成大量日志，它们可能会积累到超出节点磁盘容量的程度。要了解完整的监控定义，请查看详细信息。 允许 覆盖监控参数

节点内存压力是指 Kubernetes 节点上的内存资源受到过度压力的情况。虽然由于Kubernetes内置的资源管理机制，节点内存压力的出现并不常见，但在特定情况下仍然可能发生。节点内存压力可能产生的主要原因有两个。第一个原因与在节点上运行的容器的资源请求和限制配置不当或不足有关。Kubernetes 依赖资源请求和限制来有效分配和管理资源。如果容器的内存需求未准确配置，它们可能会消耗超过预期的内存，从而导致节点内存压力。第二个原因涉及内存密集型应用程序或进程的存在。某些工作负载或应用程序可能具有更高的内存需求，导致节点上的内存利用率增加。如果多个具有较大内存需求的Pod或容器在同一节点上调度而没有适当的资源分配，可能会导致内存压力。为了减轻节点内存压力，审查和调整容器的资源请求和限制至关重要，以确保它们与应用程序的实际内存需求相符。监控和优化应用程序内部的内存使用情况也可以帮助减少内存消耗。此外，考虑使用水平Pod自动扩缩来根据内存利用率动态调整Pod的数量。定期监控、分析与内存相关的指标以及主动分配内存资源可以帮助保持Kubernetes节点的健康内存状态。了解工作负载的具体需求并相应调整资源分配，以防止内存压力并确保最佳性能是至关重要的。 允许 覆盖监控参数

节点PID压力发生在Kubernetes节点上的可用进程标识符（PID）资源受到过度压力时。第一个原因与在节点上运行的容器的资源请求和限制配置不当或不足有关。Kubernetes 依赖准确的资源请求和限制来有效分配和管理资源。如果容器未正确配置其PID需求，它们可能会消耗超过预期的PID，从而导致节点PID压力。第二个原因是PID密集型应用程序或进程的存在。某些工作负载或应用程序对进程标识符的需求更高，导致节点上的PID利用率增加。如果多个具有显著PID需求的Pod或容器在同一节点上调度而没有适当的资源分配，可能会导致PID压力。为了解决节点PID压力，重要的是审查和调整容器的资源请求和限制，以确保它们与应用程序的实际PID需求相符。监控和优化应用程序内部的PID使用也可以帮助减少PID消耗。此外，考虑水平Pod自动扩缩可以根据PID利用率动态调整Pod的数量。定期监控、分析与PID相关的指标，以及主动分配PID资源，对于维护Kubernetes节点上PID使用的健康状态至关重要。了解工作负载的具体要求并相应调整资源分配，以防止PID压力并确保最佳性能是至关重要的。 允许 覆盖监控参数

检查节点是否正常运行。 允许 覆盖监控参数

验证没有孤立的持久卷。孤立的持久卷是指未与持久卷声明关联的持久卷。孤立的持久卷可能会带来安全风险，因为它可能包含未被使用的敏感数据。孤立的持久卷也可能是资源的浪费，因为它没有被使用。 允许 覆盖监控参数，但仅限于`enabled`属性。

确保在Kubernetes集群中运行的容器有足够的内存以正常工作是重要的。内存不足（OOM）情况可能导致容器崩溃或变得无响应，从而导致重启和潜在的数据丢失。 为了监控这些情况，SUSE Observability 设置了一个检查项，检测并报告在集群中运行的容器中的 OOM 事件。此检查将帮助您识别任何内存不足的容器，并允许您采取措施在问题发生之前防止问题。 允许 覆盖监控参数

检查已调度的Pod是否在预期时间内运行并准备好接收流量。

监控服务器和消费者跨度的持续时间。当持续时间的95百分位数超过阈值（默认5000毫秒）时，监控器处于偏差状态。此监控器支持通过监控参数覆盖来覆盖设置。

监控具有错误状态的服务器和消费者跨度的百分比。如果错误跨度的百分比超过阈值（默认5），监控器将处于偏离状态。此监控器支持通过监控参数覆盖来覆盖设置。

如果一个Pod处于等待状态，并且包含CreateContainerConfigError、CreateContainerError、CrashLoopBackOff或ImagePullBackOff的原因，则将被视为偏差。

确保您的ReplicaSet（和Deployment）的期望副本数得到满足是很重要的。ReplicaSets和Deployments用于管理Kubernetes集群中特定Pod的副本数量。

为了监控这一点，SUSE Observability 设置了一个检查，以验证可用副本是否与所需副本数量匹配。此检查仅适用于期望副本数大于零的ReplicaSets和Deployments。

此外，ReplicaSet的健康状态将传播到Deployment，以便进行更全面的监控。

监控Kubernetes集群中每个容器的重启是很重要的。容器可能因多种原因重启，包括应用程序或基础设施的问题。 为了确保应用程序平稳运行，SUSE Observability 设置了一个监控器，用于跟踪10分钟内容器重启的次数。如果在此时间段内重启次数超过3次，容器的健康状态将被设置为偏离，表示可能存在需要调查的问题。

确保您的服务对用户可用且可访问非常重要。为了监控这一点，我们设置了一个检查，验证服务是否至少有一个可用的端点。端点是网络地址，使分布式系统中不同组件之间能够通信，服务正常运行需要这些端点可用。 如果在过去10分钟内没有可用的端点，监控将保持在偏离状态，表示服务可能存在需要解决的问题。 要了解完整的监控定义，请查看详细信息。

监控服务器和消费者跨度的持续时间。当持续时间的95百分位数超过阈值（默认5000毫秒）时，监视器处于偏离状态。此监控器支持通过 监控参数覆盖 来覆盖设置。

Kubernetes 服务中处于错误状态的服务器和消费者跨度所占的百分比。此监视器支持通过monitor argument overrides覆盖设置。

确保StatefulSet的期望副本数得到满足是很重要的。StatefulSets用于管理有状态的应用程序，并需要特定数量的副本才能正常运行。

为了监控这一点，SUSE Observability 设置了一个检查，以验证可用副本是否与期望副本数匹配。此检查仅适用于期望副本数大于零的StatefulSets。

如果您在Kubernetes中遇到"NodeNotSchedulable"事件，这意味着Kubernetes调度程序由于某些约束或节点问题无法将一个Pod放置在特定节点上。当调度程序无法根据Pod的资源需求和其他约束找到合适的节点来运行Pod时，会发生此事件。

集群本身没有任何健康状态。但集群是由几个组件构成的，其中一些对正常运行至关重要。监视器聚合这些组件的状态：

监视器聚合所有最上层依赖项的状态，然后根据直接观察（例如，从指标中）返回最关键的健康状态。 这种方法确保健康信号从低级技术组件（如 Pod）传播到更高级的逻辑组件，但仅在组件本身缺乏观察到的健康状态时。 要有效使用此监视器，请确保以下某些或所有健康检查已禁用：

如果您有一个逻辑组件没有直接监视器的用例，您可以使用Derived State Monitor功能，根据其所依赖的技术组件推断其健康状况。