Versiones e historial del esquema de configuración de la extensión de Microsoft Azure Diagnostics (WAD)

En este artículo se proporciona el historial de versiones de la extensión Azure Diagnostics para Windows (WAD) versiones de esquema enviadas como parte de Microsoft SDK de Azure.

gráfico de envío de versiones de diagnóstico y SDK de Azure

Azure Diagnostics versión 1.0 se envió por primera vez en un modelo de complemento, lo que significa que, al instalar el SDK de Azure, obtuvo la versión de Azure diagnostics se incluye con él.

A partir de SDK 2.5 (versión de diagnóstico 1.2), Azure los diagnósticos fueron a un modelo de extensión. Las herramientas para usar nuevas características solo estaban disponibles en SDK de Azure más recientes, pero cualquier servicio que use diagnósticos de Azure recogería la versión de envío más reciente directamente desde Azure. Por ejemplo, cualquier usuario que siga usando SDK 2.5 cargaría la versión más reciente que se muestra en la tabla anterior, independientemente de si usan las características más recientes.

Índice de esquemas

Las distintas versiones de Azure diagnóstico usan esquemas de configuración diferentes. El esquema 1.0 y 1.2 están en desuso. Para obtener más información sobre la versión 1.3 y posteriores, consulte Diagnostics 1.3 y versiones posteriores esquema de configuración.

Historial de versiones

En las secciones siguientes se describen los cambios realizados en cada versión de la extensión de diagnóstico.

Extensión Diagnostics 1.11

Se ha agregado compatibilidad con el receptor de Azure Monitor. Este receptor solo se puede aplicar a los contadores de rendimiento. Permite enviar contadores de rendimiento recopilados en la máquina virtual, Virtual Machine Scale Sets o servicio en la nube para Azure Monitor como métricas personalizadas. El receptor Azure Monitor admite:

• Recuperación de todos los contadores de rendimiento enviados a Azure Monitor a través de las API de métricas de Azure Monitor.
• Alertas sobre todos los contadores de rendimiento enviados a Azure Monitor a través de la nueva experiencia de alertas unified en Azure Monitor
• El tratamiento del operador comodín de los contadores de rendimiento como la dimensión "Instancia" de la métrica. Por ejemplo, si recopiló el contador "LogicalDisk(*)/DiskWrites/sec", podría filtrar y dividir en la dimensión "Instance". Permite trazar o alertar en las escrituras de disco por segundo para cada disco lógico. Por ejemplo, C:, D:, etc.

Definir Azure Monitor como un nuevo receptor en la configuración de la extensión de diagnóstico

"SinksConfig": {
    "Sink": [
        {
            "name": "AzureMonitorSink",
            "AzureMonitor": {}
        },
    ]
}

<SinksConfig>  
  <Sink name="AzureMonitorSink">
      <AzureMonitor/>
  </Sink>
</SinksConfig>

A continuación, puede configurar los contadores de rendimiento que se enrutarán al receptor de Azure Monitor.

"PerformanceCounters": {
    "scheduledTransferPeriod": "PT1M",
    "sinks": "AzureMonitorSink",
    "PerformanceCounterConfiguration": [
        {
            "counterSpecifier": "\\Processor(_Total)\\% Processor Time",
            "sampleRate": "PT1M",
            "unit": "percent"
        }
    ]
},

<PerformanceCounters scheduledTransferPeriod="PT1M", sinks="AzureMonitorSink">  
  <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT1M" unit="percent" />  
</PerformanceCounters>

Extensión Diagnostics 1.9

Se agregó compatibilidad con Docker.

Extensión Diagnostics 1.8.1

Puede especificar un token de SAS en lugar de una clave de cuenta de almacenamiento en la configuración privada. Si se proporciona un token de SAS, se omite la clave de cuenta de almacenamiento.

{
    "storageAccountName": "diagstorageaccount",
    "storageAccountEndPoint": "https://core.windows.net",
    "storageAccountSasToken": "{sas token}",
    "SecondaryStorageAccounts": {
        "StorageAccount": [
            {
                "name": "secondarydiagstorageaccount",
                "endpoint": "https://core.windows.net",
                "sasToken": "{sas token}"
            }
        ]
    }
}

