Quando si gestiscono diversi servizi self-hosted, dalla NAS al gestionale, dai container Docker agli strumenti di monitoraggio, ci si ritrova presto con una collezione disordinata di indirizzi IP, porte e bookmark sparsi tra browser e appunti.

Tenere tutto sotto controllo diventa rapidamente scomodo, soprattutto quando il numero di applicazioni cresce.

Heimdall nasce proprio per risolvere questo problema: è una dashboard leggera e open source che funge da punto d’accesso unico a tutte le applicazioni e i servizi del nostro homelab o della nostra infrastruttura.

Con un’interfaccia pulita e personalizzabile, permette di organizzare i collegamenti in un’unica pagina, aggiungere icone, e per molti servizi supportati mostra anche informazioni in tempo reale tramite appositi “enhanced links” (ad esempio lo stato di un container, lo spazio su disco di una NAS o le statistiche di un servizio).

In questa guida vedremo come installare e configurare Heimdall su Ubuntu Server 26.04, partendo dai prerequisiti fino alla prima messa in funzione della dashboard.

Affronteremo l’installazione tramite Docker, l’approccio più pulito e replicabile, e vedremo le configurazioni di base per iniziare subito a organizzare i nostri servizi in modo ordinato ed elegante.

PREREQUISITI

Server Ubuntu 26.02

Utente con diritti di sudo

METODO 1 – DOCKER (CONSIGLIATO)

Installare Docker se non presente

sudo apt update

Rimuovere l’eventuale docker.io già installato e aggiungere il repo Docker:

sudo apt remove -y docker.io
sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Aggiungere il repository con il seguente comando:

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Installare tutto il pacchetto completo (engine + CLI + compose plugin):

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo systemctl enable --now docker

sudo usermod -aG docker $USER

newgrp docker

Creare la struttura e il file Compose con i seguenti comandi:

mkdir -p ~/heimdall/config

cd ~/heimdall

cat > compose.yaml << 'EOF'
services:
heimdall:
image: lscr.io/linuxserver/heimdall:latest
container_name: heimdall
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/Rome
volumes:
- ./config:/config
ports:
- 8080:80
- 8443:443
restart: unless-stopped
EOF

Verificare PUID/PGID con id e correggere se diversi da 1000. Avviare con il comando:

docker compose up -d

docker compose logs -f

Se è tutto OK dovremmo visualizzare il seguente ouput:

heimdall | [migrations] started
heimdall | [migrations] 01-nginx-site-confs-default: executing...
heimdall | [migrations] 01-nginx-site-confs-default: succeeded
heimdall | [migrations] 02-default-location: executing...
heimdall | [migrations] 02-default-location: succeeded
heimdall | [migrations] done
heimdall | ───────────────────────────────────────
heimdall |
heimdall | ██╗ ███████╗██╗ ██████╗
heimdall | ██║ ██╔════╝██║██╔═══██╗
heimdall | ██║ ███████╗██║██║ ██║
heimdall | ██║ ╚════██║██║██║ ██║
heimdall | ███████╗███████║██║╚██████╔╝
heimdall | ╚══════╝╚══════╝╚═╝ ╚═════╝
heimdall |
heimdall | Brought to you by linuxserver.io
heimdall | ───────────────────────────────────────
heimdall |
heimdall | To support LSIO projects visit:
heimdall | https://www.linuxserver.io/donate/
heimdall |
heimdall | ───────────────────────────────────────
heimdall | GID/UID
heimdall | ───────────────────────────────────────
heimdall |
heimdall | User UID: 1000
heimdall | User GID: 1000
heimdall | ───────────────────────────────────────
heimdall | Linuxserver.io version: v2.7.6-ls351
heimdall | Build-date: 2026-06-26T20:11:47+00:00
heimdall | ───────────────────────────────────────
heimdall |
heimdall | Setting resolver to 127.0.0.11
heimdall | Setting worker_processes to 2
heimdall | generating self-signed keys in /config/keys, you can replace these w ith your own keys if required
heimdall | ..+......+......+...+..+......+...+.+........+...+++++++++++++++++++ ++++++++++++++++++++*........+......+.+...........+....+...+.....+.............. ....+...+......+.+..+.+...........+.........+.........+......+....++++++++++++++ +++++++++++++++++++++++++*.........+...+..+....+........+...+...+.+...+...+..... +.........+...+...............+.+..+...+....+...+........+....+................. .+...+.........+...........+..........+.....+..........+......+.....+...+....... ...+...........+.........+.......+.....+.++++++
heimdall | .+.+........+++++++++++++++++++++++++++++++++++++++*...+............ .....+...+.+...+.....+.+.....+....+...+..+++++++++++++++++++++++++++++++++++++++ *...........+.....+.......+........+.+..+...+.......+..+...+.......+...+........ +.+........+.+.....+......................+...............+...+..+.............+ ..+...+....+......+...........+....+......+...........+...+.+......+.....+...... .......+..+...+................+...+.....+...+...+....+............+...+..+...+. +......+.....+......+.........+......+...+.+....................+.+..+.+........ ...+......+.............+......+...+..+.+..................+...........+......+. ........+.++++++
heimdall | -----
heimdall | New container detected, installing Heimdall
heimdall | Creating app key. This may take a while on slower systems
heimdall |
heimdall | INFO Application key set successfully.
heimdall |
heimdall | [custom-init] No custom files found, skipping...
heimdall | [ls.io-init] done.

Accedere via http://IP_SERVER:8080 (o https://IP_SERVER:8443).

Se è andato tutto a buon fine dovremmo visualizzare una schermata come quella sovrastante

Dopo aver caricato un po di applicazioni dovremmo visulizzare una schermata simile a quella sovrastante

METODO 2 – INSTALLAZIONE NATIVA CON LEMP

Heimdall è un’app Laravel/PHP. Servono PHP 8.x, un web server e SQLite.

Eseguire i seguenti comandi:

sudo apt update

sudo apt install -y nginx php-fpm php-cli php-sqlite3 php-xml php-mbstring php-zip php-curl php-bcmath git unzip

Scaricare l’ultima release da GitHub (controlla il tag aggiornato su github.com/linuxserver/Heimdall/releases):

cd /var/www

sudo git clone https://github.com/linuxserver/Heimdall.git heimdall

cd heimdall

sudo git checkout $(git describe --tags --abbrev=0)

Installare Composer e le dipendenze con i seguenti comandi:

curl -sS https://getcomposer.org/installer | php

sudo mv composer.phar /usr/local/bin/composer

sudo composer install --no-dev --optimize-autoloader

Configurare l’ambiente con i comandi:

sudo cp .env.example .env

sudo php artisan key:generate

sudo chown -R www-data:www-data /var/www/heimdall

sudo chmod -R 755 /var/www/heimdall/storage

Creare il virtual host Nginx in /etc/nginx/sites-available/heimdall con il comando:

sudo nano /etc/nginx/sites-available/heimdall

Quindi inccolare il seguente output:

server {
listen 80;
server_name _;
root /var/www/heimdall/public;
index index.php;

location / {
try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}

Verificare il path esatto del socket PHP-FPM con ls /run/php/, poi attivare e riavviare con i comandi:

sudo ln -s /etc/nginx/sites-available/heimdall /etc/nginx/sites-enabled/

sudo nginx -t

sudo systemctl reload nginx

Accedere via http://IP_SERVER.

Se è andato tutto a buon fine dovremmo visualizzare una schermata come quella sovrastante

Dopo aver caricato un po di applicazioni dovremmo visulizzare una schermata simile a quella sovrastante

PRO E CONTRO

Pro

Semplicità d’uso — Interfaccia molto intuitiva, aggiungere applicazioni richiede pochi clic. Adatto anche a chi è alle prime armi con il self-hosting.

Leggero — Consuma poche risorse, gira senza problemi anche su hardware modesto come un Raspberry Pi o una piccola VM.

Enhanced links — Per diversi servizi popolari (Pi-hole, Portainer, Nextcloud, Sonarr/Radarr, ecc.) mostra statistiche in tempo reale direttamente sulla tile, non solo un semplice collegamento.

Estetica curata — Sfondi personalizzabili, tile con icone, layout pulito. Visivamente è una delle dashboard più gradevoli.

Setup rapido — Con Docker è operativo in pochi minuti, configurazione persistente in un singolo volume.

Open source e gratuito — Mantenuto attivamente, immagine ufficiale curata da LinuxServer.io.

Contro

Solo bookmark e widget base — Non è un dashboard “data-driven” avanzato. Se cerchi grafici complessi, aggregazione di metriche o widget altamente configurabili, resta limitato.

Catalogo enhanced links limitato — Il numero di integrazioni native è relativamente ristretto e cresce lentamente rispetto ad alternative.

Nessun auto-discovery — Ogni applicazione va aggiunta manualmente. Non rileva automaticamente i container Docker in esecuzione (a differenza di alternative come Homepage o Dashy).

Configurazione non dichiarativa — Tutto si gestisce dalla GUI; non esiste un file di configurazione YAML versionabile. Poco comodo se vuoi un approccio “as code” o replicare il setup tra più ambienti.

Sviluppo lento — Il progetto è stabile ma il ritmo di rilascio di nuove funzionalità è piuttosto contenuto.

Multi-utente assente — Nessuna gestione di utenti o permessi: è pensato per uso personale/singolo, non per team con viste differenziate.

IN SINTESI

Heimdall è una scelta eccellente se vuoi una dashboard bella, semplice e leggera per organizzare i tuoi servizi senza complicazioni. Se invece cerchi configurazione dichiarativa, auto-discovery dei container o widget di monitoraggio ricchi, vale la pena valutare alternative come Homepage, Dashy o Homarr.

La gestione delle notifiche email è uno di quegli aspetti dell’amministrazione SQL Server che spesso viene trascurata finché non si ha bisogno davvero di sapere in tempo reale che un job è fallito, che un backup non è andato a buon fine o che un alert di monitoraggio si è attivato nel cuore della notte.

In ambienti enterprise, dove l’affidabilità dei processi schedulati è critica, avere un sistema di notifiche email configurato correttamente fa la differenza tra scoprire un problema all’alba di lunedì mattina e ricevere un avviso alle 2:00 di notte, quando si può ancora intervenire in tempo.

In questo articolo vedremo come configurare Database Mail su SQL Server Enterprise e come collegarlo all’SQL Server Agent per abilitare le notifiche automatiche tramite SMTP.

Partiremo dalla configurazione del profilo mail, analizzeremo le opzioni di sicurezza e autenticazione supportate incluso l’uso di account moderni come Microsoft 365 con autenticazione SMTP AUTH fino ad arrivare alla creazione degli operatori e all’associazione delle notifiche ai job agent.

Una configurazione completa, testata in produzione su SQL Server 2022 e 2025.

PREREQUISITI

Accesso a SSMS con privilegi sysadmin
Credenziali del server SMTP (host, porta, utente, password)
Service Broker abilitato su msdb (verificato automaticamente dalla procedura guidata)

STEP 1 — ABILITARE DATABASE MAIL XPS

Database Mail è disabilitato per default. Prima di tutto va abilitato tramite sp_configure con i seguenti comandi:

sqlUSE master;
GO
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'Database Mail XPs', 1;
RECONFIGURE;
GO

Se è andato tutto a buon fine dovremmo visualizzare una schermata come quella sovrastante

STEP 2 — AVVIARE LA PROCEDURA GUIDATA DA SSMS

A questo punto avviare la procedura tramite SSMS

In Object Explorer espandere il nodo Management e fare clic con il tasto destro su Database Mail e selezionare Configure Database Mail

Si aprirà il wizard. Cliccare Next

Alla prima schermata selezionare Set up Database Mail by performing the following tasks e cliccare Next

STEP 3 — CREARE UN PROFILO

Nella schermata New Profile inserire un nome per il profilo (es. SQLMailProfile) e una descrizione.

NOTA BENE: Il profilo è il contenitore che raccoglie uno o più account SMTP.

Cliccare Add… per aggiungere un account SMTP.

STEP 4 — CONFIGURARE L’ACCOUNT SMTP

Nella finestra New Database Mail Account compila i campi:

Account name: Nome univoco dell’account SMTP

Description: semplice descrizione

Email Address: Mittente delle email

Display Name: Nome visualizzato

Reply e-mail (opzionale): indirizzo reply-to

Server name: FQDN o IP del server SMTP

Port number: Porta SMTP — tipicamente 25 o 587, oppure 465 per SSL Microsoft

This Server requires a secure connection (SSl): Abilita se richiesto dal server

Nella Sezione autenticazione ci sono tre opzioni:

• Windows Authentication (NTLM, solo per Exchange on-premises)
• Basic Authentication (username e password espliciti)
• Anonymous (nessuna credenziale, solo se il server SMTP lo consente)

Per Office 365 / SMTP esterno scegli Basic Authentication e inserisci username e password.

Cliccare OK per confermare la configurazione

Cliccare Next

STEP 5 — GESTIRE LA SICUREZZA DEL PROFILO

Nella schermata Manage Profile Security spuntare la casella Public e impostare il profilo come Default Profile = Yes

Questo permette a qualsiasi utente con accesso a msdb di inviare email senza specificare un profilo esplicitamente.

STEP 6 — PARAMETRI DI SISTEMA (OPZIONALI)

Lasciare i valori di default. Il Logging Level è impostato su Extended di default, che registra errori, warning e messaggi informativi.

Cliccare Next

Cliccare Finish

Cliccare Close per chiudere il wizard

STEP 7 — INVIO DI UNA MAIL DI TEST

Da SSMS cliccare di destro su Database Mail → Send Test E-Mail…

Selezionare il profilo, inserire un destinatario e cliccare Send Test E-Mail

Se riceviamo la mail cliccare OK per confermare che tutto funzioni

In alternaitva è possibile fare il test dell’email tramite script T-SQL:

sqlEXEC msdb.dbo.sp_send_dbmail
@profile_name = 'SQLMailProfile',
@recipients = 'tuo@indirizzo.it',
@subject = 'Test Database Mail',
@body = 'Configurazione SMTP completata con successo!';

CONFIGURAZIONE DEL SERVER SMTP TRAMITE SCRIPT T-SQL

In alternativa al wizard è possibile configurare tutto via T-SQL se si preferisce configurare tutto via script (utile per automazione o documentazione):

sql-- 1. Abilita Database Mail
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'Database Mail XPs', 1; RECONFIGURE;

-- 2. Crea il profilo
EXEC msdb.dbo.sysmail_add_profile_sp
@profile_name = 'SQLMailProfile',
@description = 'Profilo SMTP per SQL Server';

-- 3. Crea l'account SMTP
EXEC msdb.dbo.sysmail_add_account_sp
@account_name = 'SMTPAccount',
@email_address = 'sqlserver@nposervices.com',
@display_name = 'SQL Server Alerts',
@mailserver_name = 'smtp.office365.com',
@port = 587,
@enable_ssl = 1,
@username = 'sqlserver@nposervices.com',
@password = 'TUA_PASSWORD';

-- 4. Associa account al profilo
EXEC msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = 'SQLMailProfile',
@account_name = 'SMTPAccount',
@sequence_number = 1;

-- 5. Rendi il profilo pubblico e default
EXEC msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = 'SQLMailProfile',
@principal_name = 'public',
@is_default = 1;

Verifica e troubleshooting
sql-- Controlla la coda dei messaggi inviati
SELECT * FROM msdb.dbo.sysmail_sentitems ORDER BY sent_date DESC;

-- Controlla eventuali errori
SELECT * FROM msdb.dbo.sysmail_event_log ORDER BY log_date DESC;

-- Verifica configurazione profili e account
EXEC msdb.dbo.sysmail_help_profile_sp;
EXEC msdb.dbo.sysmail_help_account_sp;

A questo punto dovremmo essere in grado di inviare le mail con il nostro SQL Server…

Meridian ARC oltre il ticket: Orbit e il CRM interno della Enterprise Edition

Un buon Service Desk gestisce i ticket. Ma chi eroga servizi IT a più clienti sa che il lavoro vero comincia *attorno* al ticket: i contratti, gli SLA concordati, i verbali di avanzamento, chi è responsabile di cosa, le offerte da preparare. E poi c’è la macchina interna — documenti da firmare, cespiti aziendali da assegnare ai dipendenti, ricevute da tracciare.

Meridian ARC affronta questi due mondi con due aree dedicate, distinte dal Service Desk:

Orbit — l’area di governance e gestione contrattuale, cliente-centrica.
CRM / Gestionale interno — la console per le risorse interne dell’MSP.

La cosa interessante, dal punto di vista delle licenze, è che Orbit è quasi tutto incluso nella Community, mentre il CRM interno è ciò che la Enterprise Edition sblocca davvero. Vediamoli in dettaglio.

Questo articolo è dedicato alle aree Orbit e CRM interno. Il modulo ITSM / Service Desk (Incident, Problem, Change, SLA, CMDB…) ha un articolo a parte.

Home di Orbit: la griglia dei clienti assegnati al Service Manager

Orbit: la governance del cliente, già nella Community

Orbit è la seconda area della piattaforma, accessibile al personale MSP (Service Manager, Team Leader). È pensata per la governance: tutto ciò che riguarda il rapporto contrattuale e organizzativo con il cliente, sopra e oltre il singolo ticket. E — buona notizia — fa parte del nucleo Community.

Contratto & SLA

Una vista del contratto attivo del cliente: livelli di servizio, KPI, orari di lavoro, RPO/RTO, CSAT e note interne. È il punto di riferimento per il Service Manager quando deve verificare cosa abbiamo promesso a quel cliente.

Contratto & SLA: copertura, periodo KPI, RPO/RTO, retention e livelli di priorità

SAL e verbali

La gestione degli Stati Avanzamento Lavori in due forme:

• SAL cliente — rendicontazione condivisa tra Service Manager e Team Leader.
• Verbale di governance — riservato al Service Manager.

Con ordine del giorno, minuta, action item e decision log. Le riunioni di governance smettono di vivere in file Word sparsi e diventano parte del sistema.

Editor di un SAL: ordine del giorno, minuta, action log e decision log

Matrice RACI

Una matrice RACI interattiva che incrocia funzioni con servizi, sottoprocessi e task, con assegnazioni di governance (Service Manager, Technical Service Manager, Project Manager, operatore) e import/export. Finalmente chi fa cosa è esplicito e tracciato.

Matrice RACI interattiva: funzioni, servizi, task e assegnazioni, con import/export

Contatti e anagrafiche

L’anagrafe completa del rapporto: contatti del cliente, aziende stakeholder, prodotti/applicazioni, staff interno, gruppi di team e code TK — con un workflow per le richieste di modifica.

Documentazione

Un repository documentale per ciascun cliente (upload/download): contratti, allegati tecnici, documentazione di progetto, sempre nel contesto del cliente giusto.

Offerte & Preventivi

Il modulo per creare e gestire quote per cliente: figure professionali, listini, regole di margine, righe d’offerta ed export in Word/PDF. Con una macchina a stati (bozza → inviata → ordine), audit e revisioni. La parte commerciale e quella operativa vivono nello stesso sistema.

Offerte & Preventivi: elenco delle quote per cliente con stato, categoria e scadenza

In altre parole: tutta la governance cliente-centrica è già nella Community. Contratti, SAL, RACI, anagrafiche e offerte non sono funzioni premium — sono parte dell’impianto base.

Il CRM interno: ciò che sblocca la Enterprise Edition

Qui cambia la prospettiva. Mentre Orbit guarda al cliente, il Gestionale interno (la terza area, riservata all’MSP) guarda dentro l’organizzazione: i documenti da firmare, i beni aziendali, le risorse interne. E questa console è disponibile solo nelle immagini Enterprise — nella Community il codice non è proprio presente.

È, di fatto, il vero motivo per cui molti MSP passano alla Enterprise.

Firma digitale (FEA)

Preparazione della firma elettronica avanzata su documenti PDF o template: la richiesta di firma viene inviata ai destinatari, con OTP, tracciamento dello stato, invio e download del documento firmato. Sotto il cofano: conservazione a 10 anni e crypto-shredding (la chiave di cifratura del documento viene distrutta in caso di cancellazione GDPR).

Console Firme documenti: documenti firmabili dell’MSP via FEA con email + OTP

Repository documenti interno

Una libreria interna all’MSP per template e documenti standard: cartelle, upload e download, separata dalla documentazione cliente di Orbit.

Magazzino cespiti

L’inventario dei beni aziendali: categorie, articoli con due modelli di tracciamento — serializzato (seriale, IMEI, MAC, barcode, numero interno) o a quantità (consumabili) — con giacenze e movimenti append-only (carico, scarico, rettifica).

Magazzino cespiti: categorie, articoli serializzati e a quantità, con conteggio assegnati

Assegnazione materiale

Il tracciamento dell’assegnazione e della restituzione di un bene a un dipendente, con ricevuta digitale firmabile. Il magazzino e la firma si parlano: assegni il portatile dal bene stesso e generi automaticamente la ricevuta da far firmare.

Assegnazioni materiale: cespiti assegnati ai dipendenti con ricevuta firmata (FEA)

Firma documenti massiva

Le campagne di firma massiva: lo stesso documento a più firmatari, con solleciti manuali, tracking dello stato di firma ed export CSV per la compliance. Utile per policy aziendali, informative, accettazioni da raccogliere da tutto lo staff.

Firma documenti massiva: lo stesso documento a più firmatari, con tracking dello stato

Orbit + CRM: il confronto Community vs Enterprise

| Funzionalità | Componente | Community | Enterprise |
|—|—|:—:|:—:|
| Home MSP + dashboard cliente | Orbit | | |
| Contratto & SLA (vista governance) | Orbit | | |
| SAL / Verbali (cliente + governance) | Orbit | | |
| Matrice RACI interattiva | Orbit | | |
| Contatti / anagrafiche cliente | Orbit | | |
| Documentazione cliente | Orbit | | |
| Offerte & Preventivi (con margine, export Word/PDF) | Orbit | | |
| Firma digitale (FEA) | CRM interno | — | |
| Repository documenti interno | CRM interno | — | |
| Magazzino cespiti | CRM interno | — | |
| Assegnazione materiale (ricevuta firmata) | CRM interno | — | |
| Firma documenti massiva | CRM interno | — | |

Dettaglio tier: firma digitale, magazzino e assegnazioni richiedono il tier Professional con l’add-on Workforce & Signature; la firma massiva è Enterprise. In entrambi i casi servono le immagini Enterprise — nella Community questa console non esiste.

Come funziona la licenza Enterprise

Il modello di licenza di Meridian ARC è pensato anche per ambienti regolati, ed è il motivo per cui sblocca queste funzioni in modo netto.

1. Stesso codice, immagini diverse
La Community **non contiene** il codice del CRM interno: non è una funzione spenta da un flag, è proprio un’immagine Docker diversa. Le variabili d’ambiente, da sole, non sbloccano nulla.

2. Licenza verificata offline
L’attivazione usa una chiave Ed25519 validata localmente. L’istanza non deve “chiamare casa”: funziona on-premise e in ambienti air-gapped, senza dipendere da un server di attivazione e senza lock-in.

3. Professional ed Enterprise sono due tier
La license key decide quali feature e add-on sono attivi. Per il CRM interno: l’add-on Workforce & Signature abilita firma digitale, magazzino e assegnazioni; la firma massiva richiede il tier Enterprise.

4. Upgrade senza reinstallare
Si parte dalla Community, si puntano le immagini Enterprise e si applica la licenza da Admin → Licenza & Edizione. Dati, OAuth e configurazione restano identici: nessuna migrazione, nessun fermo del servizio.

Attivazione in 3 passi

1. Parliamone — esigenze, clienti gestiti, volumi, integrazioni.
2. Accesso e licenza — token di sola lettura al registry privato + file azienda.license.key firmato.
3. Attivazione — docker login, si puntano le immagini Enterprise nello stesso stack, si applica la licenza dal pannello Admin.

Admin → Licenza & Edizione: stato della licenza, edizione e feature/add-on attivi

In conclusione

Meridian ARC separa con chiarezza tre piani di lavoro: il ticket (il Service Desk), la governance del cliente (Orbit) e la macchina interna dell’MSP (il CRM).

Orbit — contratti, SAL, RACI, anagrafiche, offerte — è già tutto nella Community: la governance non è un lusso da pagare. La Enterprise sblocca invece la console interna, dove la firma digitale, il magazzino cespiti, le assegnazioni con ricevuta firmata e la firma massiva automatizzano e mettono a norma i processi interni di chi gestisce davvero molte persone e molti beni.

Se il tuo MSP è cresciuto al punto da dover firmare documenti in modo strutturato, tracciare i cespiti aziendali e raccogliere firme da tutto lo staff, il CRM interno della Enterprise è esattamente il pezzo che ti manca.

Trovi tutti i dettagli su Orbit, il CRM interno e le condizioni Enterprise su meridian-arc.io

Monitorare un’infrastruttura Linux senza ricevere notifiche è un po’ come guidare di notte senza luci: tutto sembra tranquillo finché non lo è più.

PatchMon v2 risolve questo problema mettendo a disposizione un sistema di notifiche flessibile e ben strutturato che permette di ricevere alert in tempo reale e report periodici direttamente nella propria casella di posta.

In questa guida vedremo come configurare una destinazione SMTP all’interno dell’interfaccia di PatchMon v2 come definire le regole di routing degli alert verso quella destinazione e come impostare report email programmati giornalieri, settimanali o mensili con le sezioni più utili per tenere sempre sotto controllo lo stato del parco macchine.

La configurazione si gestisce interamente dalla UI web, senza toccare file di configurazione a mano: bastano pochi minuti per iniziare a ricevere le prime notifiche.

PREREQUISITI

PatchMon v2 installato

Installazione e Configurazione Base di PatchMon v2 su Ubuntu Server 26.04

La configurazione si divide in 3 fasi: configurare la destinazione SMTP, creare le regole di routing degli alert e impostare i report programmati.

FASE 1 – AGGIUNTA DELLA DESTINAZIONE SMTP

In PatchMon v2 le destinazioni (SMTP, webhook, ntfy) si gestiscono da Reporting → scheda Destinations.

Apri la UI web di PatchMon quindi cliccare su Reporting nel menu laterale

Clicca sulla scheda Destinations

Clicca Add Destination

Selezionare SMTP Delivery quindi Next

Inserire tutti i dati relativi al server SMTP quindi cliccare Create

NOTA BENE: in v2.0.2 è stato corretto un bug per cui l’opzione Use TLS non veniva rispettata. Assicurati di essere aggiornato almeno a quella versione.

Se è tutto corretto dovremmo vedere la Destination creata come nella figura sovrastante

Cliccare Test per verificare che le mail arrivino

Aprire la mail e verificare di aver ricevuto un messaggio come quello sovrastante

FASE 2 – CREAZIONE DELLE EVENT RULES (ROUTING DEGLI ALERT)

Le Event Rules per instradare gli alert verso le destinazioni si trovano in Reporting → scheda Event Rules.

Andare su Reporting quindi selezionare Event Rules

Cliccare Add Event Rule

In questa schermata selezionare

• Destination: inserire la destinazione SMTP creata nella Fase 1
• Events: selezionare gli eventi che devono scatenare l’alert
• Minimum Severity: si può scegliere tra Informational, Warning, Error e Critical
• Host Group: selezionare gli host group a cui applicare la regola

Cliccare Add

Dovremmo visualizzare in questa schermata tutte le Rules create

FASE 3 — CONFIGURAZIONE DEI REPORT PROGRAMMATI

Le Schedulazioni le troviamo in Reporting → scheda Scheduled Reports

Cliccare su Scheduled Reports

Cliccare su New Report

Le opzioni disponibili configurabili sono:

• Report Name: Nome del Report
• Schedule: daily, weekdays, weekly (scegli i giorni) o monthly
• Deliver to: spunta la tua destinazione email creata in precedenza
• Delivery time: ora e minuto nel timezone del server
• Sections: scegli cosa includere nel report — open alerts, host con aggiornamenti pendenti, top security packages, stato compliance, ecc.
• Scope to host Groups: selezionare i gruppi a cui applicare la schedulazione

Cliccare Create

Dovremmo visualizzare una schermata con la schedulazione creata

ATTENZIONE: PatchMon mantiene un Delivery Log con traccia completa di ogni notifica inviata: stato, errori e numero di tentativi.

E’ possibile consultarlo in Reporting per verificare che le email vengano consegnate correttamente.

In questo articolo vedremo come costruire un sistema completo di monitoraggio della salute dei dischi SSD e NVMe installati negli host VMware ESXi, utilizzando esclusivamente strumenti open source: pyVmomi per interfacciarsi con le API vSphere, Prometheus e Pushgateway per la raccolta e lo storage delle metriche, e Grafana per la visualizzazione e gli alert.

La soluzione non richiede l’installazione di agenti sugli host ESXi, non dipende da VIB di terze parti e funziona correttamente anche con il Secure Boot abilitato.

PREREQUISITI

Uno o più host VMware ESXi gestiti da vCenter
Un server Linux con Docker e Portainer già installati

Installazione e Configurazione di Portainer su Ubuntu Server 24.04

Grafana già installato e funzionante su Docker

Installazione e Configurazione base di Grafana su Ubuntu Server 24.04

Un’istanza Gitea per il versioning dei file di configurazione

Installazione e Configurazione Base di Gitea su Ubuntu Server 24.04

Accesso amministrativo a vCenter per la creazione di un utente dedicato

ARCHITETTURA

Host ESXi 1 ──┐
Host ESXi 2 ──┤──→ vCenter API ──→ smart-exporter ──→ Pushgateway ──→ Prometheus ──→ Grafana
Host ESXi 3 ──┘ (Python/pyVmomi)

└──────────── Stack Docker ────────────┘

Lo smart-exporter è un container Python che si connette a vCenter tramite le API vSphere, itera su tutti gli host registrati, legge lo stato operativo dei dischi e pubblica le metriche sul Pushgateway. Prometheus scrape il Pushgateway periodicamente e Grafana visualizza i dati.

FASE 1 — CREAZIONE DI UN UTENTE DEDICATO SUL VCENTER

Per motivi di sicurezza è consigliabile non usare l’utente amministratore per il monitoraggio. Creare quindi un utente read-only dedicato.

Accedere a vCenter e andare su:

Administration → Single Sign-On → Users and Groups → Add

Compilare i campi:

Username: monitoring-smart
Password: scegli una password sicura

Assegnare il ruolo:

Administration → Access Control → Global Permissions

Assegnare il ruolo Read-Only all’utente monitoring-smart

Spuntare Applica a tutti gli oggetti figli

FASE 2 – STRUTTURA DEL REPOSITORY DI GITEA

Creare un nuovo repository su Gitea chiamato esxi-smart-monitoring con la seguente struttura:

esxi-smart-monitoring/
├── .gitignore
├── docker-compose.yml
└── exporter/
├── Dockerfile
├── requirements.txt
└── smart_exporter.py

FASE 3 — CREAZIONE DEI FILE DI CONFIGURAZIONE

Di seguito il contenuto del file .gitignore:

ssh_key/

Di seguito il contenuto del file exporter/requirements.txt

pyVmomi==8.0.3.0.1
prometheus-client==0.20.0
schedule==1.2.1
urllib3==2.2.1

Adesso creare lo script si connette a vCenter tramite pyVmomi, itera su tutti gli host ESXi registrati e per ogni host legge lo stato operativo dei dischi locali. Le metriche vengono pubblicate sul Pushgateway in formato Prometheus.

Di seguito il contenuto del file exporter/smart_exporter.py:

python#!/usr/bin/env python3

import os
import ssl
import time
import schedule
import logging
from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
from prometheus_client import Gauge, push_to_gateway, CollectorRegistry

logging.basicConfig(
level=logging.INFO,
format='%(asctime)s %(levelname)s %(message)s'
)
log = logging.getLogger(__name__)

VCENTER_HOST = os.environ.get('VCENTER_HOST')
VCENTER_USER = os.environ.get('VCENTER_USER')
VCENTER_PASSWORD = os.environ.get('VCENTER_PASSWORD')
VCENTER_PORT = int(os.environ.get('VCENTER_PORT', 443))
VERIFY_SSL = os.environ.get('VCENTER_SSL', 'false').lower() == 'true'
PUSHGATEWAY_URL = os.environ.get('PUSHGATEWAY_URL', 'http://pushgateway:9091')
INTERVAL_MINUTES = int(os.environ.get('INTERVAL_MINUTES', 5))


def get_vcenter_connection():
if not VERIFY_SSL:
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE
else:
context = ssl.create_default_context()

return SmartConnect(
host=VCENTER_HOST,
user=VCENTER_USER,
pwd=VCENTER_PASSWORD,
port=VCENTER_PORT,
sslContext=context
)


def get_all_hosts(content):
container = content.viewManager.CreateContainerView(
content.rootFolder,
[vim.HostSystem],
recursive=True
)
hosts = list(container.view)
container.Destroy()
return hosts


def collect_smart_metrics():
log.info("Starting SMART collection cycle")

try:
si = get_vcenter_connection()
content = si.RetrieveContent()
hosts = get_all_hosts(content)
log.info(f"Found {len(hosts)} ESXi hosts")

for host in hosts:
host_name = host.name
log.info(f"Processing host: {host_name}")

try:
storage_system = host.configManager.storageSystem
devices = storage_system.storageDeviceInfo.scsiLun

registry = CollectorRegistry()

smart_health = Gauge(
'esxi_smart_health',
'SMART health status (1=OK, 0=FAIL)',
['host', 'device', 'device_name'],
registry=registry
)
device_is_ssd = Gauge(
'esxi_device_is_ssd',
'Whether the device is an SSD (1=SSD, 0=HDD)',
['host', 'device', 'device_name'],
registry=registry
)

for device in devices:
dev_id = device.canonicalName if hasattr(device, 'canonicalName') else device.uuid
dev_name = device.displayName if hasattr(device, 'displayName') else dev_id

log.info(f" Device: {dev_name} ({dev_id})")

# Rileva se SSD
is_ssd = getattr(device, 'ssd', False)
device_is_ssd.labels(
host=host_name,
device=dev_id,
device_name=dev_name
).set(1 if is_ssd else 0)

# Leggi stato operativo
try:
op_state = getattr(device, 'operationalState', [])
health_ok = 1
if op_state:
for state in op_state:
if 'degraded' in str(state).lower() or \
'error' in str(state).lower():
health_ok = 0
break

smart_health.labels(
host=host_name,
device=dev_id,
device_name=dev_name
).set(health_ok)
log.info(f" Health: {'OK' if health_ok else 'FAIL'}")

except Exception as e:
log.warning(f" Could not get health for {dev_id}: {e}")
continue

push_to_gateway(
PUSHGATEWAY_URL,
job='esxi_smart',
grouping_key={'host': host_name},
registry=registry
)
log.info(f" → Pushed metrics for host {host_name}")

except Exception as e:
log.error(f"Error processing host {host_name}: {e}")
continue

Disconnect(si)
log.info("Collection cycle completed")

except Exception as e:
log.error(f"Failed to connect to vCenter: {e}")


if __name__ == '__main__':
log.info(f"Starting ESXi SMART exporter, interval: {INTERVAL_MINUTES} min")
log.info(f"vCenter: {VCENTER_HOST}, Pushgateway: {PUSHGATEWAY_URL}")

collect_smart_metrics()

schedule.every(INTERVAL_MINUTES).minutes.do(collect_smart_metrics)

while True:
schedule.run_pending()
time.sleep(30)

Di seguito il contenuto del file exporter/Dockerfile:

dockerfileFROM python:3.12-slim

WORKDIR /app

COPY requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

COPY smart_exporter.py /app/smart_exporter.py

CMD ["python", "-u", "/app/smart_exporter.py"]

La configurazione vCenter viene passata tramite variabili d’ambiente, evitando così problemi di bind mount. La configurazione di Prometheus viene iniettata tramite Docker configs, una funzionalità nativa di Docker Compose che non richiede file sul disco dell’host.

Di seguito il contenuto del file docker-compose.yml:

yamlversion: '3.8'

services:

pushgateway:
image: prom/pushgateway:latest
container_name: pushgateway
restart: unless-stopped
ports:
- "9091:9091"
networks:
- esxi_monitoring

prometheus:
image: prom/prometheus:latest
container_name: prometheus
restart: unless-stopped
ports:
- "9090:9090"
volumes:
- prometheus_data:/prometheus
configs:
- source: prometheus_config
target: /etc/prometheus/prometheus.yml
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d'
networks:
- esxi_monitoring

smart-exporter:
build: ./exporter
container_name: smart-exporter
restart: unless-stopped
environment:
- VCENTER_HOST=vcenter.dominio.local
- VCENTER_USER=monitoring-smart@dominio.local
- VCENTER_PASSWORD=la-tua-password
- VCENTER_PORT=443
- VCENTER_SSL=false
- PUSHGATEWAY_URL=http://pushgateway:9091
- INTERVAL_MINUTES=5
depends_on:
- pushgateway
networks:
- esxi_monitoring

configs:
prometheus_config:
content: |
global:
scrape_interval: 60s
evaluation_interval: 60s

scrape_configs:
- job_name: 'pushgateway'
honor_labels: true
static_configs:
- targets: ['pushgateway:9091']

volumes:
prometheus_data:

networks:
esxi_monitoring:
driver: bridge

NOTA BENE: sostituire le variabili VCENTER_HOST, VCENTER_USER e VCENTER_PASSWORD con i valori reali del tuo ambiente.

FASE 4 — COLLEGARE GRAFANA ALLA NETWORK DI PROMETHEUS

Poiché Grafana è già installato in uno stack Docker separato, dobbiamo collegarla alla network esxi_monitoring affinché possa raggiungere Prometheus per nome container.

Eseguire il comando:

docker network connect <nome_stack>_esxi_monitoring grafana

Verificare che la connessione funzioni con il comando:

docker exec -it grafana wget -qO- http://prometheus:9090/-/healthy

Se è tutto OK la risposta dovrebbe essere:

Prometheus Server is Healthy.

NOTA BENE: questa connessione va persa al riavvio del container. Per renderla permanente aggiungi la network esxi_monitoring come esterna nel docker-compose.yml dello stack Grafana.

FASE 5 — DEPLOY SU PORTAINER

Su Portainer creare un nuovo stack collegato al repository Gitea:

Stacks → Add stack → Repository

Repository URL: http://<IP_GITEA>/<utente>/esxi-smart-monitoring

Compose path: docker-compose.yml

Cliccare Deploy the stack

Verificare che tutti i container siano in stato Running con il comando:

docker ps --format "table {{.Names}}\t{{.Status}}" | grep -E "prometheus|smart|pushgateway"

Dovremmo visualizzare un output simile al seguente:

smart-exporter Up 1 days
prometheus Up 1 days
pushgateway Up 1 days

Controllare i log dello smart-exporter per verificare la connessione a vCenter con il comando:

docker logs smart-exporter --tail 30

L’output atteso dovrebbe essere simile al seguente:

2026-01-01 10:00:00,000 INFO Starting ESXi SMART exporter, interval: 5 min
2026-01-01 10:00:00,000 INFO vCenter: vcenter.dominio.local, Pushgateway: http://pushgateway:9091
2026-01-01 10:00:00,000 INFO Starting SMART collection cycle
2026-01-01 10:00:00,000 INFO Found 4 ESXi hosts
2026-01-01 10:00:00,000 INFO Processing host: esxi01.dominio.local
2026-01-01 10:00:00,000 INFO Device: Local NVMe Disk (...) (...)
2026-01-01 10:00:00,000 INFO Health: OK
2026-01-01 10:00:00,000 INFO → Pushed metrics for host esxi01.dominio.local
2026-01-01 10:00:00,000 INFO Collection cycle completed

FASE 6 – CONFIGURAZIONE DELLE DASHBOARD SU GRAFANA

Di seguito i vari step da seguire per la realizzazione della Dashboard.

STEP 1 — VERIFICA DEL DATASCOURCE DI PROMETHEUS

Aprire Grafana nel browser
Nel menu a sinistra cliccare Connections (icona a forma di fulmine)
Cliccare Data sources
Cercare Prometheus nella lista e cliccrci sopra

Verificare che l’URL sia http://prometheus:9090

Scorrere in fondo alla pagina e cliccare Save & Test

Dovrebbe apparire il banner verde Successfully queried the Prometheus API

STEP 2 — CREARE UNA NUOVA DASHBOARD

Adesso procedere con la creazione della Dashboard

Nel menu a sinistra cliccare Dashboards quindi cliccare il pulsante blu Create Dashboard

Cliccare Add visualization

Selezionare il datasource Prometheus

STEP 3 — PANNELLO 1: HEALTH STATUS

Si apre l’editor del pannello. Procedere così:

Tipo grafico (in alto a destra):

Cambiare da Time series a Stat come nell’immagine sovrastante

Impostare la Query (in basso):

Nel campo query selezionare la voce: esxi_smart_health

Cliccare Run queries

Dovresti vedere dei valori 0 o 1 apparire nell’anteprima.

Inserire il Titolo nella colonna destra nel campo Title:

Health Status Dischi

Nella colonna destra scorrere fino a Value mappings quindi cliccare su Add value mapping

Tipo: Value

Value: 1 → Display text: OK → Color: Verde

Clicca Add value mapping di nuovo

Value: 0 → Display text: FAIL → Color: Rosso

Cliccare Update

Se è tutto corretto dovremmo vedere una schermata come quella sovrastante

Adesso andare al fondo della colonna destra fino a Thresholds

Impostare:

Base → Rosso

Aggiungi soglia: 1 → Verde

Individuare le Standard options:

Impostare nelle Standard options → Display name (colonna destra) il seguente valore:

${__series.labels.device_name} – ${__series.labels.host}

Cliccare in alto a destra Save Dashboard

Inserire il titolo quindi cliccare Save

STEP 4 — PANNELLO 2: INVENTARIO DISCHI

Tornare alla dashboard e cliccare Add → Visualization.

Tipo grafico: Cambiare a Table

Query: esxi_device_is_ssd

Cliccare Run queries

Titolo: Inventario Dischi

Cliccare sul tab Transformations in basso accanto a Queries:

Clicca Add transformation

Scegliere Labels to fields

Apparirà una colonna per ogni label: host, device, device_name

Nella lista dei campi tenere: host, device_name, device

Clicca Add transformation → cerca Organize fields

Nascondere: Time, __name__, job, instance

Quindi rinominare:

host → Host
device_name → Disco
device → Device ID
Value #A → Health
Value #B → Tipo

Cliccare Apply

STEP 5 — PANNELLO 2: CONTEGGIO DISCHI OK PER HOST

Cliccare Add → Visualization

Impostare il tipo grafico in: Stat

Query: count by (host) (esxi_smart_health == 1)

Titolo: Dischi OK per host

In Standard options → Unit impostare: short

In Standard options → Display name: ${__series.labels.host}

In Thresholds impostare: Base → Verde (tutti OK è buono)

Cliccare Apply

STEP 6 — SALVATAGGIO DELLA DASHBOARD

Cliccare l’icona salva in alto a destra (o Ctrl+S)

Nome dashboard: ESXi Disk Health

Folder: puoi lasciare General

Cliccare Save

Al termine dopo varie implementazioni dovremmo visualizzare la nostra Dashoboard

FASE 7 – JSON DASHBOARD

Di seguito il codice Json pronto per avere la Dashboard pronta:

{
"__inputs": [
{
"name": "DS_PROMETHEUS",
"label": "Prometheus",
"description": "",
"type": "datasource",
"pluginId": "prometheus",
"pluginName": "Prometheus"
}
],
"__elements": {},
"__requires": [
{ "type": "grafana", "id": "grafana", "name": "Grafana", "version": "10.0.0" },
{ "type": "datasource", "id": "prometheus", "name": "Prometheus", "version": "1.0.0" },
{ "type": "panel", "id": "stat", "name": "Stat", "version": "" },
{ "type": "panel", "id": "table", "name": "Table", "version": "" },
{ "type": "panel", "id": "gauge", "name": "Gauge", "version": "" },
{ "type": "panel", "id": "piechart", "name": "Pie chart", "version": "" },
{ "type": "panel", "id": "timeseries","name": "Time series","version": "" }
],
"annotations": {
"list": [
{
"builtIn": 1,
"datasource": { "type": "grafana", "uid": "-- Grafana --" },
"enable": true,
"hide": true,
"iconColor": "rgba(0, 211, 255, 1)",
"name": "Annotations & Alerts",
"type": "dashboard"
}
]
},
"description": "Monitoraggio salute dischi SSD e NVMe su host VMware ESXi tramite pyVmomi e Prometheus",
"editable": true,
"fiscalYearStartMonth": 0,
"graphTooltip": 1,
"id": null,
"links": [],
"panels": [

{
"collapsed": false,
"gridPos": { "h": 1, "w": 24, "x": 0, "y": 0 },
"id": 100,
"title": " Riepilogo Generale",
"type": "row"
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "blue", "value": null }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 4, "w": 4, "x": 0, "y": 1 },
"id": 1,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "auto"
},
"title": "Dischi Totali",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count(esxi_smart_health)", "instant": true, "legendFormat": "Totale", "refId": "A"
}]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 4, "w": 4, "x": 4, "y": 1 },
"id": 2,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "auto"
},
"title": "Dischi OK",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count(esxi_smart_health == 1)", "instant": true, "legendFormat": "OK", "refId": "A"
}]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }, { "color": "red", "value": 1 }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 4, "w": 4, "x": 8, "y": 1 },
"id": 3,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "auto"
},
"title": "Dischi FAIL",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count(esxi_smart_health == 0) or vector(0)", "instant": true, "legendFormat": "FAIL", "refId": "A"
}]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "blue", "value": null }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 4, "w": 4, "x": 12, "y": 1 },
"id": 4,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "auto"
},
"title": "Host Monitorati",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count(count by (host) (esxi_smart_health))", "instant": true, "legendFormat": "Host", "refId": "A"
}]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "blue", "value": null }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 4, "w": 4, "x": 16, "y": 1 },
"id": 5,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "auto"
},
"title": "SSD/NVMe",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count(esxi_device_is_ssd == 1)", "instant": true, "legendFormat": "SSD/NVMe", "refId": "A"
}]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "grey", "value": null }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 4, "w": 4, "x": 20, "y": 1 },
"id": 6,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "auto"
},
"title": "HDD",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count(esxi_device_is_ssd == 0) or vector(0)", "instant": true, "legendFormat": "HDD", "refId": "A"
}]
},

