[grnog] Telemetry

[Athanasios Douitsis]

On Mon, Mar 13, 2017 at 11:06:49AM +0200, Andreas Polyrakis wrote:

> Καλημέρα Νίκο,
> 
> Αντίστοιχα προγραμματίζουμε και εμείς κάποιες αναβαθμίσεις, μετά από τις 
> οποίες το telemetry θα υποστηρίζεται και στο δίκτυο παραγωγής μας.
> 
> Σωστό το σχόλιό σου για το "ποιο πρόβλημα θέλουμε να λύσουμε" -- αν και 
> κάποιες φορές ενα νέο feature δημιουργεί εμπνεύσεις και ιδέες. Στην 
> περίπτωσή μας πάντως:
> - το snmp έχει φτάσει πολλές φορές στα όριά του (ειδικά σε συσκευές με 
> O(1000) interfaces), και αντίστοιχα έχουν φτάσει και οι monitoring 
> server μας.
> - το granularity (5min -> 5sec polling) είναι σίγουρα χρήσιμο κατά την 
> διάρκεια εργασιών ή προβλημάτων
> - μας ενδιαφέρει να κάνουμε "εύκολα" monitoring παραμέτρων που δεν 
> μπορείς να πάρεις από το snmp
> Κατά συνέπεια η συγκεκριμένη λειτουργικότητα έχει κεντρίσει την προσοχή 
> μας.

Καλησπέρα σε όλους,

(Αντρέα συμφωνώ μαζί σου και σίγουρα αυτά τα προβλήματα υπάρχουν και τα
έχουμε δει όλοι υποθέτω. Οπότε θεωρήστε το υπόλοιπο mail σαν ένα
παράπονο ή γκρίνια)

Προβλήματα επιδόσεων με το SNMP δεν έπρεπε να έχουμε εν έτει 2017.

- UDP θα μπορούσε κανείς να το θεωρήσει πιο "ελαφρύ" και πιο γρήγορο από
  TCP. Πάντως υπάρχει και δυνατότητα SNMP πάνω από TCP αλλά δεν είναι
  διαδεδομένο.
- Κωδικοποίηση των πακέτων κατά BER δεν νομίζω στο 2017 να αποτελεί
  πρόβλημα. Τα primitives είναι εντελώς primitive (integers, strings,
  κλπ), οπότε έχεις φτηνό serialization και ξεserialization.
- Με getbulk και μεγάλο repeat λύνεται και το πρόβλημα του back-n-forth
  που είχε κανείς με το getnext. Στέλνεις ένα getbulk και έρχονται πίσω
  100+ μεταβλητές.
- Το SNMP έχει και push και pull σαν υποπεριπτώσεις του transport.
  Μπορεί και ο agent να στείλει traps/informs.

Tι θα μπορούσε κανείς να κάνει για να μιλήσει πιο γρήγορα με μια
διαχειριζόμενη συσκευή; Το latency του SNMP είναι τρομερά χαμηλό αν πας
να ζητήσεις ένα συγκεκριμένο object id.

Αυτό που πράγματι αποτελεί πρόβλημα πολύ σοβαρό είναι (imho πάντα) το
SMI του SNMP, δηλαδή το σχήμα της πληροφορίας. Αντρέα, υποψιάζομαι τα
προβλήματα που αναφέρεις μεταφράζονται σε:

- Προσπαθεί κανείς να κάνει poll 1000 interfaces με SNMP και γίνεται
  μπάχαλο με τα indexes και την πληροφορία να είναι διεσπαρμένη σε
  διάφορα σημεία του δέντρου, κλπ.
- Επίσης, το ότι όλα είναι κρεμασμένα πάνω στο δέντρο δημιουργεί
  πρόβλημα έκφρασης σε πολλές περιπτώσεις. Δεν είναι τυχαίο που στο
  prometheus έχουν βάλει πολλαπλά labels χωρίς δομή.
- Ο agent της συσκευής πολλές φορές αντιδρά άσχημα όταν χρειαστεί να
  κάνει πράγματα παράλληλα. Και πάλι αυτό μπορεί να οφείλεται στο σχήμα.
