Monitoring Nodes

I nodi di monitoring permettono di verificare lo stato di salute di servizi, applicazioni e infrastruttura.


Monitor

monitor

Esegue controlli di disponibilità e performance su target specificati.

Configurazione

CampoTipoObbligatorioDescrizione
labeltextNome identificativo
checkTypeselectTipo di controllo
urltextPer httpURL da controllare
hosttextPer tcp/pingHostname o IP
portnumberPer tcpPorta TCP
expectedStatusnumberPer httpStatus code atteso (default: 200)
timeoutnumberNoTimeout in ms (default: 30000)
containerNametextPer dockerNome container da monitorare

Tipi di controllo

TipoDescrizioneMetriche
httpVerifica endpoint HTTP/HTTPSStatus, latency, body
tcpConnessione TCP a host:portConnect time, success
pingICMP pingRTT, packet loss
dockerStato container DockerRunning, health, stats
sslVerifica certificato SSLExpiry, chain validity
dnsRisoluzione DNSResponse time, records

HTTP Check

Verifica la disponibilità e risposta di endpoint HTTP.

Workflow Esempio: Uptime Monitoring

Diagramma di flusso

Configurazione
type: monitor
checkType: http
url: "https://api.example.com/health"
expectedStatus: 200
timeout: 10000
label: "API Health Check"

Opzioni avanzate:

headers:
  Authorization: "Bearer {{secrets.API_TOKEN}}"
validateSSL: true
followRedirects: true
maxRedirects: 5

Output

{
  "url": "https://api.example.com/health",
  "checkType": "http",
  "success": true,
  "status": 200,
  "statusText": "OK",
  "latency": 145,
  "headers": {
    "content-type": "application/json",
    "x-response-time": "12ms"
  },
  "body": {
    "status": "healthy",
    "version": "1.2.3",
    "uptime": 86400
  },
  "ssl": {
    "valid": true,
    "daysToExpiry": 45
  },
  "checkedAt": "2024-01-15T10:30:00Z"
}

TCP Check

Verifica che un servizio sia in ascolto su una porta specifica.

Workflow Esempio: Database Monitoring

Diagramma di flusso

Configurazione
type: monitor
checkType: tcp
host: "db.example.com"
port: 3306
timeout: 5000
label: "MySQL Check"

Output

{
  "host": "db.example.com",
  "port": 3306,
  "checkType": "tcp",
  "success": true,
  "connectTime": 23,
  "banner": "5.7.40-log",
  "checkedAt": "2024-01-15T10:30:00Z"
}

Ping Check

Verifica la raggiungibilità di un host tramite ICMP.

Workflow Esempio: Network Monitoring

Diagramma di flusso

Configurazione
type: monitor
checkType: ping
host: "8.8.8.8"
count: 5
timeout: 5000
label: "Google DNS Ping"

Output

{
  "host": "8.8.8.8",
  "checkType": "ping",
  "success": true,
  "stats": {
    "transmitted": 5,
    "received": 5,
    "packetLoss": 0,
    "minRtt": 12.5,
    "avgRtt": 15.2,
    "maxRtt": 22.1,
    "stddevRtt": 3.4
  },
  "checkedAt": "2024-01-15T10:30:00Z"
}

Docker Check

Verifica lo stato di container Docker.

Workflow Esempio: Container Health

Diagramma di flusso

Configurazione
type: monitor
checkType: docker
containerName: "app-web"
label: "Web Container Check"

Output

{
  "containerName": "app-web",
  "checkType": "docker",
  "success": true,
  "container": {
    "id": "abc123...",
    "name": "app-web",
    "image": "nginx:1.21",
    "status": "running",
    "state": "Up 3 days",
    "health": "healthy"
  },
  "stats": {
    "cpu": {
      "percent": 2.5,
      "cores": 4
    },
    "memory": {
      "usage": 256000000,
      "limit": 512000000,
      "percent": 50
    },
    "network": {
      "rxBytes": 1024000,
      "txBytes": 512000
    }
  },
  "checkedAt": "2024-01-15T10:30:00Z"
}

Condition per memoria alta

type: condition
condition: |
  {{monitor.output.stats.memory.percent}} > 80