{
"collapsed": false,
"gridPos": { "h": 1, "w": 24, "x": 0, "y": 5 },
"id": 101,
"title": " Health Status per Host",
"type": "row"
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [
{ "options": { "0": { "color": "red", "index": 1, "text": "FAIL" }, "1": { "color": "green", "index": 0, "text": "OK" } }, "type": "value" }
],
"thresholds": { "mode": "absolute", "steps": [{ "color": "red", "value": null }, { "color": "green", "value": 1 }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 6, "w": 24, "x": 0, "y": 6 },
"id": 10,
"options": {
"colorMode": "background", "graphMode": "none", "justifyMode": "center",
"orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"textMode": "value_and_name"
},
"title": "Health Status Dischi — Tutti gli Host",
"type": "stat",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "esxi_smart_health{host=~\"$host\"}",
"instant": true,
"legendFormat": "{{device_name}} | {{host}}",
"refId": "A"
}]
},

{
"collapsed": false,
"gridPos": { "h": 1, "w": 24, "x": 0, "y": 12 },
"id": 102,
"title": " Inventario Dischi",
"type": "row"
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"custom": {
"align": "left",
"cellOptions": { "type": "auto" },
"filterable": true,
"inspect": false
},
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }] }
},
"overrides": [
{
"matcher": { "id": "byName", "options": "Value" },
"properties": [
{ "id": "displayName", "value": "Health" },
{
"id": "mappings",
"value": [
{ "options": { "1": { "color": "green", "index": 0, "text": " OK" },
"0": { "color": "red", "index": 1, "text": " FAIL" } }, "type": "value" }
]
},
{ "id": "custom.cellOptions", "value": { "type": "color-background" } },
{ "id": "custom.width", "value": 120 }
]
},
{
"matcher": { "id": "byName", "options": "host" },
"properties": [
{ "id": "displayName", "value": "Host" },
{ "id": "custom.width", "value": 220 }
]
},
{
"matcher": { "id": "byName", "options": "device_name" },
"properties": [
{ "id": "displayName", "value": "Disco" },
{ "id": "custom.width", "value": 260 }
]
},
{
"matcher": { "id": "byName", "options": "device" },
"properties": [
{ "id": "displayName", "value": "Device ID" },
{ "id": "custom.width", "value": 420 }
]
},
{
"matcher": { "id": "byName", "options": "Time" },
"properties": [{ "id": "custom.hidden", "value": true }]
}
]
},
"gridPos": { "h": 10, "w": 12, "x": 0, "y": 13 },
"id": 20,
"options": {
"cellHeight": "sm",
"footer": { "countRows": false, "fields": "", "reducer": ["sum"], "show": false },
"showHeader": true,
"sortBy": [{ "desc": false, "displayName": "Host" }]
},
"title": "Health Status Dischi",
"transformations": [
{
"id": "labelsToFields",
"options": { "mode": "columns", "keepLabels": ["host", "device_name", "device"] }
},
{
"id": "organize",
"options": {
"excludeByName": { "Time": true, "__name__": true, "job": true, "instance": true },
"indexByName": { "host": 0, "device_name": 1, "device": 2, "Value": 3 },
"renameByName": {}
}
}
],
"type": "table",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "esxi_smart_health{host=~\"$host\"}",
"instant": true,
"legendFormat": "",
"refId": "A",
"format": "table"
}]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"custom": {
"align": "left",
"cellOptions": { "type": "auto" },
"filterable": true,
"inspect": false
},
"mappings": [],
"thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }] }
},
"overrides": [
{
"matcher": { "id": "byName", "options": "Value" },
"properties": [
{ "id": "displayName", "value": "Tipo" },
{
"id": "mappings",
"value": [
{ "options": { "1": { "color": "blue", "index": 0, "text": " SSD/NVMe" },
"0": { "color": "grey", "index": 1, "text": " HDD" } }, "type": "value" }
]
},
{ "id": "custom.cellOptions", "value": { "type": "color-background" } },
{ "id": "custom.width", "value": 140 }
]
},
{
"matcher": { "id": "byName", "options": "host" },
"properties": [
{ "id": "displayName", "value": "Host" },
{ "id": "custom.width", "value": 220 }
]
},
{
"matcher": { "id": "byName", "options": "device_name" },
"properties": [
{ "id": "displayName", "value": "Disco" },
{ "id": "custom.width", "value": 260 }
]
},
{
"matcher": { "id": "byName", "options": "device" },
"properties": [
{ "id": "displayName", "value": "Device ID" },
{ "id": "custom.width", "value": 420 }
]
},
{
"matcher": { "id": "byName", "options": "Time" },
"properties": [{ "id": "custom.hidden", "value": true }]
}
]
},
"gridPos": { "h": 10, "w": 12, "x": 12, "y": 13 },
"id": 21,
"options": {
"cellHeight": "sm",
"footer": { "countRows": false, "fields": "", "reducer": ["sum"], "show": false },
"showHeader": true,
"sortBy": [{ "desc": false, "displayName": "Host" }]
},
"title": "Tipo Disco (SSD/NVMe vs HDD)",
"transformations": [
{
"id": "labelsToFields",
"options": { "mode": "columns", "keepLabels": ["host", "device_name", "device"] }
},
{
"id": "organize",
"options": {
"excludeByName": { "Time": true, "__name__": true, "job": true, "instance": true },
"indexByName": { "host": 0, "device_name": 1, "device": 2, "Value": 3 },
"renameByName": {}
}
}
],
"type": "table",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "esxi_device_is_ssd{host=~\"$host\"}",
"instant": true,
"legendFormat": "",
"refId": "A",
"format": "table"
}]
},

