ContainerAppSystemLogs_CL dropped 99.7% after silent platform update - ContainerAppController lost job tracking

Alvaro Flores 20 Puntos de reputación
2026-05-20T17:07:01.0966667+00:00

Environment: rmsa-container-app-entorno | East US | Resource Group: Analitica

ISSUE:

On May 13, 2026 between 13:15–14:00 UTC, ContainerAppSystemLogs_CL dropped

from ~100,000 logs/day to ~336/day and never recovered.

FORENSIC EVIDENCE:

  • May 1–12: ~100k SystemLogs/day, ~100 jobs tracked normally, ReplicaName_s populated in ~67% of records
  • May 13 12:00–13:15 UTC: all jobs visible normally in SystemLogs
  • May 13 13:15–14:00 UTC: jobs disappeared one by one over ~45 minutes. 45-minute data gap in logs confirms component crash or restart.
  • May 13 14:00 UTC onward: only 2 jobs emit SystemLogs (recomendador-v2 and recomendador-v2-dev), which were the only jobs with active pods at the exact moment of the crash.
  • All other ~100 jobs continue executing normally (confirmed via ContainerAppConsoleLogs_CL) but are completely invisible to the ContainerAppController.
  • Forcing manual execution via "az containerapp job start" does NOT
    restore tracking. Job ran successfully but produced zero SystemLogs.

WHAT WAS RULED OUT:

  • Not a metadata enrichment issue
  • Not MDSD or Log Analytics ingestion problem
  • Not customer configuration
  • No ARM changes, no environment recreation, no customer-side changes on May 13
  • ContainerAppConsoleLogs_CL unaffected in volume

ROOT CAUSE HYPOTHESIS:

ContainerAppController restarted silently (likely a platform update) at

~13:15 UTC on May 13. On restart, it only re-registered jobs that had

active pods at that moment. All other ~100 jobs lost tracking permanently

and no longer emit SystemLogs despite running correctly.

REQUEST:

  1. Identify what platform component restarted in this environment between 13:15–14:00 UTC on May 13, 2026.
  2. Restore full job tracking in the ContainerAppController without requiring environment recreation.
Azure Container Apps
Azure Container Apps

Un servicio de Azure que proporciona una plataforma de contenedor sin servidor de uso general.


Respuesta aceptada por el autor de la pregunta
Rakesh Mishra 11,510 Puntos de reputación Personal externo de Microsoft Moderador
2026-05-20T17:56:13.3433333+00:00

Oye Álvaro, solo los dos trabajos con pods activos en el momento de ese reinicio seguían registrados, por eso ves los SystemLogs solo de esos dos y de ninguno de los otros, aunque sigan funcionando (como confirman tus ConsoleLogs).

Esto es lo que puedes probar:

  1. Confirma qué componente realmente se ha enrollado
    • Consulta el Registro de Actividad de Azure para tu recurso de entorno gestionado (tipo "microsoft.app/managedEnvironments") en el RG "Analitica" alrededor de las 2026-05-13T13:00–14:00 UTC. Busca operaciones como "Reiniciar Entorno", "Actualizar Entorno Gestionado" o cualquier Microsoft.App que muestre un reinicio del mando.
    • También consulta la tabla de ContainerAppSystemLogs_CL durante el mismo periodo de tiempo para ver si algún mensaje a nivel de sistema indica que un proceso Dapr/Keda/Envoy o controlador se está reiniciando:
         
           ContainerAppSystemLogs_CL
           
           | where EnvironmentName_s == "rmsa-container-app-entorno"
            
           | where TimeGenerated between (datetime(2026-05-13T13:00:00Z) .. datetime(2026-05-13T14:00:00Z))
            
           | project TimeGenerated, EventSource, ComponentName, Log_s
         
      
  2. Forzar al controlador a volver a registrar todos los trabajos sin recrear el entorno
    1. Activa una actualización no-op en el entorno para forzar una actualización completa de su plano de control. Por ejemplo:
            az containerapp env update \
            --name rmsa-container-app-entorno \
            --resource-group Analitica \
            --tags forceRefresh=$(date +%s)
      
    2. Alternativamente, sube la revisión de cada trabajo (lo que efectivamente la sincroniza de nuevo con el controlador):
            az containerapp job update \
            --name <jobName> \
            --resource-group Analitica \
            --environment rmsa-container-app-entorno
      
        After doing either of these, give it ~5–10 minutes and then re-query ContainerAppSystemLogs_CL for your job names. You should see SystemLogs flowing again for all of them.
      

Si eso no restaura el seguimiento, por favor comparte la información siguiente en mensajes privados.

  • ¿Alguna entrada en el Registro de Actividad para el entorno gestionado alrededor de las 13:15 UTC?
  • Resultados de la consulta ContainerAppSystemLogs_CL anterior (especialmente cualquier mensaje de "reinicio" o "inicialización").
  • Confirma que has probado tanto el enfoque de actualización ambiental como la actualización por trabajo y si has cambiado la aguja.

¡Espero que esto ayude a recuperar vuestros trabajos en el mando! Avísame qué encuentras en el Registro de Actividad y en tu consulta de SystemLogs, y podemos profundizar si es necesario.

Referencias

  1. Login de aplicaciones en Azure Container Apps (log del sistema)
  2. Monitorizar los logs en Azure Container Apps con Log Analytics
  3. Referencia de la tabla ContainerAppSystemLogs
  4. Columnas ContainerAppSystemLogs
  5. Notas de lanzamiento de la extensión Azure Container Apps

Nota: Este contenido fue redactado con la ayuda de un sistema de IA.

¿Le resultó útil esta respuesta?

2 personas encontraron esta respuesta útil.
0 comentarios No hay comentarios

1 respuesta adicional

Ordenar por: Lo más útil
  1. Alvaro Flores 20 Puntos de reputación
    2026-05-20T18:54:10.5+00:00

    Todo se resolvio,

    muchas gracias.

    ¿Le resultó útil esta respuesta?

    1 persona encontró esta respuesta útil.

Su respuesta

Las respuestas pueden ser marcadas como Respuestas aceptadas por el autor de la pregunta, lo que indica a los usuarios que la respuesta resolvió su problema.