Tâche planifiée qui s'emballe

Une tâche planifiée se déclenche, ne se termine pas et maintient le CPU à 100 %. C'est le seul incident qui revient après que vous l'avez traité — parce que s'occuper du processus n'est pas la même chose que s'occuper du planning.

Ce qu'il fait

Sur la machine cible, le CPU entre en saturation : WARN, puis CRIT, et la disponibilité glisse avec lui. La tâche est un processus nommé et apparaît dans la sortie de top avec son PID ; la difficulté n'est donc pas le diagnostic.

La difficulté, c'est que le planificateur est toujours vivant. Vous arrêtez le processus et la même instance d'incident le relance peu après. Elle le fait un nombre limité de fois, jusqu'à ce que la fenêtre propre de la tâche se referme d'elle-même — la nuit que vous passez à vous en occuper encore et encore finit donc bien par s'achever, mais elle s'achève parce que la tâche a perdu patience, pas parce que vous avez résolu quoi que ce soit ; la ligne de log de clôture le dit.

La signature dans les logs

Dans le log de cron, une tâche démarre, puis monit affiche le même nom au-dessus du seuil de CPU :

03:02:15 db-01 CRON[24310]: (root) CMD (/opt/jobs/backup.sh)
03:02:51 db-01 monit[588]: 'backup.sh' cpu usage of 100% matches resource limit [cpu usage > 80.0%]
03:03:40 db-01 monit[588]: 'db-01' cpu usage of 98% matches resource limit [cpu usage > 90.0%]

Le moment fait partie de la signature. Cet incident tend à tomber au milieu de la garde, vers 03:00 — précisément quand s'ouvrirait une vraie fenêtre de sauvegarde. Vous trouvez le processus avec top ; qui l'a lancé est écrit dans ps et dans les enregistrements de cron.

Si vous n'y touchez pas

Une saturation prolongée du CPU sur une seule machine, et la dette de SLA qu'apporte un incident non résolu. On y survit — la machine ne passe pas à DOWN d'elle-même — mais il saigne de la disponibilité tant qu'il tourne.

Le distinguer des autres

Quand il apparaît