• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

configuration avancée pour monitoring du réseau

Si vous souhaitez explorer toutes les options que vous pouvez utiliser lors de la configuration de la monitoring de votre réseau, consultez les sections suivantes.

snmp-base.yaml

Voici un exemple des différentes options de configuration disponibles dans le fichier snmp-base.yaml utilisé par l'image Docker ktranslate pour interroger les périphériques de données SNMP et de flux. Vous pouvez également voir un exemple fortement commenté dans le référentiel KTranslate sur GitHub.

# Configuration of every device monitored by this container
devices:
  # Sample of SNMP v2c device
  ups_snmpv2c__10.10.0.201:
    device_name: ups_snmpv2c
    device_ip: 10.10.0.201
    snmp_comm: $YOUR_COMMUNITY_STRING
    oid: .1.3.6.1.4.1.318.1.3.27
    description: "APC Web/SNMP Management Card (MB:v4.1.0 PF:v6.2.1 PN:apc_hw05_aos_621.bin AF1:v6.2.1 AN1:apc_hw05_sumx_621.bin MN:AP9537SUM HR:05 SN: ABC123DEF456 MD:05/21/2016) (Embedded PowerNet SNMP Agent SW v2.2 compatible)"
    last_checked: 2021-11-09T18:14:59.907821489Z
    mib_profile: apc_ups.yml
    provider: kentik-ups
    poll_time_sec: 300
    retries: 1
    timeout_ms: 5000
    user_tags:
      owning_team: dc_ops
    discovered_mibs:
    - PowerNet-MIB_UPS
    - TCP-MIB
    - UDP-MIB
    purge_after_num: 1
  # Sample of SNMP v3 device
  router_snmpv3__10.10.0.202:
    device_name: router_snmpv3
    device_ip: 10.10.0.202
    snmp_v3:
      user_name: $YOUR_USER_NAME
      authentication_protocol: $YOUR_AUTH_PROTOCOL
      authentication_passphrase: $YOUR_AUTH_PASSPHRASE
      privacy_protocol: $YOUR_PRIVACY_PROTOCOL
      privacy_passphrase: $YOUR_PRIVACY_PASSPHRASE
    oid: .1.3.6.1.4.1.9.1.544
    description: "Cisco IOS Software, 3800 Software (C3845-ADVENTERPRISEK9-M), Version
      15.1(3)T4, RELEASE SOFTWARE (fc1)\r\nTechnical Support: http://www.cisco.com/techsupport\r\nCopyright
      (c) 1986-2012 by Cisco Systems, Inc.\r\nCompiled Thu 24-May-12 04:27 by prod_rel_team"
    last_checked: 2021-11-09T18:14:59.907821489Z
    mib_profile: cisco-asr.yml
    provider: kentik-router
    user_tags:
      owning_team: core-networking
    discovered_mibs:
    - BGP4-MIB
    - CISCO-MEMORY-POOL-MIB
    - CISCO-PROCESS-MIB
    - IF-MIB
    - OSPF-MIB
    engine_id: "80:00:01:01:0a:14:1e:28"
    match_attributes:
      if_interface_name: "^Ten.*|^Gig.*"
      "!if_Alias": "[Uu]plink"
  # Sample of SNMP v1 device
  netbotz_snmpv1__10.10.0.203:
    device_name: netbotz_snmpv1
    device_ip: 10.10.0.201
    snmp_comm: $YOUR_COMMUNITY_STRING
    use_snmp_v1: true
    oid: .1.3.6.1.4.1.5528.100.20.10.2013
    description: "Linux netbotz930A7A 2.6.12 #307 Wed Dec 29 15:25:32 EST 2010 ppc"
    last_checked: 2021-11-09T18:14:59.907821489Z
    mib_profile: apc-netbotz.yml
    provider: kentik-netbotz
    user_tags:
      owning_team: sys_ops
    discovered_mibs:
    - IF-MIB
    - IP-MIB
    - TCP-MIB
    - UDP-MIB
    no_use_bulkwalkall: true
  # Sample of "flow only" device
  flow_only__10.10.0.210:
    device_name: flow_only
    device_ip: 10.10.0.210
    user_tags:
      owning_team: net_eng
    flow_only: true
  # Sample of "ping only" device
  ping_only__10.10.0.220:
    device_name: ping_only
    device_ip: 10.10.0.220
    provider: kentik-ping
    user_tags:
      owning_team: load_balancing
    ping_only: true
    ping_interval_sec: 5
  # Sample of Arista eAPI device
  arista_eapi_10.10.0.230:
    device_name: arista_eapi
    device_ip: 10.10.0.230
    snmp_comm: public
    oid: .1.3.6.1.4.1.30065.1.3011.7020.3735.24.2878.2
    description: "Arista Networks EOS version 4.22.9M running on an Arista
      Networks DCS-7020SR-24C2"
    last_checked: 2021-11-09T18:14:59.907821489Z
    mib_profile: arista-switch.yml
    provider: kentik-switch
    discovered_mibs:
    - ARISTA-BGP4V2-MIB
    - ARISTA-QUEUE-MIB
    - BGP4-MIB
    - HOST-RESOURCES-MIB
    - IF-MIB
    ext:
      ext_only: false
      eapi_config:
        username: $YOUR_ARISTA_API_USERNAME
        password: $YOUR_ARISTA_API_PASSWORD
        transport: https
        port: 443
  # Sample of Meraki Dashboard API device
  meraki_dashboard_api:
    device_name: meraki_controller
    device_ip: snmp.meraki.com
    provider: meraki-cloud-controller
    ext:
      ext_only: true
      meraki_config:
        api_key: $YOUR_MERAKI_API_KEY
        monitor_devices: true
        monitor_org_changes: true
        monitor_uplinks: true
        monitor_vpn_status: true
        organizations:
          - "Top Org.*"
        networks:
          - "Production"
          - "Guest"
        product_types:
          - appliance
        preferences:
          device_status_only: true
          hide_uplink_usage: false
          show_vpn_peers: true
          show_network_attr: true