{
"collapsed": false,
"gridPos": { "h": 1, "w": 24, "x": 0, "y": 23 },
"id": 103,
"title": " Distribuzione e Statistiche",
"type": "row"
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "palette-classic" },
"custom": { "hideFrom": { "legend": false, "tooltip": false, "viz": false } },
"mappings": []
},
"overrides": [
{ "matcher": { "id": "byName", "options": "OK" }, "properties": [{ "id": "color", "value": { "fixedColor": "green", "mode": "fixed" } }] },
{ "matcher": { "id": "byName", "options": "FAIL" }, "properties": [{ "id": "color", "value": { "fixedColor": "red", "mode": "fixed" } }] }
]
},
"gridPos": { "h": 8, "w": 8, "x": 0, "y": 24 },
"id": 30,
"options": {
"legend": { "displayMode": "table", "placement": "right", "showLegend": true, "values": ["value", "percent"] },
"pieType": "pie",
"tooltip": { "mode": "single", "sort": "none" }
},
"title": "Distribuzione Health Status",
"type": "piechart",
"targets": [
{ "datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" }, "expr": "count(esxi_smart_health == 1)", "instant": true, "legendFormat": "OK", "refId": "A" },
{ "datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" }, "expr": "count(esxi_smart_health == 0) or vector(0)", "instant": true, "legendFormat": "FAIL", "refId": "B" }
]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "palette-classic" },
"custom": { "hideFrom": { "legend": false, "tooltip": false, "viz": false } },
"mappings": []
},
"overrides": [
{ "matcher": { "id": "byName", "options": "SSD/NVMe" }, "properties": [{ "id": "color", "value": { "fixedColor": "blue", "mode": "fixed" } }] },
{ "matcher": { "id": "byName", "options": "HDD" }, "properties": [{ "id": "color", "value": { "fixedColor": "grey", "mode": "fixed" } }] }
]
},
"gridPos": { "h": 8, "w": 8, "x": 8, "y": 24 },
"id": 31,
"options": {
"legend": { "displayMode": "table", "placement": "right", "showLegend": true, "values": ["value", "percent"] },
"pieType": "donut",
"tooltip": { "mode": "single", "sort": "none" }
},
"title": "Distribuzione Tipo Disco",
"type": "piechart",
"targets": [
{ "datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" }, "expr": "count(esxi_device_is_ssd == 1)", "instant": true, "legendFormat": "SSD/NVMe", "refId": "A" },
{ "datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" }, "expr": "count(esxi_device_is_ssd == 0) or vector(0)", "instant": true, "legendFormat": "HDD", "refId": "B" }
]
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "thresholds" },
"mappings": [],
"max": 4, "min": 0,
"thresholds": { "mode": "absolute", "steps": [{ "color": "red", "value": null }, { "color": "yellow", "value": 1 }, { "color": "green", "value": 2 }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 8, "w": 8, "x": 16, "y": 24 },
"id": 32,
"options": {
"minVizHeight": 75, "minVizWidth": 75, "orientation": "auto",
"reduceOptions": { "calcs": ["lastNotNull"], "fields": "", "values": false },
"showThresholdLabels": false, "showThresholdMarkers": true
},
"title": "Dischi OK per Host",
"type": "gauge",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "count by (host) (esxi_smart_health{host=~\"$host\"} == 1)",
"instant": true, "legendFormat": "{{host}}", "refId": "A"
}]
},

