sábado, 17 de diciembre de 2022

Crear alertas de un servicio publicado monitorizado con application insights

 

A través de un test y seguimiento de un servicio publicado, podemos generar alertas,  por ejemplo cuando este, llegue a un umbral de desaparición configurado.

Previamente, tendremos que tener el servicio monitorizado siguiendos los pasos aquí detallados:

HybridCPD: Test de disponibilidad sobre servicio publicado con Application insights y Functions app


A continuación, yendo al test de monitorización creado, podemos configurar una alerta:



Dentro de esa opción, podremos configurar tanto la configuración del umbral de alerta, como la consideración de la alerta tras X intentos fallidos tras X segundos, por ejemplo y por supuesto, el trigger, la acción que quieres que se realice al llegar al umbral del kpi establecido.




















Realizar seguimiento de Sla de servicio publicado y monitorizado con Azure applications insights

 

A continuación, crearemos un seguimiento del  acuerdo de continuidad de servicios de un servicio publicado.

Para ellos, nos apoyaremos en un servicios monitorizado con Applications Insights y Function App a través de TrackAvalilability().

HybridCPD: Test de disponibilidad sobre servicio publicado con Application insights y Functions app

Para poner esto en marcha, tendremos que ir nuestro applications insights y crear un workbook a raiz de la plantilla "Downtime & Outages"




Solo con pinchar en la plantilla, ya tenemos la información disponible:



Allí podremos incluso cambiar los parámetros de seguimiento y los umbrales, kpis y demás que queremos monitorizar:




Test de disponibilidad sobre servicio publicado con Application insights y Functions app

 Hola, 

En esta entrada, os explicaré como crear con Azure Functions, un test de disponibilidad de una URL y/o servicio publicado. El servicio no ha estar publicado en Azure.

En primer lugar, crearemos un Function App, según veis en la captura siguiente:


En la ventana siguiente, Hosting, podremos crear el almacenamiento en el que se apoyará.

Y lo más importante, en monitoring tenéis que crear un Application Insights con el nombre de vuestro function.

A continuación, podréis crearlo.

El siguiente paso, será ir a ir a Functions en el menú de la izquierda y crear uno nuevo:


En la creación, elegiremos una plantilla del tipo "Timer trigger":


Una vez creado, vea a App Service Editor en las opciones de desarrollo, dentro del Function creado:



Allí has de crear y modificar los siguientes archivos:

En TimerTrigger1, botón derecho crear function.proj con el siguiente contenido:

<Project Sdk="Microsoft.NET.Sdk"> 

    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>




Ahora crear el archivo RunAvailabilityTest.csx con el contenido siguiente (Cambiando www.google.com por la url a  monitorizar:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.google.com/"); 
    } 
}

Y ahora, reemplaza el contenido de run.csx por el siguiente contenido, indicando en REGION_NAME la región desde donde quieres que se realice el sondeo a la url.


#load "runAvailabilityTest.csx" 


using System; 


using System.Diagnostics; 


using Microsoft.ApplicationInsights; 


using Microsoft.ApplicationInsights.Channel; 


using Microsoft.ApplicationInsights.DataContracts; 


using Microsoft.ApplicationInsights.Extensibility; 


private static TelemetryClient telemetryClient; 


public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 


    if (telemetryClient == null) 

    { 

        // Initializing a telemetry configuration for Application Insights based on connection string 


        var telemetryConfiguration = new TelemetryConfiguration(); 

        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 

        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 

        telemetryClient = new TelemetryClient(telemetryConfiguration); 

    } 


    string testName = executionContext.FunctionName; 

    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 

    var availability = new AvailabilityTelemetry 

    { 

        Name = testName, 


        RunLocation = location, 


        Success = false, 

    }; 


    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 

    availability.Context.Operation.Id = Activity.Current.RootId; 

    var stopwatch = new Stopwatch(); 

    stopwatch.Start(); 


    try 

    { 

        using (var activity = new Activity("AvailabilityContext")) 

        { 

            activity.Start(); 

            availability.Id = Activity.Current.SpanId.ToString(); 

            // Run business logic 

            await RunAvailabilityTestAsync(log); 

        } 

        availability.Success = true; 

    } 


    catch (Exception ex) 

    { 

        availability.Message = ex.Message; 

        throw; 

    } 


    finally 

    { 

        stopwatch.Stop(); 

        availability.Duration = stopwatch.Elapsed; 

        availability.Timestamp = DateTimeOffset.UtcNow; 

        telemetryClient.TrackAvailability(availability); 

        telemetryClient.Flush(); 

    } 

}


