bonnes pratiques pour monitoring du réseau

Dans monitoring du réseau, New Relic utilise des agents pour collecter des données télémétriques du réseau, qui peuvent être utilisées pour monitorer les performances du réseau, identifier les goulots d'étranglement et résoudre les problèmes. Apprenez les bonnes pratiques pour déployer l'agent monitoring du réseau en fonction de l'architecture et de la déploiement de votre système.

Considérations relatives au déploiement

Ce guide fait référence à une architecture réseau courante avec les exigences suivantes :

Interrogation SNMP et collecte d'interruptions SNMP.
Collecte Syslog à partir des périphériques réseau.
Collecte de flux réseau dans les protocoles NetFlow v5, NetFlow v9, IPFIX et sFlow.
Prise en charge de plusieurs sites séparés par une distance géographique importante.

Considérations architecturales

La tâche d'un agent

Les tâches des agents individuels détermineront la conception de votre déploiement réseau. Voici quelques règles de base à suivre :

Les agents qui collectent des données SNMP peuvent également recevoir des interruptions SNMP par défaut.
Les agents qui reçoivent des données Syslog doivent s'exécuter seuls.
Les agents qui reçoivent des données de flux réseau peuvent devoir être isolés en fonction du type de modèle de flux collecté.

Agents de flux réseau et Syslog

Lorsque vous utilisez des agents Network Flow et Syslog, vous n'avez pas besoin d'un fichier de configuration personnalisé. Les paramètres par défaut de l'agent fonctionneront correctement car tous les paramètres de l'agent sont transmis au moment de l'exécution via des indicateurs.

Cependant, si vous ne fournissez pas de fichier de configuration avec des entrées dans la section des périphériques, les résultats envoyés aux API New Relic utiliseront un device_name résolu via DNS à partir de l'adresse IP dans le paquet respectif. Vous pouvez fournir un emplacement de serveur DNS personnalisé lors de l'exécution, mais pour un contrôle total avec la balise, vous devez fournir vos propres entrées dans la section des périphériques avec le paramètre flow_only défini sur true. C'est ce que l'administrateur souhaite généralement faire pour que le nom envoyé aux API New Relic corresponde au nom envoyé par l'interrogation SNMP du même périphérique.

Géographie

En raison de la dégradation de leur priorité dans les réseaux modernes, les protocoles SNMP et ICMP (ping) peuvent être affectés par une latence prolongée dans les temps d'aller-retour. Pour éviter les échecs d'interrogation dus à des délais d'attente, les agents doivent être créés à proximité de leurs appareils cibles.

Échelle de calcul

Les agents individuels sont généralement hébergés sur de très petits hôtes et ont des exigences minimales telles que décrites dans les exigences du conteneur KTranslate. Cependant, dans les scénarios d'interrogation intensive, vous devrez peut-être faire évoluer le processeur de l'hôte. La principale raison de la mise à l’échelle vers une empreinte CPU plus grande pour un agent est la quantité de charge présentée à la tâche. Dans ces situations, il est généralement préférable d’exécuter plusieurs agents pour équilibrer la charge plutôt que d’augmenter la taille totale de votre hôte, ce qui a des implications en termes de coûts.

Exemple d'architecture courante

Ce diagramme reflète un exemple d'architecture réseau avec les éléments suivants :

Chaque emplacement géographique dispose de ses propres agents locaux utilisés pour collecter et transmettre des données à New Relic :
- DC_01 (AMER):
  - Trois agents sur un hôte desservant l'emplacement DC_01 à New York.
  - processus conteneur, interrogation SNMP, collecte NetFlow v5 et collecte Syslog
  - Consideration:Cet hôte contient un sous-réseau privé de classe B (/16). Pour garantir que le travail ait le temps d'être terminé, la cible de découverte doit être divisée en sous-réseaux de tailles gérables.
- OFFICE_01 (APJ):
  - Un agent sur un hôte desservant l'emplacement OFFICE_01 à Sydney, en Australie.
  - Le conteneur traite l'interrogation SNMP et la collecte des interruptions SNMP avec découverte sur un sous-réseau /24.
- DC_02 (EMEA):
  - Trois agents sur un hôte desservant l'emplacement DC_02 à Dublin, en Irlande.
  - processus conteneur NetFlow v9, IPFIX et collection sFlow , chacun ciblant un port d'écoute différent sur l'hôte.
  - Consideration:Cet hôte dispose d'un sous-réseau privé de classe A encore plus grand (/8), mais il n'est pas nécessaire de faire évoluer les tâches car il n'y a pas besoin de découverte à cet emplacement. En fonction des flux par seconde, il peut être nécessaire d'étendre la capacité à des agents supplémentaires à l'avenir.

