3. Target disponibili

3.1. Target di sistema

3.1.1. CONTINUE

Non esegue nessuna operazione.

-J CONTINUE

3.1.1.1. Esempi

entables   -A DEFAULT  -m ......  -J CONTINUE

3.1.2. RETURN

L’allarme termina la traversata della catena corrente, tornando eventualmente alla catena precedente in caso avesse effettuato un jump (o piu’ jump).

NOTA: non viene applicata la regola di default della catena corrente.

-J RETURN

3.1.2.1. Esempi

entables   -A CATENA_H24  -m ......  -J RETURN

3.1.3. ENDTABLE

L’allarme termina immediatamente la sua traversata della tabella corrente (senza che vengano processate regole di default delle chain che sta attraversando):

-J ENDATABLE

3.1.3.1. Esempi

entables   -A DEFAULT  -m ......  -J ENDTABLE

3.1.4. DROP

Ferma definitvamente un allarme.

-J DROP

3.1.4.1. Esempi

Tutti gli allarmi nel weekend vengono ignorati:

entables   -A DEFAULT  -m times --times_range  0-24/6-7  -J DROP

3.1.5. JUMP

Il comando di jump non viene indicato esplicitamente. Per effettuare un jump ad una catena bisogna indicare come target il nome della catena:

-J COMMON_RULES

3.1.5.1. Esempi

Tutti gli allarmi prodotto nei giorni del weekend vengono mandati ad una catena chiamata WEEKENDS:

entables   -A DEFAULT  -m times --times_range  0-24/6-7  -J WEEKENDS

3.2. SETATTR

Aggiunge al pacchetto dati di un allarme un campo valorizzato in base ai parametri specificati

I parametri questo target vanno specificati secondo la sintassi:

-J SETATTR --setattr_field_name <nome>  --setattr_<parametro opzionale> <valore>

Parametri obbligatori:

Parametro Type Descrizione
field_name stringa Nome del nuovo campo da aggiungere al messaggio

E’ possibile specificare uno solo dei seguenti parametri opzionali:

Parametro Type Descrizione
value stringa Salva nel messaggio un nuovo campo field_name con il valore indicato (stringa libera)
treetags stringa Salva nel messaggio un nuovo campo field_name con tutti i nomi dei tag relativi all’allarme appartenenti al tree indicato
tagmeta stringa Salva nel messaggio un nuovo campo field_name con la stringa contenente tutti i metadati con nome tagmeta estratto da tutti i tag associatil al nodo/condition dell’allarme. tagmeta puo’ essere ‘*’

3.2.1. Esempi

Esempio 1: Aggiungiamo al messaggio un campo custom con un valore (per essere processato in qualche altra regola)

entables -t notify -A DEFAULT   -J SETATTR --setattr_field_name 'foo'        --setattr_value '12345'

Esempio 2: I messaggi nel weekend vengono ritardati fino al lunedi’ mattina:

entables -t notify -A DEFAULT   -J SETATTR --setattr_field_name 'foo'        --setattr_treetags 'geo'

Esempio 3: salva un campo “indirizzi” con il valore del metadato “referenti” dei tag associati al nodo/condition dell’allarme:

entables -t notify -A DEFAULT   -j SETATTR --setattr_field_name  indirizzi   --setattr_tagmeta referenti
                                
entables -t notify -A DEFAULT   -j SMTP    --smtp_subject '${mail_subject}' --smtp_message '${mail_body}'    --smtp_rcpt_to '${tags['"'"'alarmpath:indirizzi'"'"']}'

3.3. SMTP

Questo target permette l’invio di un messaggio tramite protocollo SMTP.

I parametri questo target vanno specificati secondo la sintassi:

-J SMTP --smtp_<parametro> <valore> [ --smtp_<parametro> <valore> ... ]

Parametri:

