Questo obiettivo raccoglie le quattro cose che in VCF Operations si toccano dopo che l’inventario è già collegato: le policy che decidono come analizzare gli oggetti, il monitoraggio delle applicazioni dentro le VM, la scoperta dei servizi e delle loro dipendenze, e la misura della conformità. Sono funzioni che vivono tutte nella stessa console, ma in tre punti diversi del menu, e l’esame gioca esattamente su quella distanza.

La policy è il contenitore delle regole di analisi

Una policy è un insieme di regole che VCF Operations usa per analizzare e presentare le informazioni sugli oggetti: da essa dipendono le soglie, gli alert che scattano, i calcoli di capacità e ciò che dashboard, viste e report mostrano. Ne esistono tre famiglie: la default policy, che si applica alla maggior parte degli oggetti; le policy fornite con il prodotto, usabili così o come base; e le policy custom che create voi. Il meccanismo chiave è l’ereditarietà: una policy che non ha impostazioni locali definite eredita le impostazioni dalla sua policy base. Non si parte quasi mai da zero — si sceglie una base e si sovrascrive solo ciò che serve.

Il Policy Workspace è diviso in sezioni che conviene conoscere per nome: Metrics and Properties (quali metriche, proprietà e super metriche raccogliere e conservare), Alerts and Symptoms (attivare o disattivare le definizioni di alert e di sintomo), Capacity (impostazioni di calcolo di capacità e tempo rimanente, progetti impegnati), Compliance (la soglia di conformità richiesta dalla policy), Workload Automation (con l’icona del lucchetto: finché è bloccata, la sezione eredita dalla policy padre) e Groups and Objects, dove la policy viene legata a gruppi e oggetti.

Assegnazione e precedenza: la parte che si sbaglia

L’assegnazione si fa da Operate > Administration Configurations > Policy Definition. Nel riquadro di destra si aprono All Objects > Inventory oppure All Objects > Custom Groups, si selezionano gli elementi e li si trascina sulla scheda della policy a sinistra; a quel punto si sceglie se applicarla solo a questo oggetto o includere gli oggetti figli, con una profondità massima di dieci livelli.

La regola di precedenza è netta: quando più policy si applicano allo stesso oggetto, vince quella con la priorità più alta — con una sola eccezione, l’assegnazione diretta all’oggetto, che prevale anche se la sua policy ha priorità inferiore. Le assegnazioni predefinite si vedono espandendo la scheda della policy e compaiono solo per la default policy. Ricordate anche che le soglie dinamiche sono un motore separato, governato da Administration > Global Settings > Dynamic Thresholds: si attivano, disattivano e si può forzarne il ricalcolo fuori dalla pianificazione, ma non si tarano oggetto per oggetto dentro la policy.

Monitorare le applicazioni: agente, cloud proxy, servizi

Il monitoraggio di OS e applicazioni si appoggia a tre pezzi: l’agente Telegraf installato sulla macchina bersaglio (VM gestita da vCenter, VM non gestita o server fisico), il cloud proxy che raccoglie e inoltra, e il collector group, che con l’HA del monitoraggio applicativo attivata lavora in modalità primario-secondario. Il flusso operativo è ordinato: si configura il cloud proxy su cui nasce l’istanza dell’adapter OS and Application, si soddisfano i prerequisiti e le credenziali per raggiungere le macchine, si installa l’agente (dall’interfaccia di VCF Operations per le VM gestite, oppure via script su Linux e Windows), si attivano i servizi applicativi da monitorare e infine si verifica il riepilogo dei sistemi operativi e dei servizi scoperti.

Esiste anche la via del Telegraf open source su endpoint eterogenei, comprese VM in cloud pubblico: uno script helper scrive nella configurazione di Telegraf ciò che serve per postare le metriche al cloud proxy. Attenzione ai limiti dichiarati: la versione 1.19.0 non è supportata, per i servizi non supportati arrivano le metriche ma non gli alert, quelle metriche non sono localizzate, il tag identifier distingue istanze multiple dello stesso servizio, e il supporto del vendor copre la sola installazione iniziale.

