• /
  • EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

Configuração avançada para monitoramento de rede

Se você quiser explorar todas as opções que pode usar ao configurar o monitoramento da sua rede, consulte as seções a seguir.

snmp-base.yaml

Aqui está um exemplo das diversas opções de configuração disponíveis no arquivo snmp-base.yaml usado pela imagem Docker ktranslate para pesquisar dispositivos SNMP e de dados de fluxo. Você também pode ver um exemplo muito comentado no repositório KTranslate no 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

Segredos do provedor de nuvem

O agente de monitoramento de rede tem suporte integrado para recuperação de chaves do AWS Secrets Manager, Azure Key Vault e GCP Secret Manager.

Importante

SNMPv1 e SNMPv2c não suportam o uso de segredos de nuvem, pois os próprios protocolos enviam suas strings de comunidade por meio de texto simples por padrão. Se você estiver preocupado com a segurança da sua autenticação SNMP, atualize para usar o SNMPv3.

Opções de SNMPv3

Configuração de pesquisa API

Dica

Você também pode usar segredos do provedor de nuvem na configuração de autenticação da API.

Arquivos de configuração externos

Para oferecer suporte a uma ampla variedade de necessidades de configuração e automação, você pode usar arquivos externos montados em volume em seu contêiner Docker para desacoplar determinados elementos do arquivo de configuração padrão. Você precisará incluir o argumento mount abaixo no comando docker run , com um argumento por arquivo de configuração externo.

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

A sintaxe desses arquivos é "@fileName.yaml", incluindo as aspas duplas.

O match_attributes

Para oferecer suporte à filtragem de dados que não criam valor para suas necessidades de observabilidade, você pode definir o mapa de atributos global.match_attributes.{} e/ou devices.[].match_attributes.{} .

Isso fornecerá filtragem no nível ktranslate , antes de enviar dados para o New Relic, proporcionando controle granular sobre o monitoramento de itens como interfaces.

O comportamento padrão deste mapa é uma condição OR , mas você pode substituí-la e forçar um operador AND prefixando o nome da sua chave com !. Isso também é útil para retornar apenas itens correspondentes e omitir todos os resultados null e "" (vazios).

O response_time e ping_only

Para suportar o monitoramento de dispositivos onde as estatísticas de desempenho não estão acessíveis ou disponíveis, ou em casos simples onde o monitoramento do tempo de ida e volta (RTT) básico é necessário, você pode definir o atributo global.response_time ou devices.[].ping_only como true.

Este recurso usa o pacote go-ping para enviar pacotes ICMP (padrão) ou UDP sem privilégios para dispositivos a fim de coletar o tempo de ida e volta (RTT) médio, mínimo, máximo e desvio padrão. Este pacote também mostra a porcentagem de perda de pacotes para o endpoint com base no envio de um pacote/seg de ktranslate para o endereço IP do dispositivo, que pode ser substituído definindo o atributo devices.[].ping_interval_sec. Você pode alternar do uso padrão de pacotes ICMP privilegiados para UDP definindo a variável de ambiente KENTIK_PING_PRIV=false durante o tempo de execução do docker.

Definir o atributo global.response_time como true adicionará o monitoramento RTT à pesquisa SNMP existente. Para monitor dispositivos apenas com pacotes UDP|ICMP para RTT e sem sondagem SNMP, use devices.[].ping_only: true.

No New Relic, você pode ver os resultados desta pesquisa investigando a seguinte métrica:

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

Dica

Você pode usar o atributo ping_only em substituição ao atributo flow_only se desejar coletar a métrica RTT de um dispositivo de fluxo. Se ping_only e flow_only forem true, o dispositivo será tratado como um dispositivo flow_only .

O flow_only

Para oferecer suporte ao monitoramento de dispositivos onde você deseja coletar apenas dados de fluxo, você pode definir o atributo devices.<deviceName>.flow_only como true.

Isso gerará uma entidade Flow Device que terá telemetria apenas no namespace do evento KFlow . Como alternativa, a coleta de telemetria de fluxo de um dispositivo que está em seu arquivo de configuração como um dispositivo SNMP adicionará a decoração dos dados KFlow à entidade pré-existente, como Router ou Firewall.

No New Relic, você pode ver os resultados desta pesquisa investigando o seguinte evento:

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

Aplicativo de mapeamento de dados de fluxo

Por padrão, a telemetria de fluxo é mapeada para um aplicativo conhecido com base na avaliação da porta da camada 4 em uso em uma conversa de fluxo específica. Se necessário, você pode substituir o mapeamento padrão fornecendo um arquivo YAML durante o tempo de execução Docker para a sinalização -application_map. Isso permitirá que você especifique nomes de aplicativos com base nas portas que você identificar.

Sintaxe de exemplo:

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

Filtragem de entrada de dados de fluxo

Por padrão, o contêiner de dados de fluxo coletará e processará cada pacote de fluxo recebido. Se necessário, você pode adicionar um filtro de inclusão à sinalização -nf.source que ignorará todo o tráfego que não corresponda ao filtro fornecido.

Recarregando automaticamente perfis SNMP personalizados

Por padrão, o contêiner Docker ktranslate deve ser destruído e reconstruído manualmente para incorporar alterações nos perfis SNMP no caminho mib_profile_dir. Este é um comportamento normal na maioria das implantações, pois a imagem Docker extrai os perfis mais recentes disponíveis no repositório público de perfis snmp. Em situações em que você fornece perfis personalizados, você pode usar a configuração watch_profile_changes para permitir que o contêiner atualize automaticamente as configurações subjacentes e os perfis SNMP do contêiner.

Importante

Isso não é recursivo devido a uma limitação na biblioteca do observador. Portanto, se um perfil for alterado em um subdiretório, você também deverá editar um arquivo de nível superior para acionar a alteração.

Assumindo esta estrutura de diretórios:

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

Você precisará colocar um novo arquivo na raiz do diretório e alterá-lo manualmente para acionar este ciclo de atualização. Uma maneira fácil de implementar isso é simplesmente gravar um timestamp em um arquivo como last_updated.txt quando sua alteração for enviada.

.
└── /snmp-profiles/
    ├── last_updated.txt
    └── profiles/
        └── kentik-snmp/
            ├── 3com
            ├── _general
            ├── a10networks
            └── ...
Copyright © 2024 New Relic Inc.
CarreirasTermos de serviçoPolítica do DMCAAviso de privacidadePolítica de cookiesUK Slavery Act

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