In VCF 9.0 il monitoraggio non è più una collezione di prodotti separati da collegare a mano: è un insieme di pagine dentro VCF Operations, alimentate da componenti dedicati — VCF Operations for Logs, VCF Operations for Networks — che si dichiarano alla console centrale e da lì si configurano. Chi arriva da vRealize/Aria deve rifare la mappa mentale prima ancora di rifare i click: cambiano i nomi, cambia il punto in cui si preme «Add», e in diversi casi cambia il prodotto che tiene lo stato.

Log: architettura di raccolta e pagina Analyze

VCF Operations 9.0 raccoglie, analizza, trasforma ed elabora i log dei componenti della piattaforma. L’architettura di raccolta centralizzata richiede l’integrazione fra VCF Operations e VCF Operations for Logs: il cluster di Logs conserva la configurazione di raccolta, ma gli aggiornamenti si avviano sempre da VCF Operations. Sui componenti supportati l’agent è preinstallato, si configura centralmente tramite gli Agent Groups, si autoaggiorna scaricando la versione dal server e arricchisce i log con informazioni statiche come nome dell’applicazione e percorso del file. Quando i data center sono più d’uno entra in gioco lo Unified Cloud Proxy, che gestisce credenziali e trasmissione cifrata e configura il log forwarder verso VCF Operations for Logs.

Novità della 9.0 è la standardizzazione del formato: HEADER <space> STRUCTURED-DATA <space> MSG, dove HEADER e STRUCTURED-DATA sono obbligatori e MSG può mancare. L’header porta timestamp RFC 5424 in UTC, severity (da EMERGENCY a DEBUG), APP-NAME e PROC-ID; lo STRUCTURED-DATA contiene un SD-ID che identifica il componente emittente, con suffisso @4413 (per esempio ops@4413). Attenzione al perimetro: aderiscono VCF Operations (solo adapter e collector services), VCF Operations for Networks (solo i servizi Java, non gli script shell) e VCF Identity Broker (solo i log del Federation Service). Se avete automazioni o parsing costruiti sul formato precedente, vanno riscritti.

L’analisi vera si fa da Infrastructure Operations → Analyze, tab Logs: si costruiscono query per estrarre eventi per timestamp, testo, sorgente e campi, si estraggono dinamicamente campi dai messaggi in base a query personalizzate, e i grafici prodotti si salvano per ritrovarli in Dashboards and Reports. L’accesso alla pagina dipende dal permesso Infrastructure Operations Analyze del ruolo, in Administration → Control Panel → Roles.

Dal log si passa all’allarme senza cambiare prodotto: Infrastructure Operations → Configurations → Alert Definitions → Add, si dà il nome, si sceglie il Base Object Type (per esempio Host System), si trascina Add Log Condition nella sezione Symptoms/Conditions, si imposta il Filter By e la finestra temporale, si assegna la policy e si crea. Il tile Symptom Definitions, nella stessa pagina, ospita i quattro tipi di sintomo — Metric/Property, Message Events, Faults, Logs — e la regola d’oro resta definire più sintomi per coprire tutte le severità. Gli alert nascono con impatto Health, Risk o Efficiency e severità Critical, Immediate, Warning o Info; il tile Notifications decide cosa esce, con i plug-in outbound Standard Email, REST, SNMP Trap e Log File.

VCF Health e Diagnostics

VCF Operations diagnostics riunisce tre strumenti: Diagnostic Findings, VCF Health e Log Assist. Un vincolo che l’esame ama: funzionano solo in Connected mode, perché servono i link alla knowledge base, le guide di troubleshooting e la documentazione.

VCF Health offre due prospettive complementari, la Component View — riepilogo olistico di tutti gli oggetti — e la VCF View, che scende l’albero dell’inventario dai domini di gestione fino al singolo host ESX, e sorveglia aree come certificati, NTP/DNS, istanze vCenter, host, operazioni sulle VM, task vMotion e snapshot.

I Diagnostics Findings raccolgono proprietà e log da vCenter, ESX, NSX, SDDC Manager, VCF Operations, vSAN e VCF Automation. Gli Active Findings mostrano l’esito delle ultime 24 ore da controlli sulle proprietà eseguiti ogni 4 ore; Refresh Findings lancia un’analisi su richiesta basata sui log di prodotto; gli Historical Findings guardano oltre quella finestra. Espandendo un finding si leggono sommario, descrizione, oggetti interessati con link e raccomandazioni — passi specifici oppure una KB. Perché funzioni servono oggetti con collector attivo e Collection Status verde; i controlli basati sui log richiedono VCF Operations for Logs installato e integrato.

