Directrices para agregar datos de interfaz de telemetría de Junos
Una característica importante de la interfaz de telemetría de Junos es que el procesamiento de datos se produce en el recopilador que transmite los datos, en lugar del dispositivo. Los datos no se agregan automáticamente, pero se pueden agregar para su análisis.
La agregación de datos es útil en los siguientes escenarios:
Datos de la misma métrica en intervalos de tiempo fijos, como el número promedio de errores de entrada de la interfaz física durante un intervalo de 30 segundos.
Datos de diferentes fuentes (como varias tarjetas de línea) para la misma métrica, como estadísticas de ruta de conmutación de etiquetas (LSP) o estadísticas de contador de filtros.
Datos de varias fuentes, como estadísticas de entrada y salida para interfaces Ethernet agregadas.
En las secciones siguientes se describe cómo realizar la agregación de datos para varios escenarios. En los ejemplos de estas secciones se usa la base de datos de series temporales InfluxDB para aceptar consultas sobre datos de telemetría. InfluxDB es una base de datos de código abierto escrita en Go específicamente para manejar datos de series temporales.
Agregación de datos en períodos de tiempo fijos
Agregar datos para la misma métrica en intervalos de tiempo fijos es una forma común y útil de detectar tendencias. Las métricas pueden incluir medidores, es decir, valores únicos o contadores acumulativos. Es posible que también desee agregar datos continuamente.
- Ejemplo: agregación de datos para métricas de medición
- Ejemplo: agregación de datos para estadísticas acumulativas
Ejemplo: agregación de datos para métricas de medición
En este ejemplo, los datos de from se escriben en la base de datos JuniperNetworksSensors.jnpr_interface_ext.interface_stats.egress_queue_info.current_buffer_occupancy InfluxDB con etiquetas que identifican el nombre de host, un nombre de interfaz y el número de port.proto cola y la medición correspondientes llamados current_buffer_occupancy. Consulte la Tabla 1 para ver los valores específicos utilizados en este ejemplo.
| Marca de tiempo (segundos) |
Valor |
Etiquetas |
|---|---|---|
| 1458704133 |
1547 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704143 |
3221 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704155 |
4860 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704166 |
6550 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
Cada punto de datos de medición tiene una marca de tiempo y un valor registrado. En este ejemplo, la etiqueta queue_number es el identificador numérico de la cola de la interfaz.
Para agregar estos datos en intervalos de 30 segundos, use la siguiente consulta influxDB:
select mean(value) from current_buffer_occupancy where time >= $time_start and time <= $time_end and queue_number=’0’ and interface_name=’xe-1/0/0’ and host=’sjc-a’ group by time(30s)
Para $time_start y $time_end, especifique el intervalo de tiempo real.
Ejemplo: agregación de datos para estadísticas acumulativas
Algunos sensores de interfaz de telemetría de Junos informan de valores de contador acumulativos, como el número de paquetes de entrada, definido como JuniperNetworksSensors.jnpr_interface_ext.interface_stats.ingress_stats.packets.
Es común derivar tasas de tráfico de contadores de paquetes o bytes. A diferencia de las métricas de medidor, el punto de datos inicial de la serie para contadores acumulativos solo se usa para establecer la línea base.
Use las siguientes directrices para crear una consulta de base de datos para estadísticas acumulativas:
-
Calcule el valor acumulado para un intervalo de tiempo específico. Puede calcular un promedio entre varios puntos de datos registrados durante el intervalo de tiempo o puede interpolar un valor. Todos los puntos de datos deben pertenecer a la misma serie. Si se ha producido un restablecimiento del contador entre los dos puntos de datos notificados en momentos diferentes, no utilice ambos puntos de datos.
-
Determine el valor adecuado para el intervalo de tiempo anterior. Si se restableció un contador desde la última actualización, declare ese valor como no disponible.
-
Si el intervalo anterior está disponible, calcule la diferencia entre los puntos de datos y la velocidad de tráfico.
Estas directrices se resumen en la siguiente consulta de influxDB. En esta consulta se supone que los datos se almacenan en la medición ingress_packets. La consulta utiliza las mismas etiquetas que el ejemplo de la métrica de medidor, así como la etiqueta para el tiempo de inicialización del contador, init_time. La consulta utiliza valores promedio en un intervalo de tiempo de 30 segundos. Calcula la tasa de las métricas que tienen la misma inicialización de contador.
select non_negative_derivative(mean(value)) from ingress_packets
where time >= $time_start and time <= $time_end and
interface_name=’xe-1/0/0’ and host=’sjc-a’
group by time(30s), init_time
Utilice la siguiente consulta para calcular el número de paquetes recibidos durante un intervalo de tiempo, sin derivar la velocidad.
select difference(mean(value)) from ingress_packets where time >= $time_start and time <= $time_end and interface_name=’xe-1/0/0’ and host=’sjc-a’ group by time(30s), init_time
En algunos casos, la consulta devuelve más de un punto de datos agregado para un intervalo de tiempo determinado. Por ejemplo, cuatro puntos de datos están disponibles para un intervalo de tiempo. Dos puntos de datos tienen , y los otros dos tienen init_time t0init_time t1. Puede ejecutar una consulta que utilice la etiqueta de marca de tiempo del último cambio, , en lugar de , last_changepara calcular la diferencia y derivar la velocidad entre los dos puntos de datos con la misma marca de init_timetiempo del último cambio.
select difference(mean(value)) from ingress_packets
where time >= $time_start and time <= $time_end and
interface_name=’xe-1/0/0’ and host=’sjc-a’
group by time(30s), last_change
Todas estas consultas se pueden ejecutar como consultas continuas y pueden rellenar periódicamente nuevas mediciones de series temporales.
Agregación de datos de varias fuentes
Algunas métricas se informan desde varias tarjetas de línea o motores de reenvío de paquetes. Es útil agregar datos derivados de diferentes orígenes en los siguientes escenarios:
-
Los recuentos de paquetes y bytes para las rutas de conmutación de etiquetas (LSP) se informan por separado en cada tarjeta de línea. Sin embargo, se requiere una vista de las rutas de LSP para todo el dispositivo para los controladores de elementos de cálculo de rutas.
-
En el caso de los dispositivos de Juniper Networks que admiten colas de salida virtuales, las estadísticas de caída de cola o de caída de detección temprana aleatoria para cada cola se informan por separado en cada tarjeta de línea para cada interfaz física. Es útil poder agregar las estadísticas de todas las tarjetas de línea de una interfaz.
-
Los contadores de filtro de un filtro de firewall conectado a una tabla de reenvío o a una interfaz Ethernet agregada se notifican por separado en cada tarjeta de línea. Es útil agregar las estadísticas de todas las tarjetas de línea.
Para agregar datos de varios orígenes, realice lo siguiente:
Agregue datos durante un período de tiempo específico para cada fuente, por ejemplo, cada tarjeta de línea.
Agregue los datos que deriva para cada origen en el paso 1.
Para los datos almacenados en una base de datos InfluxDB, puede completar el paso 1 del procedimiento ejecutando una consulta continua y rellenando una nueva medición. Le recomendamos encarecidamente que agrupe los puntos de datos según cada fuente. Por ejemplo, para las estadísticas de LSP, el component_id en el mensaje gpb identifica la tarjeta de línea que envía los datos. Agrupe los puntos de datos en función de cada archivo .component_id
Ejemplo: agregación de datos de varias fuentes
En este ejemplo, se ejecutan dos consultas para derivar la velocidad de paquetes LSP para los datos de todas las tarjetas de línea.
En primer lugar, ejecute la siguiente consulta continua sobre la medición denominada lsp_packet_count para cada component_id etiqueta y la counter_name etiqueta. Cada etiqueta única component_id corresponde a una tarjeta de línea diferente. Esta consulta rellena una nueva medición, lsp_packet_rate.
select non_negative_derivative(mean(value)) as value from lsp_packet_count into lsp_packet_rate group by time(30s), component_id, counter_name, host
El sensor de estadísticas LSP no informa del tiempo de inicialización del contador.
Utilice la nueva medida derivada de esta consulta continua ——lsp_packet_countpara ejecutar la siguiente consulta, que agrega datos de todas las tarjetas de línea para velocidades de paquetes para un LSP denominado lsp-sjc-den-1.
select sum(value) from lsp_packet_rate where counter_name=’lsp-sjc-den-1’, host=’sjc-a’
Dado que esta consulta no agrupa los datos según la etiqueta o la component_id tarjeta de línea, se devuelven las velocidades de paquetes LSP de todos los componentes o tarjetas de línea.
Agregación de datos para múltiples métricas
Puede ser útil agregar métricas para varios valores. Por ejemplo, para las interfaces Ethernet agregadas, normalmente querrá realizar un seguimiento de las velocidades de paquetes y bytes para cada miembro de la interfaz, así como la utilización de la interfaz para el vínculo agregado.
Ejemplo: agregar varios valores de métrica
En este ejemplo, se ejecutan las dos consultas siguientes:
-
Consulta continua para derivar los recuentos de paquetes de entrada para cada vínculo miembro en una interfaz Ethernet agregada
-
Consulta para agregar datos de recuento de paquetes para todos los vínculos de miembro que pertenecen a la misma interfaz Ethernet agregada
La siguiente consulta continua deriva una medida, , ingress_packetspara cada vínculo miembro en una interfaz Ethernet agregada. La interface_name etiqueta identifica la interfaz de cada miembro. También puede utilizar la etiqueta para identificar la parent-ae-name pertenencia a una interfaz Ethernet agregada específica. Agrupar cada enlace de miembro con la etiqueta garantiza que los datos se recopilen solo para los enlaces de parent-ae-name miembros actuales. Por ejemplo, una interfaz puede cambiar su pertenencia durante el intervalo de informe. La agrupación de interfaces miembro con la interfaz Ethernet agregada específica significa que los datos del vínculo miembro no se transferirán a la nueva interfaz Ethernet agregada de la que ahora es miembro.
select difference(mean(value)) as value from ingress_packets
into ingress_packets_difference
group by time(30s), component_id, interface_name, host, parent-ae-name
La siguiente consulta agrega datos para los paquetes de entrada para la interfaz Ethernet agregada, es decir, todos los vínculos de miembro.
select sum(value) from ingress_packets_difference
where parent-ae-name=’ae0’ and host=’sjc-a’
Esta consulta agrega datos para la interfaz ae0Ethernet agregada. La parent-ae-name etiqueta no verifica los vínculos reales de los miembros.