Parametro Type Default Descrizione
smtp_host stringa localhost Indirizzo o hostname del’MTA.
smtp_port numero 25 Porta TCP dell’MTA.
envelope_from email monitoring-daemon@localhost Return-path SMTP del messaggio.
header_from email monitoring-daemon@$localhost Indirizzo che comaparira nel campo “From:”
rcpt_to email root@localhost Destinatario/i del messaggio (separati da virgole)
rcpt_cc email   Destinatario/i in CC (separati da virgole)
rcpt_bcc email   Destinatario/i in BCC (separati da virgole)
message stringa Message from ${hostname} Corpo del mesasaggio
subject stringa ${rawalarm} Soggetto del messaggio
xheaders stringa   Stringa con Extra-headers SMTP (es. X-Message-Foo: bar )

3.3.1. Destinatari multipli

IL parametro rcpt_to puo’ contenere destinatari multipli separati da virgola (‘,’).

entables -A DEFAULT -j SMTP --smtp_rcpt_to noc@labs.it,netwarning,root

IMPORTANTE: se la stringa memorizzata in rcpt_to contiene caratteri di new-line ( ), questi vengono sostituiti con la virgola (‘,’).

3.3.2. Destinatari invalidi

Il target NON INVIA email quando il parametro rcpt_to conviene le seguenti stringhe:

  • stringa vuota

IMPORTANTE: l’allarme non viene inviato ma continua ad essere processato dalle regole successive.

IMPORTANTE: l’allarme non viene inviato e quindi non produce nessun tipo di LOG nel server MTA utilizzato.

3.3.3. Esempi

Invia tutti i messaggi a noc@labs.it:

entables -A DEFAULT -j SMTP --smtp_rcpt_to noc@labs.it  --smtp_rcpt_bcc hiddennoc@labs.it  --smpt_xheaders 'X-test: email di prova'

3.4. DELAY

Trattiene un allarme nel sistema fino al termine indicato.

I parametri questo target vanno specificati secondo la sintassi:

-J DELAY --delay_<parametro> <valore> [ --delay_<parametro> <valore> ... ]

Parametri:

Parametro Type Default Descrizione
holdfor numero   Numero di secondi da attendere prima di sbloccare il messaggio
holduntil stringa   Data di scadenza di quando sbloccare il messaggio.
holduntil_next stringa   Prossimo orario valido (del giorno stesso o giorno successivo)
drop_if_up numero 0 Quando vale 1, l’allarme di DOWN non riparte se la condition associata all’allarme non e’ in stato DOWN (o similiari)
drop_if_changed numero 0 Quando vale 1, l’allarme non riparte se la condition associata all’allarme ha subito una qualunque variazione di stato

Obsoleti:

Parametro Type | Default Descrizione
seconds

DEPRECATO: vedi “holdfor”
until     DEPRECATO: vedi “holduntil”
until_next     DEPRECATO: vedi “holduntil_next”

3.4.1. Formato e semantica dei paremetri holdfor/holduntil/holduntil_next

3.4.1.1. Formati validi per parametro holduntil

Il parametro holduntil seleziona il prossimo giorno SEMPRE SUCCESSIVO a quello corrente.

Questo significa che se adesso sono le 06:30 di lunedi’ (monday) 1/1/2016 e un allarme viene processato adesso, se il parametro holduntil viene specificato con valore:

monday 7:00

il digest viene ritardato/genarto il prossimo lunedi (monday) SUCCESSIVO, ovvero 8/1/2016.

3.4.1.1.1. Formato 1
yyyy-mm-gg [ hh:mm [ :ss ]  ]          Es: 2013-12-23 12:34:56 , 2013-12-23 12:34 , 2013-12-23
3.4.1.1.2. Formato 2
<day name       > [ hh:ss ]            Es: monday 12:34 , monday
<day week number> [ hh:ss ]            Es: 1 12:34, 1

I giorni della settimana:

monday           1
tuesday          2
wednesday        3
thursday         4
friday           5
saturday         6
sunday           7
3.4.1.1.3. Formato 3
next-work-day hh:ss [ <working days> ]

Calcola il primo giorno+orario lavorativo immediatamente successivo al momento di elaborazione. Il giorno lavorativo viene scelto “saltando” i giorni festivi configurati in Sanet.

E’ possibile specificare quali giorni della settimana sono da considerare giorni lavorativi attraverso il parametro <working days>.

Esempio:

next-work-day 8:00                  # il giorno lavorativo piu' vicino (festivita'+ sabato + domeniche esclusi)
next-work-day 8:00 1,2,3,4,5        # idem

