Migrando Azure Application Insights URL Ping Tests a Standard Tests sin perder alertas

Microsoft retirará los URL Ping Tests clásicos de Application Insights el 30 de septiembre de 2026. Para quienes todavía tienen este tipo de disponibilidad configurada, no basta con crear un Standard Test nuevo y asumir que Azure se encargará del resto.

En una migración real reciente utilizamos Codex con GPT-5.6 Terra y reasoning effort medium, Azure CLI, Azure MCP y Azure Resource Manager (ARM) para auditar, migrar y validar un conjunto de availability tests de producción sin interrumpir el monitoreo existente.

La estrategia fue deliberadamente conservadora:

descubrir primero, reproducir la configuración, validar en paralelo, mover las alertas y solamente entonces apagar los tests antiguos.

Ese orden terminó siendo la parte más importante de toda la migración.

Microsoft confirma tres puntos especialmente relevantes:

  • Los URL Ping Tests se retiran el 30 de septiembre de 2026.
  • Los Standard Tests generan cargos cuando están habilitados.
  • Las alert rules no se migran automáticamente al crear el nuevo test.

El problema

El entorno tenía varios recursos Microsoft.Insights/webtests antiguos con:

properties.Kind = ping

Una auditoría inicial encontró:

7 URL Ping Tests clásicos
├── 4 habilitados
└── 3 deshabilitados

También existían reglas de Azure Monitor asociadas a esos tests.

En lugar de migrarlo todo ciegamente, se decidió migrar exclusivamente los cuatro tests activos.

Esto tenía dos ventajas:

  1. reducir el riesgo;
  2. evitar crear Standard Tests innecesarios que después generarían ejecuciones y costo.

La sesión siguió precisamente ese modelo: primero se descubrieron los siete tests y sus alertas, se generó un reporte de migración y posteriormente se limitó el cambio a cuatro tests activos.

Una diferencia operativa importante: los Standard Tests sí tienen costo

Los URL Ping Tests clásicos eran gratuitos. Los Standard Tests se cobran por ejecución programada cuando están habilitados, por lo que la migración también cambia el modelo económico del monitoreo.

El costo crece principalmente con tres variables:

número de tests
×
número de ubicaciones
×
frecuencia de ejecución

Una aproximación útil para estimar el volumen mensual es:

ejecuciones/mes ≈ tests × locations × (43,200 minutos / intervalo_en_minutos)

Por ejemplo, cuatro tests ejecutándose desde cinco ubicaciones cada cinco minutos producirían aproximadamente:

4 × 5 × (43,200 / 5)
= 172,800 ejecuciones programadas / mes

Con una tarifa de referencia de US$0.0005 por ejecución, eso sería del orden de:

172,800 × $0.0005 ≈ $86.40 / mes

Ese valor es solamente un ejemplo para entender la escala. La tarifa aplicable puede variar por región, moneda y cambios de pricing, por lo que debe comprobarse siempre en la página oficial de precios de Azure Monitor antes de estimar un presupuesto.

También hay que separar este costo del resto de Azure Monitor: las reglas de alerta y determinadas notificaciones pueden facturarse aparte.

Esta diferencia económica refuerza dos decisiones que ya eran correctas desde el punto de vista técnico:

  • no migrar automáticamente tests legacy que estaban deshabilitados;
  • crear los Standard Tests inicialmente con Enabled=false y habilitarlos solamente cuando su configuración hubiera sido validada.

En otras palabras, en una migración de observabilidad el costo también forma parte del estado que debemos preservar y controlar. No basta con preguntar «¿funciona igual?»; también conviene preguntar «¿cuánto costará operar esta configuración cuando esté activa?».

1. El agente LLM y las herramientas que ejecutaron la migración

La migración fue orquestada por Codex usando GPT-5.6 Terra con reasoning effort medium.