{
"collapsed": false,
"gridPos": { "h": 1, "w": 24, "x": 0, "y": 32 },
"id": 104,
"title": " Storico Health Status",
"type": "row"
},

{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"fieldConfig": {
"defaults": {
"color": { "mode": "palette-classic" },
"custom": {
"axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto",
"barAlignment": 0, "drawStyle": "line", "fillOpacity": 10, "gradientMode": "none",
"hideFrom": { "legend": false, "tooltip": false, "viz": false },
"insertNulls": false, "lineInterpolation": "stepAfter", "lineWidth": 2,
"pointSize": 5, "scaleDistribution": { "type": "linear" },
"showPoints": "auto", "spanNulls": false,
"stacking": { "group": "A", "mode": "none" },
"thresholdsStyle": { "mode": "off" }
},
"mappings": [], "max": 1.1, "min": -0.1,
"thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }] },
"unit": "short"
},
"overrides": []
},
"gridPos": { "h": 8, "w": 24, "x": 0, "y": 33 },
"id": 40,
"options": {
"legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true },
"tooltip": { "mode": "multi", "sort": "none" }
},
"title": "Storico Health Status (1=OK, 0=FAIL)",
"type": "timeseries",
"targets": [{
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"expr": "esxi_smart_health{host=~\"$host\"}",
"legendFormat": "{{device_name}} | {{host}}", "refId": "A"
}]
}

],
"refresh": "5m",
"schemaVersion": 38,
"tags": ["esxi", "vmware", "disk", "smart", "storage"],
"templating": {
"list": [
{
"current": {},
"datasource": { "type": "prometheus", "uid": "${DS_PROMETHEUS}" },
"definition": "label_values(esxi_smart_health, host)",
"hide": 0,
"includeAll": true,
"multi": true,
"name": "host",
"options": [],
"query": { "query": "label_values(esxi_smart_health, host)", "refId": "StandardVariableQuery" },
"refresh": 2,
"regex": "",
"sort": 1,
"type": "query",
"label": "Host ESXi",
"allValue": ".*"
}
]
},
"time": { "from": "now-24h", "to": "now" },
"timepicker": {},
"timezone": "browser",
"title": "ESXi Disk Health Monitoring",
"uid": "esxi-disk-health-v2",
"version": 1,
"weekStart": ""
}