Ahora podrás ir a la opción Availability del application insights creado y monitorizar la disponibilidad del servicio:






jueves, 8 de diciembre de 2022

ChatGPT -Creación de scripts powershell-

 Pues me acabo de quedar de piedra. 

He pedido a ChatGPT "Make me a powershell script to configure a server as domain controller.

y aquí está su respuesta:






miércoles, 7 de diciembre de 2022

Automatizar Backup a raíz de etiqueta forzada en recursos

 

Hola, 

En el presente artículo voy a explicaros como forzar el etiquetado de recursos y a través de esta etiqueta y su valor, incluir por ejemplo una VM en un Recovery Service.

Esta configuración nos fuerzar a posicionarnos en cuanto a si queremos tener backup o no de las máquinas virtuales.

Forzar etiqueta Backup en recursos

Vamos a trabajar con una política pre estrablecida con nombre "Require a tag on resources"



Al hacer click sobre la política, podremos desplegarla a través de la opción "Assign"

Ahí tendremos que elegir el "scope" o sea a qué suscripción y posible grupo de recursos se va a aplicar.Podremos configurar una excepción y poner nombre a la asignación de forma que sea más descriptiva que el nombre genérico inicial.


En parámetros, podremos crear la etiqueta que vamos a forzar


En la siguiente opción, "Remediation" podríamos por ejemplo forzar a que todo recursos sin etiqueta, reciba una etiqueta "Backup" con valor "No", pero yo en mi caso no voy a remediarlo para que la crear un recurso, este muestre un error si no tiene la etiqueta Backup con un valor.

Configuraremos entonces un mensaje en la opción "Non-compliance messages" y crearemos la asignación de la política.

Test

Al crear una VM, si no tenemos la etiqueta en cuestión, nos aparecerá este error.



Hasta que en mi caso, he creado la etiqueta Backup con valor No.



Posteriormente, tras etiquetar correctamente la VM, ya me deja crearla.



Configuración de Backup tras aparición de etiqueta en recurso


Ahora configuraremos la inclusión automática de máquinas virtuales en un recovery vault a partir de la aparición de valor "Si" en la etiqueta Backup.

Esta vez y por cambiar la forma de asignación, nos iremos a la opción "Assignments" en las políticas de nuestro portal de Azure.



Aquí buscaremos la política que vamos a utilizar.  Podéis verla a continuación


Configuraremos también el scope al que aplicará la asignación

En los parámetros, configuraremos el nombre de la etiqueta y el valor que estaremos esperando para considerar "compliant" al recurso. en este caso será Tag name "Backup" Value "si"



Configuraremos también la remediación, que no es otra que incluir al recurso en el recovery vault y política que hemos indicado en los parámetros. 


Con esto ya tendremos configurada la respuesta que queríamos a nuestra etiqueta.

Test

Comprobamos que nuestra VM aparece como "Non-compliant" ya que dispone de la etiqueta pero no del valor requerido.


 
Nos vamos a buscar la VM con etiqueta "Backup" = "No" y cambiamos su valor a "Si"


Pasados unos segundos, vemos como se ha creado una remediación, ya que a máquinas con valor "Si" la remediación indica que ha de incluirse en el recovery vault.


La máquina ya aparece en el Vault de backup



Y la VM ya aparece como "Compliant".


domingo, 4 de diciembre de 2022

Pasar de 99,9% a 99,95% o 99,99% en Azure Compute es casi gratis y está en tu mano.

 

Pues sí, contar con una disponibilidad del 99,9%, 99,95% o 99,99%,  es la diferencia entre tener una VM en Azure -con cierta calidad-, ubicar dos VMS de calidad media en grupos de disponibilidad o ubicar esas mismas dos máquinas, en dos zonas de la misma región.


99,9%. 

Este es la disponibilidad garantizada que obtienes si montas en Azure una VM con SSD Premium o Ultra disk. 