El papel del modelo no fue sustituir las APIs de Azure ni “adivinar” el estado de la infraestructura. Su función fue coordinar un procedimiento verificable:

  1. traducir el objetivo de migración a consultas y artefactos;
  2. descubrir el estado real de Azure mediante Azure MCP;
  3. contrastar los hallazgos con Azure CLI y ARM;
  4. construir la plantilla ARM y el plan de rollback;
  5. ejecutar cambios graduales únicamente después de validar el diff;
  6. consultar telemetría y estado de alertas antes de cada siguiente paso.

Es importante distinguir entre el razonamiento del agente y la fuente de verdad:

Codex / GPT-5.6 Terra (medium)
      ↓
planificación, análisis, generación de consultas y plantillas
      ↓
Azure MCP + Azure CLI + ARM
      ↓
inventario, estado, despliegue, telemetría y alertas reales

La variante del modelo describe la sesión concreta que ejecutó esta migración, pero la reproducibilidad no depende del LLM. Depende de los comandos, la plantilla, los diffs y las verificaciones de Azure que se documentan a continuación.

El principio operativo fue simple:

LLM propone y coordina
Azure expone el estado real
ARM calcula y aplica el cambio
telemetría demuestra el resultado

2. Preparar Codex, Azure CLI y Azure MCP

Primero se autenticó Azure CLI y se comprobó el contexto activo:

az login --tenant <tenant-id> --use-device-code

az account show \
  --query "{user:user.name, tenantId:tenantId, subscription:name, subscriptionId:id, state:state}" \
  --output json

Los identificadores reales se trataron siempre como parámetros:

Subscription: <subscription-id>
Tenant:       <tenant-id>
Resource RG:  <resource-group>

Nunca es necesario incluirlos en documentación pública.

Azure MCP se agregó a Codex como servidor MCP consolidado:

codex mcp add azure -- \
  npx -y @azure/mcp@latest server start --mode consolidated

codex mcp list

Una propiedad útil de este flujo es que Azure MCP puede apoyarse en la autenticación ya establecida mediante Azure CLI.

La separación de responsabilidades quedó así:

Codex / GPT-5.6 Terra
   │
   ├── Azure MCP ─────► discovery / contexto de Azure
   │
   ├── Azure CLI ─────► comprobaciones / despliegues / consultas
   │
   └── ARM REST ──────► actualizaciones quirúrgicas de recursos

Durante la fase de discovery, Azure MCP se utilizó de forma read-only.

3. Azure MCP para descubrir los Ping Tests clásicos

En la auditoría se utilizó el router arm de Azure MCP con estos subcomandos read-only:

arm.generate_query
arm.execute_query

Primero se pidió a arm.generate_query producir una consulta de Azure Resource Graph para descubrir tests clásicos:

resources
| where type =~ 'microsoft.insights/webtests'
| where properties.Kind =~ 'ping'
| project id, name, resourceGroup, location, tags, kind, properties

Después se ejecutó mediante arm.execute_query.

La consulta devolvió resultados paginados. Por tanto, no se asumió que la primera respuesta era el inventario completo: se comprobó el skipToken y se consumieron las páginas restantes hasta completar el conjunto de recursos.

Este detalle es importante en automatizaciones agentic. Un resultado parcial puede parecer perfectamente válido si el agente no verifica explícitamente si existe continuación.

Azure MCP aportó el discovery y el contexto de recursos. Los cambios posteriores se verificaron y ejecutaron de forma determinista con Azure CLI y Azure Resource Manager.

Como comprobación independiente, también se consultó directamente la API de Web Tests mediante Azure CLI:

az rest --method get \
  --url "https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Insights/webtests?api-version=2022-06-15" \
  --output json

Y se inventariaron las alertas métricas existentes:

az rest --method get \
  --url "https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Insights/metricAlerts?api-version=2018-03-01" \
  --output json

El patrón fue deliberado:

MCP descubre
   ↓
CLI contrasta
   ↓
ARM modifica solamente después del dry run

4. Hacer un dry run antes de modificar nada

Una migración de observabilidad es especialmente peligrosa porque puede parecer exitosa mientras silenciosamente rompe las alertas.

Por eso el primer entregable no fue infraestructura.

Fue un reporte:

URL_PING_MIGRATION_REPORT.md