<PrivateConfig>
    <StorageAccount name="diagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas token}" />
    <SecondaryStorageAccounts>
        <StorageAccount name="secondarydiagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas token}" />
    </SecondaryStorageAccounts>
</PrivateConfig>

Extensión Diagnostics 1.8

Se agregó StorageType a PublicConfig. Puede ser Table, Blob y TableAndBlob. Table es el valor predeterminado.

{
    "WadCfg": {
    },
    "StorageAccount": "diagstorageaccount",
    "StorageType": "TableAndBlob"
}

<PublicConfig>
    <WadCfg />
    <StorageAccount>diagstorageaccount</StorageAccount>
    <StorageType>TableAndBlob</StorageType>
</PublicConfig>

Extensión Diagnostics 1.7

Se ha agregado la capacidad de enrutar a Azure Event Hubs.

Extensión Diagnostics 1.5

Se agregaron el elemento Sinks y la capacidad de enviar datos de diagnóstico a Application Insights, lo que permitió diagnosticar de forma más sencilla los problemas tanto en la aplicación como en la infraestructura y el sistema.

SDK de Azure 2.6 y extensión de diagnóstico 1.3

En el caso de los proyectos de Cloud Service en Visual Studio, se realizaron los siguientes cambios. (Estos cambios también se aplican a versiones posteriores de SDK de Azure).

• El emulador local ahora es compatible con diagnósticos. Este cambio significa que puede recopilar datos de diagnóstico y asegurarse de que la aplicación está creando los seguimientos correctos mientras desarrolla y prueba en Visual Studio. El cadena de conexión UseDevelopmentStorage=true habilita la recopilación de datos de diagnóstico mientras ejecuta el proyecto de servicio en la nube en Visual Studio mediante el emulador de Azure Storage. Todos los datos de diagnóstico se recopilan en la cuenta de almacenamiento (Almacenamiento de desarrollo).
• La cuenta de almacenamiento de diagnóstico cadena de conexión (Microsoft. WindowsAzure.Plugins.Diagnostics.ConnectionString) se almacena una vez más en el archivo de configuración del servicio (.cscfg). En SDK de Azure 2.5, la cuenta de almacenamiento de diagnóstico se especificó en el archivo diagnostics.wadcfgx.

Hay algunas diferencias importantes entre la forma en que el cadena de conexión funcionó en SDK de Azure 2.4 y versiones anteriores y cómo funciona en SDK de Azure 2.6 y versiones posteriores.

• En SDK de Azure 2.4 y versiones anteriores, el complemento de diagnósticos usó el cadena de conexión para obtener la información de la cuenta de almacenamiento para transferir registros de diagnóstico.
• En SDK de Azure 2.6 y versiones posteriores, Visual Studio usa el cadena de conexión de diagnóstico para configurar la extensión de diagnóstico con la información de la cuenta de almacenamiento adecuada durante la publicación. El cadena de conexión permite definir diferentes cuentas de almacenamiento para distintas configuraciones de servicio que Visual Studio usa al publicar. Sin embargo, dado que el complemento de diagnóstico ya no está disponible (después de SDK de Azure 2.5), el archivo .cscfg por sí solo no puede habilitar la extensión diagnostics. Tiene que habilitar la extensión por separado a través de herramientas como Visual Studio o PowerShell.
• Para simplificar el proceso de configuración de la extensión de diagnóstico con PowerShell, la salida del paquete de Visual Studio también contiene el XML de configuración pública para la extensión de diagnóstico para cada rol. Visual Studio usa el cadena de conexión de diagnóstico para rellenar la información de la cuenta de almacenamiento presente en la configuración pública. Los archivos de configuración públicos se crean en la carpeta Extensiones y siguen el patrónPaaSDiagnostics.<RoleName>.PubConfig.xml. Cualquier implementación basada en PowerShell puede usar este patrón para asignar cada configuración a un rol.
• El cadena de conexión del archivo .cscfg también lo usa el portal de Azure para acceder a los datos de diagnóstico para que pueda aparecer en la pestaña Monitoring. El cadena de conexión es necesario para configurar el servicio para mostrar datos detallados de supervisión en el portal.

Migración de proyectos a SDK de Azure 2.6 y versiones posteriores

