Script to add an alert to an Azure App Service using Powershell

With this script, you can add an alert about the number of HTTP errors to an Azure App Service.

The same script could be used to add any kind of alert to any kind of Azure Resource.

---------------------------------------------------

Create a Logic App to increase the number of instances in one App Service Plan

The purpose of this procedure is to increase the number instances of one WebApp in an automatic way, triggering from one specific http request. For that, one pre-requisite is to have Application Insights enabled for that WebApp.

First, we need to get the App Service Plan configuration in json format. To do that, we can do a REST API call to retrieve the json.

1. Generate the App Service Plan management URL:

     a. In the Azure portal, we navigate to the App Service Plan and copy the URL.

     b. Modify the URL as the example:

https://portal.azure.com/dafd**ail.onmicrosoft.com/resource/subscriptions/d9ec***a286c474d612/resourceGroups/ScaleOut_Test/providers/Microsoft.Web/serverFarms/ ASP-ScaleOut***/webHostingPlan

https://management.azure.com/subscriptions/ d9ec*****a286c474d612/resourceGroups/ScaleOut_Test/providers/Microsoft.Web/serverFarms/ASP-ScaleOut***?api-version=2019-08-01

2. We need to generate a bearer to authenticate. 

     a. An easy way is to use this site: 

https://docs.microsoft.com/en-us/rest/api/resources/tenants/list

     b. Click on TRY IT and authenticate with some credentials valid in the subscription, and you will get a temporary valid token.

3. Now we can use the App Service Plan management URL and the token to retrieve the json. We are going to use the tool Postman:

The next step is to get the information for the API Access of the Application Insights. We got this information in the Azure Portal. The information we need is the Application ID and one valid API Key.

To authenticate the REST API request we will launch to modify the App Service Plan, we are going to use an AAD APP, and we assign Owner permissions to this APP.

Now we can create the Logic App:

1. In the Azure Portal, go to the Logic Apps section and add a new Logic App.

2. The Logic App first trigger will be based in Recurrence:

  

3. Add and configure a new one step of type Application Insights - Run Analytics Query:

     a. Configure the Application Insights connection with the API Access information

     b. Configure the query we want to execute to see if the request has been registered in the WebApp:

4. Add and configure a new one step of type Control – For Each

     a. Add a Dynamic Content of “Value”:

     b. Add an action of type Control – Condition:

     c. Add a Dynamic Content of “Content_”

     d. And configure the condition as count is greater than or equal to 1

5. In the “If true”  column, add a new HTTP action:

     Configure the HTTP request as the example:

6. In the “If true”  column, add a new SMTP – Send Email (V3) action:

     a. Create an SMTP connection, with your SMTP server/user:

     b. Configure the outgoing email with the parameters you prefer, for example:

7. Finally, save the new Logic App

And if you want to verify if the change in the number of instances has been successful, check in the Web App, the sections Scale Out (App Service Plan) and Process Explorer:

Ping to a specific port

Many times is necessary to check if a socket replies (a socket is the combination of a host and a port).
At least by my side, the most common way to do that is with the command telnet.
You only need to open a command prompt in Windows and type

telnet <ip address or hostname> <port>

But there are some problems with telnet:

• Since Windows 7/2008, it is not installed by default, and maybe you have not rights to install it.
• Each time you launch the command, the connection usually get stuck (it depends of the service we are testing) and you have to wait until the remote host cuts the connection.

There are a lot of third party software that we can use in Windows (netcat, nmap, etc). But in some cases you cannot use third party software in your computer because the security policy of your company forbids it.

Fortunately in PowerShell we can use the cmdlet Test-NetConnection for make some diagnostics for a network connection. It is a kind of PowerShell swiss army knife for networking, because it can replace the commands ping, telnet, and traceroute, and provides more info that these ones.

But in this case we can use this command (or his alias TNC) to check if a TCP port is open in a remote host. The syntax would be:

Test-NetConnection <ip address or hostname> -port <port>

The result of the test will be like this:

                              ComputerName           : palou-it.blogspot.com
                              RemoteAddress          : 172.217.20.65
                              RemotePort             : 80
                              InterfaceAlias         : Ethernet 2
                              SourceAddress          : 192.168.1.25
                              PingSucceeded          : False
                              PingReplyDetails (RTT) : 0 ms
                              TcpTestSucceeded       : True

