Su VMware vSphere Foundation l’osservabilità vive in due appliance che si comportano come un prodotto solo: VCF Operations raccoglie metriche, proprietà ed eventi e ospita alert, policy e dashboard; VCF Operations for Logs raccoglie e indicizza i log. La differenza che l’esame ama è come arrivano. Con licenza VMware Cloud Foundation l’appliance dei log si distribuisce dal fleet management; con licenza vSphere Foundation si scarica l’OVA e la si distribuisce a mano, poi si configurano le sorgenti di log e il Single Sign-On verso l’identity provider esterno. Da quel momento i log si leggono dentro la console di VCF Operations, in Infrastructure Operations, senza cambiare interfaccia. E niente di tutto questo passa da NSX o da VCF Automation: su VVF non ci sono.
Sintomi, alert, policy: l’anatomia che l’esame interroga
Un alert in VCF Operations non nasce da una soglia scritta a caso dentro una regola: nasce da un sintomo. In Infrastructure Operations > Configurations > Symptom Definitions i sintomi si definiscono in quattro famiglie — Metric/Property, Message Events, Faults e Logs — e la documentazione suggerisce di scriverne una serie che descriva livelli crescenti di preoccupazione: «Volume nearing capacity limit» in Warning, «Volume reached capacity limit» in Critical. La soglia può essere statica oppure dinamica: le dynamic threshold si calcolano sui dati storici e su quelli in arrivo, si ricalcolano a intervalli pianificati e si governano in Administration > Global Settings > Dynamic Thresholds.
L’alert definition (Configurations > Alert Definitions, pulsante Add) è il contenitore che combina sintomi e raccomandazioni. Compili Name e Description, scegli il Base Object Type attraverso l’adapter (per esempio vCenter Adapter > Host System), poi nelle impostazioni avanzate imposti Impact (Health, Risk o Efficiency), Criticality (Symptom, Critical, Immediate, Warning, Info), Alert Type and Subtype e i cicli Wait Cycle e Cancel Cycle, cioè quanti cicli di raccolta servono perché l’alert scatti e quanti perché si chiuda. Nel passo Symptoms/Conditions scegli su cosa è definito il sintomo (Self, o un oggetto correlato), filtri la libreria e trascini i sintomi nel riquadro di sinistra; il selettore Base object exhibits criteria decide se servono All i sintomi del set o Any di essi. Le Recommendations si trascinano allo stesso modo e portano con sé una priorità: sono le istruzioni, i link o le azioni che l’operatore vedrà accanto all’alert. L’ultimo passo assegna l’alert a una policy: un alert non abilitato in policy esiste ma non lavora.
Dall’alert alla notifica: due oggetti diversi
Generare un alert e notificarlo sono cose distinte. La consegna verso l’esterno si configura in due tile: Outbound Settings, dove crei le istanze dei plug-in — REST Notification, Standard Email, SNMP Trap, Webhook Notification, Slack, Service-Now e VMware Hosted Email, quest’ultimo attivo per impostazione predefinita — e Notifications, dove scrivi le regole che filtrano quali alert escono verso quale istanza. Un’istanza deve essere attiva perché una regola possa usarla, e disattivarla ferma l’invio senza cancellare la configurazione. È la catena che va ricostruita davanti a uno scenario del tipo «l’alert si vede in console ma nessuno riceve la mail».
I log: com’è fatto un evento e come diventa un alert
Un log event ha quattro elementi: Timestamp, Source (chi ha originato il messaggio, un host ESX o un forwarder), Text (il testo grezzo) e Fields, coppie nome-valore estratte dall’evento. I campi arrivano come statici solo quando l’agente usa il protocollo CFAPI; altrimenti si estraggono dinamicamente dal testo con query personalizzate, che è il modo di dare struttura a eventi non strutturati. L’ingestione avviene per integrazione vSphere (eventi, task e allarmi da vCenter e dagli host ESX), per agenti (filelog, eventi Windows, journald), per syslog e per CFAPI; l’agente è preinstallato nei componenti supportati e prende la propria configurazione dagli Agent Groups, mentre la raccolta fra datacenter passa dall’Unified Cloud Proxy. Selezionando un oggetto dall’Inventory compare la scheda Logs, che correla i messaggi con le metriche dello stesso oggetto.
La novità di VCF 9.0 sono gli alert basati sui log: nella stessa procedura di creazione dell’alert definition, al passo Symptoms/Conditions trascini Add Log Condition, scegli con il menu Filter By il sintomo di log già definito e imposti il periodo di osservazione (l’esempio della documentazione usa sei ore su un Host System per i vMotion falliti).
Explore Logs: query, campi, grafico
La pagina Analyze è dove si indaga. Una query può essere una message query (parole chiave, espressioni regolari e operazioni sui campi), una query di espressioni regolari e parole chiave, oppure una aggregation query fatta di una funzione, uno o più raggruppamenti e un certo numero di campi. I filtri sui campi si compongono in tre pezzi: campo, operatore, valore. Gli operatori sono is, is not, contains, Starts With ed exists; i campi numerici aggiungono =, >, <, >=, <=. Più valori nella stessa casella sono in OR implicito, mentre fra righe di filtro scegli All (AND) o Any (OR).
Il grafico di Explore Logs trasforma il risultato in analisi visiva. L’aggregazione predefinita è COUNT OF EVENTS, e le altre sono Unique count, Min, Maximum, Average, Std dev, Sum e Variance (tutte su campi numerici, tranne le prime due). I tipi di grafico sono Column, Line, Area, Bar, Pie, Bubble, Scalar e Table, e non sono intercambiabili: Column, Line e Area vogliono la serie temporale; Bar richiede almeno un group-by; Pie accetta solo Count o Unique Count; Bubble pretende due campi di raggruppamento. Le query si salvano, si rinominano, si caricano e si condividono con altri utenti, e finiscono nella card Saved Queries delle Configurations, insieme ai campi salvati nella Fields Library.
Dashboard e condivisione
Le dashboard si creano da Infrastructure Operations > Dashboards & Reports > Dashboards > Create: dai un nome, aggiungi widget e view, configuri le interactions perché un widget alimenti l’altro, imposti la navigazione verso altre dashboard e salvi; poi si modifica da Actions > Edit Dashboard. Per i log esiste il widget Log Analysis, che pesca dalle query di chart e di messaggio salvate, accetta filtri e aggregazioni aggiuntive e ha il consueto interruttore Self Provider per decidere se sceglie da sé gli oggetti o li riceve da un altro widget; la documentazione avverte esplicitamente di non usarlo per i report, perché richiede input interattivi. La condivisione si fa selezionando la dashboard e usando l’icona Share Dashboard: si assegna e si revoca ai gruppi di utenti, e la funzione si applica solo a gruppi con licenza Standard Edition. Esportare la configurazione della dashboard è un’altra strada, e non è la stessa cosa.
Trappole tipiche d’esame
- Deploy dei log su VVF. Se lo scenario dice «licenza vSphere Foundation», l’appliance VCF Operations for Logs si distribuisce scaricando l’OVA; il percorso dal fleet management è quello VCF. Chi risponde «fleet management» per riflesso sbaglia proprio la domanda pensata per VVF.
- Sintomo ≠ alert ≠ notifica. Tre oggetti in tre tile diverse. Un alert visibile in console e non recapitato significa regola di notifica assente o istanza di plug-in non attiva in Outbound Settings, non un sintomo mal definito.
containslavora su token interi. Cercareerrnon trovaerror: serveStarts Witho un glob. È l’errore che l’esame mette in bocca a un troubleshooting «la query non restituisce nulla».- I tipi di grafico hanno prerequisiti. Pie solo con Count o Unique Count, Bar almeno un group-by, Bubble due, Column/Line/Area sulla serie temporale. «Perché non posso usare un grafico a torta con la media?» è una domanda plausibilissima.
- Condividere non è esportare. La condivisione assegna la dashboard a gruppi di utenti (con licenza Standard Edition); l’export produce un file di configurazione. E il widget Log Analysis non è materiale da report.
- Il perimetro VVF. Uno scenario che chiede di far confluire i log di edge NSX o di flussi di VCF Automation è fuori piattaforma: su vSphere Foundation quei componenti non esistono.