Fixed playbook

Signed-off-by: Marco Pracucci <[email protected]>

Author: pracucci

cortex-mixin/docs/playbooks.md

@@ -231,16 +231,6 @@ How to **investigate**:
 
 _If the alert `CortexIngesterTSDBHeadCompactionFailed` fired as well, then give priority to it because that could be the cause._
 
-### CortexRolloutStuck
-
-This alert fires when a Cortex service rollout is stuck, which means the number of updated replicas doesn't match the expected one and looks there's no progress in the rollout. The alert monitors services deployed as Kubernetes `StatefulSet` and `Deployment`.
-
-How to **investigate**:
-- Run `kubectl -n <namespace> get pods -l name=<statefulset|deployment>` to get a list of running pods
-- Ensure there's no pod in a failing state (eg. `Error`, `OOMKilled`, `CrashLoopBackOff`)
-- Ensure there's no pod `NotReady` (the number of ready containers should match the total number of containers, eg. `1/1` or `2/2`)
-- Run `kubectl -n <namespace> describe statefulset <name>` or `kubectl -n <namespace> describe deployment <name>` and look at "Pod Status" and "Events" to get more information
-
 #### Ingester hit the disk capacity
 
 If the ingester hit the disk capacity, any attempt to append samples will fail. You should:
@@ -734,6 +724,15 @@ When an alertmanager cannot read the state for a tenant from storage it gets log
 - The state could not be merged because it might be invalid and could not be decoded. This could indicate data corruption and therefore a bug in the reading or writing of the state, and would need further investigation.
 - The state could not be read from storage. This could be due to a networking issue such as a timeout or an authentication and authorization issue with the remote object store.
 
+### CortexRolloutStuck
+
+This alert fires when a Cortex service rollout is stuck, which means the number of updated replicas doesn't match the expected one and looks there's no progress in the rollout. The alert monitors services deployed as Kubernetes `StatefulSet` and `Deployment`.
+
+How to **investigate**:
+- Run `kubectl -n <namespace> get pods -l name=<statefulset|deployment>` to get a list of running pods
+- Ensure there's no pod in a failing state (eg. `Error`, `OOMKilled`, `CrashLoopBackOff`)
+- Ensure there's no pod `NotReady` (the number of ready containers should match the total number of containers, eg. `1/1` or `2/2`)
+- Run `kubectl -n <namespace> describe statefulset <name>` or `kubectl -n <namespace> describe deployment <name>` and look at "Pod Status" and "Events" to get more information
 
 ## Cortex routes by path