Al migrar de SDK de Azure 2.5 a SDK de Azure 2.6 o posterior, si tenía una cuenta de almacenamiento de diagnóstico especificada en el archivo .wadcfgx, permanece allí. Para aprovechar la flexibilidad de usar diferentes cuentas de almacenamiento para distintas configuraciones de almacenamiento, debe agregar manualmente el cadena de conexión al proyecto. Si va a migrar un proyecto de SDK de Azure 2.4 o versiones anteriores a SDK de Azure 2.6, se conservan las cadenas de conexión de diagnóstico. Sin embargo, tenga en cuenta los cambios en cómo se tratan las cadenas de conexión en SDK de Azure 2.6, tal como se especifica en la sección anterior.

Cómo Visual Studio determina la cuenta de almacenamiento de diagnóstico

• Si se especifica un cadena de conexión de diagnóstico en el archivo .cscfg, Visual Studio lo usa para configurar la extensión de diagnóstico al publicar y al generar los archivos XML de configuración pública durante el empaquetado.
• Si no se especifica ningún cadena de conexión de diagnóstico en el archivo .cscfg, Visual Studio recurre al uso de la cuenta de almacenamiento especificada en el archivo .wadcfgx. Usa esta cuenta de almacenamiento para configurar la extensión de diagnóstico al publicar y generar los archivos XML de configuración pública al empaquetar.
• El cadena de conexión de diagnóstico del archivo .cscfg tiene prioridad sobre la cuenta de almacenamiento en el archivo .wadcfgx. Si se especifica un cadena de conexión de diagnóstico en el archivo .cscfg, Visual Studio usa eso y omite la cuenta de almacenamiento en .wadcfgx.

¿Qué cadenas de conexión de almacenamiento de desarrollo se actualizan...". checkbox sí

La casilla de Actualizar cadenas de conexión de almacenamiento de almacenamiento para diagnósticos y almacenamiento en caché con credenciales de cuenta de almacenamiento Microsoft Azure al publicar en Microsoft Azure le ofrece una manera cómoda de actualizar las cadenas de conexión de la cuenta de almacenamiento de desarrollo con la cuenta de almacenamiento de Azure especificada durante la publicación.

Por ejemplo, supongamos que activa la casilla y el cadena de conexión de diagnóstico especifica UseDevelopmentStorage=true. Al publicar el proyecto en Azure, Visual Studio actualiza automáticamente el cadena de conexión de diagnóstico con la cuenta de almacenamiento especificada en el Asistente para publicación. Sin embargo, si se especificó una cuenta de almacenamiento real como el cadena de conexión de diagnóstico, esa cuenta se usa en su lugar.

Diferencias de funcionalidad de diagnóstico entre SDK de Azure 2.4 y versiones anteriores y SDK de Azure 2.5 y versiones posteriores

Si va a actualizar el proyecto de SDK de Azure 2.4 a SDK de Azure 2.5 o posterior, debe tener en cuenta las siguientes diferencias de funcionalidad de diagnóstico.

• las API de Configuration están en desuso: la configuración mediante programación de diagnósticos está disponible en SDK de Azure 2.4 o versiones anteriores, pero está en desuso en SDK de Azure 2.5 y versiones posteriores. Si la configuración de diagnóstico está definida actualmente en el código, debe volver a configurar esa configuración desde cero en el proyecto migrado para que los diagnósticos sigan funcionando. El archivo de configuración de diagnóstico para SDK de Azure 2.4 es diagnostics.wadcfg y diagnostics.wadcfgx para SDK de Azure 2.5 y versiones posteriores.
• El diagnóstico para aplicaciones de servicio en la nube solo se puede configurar en el nivel de rol, no en el nivel de instancia.
• Cada vez que implemente la aplicación, la configuración de diagnóstico se actualiza : puede provocar problemas de paridad si cambia la configuración de diagnóstico desde el Explorador de servidores y, a continuación, vuelve a implementar la aplicación.
• In SDK de Azure 2.5 y versiones posteriores, los volcados de memoria se configuran en el archivo de configuración de diagnóstico, no en el código : si tiene volcados de memoria configurados en el código, debe transferir manualmente la configuración del código al archivo de configuración, ya que los volcados de memoria no se transfieren durante la migración a SDK de Azure 2.6.