← Indice documentazione Guida all'architettura › osservabilità

Metnos

Osservabilità operativa
Vedere lo stato del sistema senza confondere una vista con una fonte di autorità.

Per controllare un'installazione in funzione si usa Settings, l'area amministrativa della chat web. Metnos può anche produrre un rendiconto HTML da aprire come file locale: è una fotografia tecnica del momento in cui viene generata, non una seconda versione di Settings.

Indice

  1. Da dove cominciare
  2. I due strumenti
  3. Settings nella chat
  4. Il rendiconto HTML statico
  5. Dati raccolti dal rendiconto
  6. Accesso, utenti e riservatezza
  7. Generazione e durata
  8. Verifiche e fonti canoniche

1. Da dove cominciare

Puoi chiedere direttamente a Metnos:

Mostrami dove posso controllare gli ultimi turni e lo stato dei servizi.

Il percorso più semplice passa dalla chat web: Settings > Attività > Turni per le richieste recenti e Settings > Sistema > Servizi per i servizi configurati. Se stai parlando con Metnos da Telegram, devi comunque aprire queste pagine nel browser: Telegram non contiene l'area amministrativa.

API, registri e file servono invece per una diagnosi tecnica. Il rendiconto statico descritto più avanti appartiene a questo secondo caso e non è il percorso ordinario per chi usa la chat.

2. I due strumenti

StrumentoAggiornamentoAccessoScopo
Settings (/admin)Rilegge i dati quando si apre o si aggiorna una pagina.Richiede una sessione con ruolo amministratore.Controllare l'installazione mentre è in funzione.
Rendiconto statico (runtime.observability)Resta fermo all'istante in cui viene generato.È un file locale; la protezione dipende dai permessi del file e del computer.Esaminare fuori linea sei sorgenti locali.

Non sono due viste dello stesso strumento. Settings usa pagine e dati propri; il generatore statico viene avviato soltanto dalla riga di comando e il server HTTP non lo usa.

3. Settings nella chat

La pagina iniziale di Settings riassume versione e tempo di attività, turni delle ultime 24 ore, proposte, executor, scheduler, firme Safety e utenti. Le pagine di dettaglio separano le diverse domande operative:

Percorso nella chatInformazioni principali
Settings > Attività > TurniIdentificativo, orario, canale, attore, passi, esito, durata e richiesta.
Settings > Attività > SchedulerEsecuzioni delle attività, esito e durata.
Settings > Sistema > ServiziServizi presenti nel registro canonico, stato e controlli ammessi.
Settings > Sistema > ModelliConfigurazione effettiva e oscurata di LLM, embedding e VLM: LLM e VLM sono modificabili e ripristinabili; l’embedding è consultabile.
Settings > Sistema > DispositiviDispositivi associati, presenza e revoca.
Settings > Sistema > UtentiUtenti, ruoli, canali e preferenze amministrabili.

Il registro in runtime/ui_surfaces.py descrive in modo canonico le pagine visibili e il percorso per raggiungerle. Il Tutor usa lo stesso registro; per questo una modifica strutturale dell'interfaccia richiede di aggiornare anche la guida di navigazione e l'indice del Tutor.

4. Il rendiconto HTML statico

Il generatore legge le sorgenti locali e compone un unico documento con gli stili incorporati, senza JavaScript e senza collegamenti in tempo reale con il server. Le sezioni appaiono in questo ordine: test, Mnestoma, associazioni, turni recenti, decisioni del Vaglio e scheduler.

Ogni raccoglitore gestisce separatamente una sorgente non disponibile. La pagina può quindi essere prodotta anche quando una sezione è vuota o in errore. Questo comportamento rende leggibile una fotografia parziale, ma non trasforma l'assenza di dati in prova del buon funzionamento del componente.

Il documento generato usa attualmente etichette italiane e lang="it". Non è una superficie localizzata della chat e non va presentato come tale.

5. Dati raccolti dal rendiconto

SorgenteDati mostratiPosizione configurata
MnestomaConteggi, archi attivi e proto, eventi recenti.Database di Mnestoma, normalmente sotto PATH_WORKSPACE/.mnestoma.
AssociazioniCanale, identificativo del mittente, livello, date e autore dell'associazione; conteggio delle revoche.DB_PAIRINGS sotto PATH_USER_STATE.
TurniUltimi quindici turni: richiesta, esito, numero di passi e inizio della risposta.PATH_TURNS sotto PATH_USER_DATA.
VaglioUltime venti decisioni: executor, punteggio, esito e motivazione abbreviata.PATH_USER_DATA/vaglio.
SchedulerAttività abilitate, regola temporale, ultima esecuzione ed esito.PATH_USER_STATE/scheduler_v2.sqlite.
Prove registrateModuli, casi abilitati, ultimo stato e moduli più numerosi.PATH_RUNTIME/testing/tests.db.

I limiti sono fissi nel generatore e non si possono cambiare dalla riga di comando: al massimo cinque file di turni, tre file del Vaglio e un numero limitato di righe o eventi per sezione. Il rendiconto serve quindi a orientare la diagnosi, non a calcolare totali completi.

6. Accesso, utenti e riservatezza

7. Generazione e durata

Dalla radice dell'installazione, usando l'ambiente Python di Metnos:

PYTHONPATH=runtime ./.venv/bin/python -m observability render
PYTHONPATH=runtime ./.venv/bin/python -m observability render --out /percorso/scelto/dashboard.html

Il percorso predefinito è PATH_WORKSPACE/dashboard/index.html. Il comando restituisce il percorso scritto e termina. Non esiste un aggiornamento periodico incorporato: ora di generazione e contenuto restano invariati finché il comando non viene eseguito di nuovo.

Il file è un prodotto derivato. Per eliminarlo si può rimuovere il solo percorso di uscita dopo aver verificato che non sia usato da altri processi; le sorgenti operative non vengono eliminate con esso.

8. Verifiche e fonti canoniche

Le prove mirate del generatore statico sono in tests/runtime/runtime/test_observability.py. Verificano, fra l'altro, che nomi degli executor, richieste e risposte non possano introdurre markup attivo nel file. Le prove HTTP ed end-to-end controllano separatamente le pagine amministrative: non si usa un conteggio fisso, destinato a diventare obsoleto.