El reporte inventariaba, para cada test:

- estado enabled/disabled
- Application Insights asociado
- endpoint
- HTTP method
- frecuencia
- timeout
- status code esperado
- redirects
- retry
- content validation
- geographic locations
- alert rule asociada

La idea era construir primero un modelo de:

ESTADO ACTUAL
     │
     ▼
CONFIGURACIÓN EQUIVALENTE
     │
     ▼
CAMBIO PROPUESTO

antes de tocar Azure.

5. Buscar equivalencia funcional, no mejoras

Los Standard Tests tienen capacidades que los antiguos Ping Tests no tenían o no exponían de la misma forma:

  • validación TLS/SSL;
  • expiración de certificados;
  • headers personalizados;
  • distintos HTTP verbs;
  • request bodies;
  • validaciones adicionales.

Era tentador habilitar estas capacidades durante la migración.

No se hizo.

El primer objetivo fue conseguir:

Legacy Ping Test ≈ Standard Test

manteniendo la semántica existente.

Para los cuatro tests se conservaron parámetros como:

HTTP method:              GET
Follow redirects:         true
Parse dependent requests: false
Retry:                    true
Expected status:          original
Frequency:                original
Timeout:                  original
Locations:                mismas ubicaciones

También se mantuvo inicialmente:

SSLCheck = false

No porque verificar TLS sea una mala idea, sino porque una migración no es el momento ideal para cambiar simultáneamente la política de monitoreo.

Primero paridad.

Después mejoras.

La plantilla ARM conservó frecuencias, timeouts, ubicaciones, códigos esperados y reglas de validación de contenido de los tests originales.

6. Nunca copiar secretos desde el test antiguo al repositorio

Uno de los availability tests llamaba a una Azure Function utilizando una URL similar a:

https://<function-app>/api/health?code=<function-key>

Ese code es un secreto.

Una migración automatizada puede caer fácilmente en este antipatrón:

{
  "requestUrl": "https://example.azurewebsites.net/api/health?code=REAL_SECRET"
}

y terminar guardando la Function Key en Git.

La solución fue declarar el parámetro de la plantilla como:

secureString

Conceptualmente:

{
  "healthcheckFunctionKey": {
    "type": "secureString"
  }
}

Durante el deployment:

Ping Test antiguo
       │
       │ extraer key
       ▼
     memoria
       │
       │ secureString
       ▼
ARM deployment
       │
       ▼
Standard Test

El secreto nunca quedó almacenado en:

Git
migration report
ARM template
logs de documentación

En un pipeline real conviene inyectarlo desde un almacén de secretos o un mecanismo seguro de CI/CD, nunca desde Git ni documentación.

7. ARM What-If como gate antes del deployment

Antes de aplicar la plantilla se ejecutó ARM What-If.

El comando anonimizado equivalente fue:

az deployment group what-if \
  --resource-group <resource-group> \
  --name <deployment-name>-whatif \
  --template-file URL_PING_STANDARD_TESTS.template.json \
  --parameters healthcheckFunctionKey="<secret-provided-at-runtime>" \
  --result-format ResourceIdOnly \
  --output json

El resultado esperado era extremadamente específico:

+ 4 Microsoft.Insights/webtests

0 modificaciones inesperadas
0 eliminaciones

Esa condición funcionó como gate.

Si What-If hubiera mostrado cambios en Application Insights, alert rules u otros recursos, el deployment se habría detenido.

Este patrón es especialmente útil cuando un agente está generando infraestructura:

GENERATE
   ↓
WHAT-IF
   ↓
INSPECT
   ↓
APPLY

en vez de:

GENERATE
   ↓
APPLY
   ↓
😬

El What-If real confirmó exactamente cuatro nuevos Microsoft.Insights/webtests y ningún cambio sobre recursos existentes.

8. Crear primero los Standard Tests deshabilitados

El deployment se ejecutó mediante la plantilla ARM:

az deployment group create \
  --resource-group <resource-group> \
  --name <deployment-name> \
  --template-file URL_PING_STANDARD_TESTS.template.json \
  --parameters healthcheckFunctionKey="<secret-provided-at-runtime>" \
  --query "{state:properties.provisioningState,timestamp:properties.timestamp}" \
  --output json

Los tests nuevos no se crearon inmediatamente activos.

Primero:

Legacy Test       Enabled
Standard Test     Disabled

Se inspeccionaron entonces:

Kind = standard
ProvisioningState = Succeeded
Frequency = expected
Timeout = expected
Locations = expected

Solamente después:

Standard Test → Enabled

Durante este período existieron temporalmente ambos recursos.

Eso es intencional.

Además de reducir el riesgo técnico, este patrón evita generar ejecuciones —y por tanto costo— mientras el recurso todavía está siendo validado.

9. Validar telemetría antes del cutover

Una vez activos los Standard Tests, había que demostrar que realmente funcionaban.

La extensión de Application Insights de Azure CLI permitió consultar la telemetría directamente:

az extension add --name application-insights --yes --only-show-errors

az monitor app-insights query \
  --app <app-insights-name> \
  --resource-group <resource-group> \
  --analytics-query "
    availabilityResults
    | where timestamp > ago(90m)
    | where name endswith '-standard'
    | summarize
        runs=count(),
        successful=countif(success == '1'),
        failed=countif(success != '1'),
        latest=max(timestamp),
        maxDurationMs=max(duration)
      by name
    | order by name asc
  " \
  --output json

La primera muestra observada fue aproximadamente:

Test A     10 / 10 successful
Test B      9 / 9 successful
Test C      9 / 9 successful
Test D      9 / 9 successful

No se modificaron todavía los tests legacy.

La arquitectura temporal era:

             ┌── Legacy Ping Test ─────► endpoint
Application ─┤
             └── Standard Test ────────► endpoint

Ambos observaban la misma aplicación.

Esta ejecución paralela permite detectar diferencias antes de que el test nuevo se convierta en el monitor principal.

10. El detalle fácil de olvidar: las alertas

Aquí está probablemente la lección más importante de la migración.

Crear:

foo-standard

no hace que una alerta que apuntaba a:

foo-legacy

empiece mágicamente a vigilar el nuevo recurso.

Microsoft lo advierte expresamente: las alert rules no se migran automáticamente.

Por eso el cutover se hizo explícitamente.

Cada regla de disponibilidad tenía que cambiar de:

Alert Rule
    │
    ▼
Legacy Ping Test

a:

Alert Rule
    │
    ▼
Standard Test

En las reglas utilizadas había al menos dos referencias que debían quedar coherentes:

properties.criteria.webTestId
properties.scopes

Actualizar solamente criteria.webTestId produjo un error de validación de scope. La corrección fue actualizar también la entrada del Web Test dentro de properties.scopes, manteniendo sin cambios el scope del componente de Application Insights.

También se conservaron características operativas como:

Severity:           Sev1
Evaluation:         1 minute
Window:             5 minutes
Failed locations:   original threshold
Enabled:            true

La migración real actualizó ambos campos y conservó severidad, ventana, frecuencia de evaluación y umbral de localizaciones fallidas.

11. Operaciones ARM para cambios quirúrgicos

No todas las operaciones necesarias tenían un subcomando Azure CLI específico o suficientemente cómodo para esta migración.

Para esas actualizaciones se obtuvo un token con Azure CLI y se invocó ARM desde PowerShell. Esto permitió conservar el documento completo de cada recurso y modificar solamente los campos necesarios.

$token = az account get-access-token `
  --resource https://management.azure.com/ `
  --query accessToken -o tsv

$headers = @{ Authorization = "Bearer $token" }

La actualización de una alerta requería mantener coherentes dos referencias:

properties.criteria.webTestId
properties.scopes

Pseudocódigo del cambio:

$alert = Get-ArmResource <metric-alert-resource-id>
$oldTestId = $alert.properties.criteria.webTestId
$newTestId = <standard-test-resource-id>

