Avec les escalades, vous pouvez cr¨¦er des sc¨¦narios personnalis¨¦s pour envoyer des notifications ou ex¨¦cuter des commandes ¨¤ distance.
Concr¨¨tement cela signifie que :
Les actions sont escalad¨¦es en fonction de l'¨¦tape d'escalade. Chaque ¨¦tape a une dur¨¦e dans le temps.
Vous pouvez d¨¦finir ¨¤ la fois la dur¨¦e par d¨¦faut et une dur¨¦e personnalis¨¦e d'une ¨¦tape individuelle. La dur¨¦e minimale d'une ¨¦tape d'escalade est de 60 secondes.
Vous pouvez d¨¦marrer des actions, telles que l'envoi de notifications ou l'ex¨¦cution de commandes, ¨¤ partir de n'importe quelle ¨¦tape. La premi¨¨re ¨¦tape concerne les actions imm¨¦diates. Si vous souhaitez retarder une action, vous pouvez l'affecter ¨¤ une ¨¦tape ult¨¦rieure. Pour chaque ¨¦tape, plusieurs actions peuvent ¨ºtre d¨¦finies.
Le nombre d'¨¦tapes d'escalade n'est pas limit¨¦.
Les escalades sont d¨¦finies lors de la configuration d'une op¨¦ration. Les escalades sont prises en charge uniquement pour les op¨¦rations probl¨¦matiques, pas pour la r¨¦cup¨¦ration.
Consid¨¦rons ce qui se passe dans diff¨¦rentes circonstances si une action contient plusieurs ¨¦tapes d'escalade.
Situation | Comportement |
---|---|
L'h?te en question passe en maintenance apr¨¨s l'envoi de la notification de probl¨¨me initiale | Selon le param¨¨tre Suspendre les op¨¦rations pour les probl¨¨mes supprim¨¦s dans la configuration de l'action, tout les ¨¦tapes d'escalade restantes sont ex¨¦cut¨¦es soit avec un retard caus¨¦ par la p¨¦riode de maintenance, soit sans retard. Une p¨¦riode de maintenance n'annule pas les op¨¦rations. |
La p¨¦riode de temps d¨¦finie dans la condition d'action ±Ê¨¦°ù¾±´Ç»å±ð de temps se termine apr¨¨s l'envoi de la notification initiale | Toutes les ¨¦tapes d'escalade restantes sont ex¨¦cut¨¦es. La condition ±Ê¨¦°ù¾±´Ç»å±ð ne peut pas arr¨ºter les op¨¦rations ; il a un effet sur le moment o¨´ les actions sont d¨¦marr¨¦es/non d¨¦marr¨¦es, pas sur les op¨¦rations. |
Un probl¨¨me commence pendant la maintenance et continue (n'est pas r¨¦solu) apr¨¨s la fin de la maintenance | Selon le param¨¨tre Suspendre les op¨¦rations pour les probl¨¨mes supprim¨¦s dans la configuration de l'action, toutes les ¨¦tapes d'escalade sont ex¨¦cut¨¦es d¨¨s la fin de la maintenance ou imm¨¦diatement. |
Un probl¨¨me commence pendant une maintenance sans donn¨¦e et continue (n'est pas r¨¦solu) apr¨¨s la fin de la maintenance | Il doit attendre que le d¨¦clencheur se d¨¦clenche, avant que toutes les ¨¦tapes d'escalade ne soient ex¨¦cut¨¦es. |
Diff¨¦rentes escalades se succ¨¨dent et se chevauchent | L'ex¨¦cution de chaque nouvelle escalade remplace l'escalade pr¨¦c¨¦dente, mais pour au moins une ¨¦tape d'escalade qui est toujours ex¨¦cut¨¦e sur l'escalade pr¨¦c¨¦dente. Ce comportement est pertinent dans les actions sur les ¨¦v¨¦nements qui sont cr¨¦¨¦s avec CHAQUE ¨¦valuation de probl¨¨me du d¨¦clencheur. |
Lors d'une escalade en cours (comme l'envoi d'un message), en fonction de tout type d'¨¦v¨¦nement : - l'action est d¨¦sactiv¨¦e En fonction de l'¨¦v¨¦nement d¨¦clencheur : - le d¨¦clencheur est d¨¦sactiv¨¦ - l'h?te ou l'¨¦l¨¦ment est d¨¦sactiv¨¦ Selon un ¨¦v¨¦nement interne concernant les d¨¦clencheurs : - le d¨¦clencheur est d¨¦sactiv¨¦ Selon un ¨¦v¨¦nement interne concernant les ¨¦l¨¦ments/r¨¨gles de d¨¦couverte de bas niveau : - l'¨¦l¨¦ment est d¨¦sactiv¨¦<br >- l'h¨¦bergeur est d¨¦sactiv¨¦ |
Le message en cours est envoy¨¦ puis un autre message sur l'escalade est envoy¨¦. Le message de suivi contiendra le texte d'annulation au d¨¦but du corps du message (NOTE: Escalation canceled) indiquant la raison (par exemple, **NOTE: Escalation canceled: action '<Action name>' disabled). De cette fa?on, le destinataire est inform¨¦ que l'escalade est annul¨¦e et qu'aucune autre ¨¦tape ne sera ex¨¦cut¨¦e. Ce message est envoy¨¦ ¨¤ tous ceux qui ont re?u les notifications auparavant. La raison de l'annulation est ¨¦galement consign¨¦e dans le fichier journal du serveur (¨¤ partir du Niveau de d¨¦bogage 3=Avertissement). Notez que le message Escalation canceled* est ¨¦galement envoy¨¦ si les op¨¦rations sont termin¨¦es, mais les op¨¦rations de r¨¦cup¨¦ration sont configur¨¦es et ne sont pas encore ex¨¦cut¨¦es. |
Lors d'une escalade en cours (comme l'envoi d'un message) l'action est supprim¨¦e | Plus aucun message n'est envoy¨¦. Les informations sont consign¨¦es dans le fichier journal du serveur (¨¤ partir du Niveau de d¨¦bogage 3=Avertissement), par exemple : escalation canceled: action id:334 deleted |
Envoi d'une notification r¨¦p¨¦t¨¦e une fois toutes les 30 minutes (5 fois au total) ¨¤ un groupe 'MySQL Administrators'. Pour le configurer :
Les notifications seront envoy¨¦es 0:00, 0:30, 1:00, 1:30, 2:00 heures apr¨¨s le d¨¦but du probl¨¨me (¨¤ moins, bien s?r, que le probl¨¨me ne soit r¨¦solu plus t?t).
Si le probl¨¨me est r¨¦solu et qu'un message de r¨¦cup¨¦ration est configur¨¦, il sera envoy¨¦ ¨¤ ceux qui ont re?u au moins un message de probl¨¨me dans ce sc¨¦nario d'escalade.
Si le d¨¦clencheur qui a g¨¦n¨¦r¨¦ une escalade active est d¨¦sactiv¨¦, Áú»¢¶Ä²© envoie un message informatif ¨¤ ce sujet ¨¤ tous ceux qui ont d¨¦j¨¤ re?u des notifications.
Envoi d'une notification diff¨¦r¨¦e concernant un probl¨¨me de longue date. Configurer :
Une notification ne sera envoy¨¦e qu'¨¤ l'¨¦tape 2 du sc¨¦nario d'escalade, ou 10 heures apr¨¨s le d¨¦but du probl¨¨me.
Vous pouvez personnaliser le texte du message avec quelque chose comme "Le probl¨¨me date de plus de 10 heures".
Faire remonter le probl¨¨me au Boss.
Dans le premier exemple ci-dessus, nous avons configur¨¦ l'envoi p¨¦riodique de messages aux administrateurs MySQL. Dans ce cas, les administrateurs recevront quatre messages avant que le probl¨¨me ne soit transmis au gestionnaire de base de donn¨¦es. Notez que le responsable ne recevra un message que si le probl¨¨me n'est pas encore acquitt¨¦, c'est-¨¤-dire que personne n'y travaille.
D¨¦tails de l'op¨¦ration 2?:
Notez l'utilisation de la macro {ESC.HISTORY} dans le message personnalis¨¦. La macro contiendra des informations sur toutes les ¨¦tapes pr¨¦c¨¦demment ex¨¦cut¨¦es sur cette escalade, telles que les notifications envoy¨¦es et les commandes ex¨¦cut¨¦es.
Un sc¨¦nario plus complexe. Apr¨¨s plusieurs messages aux administrateurs MySQL et une escalade vers le responsable, Áú»¢¶Ä²© essaiera de red¨¦marrer la base de donn¨¦es MySQL. Cela se produira si le probl¨¨me existe depuis 2h30 et qu'il n'a pas ¨¦t¨¦ acquitt¨¦.
Si le probl¨¨me persiste, apr¨¨s 30 minutes suppl¨¦mentaires, Áú»¢¶Ä²© enverra un message ¨¤ tous les utilisateurs invit¨¦s.
Si cela ne r¨¦sout pas le probl¨¨me, apr¨¨s une heure suppl¨¦mentaire, Áú»¢¶Ä²© red¨¦marrera le serveur avec la base de donn¨¦es MySQL (deuxi¨¨me commande ¨¤ distance) ¨¤ l'aide des commandes IPMI.
Une escalade avec plusieurs op¨¦rations affect¨¦es ¨¤ une ¨¦tape et des intervalles personnalis¨¦s utilis¨¦s. La dur¨¦e de l'¨¦tape de fonctionnement par d¨¦faut est de 30 minutes.
Les notifications seront envoy¨¦es comme suit :