Un plugin può controllare un processo tecnico che i controlli standard non coprono: per esempio, da quanto tempo una cassa non completa l’invio dei dati. L’AI può preparare codice, documentazione e casi di prova a partire da una specifica. La specifica deve chiarire cosa misurare e cosa fare quando il dato manca.
Definire il controllo prima del codice
Nel nostro esempio, un processo locale scrive un file JSON con l’orario dell’ultimo invio riuscito. Il plugin legge quel file e calcola l’età del dato. Il controllo riguarda la sincronizzazione, non lo stato completo della cassa.
{
"store": "ST017",
"asset": "POS03",
"last_success": "2026-10-08T10:00:00+02:00"
}
Alle 10:20 l’ultimo successo risale a 1.200 secondi prima. Per questo esercizio scegliamo WARNING da 600 secondi e CRITICAL da 900 secondi, con soglie inclusive. Sono valori didattici: in azienda vanno adattati alla frequenza prevista, agli orari di attività e alla tolleranza del processo.
Un servizio che non dovrebbe inviare dati fuori orario non deve generare falsi incidenti durante la chiusura. La pianificazione del controllo o una regola esplicita deve gestire questa condizione.
Una richiesta di sviluppo verificabile
Sviluppa un plugin Python 3 che legga un file JSON locale in sola lettura.
Campo richiesto: last_success, data ISO 8601 con fuso orario.
Calcola l'età in secondi usando un orologio sostituibile nei test.
Parametri: --file, --warning, --critical.
Richiedi 0 < warning < critical.
CRITICAL se età >= critical; WARNING se età >= warning; altrimenti OK.
File mancante, JSON invalido, timestamp senza fuso o futuro: UNKNOWN.
Limita la lettura del file a 64 KiB e gestisci gli errori senza traceback nell'output normale.
Non eseguire comandi, non modificare file e non usare rete.
Usa codici 0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN.
Produci una riga di stato e la metrica age_seconds.
Per UNKNOWN ometti la metrica, perché non hai una misura valida.
Prepara test per soglie esatte, input invalidi e orologi incoerenti.
Spiega come eseguire il controllo con un utente privo di privilegi amministrativi.
I codici di stato e il formato delle metriche devono rispettare il contratto del sistema di monitoring. Per plugin compatibili con Monitoring Plugins, il riferimento è la documentazione ufficiale di sviluppo. La classificazione degli input invalidi proposta qui riguarda questo controllo locale; per controlli di rete occorre definire separatamente il significato degli errori di connessione.
Risultati attesi
Con orologio fissato alle 10:20, il file dell’esempio deve produrre codice 2 e un output equivalente a:
CRITICAL - ultimo invio riuscito 1200 s fa | age_seconds=1200s;600;900;0;
Se il file è malformato, il plugin deve produrre codice 3 e un messaggio utile, senza fingere che il servizio stia funzionando.
| Età o condizione | Stato atteso |
|---|---|
| 599 secondi | OK |
| 600 secondi | WARNING |
| 899 secondi | WARNING |
| 900 secondi | CRITICAL |
| Timestamp futuro | UNKNOWN |
| Timestamp senza fuso | UNKNOWN |
| File illeggibile | UNKNOWN |
Questa tabella è il criterio di accettazione, non la prova che un codice generato lo rispetti. Esegui i test, leggi il codice e confronta l’output con il contratto del monitoring prima del rilascio.
Dal prototipo al controllo operativo
Prova il plugin su file fittizi, poi su copie dei dati reali. Eseguilo con lo stesso utente del monitoring: i permessi possono essere diversi da quelli della tua sessione. Proteggi il file sorgente da modifiche non autorizzate e assicurati che il produttore lo aggiorni in modo atomico, per evitare letture parziali.
Inserisci il controllo su un gruppo limitato di casse e confronta gli alert con gli invii effettivi. Documenta versione, soglie, frequenza e procedura di ritorno alla versione precedente. Potrai automatizzare la generazione di ulteriori plugin mantenendo una specifica, prove e revisione per ogni controllo.
Per esercitarti nel passaggio da requisiti a un progetto verificabile, trovi il corso gratuito Codex e vibe coding. Le lezioni complete richiedono un account gratuito.