next-work-day 8:00 1,2,3,4,6,7      # il giorno lavorativo piu' vicino (festivita' + venerdi' di preghiera esclusi)

Se la data di esecuzione ha superato il giorno indicato, viene considerato il giorno della settimana successiva.

3.4.2. Esempi

I messaggi nel weekend vengono ritardati fino al lunedi’ mattina:

entables   -A DEFAULT  -m times --times_range  0-24/6-7                 -j DELAY --delay_holdfor        120

entables   -A DEFAULT  -m times --times_range  0-24/6-7                 -j DELAY --delay_holduntil      'monday 08:00'

entables   -A DEFAULT  -m times --times_range  00:00-8:00,18:00-24/1-5  -J DELAY --delay_holduntil_next '08:00'

entables   -A DEFAULT  -m times --times_range  00:00-8:00,18:00-24/1-5  -J DELAY --delay_holduntil_next '08:00' --delay_drop_if_up 1

3.5. DIGEST

Questo target viene utilizzato per fermare uno o piu’ allarmi che fanno match sulla regola. I messaggi intercettati vengono processati per produrre un “digest”.

  • Il primo allarme che fa match scatena il calcolo di un nuovo “digest”, che altro non e’ che un raggruppamento di allarmi.
  • Il primo allarme viene fermato e tenuto bloccato fino alla scadenza indicata.

Tutti gli allarmi successivi al primo che fanno match sulla stessa regola nello stesso range temporale, se vengono processati correttamente, vengono fermati e salvati in stato “merged”.

3.5.1. Allarmi ignorati dal digest

Se l’allarme da processare e’ relativo al cambio di stato di una condition (UP->DN, DN->UP), il target digest gestisce in maniera particolare i messaggi di UP:

REGOLA: se l’allarme e’ un UP, viene trattenuto (merge) solo se il nel digest e’ presente anche l’allarme del DOWN precedente.

3.5.2. Scadenza del digest e ripresa del routing

Alla scadenza del termine indicato, il primo allarme riparte con il routing arricchito dai seguenti campi:

Attributo Descrizione
isdigest 1 l’allarme e’ un digest, 0 l’allarme non e’ un digest (allarme ignorato)
digest_data conviene informazioni su tutti i messaggi che fanno parte dello stesso digest calcolato fino a quel momento.
digestinfo Campo composto con i seguenti attributi: ‘downs’ = numero di allarmi down ancora in corso. ‘conditions’: dizionario con numer i di allarmi raggruppati per condition

Per utilizzare le informazioni di questi attributi dovrebbero essere usati:

3.5.3. Parametri

I parametri questo target vanno specificati secondo la sintassi:

-j digest --digest_<parametro> <valore>

Elenco:

Parametro Type Default Descrizione
holdfor numero   Numero di secondi da attendere prima di sbloccare il messaggio
holduntil stringa   Data di scadenza di quando sbloccare il digest.
holduntil_next stringa   Prossimo orario valido (del giorno stesso o giorno successivo)

I parametri sono equivalenti al target DELAY.

Si rimanda alla sezione Formato e semantica dei paremetri holdfor/holduntil/holduntil_next per i dettagli sulla sintassi e semantica dei parametri.

3.5.4. Esempi

Esempi di regole per creare un digest: Tutti gli allarmi tra le 00:00 e le 24:00 del weekend vengono aggregati e il digest viene inviato alle 7:00 del lunedi seguente:

entables   -N OUTOFTIME                                  -j DROP
entables   -A OUTOFTIME -m times --times_range  0-24/6-7 -j DIGEST --digest_holduntil "monday 07:00:00"
entables   -A OUTOFTIME                                  -j SMTP   --smtp_rcpt_to "info@labs.it" --smpt_subject "Summary"  --smtp_message "${digesttextbrief}"  

entables   -A DEFAULT  -m times --times_range  0-24/6-7  -J OUTOFTIME
entables   -A DEFAULT                                    -j SMTP

3.6. SMTPDIGEST

Questo target permette di inviare tramite protocollo SMTP tutti gli allarmi DOWN piu’ recenti ed ancora attivi presenti in in un DIGEST.

3.6.1. Logica del target

