Monitoring των Boomi integrations: τι παρακολουθείτε και για τι ειδοποιείστε

Ο χειρότερος τρόπος να μάθετε ότι ένα integration απέτυχε είναι από έναν πελάτη: «Πλήρωσα την Παρασκευή, γιατί δεν έχει φύγει η παραγγελία μου;». Σε αυτό το άρθρο εξηγούμε πώς μοιάζει το καλό monitoring για integrations, και μετά πώς το στήνετε για Boomi integrations: ιστορικό εκτελέσεων, υγεία runtime, ειδοποιήσεις, και αποστολή σφαλμάτων στο εργαλείο monitoring που ήδη χρησιμοποιεί το υπόλοιπο IT.

Γιατί το «στείλε μου email σε σφάλμα» δεν αρκεί

Οι περισσότερες ομάδες ξεκινούν στέλνοντας email όταν αποτυγχάνει ένα process. Πιάνει κάποια προβλήματα και χάνει τα επικίνδυνα:

Το process που δεν έτρεξε ποτέ. Το runtime ήταν offline, το schedule απενεργοποιημένο, ή η πηγή σταμάτησε να στέλνει αρχεία. Χωρίς εκτέλεση, δεν υπάρχει σφάλμα.
Το process που πέτυχε με τίποτα. Το API του e-shop γύρισε κενή λίστα λόγω ληγμένου token από τη δική τους πλευρά. Κατάσταση: επιτυχία, μηδέν παραγγελίες.
Η συσσώρευση. Τα μηνύματα μπαίνουν σε ουρά γρηγορότερα απ’ όσο επεξεργάζονται. Τίποτα δεν αποτυγχάνει, μέχρι κάτι να κάνει timeout ώρες μετά.
Κόπωση από ειδοποιήσεις. Ένα email ανά αποτυχημένο έγγραφο, διακόσια emails σε μια διακοπή του ERP, και το πραγματικό πρόβλημα χάνεται.

Το pattern: τέσσερα είδη σήματος

Το καλό monitoring για integrations παρακολουθεί τέσσερα πράγματα:

Σήμα	Ερώτηση	Παράδειγμα ειδοποίησης
Αποτυχίες	Πήγε κάτι στραβά;	Ο συγχρονισμός παραγγελιών απέτυχε 3 φορές σε 15 λεπτά
Απουσία	Έγινε καν αυτό που περιμέναμε;	Κανένα επιτυχημένο export τιμολογίων από τις 02:00
Όγκος/συσσώρευση	Είναι φυσιολογικός ο όγκος δουλειάς;	0 παραγγελίες σε ώρες λειτουργίας· ουρά > 500
Λήξη/υγεία	Πρόκειται κάτι να χαλάσει;	Runtime offline· πιστοποιητικό λήγει σε 21 ημέρες

Κάθε ειδοποίηση πρέπει να έχει υπεύθυνο, σοβαρότητα και σύνδεσμο στο runbook που λέει τι κάνετε.

Βήμα 1: Process Reporting για το ιστορικό εκτελέσεων

Το Process Reporting στο Boomi δείχνει κάθε εκτέλεση: όνομα process, runtime, ώρα έναρξης, διάρκεια, κατάσταση, και πλήθος εισερχόμενων και εξερχόμενων εγγράφων. Φιλτράρετε ανά process, κατάσταση και χρονικό διάστημα, ανοίγετε μια εκτέλεση για να δείτε τα έγγραφα και το process log, και σε πολλές περιπτώσεις ξανατρέχετε τα έγγραφα που απέτυχαν.

Κάντε το συνήθεια, και τεκμηριωμένο βήμα στο runbook, κάθε διερεύνηση να ξεκινά από εδώ. Δύο πρακτικές το κάνουν πολύ πιο χρήσιμο:

Συνεπής ονοματολογία στα processes, για παράδειγμα Orders | E-shop to ERP, ώστε να δουλεύουν τα φίλτρα.
Tracked fields στα έγγραφα (αριθμός παραγγελίας, κωδικός πελάτη όπως C-1042), ώστε να ψάχνετε εκτελέσεις με επιχειρηματικό κλειδί αντί για ώρα. Η ακριβής ρύθμιση των tracked fields εξαρτάται από τον connector και την έκδοση.

