7.3. Target disponibili¶
Contenuti
7.3.1. Target di sistema¶
7.3.1.1. CONTINUE¶
Non esegue nessuna operazione.
-J CONTINUE
7.3.1.1.1. Esempi¶
entables -A DEFAULT -m ...... -J CONTINUE
7.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
7.3.1.2.1. Esempi¶
entables -A CATENA_H24 -m ...... -J RETURN
7.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
7.3.1.3.1. Esempi¶
entables -A DEFAULT -m ...... -J ENDTABLE
7.3.1.4. DROP¶
Ferma definitvamente un allarme.
-J DROP
7.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
7.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
7.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
7.3.2. SETATTR¶
Aggiunge/sovrascrive informazioni (chiavi o campi) contenute nella struttura dati (dizionario) di una allarme.
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. Puo' contenere una sequenza di campi separati da ".". Vedi Specificare sotto-campi.
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)
jsonvalue
stringa
Salva nel messaggio un nuovo campo field_name con il valore indicato dal JSON passato in input.
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 '*'
Warning
Se il valore da salvare nell'allarme non puo' essere calcolato (es: treetags specifica un tree che non esiste oppure tagmeta specifica un nome di meta-data non esistente), il target SETATTR non aggiunge / modifica nessun nuovo attributo all'allarme.
7.3.2.1. Specificare sotto-campi¶
E' possibile modificare qualuque campo o sotto-campo nella struttura dati dell'allarme (un dizionario).
Esempio1: Per aggiungere/modificare un campo
entables -A DEFAULT -j SETATTR --setattr_field_name my_field --setattr_value "fake value"
l'effetto e' che nel messaggio viene aggiunto:
{ ... "my_field": "fake value" ... }
Esempio2: Per aggiungere/modificare un sotto-campo bisogna specificare la sequenza di campi separati da ".":
entables -A DEFAULT -j SETATTR --setattr_field_name k1.k2 --setattr_value value1
l'effetto e' che nel messaggio viene aggiunto:
{ ... "k1": { ... "k2": "value1" ... } ... }
Esempio3:
entables -A DEFAULT -j SETATTR --setattr_field_name mail.headers.X-header1 --setattr_value "header12345"
l'effetto e':
{ ... "mail": { ... "headers": { ... "X-header1": "header12345" ... } } ... }
Warning
se viene specificata una sequenza di campi "x.y.z", e i campi "x" e "x.y" non esistono, questi vengono creati e aggiunti al volo.
Warning
se viene specificata una sequenza di campi "x.y.z", i campi "x" e "x.y" vengono trattati/convertiti a dizionari. Questa conversione puo' cancellare il valore precedente se il valore precedente non era un dizionario.
7.3.2.2. 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:
# Salviamo nella chiave "indirizzi" il valore entables -t notify -A DEFAULT -j SETATTR --setattr_field_name 'indirizzi' --setattr_tagmeta 'referenti' ^ | `--------------------------------' # Usiamo {{alarmpath.*}} per estrarre dalla chiave "indirizzi" il valore e usarlo come destinatario entables -t notify -A DEFAULT -j SMTP --smtp_subject '{{mail.subject}}' --smtp_message '{{mail.body}}' --smtp_rcpt_to '{{mail.to}},{{alarmpath.indirizzi}}' ^^^^^^^^^^^^^^^^^^^^^^^
Warning
quando si compongono valori usando tag diversi bisogna essere sicuri che il risultato finale sia semanticamente corretto. In questo caso se {{alarmpath.indirizzi}} contiene indirizzi email non validi si rischia l'elenco dei destinatari della mail non venga interpretato correttamente durante l'invio della mail.
Esempio 4: Sovrascrivere il destinatario {{mail.to}} configurato nell'allarme.
entables -t notify -A DEFAULT -j SETATTR --setattr_field_name 'mail.to' --setattr_value 'foo@bar.com'
Esempio 5: Aggiunta di dati strutturati da una stringa JSON
# Caricamento di un *dizionario* da stringa JSON e salvataggio nella chiave 'key1' entables -t notify -A DEFAULT -j SETATTR --setattr_field_name 'key1' --setattr_jsonvalue '{ "foo": "bar", "value": 123, "msg": "Hello world!" }' # Estrazione di una sottochiave "msg" dalla struttura caricata entables -t notify -A DEFAULT -j SMTP --smtp_subject '{{mail.subject}} {{alarmpath.key1.msg}}' ...
7.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
Return-path SMTP del messaggio.
header_from
Indirizzo che comaparira nel campo "From:"
rcpt_to
Destinatario/i del messaggio (separati da virgole)
rcpt_cc
Destinatario/i in CC (separati da virgole)
rcpt_bcc
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 )
7.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 (',').
7.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.
7.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'
7.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 [1] 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
[1] se l'allarme in sospeso era di UP (al momento della sospensione), il parametro "drop_if_up" viene ignorato
Obsoleti:
Parametro
Type | Default
Descrizione
seconds
DEPRECATO: vedi "holdfor"
until
DEPRECATO: vedi "holduntil"
until_next
DEPRECATO: vedi "holduntil_next"
7.3.4.1. Formato e semantica dei paremetri holdfor/holduntil/holduntil_next¶
7.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.
7.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
7.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
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.
7.3.4.1.2. Formati validi per parametro holduntil_next¶
hh:ss Es: 8:00
7.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
7.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".
7.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.
7.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:
i match disponibili del match attr (vedi documentazione Campi/shortcut per i messaggi digest )
i tag del tagprovider digest (vedi documentazione Digest)
7.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.
7.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
7.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.
7.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.
7.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 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.
7.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
7.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}'
7.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}'
7.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 ).
Warning
per gestire allarmi intercettate da regole diverse vedi Logica gestione allarmi intercettati e context.
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.
7.3.7.1. Parametri speciali¶
La logica di filtro del target puo' essere alterata attraverso due parametri:
Parametro
Type
Default
Descrizione
context
stringa
Identificativo logico dell'insieme di tutti gli allarmi "intercettati". Vedi Logica gestione allarmi intercettati e context
drop_last_up
numero
0
Quando vale 1, gli allarmi bloccati 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 bloccato/ritardato) il primo UP.
drop_if_up
numero
0
Quando vale 1, l'allarme di DOWN bloccato 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 bloccato non riparte se la condition associata all'allarme ha subito una qualunque variazione di stato
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.
Attention
sare questo parametro in tutte le regole con il "contesto" giusto ( Vedi Logica gestione allarmi intercettati e context ).
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.
Attention
usare questo parametro in tutte le regole con il "contesto" giusto ( Vedi Logica gestione allarmi intercettati e context ).
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.
7.3.7.2. Logica gestione allarmi intercettati e context¶
Quando una regola con target SILENCE "intercetta" degli allarmi e li ritarda fino ad un certo orario, questi vengono "raggruppati" in un gruppo "logico". Le logiche del SILENCE descritte nei paragrafi precedenti si applicano considerando "gruppo" di allarmi intercettati.
Warning
se due regole diverse (anche consecutive) "intercettano" allarmi e li ritardano fino alla stessa ora, gli allarmi intercettati dalla prima regola verranno elaborati diversamente dagli allarmi intercettati dalla seconda.
Per poter gestire con SILENCE allarmi ritardati alla stessa ora, ma da regole diverse (applicando quindi a tutti la stessa logica), bisogna specificare per tutte le regole lo stesso "context".
Il "context" indica il "nome logico" del gruppo di allarmi ritardati fino alla stessa ora.
Il parametro "context" puo' essere una qualunque sequenza di caratteri.
Se non specificato, ogni regola con SILENCE gestisce gli allarmi intercettati in gruppi separati.
Esempio1: due regole di SILENCE gestiscono allarmi filtrati diversamente fino alla stessa ora (7:01) raggruppandoli pero' nello stesso gruppo logico (chiamato "morning")
entables -A DEFAULT ...filtro A... -j SILENCE --silence_holduntil_next 7:01 --silence_drop_last_up 1 --silence_notify_first_up 1 --silence_context "alla_mattina" entables -A DEFAULT ...filtro B... -j SILENCE --silence_holduntil_next 7:01 --silence_drop_last_up 1 --silence_notify_first_up 1 --silence_context "alla_mattina"
Esempio2: Le due regole gestiscono allarmi prodotti in orarii/giorni extralavorativi, ritardandoli tutti alle 7:01 del mattino del giorno lavorativo successivo. Per essere sicuri di gestire tutti gli allarmi correttamente specifichiamo che il contesto e' lo stesso per entrambe le regole.
entables -A DEFAULT -m times --times_range '00:00-7:00/1-6|18:30-24:00/1-5' -j SILENCE --silence_holduntil_next 7:01 --silence_drop_last_up 1 --silence_notify_first_up 1 --silence_context "next_working_day" entables -A DEFAULT -m times --times_range '13:30-24:00/6|00:00-24:00/7' -j SILENCE --silence_holduntil 'monday 7:01' --silence_drop_last_up 1 --silence_notify_first_up 1 --silence_context "next_working_day"
7.3.7.3. 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
7.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
7.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¶m2=value2 with space' --json_http_alarmparam data
Viene generata una post con i seguenti dati:
param1=value1 param2=valu2 with space data={....alarm json.....}
7.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>' ] ... }, }
7.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.
7.3.9.1. Informazioni/contatori aggiornati¶
Queste sono le informazioni aggiornate dal target:
stato dell'ultimo allarme intercettato
7.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
7.3.10. SYSLOG¶
Questo target permette loggare su syslog.
I parametri questo target vanno specificati secondo la sintassi:
-J SYSLOG --syslog_<parametro> <valore>
Parametri:
Parametro
Type
Default
Descrizione
msg
stringa
${rawalarm}
Testo del messaggio syslog
7.3.10.1. Esempi¶
Produce un messaggio:
entables -A DEFAULT -j SYSLOG --syslog_msg "[entables] Processed alarm ${alarmid}"