Il target verifica per tutti gli allarmi aggregati quali allarmi di DOWN sono ancora validi (La condition associata e’ ancora DOWN) ed PER OGNIUONO invia un messaggio di mail per l’ultimo DOWN intercettato in base ai parametri specificati.

3.6.2. Parametri

I parametri questo target vanno specificati secondo la sintassi:

-J SMTPDIGEST --smtpdigest_<parametro> <valore> [ --smtpdigest_<parametro> <valore> ... ]

Parametri disponibili sono gli stessi del target _target-SMTP. Si rimanda alla documentazione del digest per dettagl sull’utilizzo dei parametri.

IMPORTANTE: Se nei parametri del target vengono usati dei tag ( ${mail_to}, ${mail_subject}. ${alarmid}, ecc..) questi vengono sostituiti di volta in volta con i dati dell’allarme di DOWN attivo e inviato.

3.6.3. Tag speciali utilizzabili nei parametri del digest

E’ possibile inviare informazioni aggiuntive sull’allarme di DOWN utilizzando dei tag appositi:

Tag Descrizione
${digestchangescount} Numero di variazioni aggregate dal digest relative alla stessa condition dell’allarme

3.6.4. Invio semplice del digest

Aggrega tutti gli allarmi fino alle 8:00 del prossimo lunedi’. Alle 8:00 di lunedi’ mattina tutti gli allarmi di DOW

entables -A DEFAULT -j DIGEST     --digest_holduntil "monday 8:00"
...
...
entables -A DEFAULT -m attr --attr_digest_downs 0     -j DROP 
entables -A DEFAULT                                   -j SMTPDIGEST --smtpdigest_rcpt_to '${mail_to}'  --smtpdigest_subject '${mail_subject}' --smtpdigest_message '${mail_body}'

3.6.5. Invio arricchito con informazioni dal digest

Come il precedente, ma nel subject e corpo del messaggio aggiungiamo qualche informazione per far capire che il messaggio di DOWN era associato ad un digest.

entables -A DEFAULT -j DIGEST     --digest_holduntil "monday 8:00"
...
...
entables -A DEFAULT -m attr --attr_digest_downs 0    -j DROP 
entables -A DEFAULT                                  -j SMTPDIGEST --smtpdigest_rcpt_to ' ${mail_to}' --smtpdigest_subject '[FOR DIGEST] [ ${digestchangescount} changes ] ${mail_subject}'  --smtpdigest_message '${mail_body}'

3.7. SILENCE

Ritarda un uno o piu’ allarmi fino all’orario indicato.

Di tutti gli allarmi generati dalla stessa condition e che vengono ritardati allo stesso istante temporale, viene fatto “ripartire” solo l’ultimo. Questo comportamento e’ leggermente modificabile attraverso parametri speciali ( Parametri speciali ).

I parametri questo target vanno specificati secondo la sintassi:

-J SILENCE --silence_<parametro> <valore> [ --silence_<parametro> <valore> ... ]

Parametri:

Parametro Type Default Descrizione
holdfor numero   Numero di secondi da attendere prima di sbloccare il messaggio
holduntil stringa   Data di scadenza di quando sbloccare il messaggio.
holduntil_next stringa   Prossimo orario valido (del giorno stesso o giorno successivo)

I parametri sono equivalenti al target DELAY.

Si rimanda alla sezione Formato e semantica dei paremetri holdfor/holduntil/holduntil_next per i dettagli sulla sintassi e semantica dei parametri.

3.7.1. Parametri speciali

La logica di filtro del target puo’ essere alterata attraverso due parametri:

Parametro Type Default Descrizione
drop_last_up numero 0 Quando vale 1, gli allarmi che dovrebbero ripartire vengono DROPPATI se sono relativi a stati UP.
notify_first_up numero 0 Quando vale 1, di tutti gli allarmi di una stessa condition “intercettati”, non viene gestito (e quindi non viene ritardato) il primo UP.

Il parametro notify_first_up serve per decidere come gestire allarmi UP relativi a condition che sono andate DOWN prima che si cominciasse a filtrare gli allarmi con una regola di SILENCE.

Esempio:

     DOWN        UP      DOWN    UP      DOWN       