But really, this is not a ping, because it only makes a request, and sometimes we need a continuous connection attempt, per example when we are monitoring some remote service, and we have to launch the command each time we want to check the connectivity to the socket.

Well, why don't we use PowerShell to create a little tool to launch a ping to a specific port?

With only 4 lines of test, we have a tool that will ask us for the remote host and the remote port, and it will be probing the connection until we stop it. 

$destination_host = Read-host -prompt 'Input destination host'

$destination_port = Read-host -prompt 'Input destination port'

do

{

start-sleep -s 2

tnc $destination_host -port $destination_port | fl remoteaddress,RemotePort,tcptestsucceeded

} while ($destination_host=$destination_host)

Copy and paste the script in a notepad and save it as ping-port.ps1.
Then execute it in PowerShell and you have your new tool to check continuously a port in a remote host (to stop it, simply press Control+C).

Capturar trazas de Fiddler de APPS en Android 7 (Nougat)

Si estamos trabajando Android versión 7 (Nougat) o superior, algunas APPS no funcionarán correctamente si intentamos capturar trazas con Fiddler, o no podremos capturar dichas trazas.
Esto es debido a un cambio implementado por el Equipo de Desarrollo de Android, que decidió que por defecto la validación de certificados HTTPS para aplicaciones con API Level 24 o posterior ignorarán todos los certificados raiz instalados por el usuario en el dispositivo. Más información en https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html

Pero no hay que desesperarse, ya que hay un workaround para poder capturar las trazas con Fiddler, el único problema es que hay que disponer del APK correspondiente a la aplicación, pero para ello tenemos la posibilidad de conseguirlo en alguna de las webs-repositorio de APPS, por ejemplo https://apkpure.com/

Aparte del APK, necesitamos tener instalado en el ordenador las siguientes herramientas para seguir este procedimiento:

• Descargar la herramienta https://ibotpeaches.github.io/Apktool/ y seguir las instrucciones de instalación https://ibotpeaches.github.io/Apktool/install/
• Descargar e instalar el Java Development Kit http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
•  Es necesaria la herramienta zipaling, por lo que se puede conseguir mediante la instalación de https://developer.android.com/studio/index.html

Una vez que tenemos todo lo necesario, nos ponemos manos a la obra.

• Desempaquetar el APK. 

• Para ello abriremos una ventana de comandos como administrador en el directorio donde tengamos el APK
• Lanzamos el siguiente comando, modificando el nombre del paquete

apktool decode app-store-release-6.3.0.apk

•  Realizar modificaciones en el paquete.

• Creamos un fichero llamado network_security_config.xml que estará en el directorio %nombre de la app%\res\xml
• Editamos el fichero xml añadiendo estas líneas

<?xml version="1.0"?> <network-security-config><base-config><trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system"/> <!-- Additionally trust user added CAs --> <certificates src="user"/></trust-anchors></base-config></network-security-config>

• Modificamos el fichero %nombre de la app%\AndroidManifest.xml añadiendo en la sección "application" la siguiente línea

android:networkSecurityConfig="@xml/network_security_config"

• Empaquetar el paquete modificado.

• Desde la ventana de comandos, entraremos en el directorio donde se ha desempaquetado anteriormente %nombre de la app%
• Lanzaremos el siguiente comando cambiando el nombre por uno de nuestra elección que nos permita saber que es el APK modificado

apktool build -o RM_PRO_unsafe.apk

•  Crear el certificado con el que firmaremos el APK.

• Lanzaremos el siguiente comando (cambiando los nombres a nuestra elección), desde la carpeta donde esté instalado el Java Development Kit, en mi caso es C:\Program Files\Java\jdk1.8.0_151\bin. La ventana de comandos la abriremos como administrador.

C:\Program Files\Java\jdk1.8.0_151\bin>keytool -keystore RM_PRO_Unsafe_fix.jks -genkey -keyalg RSA -keysize 2048 -validity 365 -alias RM_PRO_Unsafe_fix

• Le asignaremos una contraseña al certificado, y rellenaremos los datos de generación del certificado según nos los vaya solicitando.