Meridian ARC ITSM: il Service Desk completo e cosa aggiunge la Enterprise Edition

Quando si parla di software ITSM (IT Service Management) la domanda ricorrente è sempre la stessa: cosa mi danno davvero gratis, e per cosa devo pagare?. Con la maggior parte dei prodotti la risposta è frustrante — la versione gratuita è una demo mutilata, pensata per farti sentire stretto entro la prima settimana.

Meridian ARC ribalta questo schema. La sua Community Edition è un Service Desk ITIL completo e pronto alla produzione: la Enterprise non sblocca le funzioni base aggiunge le funzioni che servono a chi del servizio IT fa il proprio business. In questo articolo vediamo tutte le funzionalità del modulo ITSM (il Desk) e, soprattutto, dove finisce la Community e dove inizia la Enterprise — con un occhio a come funziona concretamente la licenza EE.

Questo articolo è dedicato al solo modulo ITSM / Service Desk. Le aree Orbit (governance e contratti) e CRM interno hanno un articolo a parte.

Dashboard del Service Desk di Meridian ARC: ticket aperti, SLA, KPI in tempo reale, asset CMDB e ultimi incident

La base: un ciclo ITIL completo, già nella Community

Partiamo da un punto fermo, perché è il vero elemento differenziante. La Community Edition di Meridian ARC non è una versione di prova: copre l’intero ciclo di vita di un ticket secondo le pratiche ITIL, ed è pensata per girare in produzione, on-premise o in cloud privato, sui tuoi server.

