Te ofrecemos esta traducción automática para facilitar la lectura.
En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.
Si desea explorar todas las opciones que puede utilizar al configurar el monitoreo de su red, consulte las siguientes secciones.
snmp-base.yaml
A continuación se muestra un ejemplo de las diversas opciones de configuración disponibles en el archivo snmp-base.yaml utilizado por la imagen Docker ktranslate para sondear dispositivos de datos de flujo y SNMP. También puede ver una muestra muy comentada en el repositorio de KTranslate en GitHub.
# Configuration of every device monitored by this container
Indica si se debe habilitar el registro de nivel de depuración durante el sondeo SNMP. De forma predeterminada, está configurado en false.
port
Puerto al que enviar la consulta SNMP. De forma predeterminada, está configurado en el puerto 161.
oid
✓ (Requerido para el sondeo SNMP)
El systemObjectID | sysObjectID | sysOID descubierto para el dispositivo. Esto se utiliza para hacer coincidir el dispositivo con un perfil SNMP conocido y establecer el atributo provider . Si no se encuentra ninguna coincidencia, esto establece el provider como un dispositivo kentik predeterminado .
descripción
El sysDescr descubierto del dispositivo. Este campo es informativo.
last_checked
Timestamp cuando este dispositivo fue descubierto por última vez por la imagen de la Docker ktranslate. Este campo es informativo.
mib_profile
✓ (Requerido para el sondeo SNMP)
Archivo de perfil SNMP asociado con este dispositivo durante la ejecución de descubrimiento según su sysOID. If this starts with a bang (!) token, it will override the automatic matching from the sysOID and use a manual override. Ej: "!cisco-asa.yml" (se requieren comillas).
provider
✓ (Requerido para New Relic)
Valor empleado durante la síntesis de entidad para New Relic. Esto se crea automáticamente en función del mib_profile coincidente y debe coincidir con una de las reglas en el repositorio de definiciones de entidad para que se pueda crear una entidad. Si agrega dispositivos manualmente, deberá tener cuidado y cerciorar de que este valor sea válido.
poll_time_sec
Indica la frecuencia de sondeo SNMP en segundos. Esta configuración se utiliza para anular el atributo global.poll_time_sec .
reintentos
Indica el número de intentos de volver a intentar sondear los OID de SNMP. Esta configuración se utiliza para anular el atributo global.retries .
timeout_ms
Indica el tiempo de espera del sondeo SNMP en milisegundos. Esta configuración se utiliza para anular el atributo global.timeout_ms .
user_tags
key:value atributo pair para darle más contexto al dispositivo. La etiqueta en este nivel se agregará a cualquier etiqueta aplicada en el atributo global.user_tags .
discovered_mibs
Lista de MIB extraídas de mib_profile coincidentes a las que este dispositivo puede responder. Este campo es informativo.
engine_id
El ID de motor único descubierto para el agente SNMP de este dispositivo. Generalmente se encuentra durante el descubrimiento de SNMP v3. Este campo es informativo.
match_attributes
attribute:regex pares para agregar métrica a la lista de permitidos. Los pares de este nivel se agregarán a cualquier par aplicado en el atributo global.match_attributes . Utiliza la sintaxis RE2 y tiene un operador OR predeterminado. Tecla de prefijo con ! para forzar a AND operadores.
monitor_admin_shut
Indica si se deben monitor las interfaces en estado Administratively Shutdown. De forma predeterminada, está configurado en false.
no_use_bulkwalkall
Deshabilita la acción de solicitud SNMP GETBULK cuando true. De forma predeterminada, está configurado en false.
response_time
Indica si el sondeo de tiempo de respuesta está habilitado para este dispositivo. De forma predeterminada, está configurado en false.
ping_only
Deshabilita todos los sondeos SNMP y habilita el sondeo de tiempo de respuesta para este dispositivo cuando true. Esta configuración anulará el atributo global.response_time . De forma predeterminada, está configurado en false. Querrá asegurarse de haber incluido la línea provider: kentik_ping para cada dispositivo ping_only.
ping_interval_sec
Esta configuración se utiliza para anular la velocidad predeterminada de 1 paquete/seg utilizada durante ping_only | response_time encuesta.
flow_only
Deshabilita todos los sondeos SNMP cuando true. De forma predeterminada, está configurado en false.
purge_after_num
Elimina el dispositivo del archivo de configuración después de que X trabajos de descubrimiento programados hayan fallado. This setting overrides the global purge_devices_after_num setting. Establezca esto en -1 para conservar el dispositivo para siempre, o cualquier número entero >= 1 para configurar un umbral de purga. (Predeterminado: 0)
Deshabilita todos los sondeos SNMP para esta configuración device_name . Predeterminado: false.
Nombre clave
Requerido
Descripción
escuchar
✓
Puerto IP de escucha para recibir capturas SNMP. De forma predeterminada, está configurado en 0.0.0.0:1620 y utilizamos una redirección en su comando docker run ... para redirigir el UDP 162 más común en el host al UDP 1620 en el contenedor. La redirección se realiza con esta bandera. -p 162:1620/udp
comunidad
Cadena de comunidad SNMPv1/v2c para recibir capturas SNMP. De forma predeterminada, seguimos procesando trampas entrantes incluso si no coinciden con esta comunidad.
versión
Versión SNMP a utilizar. Las opciones son v1, v2c y v3. De forma predeterminada, está configurado en v2c.
transporte
Protocolo de transporte SNMP a utilizar. Las opciones son TCP y UDP. De forma predeterminada, está configurado en UDP
Establecer esto en true evitará que el contenedor intente realizar cualquier sondeo SNMP o ICMP, que se utiliza en los casos en los que desea un contenedor que solo escuche las capturas entrantes.
drop_undefined
Establecer esto en true evitará que el contenedor reenvíe mensajes de captura SNMP que no estén definidos explícitamente en un perfil SNMP existente. (Predeterminado: false)
Matriz de direcciones IP que desea ignorar explícitamente durante todos los trabajos de descubrimiento.
depurar
Indica si se debe habilitar el registro de nivel de depuración durante el descubrimiento. De forma predeterminada, está configurado en false
ports
✓
Matriz de puertos de destino para escanear durante el sondeo SNMP.
default_communities
✓ (Requerido para SNMPv1/2c)
Matriz de cadenas de comunidad SNMPv1/v2c para escanear durante el sondeo SNMP. Esta matriz se evalúa en orden y el descubrimiento acepta la primera comunidad que pasa.
use_snmp_v1
✓ (Requerido para SNMPv1)
Indica si se debe utilizar SNMPv1 durante el descubrimiento. De forma predeterminada, está configurado en false
Múltiples configuraciones SNMPv3 para escanear durante el sondeo SNMP. Use this option OR default_v3, not both
add_devices
✓
Indica si se deben agregar dispositivos descubiertos a la sección devices del archivo snmp-base.yaml . De forma predeterminada, está configurado en true.
add_mibs
✓
Indica si se deben agregar MIB descubiertas a la sección global.mibs_enabled del archivo snmp-base.yaml . De forma predeterminada, está configurado en true.
hilos
✓
Límite entero de subprocesos que se utilizarán durante el descubrimiento. Debe ser menor que la cantidad de núcleos disponibles para el contenedor. De forma predeterminada está configurado en 4.
replace_devices
✓
Indica si se deben reemplazar los dispositivos descubiertos si ya existen en la sección devices del archivo snmp-base.yaml . De forma predeterminada, está configurado en true.
no_dedup_engine_id
Cuando se establece en true, deshabilita la deduplicación de dispositivos descubiertos si parece que son el mismo dispositivo, según su ID de motor SNMP informado. De forma predeterminada, está configurado en false
check_all_ips
Cuando se establece en true, obliga al trabajo de descubrimiento a intentar la conectividad SNMP con cada dirección IP de destino de la matriz cidrs , sin verificar primero la vitalidad a través del escaneo del puerto TCP. Esta configuración ralentizará los trabajos de detección, pero puede ayudar a evitar problemas en los que la detección falla en dispositivos que no figuran en su cidrs matriz con /32 anulaciones. De forma predeterminada, está configurado en false
Nombre clave
Requerido
Descripción
poll_time_sec
✓
Tiempo en segundos para sondear dispositivos. Esto se puede anular por dispositivo utilizando el atributo devices.<deviceName>.poll_time_sec . De forma predeterminada, está configurado en 60.
drop_if_outside_poll
Indica si se deben eliminar todos los valores de este ciclo si el sondeo tarda más que el valor establecido en poll_time_sec. De forma predeterminada, está configurado en false.
mib_profile_dir
Directorio para encontrar perfiles MIB seleccionados. Estos se incorporan automáticamente a la imagen ktranslate desde el repositorio de perfiles snmp de Kentik y se pueden anular en el tiempo de ejecución Docker creando un montaje de volumen de su propio directorio local de perfiles.
mibs_db
mibs_enabled
✓
Matriz de todas las MIB activas que sondeará la imagen Docker ktranslate. Esta lista se genera automáticamente durante el descubrimiento si el atributo discovery_add_mibs es true. Las MIB que no figuran aquí no serán sondeadas en ningún dispositivo en el archivo de configuración. Puede especificar una tabla SNMP directamente en un archivo MIB usando la sintaxis MIB-NAME.tableName . Ej: HOST-RESOURCES-MIB.hrProcessorTable.
timeout_ms
✓
Tiempo en milisegundos Tiempo de espera de consulta SNMP. Esto se puede anular por dispositivo utilizando el atributo devices.<deviceName>.timeout_ms . De forma predeterminada, está configurado en 3000.
reintentos
✓
Número de intentos fallidos de reintentar sondeos SNMP. Esto se puede anular por dispositivo utilizando el atributo devices.<deviceName>.retries . De forma predeterminada, está configurado en 0.
user_tags
key:value atributo pair para darle más contexto al dispositivo. La etiqueta en este nivel se aplicará a todos los dispositivos en el archivo de configuración.
match_attributes
attribute:regex pares para agregar métrica a la lista de permitidos. Los pares de este nivel se compararán con todos los dispositivos en el archivo de configuración. Utiliza la sintaxis RE2 y tiene un operador OR predeterminado. Tecla de prefijo con ! para forzar a AND operadores.
response_time
Indica si el sondeo de tiempo de respuesta está habilitado para todos los dispositivos en el archivo de configuración. De forma predeterminada, está configurado en false.
purge_devices_after_num
Elimina dispositivos del archivo de configuración después de que X trabajos de descubrimiento programados hayan fallado. Establezca esto en -1 para conservar los dispositivos para siempre, o cualquier número entero >= 1 para configurar un umbral de purga. De forma predeterminada, está configurado en 0.
Configura un observador para recargar subprocesos SNMP sobre cambios en los perfiles en la ruta mib_profile_dir. De forma predeterminada, está configurado en false.
SNMPv1 y SNMPv2c no admiten el uso de secretos de la nube, ya que los propios protocolos envían sus cadenas comunitarias en texto sin formato de forma predeterminada. Si le preocupa la seguridad de su autenticación SNMP, actualice para utilizar SNMPv3.
Para utilizar AWS Secrets Manager, deberá configurar las siguientes tres variables ambientales y proporcionarlas a Docker en tiempo de ejecución:
Nombre
Descripción
AWS_ACCESS_KEY_ID
Especifica la clave de acceso de AWS utilizada como parte de las credenciales para autenticar al usuario.
AWS_SECRET_ACCESS_KEY
Especifica la clave secreta de AWS utilizada como parte de las credenciales para autenticar al usuario.
AWS_REGION
Especifica la región de AWS a la que enviar solicitudes.
Para usar Azure Key Vault, deberá configurar las siguientes cinco variables ambientales y proporcionarlas a Docker en tiempo de ejecución:
Sugerencia
Debe configurar KT_AZURE_KEY_VAULT_NAME o KT_AZURE_KEY_VAULT_URL, no ambos. El valor predeterminado es usar KT_AZURE_KEY_VAULT_NAME y el agente usará un patrón de URL común: https://$KT_AZURE_KEY_VAULT_NAME.vault.azure.net/
Nombre
Descripción
KT_AZURE_KEY_VAULT_NAME
El nombre del almacén donde se almacena el secreto.
KT_AZURE_KEY_VAULT_URL
URL completa opcional para la API de llamada al objetivo.
Este es el secreto del cliente (contraseña) que se utiliza para la entidad de servicio durante la autenticación. Tenga en cuenta que este ID es para el value del secreto del cliente, no el ID del secreto en sí.
Para usar GCP Secret Manager, deberá configurar el siguiente montaje de volumen para un archivo JSON de credenciales junto con dos variables ambientales y proporcionarlas a la Docker en tiempo de ejecución:
Especifica la ruta del archivo local para la clave de la cuenta de servicio utilizada para autenticar al usuario. Este archivo se monta en volumen en el contenedor de la Docker y luego se hace referencia a él en la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.
Protocolo de autenticación SNMPv3. Los valores posibles son NoAuth, MD5 o SHA
authentication_passphrase
Frase de contraseña de autenticación SNMPv3
privacy_protocol
✓
Protocolo de privacidad SNMPv3. Los valores posibles son NoPriv, DES, AES, AES192, AES256, AES192C o AES256C
privacy_passphrase
Frase de contraseña de privacidad SNMPv3
context_engine_id
ID del motor de contexto SNMPv3
context_name
Nombre del contexto SNMPv3
Ejemplos:
Sugerencia
El uso de secretos de AWS, Azure o GCP también requerirá que proporcione las variables de entorno adecuadas y cualquier otra información de autenticación necesaria para que el agente consulte la API de destino.
Para admitir la ejecución de trabajos de descubrimiento con múltiples perfiles SNMP v3, puede reemplazar la clave discovery.default_v3 con la clave discovery.other_v3s , que contiene una matriz de configuración SNMPv3.
Esto también puede funcionar utilizando un administrador de secretos de un proveedor de la nube. Un ejemplo para AWS:
discovery:
other_v3s:
- aws.sm.$YOUR_SECRET_NAME_1
- aws.sm.$YOUR_SECRET_NAME_2
Configuración de sondeo API
Sugerencia
También puede utilizar secretos del proveedor de la nube en la configuración de autenticación de su API.
La integración de Arista eAPI recopila telemetría BGP y MLAG adicional que normalmente no está disponible a través del sondeo SNMP.
Los detalles de BGP se recopilan de este comando: show ip bgp summary vrf all
NRQL para encontrar telemetría BGP:
FROM Metric SELECT
max(kentik.eapi.bgp.InMsgQueue)AS'InQ',// Messages Queued from the Neighbor
max(kentik.eapi.bgp.MsgReceived)AS'MsgSent',// Messages Received from the Neighbor
max(kentik.eapi.bgp.MsgSent)AS'MsgRcvd',// Messages Sent to the Neighbor
latest(peer_state)AS'State',// State of the BGP session
latest(kentik.eapi.bgp.UpDownTime)AS'Up/Down',// Period the BGP session has been in current state
latest(kentik.eapi.bgp.Version)AS'V'// BGP version number
FACET
entity.name AS'Device',
router_id AS'Device IP',
peer AS'BGP Peer',
peer_asn AS'BGP Peer ASN',
vrf AS'VRF Name'
Los detalles de MLAG se recopilan de este comando: show mlag detail
NRQL para encontrar telemetría MLAG:
FROM Metric SELECT
latest(kentik.eapi.mlag.PortsConfigured)AS'Ports Configured',// Count of MLAG ports currently configured
latest(kentik.eapi.mlag.PortsDisabled)AS'Ports Disabled',// Count of MLAG ports in 'Disabled' state
latest(kentik.eapi.mlag.PortsActivePartial)AS'Ports Active-partial',// Count of MLAG ports in 'Active-partial' state
latest(kentik.eapi.mlag.PortsInactive)AS'Ports Inactive',// Count of MLAG ports in 'Inactive' state
latest(kentik.eapi.mlag.PortsActiveFull)AS'Ports Active-full',// Count of MLAG ports in 'Active-full' state
latest(kentik.eapi.mlag.PortsErrdisabled)AS'Ports Err-disabled',// Count of MLAG ports in 'Err-disabled' state
latest(config_sanity)AS'Config-Sanity',// Current result of 'config-sanity' check
latest(state)AS'State',// Current MLAG state
latest(neg_status)AS'Negotiation Status',// Current negotiation status between switches
latest(peer_address)AS'Peer Address',// Address of MLAG peer
latest(peer_link)AS'Peer Link',// Link name for MLAG peer
latest(peer_link_status)AS'Peer Link Status',// Status of MLAG peer
latest(local_interface)AS'Local Interface',// Local interface used for MLAG configuration
latest(local_intf_status)AS'Local Interface Status'// Status of local interface used for MLAG configuration
FACET
entity.name AS'Device',
domain_id AS'MLAG Domain ID'
Opciones de configuración
Nombre clave
Requerido
Descripción
eapi_config.username
✓
El nombre de usuario que se pasará al dispositivo para autenticar la autenticación eAPI.
eapi_config.password
✓
La contraseña que se debe pasar al dispositivo para autenticar la autenticación eAPI.
eapi_config.transport
Especifica el tipo de transporte de conexión que se utilizará. Los valores posibles son https y http. Predeterminado: https.
eapi_config.port
✓
El puerto TCP del extremo para la conexión eAPI.
La integración API del panel de Meraki extrae varias métricas relacionadas con el estado de su entorno Meraki. La combinación de opciones de configuración le permite configurar diferentes escenarios de monitoreo para sus necesidades y crea una entidad en su cuenta de New Relic .
Organización métrica se recopilan de forma predeterminada bajo la kentik.meraki.organization.Count métrica que se utiliza exclusivamente para generar la Meraki Organization entidad. Esto es principalmente para permitir la visualización de la jerarquía de Meraki para alinear redes y dispositivos con su organización principal.
NRQL para encontrar telemetría de cambios de configuración de la organización:
FROM KExtEvent SELECT*
meraki_config.preferences.show_network_attr: true
Las métricas de la red se recopilan bajo la kentik.meraki.network.Count métrica que se utiliza exclusivamente para generar la Meraki Network entidad. Esto es principalmente para permitir la visualización de la jerarquía de Meraki y alinear los dispositivos con la red a la que pertenecen.
meraki_config.monitor_devices: true && meraki_config.preferences.device_status_only: true:Emplea el extremo Obtener estados del dispositivo de la organización para enumerar el estado de cada dispositivo Meraki en la organización.
NRQL para encontrar telemetría del estado del dispositivo:
FROM Metric SELECT
latest(status)AS'Device Status'// Current status of this device
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
src_addr AS'Device Public IP',
mac AS'Device MAC',
model AS'Device Model',
serialAS'Device Serial',
address AS'Device Address',
lat AS'Device Latitude',
lng AS'Device Longitude',
notes AS'Device Notes'
WHERE instrumentation.name ='meraki.device_status'
NRQL para encontrar telemetría de enlace ascendente del dispositivo:
FROM Metric SELECT
max(kentik.meraki.uplinks.LatencyMS)AS'Uplink Latency',// Uplink measured latency in milliseconds
max(kentik.meraki.uplinks.LossPct)AS'Uplink Loss %',// Uplink measured loss percentage
max(kentik.meraki.uplinks.Recv)AS'Uplink Receive Bytes',// Uplink bytes received
max(kentik.meraki.uplinks.Sent)AS'Uplink Transmit Bytes',// Uplink bytes sent
latest(status)AS'Uplink Status'// Latest status of the uplink
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
interface AS'Device Uplink Interface',
model AS'Device Model',
serialAS'Device Serial'
WHERE org_id ISNOTNULL
meraki_config.monitor_uplinks: true && meraki_config.preferences.hide_uplink_usage: true: Emplea el extremo Obtener estados de enlaces ascendentes de la organización para enumerar solo el estado del enlace ascendente de todos los dispositivos Meraki de los seriales MX, MG y Z en la organización.
NRQL para encontrar la telemetría del estado del enlace ascendente del dispositivo:
FROM Metric SELECT
latest(status)AS'Uplink Status'// Latest status of the uplink
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
interface AS'Device Uplink Interface',
model AS'Device Model',
serialAS'Device Serial'
WHERE org_id ISNOTNULL
meraki_config.monitor_vpn_status: true && meraki_config.preferences.show_vpn_peers: false: Emplea el extremo Get organization Appliance VPN States para mostrar los estados de VPN en todas las redes de la organización.
NRQL para encontrar la telemetría del estado de VPN:
FROM Metric SELECT
latest(status)AS'VPN Status'// Latest status of this VPN
FACET
org_id AS'Organization ID',
org_name AS'Organization Name',
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
serialAS'Device Serial',
vpn_mode AS'VPN Mode',
wan1 OR wan2 AS'WAN Interface IP'
WHERE instrumentation.name ='meraki.vpn_status'
AND org_id ISNOTNULL
meraki_config.monitor_vpn_status: true && meraki_config.preferences.show_vpn_peers: true: Emplea el extremo Obtener estados de VPN del dispositivo de organización para agregar información sobre los pares de VPN en las redes de la organización.
NRQL para encontrar telemetría de pares VPN:
FROM Metric SELECT
latest(status)AS'Peer Status'// Current status of this VPN peer
FACET
network_id AS'Network ID',
network AS'Network Name',
device_name AS'Device Name',
serialAS'Device Serial',
vpn_mode AS'VPN Mode',
wan1 AS'WAN 1 IP',
wan2 AS'WAN 2 IP',
peer_name AS'Peer Name',// Name of this peer
peer_reachability AS'Peer Reachability',// Latest results of reachability test for this peer
peer_network_id AS'Peer Network ID',// Network ID for this peer
peer_type AS'Peer Type'// Type of Peer (Meraki vs Third-party)
WHERE metricName ='kentik.meraki.vpn_status.PeerStatus'
Sugerencia
Puede utilizar la variable de entorno KENTIK_MERAKI_API_KEY para pasar su clave de API a la integración de Meraki sin almacenarla en texto sin formato en su archivo de configuración.
Configuración opcional que controla la frecuencia con la que se intenta un reintento en solicitudes de API que devuelven un error HTTP 429 . El intervalo entre reintentos es de 5 segundos.
meraki_config.monitor_devices
verdadero | falso (predeterminado: falso)
Monitor el estado de cada dispositivo Meraki en la organización.
meraki_config.monitor_org_changes
verdadero | falso (predeterminado: falso)
Monitorear el log de cambios de la organización.
meraki_config.monitor_uplinks
verdadero | falso (predeterminado: verdadero)
Monitorear el estado del enlace ascendente y el rendimiento de cada dispositivo Meraki de las series MX, MG y Z de la organización.
meraki_config.monitor_vpn_status
verdadero | falso (predeterminado: falso)
Monitorear los estados de VPN en las redes de la organización.
Estas opciones le permiten restringir el monitoreo a objetos específicamente objetivos en su entorno Meraki.
Estas opciones le permiten definir aún más los datos recopilados desde las opciones de configuración principales. En la sección de ejemplos anterior se describen varias combinaciones.
Nombre clave
Requerido
Aporte
Descripción
meraki_config.preferences.device_status_only
verdadero | falso (predeterminado: falso)
Se requiere cuando se utiliza monitor_devices: true para restringir el sondeo solo a información de estado. (This is used to prevent timeout issues.)
meraki_config.preferences.hide_uplink_usage
verdadero | falso (predeterminado: falso)
Se utiliza en combinación con monitor_uplinks para eliminar el rendimiento métrico y devolver solo información de estado para los enlaces ascendentes.
meraki_config.preferences.show_vpn_peers
verdadero | falso (predeterminado: falso)
Se utiliza en combinación con monitor_vpn_status para agregar telemetría en pares de VPN.
meraki_config.preferences.show_network_attr
verdadero | falso (predeterminado: falso)
Se utiliza para agregar telemetría en redes. Requerido para crear Meraki Network entidad.
Ejemplo de configuración mínima
# This represents the minimal configuration required for a container that only performs Meraki API polling.
# By default we only monitor uplinks. All other items are optional.
---
devices:
meraki_cloud_controller:
device_name: meraki_cloud_controller
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY"
trap:{}
discovery:{}
global:
poll_time_sec:300
timeout_ms:30000
Ejemplos de configuración completos [#meraki-full-config]
Todas las opciones necesarias para crear la entidad Meraki Organization, Meraki Network y Meraki Device .
devices:
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
preferences:
device_status_only:true
hide_uplink_usage:false
show_vpn_peers:true
show_network_attr:true
trap:{}
discovery:{}
global:
poll_time_sec:300
timeout_ms:30000
Dirigirse a múltiples claves de API del dashboard de Meraki
devices:
# Entity 1 - monitor everything this API key has access to
meraki_all:
device_name: meraki_all
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY_1"
max_http_retry:8
monitor_devices:true
monitor_org_changes:true
monitor_uplinks:true
monitor_vpn_status:true
preferences:
device_status_only:true
show_vpn_peers:true
hide_uplink_usage:false
# Entity 2 - Monitor these specific organizations under this API key
meraki_single_org:
device_name: meraki_single_org
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY_2"
monitor_devices:true
monitor_org_changes:true
monitor_uplinks:true
monitor_vpn_status:true
preferences:
device_status_only:true
show_vpn_peers:true
hide_uplink_usage:false
organizations:
-"Org 1 - Prod.*"
-"Org 2 - Staging"
# Entity 3 - Monitor specific devices filtered by organization, network, and product types; using the same API key from Entity 2
meraki_filtered:
device_name: meraki_filtered
device_ip: snmp.meraki.com
provider: meraki-cloud-controller
ext:
ext_only:true
meraki_config:
api_key:"$YOUR_API_KEY_2"
monitor_devices:true
monitor_uplinks:false
preferences:
device_status_only:true
organizations:
-"Org 3 - Remote Sites"
networks:
-"Corp.*99"
-"Retail.*"
product_types:
- wireless
- appliance
trap:{}
discovery:{}
global:
poll_time_sec:300
timeout_ms:30000
Archivos de configuración externos
Para admitir una amplia variedad de necesidades de configuración y automatización, puede utilizar archivos externos que monte por volumen en su contenedor Docker para desacoplar ciertos elementos del archivo de configuración estándar. Deberá incluir el siguiente argumento de montaje en su comando docker run , con un argumento por archivo de configuración externo.
-v `pwd`/fileName.yaml:/fileName.yaml \
La sintaxis de estos archivos es "@fileName.yaml", incluidas las comillas dobles.
Ejemplo:
discovery:
cidrs:"@cidrs.yaml"
El archivo CIDR debe usar una sintaxis de lista YAML como esta:
- 10.10.0.0/24
- 10.20.0.0/24
- 192.168.0.21/32
Ejemplo:
devices:
"@neteng-devices.yaml"
Los archivos del dispositivo deben usar la misma sintaxis que la sección estándar devices del archivo de configuración principal, omitiendo los campos opcionales que se generan durante el descubrimiento:
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
mib_profile: apc_ups.yml
provider: kentik-ups
poll_time_sec:300
retries:1
timeout_ms:5000
user_tags:
owning_team: dc_ops
El match_attributes
Para admitir el filtrado de datos que no crean valor para sus necesidades de observabilidad, puede configurar el mapa de atributos global.match_attributes.{} y/o devices.[].match_attributes.{} .
Esto proporcionará filtrado en el nivel ktranslate , antes de enviar datos a New Relic, lo que le brindará un control granular sobre el monitoreo de aspectos como las interfaces.
El comportamiento predeterminado de este mapa es una condición OR , pero puede anularla y forzar un operador AND anteponiendo el nombre de su clave con el prefijo !. Esto también es útil para devolver solo elementos coincidentes y omitir todos los resultados null y "" (vacíos).
Haga coincidir cuando if_Alias comience con UplinkOR cuando if_interface_name comience con Gig, mantenga todos los valores de null y "" :
devices:
deviceName:
...
match_attributes:
if_Alias:"^Uplink.*"
if_interface_name:"^Gig.*"
Haga coincidir cuando if_Alias comience con UplinkAND cuando if_interface_name comience con Gig, elimine todos los valores null y "" :
devices:
deviceName:
...
match_attributes:
if_Alias:"^Uplink.*"
"!if_interface_name":"^Gig.*"
Haga coincidir cuando if_Alias comience con Uplink, elimine todos los valores null y "" :
devices:
deviceName:
...
match_attributes:
"!if_Alias":"^Uplink.*"
El paquete de expresiones regulares de Golang no admite patrones de anticipación negativos (q(?!u)) de forma predeterminada. Como solución alternativa, puede agregar el token DOES_NOT_MATCH a su mapa de atributos para obtener de manera efectiva los resultados inversos de su patrón coincidente.
Por ejemplo, para hacer coincidir en cada interfaz que no incluya la cadena Uplink; puedes usar una configuración como esta:
devices:
deviceName:
...
match_attributes:
"!if_Alias":"^Uplink.*"
DOES_NOT_MATCH:true
El response_time y ping_only
Para admitir el monitoreo de dispositivos donde las estadísticas de rendimiento no son accesibles o no están disponibles, o en casos simples donde se requiere un monitoreo de tiempo de ida y vuelta básico (RTT), puede configurar el atributo global.response_time o devices.[].ping_only en true.
Esta función emplea el paquete go-ping para enviar paquetes ICMP (predeterminado) o UDP sin privilegios a los dispositivos para recopilar el tiempo de ida y vuelta (RTT) promedio, mínimo, máximo y desviación estándar. Este paquete también muestra el porcentaje de pérdida de paquetes para el extremo basado en el envío de un paquete/seg desde ktranslate a la dirección IP del dispositivo, que se puede anular configurando el atributo devices.[].ping_interval_sec . Puede cambiar del uso predeterminado de paquetes ICMP privilegiados a UDP configurando la variable de entorno KENTIK_PING_PRIV=false durante el tiempo de ejecución de Docker.
Establecer el atributo global.response_time en true agregará monitoreo RTT además del sondeo SNMP existente. Para monitor dispositivos solo con paquetes UDP|ICMP para RTT y sin sondeo SNMP, use devices.[].ping_only: true.
En New Relic, puedes ver los resultados de esta encuesta investigando la siguiente 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
Sugerencia
Puede utilizar el atributo ping_only en reemplazo del atributo flow_only si desea recopilar RTT métrico de un dispositivo de flujo. Si tanto ping_only como flow_only son true, el dispositivo se tratará como un dispositivo flow_only .
El flow_only
Para admitir el monitoreo de dispositivos donde solo desea recopilar datos de flujo, puede configurar el atributo devices.<deviceName>.flow_only en true.
Esto generará una Flow Device entidad que solo tendrá telemetría en el namespace del evento KFlow. Alternativamente, recopilar telemetría de flujo de un dispositivo que está en su archivo de configuración como dispositivo SNMP agregará decoración de los datos KFlow a la entidad preexistente, como Router o Firewall.
En New Relic, puedes ver los resultados de esta encuesta investigando el siguiente evento:
FROM KFlow SELECT*
WHERE instrumentation.name ='netflow-events'
Aplicación de datos de flujo mapeo.
De forma predeterminada, la telemetría de flujo se asigna a una aplicación conocida según la evaluación del puerto de capa 4 en uso en una conversación de flujo específica. Si es necesario, puede anular el mapeo predeterminado proporcionando un archivo YAML durante el tiempo de ejecución Docker en el indicador -application_map. Esto le permitirá especificar nombres de aplicaciones según los puertos que identifique.
Sintaxis de ejemplo:
applications:
-ports:[9092,9093]
name: kafka
-ports:[80,8080]
name: http
-ports:[443,8443]
name: https
Filtrado de entrada de datos de flujo
De forma predeterminada, el contenedor de datos de flujo recopilará y procesará cada paquete de flujo que reciba. Si es necesario, puede agregar un filtro de inclusión al indicador -nf.source que ignorará todo el tráfico que no coincida con el filtro que proporcione.
Sintaxis: --filters $TYPE,$FIELD,$FUNCTION,$MATCH
Nombre del argumento
Requerido
Descripción
$TIPO
✓
El tipo de filtro a aplicar. Los valores posibles son string, int y addr.
$CAMPO
✓
El nombre del campo contra el que se evaluará el patrón de coincidencia.
$FUNCIÓN
✓
El tipo de función que se utilizará durante la evaluación. Los valores posibles son Equal: ==, NotEqual: !=, LessThan: <, GreaterThan: >, Contains: %
$ PARTIDO
✓
El valor que se utilizará como patrón de coincidencia.
Recopile datos de flujo únicamente de direcciones de origen en el rango CIDR 10.0.0.0/24
Recopile datos de flujo únicamente de direcciones de origen en el rango CIDR 10.0.0.0/24 Y donde el puerto de destino no sea igual a 8531 (operador AND implícito)
Recarga automática de perfiles SNMP personalizados
De forma predeterminada, el contenedor Docker ktranslate debe destruir y reconstruir manualmente para incorporar cambios en los perfiles SNMP en la ruta mib_profile_dir. Este es un comportamiento normal en la mayoría de los casos, ya que la imagen Docker extrae los últimos perfiles disponibles en el repositorio público snmp-profiles. En situaciones en las que proporciona perfiles personalizados, puede emplear la configuración watch_profile_changes para permitir que el contenedor actualice automáticamente las configuraciones subyacentes y los perfiles SNMP del contenedor.
Importante
Esto no es recursivo debido a una limitación en la biblioteca del observador. Por lo tanto, si un perfil cambia en un subdirectorio, también debe editar un archivo de nivel superior para activar el cambio.
Suponiendo esta estructura de directorio:
.
└── /snmp-profiles/
└── profiles/
└── kentik-snmp/
├── 3com
├── _general
├── a10networks
└── ...
Deberá colocar un archivo nuevo en la raíz del directorio y cambiarlo manualmente para activar este ciclo de actualización. Una forma sencilla de implementar esto es simplemente escribir una timestamp en un archivo como last_updated.txt cuando se envía el cambio.