Modulo 4 — Observability

⏱ Tempo di lettura: ~10 minuti 🎯 Obiettivo: capire come si fanno monitoring, alerting e logging in OpenShift Virtualization, traducendo dal mondo vCenter Alarms / Aria Operations / log shipping di vSphere.

Punto di partenza: il modello vSphere

In vSphere l’osservabilità è distribuita fra più strumenti:

• vCenter Alarms: regole su eventi, condizioni, stato (es. “host non risponde”, “datastore al 90%”). Possono inviare email, SNMP trap, eseguire script.
• vCenter Performance Charts: grafici realtime e storici di CPU, RAM, IO storage, rete, per host e per VM.
• vRealize / Aria Operations: il prodotto più ricco, con analisi capacity, trending, what-if.
• Log shipping: i log dell’host ESXi e di vCenter possono essere inviati a Syslog server o a vRealize Log Insight / Aria Operations for Logs.
• Per-VM logging: un’opzione avanzata permette di abilitare un log file dedicato per ciascuna VM (vmware.log, vmware-1.log, vmware-2.log…).

L’admin VMware ha quindi una “pila” di strumenti, alcuni inclusi (vCenter Alarms, charts), altri commerciali (Aria).

Il modello OpenShift: lo stack è già lì, integrato

OpenShift include nativamente un intero stack di osservabilità basato su componenti CNCF/open source, gestito da operator. Non devi installare nulla: una volta installato OpenShift, hai già:

            ┌──────────────────────────────────────────────────┐
            │             OpenShift Observability              │
            ├──────────────────────────────────────────────────┤
            │                                                  │
            │   METRICHE       Prometheus + Thanos             │
            │                  (collect + storage HA)          │
            │                                                  │
            │   DASHBOARD      Grafana / Console dashboards    │
            │                                                  │
            │   ALERTING       Alertmanager                    │
            │                  (routing su email, Slack,       │
            │                   PagerDuty, MSTeams, webhook…)  │
            │                                                  │
            │   LOGGING        Vector (collect)                │
            │                  Loki (storage)                  │
            │                  Console plugin (visualization)  │
            │                                                  │
            │   TRACING        Distributed Tracing (Tempo,     │
            │                  opzionale)                      │
            │                                                  │
            │   FLOW LOGS      Network Observability Operator  │
            │                                                  │
            └──────────────────────────────────────────────────┘

Tutto questo è gestito tramite operator, è multi-tenant (ogni team vede i propri pod/VM), ed è esteso automaticamente a OpenShift Virtualization: le VM emettono metriche e log come qualunque altro workload.

Tabella di mapping delle feature

Feature vSphere	Equivalente OpenShift
vCenter Alarms (regole su eventi/condizioni)	PrometheusRule + Alertmanager
Email / SNMP / script come azione	Alertmanager: email, webhook, PagerDuty, Slack, MSTeams (e altri tramite webhook)
vCenter Performance Charts	Console di OpenShift, dashboard predefinite per VM, oppure Grafana custom
Aria Operations (analytics e capacity)	OpenShift Monitoring + Advanced Cluster Management (ACM) per multi-cluster
Per-VM log file (vmware.log)	Log della VM (console + qemu) raccolti da Vector, indicizzati in Loki
Log shipping verso Syslog / vRLI	Vector come multi log forwarder verso destinazioni esterne (Splunk, Elastic, syslog, S3…)
vRealize Log Insight (storage e ricerca log)	Loki + Console plugin di logging
APM commerciale (Wavefront, Dynatrace…) per observability applicativa	Service Mesh (Istio + Kiali + Jaeger/Tempo) per pod e VM

Il menu Observe della web console

In OpenShift Virtualization le voci principali per l’osservabilità sono raccolte sotto Observe:

Voce di menu	Cosa rappresenta	Equivalente per admin VMware
Alerting	Allarmi attivi, silenzi, regole di alerting	È la sezione “Alarms” di vCenter
Metrics	Esplorazione interattiva delle metriche (PromQL)	È simile a “performance charts” ma con un linguaggio query potente
Dashboards	Dashboard predefinite e custom	Equivalente delle “Performance > Overview / Advanced”
Targets	Lista degli endpoint che Prometheus sta facendo scrape	Concetto nuovo: vede in trasparenza “chi sto monitorando”

E aggiungendo i plugin:

• Logging (richiede l’omonimo operator) — vista log centralizzata
• Network Traffic (richiede Network Observability Operator) — flow logs della rete