-----v-----|-----^-------v-------^-------v---------------------|--------------->
         00:00                                                6:00

           |---------------holduntil_next 6:00---------------->

In questa situazione, il primo allarme UP viene “intercettato” e ignorato se non viene specificato altrimenti (valorizzando ad 1 il parametro notify_first_up).

Warning

Se viene intercettato un solo allarme UP per una determinata condition, se non si utilizza il parametro notify_first_up si rischia di non ricvere nessun allarme.

Il parametro drop_last_up server per decidere di ignorare situazioni di guasto che sono gia’ rientrate.

Esempio:

                DOWN    UP      DOWN    UP    DOWN   UP
----------|-----v-------^-------v-------^-----v------^--------|--------------->
        00:00                                                6:00

          |---------------holduntil_next 6:00---------------->

In questa situazione, alle 6:00 non vogliamo ricevere l’ultimo allarme (UP) perche’ la segnalazione non e’ significativa.

Warning

Se viene intercettato un solo allarme UP per una determinata condition, utilizzando il parametro drop_last_up si rischia di non ricvere nessun allarme.

3.7.2. Esempi

I messaggi nel weekend vengono ritardati fino al lunedi’ mattina:

entables   -A DEFAULT                                                   -j SILENCE --silence_holduntil      'monday 08:00'
entables   -A DEFAULT                                                   -j SILENCE --silence_holduntil      'monday 08:00'     --silence_drop_last_up 1       --silence_notify_first_up 1

entables   -A DEFAULT  -m tags  --tags_path sedi_remote.*               -j SILENCE --silence_holduntil      'monday 08:00'

entables   -A DEFAULT  -m times --times_range  0-24/6-7                 -j SILENCE --silence_holduntil      'monday 08:00'
entables   -A DEFAULT  -m times --times_range  00:00-8:00,18:00-24/1-5  -J SILENCE --silence_holduntil_next '08:00'
entables   -A DEFAULT  -m times --times_range  00:00-8:00,18:00-24/1-5  -J SILENCE --silence_holduntil_next '08:00' --delay_drop_if_up 1

3.8. JSON_HTTP

Questo target permette l’invio dei dati di un allarme codificati in formato JSON tramite protocollo HTTP ad una URL remota:

I parametri questo target vanno specificati secondo la sintassi:

-J JSON_HTTP --json_http_<parametro> <valore> [ --smtp_<parametro> <valore> ... ]

Parametri principali:

Parametro Type Default Descrizione
url stringa   Url della richiesta
method stringa post Metodo HTTP: GET o POST
timeout stringa 5 Request timeout
headers stringa   Stringa con header HTTP addizionali da aggiungere alla richiesta.
rawdata intero 0 Quando vale 1, i dati vengono inviati in formato JSON con Content-type: application/json. I parametri ‘params’ e ‘alarmparm’ vengon ignorati.

Parametri per GET/POST normali:

Parametro Type Default Descrizione
params stringa   Query string parametri da inviare insieme ai dati
alarmparam stringa alarm Nome variabile che conterra i dati dell’allarme codificati in JSON

3.8.1. Esempi

In base a questa regola:

entables -t notify -A DEFAULT                          -j JSON_HTTP                          --json_http_url        http://127.0.0.1:8000/test                          --json_http_method     POST                          --json_http_params     'param1=value1&param2=value2 with space'                          --json_http_alarmparam data

Viene generata una post con i seguenti dati:

param1=value1
param2=valu2 with space
data={....alarm json.....}

3.8.2. Struttura dati JSON

