Calendrier de l'Avent NetOpsCoding 2016 Entrée 12/8 minutes.

introduction

Lors d'un événement appelé "Juniper Cloud Builder Community" organisé par Juniper le 1er décembre J'ai donné une conférence sous le titre de "Winnig avec surveillance".

Heureusement, pendant l'événement, j'ai reçu un certain nombre de voix disant «Veuillez me donner du matériel de présentation». Je voudrais profiter de cette occasion pour le rendre public.

Le temps de conférence de l'événement était relativement court, 25 minutes, et j'ai dû raser environ la moitié du matériel que j'ai créé. Comme c'est beaucoup, je posterai seulement le résumé dans cette entrée.

Le contenu de la conférence lors de l'événement Fonction de télémétrie dont on parle souvent dans la catégorie Surveillance ces dernières années (Contrairement à SNMP, le périphérique réseau lui-même envoie des métriques) est une implémentation. Validez OpenNTI (ne remplace pas le support officiel de Juniper) Il s'agit de confirmer l'utilité de la fonction de télémétrie.

Architecture de surveillance

En guise d'examen, sur l'architecture de surveillance

Dans le type d'extraction, le collecteur envoie une demande à une cible telle qu'un nœud de réseau pour collecter des informations. En revanche, la cible renvoie une réponse.

En revanche, dans le type Push, la cible est unilatéralement un collecteur comme SNMP Trap et SYSLOG. C'est un type qui envoie des informations.

Comme vous pouvez le voir, contrairement au type Pull avec demande / réponse Je pense que le type Push est une architecture avec de fortes caractéristiques temps réel.

Cependant, personnellement, je ne veux pas parler de ce qui est le meilleur, du type Pull ou du type Push, donc je pense que c'est un bon choix. (Par exemple, le type Pull peut mesurer les retards par demande / réponse et convient à la surveillance de la vie et de la mort).

Classification du système de surveillance

Ce qui suit est la classification du système de surveillance, mais comme il n'est pas possible de classer clairement J'espère que vous ne pourrez le prendre qu'à titre d'exemple.

En réalité, il existe différentes combinaisons et la source de données backend peut être sélectionnée. Même dans l'architecture, l'existence de SNMP ne peut être ignorée. Je pense que la plupart des types Push prennent en charge le type Pull avec des plug-ins, etc.

SNMP Je pense que le protocole appelé SNMP est inévitable dans Monitoring. Voici les points forts et les problèmes.

J'ai trop à parler de SNMP, je vais donc l'omettre.

État de mise en œuvre de la télémétrie des fournisseurs de réseau

■Cisco ・ La fonction de télémétrie a été implémentée dans IOS XR 6.X (L'intervalle le plus court pour sauter la métrique semble être de 5 secondes jusqu'à présent)

・ Exemple de mise en œuvre 　　IOS XR 6.X + Streaming Telemetry Collector Stacks

■Arista ・ Des fonctions de télémétrie telles que LANZ ont été implémentées dès le début. -Récemment, les informations collectées par différentes fonctions de Tracer (VM Tracer, Container Tracer) sont accumulées dans NetDB. Il est désormais possible d'analyser avec CloudVision

・ Exemple de mise en œuvre 　　NetDB + CloudVision 　　EOS Splunk Extension + Splunk Apps 　　LANZ + CorvilNet

■Juniper ・ De QFX5100 à Insight Technology (appelé Analyticsd dans cette entrée) Réalisez la télémétrie avec une fonction appelée ・ Implémenté avec une fonction appelée JTI (Junos Telemetry Interface) même dans MX etc.

・ Exemple de mise en œuvre 　　Analyticsd + Cloud Analytics Engine + Network Director 　　Analyticsd + Contrail 　　docker-junos-datadog 　　junos-telemetry-splunk 　　NetReflex 　　BizReflex

** OpenNTI ⇒ ** Pour le matériel de conférence

Comme il existe de nombreuses animations, nous les avons téléchargées sur docs.com.
Puisqu'il s'agit d'une diapositive qui nécessite des explications supplémentaires, elle peut être difficile à comprendre.

Supplément aux documents publics (ajouté le 2016/12/16)

P.6 Il existe un processus appelé "Data Streaming Collector" dans OpenNTI Il s'agit du traitement utilisant la fonction de télémétrie du périphérique réseau (type Push). Il existe également un processus appelé «Agent de collecte de données» Il s'agit d'un processus de récupération de données via Netconf (type Pull). Le dernier "SYSLOG" n'envoie pas le journal de tous les périphériques réseau J'essaie de n'envoyer que des événements spécifiques (tels que commit complet) (qui peuvent être utilisés plus tard pour l'analyse).

P.8 Il s'agit d'un exemple de paramètre pour Analyticsd, mais la valeur du seuil de profondeur de l'élément de paramètre est assez faible. Dans certains cas, il peut être nécessaire de modifier la valeur.

P.9 Ce qui peut être réalisé en utilisant la fonction de télémétrie ・ Surveillance du tampon de paquets et du retard de communication ・ Surveillance des microrafales ・ Surveillance PPS large / multicast

Mais ces avantages sont Scènes susceptibles de causer des problèmes en tant que fournisseur de services, telles que la prévention des impacts sur les services, leur détection immédiate et l'obtention de preuves (Par exemple, des retards de communication se produisent, la preuve d'une communication qui remplit momentanément la bande est supprimée, des tempêtes sont détectées, etc.) C'est efficace dans.