- Ωραία, έχεις getbulk και πάει σφαίρα. Δυστυχώς όμως πρέπει να
  ακολουθείς τη σειρά των αντικειμένων μέσα στο δέντρο, που πολλές φορές
  δεν σε βοηθάει πολύ. Με άλλα λόγια το query expression που μπορείς να
  στείλεις προς τον agent είναι πρακτικά ανύπαρκτο. Δεν μπορείς π.χ. να
  ζητήσεις όλα τα αντικείμενα του ifTable με συγκεκριμένο instance. Ή
  μάλλον, μπορείς, αλλά είναι πολύ πιο δύσκολο από ό,τι έπρεπε να είναι.
  Και ακόμα πιο δύσκολο είναι να μεταφραστεί αυτό σε traps. ’ντε να πεις
  στον agent τι σε ενδιαφέρει, απλά δεν γίνεται.

Εν συντομία το SNMP έχει φανταστικό transport αλλά χάλια control.
Διαβάζοντας διαγώνια το document της Juniper για το telemetry, παρατηρώ
ότι το telemetry subscription εκτελεί χρέη control plane για το τι μας
ενδιαφέρει ενώ το telemetry εκτελεί χρέη data plane προς τον collector.
Nice, αυτό μπορεί να λύσει πολλά προβλήματα που έχουμε σήμερα.

Θερμούς χαιρετισμούς,
Θανάσης



> 
> Αυτό φυσικά δεν σημαίνει ξήλωμα των εργαλείων που ήδη έχουμε, αλλά 
> ενδεχόμενως σταδιακές βελτιώσεις.
> 
> Ανδρέας
> 
> ΥΓ: Οταν βρεθείς στην Ελλάδα θα με ενδιέφερε να ακούσω την εμπειρία σας 
> με το fusion!
> 
> 
> On 03/12/2017 04:10 PM, Nikos Leontsinis wrote:
> > Γεια σου Ανδρεα,
> >
> > Τρεχω 14.2R3.8 me fusion και λογω fusion που δεν υποστηριζεται στο 15 
> > περιμενω να βαλω το 16 release για να δω οτιδηποτε relevant γυρω απο 
> > το telemetry. θα γινει πολυ συντομα.
> >
> > Νομιζω οτι δεν υπαρχει κανενα προβλημα με το snmp οποτε πριν απο 
> > οποιοδηποτε marketing fluff
> > καλο ειναι να δουμε αν υπαρχει καποιο real use case στον service 
> > provider. Καλο ειναι να βλεπουμε τα microcongestion episodes που 
> > μπορει να ειναι και umitigated dos attacks η τα queue depths στα 
> > interfaces ωστοσο δεν εχω δει ενα compelling use case.
> >     Για παραδειγμα θα ειχε νοημα να χτισεις ενα service me sla se 
> > microseconds gia ena financial trading firm στην οποια περιπτωση θα 
> > ηταν επιβεβλημενο το PTP προκειμενου να μετρησεις one way delay me ena 
> > toso aggressive sla.
> >  Οποτε παμε για μια συζητηση γυρω απο το PTP vs NTP που ειναι ακομα 
> > στα σπαργανα και δεν ειμαι σιγουρος οτι θελουμε να την ανοιξουμε.
> >
> > Θα προτιμουσα να δω ποιο προβλημα θελουμε να λυσουμε πρωτα.
> >
> > Sensor telemetry με βαση οτι εχω παρακολουθησει ειναι κατι σαν in-site 
> > OAM οπου dedicated nodes inject and terminate probe flows onto which 
> > the intermediate nodes add the telemetry records?
> >
> > /nikos
> >
> >
> >
> >
> >
> > 2017-03-10 13:53 GMT+00:00 Andreas Polyrakis <apolyr at noc.grnet.gr 
> > <mailto:apolyr at noc.grnet.gr>>:
> >
> >     ρίως) στοιχείων μέσω ενός push μοντέλου (συσκευή->collector), που
> >     μάλιστα μπορεί να υλοποιείται και στο hardware, αντί του
> >     παραδοσιακού pull του snmp. Με τον τρόπο αυτό μπορεί κανείς να
> >     έχει πολύ πυκνότερα στατιστικά (πχ per second) χωρίς η συσκευή να
> >     ζορίζεται.
> >
> >
> >
> >
> >
> 
> 
> -- 
> -----------------------------------------------------------------------
> Andreas Polyrakis - apolyr at noc.grnet.gr
> GRNET NOC Technical Manager
> Greek Research & Technology Network - http://www.grnet.gr
> 7, Kifisias Av., 11523 Athens, Greece
> Mobile: +30 6972832445    Office: +30 2107474249   Fax: +30 2107474490
> -----------------------------------------------------------------------
> 

-- 
Athanasios Douitsis
National Technical University of Athens NOC
e: aduitsis at noc.ntua.gr | t: +302107722409