Cabe tener en cuenta, que esta cifra no incluye paradas planeadas de actualización y mantenimiento de Microsoft y paradas previsibles por parte del administrador a la hora de actualizar y reiniciar la máquina. Así que podemos decir que todo servicio que corre en una sola VM con SSD Premium en Azure, además de los hasta 43 minutos posibles por SLA, va a tener bastante más tiempo de indisponibilidad del servicio que ese 99,9%.


99,95%

Pongamos el ejemplo de dos controladores de dominio con rol además de DNS. Estará garantizado que estos servidores funcionen un 99,95% del tiempo, o lo que es igual, de antemano has de contar que el servicio que los servicios de Active Directory y DNS podrán no funcionar durante 21 minutos cada mes, si las dos máquinas virtuales, están colocadas en el mismo conjunto de disponibilidad y diferente dominio de error.

Cabe destacar también que en esta configuración y al contar con dos VMS, estas podrán reiniciarse de forma ordenada, sin que caiga els servicio. No como en la configuración anterior.

Grupos de disponibilidad y dominios de error.

Los conjuntos de disponibilidad, vienen a indicar a Microsoft que durante sus actualizaciones y problemas técnicos, estas dos máquinas virtuales no han de reiniciarse o caer por estar en un mismo "bastidor" o "pasillo". De no ubicar estos DCs  del ejemplo, en el mismo conjunto de disponibilidad y si además, las máquinas se crearon a la vez, hay grandes probabilidades que estén conviviendo incluso en el mismo host.

Vale la pena que leáis el artículo siguiente, porque en el caso de tener más de tres servidores en un mismo servicio, vas a tener que "jugar" también con los dominios de error.

Más info.: Información general sobre los conjuntos de disponibilidad - Azure Virtual Machines | Microsoft Learn

Grupo de disponibilidad: VMS ubicadas en grupos de hosts que no se reiniciarán al mismo tiempo durante actualizaciones. 

Dominio de error: VMs ubicadas en conjuntos de bastidores que no están alimentados ni cuentan con conexión a red compartida, por lo que seguirán funcionando a pesar de caídas de electrónica de red y alimentación conjunta, pongamos que si cada armario o pasillo, comparte electricidad y red, estas máquinas estarán en dos bastidores o dos pasillos diferentes.


99,99%

Esta es la cifra de disponibilidad que cuenta el servicio si ubicamos dos VMs en dos zonas diferentes de la misma región, eso si, siempre que tengamos el servicio bien diseñado, porque si ubicamos dos VMS en dos Zonas, pero no tenemos VPN y una IP pública multi zona, realmente no tendremos nada :(.

En comparación con la disponibilidad anterior, estamos ubicando dos VMS en dos datacenters separados un mínimo de 300 millas, no penalizando prácticamente en nada la latencia y solo teniendo un incremento en coste por el dato saliente.

Impacto del dato saliente entre zonas

El precio del Gb. entre zonas es de 0,010€ y tenemos que considerar lo siguiente:

1. No tenemos VPN del tipo VPNGTWXAZ, la cual redundan entre zona.

2. Según lo anterior, tendremos cargo de tráfico entre zonas, por cada búsqueda de la máquina no asociada a la zona, donde tenemos una VPN básica o VPNGTWX normal.

3. Tráfico saliente de cada VM hacia la otra.

4. No tendremos cargo de tráfico hacia el Recovery Vault al ser este un recurso multizona.

 Contar con una VPNGTWX del tipo que termina su nombr en AZ, es un fallo bastante habitual. El precio atractivo de estas VPN frente a las multi zona -las terminadas en AZ- hace que el día que falle la zona a la que está asociada la VPN, no tengamos acceso al DC que se mantiene funcionando en la zona lejana. No olvidéis, como ya he dicho anteriormente, que la IP pública asociada al VPN Gateway también ha de ser multi zona.



Planificación del mantenimiento y el tiempo de inactividad - Training | Microsoft Learn

Notas:

- Puedes provocar que la VM se reubique en otro Host, realizando un Redeploy de la misma.

- No puedes ubicar una VM en un conjunto de disponibilidad, una vez creada. Para ubicarla en uno, has de recuperar la VM de un Backup y con ello, crear una VM nueva.

- Me parece mejor opción, mejor precio en conjunto y más segura la opción que nos ofrece 99,95% al contar con menos puntos posible de fallo.