•  Fimar el APK
• Copiamos el APK modificado a la carpeta donde hemos lanzado el comando anterior.
• Lanzamos el siguiente comando haciendo referencia al certificado que hemos creado en el punto anterior y al APK modificado. Nos pedirá la contraseña del certificado.

jarsigner -keystore RM_PRO_unsafe_fix.jks RM_PRO_unsafe_fix.apk RM_PRO_unsafe_fix

•  Re-empaquetar el APK modificado y firmado
• Desde la ventana de comandos que teníamos abierta en el paso anterior, lanzamos el siguiente comando (la ruta de la herramienta zipalign puede cambiar dependiendo de la versión de las herramientas de desarrollo de Android que tengamos instaladas en el ordenador), modificando el nombre de salida para poder distinguirlo del APK original.

"C:\Program Files (x86)\Android\android-sdk\build-tools\25.0.3\zipalign" -f -v 4 RM_PRO_unsafe_fix.apk RM_PRO_unsafe_fix-signed.apk

 

Ya tenemos el APK de nuestra aplicación modificado para capturar trazas con Fiddler. Solo hay que instalarlo en el dispositivo Android, recordando que hay que activar la opción de seguridad que permite instalar aplicaciones desde fuentes desconocidas.

Monitorizar App Services en el Portal de Azure

Recientemente han vuelto a modificar en el Portal Ibiza de Azure las opciones para monitorizar las webapps (App Services), por lo que voy a tratar de explicar un poco las opciones que tenemos para monitorizar nuestra página web alojada en Microsoft Azure. Estas herramientas nos ayudarán a determinar el rendimiento y posibles problemas que esté sufriendo nuestro sistema.

Ahora hay que entrar desde “Diagnose and Solve Problems”.

Nada más abrir esa opción podemos ver una gráfica con el status de las últimas 24h  y podemos intercambiar entre Availability, Requests y Performance.

También hay una zona con Herramientas útiles para diagnosticar el estado del WebApp. Voy a intentar explicar un poco cada una de ellas:

• Metrics per instance (Apps):

En esta sección podemos revisar múltiples contadores de rendimiento (.NET Process, ASP.NET, .NET CLR, TCPv4 y TCPv6) y en distintos intervalos de tiempo, viendo las mismas en todas las instancias a la vez o indicando manualmente que instancia queremos comprobar.

También podemos ver las métricas del site, viendo las mismas en todas las instancias a la vez o indicando manualmente que instancia queremos monitorizar.

• Metrics per instance (App Service Plan)

Aquí podemos ver las métricas de las instancias del Service Plan, viendo todas las APPS que comparten dichas instancias al estar en el mismo Service Plan, permitiendo ver también las métricas de los slots de staging. Podemos filtrar por instancia, intervalo de tiempo y Sites.

• Live HTTP Traffic

Como su nombre indica, podemos visualizar el tráfico recibido por el WebApp en tiempo real, viendo las peticiones correctas, así como los errores de servidor (5xx) y las peticiones erróneas (4xx)

• Application Events

Es un Visor de Eventos del IIS donde está alojado el WebApp.

• Failed Requests Tracing Logs (FREB)

Esta herramienta realiza un seguimiento basado en una solicitud y produce un archivo de registro (en formato .xml) que muestra eventos y notificaciones de los diversos módulos que trabajaron en la solicitud durante su ciclo de vida.

Se puede filtrar por la URL, por el tipo de petición, por la hora y fecha, por el código de estatus…

• Diagnostics as a Service

Permite lanzar una solicitud para recopilar información en forma de log y analizada en formato HTML del Visor de Eventos, de los logs HTTP y hacer un Memory Dump (utilizar el Memory Dump con cuidado, ya que puede provocar una caída del servicio) de la instancia.

• Mitigate

Permite crear reglas de auto-reciclado del WebApp basado en el número de peticiones en un determinado intervalo de tiempo.

• Advanced Application Restart

El reinicio avanzado de aplicación le permite reiniciar instancias individuales de la aplicación y reiniciar de forma inteligente varias instancias. El temporizador de reinicio le permite especificar el intervalo de tiempo en segundos que se usa al reiniciar determinadas instancias de la aplicación y reducir el efecto de los arranques en frío.