Su una piattaforma vSphere Foundation l’osservabilità non arriva dal vSphere Client: arriva da VCF Operations, che in VVF è incluso insieme a VCF Operations for Logs. Chi amministra davvero questa piattaforma passa metà del tempo a decidere quale dei tre tipi di dato gli serve — una metrica, una proprietà o un log — perché la scelta determina dove si va a cercare, che tipo di sintomo si può costruire e in quale oggetto di reporting quel dato può finire. L’esame gioca quasi sempre su questa scelta.

Metriche, proprietà e log: tre nature diverse

Una metrica è un valore numerico che cambia nel tempo e che viene raccolto a ogni ciclo di collection dagli adapter: l’adapter vCenter raccoglie le metriche grezze dai componenti vCenter, l’adapter di VCF Operations raccoglie le metriche di self-monitoring del prodotto stesso. Ogni singolo punto raccolto è una metric observation. Accanto alle metriche grezze esistono le metriche calcolate, derivate dal prodotto per capacità, badge e salute: non arrivano dall’adapter, le costruisce VCF Operations. La documentazione di riferimento si chiama proprio metric definition perché spiega «come il valore della metrica è calcolato o derivato»: quando un numero non torna, si legge la definizione prima di aprire un caso.

Una proprietà è invece un attributo dell’oggetto: qualcosa che descrive com’è configurato, non quanto sta lavorando. Lo spazio disco configurato su una VM, il sistema operativo, il tipo di oggetto (ADAPTER_INSTANCE, GROUP, BUSINESS_SERVICE, TIER, GENERAL), i servizi Windows o i processi Linux scoperti dalla service discovery sono proprietà. Cambiano di rado e cambiano per configurazione, non per carico. Le proprietà si usano nelle symptom definition — «avvisami se questo attributo cambia» — e naturalmente in dashboard, view e report.

Un log è un evento testuale, non una serie temporale. Ogni log event porta un timestamp, una source (l’originatore dei messaggi syslog, per esempio un host ESX, oppure un forwarder che aggrega syslog), il text grezzo e dei field, cioè coppie nome-valore. I campi statici arrivano al server solo quando un agente usa il protocollo CFAPI; i campi estratti vengono ricavati dinamicamente dai messaggi in base a query personalizzate. I log vivono in VCF Operations for Logs e si consultano dalla pagina Analyze, scheda Analyse Logs, una volta integrato il prodotto.

Il triplice taglio ricompare identico nelle symptom definition, che sono di tipo Metric/Property, Message Event, Fault e Log: se il dato che ti serve è un log, nessuna symptom su metrica lo intercetterà mai.

Su VVF c’è un dettaglio operativo che su VCF non esiste: l’appliance dei log si deploya a mano. Si scarica l’OVA e si usa il wizard Deploy OVF Template del vSphere Client, si completa la configurazione iniziale dalla web interface dell’appliance e poi, in VCF Operations, si va in Administration > Control Panel a inserire indirizzo, utente e password dell’appliance. La taglia small è il minimo per la produzione (l’extra small serve solo per demo) e ridurre i dischi dell’appliance non è supportato.

View: l’unità di composizione

Una view è il modo in cui interpreti metriche, proprietà, policy, alert e sintomi da una prospettiva scelta da te. Si creano da Infrastructure Operations > Views, scheda Manage, con Add. La prima scelta del wizard è il tipo, e i tipi sono sei: List, Summary, Trend, Distribution, Text e Image. Le schede successive si percorrono avanti e indietro fino a Create: si nominano, si sceglie il soggetto (i tipi di oggetto a cui la view si applica), si scelgono i dati e si definisce come vanno trattati. Sul dato si configurano la transformation, che decide come i valori sono aggregati, il trend, che mostra come tendono a cambiare in base allo storico grezzo, e il forecast, che proietta i valori futuri sulla base del calcolo di trend.

Una view si condivide dalla scheda Manage con l’icona Share View: puoi copiarne l’URL per consumarla da strumenti esterni come Power BI — serve però un token CSP generato dai VMware Cloud Services e la view va consultata come utente autorizzato — oppure esportarne la configurazione dalla scheda Export.

