Registros de ArcGIS Enterprise y Analizador de Registros del Sistema
Mientras existen varios Artículos de la Comunidad que discuten el análisis de los registros de ArcGIS Enterprise y cómo comenzar con el Analizador de Registros del Sistema:
Hay pocos recursos que profundicen en los detalles del informe generado en hoja de cálculo y cómo tomar decisiones como administrador GIS y/o desarrollador basadas en la información de rendimiento que proporciona.
Este Artículo guiará sobre cómo realizar un análisis de registros en una implementación de Utility Network que luego puede usarse para construir conocimiento sobre el uso y eficiencia del Sitio.
Análisis de Rendimiento de los Registros de ArcGIS Enterprise
Antes de comenzar, revisemos qué es el análisis de registros y dónde se puede encontrar dicha información en una implementación de ArcGIS.
Análisis de Registros:
El proceso de extraer información a partir de datos de registro. Esta información puede usarse para cuantificar el uso GIS y ayudar a responder:
- ¿Qué servicios están solicitando los usuarios?
- ¿Qué operaciones están realizando?
- ¿Qué rendimiento están experimentando?
Datos de Registro:
Los datos a analizar son los registros de ArcGIS Enterprise. Normalmente, estos datos residen en los servidores de la implementación y vienen en diferentes formas:
- Registros de acceso del ArcGIS Web Adaptor
- La fuente de datos utilizada en este Artículo
- Registros de acceso del ArcGIS Server
- Registros generados por ArcGIS Pro
Cada fuente ofrece su propia riqueza informativa.
Escenario Ejemplo para Análisis de Registros
El siguiente escenario es el caso práctico para nuestro análisis:
Su gerente ha asignado una tarea:
Cuantificar el uso y eficiencia del ArcGIS Utility Network en su Sitio
Esto significa que se deben responder las siguientes preguntas:
- ¿Está el Sitio bien gestionado y es óptimo?
- ¿Cuáles servicios son los más populares?
- ¿Qué métodos se llaman?
- query, applyEdits, updateSubnetwork
- ¿Cómo están funcionando los servicios?
- ¿Experiencia general del usuario?
Nuestro gerente también ha pedido que dicho análisis se realice de manera rentable.
Nota: Antes de comenzar el análisis, se recomienda consultar cualquier objetivo de rendimiento que pueda ya existir para su organización. Dichos criterios pueden indicar qué rendimiento se espera para operaciones específicas durante un período determinado. Esto puede ayudarle a responder cómo están funcionando sus servicios respecto a su implementación.
¿Por qué Realizar Análisis de Registros?
Teniendo nuestra tarea, ¿por qué revisar los registros? ¿Por qué realizar análisis de registros?
Para reconocer el uso y eficiencia del Sitio en la implementación del Utility Network, una estrategia comprobada es entender el rendimiento y utilización mediante los registros.
Hay varios beneficios con este enfoque:
- Sencillo de hacer
- Se realiza rápidamente
- Muy probable que ya exista data para analizar
- Lectura no invasiva
- Puedes tener un costo mínimo para recursos del servidor
Los registros de ArcGIS Enterprise (registros del ArcGIS Web Adaptor o registros del ArcGIS Server) pueden proporcionar un valioso registro de solicitudes cliente y respuestas servidor. Estos datos ofrecen una vista poderosa y precisa del pasado.
¿Cómo Realizar el Análisis?
La estrategia para este análisis es directa:
- Consumir los registros de la implementación
- Extraer información sobre las solicitudes
- Generar estadísticas sobre el rendimiento del servicio y funciones
Los datos pueden leerse y analizarse rápidamente usando una utilidad gratuita: System Log Parser
System Log Parser es una herramienta para procesar registros que puede ejecutarse mediante interfaz gráfica (GUI) o línea de comandos (para automatización). Está compilada para la plataforma Windows.
Estrategias para Análisis de Registros
¿Qué fuente usar para el análisis?
Pueden existir varias opciones para una implementación:
- ArcGIS Enterprise
- Registros acceso ArcGIS Web Adaptor
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- Nube
Pueden existir también opciones para accesibilidad:
- Acceso web
- Acceso red local
- Sistema local archivos
Cada fuente tiene fortalezas únicas y aunque puedan existir varias fuentes, se recomienda elegir una para el análisis principal (por ejemplo, registros acceso ArcGIS Web Adaptor).
Para este Artículo, la lectura será desde los registros acceso ArcGIS Web Adaptor vía red local como fuente principal.
Nota: La mayoría formatos registro son independientes del sistema operativo y estandarizan las columnas. Los registros ArcGIS Server siguen este patrón.
Ejecutando System Log Parser
Interfaz Gráfica (GUI)
Sencilla y configurable.
Opciones:
- Elegir fuente registro
< LI >Consulta registro Internet Information Services </ LI ></ UL ></ LI >< LI >< STRONG >Establecer ruta ubicación registro </ STRONG >< UL >< LI >Local: C:\inetpub\logs\LogFiles\W3SVC1 < UL >< LI >También puede especificar ubicación compartida en red: \\server1.yourdomain.org\w3svc1 </ LI ></ UL ></ LI ></ UL ></ LI >< LI >< STRONG >Establecer rango fecha </ STRONG >< UL >< LI >Hora local </ LI ></ UL ></ LI >< LI >< STRONG >Establecer Tipo Análisis a Optimizado (por defecto) </ STRONG >< UL >< LI >Rápido y eficiente en memoria en máquina ejecutando System Log Parser </ LI ></ UL ></ LI >< LI >< STRONG >¡Analizar registros! </ STRONG ></ LI ></ UL >< P ></ P >< H2 id = "toc-hId-1454392347" > Automatización por Línea Comandos </ H2 >< P > Igual funcionalidad que GUI pero con más flexibilidad. Ideal para generar informes automáticos periódicamente (ej., Tarea Programada Windows). </ P >< P > Ejemplo PowerShell: </ P >< UL >< LI >< STRONG >Elegir fuente registro </ STRONG >< UL >< LI > -f IIS </ LI ></ UL ></ LI >< LI >< STRONG >Establecer ruta ubicación registro </ STRONG ></ LI >< UL >< LI > Local: C:\inetpub\logs\LogFiles\W3SVC1 < UL >< LI > También puede especificar ubicación compartida en red: \\server1.yourdomain.org\w3svc1 </ LI ></ UL ></ LI ></ UL >< LI >< STRONG >Establecer rango fecha </ STRONG >< UL >< LI >Hora UTC< LI >Puede pasar valor datetime específico </ LI >< LI > -startstring "[Start_DateTime_UTC]" </ LI >< Li > -endstring "[End_DateTime_UTC]" </ Li ></ UL ></ Li ></ UL ></ Li >< Li >< STRONG >Establecer Tipo Análisis a Optimizado </ STRONG >< UL >< Li > -a Optimized </ Li ></ UL ></ Li >< Li >< STRONG >¡Analizar registros! </ STRONG ></ Li ></ UL >< pre class = "lia-code-sample language-csharp" > < code > PS C:\> # Ejecutar System Log Parser vía PowerShell
PS C:\> $startLocal = $endLocal = Get-Date # Ahora
PS C:\> $startLocal = $startLocal.AddDays(-7) # Retroceder 7 días
PS C:\> $startUtc = $startLocal.ToUniversalTime().ToString("yyyy/MM/dd h:mm:ss tt")
PS C:\> $endUtc = $endLocal.ToUniversalTime().ToString("yyyy/MM/dd h:mm:ss tt")
PS C:\> $iisLogPath = "C:\inetpub\logs\LogFiles\W3SVC1" # También podría ser \\server1\W3SVC1
PS C:\> $reportDate = $endLocal.ToString("yyyyMMddTHHmm")
& "C:\SystemLogParser\slp.exe" -f IIS -i "$iisLogPath" -startstring "$startUtc" -endstring "$endUtc" -a Optimized -d "C:\MyReports" -n "SLP_IIS_Optimized_$reportDate.xlsx" -o false </ code > </ pre >< P >< FONT color="#FF0000">Nota: Si no conoce el tamaño exacto sus datos, se recomienda iniciar con ventana consulta pequeña (ej., 1hr o 6hrs) hasta entender tiempo relativo computación. </ P >< H1 id = "toc-hId-1443889243" > El Informe Registro -- Entendiendo salida System Log Parser</ H1 >< P > Por defecto, el informe generado es basado en hoja cálculo. Crea un archivo XLSX que es un documento Open Office XML. El informe típicamente consiste en varias hojas, cada una resume una métrica particular.</ P >< H2 id = "toc-hId--486746840" > Hoja de ResumenLa página inicial enumera alguna información detallando:- La fecha en que se generó el informe
- El tipo de análisis del informe
- Ruta de registro especificada
- Tiempos de inicio y fin
- Estadísticas de consultas y solicitudes de registro a alto nivel
Hoja de Estadísticas Por MétodoLa hoja Estadísticas Por Método es un desglose de solicitudes y respuestas por función que ayuda a responder algunas de las preguntas principales de la tarea:- ¿Qué métodos (también llamados funciones u operaciones) fueron llamados?
- query, applyEdits, updateSubnetwork?
- ¿Cómo estaban funcionando los servicios?
La tabla en esta hoja proporciona mucha información. La vista predeterminada ordena las columnas de tiempo por el valor Sum más grande. Sum se deriva de la "request occurrence (Columna Count) * tiempo promedio de respuesta (Columna Avg)", lo que resalta el servicio y la operación en los que los servidores pasaron más tiempo para cumplir con las respuestas.Nota: Los tiempos de respuesta mostrados son solo para fines de demostración. Los tiempos de respuesta para cada implementación son únicos ya que el rendimiento está influenciado por muchos factores.Nota: La vista tabular de datos para una implementación real puede ser mucho más grande con más servicios y funciones adicionales reportadas.Además de Sum, Count y Average, se muestran las siguientes estadísticas para ayudar a proporcionar una comprensión más profunda sobre cómo están funcionando los servicios y funciones:- Min
- Mínimo, el valor más bajo o más rápido del tiempo de respuesta observado para esa función (de esa fuente del servicio)
- P50
- El percentil 50; el 50% de los datos del tiempo de respuesta para esa función (de esa fuente del servicio) están en o por debajo de este punto
- P95
- El percentil 95; el 95% de los datos del tiempo de respuesta para esa función (de esa fuente del servicio) están en o por debajo de este punto
- P99
- El percentil 99; el 99% de los datos del tiempo de respuesta para esa función (de esa fuente del servicio) están en o por debajo de este punto
- Max
- Máximo, el valor más alto del tiempo de respuesta observado para esa función (de la fuente del servicio)
- Stdev
- Desviación estándar, un cálculo sobre la dispersión o variación de los tiempos de respuesta para esa función (de esa fuente del servicio)
La tabla destaca que la función query fue el método más popular solicitado. Por tiempo computacional en la implementación, las tres principales operaciones fueron en realidad todas query (por ejemplo, MapServer, FeatureServer y Hosted) a través de dos servicios diferentes (Naperville_Electric y Naperville_Overlay).Mirando la columna Avg, el tiempo promedio de respuesta (en segundos) de estas funciones query se resume y las tres fueron subsegundos (es decir, menos de 1 segundo).Con los métodos query identificados, al escanear la tabla para otras funciones de interés se mostró que también se llamaron applyEdits y updateSubnetwork.Mirando otras funciones de interés, podemos observar applyEdits y updateSubnetwork. En promedio, applyEdits tuvo tiempos de respuesta subsegundos y updateSubnetwork tomó varios segundos.- Esta tabla ayuda a responder la pregunta sobre qué métodos fueron llamados
- Se encontró un perfil de rendimiento para tres diferentes queries junto con applyEdits y updateSubnetwork
- Otras funciones estuvieron presentes como trace, reconcile, and post
- En cuanto a cómo estaban funcionando los dos servicios reportados, la respuesta definitiva a esta pregunta puede variar según la organización:
- Típicamente basado en criterios existentes de rendimiento para el servicio, función y métrica
- Las ejecuciones iniciales del System Log Parser proporcionarán una comprensión del marco temporal seleccionado
- Esto debería proporcionar una buena muestra general
- Ejecutar System Log Parser regularmente le permitirá comparar cambios en perfiles de rendimiento
- Si se observa un comportamiento inusual en informes posteriores, puede ser necesaria una investigación o revisión
PNota: Típicamente, no todos los métodos siguen los mismos criterios de rendimiento. Cada función realiza un trabajo diferente al resto. Una consulta feature tendría un perfil diferente al updateSubnetwork.PHoja Conteo De Solicitudes Por RecursoP>La hoja Conteo De Solicitudes Por Recurso es una vista sencilla sobre qué servicios fueron los más populares. Los totales están separados en dos grupos:- Solicitudes De Recursos (solicitudes basadas en método)
- Enumera conteos basados en solicitudes que usaron funciones conocidas del servicio (totales similares a la hoja Estadísticas Por Método)
- Solicitudes De Recursos (solicitudes basadas en método y endpoint del servicio)
- Enumera conteos basados en solicitudes que usaron funciones conocidas del servicio y solicitudes a los endpoints REST del servicio que típicamente extraen metadatos (totales similares a la hoja Capability - Server)
- Quizás esto se pueda ajustar
- La entrada de la función (por ejemplo, los parámetros de la solicitud) también puede ser un factor
- Si los servicios son dedicados (como es con los servicios de Utility Network) y están configurados con el número apropiado de instancias
- Se podría eliminar el ajuste de configuración
La experiencia general del usuario:
- Está relacionada con las funciones ejercidas y su respectivo perfil de rendimiento
Nota: Hay varios factores que pueden influir en el rendimiento del servicio:
- Número de instancias
- Sólo disponible con servicios dedicados
- Los datos
- Los métodos llamados
- Así como los parámetros usados
- Arquitectura de despliegue
- Recursos hardware disponibles
- Demanda (por ejemplo, solicitudes concurrentes)
Ajustar estas características para modificar el rendimiento está fuera del alcance de este Artículo.
Informe de registro
El informe de registro generado facilitó responder las preguntas para la tarea.
¿Qué servicios fueron los más populares?
- Naperville_Electric fue el más popular seguido por Naperville_Overlay
¿Qué funciones fueron llamadas?
- Se llamaron muchos métodos diferentes: varias consultas espaciales, applyEdits, updateSubnetwork, trace, validateNetworkTopology, reconcile y post.
¿Cómo estaban funcionando los servicios?
- En última instancia, esta definición puede variar según la organización
- Típicamente se basa en un criterio o acuerdo que lista una expectativa para cada servicio y operación
- Sin embargo, a partir del informe System Log Parser:
- Pudo identificar el rendimiento del servicio y ver un perfil estadístico para cada operación (por servicio)
- Soporte para la toma de decisiones sobre mantenimiento y oportunidades de ajuste
Resumen
A partir del análisis del registro de ArcGIS Enterprise, se generó un informe que resumió la actividad de solicitudes y respuestas del despliegue Utility Network.
El análisis y desglose del rendimiento fueron realizados por System Log Parser. System Log Parser es una herramienta gratuita para Windows y también está listada en la sección de herramientas Well Architected Systems.
El informe proporcionó datos estadísticos para ayudar a responder preguntas sobre el Sitio tales como:
- Cuál fue el servicio más popular
- Qué métodos fueron llamados por estos servicios
- Cómo estaban funcionando los servicios y si el Sitio estaba bien gestionado
- Estas preguntas pudieron ser respondidas
- Cuando se emparejan con los objetivos de rendimiento de la organización
- A partir del juicio basado en la experiencia
Sin embargo, a pesar del análisis y la tarea completada...¡tu trabajo no ha terminado!
El mejor análisis del Sitio proviene de evaluar periódicamente el despliegue, porque:
- Las tendencias de uso cambian con el tiempo
- Algunos servicios pueden volverse más populares, otros menos
- Una oportunidad potencial para optimizar las configuraciones de servicios dedicados
- Quieres construir conocimiento histórico sobre el comportamiento del rendimiento del Sitio
- Entender cómo funcionan las funciones desde los servicios puede ayudar a identificar cuándo los comportamientos y/o patrones parecen fuera de lugar o inusuales
- Esto puede ayudar con la resolución de problemas y ajustes
- Puedes destacar cuándo los servicios y funciones
- Són óptimos
- No son óptimos
P>Ejecución regular de System Log Parser (por ejemplo, una vez al mes) puede ayudarte a construir un entendimiento histórico del rendimiento de tu Sitio. Este Artículo se centró en analizar un Sitio con servicios Utility Network pero la práctica y estrategias podrían aplicarse a cualquier despliegue GIS.
