Consultare e configurare sono due posti diversi
VCF Operations separa la superficie di consultazione da quella di configurazione, e l’esame ci gioca sopra. I dashboard stanno in Infrastructure Operations > Dashboards & Reports > Manage, gli alert generati in Infrastructure Operations > Alerts o nella scheda Alerts del singolo oggetto. Ciò che invece definisce il comportamento — alert definition, symptom definition, notification, outbound settings, policy — vive sotto Infrastructure Operations > Configurations, una griglia di tile.
Costruire un dashboard che serva a qualcosa
Un dashboard è un contenitore di widget, «the panes on your dashboards», che mostrano attributi, risorse, applicazioni o processi. Con Create parti da zero oppure cloni un predefinito: la libreria è già categorizzata per Capacity, Performance, Availability, Configuration, Cost, vSphere, NSX, Private AI (GPU). Il pannello Dashboard Time è attivo di default con 1 hour, 6 hours, 24 hours e 7 days oltre agli intervalli personalizzati, e la scelta sopravvive al logout e all’export/import fra istanze.
Il valore vero sta nelle widget interactions: molti widget forniscono o accettano dati da altri, così la selezione fatta in uno filtra gli altri e il dashboard diventa un percorso di troubleshooting invece di una parete di grafici. Il widget View merita attenzione a parte: una view presenta metriche, proprietà, alert e symptom con trasformazioni, trend e forecast, si costruisce una volta in Views > Manage e si riusa anche nei report. E ricorda che alcuni widget non mostrano dati finché non li configuri.
Condividere: gruppi, home, report
I dashboard folder raggruppano i dashboard, mentre il pannello di sinistra offre Favorites, Recents (gli ultimi dieci consultati) e All. Dal menu Actions condividi un dashboard o un dashboard template con uno o più user groups: da quel momento accanto al nome compare l’icona shared. Sono altra cosa Set as Dashboards Home, che lo mette fra i preferiti dell’utente corrente, e Add to Product Home, che lo pubblica come tab della home del prodotto con un tetto di cinque dashboard. Contano poi i privilegi — ContentAdmin gestisce views, reports, dashboards e custom groups, ReadOnly consuma e basta — e per chi in console non entra mai c’è il report, snapshot pianificato di view e dashboard in PDF o CSV.
La catena dell’alerting
L’alerting non è un interruttore, è una catena: symptom definition → symptom set → alert definition → policy → notification rule → outbound instance. Rompi un anello e non arriva niente.
Le symptom definition (Configurations > Symptom Definitions) si dividono in symptom su metric e property, su message events, su faults e nei logs symptoms: il dato raccolto viene confrontato con la condizione e, se è vera, il symptom scatta. La regola d’igiene è coprire le severità con più symptom sullo stesso fenomeno — «volume nearing capacity limit» a Warning, «volume reached capacity limit» a Critical — senza sovrapposizioni, che moltiplicano gli alert per un solo problema, e senza buchi fra gli intervalli.
L’alert definition (Configurations > Alert Definitions > Add) si àncora a un Base Object Type, dichiara Criticality (Symptom, Critical, Immediate, Warning, Info), Impact sul badge Health, Risk o Efficiency e i metadati Alert Type e Alert Subtype, poi combina i symptom set con logica All o Any. Le Recommendations sono la parte che si salta e che l’esame premia: istruzioni, link o azioni eseguibili sui sistemi target, offerte con Run Action nella scheda Alert Details. L’ultimo passo chiede in quale policy inserire la definizione. Novità della 9.0 è la log-based alert definition: da Add trascini Add Log Condition e scegli il filtro dal menu Filter By.
Rumore, policy, notifiche
La sensibilità si governa a livello di symptom, tenendo wait cycle e cancel cycle dell’alert definition a 1: l’alert nasce appena il symptom scatta e si annulla appena la condizione sparisce. Contro l’alert flooding definisci l’alert sull’oggetto gerarchicamente superiore anziché su ogni figlio, e non affollarlo di symptom secondari; al resto pensano gli Intelligent Alerts, che raggruppano con DBScan gli alert correlati.
Le policy (Configurations > Policy Definition) sono l’interruttore vero: nella scheda Alerts and Symptoms attivi o disattivi le singole definition, in Groups and Objects scegli su quali oggetti valgono, con Inherit From erediti da una policy base. Poi l’uscita: in Notifications la regola porta Rule Name, Outbound Method, Instance, Payload Template e i criteri di filtro, ma l’istanza va creata prima in Outbound Settings, con un plug-in fra Standard Email, REST Notification, SNMP Trap, Webhook Notification, Slack e Service-Now.
Trappole tipiche d’esame
- Criticality non è Impact. La prima è la severità dell’alert generato, il secondo decide quale badge fra Health, Risk ed Efficiency viene influenzato; e se cambi l’impact, gli alert già generati restano al livello precedente, solo i nuovi prendono quello nuovo.
- Definire non è attivare. Alert definition, symptom e super metric non producono nulla finché non sono attivi nella policy che governa quegli oggetti: lo scenario «l’ho creato e non scatta» punta lì, non alla soglia.
- Una notifica senza istanza non parte. Prima Outbound Settings, poi Notifications. E il VMware Hosted Email plug-in, attivo di default, non supporta le notification rules: quello che manda non lo filtri.
- Le soglie di VCF Operations non sono quelle di VCF Operations for Networks. Qui symptom e Dynamic Thresholds (Administration > Global Settings); là Analytics > Thresholds > Add, con «exceeds threshold», «drops below», «is outside range» o «deviates from the past behavior» e la Minimum Violation Duration. Il blueprint lo chiama «VCF Network Operations», la documentazione di prodotto for Networks.
- Condividere non è mettere in home. Per rendere un dashboard visibile a un team serve lo share agli user groups, non Add to Product Home né Set as Dashboards Home.