Journaux ArcGIS Enterprise et Analyseur de Journaux Système
Bien que plusieurs Articles Communautaires existent qui discutent de l'analyse des journaux ArcGIS Enterprise et comment commencer avec System Log Parser :
Il existe peu de ressources qui détaillent le rapport généré sous forme de feuille de calcul et comment prendre des décisions en tant qu'administrateur GIS et/ou développeur basées sur les informations de performance qu'il fournit.
Cet Article expliquera comment effectuer une analyse des journaux sur un déploiement Utility Network qui pourra ensuite être utilisé pour acquérir des connaissances sur l'utilisation et l'efficacité du Site.
Analyse des Performances des Journaux ArcGIS Enterprise
Avant de commencer, examinons ce qu'est l'analyse des journaux et où ces données de journal peuvent être trouvées dans un déploiement ArcGIS.
Analyse des Journaux :
Le processus d'extraction d'informations à partir des données de journal. Ces informations peuvent être utilisées pour quantifier l'utilisation du GIS et aider à répondre à :
- Quels services les utilisateurs demandent-ils ?
- Quelles opérations effectuent-ils ?
- Quelle performance expérimentent-ils ?
Données de Journal :
Les données de journal à analyser sont les journaux ArcGIS Enterprise. Typiquement, ces données résident sur les serveurs du déploiement et se présentent sous différentes formes :
- Journaux d'accès ArcGIS Web Adaptor
- La source des données de journal utilisée dans cet Article
- Journaux d'accès ArcGIS Server
- Journaux générés par ArcGIS Pro
Chaque source de journal offre sa propre richesse d'informations.
Scénario Exemple pour l'Analyse des Journaux
Le scénario suivant est le cas d'utilisation pour notre analyse des journaux :
Votre manager a assigné une tâche :
Quantifier l'utilisation et l'efficacité du ArcGIS Utility Network de votre Site
Cela signifie que les questions suivantes devront être répondues :
- Le Site est-il bien géré et optimal ?
- Quels services sont les plus populaires ?
- Quelles méthodes sont appelées ?
- query, applyEdits, updateSubnetwork
- Comment les services performent-ils ?
- Expérience utilisateur globale ?
Notre manager a également demandé que cette analyse soit réalisée de manière économique.
Note : Avant de commencer l'analyse des journaux, il est recommandé de se référer à tout objectif de performance qui pourrait déjà exister pour votre organisation. Ces critères peuvent indiquer quelle performance est attendue pour des opérations spécifiques, pendant une période donnée. Cela peut vous aider à répondre à la question de savoir comment vos services performent par rapport à votre déploiement.
Pourquoi Effectuer une Analyse des Journaux ?
Nous avons notre tâche en main, mais pourquoi passer par les journaux ? Pourquoi effectuer une analyse des journaux ?
Pour reconnaître l'utilisation du Site et l'efficacité du déploiement Utility Network, une stratégie éprouvée est de comprendre la performance et l'utilisation des requêtes via les journaux.
Cette approche présente plusieurs avantages :
- Facile à faire
- Réalisation rapide
- Données très probablement déjà existantes à analyser
- Lecture non invasive
- Peut avoir un coût minimal pour les ressources serveur
Les journaux ArcGIS Enterprise (journaux d'accès ArcGIS Web Adaptor ou journaux ArcGIS Server) peuvent fournir un enregistrement précieux des requêtes clients et réponses serveur. Ces données offrent une vue puissante et précise du passé.
Comment Réaliser l'Analyse ?
La stratégie pour cette analyse est simple :
- Consommer les journaux du déploiement
- Extraire les informations des requêtes
- Générer des statistiques sur la performance des services et fonctions
Les données de journal peuvent être lues et analysées rapidement en utilisant un utilitaire gratuit : System Log Parser
System Log Parser est un outil pour digérer les journaux qui peut être exécuté via une interface graphique utilisateur (GUI) ou en ligne de commande (pour automatisation par script). Il est compilé pour la plateforme Windows.
Stratégies d'Analyse des Journaux
Quelle source de journal doit être utilisée pour l'analyse ?
Diverses options sources peuvent exister pour un déploiement :
- ArcGIS Enterprise
- Journaux d'accès ArcGIS Web Adaptor
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- Nebuleuse (Cloud)
Des options d'accessibilité peuvent également exister :
- Accès web
- Accès réseau local
- Accès système local aux fichiers
Chaque source a ses forces uniques et bien que plusieurs sources puissent exister pour un déploiement, il est recommandé d'en choisir une seule comme source principale pour l'analyse (par exemple, les journaux d'accès ArcGIS Web Adaptor).
Pour cet Article, la lecture des journaux d'accès ArcGIS Web Adaptor via le réseau local sera la source des données.
Note : La plupart des formats de journal sont indépendants du système d'exploitation et standardisent les colonnes de données. Les journaux ArcGIS Server suivent ce modèle.
Exécution de System Log Parser
Interface Graphique Utilisateur
Facile à utiliser et configurable.
Options :
- Choisir la source du journal
- Requête Journal Internet Information Services
- Définir le chemin d'emplacement du journal
- Local : C:\inetpub\logs\LogFiles\W3SVC1
- Peut aussi spécifier un emplacement réseau partagé : \\server1.yourdomain.org\w3svc1
- Définir la plage de dates
- Définir le type d'analyse sur Optimisé (par défaut)
- Rapide et efficace en mémoire sur la machine exécutant System Log Parser
- Analyser les journaux !
Automatisation en Ligne de Commande
Même fonctionnalité que GUI mais un peu plus flexible. Idéal pour générer périodiquement des rapports automatisés (par exemple, une tâche planifiée Windows).
Exemple PowerShell :
- Choisir la source du journal
- Définir le chemin d'emplacement du journal
- Local : C:\inetpub\logs\LogFiles\W3SVC1
- Peut aussi spécifier un emplacement réseau partagé : \\server1.yourdomain.org\w3svc1
- Définir la plage de dates
- Heure en UTC
- Peut passer une valeur datetime spécifique
- -startstring "[Start_DateTime_UTC]"
- -endstring "[End_DateTime_UTC]"
- Définir le type d'analyse sur Optimisé
- Analyser les journaux !
PS C:\> # Exécuter System Log Parser via PowerShell
PS C:\> $startLocal = $endLocal = Get-Date # Maintenant
PS C:\> $startLocal = $startLocal.AddDays(-7) # Reculer 7 jours
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" # Peut aussi être \\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 falseNote : Si la taille de vos données de journal est inconnue, il est recommandé de commencer avec une fenêtre de requête plus petite (par exemple, 1h ou 6h) jusqu'à ce qu'un temps relatif de calcul soit compris.
Le Rapport Journal -- Comprendre la sortie System Log Parser
Par défaut, le rapport généré est basé sur une feuille de calcul. Il crée un fichier XLSX qui est un document Open Office XML. Le rapport consiste typiquement en plusieurs feuilles, chacune résumant une métrique particulière.
Feuille de résumé
La page initiale liste quelques informations détaillant :
- La date à laquelle le rapport a été généré
- Le type d'analyse du rapport
- Chemin de journal spécifié
- Heures de début et de fin
- Statistiques de requêtes et demandes de journal de haut niveau
Feuille de statistiques par méthode
La feuille Statistiques par méthode est une répartition des requêtes et réponses par fonction qui aide à répondre à certaines des questions principales de la tâche :
- Quelles méthodes (également appelées fonctions ou opérations) ont été appelées ?
- query, applyEdits, updateSubnetwork ?
- Comment les services fonctionnaient-ils ?
Le tableau sur cette feuille fournit beaucoup d'informations. La vue par défaut trie les colonnes de temps par la plus grande valeur Sum. Sum est dérivé de la "request occurrence (colonne Count) * temps moyen de réponse (colonne Avg)", ce qui met en évidence le service et l'opération sur lesquels les serveurs ont passé le plus de temps pour satisfaire les réponses.
Note : Les temps de réponse affichés sont uniquement à des fins de démonstration. Les temps de réponse pour chaque déploiement sont uniques car la performance est influencée par de nombreux facteurs.
Note : La vue tabulaire des données pour un déploiement réel peut être beaucoup plus grande avec plus de services et des fonctions supplémentaires rapportées.
En plus de Sum, Count et Average, les statistiques suivantes sont affichées pour aider à fournir une compréhension plus approfondie sur la performance des services et fonctions :
- Min
- Minimum, la valeur la plus faible ou la plus rapide du temps de réponse observée pour cette fonction (depuis cette source de service)
- P50
- Le 50e percentile ; 50 % des données de temps de réponse pour cette fonction (depuis cette source de service) se situent à ce point ou en dessous
- P95
- Le 95e percentile ; 95 % des données de temps de réponse pour cette fonction (depuis cette source de service) se situent à ce point ou en dessous
- P99
- Le 99e percentile ; 99 % des données de temps de réponse pour cette fonction (depuis cette source de service) se situent à ce point ou en dessous
- Max
- Maximum, la valeur la plus élevée du temps de réponse observée pour cette fonction (depuis la source du service)
- Stdev
- Écart type, un calcul sur la dispersion ou variation des temps de réponse pour cette fonction (depuis cette source de service)
Le tableau met en évidence que la fonction query était la méthode la plus populaire demandée. Par temps informatique du déploiement, les trois principales opérations étaient en fait toutes query (par exemple, MapServer, FeatureServer et Hosted) à travers deux services différents (Naperville_Electric et Naperville_Overlay).
En regardant la colonne Avg, le temps moyen de réponse (en secondes) de ces fonctions query est résumé et les trois étaient inférieurs à une seconde (c'est-à-dire moins d'une seconde).
Avec l'identification des méthodes query, l'examen du tableau pour d'autres fonctions d'intérêt a montré que applyEdits et updateSubnetwork ont également été appelés.
En regardant d'autres fonctions d'intérêt, nous pouvons observer applyEdits et updateSubnetwork. En moyenne, applyEdits avait des temps de réponse inférieurs à une seconde et updateSubnetwork prenait plusieurs secondes.
- Ce tableau aide à répondre à la question des méthodes qui ont été appelées
- Un profil de performance pour trois queries différentes a été trouvé ainsi que applyEdits et updateSubnetwork
- D'autres fonctions étaient présentes comme trace, reconcile, and post
- Quant à la performance des deux services rapportés, la réponse définitive à cette question peut varier selon l'organisation :
- Typiquement basée sur les critères existants de performance pour le service, la fonction et la métrique
- Les premières exécutions du System Log Parser donneront une compréhension du cadre temporel actuel sélectionné
- Cela devrait fournir un bon échantillon global
- L'exécution régulière du System Log Parser vous permettra de comparer les changements dans les profils de performance
- Si un comportement inhabituel est observé dans les rapports suivants, une enquête ou une révision peut être nécessaire
Note : Typiquement, toutes les méthodes ne suivent pas les mêmes critères de performance. Chaque fonction effectue un travail différent des autres. Une requête feature aurait un profil de performance différent d'updateSubnetwork.
Feuille des comptes des requêtes par ressource
La feuille Comptes des requêtes par ressource offre une vue simple sur quels services étaient les plus populaires. Les totaux sont séparés en deux groupes :
- Requêtes Ressource (requêtes basées sur méthode)
- Liste les comptes basés sur les requêtes qui utilisaient des fonctions connues du service (totaux similaires à ceux de la feuille Statistiques par méthode)
- Requêtes Ressource (requêtes basées sur méthode et point d'accès service)
- Liste les comptes basés sur les requêtes qui utilisaient des fonctions connues du service et les requêtes aux points d'accès REST du service qui tirent typiquement les métadonnées (totaux similaires à ceux de la feuille Capability - Server)
< P >< span class = un petit nombre de requêtes dans les plages de temps plus longues indique qu'il y a certaines fonctions qui s'exécutent plus longtemps
- Peut-être que cela peut être ajusté
- L'entrée de la fonction (par exemple, les paramètres de la requête) peut également être un facteur
Si les services sont dédiés (comme c'est le cas avec les services Utility Network) et qu'ils sont configurés avec le nombre approprié d'instances
- L'ajustement de la configuration pourrait être éliminé
L'expérience utilisateur globale :
- Est liée aux fonctions exercées et à leur profil de performance respectif
Note : Plusieurs facteurs peuvent influencer la performance du service :
- Nombre d'instances
- Disponible uniquement avec des services dédiés
- Les données
- Les méthodes appelées
- Ainsi que les paramètres utilisés
- Architecture de déploiement
- Ressources matérielles disponibles
- Demande (par exemple, requêtes simultanées)
L'ajustement de ces caractéristiques pour modifier la performance est hors du cadre de cet Article.
Rapport de journalisation
Le rapport de journalisation généré a facilité la réponse aux questions pour la tâche.
Quels services étaient les plus populaires ?
- Naperville_Electric était le plus populaire suivi par Naperville_Overlay
Quelles fonctions ont été appelées ?
- De nombreuses méthodes différentes ont été appelées : plusieurs requêtes spatiales, applyEdits, updateSubnetwork, trace, validateNetworkTopology, reconcile et post.
Comment les services performaient-ils ?
- En fin de compte, cette définition peut varier selon l'organisation
- Elle est généralement basée sur un critère ou un accord qui liste une attente pour chaque service et opération
- Cependant, d'après le rapport System Log Parser :
- A permis d'identifier la performance du service et de voir un profil statistique pour chaque opération (par service)
- Soutien à la décision pour les opportunités de maintenance et d'ajustement
Résumé
À partir de l'analyse des journaux ArcGIS Enterprise, un rapport a été généré qui résumait l'activité des requêtes et réponses du déploiement Utility Network.
L'analyse et la répartition des performances provenaient de System Log Parser. System Log Parser est un outil gratuit pour Windows et est également listé dans la section outils Well Architected Systems.
Le rapport fournissait des données statistiques pour aider à répondre aux questions concernant le Site telles que :
- Quel était le service le plus populaire
- Quelles méthodes ont été appelées par ces services
- Comment les services performaient et si le Site était bien géré
- Cela pouvait être répondu
- Lorsqu'associé aux objectifs de performance de l'organisation
- D'après un jugement basé sur l'expérience
Cependant, malgré l'analyse et la tâche accomplies...votre travail n'est pas terminé !
L'analyse la plus efficace du Site vient de l'évaluation périodique du déploiement, car :
- Les tendances d'utilisation changent avec le temps
- Certaines services peuvent devenir plus populaires, d'autres moins
- Une opportunité potentielle d'optimiser les configurations des services dédiés
- Vous souhaitez accumuler une connaissance historique du comportement des performances du Site
- Comprendre comment les fonctions performent à partir des services peut aider à identifier quand des comportements et/ou des modèles semblent anormaux ou inhabituels
- Cela peut aider au dépannage et à l'ajustement
- Peut aider à mettre en évidence quand les services et fonctions
- Sont optimaux
- Ne sont pas optimaux
L'exécution régulière de System Log Parser (par exemple, une fois par mois) peut vous aider à construire une compréhension historique des performances de votre Site. Cet Article s'est concentré sur l'analyse d'un Site avec des services Utility Network mais la pratique et les stratégies pourraient être appliquées à tout déploiement SIG.
