Migration depuis les checks basés sur Python vers les checks SNMP Core (en Go)

Migration depuis les checks basés sur Python vers les checks SNMP Core (en Go)

Présentation

La version 7.27.0 de l’Agent Datadog prend en charge une nouvelle version des checks SNMP en Go. Celle-ci améliore la mémoire et les performances de l’Agent lors de la surveillance d’appareils avec SNMP. Ce guide vise à vous aider à migrer vers ces nouveaux checks core.

Nouveautés de l’Agent v7.27.0

  • Autodiscovery est désormais un processus de base de l’Agent. Il doit être chargé dans le principal check de l’intégration SNMP avec loader:core, sous init_config, et configuré dans le fichier principal datadog.yaml de l’Agent Datadog.

  • Il n’est désormais plus possible de faire référence à une MIB en indiquant son nom lisible uniquement. Ainsi, toutes les références aux OID doivent inclure leur adresse numérique, ainsi que leur nom lisible. Tous les profils fournis par Datadog ont été mis à jour. Toutefois, vous devez modifier les profils personnalisés. Des exemples de migration sont fournis ci-dessous.

  • Pour les checks Core, il n’est pas possible de compiler manuellement les MIB à utiliser en tant que profil. Par conséquent, les paramètres ci-dessous ne sont plus pris en charge :

    • mibs_folder
    • optimize_mib_memory_usage
    • enforce_mib_constraints
    • bulk_threshold (supprimé pour conserver d’autres fonctions GET)

Instructions

Pour les environnements avec un Agent de cluster Datadog ou sans Kubernetes

  1. Mettez à jour l’Agent Datadog en installant la version 7.27+ pour la plate-forme correspondante.

  2. Modifiez la section init_config dans le check SNMP afin d’indiquer le nouveau check core dans snmp.d/conf.yaml.

  init_config
      loader: core
  1. Uniquement si vous utilisez Autodiscovery ou l’analyse de sous-réseaux : déplacez la configuration de chaque instance (sous-réseau) depuis la configuration du check SNMP vers le fichier principal datadog.yaml de l’Agent Datadog.
listeners:
  - name: snmp
snmp_listener:
  workers: 100              # nombre de workers utilisés pour découvrir simultanément des appareils
  discovery_interval: 3600  # secondes
  configs:
    - network: 1.2.3.4/24   # notation CIDR, nous vous conseillons de ne pas indiquer plus de /24 blocs
      version: 2
      port: 161
      community: ***
    tags:
      - "key1:val1"
      - "key2:val2"
    - network: 2.3.4.5/24
      version: 2
      port: 161
      community: ***
      tags:
      - "key1:val1"
      - "key2:val2"
listeners:
  - name: snmp
snmp_listener:
  workers: 100              # nombre de workers utilisés pour découvrir simultanément des appareils
  discovery_interval: 3600  # intervalle entre chaque découverte automatique, en secondes
  configs:
    - network: 1.2.3.4/24   # notation CIDR, nous vous conseillons de ne pas indiquer plus de /24 blocks
      snmp_version: 3
      user: "user"
      authProtocol: "fakeAuth"
      authKey: "fakeKey"
      privProtocol: "fakeProtocol"
      privKey: "fakePrivKey"
      tags:
        - "key1:val1"
        - "key2:val2"
    - network: 2.3.4.5/24
      version: 3
      snmp_version: 3
      user: "user"
      authProtocol: "fakeAuth"
      authKey: "fakeKey"
      privProtocol: "fakeProtocol"
      privKey: "fakePrivKey"
      tags:
        - "key1:val1"
        - "key2:val2"

Spécificités de l’Agent de cluster Datadog

Certains paramètres de snmp_listener ont été modifiés. Par exemple, network_address a été remplacé par network, tandis que community_string a été remplacé par community. Vous trouverez ci-dessous la liste complète des modifications de paramètres :

Configurations d’intégration (Python et core)snmp_listener
community_stringcommunity
network_addressnetwork
authKeyauthentication_key
authProtocolauthentication_protocol
privKeyprivacy_key
privProtocolprivacy_protocol
snmp_versionversion
discovery_allowed_failuresallowed_failures, configuration principale : snmp_listener.allowed_failures

Migration des profils personnalisés (distincts du déploiement)

Il n’est plus possible de faire référence à des OID en indiquant uniquement leur nom lisible. Vous pouvez spécifier leur adresse (nom de table et index) ou l’adresse de l’entrée MIB. Si vous avez créé des profils ou modifié des profils existants, migrez-les vers le nouveau format. Voici des exemples de migration :

Symboles scalaires

Avant l’Agent v7.27.0 :

scalar_symbols.yaml

metrics:
  - MIB: HOST-RESOURCES-MIB
  symbol: hrSystemUptime

Avec l’Agent v7.27.0 :

scalar_symbols_7_27.yaml

metrics:
  - MIB: HOST-RESOURCES-MIB
  symbol:
    OID: 1.3.6.1.2.1.25.1.1.0
    name: hrSystemUptime

Symboles de table

Avant l’Agent v7.27.0 :

table_symbols.yaml

metrics:
  -MIB: HOST-RESOURCES-MIB
  table: hrStorageTable
  symbols:
    - hrStorageAllocationUnits
    - hrStoageSize
  metrics_tags:
    - tag: storagedec
      column: hrStorageDescr

Avec l’Agent v7.27.0 :

table_symbols_7_27.yaml

metrics:
  -MIB: HOST-RESOURCES-MIB
  table:
    OID: 1.3.6.1.2.1.25.2.3
    name: hrStorageTable
  symbols:
    - OID: 1.3.6.1.2.1.25.2.3.1.4
      name: hrStorageAllocationUnits
    - OID: 1.3.6.1.2.1.25.2.3.1.5
      name: hrStoageSize
  metrics_tags:
    - tag: storagedec
      column:
        OID: 1.3.6.1.2.1.25.2.3.1.3
        name: hrStorageDescr

Tags de métriques

Avant l’Agent v7.27.0 :

metrics_tags.yaml

metrics_tags:
  - symbol: sysName
    tag: snmp_host

Avec l’Agent v7.27.0 :

metrics_tags_7_27.yaml

metrics_tags:
  - OID: 1.3.6.1.2.1.1.5.0
    symbol: sysName
    tag: snmp_host