Sopra le metriche si costruiscono le business application: raggruppano applicazioni, servizi e host interdipendenti che erogano un servizio all’organizzazione e ne aggregano lo stato di salute, utili per capire l’impatto di un guasto. La dashboard Troubleshoot an Application mostra metriche e alert dell’applicazione scelta e la sua relazione con l’infrastruttura.

Service Discovery: chi parla con chi

Service Discovery scopre i servizi in esecuzione in ogni VM e costruisce le relazioni di dipendenza fra servizi di VM diverse. Si configura da Infrastructure Operations > Configurations, tile Service Discovery > Configure Service Discovery, oppure dalla pagina Integrations scegliendo l’istanza vCenter e la scheda Service Discovery. I prerequisiti contano: un’istanza di vCenter adapter che monitori lo stesso vCenter, accesso HTTPS sulla 443 dall’host ESX verso il cloud proxy, orologi sincronizzati fra nodi, vCenter e VM, e una directory temporanea scrivibile.

Nelle opzioni si attiva Service Discovery, eventualmente Enable Application Discovery, e si scelgono credenziali predefinite o alternate (Windows, Linux, SRM). In Advanced Settings si può portare a Activated la modalità credential-less. Su Linux, se l’utente indicato non è root, i servizi non vengono scoperti a meno di attivare l’opzione Use Sudo. Oltre ai servizi noti si possono aggiungere definizioni custom di tipo process o regex: il nome del processo deve corrispondere esattamente all’output di ps o wmic, e il servizio è scopribile solo se ha una porta TCP in ascolto permanente o una connessione UDP stabilita. Le dashboard pronte sono Service Distribution, Service Relationships, Service Visibility e Virtual Machine Relationships.

Conformità e hardening

La conformità si governa da Security > Compliance, dove si configurano i benchmark VCF, VMware SDDC, Regulatory e Custom (importabili ed esportabili in XML). Il punto concettuale: tutti gli standard di conformità poggiano su definizioni di alert, e contano solo quelle di sottotipo Compliance; i sintomi rappresentano le regole e identificano il valore o la configurazione errata. Dalla pagina Compliance si possono abilitare le definizioni di alert direttamente in una delle policy attive. Il risultato è una score card e un punteggio percentuale per oggetto o gruppo, che VCF Operations aggiorna monitorando l’infrastruttura in continuo.

Accanto c’è Security > Security Operations, con la vista Infrastructure Security: advisory di sicurezza, Host Encryption Mode, Host Mode, cifratura dei cluster vSAN, certificati in scadenza e stato di cifratura delle VM. È postura, non punteggio: complementare alla compliance, non sostitutiva.

Trappole tipiche d’esame

  • Attivare il benchmark non basta. La conformità si misura tramite alert definitions di sottotipo Compliance: se quelle definizioni non sono abilitate in una policy attiva assegnata a quegli oggetti, lo score non si muove. È il punto in cui policy e compliance si incrociano, ed è l’anello che i distrattori tolgono.
  • Priorità sì, ma l’assegnazione diretta vince. «La policy con priorità più alta» è vera solo finché nessuno ha legato l’oggetto direttamente a un’altra policy. E ricordate il tetto di dieci livelli quando includete gli oggetti figli.
  • Service Discovery ≠ Application Monitoring. Il primo scopre quali servizi girano e come dipendono l’uno dall’altro, lavorando dal vCenter con credenziali guest o in modalità credential-less; il secondo richiede l’agente Telegraf e un cloud proxy per portare le metriche del servizio. Chi vuole metriche e alert applicativi non risolve nulla attivando solo il discovery.
  • Su VVF il catalogo dei benchmark è più corto di quello che leggete. Il benchmark VCF nomina anche NSX e SDDC Manager: in vSphere Foundation quei componenti non ci sono, quindi si auditano ESX, vCenter e vSAN. Una risposta che vi chiede di correggere la conformità «dei Logical Switch» descrive un ambiente VCF, non VVF.
  • I dettagli piccoli di Telegraf sono domande vere. Utente Linux non root senza Use Sudo uguale zero servizi scoperti; servizio non supportato uguale metriche senza alert; supporto del vendor limitato alla sola installazione iniziale del Telegraf open source.