Application Insights Azure

Monitorando WebJobs com Azure Application Insights

Olá Pessoal, tudo bem?

E aí, já começaram a usar o Azure Application Insights para monitorar suas aplicações no Azure? Why not??

Mas e se já começaram, apenas fazem o ping-test? Why??

A dica de hoje vai para voce que quer sair do “básico” e monitorar decentemente seus WebJobs 🙂

O Azure Application Insights é um dos lançamentos para o Azure (general availability em Novembro/2016) e essencial para aqueles que já utilizam a plataforma devido às informações preciosas que ele fornece.

Não iremos abordar neste post um overview ou configurações iniciais do serviço. Para tal conteúdo, sugiro os links abaixo:

Neste post iremos abordar como monitorar os webjobs pelo status, duração, ou qualquer outra informação retornada nas consulta à sua rest API via KUDU.

 

Mãos à obra!

Iremos iniciar as configurações considerando que voce ja possua o Azure Application Insights previamente configurado em sua subscription, conforme imagem abaixo:

Mas antes disso precisamos obter algumas informações para criarmos nosso teste no Azure Application Insights.

Para isso entre no App Service desejado, clique na guia WebJobs e por último acesse as Properties do WebJob:

Mais detalhes:

O mais importante até agora é a property web hook, que irá definir o endereço da chamada da API. Segue abaixo formato da URL:

https://{application-name}.scm.azurewebsites.net/api/{continuouswebjobs | triggeredwebjobs}/{job-name}/run

 

O que importa neste momento é a URL full até o job-name. Por hora podemos ignorar o método run. Portanto ao acessar a URL abaixo em uma sessão do browser previamente autenticada:

https://{application-name}.scm.azurewebsites.net/api/{continuouswebjobs | triggeredwebjobs}/{job-name}/

 

Deveremos ter um retorno em formato JSON sobre o último status do Job:

  • Para jobs contínuos: temos um retorno de running/ stoppped/ pending start
  • Para job triggered: temos um retorno de success/ failed

Mas claro, por questões de segurança não temos um acesso público a esta API, e para obter este retorno precisamos estar autenticados.

Para isso iremos criar uma key que será utilizado no header dessa chamada da API, portanto lembre-se de obter nas propriedades do WebJob o usuário e senha utilizados.

Podemos criar a key podemos utiliando o seguinte comando powershell:

[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f "`$aqui-vai-o-username", "aqui-vai-o-password")))

 

O retorno disso deverá ser um hash de 100 caracteres.

Para validar se está tudo ok, podemos validar com o Postman e fazer o seguinte teste:

 

GET (URL)https://{application-name}.scm.azurewebsites.net/api/{continuouswebjobs | triggeredwebjobs}/{job-name}/

Headers (key): Authorization

Value: Basic AQUI-VAI-MEU-HASH-DE-100-CARACTERES

 

Clique em Send para validar o retorno!

 

It’s code time (maybe not)!

Agora que temos todos as informações necessárias, vamos no Visual Studio (2017) criar um novo projeto do tipo WebTest:

Por padrão no VS2017 não temos este template de projeto. Para habilitá-lo consulte o link abaixo:

https://social.msdn.microsoft.com/Forums/vstudio/en-US/3533b549-31f7-4b4c-aef7-0f7442f0daa7/web-performance-and-load-test-project-template-missing-in-vs-2017-enterprise?forum=vsunittest

De um modo geral, basta alterar a instalação do VS para incluir novas features:

No novo projeto vamos adicionar um request:

Na property URL do request defina a URL obtida acima no WebJob.

Lembre-se: não iremos utilizar o “/run”, portanto o formato da URL deverá ser igual o abaixo:

https://{application-name}.scm.azurewebsites.net/api/{continuouswebjobs | triggeredwebjobs}/{job-name}

 

Com a URL adicionada iremos agora adicionar uma validação:

Configure conforme modelo abaixo:

Neste caso estamos validando o output se temos Success (para jobs triggered) ou Running (para jobs continuos).

Clique em OK para finalizar.

Em seguida precisamos adicionar um Header, clicando com o botão direto na URL definida > Add Header:

Nas configurações de Header iremos definir o hash de autenticação definido previamente:

A configuração final deverá estar conforme o modelo abaixo:

Voce já pode fazer seu WebTest pelo próprio VS, mas o que importa pra gente neste momento não é o projeto em si, pois não iremos realizar nenhuma publicação pelo VS, e sim o XML definition chamado {nome-do-meu-projeto}.webtest e que estará no mesmo diretório do projeto:

“- Mas posso utilizar outras regras ou validações adicionais?”

Absolutamente!

 

Mas e seu eu não tenho VS e esse arquivo de configuração é só um XML, então…

Isso mesmo! Você não precisa obrigatoriamente do VS para fazer um monitoramente dos seus webjobs!

Sinta-se à vontade para utilizar o template abaixo!

<?xml version="1.0" encoding="utf-8"?>
<WebTest Name="template-tarcisiogambin.net" Id="8929b760-8ff4-40a8-be43-a68d2c70f536" Owner="" Priority="2147483647" Enabled="True" CssProjectStructure="" CssIteration="" Timeout="0" WorkItemIds="" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010" Description="" CredentialUserName="" CredentialPassword="" PreAuthenticate="True" Proxy="default" StopOnError="False" RecordedResultFile="" ResultsLocale="">
 <Items>
 <Request Method="GET" Guid="eddeceec-2eda-4711-ba50-f0560085f2ba" Version="1.1" Url="http://aqui-vai-minha-url.scm.azurewebsites.net/api/continuouswebjobs/meu-job-continuo/" ThinkTime="0" Timeout="300" ParseDependentRequests="True" FollowRedirects="True" RecordResult="True" Cache="False" ResponseTimeGoal="0" Encoding="utf-8" ExpectedHttpStatusCode="0" ExpectedResponseUrl="" ReportingName="" IgnoreHttpStatusCode="False">
 <Headers>
 <Header Name="Authorization" Value="Basic AQUI-VAI-O-MEU-HASH-DE-100-CARACTERES" />
 </Headers>
 </Request>
 </Items>
 <ValidationRules>
 <ValidationRule Classname="Microsoft.VisualStudio.TestTools.WebTesting.Rules.ValidationRuleFindText, Microsoft.VisualStudio.QualityTools.WebTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" DisplayName="Find Text" Description="Verifies the existence of the specified text in the response." Level="High" ExectuionOrder="BeforeDependents">
 <RuleParameters>
 <RuleParameter Name="FindText" Value="&quot;status&quot;:&quot;success|running&quot;" />
 <RuleParameter Name="IgnoreCase" Value="True" />
 <RuleParameter Name="UseRegularExpression" Value="True" />
 <RuleParameter Name="PassIfTextFound" Value="True" />
 </RuleParameters>
 </ValidationRule>
 </ValidationRules>
</WebTest>

 

Com o template pronto basta voltar ao Portal Azure > Application Insights > App Insights Instance > Availabitity

Clique em Add test

E é aí que entra a diferença! O teste default é um ping test:

Mas o que iremos fazer é um multi-step test através do web test definition que criamos no VS (ou diretamente no XML):

Não iremos entrar em detalhes aqui mas as configurações disponibilizadas para o teste são bem bacanas, como definição de alertas, testes regionalizados, frequencia de testes, entre outros.

 

Enjoy!

Finalizadas as configurações, é só correr pro abraço e acompanhar seus webjobs – pela interface, alertas ou APP no seu smartphone!

 

E por último, e não menos importante – voce consegue acompanhar muito mais do que um “failed/ succees” e gerar indicadores de disponibilidade, mas também o logs das exceptions (failed tests) e fazer um trace das exceptions encontradas clicando nos indicadores em vermelho no gráfico e navegando pela interface do Azure Application Insights>

 

Esse Azure Application Insights é foda ou não é?

Espero que tenham gostado e até o próximo post!

 

Este post reflete apenas a opinião do autor sobre o assunto, e não fornece garantias ou responsabilidade sobre qualquer problema decorrente de sua utilização.

Deixe uma resposta