Metriche specifiche per le VM

OpenShift Virtualization espone una serie di metriche dedicate alle VM (oltre a quelle standard del nodo):

Metrica (esempio)	Cosa misura
kubevirt_vmi_phase_count	Quante VM sono in stato Running, Pending, Failed…
kubevirt_vmi_memory_usable_bytes	RAM utilizzabile dalla VM
kubevirt_vmi_memory_actual_balloon_bytes	Stato del balloon di memoria
kubevirt_vmi_storage_iops_read_total	IOPS in lettura
kubevirt_vmi_network_receive_bytes_total	Byte ricevuti da una NIC
kubevirt_vmi_migration_succeeded	Counter di live migration riuscite

Esempio di query PromQL per “quante VM stanno girando per namespace”:

sum by(namespace) (kubevirt_vmi_phase_count{phase="Running"})

Esempio per “uso RAM percentuale per VM”:

100 * (
  kubevirt_vmi_memory_used_bytes
  /
  kubevirt_vmi_memory_available_bytes
)

Definire un alert: il concetto di “alarm vCenter” in YAML

Un alarm vCenter “se la CPU dell’host è > 90% per 10 minuti, manda email”, in OpenShift si scrive così:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: vm-cpu-alerts
  namespace: openshift-virtualization-monitoring
spec:
  groups:
    - name: vm.cpu
      rules:
        - alert: VMCPUHighSustained
          expr: |
            avg by(name, namespace) (
              rate(kubevirt_vmi_vcpu_seconds_total[5m])
            ) > 0.9
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "VM {{ $labels.name }} ha CPU sopra il 90% da 10 minuti"
            description: "Verificare carico applicativo o sizing"

E per recapitarlo dove serve, si configura Alertmanager con le route:

# Snippet di Alertmanager config (semplificato)
route:
  receiver: default-email
  routes:
    - matchers:
        - severity = "critical"
      receiver: pagerduty-vm-team
    - matchers:
        - severity = "warning"
      receiver: slack-vm-team
receivers:
  - name: default-email
    email_configs:
      - to: vmadmin@example.com
        from: openshift-alerts@example.com
        smarthost: smtp.example.com:587
  - name: pagerduty-vm-team
    pagerduty_configs:
      - service_key: <key>
  - name: slack-vm-team
    slack_configs:
      - api_url: <webhook>
        channel: '#vm-alerts'

In una sola configurazione hai email + PagerDuty + Slack. Niente di simile è disponibile out-of-the-box in vCenter, è un evidente vantaggio di OpenShift.

Logging: dove finiscono i log delle VM

In OpenShift Virtualization i log “interessanti” sono di tre tipi:

1. Log dell’OS guest della VM. Sono dentro la VM (es. /var/log/messages su Linux). Per portarli fuori, la pratica raccomandata è usare un log forwarder dentro la VM (rsyslog, Fluent Bit, o cloud-init che configura una destinazione syslog).
2. Log del livello virtualization (qemu, virt-launcher). Sono prodotti dal pod che esegue la VM. Vengono raccolti automaticamente dallo stack OpenShift Logging (Vector → Loki) come qualunque log di pod.
3. Log della console seriale (utile per troubleshooting all’avvio). Accessibili via virtctl console <vm> o sulla Console UI.

Lo stack di logging “moderno” di OpenShift è basato su:

• Vector — collector leggero ed efficiente sui nodi (sostituisce il vecchio Fluentd).
• Loki — backend di storage log, organizzato per “stream” e label.
• OpenShift Console plugin — UI integrata per ricerca log, con filtri per namespace/VM.

L’equivalente di “spedisco i log a Splunk” è la configurazione di multi-forwarder di Vector:

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
    - name: splunk-prod
      type: splunk
      splunk:
        url: 'https://splunk.example.com:8088'
        token: <token>
    - name: loki-default
      type: loki
      loki:
        url: 'http://loki-distributor.openshift-logging.svc:3100'
  pipelines:
    - name: vm-logs
      inputRefs:
        - infrastructure
        - application
      outputRefs:
        - splunk-prod
        - loki-default

Stesso log → due destinazioni in parallelo. Pattern molto comune.

Network Observability: il “port mirroring” moderno

Quando in vSphere vuoi capire “chi sta parlando con chi e su che porte”, usi port mirroring + uno strumento di analisi (NSX Traffic Analysis, sniffer esterno).

