Logs do ArcGIS Enterprise e Parser de Log do Sistema
Embora existam vários Artigos da Comunidade que discutem a análise dos logs do ArcGIS Enterprise e como começar com o Parser de Log do Sistema:
Existem poucos recursos que detalham o relatório gerado em planilha e como tomar decisões como administrador GIS e/ou desenvolvedor com base nas informações de desempenho que ele fornece.
Este Artigo irá mostrar como realizar uma análise de log em uma implantação da Utility Network que pode então ser usada para construir conhecimento sobre o uso e eficiência do Site.
Análise de Desempenho dos Logs do ArcGIS Enterprise
Antes de começar, vamos revisar o que é análise de log e onde esses dados de log podem ser encontrados em uma implantação ArcGIS.
Análise de Log:
O processo de extrair informações dos dados de log. Essas informações podem ser usadas para quantificar o uso do GIS e ajudar a responder:
- Quais serviços os usuários estão solicitando?
- Quais operações eles estão realizando?
- Qual desempenho eles estão experimentando?
Dados de Log:
Os dados de log a serem analisados são os logs do ArcGIS Enterprise. Normalmente, esses dados residem nos servidores da implantação e vêm em diferentes formas:
- Logs de acesso do ArcGIS Web Adaptor
- A fonte dos dados de log usada neste Artigo
- Logs de acesso do ArcGIS Server
- Logs gerados pelo ArcGIS Pro
Cada fonte de log oferece sua própria riqueza de informações.
Cenário Exemplo para Análise de Log
O seguinte cenário é o caso de uso para nossa análise de log:
Seu gerente atribuiu uma tarefa:
Quantificar o uso e eficiência da Utility Network do ArcGIS do seu Site
Isto significa que as seguintes perguntas precisam ser respondidas:
- O Site está bem gerenciado e é ótimo?
- Quais serviços são os mais populares?
- Quais métodos são chamados?
- query, applyEdits, updateSubnetwork
- Como os serviços estão performando?
- Experiência geral do usuário?
Nosso gerente também pediu que essa análise seja realizada de maneira econômica.
Nota: Antes de iniciar a análise dos logs, recomenda-se consultar quaisquer metas de desempenho que já possam existir para sua organização. Tais critérios podem indicar qual desempenho é esperado para operações específicas, durante um determinado período. Isso pode ajudar a responder como seus serviços estão performando em relação à sua implantação.
Por Que Realizar Análise de Log?
Temos nossa tarefa em mãos, mas por que analisar os logs? Por que realizar análise de log?
Para reconhecer o uso do Site e a eficiência da implantação da Utility Network, uma estratégia comprovada é entender o desempenho das requisições e utilização através dos logs.
Existem vários benefícios com essa abordagem:
- Fácil de fazer
- Realizado rapidamente
- Muito provável que os dados já existam para analisar
- Lido sem invasão
- Pode ter custo mínimo para recursos do servidor
Os logs do ArcGIS Enterprise (logs de acesso do ArcGIS Web Adaptor ou logs do ArcGIS Server) podem fornecer um registro valioso das requisições dos clientes e respostas do servidor. Esses dados são uma visão poderosa e precisa do passado.
Como Realizar a Análise?
A estratégia para esta análise é direta:
- Consumir os logs da implantação
- Extrair informações das requisições
- Gerar estatísticas sobre o desempenho dos serviços e funções
Os dados dos logs podem ser lidos e analisados rapidamente usando uma ferramenta gratuita: System Log Parser
System Log Parser é uma ferramenta para processar logs que pode ser executada via interface gráfica (GUI) ou linha de comando (para scripts automatizados). É compilada para a plataforma Windows.
Estratégias para Análise de Log
Qual fonte de log deve ser usada para a análise?
Diversas opções podem existir para uma implantação:
- ArcGIS Enterprise
- Logs de acesso do ArcGIS Web Adaptor
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- Nuvem
Também podem existir opções de acessibilidade:
- Acesso web
- Acesso via rede local
- Acesso ao sistema local de arquivos
Cada fonte tem pontos fortes únicos e embora várias fontes possam existir para uma implantação, recomenda-se escolher uma e usá-la como principal para a análise (por exemplo, logs de acesso do ArcGIS Web Adaptor).
Para este Artigo, a leitura dos logs de acesso do ArcGIS Web Adaptor pela rede local será a fonte dos dados.
Nota: A maioria dos formatos de log são independentes do sistema operacional e padronizam as colunas dos dados. Os logs do ArcGIS Server seguem esse padrão.
Executando o System Log Parser
Interface Gráfica do Usuário
Fácil de usar e configurável.
Opções:
- Escolher fonte dos logs
- Consulta aos Logs do Internet Information Services
- Definir caminho da localização dos logs
< LI >Local: C:\inetpub\logs\LogFiles\W3SVC1< LI >Também pode especificar um local compartilhado na rede: \\server1.yourdomain.org\w3svc1 </ LI ></ UL ></ LI ></ UL ></ LI >< LI >< STRONG >Definir intervalo de datas </ STRONG >< UL >< LI >Hora Local </ LI ></ UL ></ LI >< LI >< STRONG >Definir Tipo de Análise para Otimizado (padrão) </ STRONG >< UL >< LI >Rápido e eficiente em memória na máquina executando o System Log Parser </ LI ></ UL ></ LI >< LI >< STRONG >Analisar logs! </ STRONG ></ LI ></ UL >< P ></ P >< H2 id = "toc-hId-1454392347" >Automação via Linha de Comando</ H2 >< P >Mesma funcionalidade da GUI mas com um pouco mais flexibilidade. Ideal para gerar relatórios automatizados periodicamente (por exemplo, uma Tarefa Agendada no Windows).</ P >< P >Exemplo PowerShell:</ P >< UL >< LI >< STRONG >Escolher fonte dos logs </ STRONG >< UL >< LI >-f IIS </ LI ></ UL ></ LI >< LI >< STRONG >Definir caminho da localização dos logs </ STRONG ></ LI >< UL >< LI >Local: C:\inetpub\logs\LogFiles\W3SVC1< LI >Também pode especificar um local compartilhado na rede: \\server1.yourdomain.org\w3svc1 </ LI ></ UL ></ LI ></ UL >< LI >< STRONG >Definir intervalo de datas </ STRONG >< UL >< LI >Hora em UTC< LI >Pode passar um valor datetime específico </ LI >< LI >-startstring "[Start_DateTime_UTC]" </ LI >< LI >-endstring "[End_DateTime_UTC]" </ LI ></ UL ></ LI ></ UL ></ LI >< LI >< STRONG >Definir Tipo de Análise para Otimizado </ STRONG >< UL >< LI >-a Optimized </ LI ></ UL ></ LI >< LI >< STRONG >Analisar logs! </ STRONG ></ LI ></ UL >< pre class = "lia-code-sample language-csharp" >< code >PS C:\> # Executar System Log Parser via PowerShell
PS C:\> $startLocal = $endLocal = Get-Date # Agora
PS C:\> $startLocal = $startLocal.AddDays(-7) # Voltar 7 dias
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" # Também poderia 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< P >< FONT color="#FF0000">Nota: Se o tamanho dos seus dados de log for desconhecido, recomenda-se começar com uma janela menor na consulta (por exemplo, 1hr ou 6hrs) até entender um tempo relativo computacional. </ FONT ></ P >< H1 id = "toc-hId-1443889243" >O Relatório de Logs -- Entendendo a saída do System Log Parser</ H1 >< P >Por padrão, o relatório gerado é baseado em planilha. Ele cria um arquivo XLSX que é um documento Open Office XML. O relatório normalmente consiste em várias planilhas, cada uma resumindo uma métrica particular.</ P >< H2 id = "toc-hId--486746840">Planilha ResumoA página inicial lista algumas informações detalhando:- A data em que o relatório foi gerado
- O tipo de análise do relatório
- Caminho do log especificado
- Horários de Início e Fim
- Estatísticas de consulta de log e requisições em alto nível
Planilha Estatísticas Por MétodoA planilha Estatísticas Por Método é uma divisão das requisições e respostas por função que ajudam a responder algumas das principais perguntas da tarefa:- Quais métodos (também chamados de funções ou operações) foram chamados?
- query, applyEdits, updateSubnetwork?
- Como os serviços estavam performando?
A tabela nesta planilha fornece uma grande quantidade de informações. A visualização padrão ordena as colunas de tempo pelo maior valor da Soma. Soma é derivada do "request occurrence (coluna Count) * tempo médio de resposta (coluna Avg)", que destaca o serviço e operação nos quais os servidores gastaram mais tempo para atender as respostas.Nota: Tempos de resposta mostrados apenas para fins de demonstração. Os tempos de resposta para cada implantação são únicos, pois o desempenho é influenciado por muitos fatores.Nota: A visualização tabular dos dados para implantação real pode ser muito maior com mais serviços e funções adicionais relatadas.Além da Soma, Count e Média, as seguintes estatísticas são exibidas para ajudar a fornecer uma compreensão mais profunda sobre como os serviços e funções estão performando:- Min
- Mínimo, o menor ou mais rápido valor de tempo de resposta observado para essa função (daquela fonte de serviço)
- P50
- O percentil 50; 50% dos dados de tempo de resposta para essa função (daquela fonte de serviço) estão nesse ponto ou abaixo dele
- P95
- O percentil 95; 95% dos dados de tempo de resposta para essa função (daquela fonte de serviço) estão nesse ponto ou abaixo dele
- P99
- O percentil 99; 99% dos dados de tempo de resposta para essa função (daquela fonte de serviço) estão nesse ponto ou abaixo dele
- Max
- Máximo, o maior valor de tempo de resposta observado para essa função (da fonte do serviço)
- Stdev
- Desvio padrão, um cálculo sobre a dispersão ou variação dos tempos de resposta para essa função (da fonte do serviço)
A tabela destaca que a função query foi o método mais popular solicitado. Pelo tempo computacional da implantação, as três principais operações foram na verdade todas query (por exemplo, MapServer, FeatureServer e Hosted) em dois serviços diferentes (Naperville_Electric e Naperville_Overlay).Olhando para a coluna Avg, o tempo médio de resposta (em segundos) dessas funções query está resumido e todas as três foram sub-segundo (ou seja, menos que 1 segundo). Com os métodos query identificados, ao escanear a tabela por outras funções de interesse mostrou que applyEdits e updateSubnetwork também foram chamados.Olhando para outras funções de interesse, podemos observar applyEdits e updateSubnetwork. Em média, applyEdits teve tempos de resposta sub-segundos e updateSubnetwork levou vários segundos.- Esta tabela ajuda a responder à pergunta sobre quais métodos foram chamados
- Um perfil de desempenho para três diferentes queries foi encontrado junto com applyEdits e updateSubnetwork
- Outras funções estavam presentes como trace, reconcile e post
- Quanto ao desempenho dos dois serviços relatados, a resposta definitiva para esta questão pode variar conforme a organização:
- Normalmente baseado em critérios existentes de desempenho para o serviço, função e métrica
- Execuções iniciais do System Log Parser fornecerão uma compreensão do período atual selecionado
- Isto deve fornecer uma boa amostra geral
- Executar o System Log Parser regularmente permitirá comparar mudanças nos perfis de desempenho
- Se comportamento incomum for observado em relatórios subsequentes, uma investigação ou revisão pode ser necessária
PNota: Normalmente, nem todos os métodos seguem os mesmos critérios de desempenho. Cada função realiza trabalho diferente das outras. Uma consulta feature teria um perfil de desempenho diferente do updateSubnetwork./PPlanilha Contagem De Requisições Por RecursoP>A planilha Contagem De Requisições Por Recurso é uma visão fácil sobre quais serviços foram os mais populares. Os totais são separados em dois grupos:- Requisições De Recursos (requisições baseadas em método)
- Lista contagens baseadas em requisições que usaram funções conhecidas do serviço (totais similares à planilha Estatísticas Por Método)
- Requisições De Recursos (requisições baseadas em método e endpoint do serviço)
- Lista contagens baseadas em requisições que usaram funções conhecidas dos serviços e requisições aos endpoints REST do serviço que normalmente puxam metadados (totais similares à planilha Capability - Server)
- Talvez isso possa ser ajustado
- A entrada da função (por exemplo, os parâmetros da solicitação) também pode ser um fator
- Se os serviços forem dedicados (como é com os serviços Utility Network) e estiverem configurados com o número apropriado de instâncias
- Ajuste de configuração poderia ser eliminado
A experiência geral do usuário:
- Está relacionada às funções exercidas e seu respectivo perfil de desempenho
Nota: Existem vários fatores que podem influenciar o desempenho do serviço:
- Número de instâncias
- Disponível apenas com serviços dedicados
- Os dados
- Os métodos chamados
- Assim como os parâmetros usados
- Arquitetura de implantação
- Recursos de hardware disponíveis
- Demanda (por exemplo, solicitações simultâneas)
Ajustar essas características para modificar o desempenho está fora do escopo deste Artigo.
Relatório de Log
O relatório de log gerado facilitou responder às perguntas da tarefa.
Quais serviços foram os mais populares?
- Naperville_Electric foi o mais popular seguido por Naperville_Overlay
Quais funções foram chamadas?
- Muitos métodos diferentes foram chamados: várias consultas espaciais, applyEdits, updateSubnetwork, trace, validateNetworkTopology, reconcile e post.
Como os serviços estavam performando?
- Em última análise, essa definição pode variar conforme a organização
- Normalmente é baseada em um critério ou acordo que lista uma expectativa para cada serviço e operação
- No entanto, a partir do relatório System Log Parser:
- Pode-se identificar o desempenho do serviço e ver um perfil estatístico para cada operação (por serviço)
- Suporte à decisão para oportunidades de manutenção e ajuste
Resumo
A partir da análise do log do ArcGIS Enterprise, foi gerado um relatório que resumiu a atividade de solicitação e resposta da implantação Utility Network.
A análise e detalhamento do desempenho foram feitos pelo System Log Parser. System Log Parser é uma ferramenta gratuita para Windows e também está listada na seção de ferramentas Well Architected Systems.
O relatório forneceu dados estatísticos para ajudar a responder perguntas sobre o Site, tais como:
- Qual foi o serviço mais popular
- Quais métodos foram chamados por esses serviços
- Como os serviços estavam performando e se o Site estava bem gerenciado
- Essas perguntas puderam ser respondidas
- Quando combinadas com metas de desempenho da organização
- A partir do julgamento baseado na experiência
No entanto, apesar da análise e da tarefa terem sido concluídas...seu trabalho não acabou!
A melhor análise do Site vem de avaliar periodicamente a implantação, porque:
- Tendências de uso mudam ao longo do tempo
- Alguns serviços podem se tornar mais populares, outros menos
- Uma oportunidade potencial para otimizar configurações de serviços dedicados
- Você quer construir conhecimento histórico sobre o comportamento de desempenho do Site
- Entender como as funções performam nos serviços pode ajudar a identificar quando comportamentos e/ou padrões parecem fora do lugar ou incomuns
- Isto pode ajudar na solução de problemas e ajustes
- Pode ajudar a destacar quando os serviços e funções
Correr o System Log Parser regularmente (por exemplo, uma vez por mês) pode ajudar você a construir um entendimento histórico do desempenho do seu Site. Este Artigo focou na análise de um Site com serviços Utility Network mas a prática e estratégias poderiam ser aplicadas a qualquer implantação GIS.