P.11 Jvision peut spécifier autre chose que Interface pour la ressource d'élément de réglage, et [lance diverses opérations à partir de JUNOS 16.1R3](http://www.juniper.net/techpubs/en_US/junos16.1/information-products/topic- collections / release-notes / 16.1 / topic-105380.html # jd0e6650) Il semble que diverses informations puissent être obtenues (opération non vérifiée).

P.17 Lorsque OpenNTI démarre, vous pouvez accéder à l'interface graphique Web et voir les données collectées. «Tableau de bord du collecteur de flux de données» correspond aux données collectées par la fonction de télémétrie. Ce sera le tableau de bord à afficher.

Soyez prudent si vous essayez d'utiliser OpenNTI tel quel. Il y a une petite erreur. Par exemple, "Data Streaming" est également correct pour ce nom de tableau de bord. La lettre «r» est manquante et devient «Data Steaming», ou les données affichées sont en fait Il devrait afficher les données de diffusion de l'interface, mais il affiche les données de multidiffusion. Il y a pas mal d'erreurs.

P.18 "Tableau de bord de l'agent de collecte de données" peut voir les données acquises via Netconf. Il peut être utilisé pour contrôler si un processus spécifique de JUNOS a une fuite de mémoire.

P.20 Le premier graphique est surveillé à partir de Cacti à intervalles de 1 minute, Lorsque le trafic d'environ 9,4 Gbit / s est transmis pendant 30 secondes, 20 secondes et 10 secondes Seuls 4,5 Gbps, 2,5 Gbps et 1,5 Gbps circulent respectivement. En fait, 9,4 Gbps de trafic circulent, mais c'est la limite que Cacti peut reconnaître. (Bien sûr, il y a aussi des informations qui peuvent être identifiées avec le plug-in Realtime de Cacti, etc.). Le graphique suivant a été acquis par la fonction de télémétrie, et des informations précises peuvent être acquises même pendant 10 secondes.

Lorsque la ligne est remplie de DDoS à court terme, etc. et que le service devient indisponible Si la ligne était vraiment remplie par DDoS, etc. Il y a de nombreux cas où cela devient un problème avec l'utilisateur, et je pense qu'il y a peu de cas où le premier graphe Cacti est convaincant. Normalement, le graphique de trafic et les informations xFlow sont combinés pour résoudre le problème. Dans de nombreux cas, le feu ne peut pas être éteint en un jour ou deux. Je pense que pouvoir surveiller et enregistrer la situation réelle du trafic avec une grande précision est un grand avantage.

P.25 Le graphique supérieur montre le trafic généré par les utilisateurs qui ont appliqué la QoS. Le graphique en bas montre la communication qui a été abandonnée en raison des restrictions de QoS. Normalement, le trafic est surveillé au moyen d'interfaces physiques et logiques, etc. Une surveillance basée sur des règles est possible.

P.27 L'acquisition de données via Netconf a tendance à être un goulot d'étranglement Même si vous essayez de régler, le traitement SSH de PyEZ utilise Paramiko, et vous pouvez définir le ControlMaster, etc. Comme il ne peut pas être modifié, il n'est pas possible de regrouper les sessions SSH. Par conséquent, nous ne pouvons traiter que d'augmenter la multiplicité du traitement SSH (effectuer plusieurs fois l'enregistrement cron).

prime

Nous avons vérifié OpenNTI, mais nous ne prévoyons pas d'utiliser OpenNTI tel quel dans l'environnement de production. Nous prévoyons de construire un système de surveillance sur un serveur bare metal en détournant uniquement le mécanisme.

La raison en est qu'il est (maintenant) physiologiquement désagréable d'avoir une base de données dans le conteneur Docker. Avec le conteneur Docker, vous devez maintenant surveiller le conteneur lui-même. (Maintenant) il existe de nombreuses solutions de gestion et de surveillance des conteneurs. C'est une raison vague pour laquelle je veux voir la situation pendant un moment.

De plus, bien sûr, non seulement la partie visualisation, mais également le système d'alerte sont liés. Au départ, Kapacitor a été supposé car il est facile de se lier à InfluxDB. Bien qu'il soit en version bêta de Grafana 4.0, il a implémenté la fonction d'alerte. Ce sera également un candidat.