Metrica o proprietà: il dato cambia da solo o cambia perché qualcuno tocca la configurazione?

VCF Operations raccoglie, per ogni oggetto del suo inventario, due famiglie di dati che l’esame ama scambiare. Una metrica è un valore osservato e ripetuto nel tempo: la documentazione parla di metric observation or value, e le metric definition spiegano come quel valore è calcolato o derivato. Le metriche arrivano da tre strade: l’adapter vCenter, che raccoglie quelle grezze; l’adapter VCF Operations, che raccoglie quelle di self-monitoring; e i calcoli interni della piattaforma, che producono le metriche di capacità, di badge e di salute. Il catalogo è per fonte: Metrics for vCenter Components, for vSAN, in NSX Adapter, Calculated Metrics, Green Score Metrics.

Una proprietà è invece un attributo dell’oggetto: Properties are attributes of objects in the VCF Operations environment. Anche le proprietà arrivano dagli adapter, ma descrivono com’è fatto l’oggetto, non come si sta comportando. L’esempio della doc è lo spazio disco come proprietà hardware di una VM, con cui definire un sintomo che avvisa quando il valore scende sotto una soglia numerica. Alcune proprietà le genera la piattaforma, come Object Type Classification, che assume valori tipo ADAPTER_INSTANCE, GROUP, TIER. Il criterio è semplice: se il dato si muove perché si muove il carico è una metrica, se si muove solo quando qualcuno cambia una configurazione — vCPU, scadenza di un certificato — è una proprietà.

La policy decide che cosa viene raccolto davvero

Nel workspace delle policy di monitoraggio la sezione Metrics and Properties è dove scegli quali attributi metrica, proprietà o super metric includere, e VCF Operations raccoglie dagli oggetti sulla base di quel che hai incluso; le altre sezioni sono Alerts and Symptoms, Capacity, Compliance, Workload Automation e Groups and Objects. Una View costruita su un attributo escluso dalla policy resterà vuota, e non c’è niente da riparare nella View.

Le super metric vivono nello stesso posto: sono formule matematiche che contengono una o più metriche o proprietà — la media della CPU di tutte le VM di un cluster, per dire — e vengono raccolte per un gruppo di oggetti solo quando l’attributo super metric è attivato in una policy. Le dynamic threshold, il confine fra comportamento normale e anomalo calcolato su dati storici e in arrivo, si applicano alle metriche e si governano da Administration > Global Settings > Dynamic Thresholds. Nei sintomi la categoria si chiama Metric/Property e sta accanto a Message Events, Faults e Logs (Infrastructure Operations → Configurations, riquadro Symptom Definitions).

Le View: sei tipi, un solo subject

Una View presenta le informazioni raccolte per un oggetto in un modo che dipende dal tipo scelto, e serve a leggere metriche, proprietà, policy, alert e sintomi da prospettive diverse. I tipi sono sei: List (dati tabellari su oggetti specifici), Summary (dati tabellari sull’uso delle risorse), Trend (usa i dati storici per generare trend e forecast), Distribution (dati aggregati sulla distribuzione delle risorse), Text e Image, che inseriscono testo o un’immagine statica. Il subject è il tipo di oggetto base per cui la View mostra le informazioni: sbagliare subject è il modo più rapido di ottenere una tabella vuota.

Le View predefinite stanno in Infrastructure Operations → Dashboards & Reports → Views, scheda Overview, per categoria (Availability, Capacity, Configuration, Inventory, Performance, Compliance). Per farne una: Views → Create, scegli il tipo nel pannello di destra, completa in sequenza le schede e chiudi con Create. La View si porta poi in una dashboard con il View widget.

Dai View ai Report

Un report è, testualmente, a scheduled snapshot of views and dashboards: non si schedula una View, si schedula il template che la contiene. Da Infrastructure Operations → Dashboards & Reports → Reports → Create il wizard ha tre schede. In Name and Description dai nome e descrizione al template. In Report Content trascini gli elementi dall’elenco di destra — Views o Dashboards — dentro il riquadro Report Template Structure; i tre puntini su ogni elemento scelgono Portrait o Landscape e attivano la Colorization, che vale solo per le list view. In Layout and Format decidi Cover Page (immagine fino a 5 MB, rapporto predefinito 8,5 x 11 pollici), Table of contents e Footer, e i formati di output: PDF, pagina per pagina, e CSV, dati in tabella.

Per pubblicarlo, nella scheda Report Template selezioni il template, dai tre puntini scegli Schedule, selezioni l’oggetto, poi Time zone, Date, Hour e Minutes e la Recurrence fra Daily, Weekly e Monthly. La casella Email report apre gli indirizzi con CC e BCC e la scelta della Outbound rule. I file finiti si prendono dalla scheda Generated Reports, colonna Download, icone PDF e CSV.

Trappole tipiche d’esame

  • Metrica contro proprietà. Trend, forecast e dynamic threshold vivono sulle metriche; la proprietà è un attributo di configurazione, e si usa in sintomi, dashboard, View e report. Che il tipo di sintomo si chiami Metric/Property non rende i due dati intercambiabili.
  • «La super metric non raccoglie nulla». Non è un difetto della formula: finché l’attributo super metric non è attivato in una policy, per quel gruppo di oggetti non arriva niente. Stessa storia per metriche e proprietà escluse da Metrics and Properties.
  • View, dashboard e report non sono sinonimi. Il report è lo snapshot schedulato di View e dashboard; PDF e CSV sono formati del report, e la Colorization tocca solo le list view.
  • Chi è il proprietario. View e template predefiniti appartengono a System; l’ultimo utente che ha modificato View, template o schedule ne diventa proprietario, chi importa un contenuto ne diventa proprietario anche se l’ha scritto un altro, e un report generato da una schedule appartiene a chi ha creato la schedule.
  • Nomi 9.0. È VCF Operations, non vRealize né Aria; VCF Operations for Logs e for Networks sono superfici distinte, e le metriche di for Networks (entity, flow, health, latency) sono un capitolo a sé.