Report: lo snapshot pianificato

Un report è, letteralmente, uno snapshot pianificato di view e dashboard. Non raccoglie dati per conto proprio: raccoglie oggetti già costruiti. Si crea da Infrastructure Operations > Dashboards & Reports > Reports > Create. Nella scheda Name and Description si dà il nome che comparirà in Report Templates; nella scheda dei contenuti si trascinano le view e le dashboard dal pannello di destra dentro la Report Template Structure a sinistra, scegliendo per ciascun elemento l’orientamento verticale o orizzontale dal menu a tre puntini — e solo per le list view si può attivare il PDF colorato. Nella scheda di layout e formato si aggiungono copertina (immagine fino a 5 MB), indice e piè di pagina con data di creazione e numeri di pagina, e si scelgono i formati: PDF per la lettura anche offline, CSV per i dati in tabella strutturata.

La pianificazione si fa dalla scheda Report Template, menu a tre puntini, Schedule: si sceglie l’oggetto, poi fuso orario, data, ora e minuti (solo 0, 15, 30 o 45), poi la ricorrenza giornaliera, settimanale o mensile con la periodicità. Per l’invio via e-mail servono destinatari, CC/BCC e una outbound rule già configurata nelle impostazioni di outbound. Attenzione: solo gli utenti creati dentro VCF Operations possono aggiungere e modificare le schedulazioni dei report.

Dashboard: costruzione e condivisione

Le dashboard si creano da Infrastructure Operations > Dashboards & Reports > Dashboards > Create: si dà il nome, si aggiungono widget o view, si configurano le widget interaction perché l’informazione mostrata da un elemento dipenda da un altro, si impostano le navigation per saltare ad altre dashboard durante un’indagine, e si salva. Dopo il salvataggio si modifica da Actions > Edit Dashboard. Le dashboard sono predefinite o custom; le predefinite coprono già molto (per esempio le dashboard vSAN di performance e utilizzo).

La condivisione passa dall’icona Share Dashboard: si assegna e si disassegna la dashboard a gruppi di utenti, oppure se ne esportano i dettagli di configurazione. La condivisione delle dashboard si applica solo ai gruppi con licenza Standard Edition.

Un widget merita una nota: il Log Analysis mostra i log dentro la dashboard, ma solo dopo l’integrazione con VCF Operations for Logs, e ha l’interruttore Self Provider per decidere se definisce da sé gli oggetti o li riceve da un altro widget. La documentazione sconsiglia esplicitamente di usarlo per il reporting, perché richiede input dell’utente per produrre risultati.

Trappole tipiche d’esame

  • Metrica o proprietà? «Lo spazio disco configurato di una VM» è una proprietà, «l’utilizzo del disco nel tempo» è una metrica. Se lo scenario parla di cambio di configurazione la risposta è property; se parla di andamento, di soglia o di forecast è metrica. Il forecast esiste sui dati metrici, non sugli attributi.
  • Il report non è una sorgente. Un report è uno snapshot pianificato di view e dashboard: se il dato non è prima in una view o in una dashboard, nel report non ci finisce. La domanda «come metto questa metrica in un report» ha come primo passo «creo la view».
  • Condividere una view e condividere una dashboard sono due meccanismi diversi. La dashboard si assegna a gruppi di utenti (con il vincolo della licenza Standard Edition); la view si condivide via URL con token CSP o si esporta. Non esiste «assegna la view al gruppo».
  • Il PDF colorato è solo per le list view, e i formati disponibili sono PDF e CSV: nessun XLSX, nessun HTML.
  • I log non ci sono finché non deployi l’appliance. Su VVF, VCF Operations for Logs si installa a mano da OVA e si registra in Administration > Control Panel. Prima di quel passaggio la pagina Analyse Logs e il widget Log Analysis non mostrano nulla, e nessuna domanda su «perché non vedo i log» si risolve toccando le metriche. Ricorda anche che VVF non ha NSX: le sorgenti di log NSX che la documentazione elenca fra quelle configurabili non fanno parte del tuo perimetro.