Άμεσο 503 ή 403: ελέγξτε πρώτα πάνω από την εφαρμογή

Το μηδενικό latency είναι η πρώτη μέτρηση

Ο χρόνος μέχρι το πρώτο byte σάς λέει αν η εφαρμογή έκανε οποιαδήποτε δουλειά. Ένα σφάλμα που φτάνει περίπου στον χρόνο του round-trip του δικτύου αποφασίστηκε χωρίς αυτήν. Ένα σφάλμα που παρήγαγε η εφαρμογή κουβαλά τον χρόνο που ξόδεψε πριν τα παρατήσει.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' https://site.example/
curl -sI https://site.example/

Τα headers κατονομάζουν το επίπεδο τις περισσότερες φορές. Ένα header Server ή Via που ανήκει στο edge ή στον balancer και όχι στον web server, ένα X-Cache ή ένα request id του edge, ένα body απλού κειμένου εκεί που η εφαρμογή θα απέδιδε template: το καθένα λέει ποιος απάντησε. Με αυτό στο χέρι, η λίστα ελέγχου είναι σύντομη.

Η λίστα ελέγχου, από πάνω προς τα κάτω

Το CDN ή το edge. Ένας κανόνας WAF, ένα rate limit, ένας κανόνας geo, μια πρόκληση bot, ή ένα πρόβλημα πιστοποιητικού ανάμεσα στο edge και το origin, το οποίο το edge αναφέρει ως δικό του 5xx. Παρακάμψτε το: επιλύστε το όνομα απευθείας στο origin και επαναλάβετε το αίτημα.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer}\n' \
     --resolve site.example:443:ORIGIN_IP https://site.example/

Το origin απαντά 200, το edge απαντά 5xx: το σφάλμα ανήκει στο edge, και το ίδιο ο κανόνας που το παρήγαγε.

Ο load balancer. Ο HAProxy απαντά 503 μόνος του όταν κανένα backend δεν είναι up, με δικό του header Server και body μίας γραμμής. Αυτό είναι ζήτημα health check, όχι εφαρμογής: μια διαδρομή ελέγχου που άλλαξε στο τελευταίο deploy, μια πόρτα ελέγχου που μετακινήθηκε, ή ένα backend μαρκαρισμένο down για έναν λόγο που φαίνεται στη σελίδα stats. Ζητήστε ένα backend απευθείας από τον host του balancer για να επιβεβαιώσετε ότι σερβίρει.

Το επίπεδο της πλατφόρμας. Μια κατάσταση αναστολής ή συντήρησης στο control panel, ο διακόπτης συντήρησης ενός εργαλείου deploy, μια υπηρεσία scaled στο μηδέν. Το καθένα σερβίρει μια σταθερή σελίδα χωρίς να καλεί την εφαρμογή, και το καθένα είναι ένα flag που μπορείτε να διαβάσετε, όχι μια θεωρία.

Κανόνες του web server. Μία μόνο οδηγία return, rewrite ή deny απαντά ακαριαία και μοιάζει καταστροφική. Εξάγετε την ενεργή διαμόρφωση και όχι το αρχείο που νομίζετε ότι έχει φορτωθεί.

# nginx: the configuration actually in effect, with the rules that short-circuit a request
nginx -T 2>/dev/null | grep -nE '^\s*(return|rewrite|deny|allow)\b'

# IIS: the URL Rewrite rules for the site
appcmd list config /section:system.webServer/rewrite/rules

Στον Apache, διαβάστε την ενεργή αλυσίδα .htaccess για τη διαδρομή, όχι μόνο το vhost.

DNS. Επιβεβαιώστε ότι το όνομα επιλύεται στον host που κάνετε debug. Μια παλιά εγγραφή, μια διαφορά split-horizon ή μια αλλαγή που ακόμη διαδίδεται σημαίνει ότι το μηχάνημα που κοιτάτε δεν είναι αυτό που απαντά.

Δικαιώματα και SELinux. Ο web server δεν μπορεί να διαβάσει το document root ή να συνδεθεί στο upstream socket. Ένα 403 ή ένα 502 χωρίς καμία γραμμή στο log της εφαρμογής. Σε σύστημα enforcing, το audit log κατονομάζει την άρνηση και η διόρθωση είναι ένα policy module, όχι αλλαγή mode.

ausearch -m avc -ts recent | audit2why

Μόνο τώρα, η εφαρμογή. Worker pools, runtime, εξαρτήσεις, ο κώδικας. Καθένα από αυτά είναι ακριβό να διερευνηθεί και δεν μπορεί να είναι η αιτία μιας απόκρισης που η εφαρμογή δεν παρήγαγε.

Δύο λεπτομέρειες που παρατείνουν το κυνήγι

Ένα 429 έχει δύο πιθανούς συντάκτες. Ένας limiter στο edge το απαντά με τα headers του ίδιου του edge και συνήθως ένα Retry-After. Ένας limiter της εφαρμογής το απαντά μέσα από την εφαρμογή, με τα headers της εφαρμογής και αφού η εφαρμογή έκανε κάποια δουλειά. Ο χρόνος μέχρι το πρώτο byte και τα headers τα ξεχωρίζουν, και η διόρθωση βρίσκεται σε διαφορετικό σημείο για το καθένα.

Μια σελίδα σφάλματος μπορεί να ζήσει περισσότερο από την αιτία της. Edges και reverse proxies μπορεί να κάνουν cache ένα 5xx για λίγο, οπότε το origin συνέρχεται και το edge συνεχίζει να σερβίρει το αποθηκευμένο σφάλμα μέχρι να λήξει. Ένα header Age στην απόκριση σφάλματος λέει ότι είναι αντίγραφο από cache. Κάντε purge τη διαδρομή στο edge, ή περιμένετε το TTL, πριν συμπεράνετε ότι η διόρθωση δεν δούλεψε.

Κάντε κάθε επίπεδο να αποδείξει τον εαυτό του

Κάθε βήμα παραπάνω ζευγαρώνει ένα επίπεδο με έναν τρόπο παράκαμψής του: η επίλυση απευθείας στο origin παρακάμπτει το edge, το αίτημα σε ένα backend από τον host του balancer παρακάμπτει τον balancer, το αίτημα στην πόρτα της εφαρμογής στο localhost παρακάμπτει τον web server. Το πρώτο hop όπου η απόκριση αλλάζει από το σφάλμα σε περιεχόμενο είναι το επίπεδο στο οποίο ανήκει το σφάλμα. Η μέθοδος είναι μηχανική επίτηδες, και αυτό είναι που την κάνει γρήγορη οποιαδήποτε ώρα.