Κεντρικό logging που αντέχει σε μια ανασκόπηση περιστατικού

Η πραγματική δοκιμασία του κεντρικού logging δεν είναι αν τα μηνύματα φτάνουν ένα ήσυχο απόγευμα. Είναι αν, το πρωί μετά από κάτι που πήγε στραβά, μπορείτε να συνθέσετε μέσα σε λίγα λεπτά ένα πλήρες, σωστά ταξινομημένο χρονολόγιο σε routers, firewalls, storage και servers. Αυτό απαιτεί ένα pipeline χτισμένο γι' αυτό. Έτσι χτίζουμε το δικό μας σε Graylog, και αυτά μπορείτε να αντιγράψετε για το δικό σας.

Ξεκινήστε από την ερώτηση που θα κάνετε

Κάθε σχεδιαστική επιλογή σε ένα pipeline logging πρέπει να εξυπηρετεί μία ερώτηση: «τι συνέβη, παντού, ανάμεσα σε αυτές τις δύο χρονικές στιγμές;» Αυτή η ερώτηση αποτυγχάνει με τέσσερις προβλέψιμους τρόπους. Λείπουν μηνύματα για μέρος του παραθύρου. Η ίδια συσκευή εμφανίζεται με περισσότερα από ένα ονόματα, άρα μια αναζήτηση βρίσκει μόνο μέρος του ιστορικού της. Τα ρολόγια διαφωνούν, άρα τα γεγονότα πέφτουν σε λάθος σειρά. Ή όλα είναι σε έναν αδιαφοροποίητο σωρό, άρα οι σημαντικές γραμμές είναι θαμμένες. Κάθε ενότητα παρακάτω αφαιρεί μία από αυτές τις αποτυχίες.

Προωθήστε αξιόπιστα, και κρατήστε buffer στον δίσκο

Το κλασικό syslog μέσω UDP είναι «στείλε και ξέχνα»: ο αποστολέας δεν μαθαίνει ποτέ αν κάτι παρέλαβε το μήνυμα. Για servers προτιμούμε προώθηση TCP με ουρά υποβοηθούμενη από δίσκο, ώστε μια επανεκκίνηση του collector ή μια στιγμιαία διακοπή δικτύου να καθυστερεί τα logs αντί να τα χάνει. Μια ελάχιστη ενέργεια rsyslog:

action(type="omfwd" target="<collector>" port="514" protocol="tcp"
       template="RSYSLOG_SyslogProtocol23Format"
       queue.type="LinkedList" queue.filename="fwd_central"
       queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

Το template στέλνει δομημένα μηνύματα RFC 5424 με πλήρες timestamp και hostname. Η ουρά κρατά τα μη παραδομένα μηνύματα στον δίσκο και ξαναπροσπαθεί μέχρι να επιστρέψει ο collector. Επικυρώστε με rsyslogd -N1 πριν επανεκκινήσετε την υπηρεσία.

Οι δικτυακές συσκευές συνήθως περιορίζονται σε απλό syslog, άρα για αυτές η προστασία είναι διαφορετική: στείλτε στον collector από διεύθυνση πηγής και routing instance που μπορούν πάντα να τον φτάσουν, και ελέγξτε αυτή τη διαδρομή κάθε φορά που αλλάζει η δρομολόγηση της συσκευής.

Δώστε σε κάθε συσκευή ακριβώς ένα όνομα

Οι κατασκευαστές διαφωνούν για το τι μπαίνει σε ένα header syslog. Κάποιες συσκευές παραλείπουν το δικό τους hostname, κάποιες στέλνουν σύντομο όνομα, κάποιες στέλνουν διεύθυνση, και η ίδια συσκευή μπορεί να αλλάξει μορφή μετά από ενημέρωση λογισμικού. Αν ο collector αποθηκεύει ό,τι φτάνει, ένας router καταλήγει απλωμένος σε τρία ονόματα πηγής, και μια αναζήτηση γι' αυτόν επιστρέφει το ένα τρίτο του ιστορικού του.

Το διορθώνουμε κατά την είσοδο. Ένας κανόνας pipeline στο Graylog ξαναγράφει την πηγή κάθε μηνύματος σε ένα κανονικό όνομα συσκευής, με έναν πίνακα αναζήτησης με κλειδί τη διεύθυνση αποστολής:

rule "normalise source name"
when
  has_field("gl2_remote_ip")
then
  let name = lookup_value("device_names", to_string($message.gl2_remote_ip));
  set_field("source", name);
end

Κρατήστε τον πίνακα αναζήτησης συγχρονισμένο με την απογραφή σας, ώστε μια νέα συσκευή να παίρνει το καθαρό της όνομα τη μέρα που καταγράφεται, όχι τη μέρα που κάποιος προσέχει ότι λείπει.

Βάλτε τα ρολόγια σωστά

Κάθε συσκευή πρέπει να καταγράφει σε UTC ή να φέρει ρητή απόκλιση. Η ανάμειξη τοπικής ώρας και UTC ανάμεσα σε συσκευές είναι ο κλασικός τρόπος να φανεί ένα περιστατικό σαν να συνέβη σε λάθος σειρά. Δύο γρήγοροι έλεγχοι σε Linux host:

chronyc tracking      # offset from the reference, should be tiny
timedatectl           # time zone and whether NTP is synchronised

Σε δικτυακό εξοπλισμό, ελέγξτε την αντίστοιχη εντολή κατάστασης και βεβαιωθείτε ότι το timestamp του logging περιλαμβάνει ημερομηνία, χιλιοστά του δευτερολέπτου και ζώνη ώρας. Τα δευτερόλεπτα δεν αρκούν όταν δύο routers αντιδρούν στο ίδιο γεγονός.

Δρομολογήστε τα μηνύματα σε streams ανά ρόλο

Ένας ενιαίος χείμαρρος δεν διαβάζεται. Δρομολογούμε τα μηνύματα σε streams ανά ρόλο: core routing, fabric datacenter, firewalls, storage, hosts. Επειδή κάθε πηγή έχει πλέον καθαρό όνομα, η δρομολόγηση είναι ζήτημα αντιστοίχισης ονομάτων ή ενός πεδίου ρόλου που ορίζει το ίδιο pipeline. Κάθε stream έχει ως φυσικούς αναγνώστες τους ανθρώπους που λειτουργούν εκείνα τα συστήματα, και καθένα μπορεί να έχει δική του διατήρηση, σχεδιασμένη να ταιριάζει σε ό,τι απαιτούν η υπηρεσία και κάθε ελεγκτής.

Συναγερμός στο πρόβλημα, και στη σιωπή

Συναγερμός σε ό,τι προηγείται του προβλήματος

Μόλις τα logs είναι καθαρά και στη σωστή θέση, οι πολύτιμες γραμμές πρέπει να φτάνουν σε έναν άνθρωπο όσο ακόμα μετράνε. Ορίζουμε events για τα μηνύματα που τείνουν να προηγούνται μιας διακοπής: ένα BGP session που πέφτει, μια γραμμή που κάνει flap, το BFD που δηλώνει μια διαδρομή νεκρή, sessions κρυπτογράφησης που ανακυκλώνονται σε ένα backbone, ένα σφάλμα hardware, ένα σφάλμα fibre channel σε ένα fabric storage, ένα pool διευθύνσεων που εξαντλείται. Πηγαίνουν στον μηχανικό σε ετοιμότητα μέσα στο chat λειτουργιών καθώς συμβαίνουν, ώστε το log να γίνεται έγκαιρη προειδοποίηση αντί για νεκροψία.

Συναγερμός και στη σιωπή

Μια συσκευή που σταματά να στέλνει μοιάζει ακριβώς με μια συσκευή που δεν έχει τίποτα να πει. Άρα βάλτε συναγερμό στην απουσία: ένα event που πυροδοτείται όταν μια πηγή που κανονικά μιλά έχει μείνει σιωπηλή περισσότερο απ' όσο έχει μείνει ποτέ. Για συσκευές που είναι από τη φύση τους ήσυχες, δώστε τους κάτι να πουν, όπως μια γραμμή heartbeat που γράφει ένας timer κάθε ώρα, ώστε η σιωπή να γίνει σήμα. Μετά από κάθε αλλαγή που θα μπορούσε να διαταράξει τη διαδρομή, στείλτε ένα δοκιμαστικό μήνυμα και βρείτε το στην άλλη άκρη. Η ομάδα δικτύου μας περιγράφει αυτόν τον έλεγχο, και την υπόλοιπη αυτοδοκιμή της παρακολούθησης, στο Δοκιμάστε τη διαδρομή του συναγερμού, όχι το dashboard.

Ελέγξτε το δικό σας pipeline

• Εμφανίζεται κάποια συσκευή με περισσότερα από ένα ονόματα πηγής;
• Τι συμβαίνει με τα logs ενός server αν ο collector είναι εκτός λειτουργίας για δέκα λεπτά;
• Είναι όλα τα ρολόγια συγχρονισμένα στις ίδιες πηγές, με ρητές ζώνες ώρας;
• Μπορείτε να βρείτε τα μηνύματα κάθε firewall σε ένα stream;
• Υπάρχει συναγερμός για μια πηγή που σώπασε;

Αν θέλετε logs στα οποία μπορείτε να βασιστείτε σε μια ανασκόπηση περιστατικού, θα χαρούμε να σας βοηθήσουμε να χτίσετε το pipeline και να το δοκιμάσετε. Μιλήστε με έναν μηχανικό

Related

Σχετικά: Τηλεμετρία δικτύου και ισχύος, logging, ανίχνευση DDoS · Παρακολούθηση στόλου και δρομολόγηση συναγερμών