Ecco cosa include — tutto gratuito e self-hosted.

Gestione ticket end-to-end

Il cuore del sistema. Cinque tipi di ticket nativi, ciascuno con il proprio flusso:

• Incident — gestione interruzioni e malfunzionamenti
• Problem — analisi delle cause (RCA con metodi *5 Whys* e *Ishikawa*), workaround, registrazione del *known error* e post-review.
• Change Request — con tipi (standard, normale, emergency, pre-autorizzato), finestra di deployment, test plan, piano di rollback e **workflow di approvazione** (interno, cliente o entrambi, anche tramite link pubblico per il cliente).
• Service Request — richieste di servizio.
• Security Incident — tipologia dedicata agli incidenti di sicurezza.

Gli stati del ticket sono strutturati (nuovo → preso in carico → in lavorazione → risolto → chiuso, più stati di attesa) e alcuni di essi sospendono automaticamente il contatore SLA.

Dettaglio di un ticket Incident con stato, priorità, badge SLA e cronologia

Change Management: stato di approvazione, finestra di deployment e calendario dei change

Code, priorità e categorie

• Code di supporto con SPOC (single point of contact), coda di default ed email di gruppo.
• Livelli di priorità personalizzabili per cliente (nome, colore, ordine).
• Categorie per tipo di ticket, con regole di approvazione configurabili.
• Orari di lavoro (business hours) per coda, con fuso orario — base di calcolo per gli SLA.

SLA inclusi

Configurazione delle metriche di servizio — *prima risposta*, *presa in carico*, *risoluzione* — per priorità, coda e tipo di ticket. Gli stati di attesa mettono in pausa il conteggio, così non vieni penalizzato per tempi che non dipendono da te.

Contratto & SLA del cliente: copertura, RPO/RTO, retention e livelli di priorità

CMDB e gestione asset

Un CMDB vero, non un elenco statico: Configuration Item per cliente, con numero auto-generato, hostname, IP/MAC, seriale, produttore, modello, date di acquisto, scadenza garanzia e fine vita. Le relazioni tra CI permettono di mappare le dipendenze, e l’anagrafica licenze software con alert di scadenza completa il quadro.

