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
| Campo | Tipo | Obbligatorio | Descrizione |
|---|---|---|---|
label | text | Sì | Nome identificativo |
checkType | select | Sì | Tipo di controllo |
url | text | Per http | URL da controllare |
host | text | Per tcp/ping | Hostname o IP |
port | number | Per tcp | Porta TCP |
expectedStatus | number | Per http | Status code atteso (default: 200) |
timeout | number | No | Timeout in ms (default: 30000) |
containerName | text | Per docker | Nome container da monitorare |
Tipi di controllo
| Tipo | Descrizione | Metriche |
|---|---|---|
http | Verifica endpoint HTTP/HTTPS | Status, latency, body |
tcp | Connessione TCP a host:port | Connect time, success |
ping | ICMP ping | RTT, packet loss |
docker | Stato container Docker | Running, health, stats |
ssl | Verifica certificato SSL | Expiry, chain validity |
dns | Risoluzione DNS | Response time, records |
HTTP Check
Verifica la disponibilità e risposta di endpoint HTTP.
Workflow Esempio: Uptime Monitoring
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
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
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
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
| Campo | Tipo | Obbligatorio | Descrizione |
|---|---|---|---|
label | text | Sì | Nome identificativo |
metric | text | Sì | Nome della metrica da analizzare |
algorithm | select | Sì | Algoritmo di detection |
sensitivity | number | No | Sensibilità (1-10, default: 5) |
windowSize | number | No | Finestra temporale in minuti |
baselineSource | select | No | Fonte baseline (historical/dynamic) |
Algoritmi disponibili
| Algoritmo | Descrizione | Use case |
|---|---|---|
zscore | Deviazione standard | Metriche con distribuzione normale |
iqr | Interquartile Range | Dati con outliers frequenti |
mad | Median Absolute Deviation | Dati robusti a outliers estremi |
ewma | Exponential Weighted Moving Average | Serie temporali con trend |
seasonal | Decomposizione stagionale | Dati con pattern ciclici |
Workflow Esempio: Anomaly Detection Latency
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.
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
| Metrica | Descrizione | Alert threshold |
|---|---|---|
uptime_percent | % tempo online | < 99.9% |
avg_latency | Latenza media | > 500ms |
error_rate | % richieste in errore | > 1% |
p95_latency | 95° percentile latenza | > 1000ms |
cert_days_remaining | Giorni a scadenza SSL | < 30 |
Best Practices
Frequenza check
| Tipo servizio | Frequenza consigliata |
|---|---|
| Produzione critica | Ogni 30 secondi |
| Produzione standard | Ogni 1 minuto |
| Staging | Ogni 5 minuti |
| Development | Ogni 15 minuti |
Evitare alert fatigue
- Conferma prima di alertare: Verifica 2-3 volte prima di inviare notifica
- Aggrega alert: Raggruppa alert correlati
- Escalation graduale: Prima log, poi Slack, poi SMS
- 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