In OpenShift c’è il Network Observability Operator, basato su eBPF: cattura i flow logs (livello L3/L4) di tutto il traffico del cluster, inclusi pod e VM, e ti dà:

• vista grafica delle conversazioni (sankey diagram, topology view);
• tabelle dei flow con filtraggio per namespace, pod, VM, IP, porta;
• esportazione verso strumenti esterni (Loki, Kafka).

È particolarmente utile in fase di migrazione da VMware a OpenShift, per verificare che le VM stiano davvero parlando solo con chi devono parlare (e capire quali NetworkPolicy scrivere).

Service Mesh: l’osservabilità a livello applicazione

Network Observability si ferma a livello L3/L4 (chi parla con chi, su quale porta). Quando ti serve capire cosa sta succedendo dentro le applicazioni — quali API HTTP stanno fallendo, qual è la latenza p99 di una chiamata REST, quale microservizio è il collo di bottiglia — entra in gioco Service Mesh.

Red Hat OpenShift Service Mesh (basato su Istio + Kiali + Jaeger) fornisce:

• Traffic flow visualization con Kiali (vista grafica delle chiamate fra servizi);
• Distributed tracing con Jaeger/Tempo (ricostruzione delle catene di chiamate cross-servizio);
• Metriche application-level (RED: Rate, Errors, Duration);
• Politiche di traffic management (canary, mirroring, circuit breaker) e mTLS automatico fra servizi.

Il punto interessante per chi viene da vSphere: in OpenShift Virtualization, Service Mesh funziona allo stesso modo per pod e per VM. Le tue VM “tradizionali” possono partecipare alla mesh come qualunque altro servizio: ottieni metriche, tracing, mTLS senza modificare il codice dell’applicazione.

Questo è qualcosa che in vSphere non ha un equivalente nativo: per avere observability applicativa di servizi ospitati su VM serviva di solito un prodotto APM separato (Wavefront, Dynatrace, AppDynamics, …).

💡 Quando ha senso accendere Service Mesh. Service Mesh aggiunge complessità (sidecar proxy per ogni pod/VM, policy YAML da gestire). Non è una “feature gratis”: va valutato per ambienti con architettura a microservizi reale o quando si ha bisogno di mTLS e tracing automatici. Per una flotta di VM “monolitiche” tradizionali, Network Observability + alerting standard sono spesso sufficienti.

Differenze chiave da tenere a mente

1. Niente prodotto separato. L’osservabilità è inclusa nella sottoscrizione OpenShift, non ci sono licenze aggiuntive da comprare per i pezzi base. Per multi-cluster c’è ACM, che è incluso in alcune edizioni.
2. Le query sono “code-as-config”. PromQL e LogQL sono linguaggi che vanno imparati. La curva di apprendimento iniziale è più alta, ma poi ti dà flessibilità impensabile in vCenter Alarms.
3. Multi-tenant nativo. Se hai più team che condividono un cluster, ognuno vede solo le proprie metriche e log per default. Concetto che in vSphere si gestisce con permission complicati su vCenter.
4. Storage dei dati osservabili è limitato. Prometheus default tiene 15 giorni, Loki dipende dalla configurazione. Per retention storica lunga si configura Thanos (per metriche) o un object storage dedicato (per Loki). Pianifica.
5. Tutto è API-driven. Puoi versionare PrometheusRule, AlertmanagerConfig, ClusterLogForwarder in Git: GitOps degli alert. Questo da solo, per molti, vale il salto.

Best practice operative

• Accendi User Workload Monitoring fin dall’inizio se hai team che vogliono auto-monitorare le proprie applicazioni.
• Definisci una baseline di alert “VM-critical”: VM in Failed, live migration falliti, nodo che pesa troppo, PVC pieni. Sono i tuoi “amber/red lights”.
• Forwarda i log fuori dal cluster verso un sistema esterno (Splunk, Elastic, syslog) per audit e compliance: un cluster che rinasce non porta con sé i log persi.
• Network Observability acceso anche solo in modalità “demand”: fa risparmiare ore di troubleshooting quando un’app non parla.
• Capacity dashboard create da subito: trend di uso CPU/RAM/storage per cluster e per namespace. Senza queste, ti accorgi tardi della saturazione.

Approfondimenti ufficiali

• Observability overview
• Monitoring overview (Prometheus stack)
• Alertmanager configuration
• Logging 6.x
• Network Observability
• Monitoring overview specifico per Virtualization

---

← Modulo 3 — Compute | Avanti → Modulo 5 — Componenti delle VM