CMDB: l’inventario dei Configuration Item del cliente

Service Catalog, Knowledge Base e Task Flows

• Service Catalog con form dinamici: il cliente compila e la richiesta diventa un ticket.
• Knowledge Base con articoli pubblici e interni, versionamento e template; collegando un articolo a un ticket Problem si costruisce il KEDB (Known Error Database).
• Task Flows: una richiesta dal catalogo può generare più task ordinati, ciascuno assegnato a una coda diversa — flussi multi-stage anche paralleli.

Service Catalog: le voci di servizio con form dinamici

Automazioni, email e portale

• Motore di automazione** config-driven: trigger (ticket creato, cambio stato, assegnazione, commento, SLA violato), condizioni e azioni (imposta priorità, assegna, trasferisci coda, aggiungi commento). In Community è incluso con un tetto di **3 regole**.
• Email-to-Ticket (Mailgun/SMTP) con processamento inbound via webhook.
• Portale self-service per il cliente: apertura ticket, commenti, consultazione di KB e catalogo.
• CSAT: survey di soddisfazione dopo la risoluzione.
• RBAC, LDAP/Active Directory e SSO (OAuth 2.0) per autenticazione e controllo accessi.
• Allegati con scansione antivirus (ClamAV) ed email templates personalizzabili.

Knowledge Base: articoli pubblici e interni, pubblicabili nel portale self-service del cliente

Editor di una regola di automazione: trigger, condizioni e azioni

In sintesi: con la Community gestisci clienti reali, SLA, asset e tutto il ciclo operativo. Non è una demo

Cosa aggiunge la Enterprise Edition

La Enterprise entra in gioco quando il servizio diventa il business: gestisci SLA contrattuali con penali, vuoi misurare la marginalità di commessa e devi integrare l’ITSM con il resto dei tuoi sistemi. Ecco cosa si attiva.

Operazioni sotto pressione

• Major Incident con War Room — dichiarazione di incidente grave con *incident commander*, *communications officer*, collaborazione in war room e postmortem strutturato. Quando un disservizio diventa una crisi, hai un protocollo, non l’improvvisazione.
• OLA e gestione avanzata degli SLA — Operational Level Agreement con tracciamento degli handoff inter-team e target in minuti lavorativi; pause SLA legate ai contratti.
• Skill routing & supervisor — assegnazione basata sulle competenze degli agenti (con livello 1–5) e vista supervisore con la disponibilità del team.

Dashboard KPI & Performance: il polso operativo del servizio in tempo reale

Supervisor view: carico di lavoro in tempo reale e routing per competenze del team

Margine e controllo

• Costing & marginalità — figure professionali con costo giornaliero/orario; il tempo registrato sui ticket si trasforma in **costo e margine per cliente, in tempo reale**. Non a fine anno.
• Reporting esteso (tier Professional) — filtri salvati per entità, export massivo e *time tracking*.
• Forecasting — analisi di trend.

Marginalità di commessa: valore venduto, costo consuntivo e margine per cliente

Integrazioni e automazione (add-on *Integrations & API*)

• REST API versionata con Personal Access Token (abilities selettive: lettura/scrittura ticket, lettura CMDB e BI), rate limit per tier.
• Webhook in/out firmati HMAC-SHA256.
• Notifiche Slack/Teams, import asset massivo da CSV/JSON.
• Automazione avanzata (regole illimitate e logiche più ricche rispetto alle 3 della Community).

BI & Analytics (add-on)

Feed BI read-only per Power BI/Tableau, export avanzato (PDF/Excel formattati) e dashboard estese.

Omnichannel (add-on)

Chatbot sul portale per ricerca in KB e apertura ticket.

Workforce & Signature (add-on) + Firma massiva

• Firma digitale (FEA) con OTP, conservazione a 10 anni e crypto-shredding (cancellazione della chiave su richiesta GDPR).
• Magazzino cespiti — beni serializzati e consumabili, movimenti append-only.
• Assegnazione materiale al dipendente con ricevuta firmabile.
• Firma documenti massiva — lo stesso documento a più firmatari, con tracking dello stato (questa funzione è di tier Enterprise).

Nota: firma digitale, magazzino e assegnazioni sono disponibili dal tier Professional (con l’add-on Workforce & Signature); Major Incident, costing, skill routing, OLA e firma massiva sono Enterprise. Lo strumento di firma vive principalmente nella console interna, di cui parlo nell’articolo dedicato a Orbit + CRM.

Firma documenti massiva: campagne di firma dello stesso documento a più destinatari, con tracking dello stato

Community vs Enterprise: il confronto

| Funzionalità | Community | Enterprise |
|—|:—:|:—:|
| Incident / Problem / Change (con approvazione) | | |
| Service Request / Security Incident | | |
| Code, SPOC, priorità, categorie | | |
| SLA base + pause | | |
| CMDB + relazioni CI + licenze software | | |
| Service Catalog + form dinamici | | |
| Knowledge Base + KEDB | | |
| Task Flows | | |
| Automazioni | (max 3 regole) | (illimitate + avanzate) |
| Email-to-Ticket, Portale, CSAT, RBAC, LDAP/SSO | | |
| Major Incident / War Room | — | |
| OLA e SLA avanzati | — | |
| Skill routing & supervisor | — | |
| Costing & marginalità di commessa | — | |
| Reporting esteso + time tracking | — | (da Professional) |
| Forecasting | — | |
| REST API + token, webhook in/out | — | (add-on) |
| Slack/Teams, feed BI, import asset, chatbot | — | (add-on) |
| Firma digitale (FEA), magazzino, assegnazioni | — | (da Professional, add-on) |
| Firma documenti massiva | — | |

Limiti operativi per edizione

| Limite | Community | Professional | Enterprise |
|—|:—:|:—:|:—:|
| Agenti (seat) | 20 | illimitato | illimitato |
| Clienti gestiti | 3 | illimitato | illimitato |
| Regole di automazione | 3 | illimitato | illimitato |
| Retention audit | 90 giorni | 365 giorni | 36 mesi |
| Storage allegati | 5 GB | 10 GB/agente | 25 GB/agente |
| Rate limit API | nessuna API | 120 req/min | 600 req/min |

Come funziona la licenza Enterprise

Questa è la parte che rende Meridian ARC diverso da un classico SaaS — e che lo rende adatto ad ambienti regolati (bancario, sanitario, PA).

1. È lo stesso codice, ma immagini diverse.
Community ed Enterprise condividono lo stesso prodotto, ma la Community **non contiene affatto** il codice delle funzioni Enterprise: non è una versione depotenziata via flag, è proprio un’immagine Docker diversa. Le variabili d’ambiente, da sole, non bastano a sbloccare nulla.

2. La licenza è una chiave firmata, verificata offline.
L’attivazione avviene con una chiave **Ed25519** validata localmente: l’istanza **non deve “chiamare casa”**. Funziona in ambienti air-gapped, senza dipendere da un server di attivazione. Nessun lock-in.

3. Professional ed Enterprise sono due tier dello stesso impianto.
La *license key* determina quali feature e add-on sono attivi. La Professional copre il passo intermedio; l’Enterprise sblocca tutto. Non c’è un prodotto nuovo da imparare.

4. L’upgrade non richiede reinstallazione.
Si parte dalla Community, poi si punta alle immagini Enterprise e si applica la licenza da **Admin → Licenza & Edizione**. OAuth, configurazione .env e dati restano identici: nessuna migrazione, nessun fermo del servizio.

Attivazione in 3 passi

1. Parliamone — esigenze, clienti gestiti, volumi e integrazioni. Si valuta insieme il tier giusto.
2. Accesso e licenza — un token di sola lettura al registry privato delle immagini + il file azienda.license.key firmato.
3. Attivazione — un docker login al registry, si puntano le immagini Enterprise nello stesso stack e si applica la licenza dal pannello Admin.

Admin → Licenza & Edizione: stato della licenza e feature attive

In conclusione

La forza del modello di Meridian ARC sta in una promessa rispettata: la Community è davvero completa. Puoi gestire un help desk ITIL serio, con clienti, SLA, CMDB e automazioni, senza spendere un euro e senza che i tuoi dati lascino i tuoi server.

La Enterprise non ti vende ciò che dovrebbe essere gratis: ti vende ciò che serve quando il servizio cresce — gestione delle crisi, marginalità misurabile, integrazioni e firma digitale. E lo fa con un modello di licenza pulito, offline, senza lock-in.

Se gestisci servizi IT per più clienti e ti riconosci in almeno uno di questi tre segnali — eroghi SLA contrattuali con penali, vuoi conoscere il margine di commessa, devi integrare l’ITSM con altri sistemi — è il momento di guardare alla Enterprise.

Trovi tutti i dettagli, la guida di installazione della Community e le condizioni Enterprise su meridian-arc.io