Log Assist, raggiungibile dalla scheda Diagnostics Findings, genera i bundle di supporto e li carica sul Broadcom Support Portal senza client FTP esterni, dopo aver verificato la connettività verso il collector, dal collector al componente e verso il portale. Il tipo di bundle dipende dal componente: LITE per VCF Operations, bundle standard per vCenter, bundle da DCUI per ESX, API logs più log applicativi per SDDC Manager e Fleet Management, filtro DEFAULT per NSX.

Reti: visibilità, analytics, troubleshooting guidato

VCF Operations for Networks porta le operazioni intelligenti su rete e sicurezza software-defined: pianificazione della micro-segmentazione, visibilità su reti virtuali e fisiche, viste operative per i deployment NSX. Sul fronte visibilità si usano Path Topology, che disegna la connessione fra due VM, BGP Neighbors per i vicini di un NSX edge o di un router logico, e Path to Internet con percorso animato.

Le soglie non si impostano in VCF Operations ma qui, da Home → Analytics → Thresholds → Add: nome, Scope (VM, flussi…), criteri di filtro, aggregazione, e poi la scelta fra soglia statica (exceeds threshold, drops below, is outside range) e dinamica (deviates from the past behavior, con sensibilità configurabile). Si completano Upper e Lower Bound, la Minimum Violation Duration che evita gli allarmi isterici, la severità, i destinatari e l’eventuale Send SNMP Trap. Il Guided Network Troubleshooting parte da un’entità, costruisce il grafo delle dipendenze, correla metriche e alert ed evidenzia le anomalie.

L’integrazione con VCF Operations consuma le API di Networks: gli alert di rete compaiono nella dashboard degli alert con prefisso vrni- e dalle pagine di VM, host e NSX-T si fa launch-in-context. Prerequisito: l’utente VCF Operations va creato in VCF Operations for Networks con almeno privilegi Member.

Storage: la pagina Storage Operations

Infrastructure Operations → Storage Operations è la dashboard centralizzata per storage vSAN e non-vSAN: alert relativi allo storage, utilizzo e distribuzione dei datastore, filtri per scendere nel dettaglio. Il widget vSAN Cluster Performance confronta i cluster fra loro e offre View Diagnostics e Run New Diagnostics, con due modalità: Troubleshooting per cluster già in produzione con carichi attivi, Benchmarking and Optimizing per cluster nuovi prima della messa in esercizio; le metriche in gioco sono IOPS, latenza e throughput. Prerequisito banale ma dimenticato spesso: un account vCenter abilitato vSAN e la raccolta dati attiva.

Sotto la dashboard resta la semantica di vSAN, che va conosciuta per interpretare gli allarmi. Un componente degraded è un guasto permanente — cache flash, disco di capacity, controller — e il rebuild parte subito se ci sono risorse; un componente absent è un guasto potenzialmente temporaneo (rete, adattatore, host, disco scollegato) e per impostazione predefinita il rebuild parte dopo 60 minuti.

Trappole tipiche d’esame

  • VCF Operations for Networks, non «VCF Network Operations»: il blueprint usa la seconda forma, la documentazione di prodotto la prima. E niente vRealize o Aria: in 9.0 sono VCF Operations, VCF Operations for Logs, VCF Operations for Networks. La documentazione scrive ESX, non «ESXi».
  • Dove si configura cosa: le soglie di rete stanno in Analytics → Thresholds dentro VCF Operations for Networks; le alert e symptom definition stanno in Infrastructure Operations → Configurations dentro VCF Operations. Gli alert vrni- si vedono in VCF Operations ma non si creano lì.
  • Connected mode: Findings, VCF Health e Log Assist non sono disponibili in modalità disconnessa. In più, i finding basati sui log richiedono VCF Operations for Logs integrato, e ogni oggetto deve avere collector attivo e Collection Status verde.
  • Absent contro degraded in vSAN: il ritardo di 60 minuti prima del rebuild vale per il componente absent, non per il degraded, che riparte immediatamente. Uno scenario che descrive un host riavviato e un rebuild che «non parte» sta descrivendo il comportamento normale.
  • VCF contro vSphere Foundation: vSphere Foundation non include le capacità di cloud management e automazione integrata di VCF. Uno scenario che nomina dashboard VCF Automation, workload domain o Fleet Management presuppone VCF, non VVF.