03 — Log tables ⭐

Il cockpit mantiene diverse tabelle di log. Sono registri prevalentemente in sola aggiunta che consulti per tre motivi: audit ("chi ha fatto cosa, quando, da dove"), troubleshooting ("perché non ha funzionato / cosa ha inviato il sensore") e provenienza ("da dove viene questo valore"). Questo articolo spiega ciascuna: cosa registra, come raggiungerla, come leggerla e filtrarla, da dove provengono i suoi dati e per quanto tempo vengono conservati.

Molte tabelle di log non hanno un collegamento nella barra laterale. Diverse sono raggiungibili solo tramite URL o tramite un pulsante su un'altra schermata (un popup di stazione, una pagina di dispositivo, un'allerta). Ogni voce qui sotto indica la route esatta.

How to read any log table

• Filtri / Reset: il pulsante a imbuto mostra/nasconde la riga dei filtri; la gomma la azzera. La maggior parte dei log si apre già ordinata dal più recente.
• Date: i filtri data semplici accettano dd/mm/yyyy (corrispondenza sull'intera giornata); i log meteo / IoT / qualità dell'aria usano selettori di intervallo di date (spesso con preset come Oggi, Ultimi 7 giorni, Questo mese).
• Gli orari sono in UTC sui log basati su sensori / qualità dell'aria / Influx (lo indicano le intestazioni di colonna) e locali sui log di tipo CRUD — attenzione all'offset quando correli gli eventi.
• Le righe eliminate in modo soft sono nascoste sui log modificabili.

The seven logs at a glance

B1 — Log azioni (audit trail)

Route: /action-log/index (View su /action-log/view). Sola lettura. Nessun collegamento nella barra laterale — raggiungibile tramite URL.

Cosa registra. L'audit trail di sicurezza delle azioni operatore ad alto impatto. Ogni riga cattura l'utente, l'IP client, il timestamp, il controller, un tag azione e un payload JSON data con i dettagli. Le azioni sottoposte ad audit includono, per esempio:

• export e condivisioni di simulazione — download di report / bundle / shapefile / video, link di condivisione creato / revocato / visualizzato;
• eliminazione massiva di simulazioni ed export di calibrazione;
• caricamenti e import di replay dello storico incendi;
• richieste di assimilazione/persistenza del layer sensori e del posizionamento del naso elettronico.

Colonne: ID · User ID · IP · Time (d/m/Y H:i:s) · Data (JSON formattato) · View. Filtra per utente, IP, controller, azione o giorno.

Usalo per ricostruire "chi ha fatto cosa": filtra per User ID o per una sottostringa di azione per seguire una sequenza di operazioni sensibili. Questa è la tabella da aprire quando un export, una condivisione o un'eliminazione massiva devono essere giustificati.

Conservazione: conservato a tempo indeterminato (nessuna pulizia automatica).

B2 — Log notifiche

Route: /notification-log/index (View, ed eliminazione). Nessun collegamento nella barra laterale.

Cosa registra. Il registro di consegna delle notifiche di allerta — una riga per destinatario per canale — così puoi confermare che un'allerta sia partita e fare troubleshooting sulle mancate consegne.

Colonne: ID · Alert ID · Recipient User · Channel · Email Subject · Send At (d/m/Y H:i:s) · Delivery Status · azioni. Lo stato di consegna è In queue, Sent o Undelivered; i canali includono Email, SMS, WhatsApp, notifica Desktop. Filtra per destinatario, canale, stato o data.

Usalo per verificare che le persone che avrebbero dovuto essere allertate lo siano state davvero, trovare i messaggi non consegnati e risalire da una notifica all'allerta che l'ha attivata. Un pannello compatto "ultimi log" mostra inoltre le notifiche recenti nelle dashboard.

Da dove viene: scritto dagli invii di notifiche quando un'allerta o una regola di matrice allerte scatta (vedi 08 — Administration).

B3 — Technology log

Route: /technology-log/index (Create/View/Update/Delete completi). Nessun collegamento nella barra laterale — area legacy.

Cosa registra. Letture/osservazioni con timestamp dai dispositivi "technology" legacy (es. telecamere/sensori che precedono il merge IoT): valori di temperatura e riferimenti a immagini, ciascuno con un data type (Temperature / Image), una log category e una log confidence (la confidence segnala le voci derivate da ML).

Colonne: ID · Technology ID · Datetime · Data Type · Data Value · Data Unit · azioni (il popover View aggiunge Log Category e Log Confidence).

Usalo per ispezionare l'output di uno specifico dispositivo legacy. Per i sensori di campo attuali preferisci il Log sensori IoT — questa tabella è in gran parte superata.

B4 — Log stazioni meteo

Route: /weather-station-log/index (View). Di solito raggiungibile dalla mappa meteo (pulsante popup "Reading history") o da una scheda stazione ("Open full log") — oppure tramite URL. Elencato sia sotto Monitoraggio sia nella sezione di amministrazione.

Cosa registra. Lo storico delle letture meteorologiche per stazione — temperatura, umidità, precipitazioni, velocità / massima / direzione del vento, radiazione, pressione — il registro dettagliato dietro la mappa meteo live.

Come leggerlo.

• Un widget statistiche in intestazione con schede Per station / Per country e un grafico temperatura/precipitazioni (un trend ↗ verde / ↘ rosso confronta questo mese con lo stesso mese dell'anno scorso). Le etichette dei paesi riportano "Italian Karst" / "Slovenian Karst".
• Un selettore di intervallo di date (con orario e preset; predefinito a oggi, ricordato per la tua sessione).
• Colonne: ID · Weather Station · Datetime · Temperature · Humidity · Precipitation · Wind Speed · Wind Max · Wind Direction · Wind Direction Max · Radiation · Pressure (hPa) · View.

Da dove viene: letto direttamente da InfluxDB (il primo caricamento può richiedere fino a un minuto). Le letture sorgente sono replicate dal servizio meteo (wf). La conservazione è governata da InfluxDB, non da una pulizia del cockpit.

Non usare il Influx log legacy (B7) per questo — è la copia MySQL dismessa.

B5 — Log stazioni aria

Route: /air-quality-station-log/index. Nel menu Monitoraggio ("Log stazioni aria"). Un pulsante "Stations" in intestazione porta al registro delle stazioni.

Cosa registra. Lo storico degli inquinanti per lettura su tutte le stazioni di qualità dell'aria (una riga per stazione × tempo × inquinante).

Come leggerlo.

• Sei KPI card: Readings · Last hour · Latest sample · PM2.5 24h · PM10 24h · O₃ 24h.
• Colonne: Observed At (UTC) · Station Code · Name · Pollutant · Value · Unit · Calibration · Created At. Il Value è colorato in base al limite normativo (rosso ≥ limite · ambra ≥ 80% · verde sotto), con la base in un tooltip.
• Filtra per stazione, inquinante e un intervallo observed-from/observed-to.

Usalo per confermare la lettura di un inquinante, individuare i superamenti (il Value colorato) e verificare la freschezza del sync confrontando Created At con Observed At.

Da dove viene: l'API AirQino, sincronizzata dai job airqino/* (più il fallback Python a 5 minuti per le stazioni di Duino). La granularità corrisponde alla risposta "last reading" a monte.

B6 — Log sensori IoT

Route: /iot-sensor-log/index. Nel menu Monitoraggio ("Log sensori IoT").

Normalmente vuoto — ed è corretto. Questa tabella è un sink di fallback: il servizio di ingest scrive qui solo quando InfluxDB è degradato o irraggiungibile. La route restituisce addirittura 404 a meno che il flag di fallback MySQL non sia abilitato. In funzionamento sano, le letture vanno in InfluxDB e questa resta vuota.

Cosa registra (durante un'interruzione). Storico IoT per lettura con un fallback_reason su ogni riga per tracciabilità.

Come leggerlo.

• KPI card sul filtro corrente: Readings · Time range (UTC) · Temperature (min–max, warn ≥ 30 / alert ≥ 35 °C, con una sparkline) · Humidity (warn ≤ 25 / alert ≤ 15 %) · Pressure · RSSI (warn ≤ −80 / alert ≤ −90 dBm).
• Colonne: Observed At · Sensor Device ID · Gateway Serial · Seq ID · Cycles Received (received/total) · RSSI · SNR · Temp · Pressure · Humidity · Gas · Fallback Reason · Created At.
• Filtra per dispositivo, gateway, fallback reason, sequenza e un intervallo di date. (La vista sensore rimanda qui con deep-link filtrato su un solo dispositivo.)

Usalo per recuperare e ispezionare le letture durante/dopo un'interruzione di InfluxDB — filtra per dispositivo o gateway; il fallback_reason spiega perché esiste ogni riga. Se questa griglia è inaspettatamente grande in funzionamento normale, InfluxDB sta fallendo in modo intermittente (vedi la tabella di troubleshooting in docs/ops/loramip-gateway.md).

Conservazione: ripulito ogni notte, default 30 giorni (configurabile; il job di pulizia gira alle 03:15).

B7 — Influx log (legacy)

Route: /influx-log/index (Create/Update/Delete). Nessun collegamento nella barra laterale.

Cos'è. Un CRUD di log meteo legacy basato su MySQL che precede la migrazione a InfluxDB. Rende lo stesso widget statistiche e le stesse colonne del Log stazioni meteo ma è modificabile e legge da una tabella MySQL locale. È esplicitamente marcato per la rimozione dopo la validazione di InfluxDB.

Usalo: in funzionamento normale, no — usa il Log stazioni meteo. Resta solo per riferimento legacy/diagnostico.

Provenance & retention summary

Un rapido modello mentale di dove ogni flusso ha origine e quanto dura:

• Meteo → servizio wf → InfluxDB → il Log stazioni meteo legge Influx; l'Influx log è la copia MySQL dismessa. Conservazione = Influx.
• Sensori / gateway IoT → observation-ingest su LoRaMIP / MQTT → InfluxDB, con il Log sensori IoT come fallback per le interruzioni (pulizia a 30 giorni).
• Qualità dell'aria → API AirQino tramite i job airqino/* (+ fallback Python di Duino) → Log stazioni aria.
• Allerte → MeteoAlarm MQTT realtime + riconciliazione REST oraria; le notifiche sono registrate nel Log notifiche.
• Azioni operatore → scritture di audit esplicite → Log azioni (conservato a tempo indeterminato).
• Dispositivi legacy → pipeline legacy → Technology log.

When to use which

• "Chi ha esportato / condiviso / eliminato questo?" → Log azioni.
• "L'allerta è arrivata davvero alle persone?" → Log notifiche.
• "Cosa ha letto questa stazione meteo?" → Log stazioni meteo.
• "Questo valore di qualità dell'aria è un superamento?" → Log stazioni aria.
• "InfluxDB ha avuto un'interruzione — recupera le letture dei sensori." → Log sensori IoT.

Related

• 02 — Monitoring — le schermate live dietro cui stanno questi log.
• 08 — Administration — le regole della matrice allerte che alimentano il Log notifiche; PyroWISE readiness/status.