Stac 19900

use/alerting/k8s-override-monitor-arguments.md

@@ -46,13 +46,17 @@ The full annotation then would look like
  monitor.kubernetes-v2.stackstate.io/service-available-endpoint: |-
  {
  "threshold": 0.0,
- "failureState": "CRITICAL"
+ "failureState": "CRITICAL",
  "enabled": true
  }
 ```
 
 ## What monitors allow overriding arguments?
 * [Available service endpoints](/use/alerting/kubernetes-monitors.md#available-service-endpoints)
+* [Cpu limits resourcequota](/use/alerting/kubernetes-monitors.md#cpu-limits-resourcequota)
+* [Cpu requests resourcequota](/use/alerting/kubernetes-monitors.md#cpu-requests-resourcequota)
+* [Memory limits resourcequota](/use/alerting/kubernetes-monitors.md#memory-limits-resourcequota)
+* [Memory requests resourcequota](/use/alerting/kubernetes-monitors.md#memory-requests-resourcequota)
 * [Node Disk Pressure](/use/alerting/kubernetes-monitors.md#node-disk-pressure)
 * [Node Memory Pressure](/use/alerting/kubernetes-monitors.md#node-memory-pressure)
 * [Node PID Pressure](/use/alerting/kubernetes-monitors.md#node-pid-pressure)

use/alerting/kubernetes-monitors.md

@@ -16,6 +16,13 @@ It is important to ensure that your services are available and accessible to use
 If there is an occurrence of zero endpoints available within the last 10 minutes, the monitor will remain deviating, indicating that there may be an issue with the service that needs to be addressed.
 Allows [Override Monitor arguments](/use/alerting/k8s-override-monitor-arguments.md)
 
+### Cpu limits resourcequota
+
+Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource limits for Cpu defined in a ResourceQuota. The monitor will alert when the total Cpu limits in the namespace gets to 90% or more of the established by the quota. Each `resourcequota` in the namespace produces a monitor health state.
+
+### Cpu requests resourcequota
+Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource requests for Cpu defined in a ResourceQuota. The monitor will alert when the total Cpu requests in the namespace gets to 90% or more of the established by the quota. Each `resourcequota` in the namespace produces a monitor health state.
+
 ### Daemonset desired replicas
 
 It is important that the desired number of replicas for a Daemonset is being met. Daemonsets are used to manage a set of pods that need to run on all or a subset of nodes in a cluster, ensuring that a copy of the pod is running on each node that meets the specified criteria. This is useful for tasks such as logging, monitoring, and other cluster-level tasks that need to be executed on every node in the cluster. To monitor this, StackState has set up a check that verifies if the available replicas match the desired number of replicas. This check will only be applied to DaemonSets that have a desired number of replicas greater than zero. - If the number of available replicas is less than the desired number, the monitor will signal a DEVIATING health state, indicating that there may be an issue with the StatefulSet. - If the number of available replicas is zero, the monitor will signal a CRITICAL health state, indicating that the StatefulSet is not functioning at all. To understand the full monitor definition check the details.
@@ -44,6 +51,12 @@ It is important to monitor the usage of Persistent Volume Claims (PVCs) in your
 It is important to monitor the usage of Persistent Volume Claims (PVCs) in your Kubernetes cluster over time. PVCs are used to store data that needs to persist beyond the lifetime of a container, and it's crucial to ensure that they have enough space to store the data.
 To track this, StackState set up a check that uses linear prediction to forecast the Kubernetes volume usage trend over a 4-day period. If the trend indicates that the PVCs will run out of space within this time frame, you will receive a notification, allowing you to take action to prevent data loss or downtime.
 
+### Memory limits resourcequota
+Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource limits for memory defined in a ResourceQuota. The monitor will alert when the total memory limits in the namespace gets to 90% or more of the established by the quota. Each `resourcequota` in the namespace produces a monitor health state.
+
+### Memory requests resourcequota
+Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource requests for memory defined in a ResourceQuota. The monitor will alert when the total memory requests in the namespace gets to 90% or more of the established by the quota. Each `resourcequota` in the namespace produces a monitor health state.
+
 ### Node Disk Pressure
 
 Node disk pressure refers to a situation where the disks connected to a node experience excessive strain. While encountering node disk pressure is unlikely due to Kubernetes' built-in preventive measures, it can still occur sporadically. There are two primary reasons why node disk pressure may arise. The first reason relates to Kubernetes failing to clean up unused images. Under normal circumstances, Kubernetes regularly checks for and deletes any images that are not in use. Therefore, this is an uncommon cause of node disk pressure, but it should be acknowledged. The more probable issue involves the accumulation of logs. In Kubernetes, logs are typically saved in two scenarios: when containers are running and when the most recently exited container's logs are retained for troubleshooting purposes. This approach aims to strike a balance between preserving important logs and discarding unnecessary ones over time. However, if a long-running container generates an extensive volume of logs, they may accumulate to the point where they overload the node disk's capacity. To understand the full monitor definition check the details.