Diagram to visualize common network architecture

Maintenir votre déploiement

Après l'installation initiale, l'empreinte d'observabilité du réseau monitoring peut être maintenue à l'aide de diverses techniques. Il s'agit notamment d'intégrer les modifications des fichiers configuration avec des outils comme Ansible et de créer un pipeline GitOps autour de l'architecture pour prendre en charge le contrôle de version et les options « invité » où les équipes externes peuvent soumettre des modifications pour examen.

Le besoin le plus courant en matière de maintenance continue est de maintenir à jour la liste des appareils cibles. Cela peut être réalisé en utilisant trois méthodes de découverte principales :

La découverte automatique est le processus utilisé par l'agent KTranslate pour analyser une liste cible d'adresses IP et/ou de plages, effectuer une sonde d'activité, puis exécuter une analyse SNMP de base du système MIB-2 MIB pour tenter de faire correspondre le périphérique à un profil SNMP connu.

L'agent dispose d'indicateurs d'exécution d'agent intégrés (-snmp_discovery_min et -snmp_discovery_on_start) qui vous permettent de créer une planification d'événements de découverte SNMP récurrents. Cela automatise les tâches de découverte par rapport à la cible de la section discovery dans le fichier configuration , puis met automatiquement à jour le fichier avec de nouveaux périphériques et actualise le service pour accepter les modifications.

Avantages

Découverte sans intervention pour les plages d'adresses IP connues et les chaînes de communauté SNMP.
Corrélation automatique avec le profil SNMP approprié pour chaque périphérique.
Des mécanismes de sécurité sont en place pour éviter des réglages incorrects qui pourraient endommager votre fichier de configuration.
Inconvénients
Nécessite une liste cible préexistante d'adresses IP et de chaînes de communauté SNMP/authentification V3 dans la section discovery du fichier de configuration.
Les grands sous-réseaux risquent d'être sujets à des dépassements de délai (nous recommandons /16 et moins).
Les équipes qui utilisent des user_tags spécifiques à l'appareil dans leurs fichiers configuration auront du travail supplémentaire pour s'assurer que les balises des nouveaux appareils sont mises à jour.
Exemple
Il s'agit du modèle configuration natif trouvé si vous suivez l'installation guidée via l'interface utilisateur de New Relic :
```
devices: {}
trap:
  listen: '0.0.0.0:1620'
discovery:
  cidrs:
    - 192.168.0.0/24
  ignore_list: []
  debug: false
  ports:
    - 161
  default_communities:
    - public
  default_v3: null
  add_devices: true
  add_mibs: true
  threads: 4
  replace_devices: true
  check_all_ips: true
  use_snmp_v1: false
global:
  poll_time_sec: 300
  mib_profile_dir: /etc/ktranslate/profiles
  mibs_enabled:
    - IF-MIB
  timeout_ms: 3000
  retries: 0
```
Votre commande d'exécution Docker associée ressemblerait à ceci, en remplaçant $UNIQUE_NAME, $YOUR_NR_LICENSE_KEY et $YOUR_NR_ACCOUNT_ID:
bash
```
$docker run -d --name ktranslate-$UNIQUE_NAME \
>  --restart unless-stopped --pull=always -p 162:1620/udp \
>  -v `pwd`/snmp-base.yaml:/snmp-base.yaml \
>  -e NEW_RELIC_API_KEY=$YOUR_NR_LICENSE_KEY \
>  kentik/ktranslate:v2 \
>  -snmp /snmp-base.yaml \
>  -nr_account_id=$YOUR_NR_ACCOUNT_ID \
>  -metrics=jchf \
>  -tee_logs=true \
>  -service_name=$UNIQUE_NAME \
>  -snmp_discovery_on_start=true \
>  -snmp_discovery_min=180 \
>  nr1.snmp
```

