Supervisión de la experiencia de red
Información general
El servicioNetwork Experience Monitoring (NEM) (anteriormente denominado Netscope) permite a los proveedores de servicios, empresas, ISP y proveedores de servicios externos acceder a registros detallados de mediciones de Radar e informes estándar en forma de datos procesables resumidos. NEM ofrece varios registros e informes estándar que los clientes pueden utilizar para medir la calidad de sus servicios.
Esta solución incluye la entrega de mediciones de radar “sin procesar” y el acceso a la API de datos de ITM. NEM proporciona tanto los datos granulares (como mediciones brutas o agregados de datos) como las alertas de umbral de datos. Estos servicios ayudan con el descubrimiento, aíslan la disponibilidad de la plataforma y los problemas de rendimiento en los pares de plataforma y los ISP subyacentes.
Mediciones “brutas”de radar: las mediciones de radar proporcionan información granular por evento que se procesa en lotes a diario. Las mediciones de radar incluyen datos de medición públicos, comunitarios y privados recopilados por la etiqueta. Se incluyen datos como la disponibilidad, el tiempo de respuesta y el rendimiento de las mediciones HTTP y HTTPS. Se proporcionan los siguientes campos de datos:
- ID de proveedor, IP de resolución, IP de cliente ofuscadas (/28)
- Encabezado de referencia ofuscado, agente de usuario, ASN de usuario final
- Datos geográficos para campos de resolución y cliente
Las métricas de radar que están disponibles en las medidas “RAW” son:
- Disponibilidad, tiempo de respuesta y rendimiento (cuando se mide)
- Hora de búsqueda de DNS (opcional), hora de conexión TCP (opcional) y hora de conexión segura (opcional)
- Latencia (opcional)
- Tiempo de descarga (opcional)
Las mediciones de radar están disponibles para permitir a los clientes realizar sus propios análisis de los datos recopilados. El conjunto de datos incluye información sobre el rendimiento y la disponibilidad del proveedor (errores) para una serie de protocolos de comunicación.
Los datos de los archivos de registro están disponibles durante 7 días, desde un depósito de AWS S3 o Google Cloud Storage. Los clientes pueden recuperar archivos de registro de datos comunitarios y privados mediante métodos de acceso a depósitos estándar.
Medidas “RAW” de radar en tiempo real (opcional): Las mediciones Raw Radar se entregan en tiempo real a un bucket de AWS S3. Por lo general, estos registros están disponibles dentro de los 5 minutos posteriores a la recopilación Proporcionan tanta granularidad como las mediciones sin procesar de radar señaladas anteriormente.
API de datos: La API de datos de ITM Radar proporciona agregados de datos de medición privados y de la comunidad pública de Radar. Los datos se actualizan continuamente y se almacenan por lotes aproximadamente cada 60 segundos para que la API los recupere. La API de datos se proporciona para permitir a los clientes integrar datos de Radar en sus propios informes y paneles.
Uso compartido y entrega de registros
- Los registros de Radar se pueden entregar en tiempo real y diariamente.
- Los informes se publican diariamente.
- Los resultados se guardan en AWS S3 (S3) o Google Cloud Storage (GCS).
- Tanto los registros como los informes tienen un período de retención de 7 días y se eliminan automáticamente una semana después de su creación.
- Los informes suelen estar en formato TSV (valores separados por tabulaciones) o JSON, según el tipo de informe.
Los clientes reciben información de inicio de sesión para acceder a los depósitos de S3 y GCS. Se puede usar una herramienta de línea de comandos como s3cmd o la CLI de AWS para S3 o gsutil para GCS para iniciar sesión. El archivo de configuración de S3cmd reconoce las claves de acceso recibidas a través de la interfaz de usuario del portal y ayuda al usuario a conectarse al bucket de S3.
La CLI de AWS debe instalarse en el equipo del cliente para conectarse a S3 y acceder a los registros. Para GCS, el cliente recibe el archivo de clave de acceso como una descarga a través de la interfaz de usuario del portal, que se puede usar con la herramienta gsutil. Para obtener más información, consulte las preguntas frecuentes.
Los clientes reciben notificaciones por correo electrónico cuando los informes están disponibles.
Configuración de la plataforma
Debe configurar su plataforma para admitir y producir los datos necesarios para Netscope NEM. Antes de empezar, asegúrese de que la siguiente configuración esté habilitada para su plataforma:
- Para Detalles de sincronización de recursos, habilite Incluir marcas de tiempo en Configuración avanzada de Radar.
Navegación
En el menú principal, seleccione Netscope NEM. Se abre la página Network Experience Monitoring Configuration.
Plataformas
Seleccione las plataformas necesarias para iniciar el proceso de configuración.
NOTA:
Los registros e informes solo se pueden configurar y generar si se selecciona al menos una plataforma o red.
Los datos resumidos que recibe el cliente incluyen mediciones de Radar de plataformas seleccionadas (para todas las redes asociadas).
Selección de plataformas
Para empresas o proveedores de servicios de contenido, seleccione plataformas como CDN, nubes, centros de datos u otros puntos finales. Seleccione las plataformas para las que se requieren mediciones.
Registros de Radar
- Los registros de Radar están disponibles para las plataformas.
- Incluyen un subconjunto de los campos disponibles en los registros sin procesar, con algunos datos anonimizados: IP cliente /28, Referer MD5 hash.
- Se proporcionan todas las medidas tomadas para plataformas públicas, independientemente de la página que generó la medición.
NOTA:
NEM nunca expone las IP de cliente completas. En su lugar, expone el /28. Por ejemplo, una IP de 255.255.255.255 se muestra en un informe como 255.255.255.240/28.
Frecuencia de registro
Los registros de Radar se pueden generar diariamente (cada 24 horas) es decir, final del día, hora UTC. Los registros también se pueden generar en tiempo real (minuto a minuto).
Formato de archivo
Elija TSV o JSON para recibir registros e informes en cualquiera de estos formatos.
Tipo de medición
Puede configurar registros para los siguientes tipos de medida: Disponibilidad, Tiempo de Respuesta y Rendimiento. En el informe, 1: Disponibilidad, 0: Tiempo de respuesta HTTP y 14: Rendimiento HTTP.
Detalles de temporización de recursos
Puede optar por incluir también detalles de temporización de recursos haciendo clic en los botones Sí o No. Los detalles de temporización de recursos incluyen:
- Hora de búsqueda de DNS
- Hora de conexión TCP
- Tiempo de conexión seguro
- Tiempo de descarga
Para obtener las descripciones de los registros, consulte Descripciones e informes de registros de radar para proveedores de servicios y empresas.
Registros de sincronización de navegación
Frecuencia de registro
Los registros de sincronización de navegación se pueden generar diariamente (cada 24 horas) es decir, final del día, hora UTC. Los registros también se pueden generar en tiempo real (minuto a minuto).
Formato de archivo
Elija TSV o JSON para recibir registros de sincronización de navegación en cualquiera de estos formatos. Para obtener las descripciones de los registros, consulte Descripciones del registro de sincronización
Registros de Openmix
Frecuencia de registro
Los registros de Openmix se generan en tiempo real (es decir, minuto a minuto). Estos registros proporcionan mediciones en tiempo real tomadas para los clientes de Openmix.
Formato de archivo
Elija TSV o JSON para recibir registros Openmix y HTTP Openmix en cualquiera de estos formatos. JSON es sin embargo el formato recomendado.
Para ver las descripciones de los registros, consulte Descripciones de los registrosde
Entrega de servicios en la nube
Esta opción le permite seleccionar el modo de entrega. Puede optar por recibir registros e informes en el depósito de AWS S3 o en el depósito de Google Cloud Storage (GCS). Puede acceder a los depósitos de S3 y GCS con la información de inicio de sesión proporcionada y usar s3cmd o la CLI de AWS para S3 y la línea de comandos de gsutil para GCS.
AWS S3
Para los registros e informes que se entregarán al depósito de AWS S3, seleccione AWS S3.
Ubicación
La ubicación representa el depósito en AWS S3 donde se guardan los registros y los informes.
Claves de IAM
Si selecciona el botón Generar claves en AWS S3, las claves de IAM de AWS (claves de acceso y secretas) se generan y se muestran en Claves de IAM. Asegúrese de grabar las claves porque no están guardadas en ningún lugar para verlas más tarde.
NOTA:
El par de claves de acceso y secreto son la única copia de las claves privadas. El cliente debe almacenarlos de forma segura. La regeneración de las nuevas claves invalida las existentes. El archivo de configuración S3cmd reconoce las claves de acceso (recibidas a través de la interfaz de usuario del portal) y ayuda al cliente a conectarse al depósito S3. La CLI de AWS debe instalarse en la máquina del cliente para conectarse a S3.
Para obtener información sobre cómo usar las claves de acceso y secretas con s3cmd para descargar informes del bucket de S3, consulte las preguntas frecuentes.
Almacenamiento en la nube de Google
Para que los registros e informes se entreguen a GCS, selecciona Google Cloud Storage.
Ubicación
La ubicación representa el depósito en Google Cloud Storage donde se guardan los registros y los informes.
Claves de IAM
Al seleccionar el botón Generar archivo de clave, el archivo de clave de cuenta de Google Service se descarga en el equipo.
NOTA:
Este archivo de clave sirve como única copia de la clave privada. Tome nota de la dirección de correo electrónico de su cuenta de servicio y almacene de forma segura el archivo de clave privada de la cuenta de servicio. La regeneración de un nuevo archivo de clave invalida el archivo existente.
Este archivo clave se puede utilizar con la herramienta gsutil para descargar registros e informes desde el depósito GCS. Para obtener más información sobre cómo usar el archivo de claves para descargar archivos de registro, consulte las preguntas frecuentes.
Descripciones e informes del registro de Radar para proveedores de servicios y empresas
Registros de Radar para proveedores
- Estos registros proporcionan mediciones de Radar para socios de referencia.
- Proporcionan todas las medidas tomadas para plataformas públicas, independientemente de la página que generó la medición.
- Los registros de Radar incluyen un subconjunto de los campos disponibles en los registros sin procesar, con algunos datos anonimizados: IP cliente /28, Referer MD5 hash.
- Este es un ejemplo de uso compartido de registro de radar de plataforma en formato de archivo TSV.
NOTA:
- NEM nunca expone las IP de cliente completas. En su lugar, expone el /28. Por ejemplo, una IP de 255.255.255.255 se muestra en un informe como 255.255.255.240/28.
- La información GEO del cliente se extrae en función de la IPv4 del cliente, que es más detallada.
Descripciones de registro
Los siguientes son los encabezados de las columnas y las descripciones de los registros de radar. Los campos aparecen en el siguiente orden en los archivos de salida:
Registro | Descripción |
---|---|
Timestamp | Es la hora UTC de la solicitud en formato AAAA-MM-DDTHH:MI:SSZ. El valor real (hasta el segundo) en las tablas de registro se redondea a la hora más cercana (30-03-2018 T 23:00:00 Z) o al día (30-03-2018 T 00:00:00 Z) en las tablas de horas/días, respectivamente. La marca de tiempo siempre está en UTC en todos los conjuntos de datos. |
ID de nodo único | También se conoce como ID de nodo de caché. Es un valor arbitrario. Por lo general, una IP que los servidores perimetrales de CDN devuelven para ayudar a las CDN a identificar internamente qué servidor gestionó una solicitud en particular”. (cadena vacía): Proviene de clientes de Radar que no admiten la detección de UNI. 0: El agente de usuario no admite las funciones necesarias para la detección de UNI. 1: El cliente encontró un error durante la detección de UNI, como HTTP 404 u otra respuesta fallida. 2: Se intentó la detección de UNI, pero se produjo un error. |
ID de proveedor | ID interno de la plataforma que se está midiendo. |
Tipo de sonda | El tipo de sondeo que se está midiendo (por ejemplo, 1: Tiempo de conexión HTTP, 0: Tiempo de respuesta HTTP, 14: Rendimiento HTTP, etc.). Para indicar que el servicio está disponible, utilice la información devuelta correctamente dentro del tiempo permitido. |
Código de respuesta | Resultado de la medición. Por ejemplo, 0: éxito, 1: tiempo de espera agotado, 4: error. Para los cálculos de disponibilidad, el porcentaje de mediciones se toma con una respuesta de 0 (éxito) frente al número total de mediciones (total, independientemente de la respuesta). Para otros tipos de sonda (RTT y rendimiento), el filtro solo debe tener en cuenta los puntos de datos RTT con un código de éxito 0 al calcular las estadísticas en el RTT. Lo mismo para el rendimiento. |
Valor de medición | El valor de medición registrado, cuyo significado varía según el tipo de sonda. Representa mediciones de disponibilidad (1)/Tiempo de respuesta (0) en milisegundos y Rendimiento (14) en kbps. |
Mercado de Resolver | El mercado del solucionador DNS que manejó la solicitud. Generalmente el continente donde se encuentra el solucionador DNS, donde, 0: Desconocido (XX), 1:América del Norte (NA) 5: África (AF), 3: Europa (UE), 4: Asia (AS), 2: Oceanía (OC), 6: América del Sur (SA). |
País de resolución | El país del solucionador DNS que manejó los request.ID se puede asignar a nombres enhttps://community-radar.citrix.com/ref/countries.json.gz |
Región de resolución | La región del solucionador de DNS que gestionó los IDs de solicitud se puede asignar a los nombres en https://community-radar.citrix.com/ref/regions.json.gz Nota: No todos los países del mundo tienen regiones definidas. |
Estado de resolución | El estado de la resolución de DNS que gestionó los IDs de solicitud se puede asignar a los nombres en https://community-radar.citrix.com/ref/states.json.gz Nota: No todos los países del mundo tienen estados definidos. |
Ciudad de Resolver | La ciudad de la resolución de DNS que gestionó la solicitud. La ciudad de resolución se agrega buscando una dirección IP de resolución. Los ID se pueden asignar a los nombres en https://community-radar.citrix.com/ref/cities.json.gz |
ASN de resolución | Número de sistema autónomo (ASN) del solucionador DNS que gestionó la solicitud. Por lo general, la ASN que tiene los ID de resolución de DNS se puede asignar a los nombres de https://community-radar.citrix.com/ref/asns.json.gz |
Resolución IP | La dirección IP del solucionador DNS desde el que nuestra infraestructura recibió la solicitud DNS. |
Mercado de clientes | El mercado del usuario final que generó esta medición. Generalmente el continente donde se encuentra la IP del cliente; donde, 0: Desconocido (XX), 1:América del Norte (NA) 5: África (AF), 3: Europa (UE), 4: Asia (AS), 2: Oceanía (OC), 6: América del Sur (SA). |
País del cliente | El país del usuario final que generó esta medida. IDs se puede asignar a nombres enhttps://community-radar.citrix.com/ref/countries.json.gz |
Región del cliente | La región del usuario final que generó esta medida. Por lo general, la región geográfica en la que se encuentra la IP del cliente. Los ID se pueden asignar a los nombres en https://community-radar.citrix.com/ref/regions.json.gz Nota: No todos los países del mundo tienen regiones definidas. |
Estado del cliente | El estado del usuario final que generó esta medida. Por lo general, el estado donde se encuentra la IP del cliente. Los ID se pueden asignar a los nombres en https://community-radar.citrix.com/ref/states.json.gz Nota: No todos los países del mundo tienen estados definidos. |
Ciudad del cliente | La ciudad del usuario final que generó esta medida. Generalmente, la ciudad en la que se encuentra la IP del cliente.IDs se pueden asignar a nombres enhttps://community-radar.citrix.com/ref/cities.json.gz |
ASN del cliente | Número de sistema autónomo (ASN) del usuario final que generó esta medida. Por lo general, el ASN que contiene los IP.IDs del cliente se puede asignar a nombres enhttps://community-radar.citrix.com/ref/asns.json.gz |
IP de cliente | La IP del usuario final que generó esta medida. |
Host de referencia MD5 | La información del Referer (Protocolo, Host y Ruta) proviene del encabezado del Referer de la solicitud HTTP a Radar. El host de referencia es MD5 hash. |
Agente de usuario | Es la cadena del agente de usuario de la página del explorador que aloja la etiqueta. Por ejemplo, si usa Chrome y navegas por una página con la etiqueta Radar, las mediciones de radar en segundo plano registran el agente de usuario de su explorador Chrome. Las medidas incluyen el explorador Chrome, la versión de Chrome, información sobre el sistema operativo en el que se ejecuta Chrome, etc. |
Tiempo de búsqueda DNS (opcional) | Con la API Resource Timing, se calcula la diferencia entre el final de la búsqueda de dominio y el inicio de la búsqueda de dominio. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como domainLookupEnd - domainLookupStart. |
Hora de conexión TCP (opcional) | Con la API Resource Timing, se calcula la diferencia entre Connect End y Connect Start. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como connectEnd - connectStart. |
Tiempo de conexión segura (opcional) | Con la API Resource Timing, se calcula la diferencia entre Connect End y Secure Connection Start. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como connectEnd - secureConnectionStart. |
Latencia (opcional) | Con la API Resource Timing, se calcula la diferencia entre el inicio de la respuesta y el inicio de la solicitud. Calcula cuándo ambos valores no son nulos y la hora de inicio de la respuesta es mayor que la hora de inicio de la solicitud. Se calcula como responseStart - requestStart |
Tiempo de descarga (opcional) | Con la API Resource Timing, se calcula la diferencia entre el final de la respuesta y el inicio de la respuesta. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como responseEnd - responseStart. |
Perfil del cliente | Este campo ayuda a identificar si los datos provienen de aplicaciones móviles o exploradores. También nos permite diferenciar entre iOS, aplicaciones Android y exploradores. Se utiliza un número para identificar cada perfil de cliente. Los valores de este campo son: null, 0, 1, 2, 3, 4. Donde, null: Generalmente implica un cliente Radar anterior que no admite el envío del valor client_profile. 0: Explorador; 1: iOS - Radar Runner para la aplicación iOS escrita en Swift; 2: Android; 3: Explorador en la versión móvil del sitio web; 4: iOS - Radar Runner para la aplicación iOS escrita en Objective-C. |
Versión del perfil del cliente | La versión del perfil del cliente nos dice qué versión del código Radar Runner (para iOS) o AndroidRadar SDK (para Android) se utilizó en la aplicación móvil. Este campo está destinado únicamente para uso interno. |
Categoría de dispositivo | Todos los dispositivos se clasifican en uno de los siguientes: Smartphone, Tablet, PC, Smart TV y Otros. ‘Otro’ se utiliza como valor predeterminado si el analizador no puede determinar el valor de cualquiera de los campos. |
Dispositivo | El tipo de dispositivo en el que se encuentra el usuario, por ejemplo, un iPhone de Apple. La cadena del agente de usuario lo detecta desde el explorador que se ejecuta en la página que aloja la etiqueta Radar. |
Explorador web | El tipo de explorador que está utilizando el usuario, por ejemplo Mobile Safari UI/WKWebView 0.0.0. La cadena del agente de usuario lo detecta desde el explorador que se ejecuta en la página que aloja la etiqueta Radar. |
SO | El sistema operativo utilizado. Por ejemplo, iOS 11.0.3. La cadena de agente de usuario lo detecta desde el explorador que se ejecuta en la página que aloja la etiqueta Radar. |
IP del cliente de informes | Esta IP es la IP pública enmascarada /48 del usuario que realiza la medición. Puede ser IPv4 o IPv6 (si es compatible). |
Descripciones del registro de temporización de navegación
Datos de sincronización de navegación
Los datos de sincronización de navegación proporcionan información sobre las diversas partes del proceso de carga de páginas para una página web.
Estos datos varían según la ubicación del usuario final, los problemas de red, los cambios realizados por el proveedor, etc. Los clientes pueden usar los datos de navigation Timing para optimizar la experiencia del usuario final al cargar la página web supervisada.
Se pueden realizar mediciones para cada sesión de Radar (si está activada). Cada sesión se adjunta a un número de ID que ayuda a realizar un seguimiento de todas las mediciones de una sesión. Estas mediciones se comparten con los clientes como Registros de sincronización de navegación a través de NEM.
El siguiente es un ejemplo de los datos de temporización de navegación en formato de archivo TSV.
Los siguientes son los encabezados de las columnas y las descripciones de los registros de sincronización de navegación. Los campos aparecen en el siguiente orden en los archivos de salida:
Registro | Descripción |
---|---|
Timestamp | Es la hora UTC de la solicitud en formato AAAA-MM-DDTHH:MI:SSZ. El valor real (hasta el segundo) en las tablas de registro se redondea a la hora más cercana (30-03-2018 T 23:00:00 Z) o al día (30-03-2018 T 00:00:00 Z) en las tablas de horas/días, respectivamente. Siempre está en UTC en todos los conjuntos de datos. |
Código de respuesta | Resultado de la medición. Por ejemplo, 0: éxito, 1: tiempo de espera agotado, 4: error. Para los cálculos de disponibilidad, el porcentaje de mediciones se toma con una respuesta de 0 (éxito) frente al número total de mediciones (total). Para otros tipos de sondeos (RTT y rendimiento), el filtro solo tiene en cuenta los puntos de datos RTT con un código de éxito 0 al calcular las estadísticas en el RTT. Lo mismo para el rendimiento. |
Mercado de Resolver | El mercado del solucionador DNS que manejó la solicitud. Generalmente el continente donde se encuentra el solucionador DNS, donde, 0: Desconocido (XX), 1:América del Norte (NA) 5: África (AF), 3: Europa (UE), 4: Asia (AS), 2: Oceanía (OC), 6: América del Sur (SA). |
País de resolución | El país del solucionador DNS que manejó los request.ID se puede asignar a nombres enhttps://community-radar.citrix.com/ref/countries.json.gz |
Región de resolución | La región del solucionador de DNS que gestionó los Request.ids se puede asignar a los nombres de https://community-radar.citrix.com/ref/regions.json.gz. No todos los países del mundo tienen regiones definidas. |
Estado de resolución | El estado de la resolución de DNS que gestionó los Request.ids se puede asignar a los nombres de https://community-radar.citrix.com/ref/states.json.gz. No todos los países del mundo tienen estados definidos. |
ASN de resolución | Número de sistema autónomo (ASN) del solucionador DNS que gestionó la solicitud. Por lo general, la ASN que tiene el solucionador de DNS. Los ID se pueden asignar a nombres en https://community-radar.citrix.com/ref/asns.json.gz |
Resolución IP | La dirección IP del solucionador DNS desde el que nuestra infraestructura recibió la solicitud DNS. |
Mercado de clientes | El mercado del usuario final que generó esta medición. Generalmente el continente donde se encuentra la IP del cliente; donde, 0: Desconocido (XX), 1:América del Norte (NA) 5: África (AF), 3: Europa (UE), 4: Asia (AS), 2: Oceanía (OC), 6: América del Sur (SA). |
País del cliente | El país del usuario final que generó esta medida. IDs se puede asignar a nombres enhttps://community-radar.citrix.com/ref/countries.json.gz |
Región del cliente | La región del usuario final que generó esta medida. Por lo general, la región geográfica en la que se encuentra la IP del cliente. Los ID se pueden asignar a los nombres de https://community-radar.citrix.com/ref/regions.json.gz. No todos los países del mundo tienen regiones definidas. |
Estado del cliente | El estado del usuario final que generó esta medida. Generalmente, el estado en el que se encuentra la IP del cliente. Los ID se pueden asignar a los nombres de https://community-radar.citrix.com/ref/states.json.gz. No todos los países del mundo tienen estados definidos. |
ASN del cliente | Número de sistema autónomo (ASN) del usuario final que generó esta medida. Por lo general, la ASN que tiene la IP del cliente. Los ID se pueden asignar a nombres en https://community-radar.citrix.com/ref/asns.json.gz |
IP de cliente | La IP del usuario final que generó la medición. |
Anfitrión de Referente | La información del Referer (Protocolo, Host y Ruta) proviene del encabezado del Referer de la solicitud HTTP a Radar. |
Protocolo de referencia | La información del Referer (Protocolo, Host y Ruta) proviene del encabezado del Referer de la solicitud HTTP a Radar. |
Ruta de referencia | La información del Referer (Protocolo, Host y Ruta) proviene del encabezado del Referer de la solicitud HTTP a Radar. |
Categoría de dispositivo | Todos los dispositivos se clasifican en uno de los siguientes: Smartphone, Tablet, PC, Smart TV y Otros. ‘Otro’ se utiliza como valor predeterminado si el analizador no puede determinar el valor de cualquiera de los campos. |
Dispositivo | El tipo de dispositivo en el que se encuentra el usuario, por ejemplo, un iPhone de Apple. La cadena del agente de usuario lo detecta desde el explorador que se ejecuta en la página que aloja la etiqueta Radar. |
Explorador web | El tipo de explorador que está utilizando el usuario, por ejemplo Mobile Safari UI/WKWebView 0.0.0. La cadena del agente de usuario lo detecta desde el explorador que se ejecuta en la página que aloja la etiqueta Radar. |
SO | El sistema operativo que se está utilizando, por ejemplo iOS 11.0.3. La cadena del agente de usuario lo detecta desde el explorador que se ejecuta en la página que aloja la etiqueta Radar. |
Hora de búsqueda de DNS | Con la API Resource Timing, se calcula la diferencia entre el final de la búsqueda de dominio y el inicio de la búsqueda de dominio. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como domainLookupEnd - domainLookupStart. |
Hora de conexión TCP | Con la API Resource Timing, se calcula la diferencia entre Connect End y Connect Start. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como connectEnd - connectStart. |
Tiempo de conexión seguro | Con la API Resource Timing, se calcula la diferencia entre el fin de la conexión y el inicio de la conexión segura. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como connectEnd - secureConnectionStart. |
Load (evento) | Es la duración o el tiempo que se tarda en ir desde el principio hasta el final del evento load. Se calcula como loadEventEnd - loadEventStart, cuando ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. |
Redirigir | Es la duración o el tiempo que se tarda en pasar de Inicio de navegación a Inicio de búsqueda. Se calcula como FetchStart - navigationStart, cuando ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. |
Carga total de página | Es la duración o el tiempo que se tarda en pasar desde el inicio de la navegación hasta el final del evento de carga de página. Se calcula como - Cargar fin de evento - Inicio de navegación cuando ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. |
dom | La duración o el tiempo que se tarda en pasar de la carga dom a dom completado. Se calcula como DomComplete - DomLoading cuando ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. |
Latencia | Con la API Resource Timing, se calcula la diferencia entre el inicio de la respuesta y el inicio de la solicitud. Calcula cuándo ambos valores no son nulos y la hora de inicio de la respuesta es mayor que la hora de inicio de la solicitud. Se calcula como responseStart - requestStart |
Tiempo de descarga | Con la API Resource Timing, se calcula la diferencia entre el final de la respuesta y el inicio de la respuesta. Calcula cuándo ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. Se calcula como responseEnd - responseStart. |
dom interactivo | La duración o el tiempo que se tarda en pasar de Inicio de navegación a dom Interactive. Se calcula como DomInteractive - navigationStart cuando ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. |
Iniciar modelizado | La duración o el tiempo que se tarda en pasar de Inicio de navegación a Iniciar procesamiento. Se calcula como startRender - navigationStart cuando ambos valores no son nulos y la hora de finalización es mayor que la hora de inicio. |
Registros Openmix y HTTP Openmix
Los registros Openmix y HTTP Openmix permiten a los clientes utilizar mediciones en tiempo real para supervisar el comportamiento de sus aplicaciones Openmix. Pueden usar estos datos para encontrar áreas de mejora o para verificar el rendimiento esperado de sus aplicaciones.
- Estos registros proporcionan mediciones en tiempo real tomadas para los clientes de Openmix.
- El formato de archivo recomendado para estos registros es JSON, pero también están disponibles en formato TSV.
- A continuación se muestran ejemplos de datos de uso compartido de registros Openmixy HTTP Openmix en formato de archivo TSV.
Descripciones del registro de Openmix
Registro | Descripción |
---|---|
Timestamp | Es la hora UTC de la solicitud en formato AAAA-MM-DDTHH:MI:SSZ. El valor real (hasta el segundo) en las tablas de registro se redondea a la hora más cercana (30-03-2018 T 23:00:00 Z) o al día (30-03-2018 T 00:00:00 Z) en las tablas de horas/días, respectivamente. La marca de tiempo siempre está en UTC en todos los conjuntos de datos. |
ID de zona del propietario de la aplicación | El identificador de zona del propietario de la aplicación que atiende la solicitud. Este valor es siempre igual a 1. |
ID de cliente del propietario de la aplicación | El ID de cliente del propietario de la aplicación que atiende la solicitud. Para las solicitudes HTTP, codifique este ID en la ruta de la solicitud y utilícelo para buscar qué aplicación ejecutar. |
ID de aplicación | El ID de la aplicación en la cuenta del cliente que atiende la solicitud. Este ID también está codificado en la ruta de solicitud HTTP. Los ID de aplicación comienzan en 1 y solo son exclusivos del cliente. Debe calificar completamente las consultas para un ID de aplicación específico consultando en appOwnerCustomerId. |
Versión de la aplicación | Versión de la aplicación que atendía la cuenta. Cada vez que una aplicación se actualiza a través del portal o la API, la versión se incrementa. Se registra la versión que se estaba ejecutando en el momento de la solicitud. Esta información se puede utilizar para separar la lógica versionada a lo largo del tiempo a medida que se actualizan las aplicaciones. Los hosts de toda la red generalmente reciben actualizaciones en un período de tiempo similar, pero casi nunca exactamente en el mismo momento. Es probable que las decisiones superpuestas en el tiempo utilicen diferentes versiones de una aplicación durante el proceso de actualización. |
Nombre de la aplicación | El nombre de la aplicación que atendía la cuenta. |
Mercado | El mercado del usuario final que generó esta medición. |
País | País del usuario final que generó esta medida. |
Region | La región del usuario final que generó esta medida. |
Estado | El estado del usuario final que generó esta medida. |
ID de ASN | Número de sistema autónomo (ASN) del usuario final que generó esta medida. Por lo general, el número de sistema autónomo que tiene la IP del cliente. |
Nombre de ASN | El nombre de la ASN del usuario final que generó la medida. |
IP efectiva | La IP efectiva es la IP utilizada para procesar la solicitud. Es la IP especificada por cadena de consulta que anula la IP solicitante (frente a The Resolver/ECS/EDNS ID para el flujo DNS). Es la dirección que el sistema considera el objetivo al procesar la información. Esta IP es la IP del solucionador solicitante o la dirección IP de ECS del cliente si se admite EDNS ECS. Por lo tanto, todos los datos de rendimiento de la sonda, información geográfica, etc.pasados a la lógica de la aplicación se basan en esta IP. |
Mercado de Resolver | El mercado del solucionador DNS que manejó la solicitud. |
País de resolución | País del solucionador DNS que gestionó la solicitud. |
Región de resolución | La región del solucionador DNS que gestionó la solicitud. |
Estado de resolución | El estado del solucionador DNS que manejó la solicitud. |
ID de ASN del solucionador | Número de sistema autónomo (ASN) del solucionador DNS que gestionó la solicitud. Por lo general, el número de sistema autónomo que tiene el solucionador de DNS. |
Nombre ASN del solucionador | El nombre de la ASN del solucionador que gestionó la solicitud. |
Resolución IP | La dirección IP del solucionador DNS desde el que nuestra infraestructura recibió la solicitud DNS. |
Nombre del proveedor de decisiones | Alias de la plataforma que selecciona una aplicación. |
Código de motivo | Código de razón establecido dentro de la aplicación que describe el motivo detrás de la decisión. |
Registro de motivos | Este registro es un resultado definido por el cliente de la aplicación Openmix. Es un campo de cadena de caracteres opcional que permite a los clientes registrar información sobre sus decisiones sobre la aplicación Openmix. |
Modo de reserva | Este modo indica si la aplicación estaba en modo alternativo cuando gestionó la solicitud. El retroceso ocurre cuando algo falló durante la preparación de la solicitud de ejecución. |
Usado EDNS | True si la aplicación usa una extensión de subred del cliente de EDNS. |
TTL | El TTL (Time To Live) que fue devuelto. |
Respuesta | El CNAME devuelto de la solicitud. |
Resultado | El valor de este campo siempre es 1. |
Contexto | Es el resumen de los datos de Radar que estaban disponibles para Openmix cuando se gestionó la solicitud. Openmix resuelve los datos de Radar en relación con los valores efectivos de cada solicitud, por lo que dos clientes que realizan solicitudes al mismo tiempo pueden tener diferentes cadenas de contexto. |
Descripciones del registro de API HTTP de Openmix
Registro | Descripción |
---|---|
Timestamp | Es la hora UTC de la solicitud en formato AAAA-MM-DDTHH:MI:SSZ. El valor real (hasta el segundo) en las tablas de registro se redondea a la hora más cercana (30-03-2018 T 23:00:00 Z) o al día (30-03-2018 T 00:00:00 Z) en las tablas de horas/días, respectivamente. La marca de tiempo siempre está en UTC en todos los conjuntos de datos. |
ID de zona del propietario de la aplicación | El identificador de zona del propietario de la aplicación que atiende la solicitud. Este valor es siempre igual a 1. |
ID de cliente del propietario de la aplicación | El ID de cliente del propietario de la aplicación que atiende la solicitud. Para las solicitudes HTTP, codifique este ID en la ruta de la solicitud y se usa para buscar qué aplicación ejecutar. |
ID de aplicación | El ID de la aplicación en la cuenta del cliente que atiende la solicitud. Este ID también está codificado en la ruta de solicitud HTTP. Los ID de aplicación comienzan en 1 y solo son exclusivos del cliente. Debe calificar completamente las consultas para un ID de aplicación específico consultando en appOwnerCustomerId. |
Versión de la aplicación | Versión de la aplicación que atendía la cuenta. Cada vez que una aplicación se actualiza a través del portal o la API, la versión se incrementa. Se registra la versión que se estaba ejecutando en el momento de la solicitud. Esta información se puede utilizar para separar la lógica versionada a lo largo del tiempo a medida que se actualizan las aplicaciones. Los hosts de toda la red generalmente reciben actualizaciones en un período de tiempo similar, pero casi nunca exactamente en el mismo momento. Es probable que las decisiones superpuestas en el tiempo utilicen diferentes versiones de una aplicación durante el proceso de actualización. |
Nombre de la aplicación | El nombre de la aplicación que atendía la cuenta. |
Mercado | El mercado del usuario final que generó esta medición. |
País | País del usuario final que generó esta medida. |
Region | La región del usuario final que generó esta medida. |
Estado | El estado del usuario final que generó esta medida. |
ID de ASN | El ID del número de sistema autónomo (ASN) del usuario final que generó esta medición, es decir, el número de ID de red asociado al nombre de ASN |
Nombre de ASN | El nombre de la ASN del usuario final que generó la medida. |
IP efectiva | La IP efectiva es la IP utilizada para procesar la solicitud. Es la IP especificada por cadena de consulta que anula la IP solicitante (frente a The Resolver/ECS/EDNS ID para el flujo DNS). Es la dirección que el sistema considera el objetivo al procesar la información. Esta IP es la IP del solucionador solicitante o la dirección IP de ECS del cliente si se admite EDNS ECS. Todos los datos de rendimiento de la sonda, la información geográfica, etc., que se pasan a la lógica de la aplicación se basan en esta IP. |
Nombre del proveedor de decisiones | Alias de la plataforma que selecciona una aplicación. |
Código de motivo | Código de razón establecido dentro de la aplicación que describe el motivo detrás de la decisión. |
Registro de motivos | Este registro es un resultado definido por el cliente de la aplicación Openmix. Es un campo de cadena de caracteres opcional que permite a los clientes registrar información sobre sus decisiones sobre la aplicación Openmix. |
Modo de reserva | Este modo indica si la aplicación estaba en modo alternativo cuando gestionó la solicitud. El retroceso ocurre cuando algo falló durante la preparación de la solicitud de ejecución. |
Código de respuesta | Resultado de la medición. Por ejemplo, 0: éxito, 1: tiempo de espera agotado, 4: error. Para los cálculos de disponibilidad, el porcentaje de mediciones se toma con una respuesta de 0 (éxito) frente al número total de mediciones (total, independientemente de la respuesta). Para otros tipos de sonda (RTT y rendimiento), el filtro solo debe tener en cuenta los puntos de datos RTT con un código de éxito 0 al calcular las estadísticas en el RTT. Lo mismo para el rendimiento. |
HTTP (método) | El método HTTP (get/post/options/etc) se refiere a la solicitud que se realizó al servidor HTTP Openmix desde un servicio de atención al cliente. Juntos, estos métodos forman partes de la URL entrante y las respuestas HTTP salientes. |
URI | Es la ruta de solicitud. Si los clientes no obtienen el comportamiento que desean, puede deberse a una solicitud mal estructurada. Los registros muestran lo que reciben nuestros servidores (protocolo, host y ruta). La información del Referer (Protocolo, Host y Ruta) proviene del encabezado del Referer de la solicitud HTTP a Radar. Para HTTP OPX, el Referer completo (protocolo, host y ruta) se incluye en una cadena etiquetada Referer. |
Agente de usuario | Es la cadena del agente de usuario de la página del explorador que aloja la etiqueta. Por ejemplo, si usa Chrome y navegas por una página con la etiqueta Radar, las mediciones de radar en segundo plano registran el agente de usuario de su explorador Chrome. Las medidas incluyen el explorador Chrome, la versión de Chrome, información sobre el sistema operativo en el que se ejecuta Chrome, etc. |
Contexto | Es el resumen de los datos de Radar que estaban disponibles para Openmix cuando se gestionó la solicitud. Openmix resuelve los datos de Radar en relación con los valores efectivos de cada solicitud, por lo que dos clientes que realizan solicitudes al mismo tiempo pueden tener diferentes cadenas de contexto. |
Informes personalizados para organizaciones de terceros
Los clientes pueden trabajar con NetScaler para obtener informes personalizados basados en los datos de Radar que recopila NetScaler. NetScaler puede generar informes para ejecutarlos según un cronograma. Los informes están disponibles como archivos de datos, normalmente en formato TSV.
Preguntas frecuentes
Radar
¿Con qué frecuencia se envían archivos a S3 y GCS?
La frecuencia de los depósitos de archivos es una vez por minuto para Radar y diariamente para los informes.
¿Dónde se almacenan los informes?
S3 Legado (Ubicación 1):
s3://public-radar/[customer name]/
S3 (Ubicación 2):
s3://cedexis-netscope/[customer id]/
GCS (Ubicación 3):
gs://cedexis-netscope-[customer id]/
¿Cómo obtener las credenciales de acceso a S3 si aún no las tiene?
El portal proporciona una clave de “Acceso” y “Secreta”. Utilice las claves con ‘s3cmd’, ‘awscli’ u otras herramientas para acceder a S3. Para Google Storage, el Portal descarga un archivo con credenciales de acceso para usarlo con la herramienta “gsutil”.
¿Cómo usar las claves de acceso y secretas con s3cmd para descargar registros e informes del depósito S3?
En primer lugar, tendría que descargar e instalar els3cmd
desdehttps://s3tools.org/download, y consultar elhttps://s3tools.org/usage uso, las opciones y los comandos. A continuación, ejecute el siguiente comando:
s3cmd --access_key=[access key] --secret_key=[secret key] ls s3://cedexis-netscope/<customer id>/radar/
<!--NeedCopy-->
Para descargar los archivos, ejecute el siguiente comando:
s3cmd --access_key=[access_key] --secret_key=[secret_key] get s3://cedexis-netscope/<customer id>/radar/[the_filename_to_download] [the_name_of_the_local_file]
<!--NeedCopy-->
Cómo usar la configuración s3cmd para enumerar archivos en el depósito S3
El primer paso es instalars3cmd
. Puede instalarlo desdehttp://s3tools.org/download
Para configurar s3cmd, ejecute el siguiente comando
s3cmd ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->
Si ya está utilizandos3cmd
con otro conjunto de claves de acceso y secretas, siga estos pasos:
Si ya usa s3cmd
, haga una copia de la configuración predeterminada, en ~/.s3cfg
. Por ejemplo, haga una copia y asígnele el nombre ~/.s3cfg_netscope
. Reemplace las entradas de clave secreta y de acceso en ~/.s3cfg_netscope
por las que proporcionamos.
Utilice la nueva configuración en lugar de la predeterminada (la de su empresa) para acceder al depósito S3 con el siguiente comando:
s3cmd -c ~/.s3cfg_netscope ls s3://cedexis-netscope/[customer id]/
<!--NeedCopy-->
La principal diferencia es que hay que poner -c
y dónde se encuentra el archivo de configuración con las claves de acceso y secretas proporcionadas por NetScaler.
Si quiere cambiar entre juegos de claves, insértelos en un archivo. Consulte el archivo con la opción -c
para especificar qué par de claves está utilizando.
NOTA:
-c
El parámetro indica dónde se encuentra el archivo de configuración, que contiene las claves de acceso y secreto.
Cómo usar el archivo clave con gsutil o gcloud para descargar archivos de registro
Una vez descargado el archivo de clave JSON de la cuenta de servicio de Google, puede usarlo para autenticar las credenciales de su cuenta de Google, ver o descargar sus archivos de registro. Por ejemplo, esta es una forma de hacerlo con las utilidades de línea de comandos gcloud
y gsutil
de Google:
Paso 1: Activar el archivo de claves
Los comandos de autenticacióngcloud auth activate-
ogsutil config -e
son necesarios para autenticar el archivo de claves para ejecutar comandos gcloud o gsutil.
Para gcloud:
Ejecute el siguiente comando con el archivo de claves descargado:
gcloud auth activate-service-account --key-file [downloaded config file]
<!--NeedCopy-->
O bien,
gcloud auth activate-service-account --key-file=[path and file name of key file]
<!--NeedCopy-->
Para gsutil:
Ejecute el siguiente comando con el archivo de configuración descargado:
gsutil config -e
<!--NeedCopy-->
Paso 2: Liste los archivos en el depósito GCS (Google Cloud Storage)
Una vez que haya activado el archivo de clave de la cuenta de servicio como se describe en el paso anterior, use este comando para enumerar los archivos en el depósito de GCS:
gsutil ls gs://cedexis-netscope-<customer id>
<!--NeedCopy-->
Paso 3 (si es necesario): Restaurar credenciales originales (o cambiar entre cuentas)
Puede cambiar entre la cuenta ITM de NetScaler y otras credenciales de Google Cloud que haya autenticado de la siguiente manera.
Primero, ejecute el siguiente comando para enumerar todas sus cuentas:
gcloud auth list
<!--NeedCopy-->
A continuación, utilice el siguiente comando para cambiar a otra cuenta:
gcloud config set account [email of the account to switch to as shown in gcloud auth list]
<!--NeedCopy-->
Puede cambiar de una cuenta a otra mediante el mismo comando, reemplazando el correo electrónico por el correo electrónico de la cuenta al que quiere cambiar.
¿Cómo es el nombre del archivo?
Legacy Daily:
Los nombres de ShareFile del registro diario de Radar tienen esta estructura:
<prefix><date: YYYY-MM-DD>.<customer_id>.part<uniq_id>.kr.txt.gz
Por ejemploCedexis_Daily-2017-11-07.21222.part-cc901e1dd55eal4e.kr.txt.gz
(ejemplo no estándar)
Legado en tiempo real:
Los nombres de ShareFile de registro en tiempo real de Radar tienen esta estructura:
<prefix><customer_id>-YYYY-MM-DDTHH:MM<uniq_id>.txt.gz
Por ejemplo:Cedexis_3-32291-2017-11-08T20:56-cc907e8fd71eaf4e.txt.gz
Formato NEM Netscope:
El formato NEM Netscope para archivos compartidos de registro diario y en tiempo real tiene esta estructura:
<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz
Donde:
-
freq
:"daily" | "rt" | "hr"
-
log_type
:"radar" | "opx" | "hopx"
-
prefix
:log_share.prefix
-
id_type
:"customer" | "provider" | "asn"
-
id
:log_share.match_id
-
iso_dt
:iso 8601 Date_time "YYYYMMDDTHHMMSSZ"
-
uniq_id
:hash(UUID)
-
line_format
:"tsv" | "json"
Por ejemplo:rt-radar-TestRadar1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz
¿Cuál es el formato del archivo de salida?
Para Radar, el formato de archivo de salida es TSV (valor separado por tabulaciones), gzip.
API HTTP Openmix y Openmix
¿Con qué frecuencia se envían archivos a S3?
La frecuencia de los depósitos de archivos es una vez por minuto para Openmix y HTTP Openmix.
¿Qué pasa si no puede ver la opción para configurar el uso compartido de registros en tiempo real de las API HTTP de Openmix y Openmix?
Su administrador de cuentas puede habilitar la función necesaria para configurar y habilitar el uso compartido de registros en tiempo real de la API HTTP de Openmix y Openmix.
¿Cómo se activa Openmix y una API HTTP de Openmix para compartir registros en tiempo real y acceder a los archivos?
Cuando la función esté habilitada en su cuenta, verá el icono Administrar registros. Haga clic para abrir el cuadro de diálogo Registros donde puede acceder a la configuración de Openmix Log Configuration. Estas configuraciones son básicamente todo lo que necesita para activar Openmix y HTTP Openmix en tiempo real para compartir registros y acceder a los archivos.
¿Cuál es el proceso back-end?
Al activar el uso compartido de registros de Openmix, también se habilita el uso compartido de registros de la API HTTP de Openmix. Los servicios de uso compartido de registros de API HTTP Openmix y Openmix deben comenzar a generar registros para el cliente en 10 minutos.
¿Dónde se almacenan los informes Openmix y HTTP Openmix?
S3 Legado (Ubicación 1):
s3://logshare/[zone ID]/[customer ID]/logs/openmix/json/[YYYY]/[MM]/[DD]/[HH]/.
S3 (Ubicación 2):
s3://cedexis-netscope/[customer id]/
GCS (Ubicación 3):
gs://cedexis-netscope-[customer id]/
¿Cómo es el nombre del archivo?
La estructura de nombres de archivo para Openmix y HTTP Openmix normalmente se ve así:
Legado en tiempo real:
[zone ID, 1][customerID]-openmix-json[YYYY][MM][DD][HH][mm][ss]Z-m1-w9-c0.gz
Formato NEM Netscope:
El formato NEM Netscope para archivos compartidos de registro diario y en tiempo real tiene esta estructura:
<freq><log_type><prefix><id_type><id><iso_dt><uniq_id>.<line_format>.gz
Donde:
-
freq
:"daily" | "rt" | "hr"
-
log_type
:"radar" | "opx" | "hopx"
-
prefix
:log_share.prefix
-
id_type
:"customer" | "provider" | "asn"
-
idv
:log_share.match_id
-
iso_dt
:iso 8601 Date_time "YYYYMMDDTHHMMSSZ"
-
uniq_id
:hash(UUID)
-
line_format
:"tsv" | "json"
Por ejemplo:hr-opx-TestOpenmix1-provider-20363-20171209183034Z-cc907e8fd71eaf4e.tsv.gz
¿Cuál es el formato de archivo de salida?
El formato de archivo para Openmix y una API HTTP de Openmix es JSON (comprimido con gzip).
En este artículo
- Información general
- Uso compartido y entrega de registros
- Navegación
- Plataformas
- Registros de Radar
- Registros de sincronización de navegación
- Registros de Openmix
- Entrega de servicios en la nube
- Descripciones e informes del registro de Radar para proveedores de servicios y empresas
- Descripciones del registro de temporización de navegación
- Registros Openmix y HTTP Openmix
- Descripciones del registro de Openmix
- Descripciones del registro de API HTTP de Openmix
- Informes personalizados para organizaciones de terceros
- Preguntas frecuentes