# Configuration for receipt of SNMP Traps
trap:
  listen: 0.0.0.0:1620
  community: public
  version: ""
  transport: ""
  v3_config: null
  trap_only: false
  drop_undefined: false
# Configuration for the SNMP discovery job
discovery:
  cidrs:
  - 10.0.0.0/24
  - 10.0.0.202/32
  ignore_list:
  - 10.0.0.98
  - 10.0.0.99
  debug: false
  ports:
  - 161
  - 1161
  default_communities:
  - $YOUR_COMMUNITY_STRING_1
  - $YOUR_COMMUNITY_STRING_2
  - $YOUR_COMMUNITY_STRING_3
  use_snmp_v1: false
  default_v3: null
  add_mibs: true
  threads: 4
  add_devices: true
  replace_devices: true
  no_dedup_engine_id: false
  check_all_ips: true
global:
  poll_time_sec: 60
  drop_if_outside_poll: false
  mib_profile_dir: /etc/ktranslate/profiles
  mibs_db: /etc/ktranslate/mibs.db
  mibs_enabled:
  - ARISTA-BGP4V2-MIB
  - ARISTA-QUEUE-MIB
  - BGP4-MIB
  - CISCO-MEMORY-POOL-MIB
  - CISCO-PROCESS-MIB
  - HOST-RESOURCES-MIB
  - IF-MIB
  - OSPF-MIB
  - PowerNet-MIB_UPS
  timeout_ms: 3000
  retries: 0
  global_v3: null
  response_time: false
  user_tags:
    environment: production
  match_attributes:
    if_Description: ".*WAN.*"
  purge_devices_after_num: 0

Les secrets des fournisseurs de cloud

L'agent monitoring réseau dispose d'une prise en charge intégrée pour la récupération des clés d'AWS Secrets Manager, Azure Key Vault et de GCP Secret Manager.

Important

SNMPv1 et SNMPv2c ne prennent pas en charge l'utilisation de secrets cloud car les protocoles eux-mêmes envoient leurs chaînes de communauté via du texte brut par défaut. Si vous êtes préoccupé par la sécurité de votre authentification SNMP, veuillez effectuer une mise à jour pour utiliser SNMPv3.

Options SNMPv3

Configuration de l'interrogation API

Conseil

Vous pouvez également utiliser les secrets du fournisseur cloud dans votre configuration d’authentification API.

Fichiers de configuration externes

Pour prendre en charge une grande variété de besoins de configuration et d'automatisation, vous pouvez utiliser des fichiers externes que vous montez en volume dans votre conteneur Docker pour découpler certains éléments du fichier de configuration standard. Vous devrez inclure l'argument de montage ci-dessous dans votre commande docker run , avec un argument par fichier de configuration externe.

-v `pwd`/fileName.yaml:/fileName.yaml \

La syntaxe de ces fichiers est "@fileName.yaml", y compris les guillemets doubles.

Le match_attributes

Pour prendre en charge le filtrage des données qui ne créent pas de valeur pour vos besoins d'observabilité, vous pouvez définir la carte d'attributs global.match_attributes.{} et/ou devices.[].match_attributes.{} .

Cela fournira un filtrage au niveau ktranslate, avant d'envoyer des données à New Relic, vous donnant un contrôle précis sur monitoring d'éléments tels que les interfaces.

Le comportement par défaut de cette carte est une condition OR , mais vous pouvez la remplacer et forcer un opérateur AND en préfixant votre nom de clé avec !. Ceci est également utile pour renvoyer uniquement les éléments correspondants et omettre tous les résultats null et "" (vides).

Le response_time et ping_only

Pour prendre en charge monitoring des périphériques pour lesquels les statistiques de performances ne sont pas accessibles ou disponibles, ou dans les cas simples où monitoring du temps aller-retour (RTT) de base est requise, vous pouvez définir l'attribut global.response_time ou devices.[].ping_only sur true.

