Πώς θα σχεδιάζατε την παρακολούθηση μιας εφαρμογής από την αρχή;

Question

Accepted Answer

Ξεκινήστε **από πάνω προς τα κάτω με εστίαση στο τι αισθάνονται οι χρήστες**, όχι από κάτω προς τα πάνω από την υποδομή. Ο πιο αξιόπιστος στόλος hosts είναι άχρηστος εάν τα αιτήματα αποτυγχάνουν, οπότε ξεκινήστε με **SLIs** στραμμένα προς τον χρήστη — **latency**, **ποσοστό σφάλματος**, **διαθεσιμότητα** — στη συνέχεια προσθέστε τα τέσσερα χρυσά σήματα, και στο τέλος μετρικές υποδομής.

## Η στρωμάτωση, από τον χρήστη προς τα ενδότερα

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

Αν παρακολουθείτε μόνο CPU και δίσκο (από κάτω προς τα πάνω), μπορείτε να είστε εντελώς πράσινα ενώ οι χρήστες λαμβάνουν 500s. Η παρακολούθηση SLIs πρώτα (από πάνω προς τα κάτω) σημαίνει ότι ειδοποιείτε για **συμπτώματα που οι χρήστες πραγματικά αισθάνονται**, και στη συνέχεια ανασκαφή στα χρυσά σήματα και την υποδομή για να βρείτε την αιτία.

## Ο σωλήνας: όργανο → συλλογή → ταμπλό → ειδοποίηση

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## Ένα συγκεκριμένο σημείο εκκίνησης

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

Ορίστε ένα **SLO** σε κάθε SLI (π.χ. διαθεσιμότητα 99,9%, p99 < 300ms), τα ταμπλό τα δεδομένα και ειδοποιήστε όταν το SLO κινδυνεύει — όχι σε κάθε διακύμανση.

## Γιατί έχει σημασία

Η παρακολούθηση που κατασκευάζεται από κάτω προς τα πάνω σας λέει ότι ένας δίσκος είναι 80% γεμάτος αλλά όχι ότι οι πελάτες δεν μπορούν να κάνουν ολοκλήρωση αγοράς. Η έναρξη από **SLIs** στραμμένα προς τον χρήστη συνδέει κάθε ταμπλό και ειδοποίηση με πραγματική επίδραση στο χρήστη, κρατά τον θόρυβο χαμηλό και παρέχει ένα σαφή μονοπάτι ανασκαφής (σύμπτωμα → χρυσό σήμα → αιτία υποδομής) όταν κάτι σπάει.