Strange CloudWatch comportamento allarme

Question

Ho uno script di backup che viene eseguito ogni 2 ore. Voglio utilizzare CloudWatch per tenere traccia delle esecuzioni di successo di questo script e degli allarmi di CloudWatch per ricevere notifiche ogni volta che lo script incontra problemi.

Lo script mette un punto dati su una metrica CloudWatch dopo ogni backup riuscito:

mon-put-data --namespace Backup --metric-name $metric --unit Count --value 1 

Ho un allarme che va allo stato allarme ogni volta che la statistica "Somma" sulla metrica è inferiore a 2 in un Periodo di 6 ore.

Per testare questa configurazione, dopo un giorno, ho interrotto l'inserimento dei dati nella metrica (ovvero, ho commentato il comando mon-put-data). Bene, alla fine l'allarme è andato in stato di ALLARME e ho ricevuto una notifica via email, come previsto.

Il problema è che, qualche tempo dopo, l'allarme ritorna allo stato OK, tuttavia non sono stati aggiunti nuovi dati alla metrica!

Le due transizioni (OK => ALARM, quindi ALARM => OK) sono state registrate e riproduco i registri in questa domanda. Si noti che, sebbene entrambi mostrino "periodo: 21600" (ovvero, 6 ore), il secondo mostra un intervallo di 12 ore tra startDate e queryDate; Vedo che questo potrebbe spiegare la transizione, ma non riesco a capire perché Cloud Watch stia considerando un intervallo di 12 ore per calcolare una statistica con un periodo di 6 ore!

Cosa mi manca qui? Come configurare gli allarmi per ottenere ciò che voglio (ad esempio, ricevere una notifica se non vengono eseguiti i backup)?

{ 
    "Timestamp": "2013-03-06T15:12:01.069Z", 
    "HistoryItemType": "StateUpdate", 
    "AlarmName": "alarm-backup-svn", 
    "HistoryData": { 
     "version": "1.0", 
     "oldState": { 
      "stateValue": "OK", 
      "stateReason": "Threshold Crossed: 1 datapoint (3.0) was not less than the threshold (3.0).", 
      "stateReasonData": { 
       "version": "1.0", 
       "queryDate": "2013-03-05T21:12:44.081+0000", 
       "startDate": "2013-03-05T15:12:00.000+0000", 
       "statistic": "Sum", 
       "period": 21600, 
       "recentDatapoints": [ 
        3 
       ], 
       "threshold": 3 
      } 
     }, 
     "newState": { 
      "stateValue": "ALARM", 
      "stateReason": "Threshold Crossed: 1 datapoint (1.0) was less than the threshold (2.0).", 
      "stateReasonData": { 
       "version": "1.0", 
       "queryDate": "2013-03-06T15:12:01.052+0000", 
       "startDate": "2013-03-06T09:12:00.000+0000", 
       "statistic": "Sum", 
       "period": 21600, 
       "recentDatapoints": [ 
        1 
       ], 
       "threshold": 2 
      } 
     } 
    }, 
    "HistorySummary": "Alarm updated from OK to ALARM" 
} 

La seconda, che ho semplice non riesco a capire:

{ 
    "Timestamp": "2013-03-06T17:46:01.063Z", 
    "HistoryItemType": "StateUpdate", 
    "AlarmName": "alarm-backup-svn", 
    "HistoryData": { 
     "version": "1.0", 
     "oldState": { 
      "stateValue": "ALARM", 
      "stateReason": "Threshold Crossed: 1 datapoint (1.0) was less than the threshold (2.0).", 
      "stateReasonData": { 
       "version": "1.0", 
       "queryDate": "2013-03-06T15:12:01.052+0000", 
       "startDate": "2013-03-06T09:12:00.000+0000", 
       "statistic": "Sum", 
       "period": 21600, 
       "recentDatapoints": [ 
        1 
       ], 
       "threshold": 2 
      } 
     }, 
     "newState": { 
      "stateValue": "OK", 
      "stateReason": "Threshold Crossed: 1 datapoint (3.0) was not less than the threshold (2.0).", 
      "stateReasonData": { 
       "version": "1.0", 
       "queryDate": "2013-03-06T17:46:01.041+0000", 
       "startDate": "2013-03-06T05:46:00.000+0000", 
       "statistic": "Sum", 
       "period": 21600, 
       "recentDatapoints": [ 
        3 
       ], 
       "threshold": 2 
      } 
     } 
    }, 
    "HistorySummary": "Alarm updated from ALARM to OK" 
} 

Answer 1

Questo comportamento (che il monitor non ha transizione verso lo stato INSFUCCIENT_DATA è perché CloudWatch considera 'pre-timestamp' datapoints metriche e così (per un allarme di 6 ore) se non ci sono dati nell'attuale finestra dell'ora aperta 6. prenderà i dati dalla finestra precedente di 6 ore (quindi il formato orario di 12 ore che vedi sopra)

Per aumentare la fedeltà 'del tuo allarme, ridurre il periodo di allarme t o 1 ora/3600 secondi e aumenta il numero di periodi di valutazione per il numero di periodi per cui si desidera mettere in allarme in caso di guasto. Ciò garantirà le transizioni di allarme in INSFUCCIENT_DATA come previsto.

Come configurare gli allarmi per ottenere ciò che voglio (ad esempio, ricevere una notifica se non vengono eseguiti i backup)?

Una possibile architettura per l'allarme sarebbe pubblicare 1 se il lavoro è andato a buon fine, 0 se non è riuscito. Quindi creare un allarme con una soglia di < 1 per periodi da 3 a 3600s, il che significa che l'allarme andrà in ALLARME se il lavoro sta fallendo (cioè in esecuzione .. ma in mancanza). Se imposti anche un'azione INSFUCCIENT_DATA su quell'allarme, riceverai anche una notifica se il tuo lavoro non è in esecuzione.

Spero che abbia senso.