La struttura dati (codificata in formato JSON e’ la seguente):

                                                                                      Presente?     NULL?  Descrizione
{
     "uuid"      : "7eb499dd9fb54f0a87afd351d0c4ce56"                                               NO     identificativo univoco dell'allarme.
     "ts"        : 1511001368,                                                                      NO     timestamp UTC di generazione dell'allarme.
     "element": {                                                                                   
         "uuid"       : "e173f52135b845a5bf1792e33ad508ac"                                          NO     identificativo univoco dell'elemento associato all'allarme.
         "path"       : "dm10lx03:rootfs",                                                          NO     identificativo univoco mnemonico dell'elemento associato all'allarme.
         "name"       : "rootfs",                                                                   NO     nome dell'elemento.
         "description": "Root FS",                                                                  NO     descrizione dell'elemento.
         "type"       : 3,                                                                          NO     tipo dell'elemento (1=nodo,2=interfaccia,3=storage,4=service,5=device).
         "parent_id"  : "a12937d61c874890914182b6d25ebbb8",                                         SI     identificativo dell'elemento padre (l'uuid del nodo).
         "parent_name": "dm10lx03",                                                                 SI     identificativo univoco dell'elemento padre (il nome del nodo).
     },
     "condition": {                                                                      
         "uuid"            : "050db78a671e48358ca266a92e9c9682"                                     NO     identificativo univoco della condition che ha generato l'allarme.
         "path"            : "dm10lx03:rootfs;storage;storage;check-storageperc",                   NO     identificativo mnemonico.
         "name"            : "check-storageperc",                                                   NO     nome della condition.
         "description"     : "Check occupazione filesystem root",                                   SI     descrizione della condition.
         "classification"  : "system.storage.usage",                                                NO     classificazione della condition.
         "priority"        : 60,                                                                    NO     importanza/priorita' associata alla condition.
         "priority_level"  : "medium",                                                              NO     classe di importanza/priorita' associata alla condition.
         "statuslastchange": 1511001368,                                                            NO     timestamp UTC della variazione di stato precedente della condition.
     },
     "datasources": {                                                                 OPZIONALE            serie dati utilizzate per generare l'allarme.
         ...
         "available": {                                                                             NO     nome della serie.
             "id"   : "09298c8603974662bf067f451bca0670",                                           NO     identificativo univoco della serie.
             "value": True                                                                          NO     valore della serie al momento dell'allarme.
         },
         ...
     },
     "result": {                                                                                           risultati del check.
         "status"    : 10,                                                                          NO     stato della verifica della condition.
         "laststatus": 20,                                                                          NO     stato precedente.
     },
     "mail": {                                                                                             Dati della mail generata da Sanet.
         "subject": "Disco pieno"                                                                   NO     Subject 
         "body"   : "......."                                                                       NO     Body 
     },
     "info": {                                                                        OPZIONALE            informazioni dell'elemento.
         "ip4s"       : ['10.0.25.201'],                                                            NO     IP del nodo. Puo' essere [].
     },
     "tags": [                                                                                      NO     classificazioni/tag assegnati alla condizione o all'elemento associati all'allarme. Puo' essere [].
         "dmh:/DMH/Sistemi Critici/3.Labs"
     ],
     "cluster": {                                                                     OPZIONALE     NO     opt. cluster al quale l'elemento e' associato.
         "name"       : ['VMWare-Produzione'],                                                      NO
     },
     "meta": {                                                                                             opt. informazioni addizionali dell'elemento.
         ...
         "referenti" : [                                                              OPZIONALE            referenti associati all'elemento. Puo' essere [].
            'Sergio Rizzi <sergio.rizzi@labs.it>',                         
            'Tiziano Fogli <tiziano.fogli@labs.it>'
         ]
         ...
     },
}

3.9. UPDATECOUNTERS

Memorizza informazioni sull’allarme che viene processato dalla regola (e della regola associata all’allarme).

Queste informazioni possono essere utilizzate dal match COUNTERS.

Utilizzo:

-J UPDATECOUNTERS

Warning

le informazioni vengono associate alla condition dell’allarme, identificata dal PATH. Questo significa che se condition viene rinominata, le informazioni gia’ memorizzate vengon perse.

3.9.1. Informazioni/contatori aggiornati

Queste sono le informazioni aggiornate dal target:

  • stato dell’ultimo allarme intercettato

3.9.2. Esempi

Esempio regola che aggiorna i contatori e poi verifica se lo stato dell’ultimo allarme “passato’ e’ UP

...
...
... regole di JUMP o DROP o ecc. ...
...
entables -t notify -A DEFAULT                                        -J UPDATECOUNTERS 
...
...
... regole di JUMP o DROP o ecc. ...
...
...
entabels -t notify -A DEFAULT    -m counters --counters_status UP    -j SMTP