La découverte manuelle utilise le même mécanisme que la découverte automatisée, mais elle vous donne plus de contrôle. Avec la découverte manuelle, vous pouvez exécuter un agent sur mesure ad hoc, ce qui signifie que vous pouvez l'exécuter quand vous le souhaitez et que vous pouvez consulter et manipuler les résultats selon vos besoins. Il s’agit de la méthode privilégiée pour les environnements où le tag est répandu ou lorsqu’il existe un bon niveau de contrôle de la part d’une équipe centralisée ajoutant de nouveaux périphériques au réseau. Cela réduit le besoin d’une analyse complète du sous-réseau, qui peut prendre du temps et être perturbante.

Avantages

Contrôle total sur la cible et les résultats, y compris la décoration tag .
Aide à prévenir les éventuels appareils qui ne sont pas dans le champ de votre empreinte monitoring .
Corrélation automatique avec le profil SNMP approprié pour chaque périphérique.
Des mécanismes de sécurité sont en place pour éviter des réglages incorrects qui pourraient endommager votre fichier de configuration.
Inconvénients
Un administrateur doit exécuter l'agent à la demande et à partir du même hôte sur lequel s'exécute votre agent de production pour garantir que la connectivité réseau/SNMP est testée correctement.
Le déplacement des résultats de la découverte vers le fichier de configuration de production est un processus manuel qui nécessite un redémarrage de l'agent de production afin de charger les nouveaux paramètres.
Exemple
Cette méthode de découverte suit l’option de déploiement d’origine pour les agents KTranslate. À un niveau élevé, le processus de découverte est :

Extrayez la dernière version de l’image de l’agent sur votre machine locale.
Copiez l’exemple de fichier de configuration snmp-base.yaml de l’image sur votre machine locale.
Modifiez le fichier de configuration pour mettre à jour la section discovery avec les paramètres dont vous avez besoin pour cidrs et default_communities.
lancement d'un agent de courte durée exécutant une tâche de découverte ad hoc.
Modifiez les modifications nécessaires aux périphériques résultants dans votre fichier de configuration.
Copiez les nouveaux périphériques de votre fichier de configuration de découverte dans le fichier de configuration de l'agent de production.
Redémarrez votre agent de production pour charger les nouveaux paramètres.
Pour utiliser cette méthode, suivez les étapes de la Configuration manuelle du conteneur.

La dernière option consiste à ignorer l’ensemble du processus de découverte et à ajouter manuellement les périphériques directement dans le fichier de configuration de production. En pratique, il est assez rare de voir ce modèle utilisé, car les options de découverte standard font automatiquement correspondre les appareils à leurs profils et garantissent que votre fichier de configuration est correctement formaté.

Avantages

Contrôle total sur la configuration des appareils et leurs décorations tag .
Inconvénients
Risque moyen de mauvaise configuration dans les paramètres. Cette méthode nécessite que vous connaissiez l'identifiant de l'objet système (SysOID) de l'appareil ainsi que que vous compreniez le profil que l'appareil ciblerait afin que vous puissiez identifier les MIB que vous souhaitez activer (tout cela est automatisé lors de la découverte).
Nécessite toujours un redémarrage de l'agent de production pour charger les nouveaux paramètres.
Exemple
Voici un exemple des paramètres de périphérique nécessaires pour monitorer avec succès un onduleur APC :
```
devices:
  ups_snmpv2c__10.10.0.201:
    device_name: ups_snmpv2c
    device_ip: 10.10.0.201
    snmp_comm: public
    oid: .1.3.6.1.4.1.318.1.3.27
    mib_profile: apc_ups.yml
    provider: kentik-ups
    user_tags:
      owning_team: dc_ops
...
global:
  ...
  mibs_enabled:
    - IF-MIB
    - PowerNet-MIB_UPS
    - UPS-MIB
```
Important
global.mibs_enabled doit être mis à jour pour pouvoir commencer à interroger un MIB. Lors de l'ajout de périphériques, vous devez vous assurer que ce paramètre est mis à jour avec une liste de noms MIB distincts trouvés dans les profils SNMP associés.
Les paramètres requis sont décrits en détail dans notre documentation pour les appareils et les blocs globaux.

Cette traduction automatique est fournie pour votre commodité.

bonnes pratiques pour monitoring du réseau

Considérations relatives au déploiement .css-21sua1{background:none;border:none;width:0;padding:0;}

Considérations architecturales

La tâche d'un agent

Agents de flux réseau et Syslog

Géographie

Échelle de calcul

Exemple d'architecture courante

Maintenir votre déploiement

Avantages

Inconvénients

Exemple

Avantages

Inconvénients

Exemple

Avantages

Inconvénients

Exemple

Important

Considérations relatives au déploiement