DNS Check

Verifica la risoluzione DNS e i tempi di risposta.

Configurazione
type: monitor
checkType: dns
host: "api.example.com"
recordType: "A"
dnsServer: "8.8.8.8"
label: "DNS Resolution Check"

Output

{
  "host": "api.example.com",
  "checkType": "dns",
  "success": true,
  "resolvedAddresses": ["192.168.1.100", "192.168.1.101"],
  "ttl": 300,
  "responseTime": 12,
  "dnsServer": "8.8.8.8",
  "checkedAt": "2024-01-15T10:30:00Z"
}

Anomaly Detector

anomalyDetector

Rileva anomalie nei dati di monitoraggio utilizzando algoritmi statistici.

Configurazione

CampoTipoObbligatorioDescrizione
labeltextNome identificativo
metrictextNome della metrica da analizzare
algorithmselectAlgoritmo di detection
sensitivitynumberNoSensibilità (1-10, default: 5)
windowSizenumberNoFinestra temporale in minuti
baselineSourceselectNoFonte baseline (historical/dynamic)

Algoritmi disponibili

AlgoritmoDescrizioneUse case
zscoreDeviazione standardMetriche con distribuzione normale
iqrInterquartile RangeDati con outliers frequenti
madMedian Absolute DeviationDati robusti a outliers estremi
ewmaExponential Weighted Moving AverageSerie temporali con trend
seasonalDecomposizione stagionaleDati con pattern ciclici

Workflow Esempio: Anomaly Detection Latency

Diagramma di flusso

Configurazione
type: anomalyDetector
metric: "response_latency"
algorithm: "zscore"
sensitivity: 7
windowSize: 60
baselineSource: "historical"
label: "Latency Anomaly Detector"

Output

{
  "metric": "response_latency",
  "algorithm": "zscore",
  "anomalyDetected": true,
  "currentValue": 850,
  "baseline": {
    "mean": 150,
    "stddev": 30,
    "min": 100,
    "max": 250
  },
  "score": 23.3,
  "threshold": 3.0,
  "severity": "critical",
  "direction": "above",
  "context": {
    "recentValues": [145, 152, 148, 155, 850],
    "windowStart": "2024-01-15T10:25:00Z",
    "windowEnd": "2024-01-15T10:30:00Z"
  },
  "recommendation": "Valore 5.6x sopra la media. Verificare il servizio."
}

Workflow Completo: Sistema di Monitoring

Un sistema di monitoring completo con multiple checsk e alerting.

Diagramma di flusso

Configurazione condition servizi down
type: condition
condition: |
  {{merge.output}}.some(check => 
    check.success === false
  )
Template notifica
type: notification
channel: slack
template: |
  🚨 *Servizi Down*
  
  {{#each merge.output}}
  {{#unless success}}
  • *{{label}}* - Down da {{formatDuration failedSince}}
    URL: {{url}}
    Errore: {{error}}
  {{/unless}}
  {{/each}}
  
  Ultimo check: {{formatDate now 'HH:mm:ss'}}

Dashboard Metriche

Puoi creare una dashboard aggregando i dati di monitoring.

Metriche da tracciare

MetricaDescrizioneAlert threshold
uptime_percent% tempo online< 99.9%
avg_latencyLatenza media> 500ms
error_rate% richieste in errore> 1%
p95_latency95° percentile latenza> 1000ms
cert_days_remainingGiorni a scadenza SSL< 30

Best Practices

Frequenza check
Tipo servizioFrequenza consigliata
Produzione criticaOgni 30 secondi
Produzione standardOgni 1 minuto
StagingOgni 5 minuti
DevelopmentOgni 15 minuti
Evitare alert fatigue
  1. Conferma prima di alertare: Verifica 2-3 volte prima di inviare notifica
  2. Aggrega alert: Raggruppa alert correlati
  3. Escalation graduale: Prima log, poi Slack, poi SMS
  4. Cooldown: Non ri-alertare per lo stesso problema entro N minuti
Retention dati
# Esempio policy retention
raw_metrics: 7 days     # Ogni minuto
hourly_aggregates: 30 days
daily_aggregates: 1 year
monthly_aggregates: forever