$alert.properties.criteria.webTestId = $newTestId
$alert.properties.scopes = $alert.properties.scopes | ForEach-Object {
  if ($_ -eq $oldTestId) { $newTestId } else { $_ }
}

Put-ArmResource <metric-alert-resource-id> $alert

El patrón GET → modificar el mínimo → PUT se reutilizó para:

  • crear inicialmente los Standard Tests con Enabled=false;
  • habilitarlos tras validar su configuración;
  • deshabilitar los cuatro Ping Tests legados sin eliminarlos;
  • asociar <availability-notifications> a las cuatro alertas;
  • ejecutar y revertir el mutation test controlado.

El valor del patrón es que evita reconstruir a mano un recurso entero a partir de supuestos. Se lee el estado actual, se modifica únicamente el campo deseado y ARM vuelve a validar el documento resultante.

12. Conectar el Action Group

El siguiente componente de la cadena era el Action Group.

Conceptualmente:

Standard Test
     ↓
Alert Rule
     ↓
Action Group
     ↓
Email / Teams / Webhook / Function / etc.

En este entorno existía un Action Group de correo.

Su configuración se inspeccionó mediante ARM:

az rest --method get \
  --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Insights/actionGroups/<availability-notifications>?api-version=2023-01-01" \
  --output json

Todos sus identificadores y destinatarios reales se omiten aquí:

Action Group: <availability-notifications>

Recipients:
  <operations-email-1>
  <operations-email-2>

Después de la migración, las cuatro alertas quedaron asociadas al mismo Action Group.

Así se completaba la ruta:

Synthetic request
      ↓
Standard Test
      ↓
Location failures
      ↓
Azure Monitor Alert
      ↓
Action Group
      ↓
Email

13. Deshabilitar, no eliminar, los tests antiguos

Después de comprobar:

Standard Tests OK
        +
Alert Rules migrated
        +
Action Group connected

se deshabilitaron los Ping Tests clásicos.

No se eliminaron.

Estado final:

Legacy Ping Tests
Enabled = false

Standard Tests
Enabled = true

¿Por qué conservar temporalmente los antiguos?

Rollback.

En caso de descubrir un problema:

1. Enable legacy test
2. Restore alert webTestId
3. Restore alert scope

y el sistema puede volver rápidamente a la topología anterior.

Es un principio clásico de deployment aplicado a observabilidad:

apagar es reversible; borrar no siempre lo es.

14. ¿Cómo demostrar que la alerta realmente funciona?

Que un Standard Test responda correctamente solo demuestra media cadena.

Todavía quedaba verificar:

Standard Test
     ↓
Alert Rule
     ↓
Action Group
     ↓
Email

Esperar a que producción fallara para probarlo no era una estrategia atractiva.

Así que se realizó un mutation test controlado sobre el monitor.

El endpoint normalmente devolvía:

HTTP/1.1 200 OK

y el Standard Test esperaba:

ExpectedHttpStatusCode = 200

La prueba no modificó la aplicación ni el endpoint. Cambió temporalmente la expectativa del monitor de 200 a 418:

$test.properties.ValidationRules.ExpectedHttpStatusCode = 418
Put-ArmResource <standard-test-resource-id> $test

Ahora ocurría esto:

Aplicación devuelve 200
        ↓
Monitor espera 418
        ↓
Synthetic test = FAILED

Solo se alteró temporalmente la interpretación del monitor.

15. Comandos y consultas usados durante la prueba de alerta

Después de cambiar la expectativa, se comprobó que se habían acumulado fallos desde suficientes ubicaciones:

availabilityResults
| where timestamp > ago(15m)
| where name == '<standard-test-name>'
| summarize
    runs=count(),
    failed=countif(success != '1'),
    failedLocations=dcountif(location, success != '1'),
    latest=max(timestamp)

Los agentes de disponibilidad ejecutaron nuevamente el test desde cinco ubicaciones.

Resultado:

Location 1 → failure
Location 2 → failure
Location 3 → failure
Location 4 → failure
Location 5 → failure

El umbral configurado requería menos fallos que esos para activar la regla.