Θυμηθείτε ότι το ιστορικό εκτελέσεων κρατιέται για περιορισμένο διάστημα και μπορεί να περιέχει δεδομένα εγγράφων· λάβετέ το υπόψη στη διατήρηση δεδομένων και στον GDPR.

Βήμα 2: Παρακολουθήστε την υγεία των runtimes

Στο Runtime Management (Atom Management σε παλαιότερες εκδόσεις), κάθε runtime (Atom, Molecule ή Atom Cloud) δείχνει την κατάστασή του. Ένα runtime που πέφτει offline σταματά όλα τα προγραμματισμένα processes που τρέχουν σε αυτό, οπότε είναι το πιο σημαντικό σήμα υγείας.

Για runtimes που φιλοξενείτε εσείς, παρακολουθήστε και τα βασικά: χώρο στον δίσκο (τα προσωρινά αρχεία και η αρχειοθέτηση μεγαλώνουν), μνήμη και τη διαθεσιμότητα του ίδιου του server. Τα τοπικά runtimes μπορούν να εκθέτουν metrics μέσω JMX, που τα διαβάζουν τα περισσότερα εργαλεία monitoring servers.

Αν χρησιμοποιείτε atom queues για ασύγχρονες ροές, ελέγχετε τακτικά το βάθος των ουρών και τις dead-letter ουρές στην προβολή διαχείρισης ουρών.

Βήμα 3: Email alerts και events

Το Boomi παράγει events για πράγματα όπως σφάλματα processes, αλλαγές κατάστασης runtime και μηνύματα που στέλνετε εσείς. Οι χρήστες μπορούν να εγγραφούν σε αυτά ως email alerts από τις ρυθμίσεις χρήστη, επιλέγοντας τύπους events και επίπεδα σοβαρότητας.

Φτιάξτε αποκλειστικό mailbox ή λίστα διανομής, για παράδειγμα integration-alerts@company.gr, με υπεύθυνη την ομάδα που έχει βάρδια.
Εγγράψτε το σε σφάλματα processes και αλλαγές κατάστασης runtime για την παραγωγή.
Κρατήστε χωριστές τις εγγραφές για τα περιβάλλοντα test, ή κλειστές, για να μην πνίγουν τις ειδοποιήσεις παραγωγής.

Επιχειρηματικά events με το Notify shape

Για συνθήκες που δεν είναι τεχνικά σφάλματα, χρησιμοποιήστε το Notify shape στο process με ενεργοποιημένα events. Για παράδειγμα, μετά τη λήψη παραγγελιών, ένα Decision shape ελέγχει αν το πλήθος είναι μηδέν σε ώρες λειτουργίας, και ένα Notify shape στέλνει event προειδοποίησης: Καμία παραγγελία από το e-shop μεταξύ 09:00 και 10:00. Αυτά τα events φτάνουν στα ίδια email alerts και στο API που περιγράφουμε παρακάτω. Συνδυάστε τα με τα patterns χειρισμού σφαλμάτων στο error handling και retries στο Boomi, ώστε και ένα σφάλμα που «πιάστηκε» να βγάζει ορατό event.

Βήμα 4: Στείλτε τα σφάλματα στο κεντρικό εργαλείο monitoring

Το email αρκεί για μικρές ομάδες. Αν το υπόλοιπο IT χρησιμοποιεί Datadog, Grafana, Azure Monitor ή κάτι αντίστοιχο, οι ειδοποιήσεις των integrations πρέπει να πηγαίνουν κι αυτές εκεί, με την ίδια βάρδια και κλιμάκωση. Δύο συνηθισμένες προσεγγίσεις:

Ανάγνωση από το Boomi Platform API. Ένα μικρό προγραμματισμένο job διαβάζει εκτελέσεις και events μέσω του Platform API (τα σχετικά objects περιλαμβάνουν ExecutionRecord και Event· ελέγξτε το τρέχον API reference για ακριβή πεδία και φίλτρα) και στέλνει metrics στο εργαλείο σας: αποτυχίες ανά process, εκτελέσεις ανά ώρα, χρόνος από την τελευταία επιτυχία.
Αποστολή από το process. Ένα subprocess χειρισμού σφαλμάτων, που καλείται από το Catch του Try/Catch στα processes σας, στέλνει ένα μικρό JSON στο HTTP endpoint του εργαλείου monitoring με όνομα process, περιβάλλον, μήνυμα σφάλματος και επιχειρηματικό κλειδί.