Cette fonctionnalité utilise le package go-ping pour envoyer des paquets ICMP (par défaut) ou UDP non privilégiés aux périphériques afin de collecter le temps aller-retour (RTT) moyen, minimum, maximum et écart type. Ce package affiche également le pourcentage de perte de paquets pour le point de terminaison en fonction de l'envoi d'un paquet/s de ktranslate à l'adresse IP du périphérique, qui peut être remplacé en définissant l'attribut devices.[].ping_interval_sec . Vous pouvez passer de l’utilisation par défaut des paquets ICMP privilégiés à UDP en définissant la variable d’environnement KENTIK_PING_PRIV=false pendant l’exécution de Docker.

La définition de l'attribut global.response_time sur true ajoutera monitoring RTT en plus de l'interrogation SNMP existante. Pour monitorer les périphériques avec uniquement les paquets UDP|ICMP pour RTT et aucune interrogation SNMP, utilisez devices.[].ping_only: true.

Dans New Relic, vous pouvez voir les résultats de ce sondage en examinant les paramètres suivants :

FROM Metric SELECT
  average(kentik.ping.AvgRttMs) AS 'Average',
  max(kentik.ping.MaxRttMs) AS 'Max',
  min(kentik.ping.MinRttMs) AS 'Min',
  average(kentik.ping.StdDevRtt) AS 'StdDev',
  latest(kentik.ping.PacketLossPct) AS 'Packet Loss %'
FACET device_name

Conseil

Vous pouvez utiliser l'attribut ping_only en remplacement de l'attribut flow_only si vous souhaitez collecter des métriques RTT à partir d'un périphérique de flux. Si ping_only et flow_only sont tous deux true, le périphérique sera traité comme un périphérique flow_only .

Le flow_only

Pour prendre en charge monitoring des appareils sur lesquels vous souhaitez uniquement collecter des données de flux, vous pouvez définir l'attribut devices.<deviceName>.flow_only sur true.

Cela générera une entité Flow Device qui n'aura de télémétrie que dans le KFlow événement espace de nommage. Alternativement, la collecte de la télémétrie de flux à partir d'un périphérique qui se trouve dans votre fichier de configuration en tant que périphérique SNMP ajoutera la décoration des données KFlow à l'entité préexistante, telle qu'un Router ou Firewall.

Dans New Relic, vous pouvez voir les résultats de ce sondage en examinant l'événement suivant :

FROM KFlow SELECT *
WHERE instrumentation.name = 'netflow-events'

Modélisation d'application de données de flux

Par défaut, la télémétrie de flux est mappée aux applications connues en fonction de l’évaluation du port de couche 4 utilisé sur une conversation de flux spécifique. Si nécessaire, vous pouvez remplacer la modélisation par défaut en fournissant un fichier YAML pendant l'exécution Docker à l'indicateur -application_map. Cela vous permettra de spécifier les noms d'application en fonction des ports que vous identifiez.

Exemple de syntaxe :

applications:
  - ports: [9092, 9093]
    name: kafka
  - ports: [80, 8080]
    name: http
  - ports: [443, 8443]
    name: https

Filtrage des données d'entrée de flux

Par défaut, le conteneur de données de flux collecte et traite chaque paquet de flux qu'il reçoit. Si nécessaire, vous pouvez ajouter un filtre d'inclusion à l'indicateur -nf.source qui ignorera tout le trafic ne correspondant pas au filtre que vous fournissez.

Rechargement automatique des profils SNMP personnalisés

Par défaut, le conteneur Docker ktranslate doit être détruit et reconstruit manuellement pour intégrer les modifications apportées aux profils SNMP dans le chemin mib_profile_dir . Il s'agit d'un comportement normal dans la plupart des déploiements, car l'image Docker récupère les derniers profils disponibles dans le référentiel public snmp-profiles. Dans les situations où vous fournissez des profils personnalisés, vous pouvez utiliser le paramètre watch_profile_changes pour permettre au conteneur d'actualiser automatiquement la configuration sous-jacente et les profils SNMP du conteneur.

Important

Ce n'est pas récursif en raison d'une limitation dans la bibliothèque watcher. Ainsi, si un profil change dans un sous-répertoire, vous devez également modifier un fichier de niveau supérieur pour déclencher la modification.

En supposant cette structure de répertoire :

.
└── /snmp-profiles/
    └── profiles/
        └── kentik-snmp/
            ├── 3com
            ├── _general
            ├── a10networks
            └── ...

Vous devrez placer un nouveau fichier à la racine du répertoire et le modifier manuellement pour déclencher ce cycle d'actualisation. Un moyen simple de mettre en œuvre ceci est d’écrire simplement un horodatage dans un fichier tel que last_updated.txt lorsque votre modification est soumise.

.
└── /snmp-profiles/
    ├── last_updated.txt
    └── profiles/
        └── kentik-snmp/
            ├── 3com
            ├── _general
            ├── a10networks
            └── ...
Droits d'auteur © 2025 New Relic Inc.
RecrutementConditions de servicePolitique DMCAAvis de confidentialitéCookiesLoi britannique sur l'esclavage

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.