Para confirmar la instancia de alerta se consultó Azure Alerts Management:

GET https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.AlertsManagement/alerts?alertRule=<metric-alert-resource-id>&timeRange=1h&includeContext=true&api-version=2019-03-01

La respuesta esperada para una prueba exitosa contiene valores como:

monitorCondition = Fired
alertState       = New
severity         = Sev1

Eso fue exactamente lo observado, y el Action Group produjo los emails reales de prueba.

Es decir, se validó end-to-end:

HTTP endpoint
      ↓
Standard Test
      ↓
Synthetic failure
      ↓
Azure Monitor
      ↓
Alert rule
      ↓
Action Group
      ↓
Email inbox

En cuanto se confirmaron los fallos y la alerta, la expectativa se restauró inmediatamente:

$test.properties.ValidationRules.ExpectedHttpStatusCode = 200
Put-ArmResource <standard-test-resource-id> $test

La prueba real siguió exactamente ese procedimiento:

200 → 418
     ↓
5 fallos sintéticos
     ↓
alerta Fired / New / Sev1
     ↓
notificación recibida
     ↓
418 → 200

No se alteró la aplicación ni el endpoint.

16. Por qué este tipo de mutation test es tan útil

Una comprobación típica de migración podría terminar aquí:

✓ Resource exists
✓ provisioningState = Succeeded
✓ test returns green

Pero eso no prueba que te enterarás cuando falle.

Hay al menos cuatro sistemas independientes:

1. Availability Test
2. Alert Rule
3. Alert Evaluation
4. Notification Channel

El mutation test valida los cuatro.

Es la diferencia entre probar:

"el monitor parece estar configurado"

y probar:

"si esto falla a las 3 AM, alguien recibe una alerta"

17. El runbook completo

El procedimiento puede resumirse en este pipeline:

1. Authenticate Azure CLI
      ↓
2. Start/configure Azure MCP in Codex
      ↓
3. Discover legacy tests via Resource Graph
      ↓
4. Consume pagination / skipToken
      ↓
5. Cross-check inventory with Azure CLI / ARM
      ↓
6. Generate migration report
      ↓
7. Select migration scope
      ↓
8. Estimate execution volume / operating cost
      ↓
9. Build equivalent Standard Test template
      ↓
10. Protect secrets with secureString
      ↓
11. ARM What-If
      ↓
12. Create Standard Tests disabled
      ↓
13. Validate configuration
      ↓
14. Enable Standard Tests
      ↓
15. Observe successful telemetry
      ↓
16. Redirect Alert Rules
      ↓
17. Validate Action Group
      ↓
18. Disable legacy tests
      ↓
19. Force controlled synthetic failure
      ↓
20. Confirm alert instance + notification
      ↓
21. Restore monitor
      ↓
22. Keep legacy tests temporarily for rollback

Una forma útil de pensar el runbook es como una serie de gates:

DISCOVERY COMPLETE?
      ↓ yes
DIFF EXPECTED?
      ↓ yes
STANDARD TESTS HEALTHY?
      ↓ yes
ALERT REFERENCES COHERENT?
      ↓ yes
NOTIFICATION VERIFIED?
      ↓ yes
CUTOVER COMPLETE

El agente no avanzaba simplemente porque un comando anterior hubiera terminado con exit code cero. Avanzaba cuando la evidencia de Azure satisfacía el gate siguiente.

18. Qué cambiaría en una migración masiva

Para cuatro tests, la inspección individual sigue siendo manejable.

Con decenas o cientos de availability tests conviene convertir el procedimiento en un pipeline declarativo.

Por ejemplo:

DISCOVER
    ↓
NORMALIZE
    ↓
DIFF
    ↓
ESTIMATE COST
    ↓
GENERATE
    ↓
WHAT-IF
    ↓
DEPLOY DISABLED
    ↓
VERIFY
    ↓
ENABLE
    ↓
OBSERVE
    ↓
CUTOVER ALERTS
    ↓
MUTATION TEST
    ↓
DEPRECATE LEGACY

Y generar un manifiesto como:

name: availability-api-prod

source:
  kind: ping

target:
  kind: standard

validation:
  expected_status: 200
  locations: 5
  retry: true

alert:
  severity: 1
  failed_locations: 2

rollback:
  legacy_test_retained: true

Esto permitiría a un agente como Codex razonar sobre un estado declarativo en vez de improvisar operaciones individuales.

También haría posible almacenar por cada monitor:

source resource id
target resource id
normalized configuration
diff esperado
estimated execution volume / cost
deployment result
telemetry evidence
alert migration evidence
mutation-test result
rollback instructions

Así, el LLM puede ayudar a coordinar la operación, pero el sistema sigue siendo auditable sin depender de su memoria o de su razonamiento interno.

19. Seis lecciones de esta migración

1. Crear el Standard Test no termina la migración

El test es solamente un nodo dentro del sistema de monitoreo.

También existen:

alert rules
action groups
notification channels
rollback paths

2. La equivalencia debe preceder a las mejoras

No mezcles:

migración
+
nuevas políticas TLS
+
nuevos timeouts
+
nuevos endpoints
+
nuevas alertas

en un mismo cambio.

Primero consigue equivalencia funcional.

Optimiza después.

3. What-If debería ser obligatorio

Especialmente cuando un agente está produciendo infraestructura.

Un buen flujo agentic debería ser:

Agent proposes
Azure calculates diff
Human/agent evaluates
Azure applies

4. Los secretos no pertenecen al artefacto de migración

Aunque el secreto ya exista dentro del recurso legacy, eso no significa que sea aceptable copiarlo a:

JSON
Markdown
logs
Git
prompt

Extraer → usar en memoria → descartar.

5. Un monitor sin una prueba de alerta completa no está completamente validado

El estado final correcto no era únicamente:

Availability = green

Era:

Availability = green
      +
Forced failure = alert
      +
Notification = received
      +
Configuration = restored

6. El costo también es parte del diseño de observabilidad

Al pasar de URL Ping Tests gratuitos a Standard Tests cobrados por ejecución, decisiones aparentemente técnicas —como usar cinco ubicaciones en vez de una o ejecutar cada cinco minutos en vez de cada quince— tienen impacto económico directo.

Por eso una migración masiva debería incluir explícitamente un cost diff junto al configuration diff:

configuración actual
      ↓
configuración objetivo
      ↓
frecuencia × locations × tests
      ↓
ejecuciones estimadas
      ↓
costo operativo estimado

La optimización no consiste necesariamente en reducir cobertura. Consiste en hacer consciente el trade-off entre frecuencia, redundancia geográfica, tiempo de detección y costo.

20. Referencias oficiales

Conclusión

Migrar los URL Ping Tests de Application Insights a Standard Tests parece inicialmente una sustitución simple de recursos.

En realidad es una migración de una cadena de observabilidad:

Endpoint
   ↓
Synthetic Test
   ↓
Availability telemetry
   ↓
Alert Rule
   ↓
Action Group
   ↓
Operator

Si solamente migramos el primer bloque, podemos terminar con dashboards verdes y alertas rotas.

La estrategia que funcionó fue mucho más parecida a un deployment blue/green:

Legacy ──────► activo
Standard ────► construir
Standard ────► validar
Alerts ──────► mover
Standard ────► probar end-to-end
Legacy ──────► deshabilitar

Codex con GPT-5.6 Terra (medium) fue útil para planificar, correlacionar información y coordinar los pasos; Azure MCP aportó discovery y contexto; Azure CLI y ARM proporcionaron operaciones deterministas y verificables; y la telemetría y las alertas de Azure dieron la evidencia necesaria para continuar o detenerse.

Pero la herramienta más importante terminó siendo el procedimiento:

inventariar, hacer dry run, preservar equivalencia, estimar el costo operativo, validar en paralelo, mover las alertas, probar el camino de fallo y mantener rollback.

Ese patrón es aplicable mucho más allá de Application Insights.

Es, en esencia, cómo debería hacerse cualquier migración de observabilidad en producción.