{
  "source": "boomi",
  "environment": "production",
  "process": "Orders | E-shop to ERP",
  "severity": "error",
  "businessKey": "SO-58812",
  "message": "ERP rejected order: customer C-1042 is blocked"
}

Μη στέλνετε ολόκληρα έγγραφα ή προσωπικά δεδομένα στο εργαλείο monitoring. Τα αναγνωριστικά και το μήνυμα σφάλματος αρκούν για να βρείτε την εκτέλεση στο Process Reporting.

Βήμα 5: Ειδοποιήσεις για απουσία και συσσώρευση

Οι ειδοποιήσεις «δεν έγινε τίποτα» χρειάζονται κάτι έξω από το ίδιο το process, γιατί ένα process που δεν τρέχει δεν μπορεί να αναφέρει ότι δεν έτρεξε:

Χρόνος από την τελευταία επιτυχία: από τα δεδομένα εκτελέσεων που διαβάζετε μέσω API, ειδοποίηση όταν το export τιμολογίων δεν έχει επιτυχημένη εκτέλεση από την αναμενόμενη ώρα.
Heartbeat: ένα μικροσκοπικό προγραμματισμένο process στέλνει «είμαι ζωντανό» κάθε λίγα λεπτά· το εργαλείο monitoring ειδοποιεί όταν σταματήσουν τα heartbeats. Πιάνει προβλήματα runtime και scheduler.
Όρια όγκου: ειδοποίηση όταν οι παραγγελίες σε ώρες λειτουργίας πέφτουν στο μηδέν, ή όταν το βάθος μιας ουράς ξεπερνά ένα όριο που έχετε μετρήσει ως μη φυσιολογικό.

Βήμα 6: Λήξη πιστοποιητικών και μυστικών

Τα πιστοποιητικά και τα client secrets είναι οι πιο προβλέψιμες αποτυχίες. Το Boomi δείχνει τα πιστοποιητικά με τις ημερομηνίες λήξης τους και, ανάλογα με τον λογαριασμό, ειδοποιεί για επερχόμενες λήξεις. Προσθέστε δικό σας κατάλογο και ειδοποιήσεις 30 έως 60 ημέρες νωρίτερα, όπως περιγράφουμε στο Διαχείριση μυστικών και πιστοποιητικών ανά περιβάλλον στο Boomi.

Πριν βγείτε στην παραγωγή

Κάθε process παραγωγής έχει υπεύθυνο και καταχώρηση στο runbook.
Οι ειδοποιήσεις πάνε σε ανθρώπους με βάρδια, όχι σε mailbox που δεν διαβάζει κανείς.
Υπάρχουν ειδοποιήσεις απουσίας για τα προγραμματισμένα processes, όχι μόνο για σφάλματα.
Οι «καταιγίδες» ομαδοποιούνται: μία ειδοποίηση «το ERP δεν απαντά», όχι μία ανά έγγραφο.
Χωρίς προσωπικά δεδομένα σε ειδοποιήσεις ή εξωτερικό monitoring.
Μηνιαία ανασκόπηση: αφαιρέστε τις θορυβώδεις, προσθέστε όσες σας έλειψαν σε περιστατικά.

Συμπέρασμα

Παρακολουθήστε τέσσερα σήματα (αποτυχίες, απουσία, όγκο και λήξεις), όχι μόνο σφάλματα. Στο Boomi, το Process Reporting και το Runtime Management δίνουν ιστορικό και υγεία, τα email alerts και τα events του Notify σηκώνουν το σήμα, και το Platform API τα φέρνει όλα στο εργαλείο monitoring που ήδη παρακολουθεί το υπόλοιπο IT. Για τη συνολική εικόνα της λειτουργίας των integrations, δείτε τον οδηγό μας DevOps για integrations.