Díganos qué opina sobre la experiencia de descarga del PDF.

Documentación de Azure Service Health

Azure Service Health es un conjunto de experiencias que proporcionan guía y soporte
técnico personalizados cuando aparecen problemas en los servicios de Azure o que
pueden afectarle en el futuro. Azure Service Health consta del estado de Azure, el
servicio de mantenimiento y del estado de los recursos.

Acerca de Azure Service Health

ｅ INFORMACIÓN GENERAL

Servicio Azure Service Health

Estado de Azure

Portal de Service Health

Estado de los recursos

ｑ VIDEO

Vídeo de introducción a Azure Service Health

Obtención de notificaciones

ｃ GUÍA PASO A PASO

Obtención de notificaciones cuando se produce un problema en un servicio de Azure que le

afecta

Obtención de notificaciones cuando el recurso de Azure no está disponible

¿Qué es Azure Service Health?
Artículo • 01/06/2023

Azure ofrece un conjunto de experiencias para mantenerle informado sobre el estado

de los recursos en la nube. Esta información incluye los problemas actuales y futuros
como eventos que afectan al servicio, el mantenimiento planeado y otros cambios que
pueden afectar a la disponibilidad.

Azure Service Health es una combinación de tres servicios independientes más

pequeños.

Estado de Azure informa de las interrupciones de servicio en Azure en la página de

estado de Azure . La página es una vista global del estado de todos los servicios y
regiones de Azure. La página de estado es una buena referencia para incidentes con un
impacto masivo, pero se recomienda encarecidamente a los usuarios de Azure actuales
que aprovechan Azure Service Health para mantenerse informados sobre los incidentes
y el mantenimiento de Azure.

Service Health proporciona una vista personalizada del estado de los servicios y
regiones de Azure que usa. Es el mejor lugar para buscar comunicaciones que afecten a
los servicios relativas a interrupciones, actividades de mantenimiento planeado y otros
avisos de mantenimiento, ya que tras la autenticación, Service Health conoce los
servicios y recursos que usa en la actualidad. La mejor forma de usar Service Health es
configurar sus alertas para que le envíen notificaciones a través de sus canales de
comunicación preferidos cuando los problemas del servicio, el mantenimiento planeado
u otros cambios puedan afectar a los servicios y regiones de Azure que utilice.

Resource Health proporciona información sobre el estado de los recursos en la nube

individuales, como una instancia de máquina virtual concreta. Mediante Azure Monitor
también puede configurar alertas que le notifiquen los cambios de disponibilidad de los
recursos en la nube. Resource Health, junto con las notificaciones de Azure Monitor, le
ayudarán a estar mejor informado acerca de la disponibilidad de los recursos minuto a
minuto y a evaluar rápidamente si un problema se le puede achacar a usted o está
relacionado con un evento de plataforma de Azure.

Conjuntamente, estas experiencias proporcionan una vista completa del estado de

Azure con el nivel de detalle relevante.

Vea una introducción de la página Estado de Azure, Azure Service Health y Azure
Resource Health
https://www.microsoft.com/es-es/videoplayer/embed/RE2OgX6?
postJsllMsg=true&autoCaptions=es-es
７ Nota

Este servicio admite Azure Lighthouse, que permite a los proveedores de servicios
iniciar sesión en su propio inquilino para administrar las suscripciones y los grupos
de recursos que los clientes hayan delegado.
Novedades del servicio Azure Service
Health
Artículo • 01/06/2023

En este artículo se enumeran los cambios recientes en el servicio Azure Service Health.

Se ha cambiado la ubicación de la página de

estado de Azure
El 25 de julio de 2022, la ubicación de la página de estado de Azure cambió a
azure.status.microsoft de status.azure.com. A partir de febrero de 2023, se le redirigirá
automáticamente a esta nueva página. La página actual dejará de estar operativa poco
después.

Cambios en la interfaz de usuario en la página

de estado de Azure
Los siguientes cambios se realizaron el 25 de julio de 2022:

Se ha agregado una nueva pestaña denominada Impacto actual a la página de

estado de Azure.
Se ha actualizado la interfaz de usuario del historial de estado.

Para obtener más información sobre la página de estado de Azure, vea Introducción al
estado de Azure.

Actualización de la experiencia del portal de

Azure Service Health
El 6 de junio de 2022, se actualizó la experiencia del portal de Azure Service Health. Para
obtener más información, consulte Actualización del portal de Azure Service Health
Creación de alertas del registro de
actividad en notificaciones del servicio
mediante Azure Portal
Artículo • 01/06/2023

En este artículo se explica cómo usar Azure Portal para configurar las alertas del registro
de actividad para las notificaciones de mantenimiento de un servicio mediante Azure
Portal.

Las notificaciones de mantenimiento del servicio se almacenan en el registro de

actividad de Azure. Debido al gran volumen de información almacenada en el registro
de actividad, existe una interfaz de usuario independiente que facilita la visualización y
la configuración de alertas en las notificaciones de mantenimiento del servicio.

Puede recibir una alerta cuando Azure envía notificaciones de estado del servicio a la
suscripción de Azure. Puede configurar la alerta en función de:

La clase de notificación de estado del servicio (problemas de servicio,

mantenimiento planificado, avisos de estado y avisos de seguridad).
La suscripción afectada.
Los servicios afectados.
Las regiones afectadas.

７ Nota

Las notificaciones de estado del servicio no envían alertas para los eventos de
estado de los recursos.

También puede configurar a quién se debe enviar la alerta:

Seleccione un grupo de acciones existente.

Cree un nuevo grupo de acciones (que puede usarse para futuras alertas).

Para más información sobre los grupos de acciones, consulte Creación y administración
de grupos de acciones.

Para obtener información sobre cómo configurar las alertas de notificación de

mantenimiento del servicio mediante plantillas de Azure Resource Manager, consulte
Plantillas de Resource Manager.
Ver un vídeo sobre cómo configurar su primera
alerta de Azure Service Health
https://www.microsoft.com/es-es/videoplayer/embed/RE2OaXt?
postJsllMsg=true&autoCaptions=es-es

Creación de una alerta de Service Health

mediante Azure Portal
1. En el portal , seleccione Estado del servicio.

2. En la sección Alertas, seleccione Alertas de estado.

 3. Seleccione Añadir alerta de Service Health.

4. El Asistente para crear una regla de alertas se abre en la pestaña Condiciones,

con la pestaña Ámbito ya rellenada. Siga los pasos para alertas de Service Health
de la pestaña Condiciones, en el Asistente para crear una regla de alertas.

Obtenga información acerca de cómo configurar notificaciones de webhook para los

sistemas de administración de problemas existentes. Para obtener información sobre el
esquema de webhook para las alertas del registro de actividad, consulte Webhooks para
alertas del registro de actividad de Azure.

Pasos siguientes
Obtenga información sobre los procedimientos recomendados para la
configuración de alertas de Azure Service Health .
Obtenga información sobre cómo configurar notificaciones de inserción móviles
de Azure Service Health .
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre la Limitación del número de notificaciones.
Revise el Esquema de webhook de alertas del registro de actividad.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo
puede recibir alertas.
Más información sobre los grupos de acciones.
Inicio rápido: Creación de alertas del
registro de actividad en notificaciones
del servicio mediante un archivo de
Bicep
Artículo • 11/05/2023

En este artículo se explica cómo configurar las alertas del registro de actividad para las
notificaciones de mantenimiento de un servicio usando un archivo Bicep.

Bicep es un lenguaje específico de dominio (DSL) que usa una sintaxis declarativa para
implementar recursos de Azure. Brinda sintaxis concisa, seguridad de tipos confiable y
compatibilidad con la reutilización de código. Bicep ofrece la mejor experiencia de
creación para sus soluciones de infraestructura como código en Azure.

Las notificaciones de mantenimiento del servicio se almacenan en el registro de

actividad de Azure. Debido al volumen posiblemente grande de la información
almacenada en el registro de actividad, hay una interfaz de usuario independiente que
facilita la visualización y la configuración de alertas en las notificaciones de
mantenimiento del servicio.

Puede recibir una alerta cuando Azure envía notificaciones de estado del servicio a la
suscripción de Azure. Puede configurar la alerta en función de:

La clase de notificación de estado del servicio (problemas de servicio,

mantenimiento planificado y avisos de estado).
La suscripción afectada.
Los servicios afectados.
Las regiones afectadas.

７ Nota

Las notificaciones de estado del servicio no envían una alerta relativa a los eventos
de estado de recursos.

También puede configurar a quién se debe enviar la alerta:

Seleccione un grupo de acciones existente.

Cree un nuevo grupo de acciones (que puede usarse para futuras alertas).
Para más información sobre los grupos de acciones, consulte Creación y administración
de grupos de acciones.

Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Para ejecutar los comandos desde la máquina local, instale la CLI de Azure o los
módulos de Azure PowerShell. Para más información, consulte Instalación de la CLI
de Azure e Instalar Azure Powershell.

Revisión del archivo de Bicep

En el siguiente archivo Bicep crea un grupo de acciones con un destino de correo
electrónico y se habilitan todas las notificaciones de estado de servicio de la suscripción
de destino. Guarde este Bicep como CreateServiceHealthAlert.bicep.

Bicep

param actionGroups_name string = 'SubHealth'

param activityLogAlerts_name string = 'ServiceHealthActivityLogAlert'
param emailAddress string

var alertScope = '/subscriptions/${subscription().subscriptionId}'

resource actionGroups_name_resource 'microsoft.insights/actionGroups@2019-

06-01' = {
name: actionGroups_name
location: 'Global'
properties: {
groupShortName: actionGroups_name
enabled: true
emailReceivers: [
{
name: actionGroups_name
emailAddress: emailAddress
}
]
smsReceivers: []
webhookReceivers: []
}
}

resource activityLogAlerts_name_resource
'microsoft.insights/activityLogAlerts@2017-04-01' = {
name: activityLogAlerts_name
location: 'Global'
properties: {
scopes: [
 alertScope
]
condition: {
allOf: [
{
field: 'category'
equals: 'ServiceHealth'
}
{
field: 'properties.incidentType'
equals: 'Incident'
}
]
}
actions: {
actionGroups: [
{
actionGroupId: actionGroups_name_resource.id
webhookProperties: {}
}
]
}
enabled: true
}
}

El archivo de Bicep define dos recursos:

Microsoft.Insights/actionGroups
Microsoft.Insights/activityLogAlerts

Implementación del archivo de Bicep

Implemente el archivo de Bicep mediante la CLI de Azure y Azure PowerShell.
Reemplace los valores de ejemplo del grupo de recursos y dirección de correo
electrónico por los valores adecuados para su entorno.

CLI

Azure CLI

az login
az deployment group create --name CreateServiceHealthAlert --resource-
group my-resource-group --template-file CreateServiceHealthAlert.bicep -
-parameters emailAddress='[email protected]'
Validación de la implementación
Para comprobar que se ha creado el área de trabajo, utilice uno de los comandos
siguientes. Reemplace los valores de ejemplo del grupo de recursos por los valores que
usó anteriormente.

CLI

Azure CLI

az monitor activity-log alert show --resource-group my-resource-group --

name ServiceHealthActivityLogAlert

Limpieza de recursos
Si planea seguir trabajando en otros inicios rápidos y tutoriales, considere la posibilidad
de dejar estos recursos activos. Cuando ya no lo necesite, elimine el grupo de recursos;
de este modo, se eliminarán también la regla de alertas y los recursos relacionados. Para
eliminar el grupo de recursos mediante la CLI de Azure o Azure PowerShell

CLI

Azure CLI

az group delete --name my-resource-group

Pasos siguientes
Obtenga información sobre los procedimientos recomendados para la
configuración de alertas de Azure Service Health .
Obtenga información sobre cómo configurar notificaciones de inserción móviles
de Azure Service Health .
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre la Limitación del número de notificaciones.
Revise el Esquema de webhook de alertas del registro de actividad.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo
puede recibir alertas.
Más información sobre los grupos de acciones.
Inicio rápido: Creación de alertas del
registro de actividad en notificaciones
del servicio mediante una plantilla de
Resource Manager
Artículo • 10/03/2023

En este artículo se explica cómo configurar las alertas del registro de actividad para las
notificaciones de mantenimiento de un servicio mediante una plantilla de Resource
Manager.

Una plantilla de administrador de recursos es un archivo de notación de objetos

JavaScript (JSON) que define la infraestructura y la configuración del proyecto. La
plantilla usa sintaxis declarativa. En la sintaxis declarativa, se describe la implementación
deseada sin escribir la secuencia de comandos de programación para crearla.

Las notificaciones de mantenimiento del servicio se almacenan en el registro de

actividad de Azure. Debido al volumen posiblemente grande de la información
almacenada en el registro de actividad, hay una interfaz de usuario independiente que
facilita la visualización y la configuración de alertas en las notificaciones de
mantenimiento del servicio.

Puede recibir una alerta cuando Azure envía notificaciones de estado del servicio a la
suscripción de Azure. Puede configurar la alerta en función de:

La clase de notificación de estado del servicio (problemas de servicio,

mantenimiento planificado y avisos de estado).
La suscripción afectada.
Los servicios afectados.
Las regiones afectadas.

７ Nota

Las notificaciones de estado del servicio no envían una alerta relativa a los eventos
de estado de recursos.

También puede configurar a quién se debe enviar la alerta:

Seleccione un grupo de acciones existente.

Cree un nuevo grupo de acciones (que puede usarse para futuras alertas).
Para más información sobre los grupos de acciones, consulte Creación y administración
de grupos de acciones.

Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Para ejecutar los comandos desde la máquina local, instale la CLI de Azure o los
módulos de Azure PowerShell. Para más información, consulte Instalación de la CLI
de Azure e Instalar Azure Powershell.

Revisión de la plantilla
En el siguiente ejemplo se crea un grupo de acciones con un destino de correo
electrónico y se habilitan todas las notificaciones de estado de servicio de la suscripción
de destino. Guarde esta plantilla como CreateServiceHealthAlert.json.

JSON

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"actionGroups_name": {
"type": "string",
"defaultValue": "SubHealth"
},
"activityLogAlerts_name": {
"type": "string",
"defaultValue": "ServiceHealthActivityLogAlert"
},
"emailAddress": {
"type": "string"
}
},
"variables": {
"alertScope": "[format('/subscriptions/{0}',
subscription().subscriptionId)]"
},
"resources": [
{
"type": "microsoft.insights/actionGroups",
"apiVersion": "2019-06-01",
"name": "[parameters('actionGroups_name')]",
"location": "Global",
"properties": {
"groupShortName": "[parameters('actionGroups_name')]",
"enabled": true,
 "emailReceivers": [
{
"name": "[parameters('actionGroups_name')]",
"emailAddress": "[parameters('emailAddress')]"
}
],
"smsReceivers": [],
"webhookReceivers": []
}
},
{
"type": "microsoft.insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlerts_name')]",
"location": "Global",
"properties": {
"scopes": [
"[variables('alertScope')]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "ServiceHealth"
},
{
"field": "properties.incidentType",
"equals": "Incident"
}
]
},
"actions": {
"actionGroups": [
{
"actionGroupId": "
[resourceId('microsoft.insights/actionGroups',
parameters('actionGroups_name'))]",
"webhookProperties": {}
}
]
},
"enabled": true
},
"dependsOn": [
"[resourceId('microsoft.insights/actionGroups',
parameters('actionGroups_name'))]"
]
}
]
}

La plantilla define dos recursos:

 Microsoft.Insights/actionGroups
Microsoft.Insights/activityLogAlerts

Implementación de la plantilla
Implemente la plantilla mediante cualquier método estándar de implementación de una
plantilla de Resource Manager como en los ejemplos siguientes con la CLI y PowerShell.
Reemplace los valores de ejemplo del grupo de recursos y dirección de correo
electrónico por los valores adecuados para su entorno.

CLI

Azure CLI

az login
az deployment group create --name CreateServiceHealthAlert --resource-
group my-resource-group --template-file CreateServiceHealthAlert.json --
parameters emailAddress='[email protected]'

Validación de la implementación
Para comprobar que se ha creado el área de trabajo, utilice uno de los comandos
siguientes. Reemplace los valores de ejemplo del grupo de recursos por los valores que
usó anteriormente.

CLI

Azure CLI

az monitor activity-log alert show --resource-group my-resource-group --

name ServiceHealthActivityLogAlert

Limpieza de recursos
Si planea seguir trabajando en otros inicios rápidos y tutoriales, considere la posibilidad
de dejar estos recursos activos. Cuando ya no lo necesite, elimine el grupo de recursos;
de este modo, se eliminarán también la regla de alertas y los recursos relacionados. Para
eliminar el grupo de recursos mediante la CLI de Azure o Azure PowerShell
CLI

Azure CLI

az group delete --name my-resource-group

Pasos siguientes
Obtenga información sobre los procedimientos recomendados para la
configuración de alertas de Azure Service Health .
Obtenga información sobre cómo configurar notificaciones de inserción móviles
de Azure Service Health .
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre la Limitación del número de notificaciones.
Revise el Esquema de webhook de alertas del registro de actividad.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo
puede recibir alertas.
Más información sobre los grupos de acciones.
Consultas de ejemplo de Azure
Resource Graph para Azure Service
Health
Artículo • 07/08/2023

Esta página es una colección de consultas de ejemplo de Azure Resource Graph para
Azure Service Health. Para obtener una lista completa de ejemplos de Azure Resource
Graph, vea Ejemplos de Resource Graph por categoría y Ejemplos de Resource Graph
por tabla.

Azure Service Health

Impacto en la suscripción de los eventos activos de

Service Health
Devuelve todos los eventos activos de Service Health, incluidos los problemas del
servicio, el mantenimiento planeado y las advertencias de estado y de seguridad, y los
agrupa por tipo de evento e incluye el número de suscripciones afectadas.

Kusto

ServiceHealthResources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend eventType = tostring(properties.EventType), status =
properties.Status, description = properties.Title, trackingId =
properties.TrackingId, summary = properties.Summary, priority =
properties.Priority, impactStartTime = properties.ImpactStartTime,
impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where properties.Status == 'Active' and tolong(impactStartTime) > 1
| summarize count(subscriptionId) by name, eventType

CLI de Azure

Azure CLI

az graph query -q "ServiceHealthResources | where type =~

'Microsoft.ResourceHealth/events' | extend eventType =
tostring(properties.EventType), status = properties.Status, description
= properties.Title, trackingId = properties.TrackingId, summary =
properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
 todatetime(tolong(properties.ImpactMitigationTime)) | where
properties.Status == 'Active' and tolong(impactStartTime) > 1 |
summarize count(subscriptionId) by name, eventType"

Todos los eventos de aviso de estado activos

Devuelve todos los eventos de advertencia de estado de Service Health que están
activos en todas las suscripciones a las que el usuario tiene acceso.

Kusto

ServiceHealthResources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend eventType = properties.EventType, status = properties.Status,
description = properties.Title, trackingId = properties.TrackingId, summary
= properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime))
| where properties.Status == 'Active' and tolong(impactStartTime) > 1 and
eventType == 'HealthAdvisory'

CLI de Azure

Azure CLI

az graph query -q "ServiceHealthResources | where type =~

'Microsoft.ResourceHealth/events' | extend eventType =
properties.EventType, status = properties.Status, description =
properties.Title, trackingId = properties.TrackingId, summary =
properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime)) | where
properties.Status == 'Active' and tolong(impactStartTime) > 1 and
eventType == 'HealthAdvisory'"

Todos los eventos de mantenimiento planeado activos

Devuelve todos los eventos de mantenimiento planeado de Service Health que están
activos en todas las suscripciones a las que el usuario tiene acceso.

Kusto

ServiceHealthResources
| where type =~ 'Microsoft.ResourceHealth/events'
 | extend eventType = properties.EventType, status = properties.Status,
description = properties.Title, trackingId = properties.TrackingId, summary
= properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime))
| where properties.Status == 'Active' and tolong(impactStartTime) > 1 and
eventType == 'PlannedMaintenance'

CLI de Azure

Azure CLI

az graph query -q "ServiceHealthResources | where type =~

'Microsoft.ResourceHealth/events' | extend eventType =
properties.EventType, status = properties.Status, description =
properties.Title, trackingId = properties.TrackingId, summary =
properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime)) | where
properties.Status == 'Active' and tolong(impactStartTime) > 1 and
eventType == 'PlannedMaintenance'"

Todos los eventos de Service Health activos

Devuelve todos los eventos de Service Health que están activos en todas las
suscripciones a las que el usuario tiene acceso, incluidos los problemas de servicio, el
mantenimiento planeado y las advertencias de estado y de seguridad.

Kusto

ServiceHealthResources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend eventType = properties.EventType, status = properties.Status,
description = properties.Title, trackingId = properties.TrackingId, summary
= properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime))
| where properties.Status == 'Active' and tolong(impactStartTime) > 1

CLI de Azure

Azure CLI

az graph query -q "ServiceHealthResources | where type =~

'Microsoft.ResourceHealth/events' | extend eventType =
properties.EventType, status = properties.Status, description =
 properties.Title, trackingId = properties.TrackingId, summary =
properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime)) | where
properties.Status == 'Active' and tolong(impactStartTime) > 1"

Todos los eventos de problemas del servicio activos

Devuelve todos los eventos de problemas del servicio (interrupciones) de Service Health
que están activos en todas las suscripciones a las que el usuario tiene acceso.

Kusto

ServiceHealthResources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend eventType = properties.EventType, status = properties.Status,
description = properties.Title, trackingId = properties.TrackingId, summary
= properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime))
| where properties.Status == 'Active' and tolong(impactStartTime) > 1 and
eventType == 'ServiceIssue'

CLI de Azure

Azure CLI

az graph query -q "ServiceHealthResources | where type =~

'Microsoft.ResourceHealth/events' | extend eventType =
properties.EventType, status = properties.Status, description =
properties.Title, trackingId = properties.TrackingId, summary =
properties.Summary, priority = properties.Priority, impactStartTime =
properties.ImpactStartTime, impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime)) | where
properties.Status == 'Active' and tolong(impactStartTime) > 1 and
eventType == 'ServiceIssue'"

Estado de los recursos

Recuento de máquinas virtuales por estado de

disponibilidad e identificador de suscripción
Devuelve el recuento de máquinas virtuales (tipo Microsoft.Compute/virtualMachines )
agregadas por su estado de disponibilidad en cada una de las suscripciones.

Kusto

HealthResources
| where type =~ 'microsoft.resourcehealth/availabilitystatuses'
| summarize count() by subscriptionId, AvailabilityState =
tostring(properties.availabilityState)

CLI de Azure

Azure CLI

az graph query -q "HealthResources | where type =~

'microsoft.resourcehealth/availabilitystatuses' | summarize count() by
subscriptionId, AvailabilityState =
tostring(properties.availabilityState)"

Lista de máquinas virtuales y estados de disponibilidad

asociados por identificadores de recursos
Devuelve la lista más reciente de máquinas virtuales (tipo
Microsoft.Compute/virtualMachines ) agregadas por estado de disponibilidad. La

consulta también proporciona el identificador de recurso asociado basado en

properties.targetResourceId para facilitar la depuración y la mitigación. Los estados de

disponibilidad pueden ser uno de los cuatro valores: Disponible, No disponible,

Degradado y Desconocido. Para obtener más información sobre lo que significa cada
uno de los estados de disponibilidad, consulte Información general sobre Azure
Resource Health.

Kusto

HealthResources
| where type =~ 'microsoft.resourcehealth/availabilitystatuses'
| summarize by ResourceId = tolower(tostring(properties.targetResourceId)),
AvailabilityState = tostring(properties.availabilityState)

CLI de Azure

Azure CLI
 az graph query -q "HealthResources | where type =~
'microsoft.resourcehealth/availabilitystatuses' | summarize by
ResourceId = tolower(tostring(properties.targetResourceId)),
AvailabilityState = tostring(properties.availabilityState)"

Lista de máquinas virtuales por estado de disponibilidad

y estado de energía con identificadores de recursos y
grupos de recursos
Devuelve una lista de máquinas virtuales (tipo Microsoft.Compute/virtualMachines )
agregadas en su estado de energía y estado de disponibilidad para proporcionar un
estado de mantenimiento coherente para las máquinas virtuales. La consulta también
proporciona detalles sobre el grupo de recursos y el identificador de recurso asociados
a cada entrada para una visibilidad detallada de los recursos.

Kusto

Resources
| where type =~ 'microsoft.compute/virtualmachines'
| project resourceGroup, Id = tolower(id), PowerState = tostring(
properties.extended.instanceView.powerState.code)
| join kind=leftouter (
HealthResources
| where type =~ 'microsoft.resourcehealth/availabilitystatuses'
| where tostring(properties.targetResourceType) =~
'microsoft.compute/virtualmachines'
| project targetResourceId =
tolower(tostring(properties.targetResourceId)), AvailabilityState =
tostring(properties.availabilityState))
on $left.Id == $right.targetResourceId
| project-away targetResourceId
| where PowerState != 'PowerState/deallocated'

CLI de Azure

Azure CLI

az graph query -q "Resources | where type =~

'microsoft.compute/virtualmachines' | project resourceGroup, Id =
tolower(id), PowerState = tostring(
properties.extended.instanceView.powerState.code) | join kind=leftouter
( HealthResources | where type =~
'microsoft.resourcehealth/availabilitystatuses' | where
tostring(properties.targetResourceType) =~
'microsoft.compute/virtualmachines' | project targetResourceId =
 tolower(tostring(properties.targetResourceId)), AvailabilityState =
tostring(properties.availabilityState)) on \$left.Id ==
\$right.targetResourceId | project-away targetResourceId | where
PowerState != 'PowerState/deallocated'"

Lista de máquinas virtuales que no están disponibles por

identificadores de recursos
Devuelve la lista más reciente de máquinas virtuales (tipo
Microsoft.Compute/virtualMachines ) agregadas por su estado de disponibilidad. La lista

rellenada solo resalta las máquinas virtuales cuyo estado de disponibilidad no es

"Disponible" para asegurarse de que conoce todos los estados relacionados en los que
se encuentran las máquinas virtuales. Cuando todas las máquinas virtuales estén
disponibles, puede esperar no recibir ningún resultado.

Kusto

HealthResources
| where type =~ 'microsoft.resourcehealth/availabilitystatuses'
| where tostring(properties.availabilityState) != 'Available'
| summarize by ResourceId = tolower(tostring(properties.targetResourceId)),
AvailabilityState = tostring(properties.availabilityState)

CLI de Azure

Azure CLI

az graph query -q "HealthResources | where type =~

'microsoft.resourcehealth/availabilitystatuses' | where
tostring(properties.availabilityState) != 'Available' | summarize by
ResourceId = tolower(tostring(properties.targetResourceId)),
AvailabilityState = tostring(properties.availabilityState)"

Pasos siguientes
Obtenga más información sobre el lenguaje de consulta.
Obtenga más información sobre cómo explorar recursos.
Vea ejemplos de Consultas de lenguaje de inicio.
Vea ejemplos de Consultas de lenguaje avanzadas.
Información general del estado de
Azure
Artículo • 01/06/2023

Estado de Azure proporciona una visión global del estado de los servicios y regiones
de Azure. Con el estado de Azure, puede obtener información sobre la disponibilidad
del servicio. El estado de Azure está disponible para que todos los usuarios puedan ver
todos los servicios que informan del estado del servicio, así como los incidentes con
gran impacto. Sin embargo, si es un usuario de Azure actual, se recomienda
encarecidamente utilizar la experiencia personalizada de Azure Service Health . Azure
Service Health incluye información acerca de todas las interrupciones, las próximas
actividades de mantenimiento planeado y las advertencias de servicio.

Esta experiencia se actualizó el 25 de julio de 2022. Para obtener más información,

consulte Novedades de Azure Service Health

Actualizaciones de estado de Azure

La página de estado de Azure se actualiza en tiempo real cuando cambia el estado de
los servicios de Azure. Si deja abierta la página de estado de Azure, puede controlar la
velocidad a la que la página se actualiza con los nuevos datos. En la parte superior,
puede ver la última vez que se actualizó la página.

Banner de estado de Azure

El banner de estado de la página Estado de Azure resalta los incidentes activos que
afectan a los servicios de Azure.

Pestaña Impacto actual

La página de estado de Azure muestra el impacto actual de un evento activo en la
totalidad de Azure. Use Azure Service Health para ver otros problemas que pueden
afectar a los servicios.
Historial de estado de Azure
Aunque la página de estado de Azure siempre muestra la información de estado más
reciente, puede ver los eventos más antiguos desde la página Historial de estado de
Azure. La página del historial contiene todos los RCA de los incidentes que se
produjeron el 20 de noviembre de 2019, o posteriormente. Los RCA anteriores al 20 de
noviembre de 2019 no están disponibles. A partir de este punto, la página del historial
mostrará los RCA de hasta cinco años de antigüedad.

Fuente RSS
El estado de Azure también proporciona una fuente RSS de los cambios en el estado
de los servicios de Azure a los que se puede suscribir.

¿Cuándo publica Azure las comunicaciones en

la página Estado?
La mayoría de nuestras comunicaciones de problemas de servicio funcionan como
notificaciones dirigidas, enviadas directamente a los socios & clientes afectados. Se
entregan a través de Azure Service Health en Azure Portal y desencadenan las alertas
de Azure Service Health que se han configurado. La página pública de Estado solo se
usa para comunicar problemas de servicio en tres escenarios específicos:

Escenario 1: Un impacto grande, que implica varias regiones, zonas o servicios:

un problema de servicio que tiene un impacto grande o significativo para el cliente
en varios servicios, abarcando una región completa o varias. En estos casos, la
notificación se envía porque es posible que la resistencia configurada por el
 cliente, como la alta disponibilidad o la recuperación ante desastres, no sea
suficiente para evitar el impacto.
Escenario 2: Azure Portal o Service Health no accesible: un problema de servicio
impide el acceso a Azure Portal o a Azure Service Health y, por tanto, afecta a
nuestra ruta estándar de comunicación de interrupciones, descrita anteriormente.
Escenario 3: Hay un impacto en el servicio, pero aún no está claro a quién ha
afectado: el problema de servicio tiene un impacto grande o significativo para el
cliente, pero aún no podemos confirmar qué clientes, regiones o servicios se ven
afectados. En este caso, no podemos enviar comunicaciones dirigidas, por lo que
proporcionamos actualizaciones públicas.

¿Cuándo publica Azure los RCA en la página de

Historial del estado?
Aunque la página de Estado de Azure siempre muestra la información de estado más
reciente, puede ver los eventos anteriores desde la página de Historial del estado de
Azure . La página del historial contiene todos los RCA (Análisis de la causa principal) de
los incidentes que se produjeron a partir del 20 de noviembre de 2019, y
proporcionarán, desde esa fecha, un historial de RCA de cinco años. Los RCA anteriores
al 20 de noviembre de 2019 no están disponibles.

A partir del 1 de junio de 2022, la página de Historial del estado de Azure solo se
usará para proporcionar RCA del escenario 1 que se ha descrito anteriormente. Nuestro
compromiso es hacer públicos los RCA que trataron los problemas de servicio con el
mayor impacto, como los que tienen un impacto en varios servicios y en varias regiones.
Lo hacemos para asegurarnos de que todos los clientes y el sector en general puedan
aprender de nuestras retrospectivas sobre estos problemas, y comprender qué pasos
estamos llevando a cabo para hacer que estos problemas sean menos probables o
menos graves en el futuro.

Respecto a los escenarios 2 y 3 que se han descrito anteriormente, podemos

comunicarnos públicamente en la página Estado durante el impacto, como forma de
manejar la situación cuando nuestras comunicaciones estándar y dirigidas no puedan
llegar a todos los clientes afectados. Una vez mitigado el problema, llevaremos a cabo
un análisis de impacto exhaustivo para determinar con exactitud cuáles fueron las
suscripciones de clientes que se vieron afectadas. En estos escenarios,
proporcionaremos el PIR pertinente solo a los clientes afectados, a través de Azure
Service Health en Azure Portal.

Pasos siguientes
Aprenda a conseguir una vista más personalizada del estado de Azure con Service
Health.
Aprenda cómo puede obtener una vista más detallada del estado de los recursos
específicos de Azure con Resource Health.
Introducción a Resource Health
Artículo • 13/12/2023

Azure Resource Health ayuda a diagnosticar problemas en los servicios que afectan a los
recursos de Azure y a obtener soporte técnico para resolverlos. Informa sobre el
mantenimiento actual y pasado de los recursos.

Estado de Azure informa sobre problemas de servicio que afectan a un amplio

conjunto de clientes de Azure. Resource Health proporciona un panel personalizado con
el mantenimiento de los recursos y muestra todas las veces que los recursos no
estuvieron disponibles debido a problemas de servicio de Azure. Estos datos facilitan la
tarea de comprobar si se ha infringido un Acuerdo de Nivel de Servicio.

Definición de recurso y evaluación de

mantenimiento
Un recurso es una instancia específica de un servicio de Azure, como una máquina
virtual, una aplicación web o una base de datos SQL. Resource Health se basa en las
señales procedentes de distintos servicios de Azure para evaluar si el mantenimiento de
un recurso es correcto. Si el mantenimiento de un recurso no es correcto, Resource
Health analiza información adicional para determinar el origen del problema. También
informa sobre las acciones que Microsoft lleva a cabo para corregir el problema e
identifica las medidas que usted puede tomar para solucionarlo.

Para obtener más información sobre cómo se evalúa el mantenimiento, consulte la lista
de tipos de recurso y comprobaciones de mantenimiento en Azure Resource Health.

Estado de mantenimiento
El mantenimiento de un recurso se muestra con uno de los siguientes estados.

Disponible
Disponible significa que no se ha detectado ningún evento que afecte al mantenimiento
del recurso. En los casos en los que el recurso se haya recuperado de un tiempo de
inactividad no planeado durante las últimas 24 horas, verá la notificación "Resuelto
recientemente".
No disponible
No disponible significa que el servicio ha detectado un evento en curso relacionado con
la plataforma o no relacionado con la plataforma que afecta al mantenimiento del
recurso.

Eventos de plataforma
Varios componentes de la infraestructura de Azure desencadenan estos eventos. Por
ejemplo, acciones programadas (como mantenimiento planeado) e incidentes
inesperados (como reinicio del host no planeado o un hardware host degradado que se
predice que falla después de un período de tiempo especifico).

Resource Health proporciona detalles adicionales sobre el evento y el proceso de

recuperación. También le permite ponerse en contacto con el Soporte técnico de
Microsoft, aunque no tenga un contrato de soporte técnico activo.
Eventos no relacionados con la plataforma
Los eventos no relacionados con la plataforma se desencadenan por las acciones del
usuario. Por ejemplo, al detener una máquina virtual o alcanzar el número máximo de
conexiones a una instancia de Azure Cache for Redis.
Unknown
Desconocido indica que Resource Health no ha recibido información sobre el recurso
durante más de 10 minutos. Esto ocurre normalmente cuando se han desasignado las
máquinas virtuales. Si bien este estado no es una indicación definitiva del estado del
recurso, es un punto de datos importante para la solución de problemas.

Si el recurso se ejecuta según lo esperado, el estado del recurso cambia a Disponible al

cabo de unos minutos.

Si tiene problemas con el recurso, el estado de mantenimiento Desconocido podría

indicar que un evento de la plataforma afecta al recurso.

Degradado
Degradado significa que el recurso ha detectado una pérdida de rendimiento, aunque
sigue estando disponible para su uso.

Los distintos recursos tienen sus propios criterios respecto a cuándo notifican que están
degradados.
Para obtener información sobre Virtual Machine Scale Sets, visite El estado de
mantenimiento de recursos es "Degradado" en la página Conjunto de escalado de
máquinas virtuales de Azure para obtener más información.

Mantenimiento no admitido
El mensaje Estado no admitido o RP no tiene información sobre el recurso o no tiene
acceso de lectura y escritura para ese recurso significa que el recurso no es compatible
con las métricas de mantenimiento.

Para saber qué recursos admiten las métricas de mantenimiento, consulte la página
Tipos de recursos admitidos.

Eventos de Resource Health enviados al

registro de actividad
Un evento de estado de recursos se registra en el registro de actividad cuando:

Se envía una anotación, por ejemplo, "ResourceDegraded" o

"AccountClientThrottling" para un recurso.
Un recurso pasado a o desde Incorrecto.
Un recurso era Incorrecto durante más de 15 minutos.

Las siguientes transiciones de estado de los recursos no se registran en el registro de

actividad:
 Una transición al estado Desconocido.
Una transición del estado Desconocido si:
Esta es la primera transición.
Si el estado anterior a Unknown es el mismo que el nuevo estado después. (Por
ejemplo, si el recurso ha pasado de Correcto a Desconocido y vuelve a
Correcto).
Para los recursos de proceso: máquinas virtuales que pasan de Correcto a
Incorrecto y vuelven a Correcto, cuando el tiempo incorrecto es inferior a 35
segundos.

Información del historial

７ Nota

Puede enumerar los eventos de mantenimiento del servicio actuales en los datos
de suscripción y consulta hasta 1 año mediante el parámetro QueryStartTime de la
API de REST Events - List By Subscription Id, pero actualmente no hay ningún
parámetro QueryStartTime en la API de REST Events - List By Single Resource, por
lo que no puede consultar datos hasta 1 año mientras se enumeran los eventos de
mantenimiento del servicio actuales para un recurso determinado.

Puede tener acceso al historial de hasta 30 días en la sección Historial de estado de

Resource Health en Azure Portal.
Información de la causa principal
Si Azure tiene más información sobre la causa principal de una falta de disponibilidad
iniciada por la plataforma, esa información puede publicarse en el estado del recurso
hasta 72 horas después de la falta de disponibilidad inicial. Esta información solo está
disponible para las máquinas virtuales en este momento.

Introducción
Para abrir Resource Health para un recurso:

1. Inicie sesión en Azure Portal.

2. Vaya a su sitio.
3. En el menú de recursos del panel izquierdo, seleccione Resource Health.
 4. En la cuadrícula historial de estado, puede descargar un PDF o hacer clic en el
botón RCA "Compartir/Administrar".

Otra manera de acceder a Resource Health es seleccionar Todos los servicios y escribir
resource health en el cuadro de texto de filtro. En el panel Ayuda y soporte técnico,
seleccione Resource Health .

Pasos siguientes
Consulte estas referencias para obtener más información sobre Resource Health:

Tipos de recursos y comprobaciones de estado en Azure Resource Health

Anotaciones de estado de máquina virtual de Resource Health
Preguntas más frecuentes sobre Azure Resource Health
Actualización del portal de Azure
Service Health
Artículo • 12/08/2023

Estamos actualizando la experiencia del portal de Azure Service Health. La nueva

experiencia permite a los usuarios interactuar con eventos de servicio y administrar
acciones para mantener la continuidad empresarial de las aplicaciones afectadas.

La nueva experiencia se implementará en fases. Algunos usuarios verán la experiencia

actualizada, mientras que otros seguirán viendo la experiencia clásica del portal de
Service Health. En la nueva experiencia, puede seleccionar **Cambiar a clásico** para
volver a la experiencia anterior.

Algunos de los aspectos destacables de la

nueva experiencia

Hoja Alertas de estado

La hoja Alertas de estado se ha actualizado para mejorar la facilidad de uso. Los usuarios
pueden buscar y ordenar su regla de alertas por nombre. Los usuarios también pueden
agrupar sus reglas de alerta por suscripción y estado.
 

En la nueva experiencia actualizada de alertas de estado, los usuarios pueden hacer clic
en su regla de alertas para obtener más detalles y ver su historial de activación de
alertas.

７ Nota

Se retirará la experiencia clásica de la hoja Alertas de estado. Los usuarios no

podrán volver de la nueva experiencia una vez que se implemente.

Vista de nivel de inquilino

Los usuarios con acceso de administrador de inquilinos ahora pueden ver eventos en el
ámbito del inquilino. Las hojas Problemas de servicio, Avisos de mantenimiento, Avisos
de seguridad e Historial de estado se actualizan para mostrar eventos en los niveles de
inquilino y suscripción.
 

Filtrado y ordenación

Los usuarios pueden filtrar por el ámbito (inquilino o suscripción) en las hojas. La
columna de ámbito indica cuándo está un evento en el nivel de inquilino o de
suscripción. La vista clásica no admite eventos de nivel de inquilino. Los eventos de nivel
de inquilino solo están disponibles en la nueva interfaz de usuario.

Mapa mejorado

La hoja de Problemas de servicio muestra una versión mejorada del mapa con todos los
servicios de usuario del mundo. Esta versión le ayuda a encontrar servicios que podrían
verse afectados por una interrupción fácilmente.
Detalles de problemas

Se ha actualizado el aspecto de los detalles de los temas para mejorar su legibilidad.

Eliminación del panel personalizado

Los usuarios ya no pueden anclar un mapa personalizado al panel de control. Esta

característica ha quedado en desuso en la nueva experiencia.

Próximamente
Las siguientes interfaces de usuario se actualizan a la nueva experiencia.

＂ Mantenimiento planeado
Introducción a la experiencia clásica del
Portal de Service Health
Artículo • 01/06/2023

El portal de Service Health forma parte del servicio Service Health. El portal
proporciona un panel personalizable que realiza un seguimiento del estado de los
servicios de Azure en las regiones donde los use. En este panel, puede realizar el
seguimiento de eventos activos, como problemas de servicio, próximos mantenimientos
planeados o avisos de estado relevantes. Cuando los eventos se vuelven inactivos, se
colocan en el historial de estado durante 90 días. Por último, puede usar el panel de
Service Health para crear y administrar las alertas de estado de servicio que
proactivamente le notifican cuando los problemas del servicio le afectan.

En este artículo se explica la experiencia clásica del Portal. El portal está en proceso de
actualización a una nueva interfaz de usuario. Algunos usuarios verán la experiencia
siguiente. Otros verán la experiencia actualizada del portal de servicio de Health.

Eventos de Service Health

El portal de Service Health realiza un seguimiento de cuatro tipos de eventos de
mantenimiento que pueden afectar a los recursos:

1. Problemas de servicios: problemas en los servicios de Azure que le afectan ahora

mismo.
2. Mantenimiento planeado: próximas acciones de mantenimiento que pueden
afectar a la disponibilidad de los servicios en el futuro.
3. Avisos de estado: cambios en los servicios de Azure que requieren su atención.
Algunos ejemplos son el desuso de las características de Azure o los requisitos de
actualización (por ejemplo, la actualización a un marco PHP compatible).
4. Avisos de seguridad: infracciones o notificaciones relacionadas con la seguridad
que pueden afectar a la disponibilidad de los servicios de Azure.

７ Nota

Para ver los eventos de Service Health, a los usuarios se les debe conceder el rol de
lector en una suscripción.

Introducción al portal de Service Health

Para iniciar el panel de Service Health, seleccione el icono de Service Health en el panel
del portal. Si previamente ha quitado el icono o si está usando el panel personalizado,
busque el servicio Service Health en "Más servicios" (parte inferior izquierda del panel).

Consulta de los problemas actuales que afectan

a los servicios
La vista Problemas del servicio muestra los problemas en curso en servicios de Azure
que afectan a los recursos. Puede saber cuándo se inició el problema y qué servicios y
regiones se ven afectados. También puede leer la actualización más reciente para
entender lo que está haciendo Azure para resolver el problema.
 

Elija la pestaña Posible impacto para ver la lista específica de sus propios recursos a los
que podría afectar el problema. Puede descargar una lista CSV de estos recursos para
compartirla con su equipo.

Visualización de problemas emergentes que

podrían afectar sus servicios
Existen situaciones en las que se pueden publicar problemas de servicio generalizados
en la página de estado de Azure antes de que las comunicaciones de destino se
puedan enviar a los clientes afectados. Para asegurarse de que Azure Service Health
proporciona una vista completa de los problemas que pueden afectar al usuario, los
problemas activos de la página de estado de Azure aparecen en Service Health como
problemas emergentes. Cuando un evento está activo en la página de estado de Azure,
se muestra un banner de problemas emergentes en Service Health. Haga clic en el
banner para ver todos los detalles del problema.

Obtención de vínculos y explicaciones

descargables
Puede obtener un vínculo para el problema para que se use el su sistema de
administración de problemas. También puede descargar el archivo PDF y a veces
archivos CSV para compartir con personas que no tienen acceso a Azure Portal.


Obtención de soporte técnico de Microsoft
Si el recurso se deja en mal estado, incluso después de que se resuelve el problema,
póngase en contacto con el soporte técnico. Use los vínculos de soporte técnico de la
derecha de la página.

Anclaje de un mapa de estado personalizado al

panel
Filtre Service Health para mostrar las suscripciones, regiones y tipos de recursos críticos
para la empresa. Guardar el filtro y ancle un mapa del mundo de estado personalizado
al panel del portal.


Configuración de alertas de estado de servicio
Service Health se integra con Azure Monitor para enviarle alertas al usuario por correo
electrónico, mensajes de texto y notificaciones webhook cuando se vean afectados
recursos críticos. Configure una alerta de registro de actividad para el evento de estado
de servicio adecuado. Enrute esa alerta a las personas adecuadas de la organización
mediante grupos de acciones. Para más información, consulte Creación de alertas de
registro de actividad en notificaciones del servicio.
https://www.microsoft.com/es-es/videoplayer/embed/RE2OaXt?
postJsllMsg=true&autoCaptions=es-es

Pasos siguientes
Configure alertas de forma que se le notifiquen los problemas de estado. Para más
información, vea el vídeo sobre los procedimientos recomendados para configurar
alertas de Azure Service Health .
Creación de alertas del registro de
actividad en notificaciones del servicio
mediante Azure Portal
Artículo • 01/06/2023

En este artículo se explica cómo usar Azure Portal para configurar las alertas del registro
de actividad para las notificaciones de mantenimiento de un servicio mediante Azure
Portal.

Las notificaciones de mantenimiento del servicio se almacenan en el registro de

actividad de Azure. Debido al gran volumen de información almacenada en el registro
de actividad, existe una interfaz de usuario independiente que facilita la visualización y
la configuración de alertas en las notificaciones de mantenimiento del servicio.

Puede recibir una alerta cuando Azure envía notificaciones de estado del servicio a la
suscripción de Azure. Puede configurar la alerta en función de:

La clase de notificación de estado del servicio (problemas de servicio,

mantenimiento planificado, avisos de estado y avisos de seguridad).
La suscripción afectada.
Los servicios afectados.
Las regiones afectadas.

７ Nota

Las notificaciones de estado del servicio no envían alertas para los eventos de
estado de los recursos.

También puede configurar a quién se debe enviar la alerta:

Seleccione un grupo de acciones existente.

Cree un nuevo grupo de acciones (que puede usarse para futuras alertas).

Para más información sobre los grupos de acciones, consulte Creación y administración
de grupos de acciones.

Para obtener información sobre cómo configurar las alertas de notificación de

mantenimiento del servicio mediante plantillas de Azure Resource Manager, consulte
Plantillas de Resource Manager.
Ver un vídeo sobre cómo configurar su primera
alerta de Azure Service Health
https://www.microsoft.com/es-es/videoplayer/embed/RE2OaXt?
postJsllMsg=true&autoCaptions=es-es

Creación de una alerta de Service Health

mediante Azure Portal
1. En el portal , seleccione Estado del servicio.

2. En la sección Alertas, seleccione Alertas de estado.

 3. Seleccione Añadir alerta de Service Health.

4. El Asistente para crear una regla de alertas se abre en la pestaña Condiciones,

con la pestaña Ámbito ya rellenada. Siga los pasos para alertas de Service Health
de la pestaña Condiciones, en el Asistente para crear una regla de alertas.

Obtenga información acerca de cómo configurar notificaciones de webhook para los

sistemas de administración de problemas existentes. Para obtener información sobre el
esquema de webhook para las alertas del registro de actividad, consulte Webhooks para
alertas del registro de actividad de Azure.

Pasos siguientes
Obtenga información sobre los procedimientos recomendados para la
configuración de alertas de Azure Service Health .
Obtenga información sobre cómo configurar notificaciones de inserción móviles
de Azure Service Health .
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre la Limitación del número de notificaciones.
Revise el Esquema de webhook de alertas del registro de actividad.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo
puede recibir alertas.
Más información sobre los grupos de acciones.
Visualización de las notificaciones de
mantenimiento del servicio mediante
Azure Portal
Artículo • 26/10/2023

Las notificaciones de mantenimiento del servicio se publican mediante la infraestructura

de Azure en el registro de actividad de Azure. Las notificaciones contienen información
acerca de los recursos en la suscripción. Debido al volumen posiblemente grande de la
información almacenada en el registro de actividad, hay una interfaz de usuario
independiente que facilita la visualización y la configuración de alertas en las
notificaciones de mantenimiento del servicio.

En función de la clase, las notificaciones de mantenimiento del servicio pueden ser

meramente informativas o pueden requerir acciones.

Para obtener más información sobre las distintas clases de notificaciones de

mantenimiento del servicio, vea Propiedades de las notificaciones de Service Health.

Visualización de las notificaciones de

mantenimiento del servicio en Azure Portal
1. En Azure Portal , seleccione Supervisión.

Azure Monitor se abre junto con toda la configuración de supervisión y los datos
en una sola vista consolidada. Primero se abre la sección Registro de actividades .

2. Seleccione Estado del servicio.

3. Seleccione +Crear o agregar alerta del registro de actividad y configure una alerta
para asegurarse de que se le notificarán para futuras notificaciones de servicio.
Para más información, consulte Creación de alertas del registro de actividad en
notificaciones del servicio.

Pasos siguientes
Más información sobre las alertas del registro de actividad.
Acceso elevado para ver avisos de
seguridad
Artículo • 19/10/2023

En este artículo se detalla un próximo cambio que requiere que los usuarios obtengan
roles de acceso elevados para ver los detalles del aviso de seguridad en Azure Service
Health.

¿Qué son los avisos de seguridad?

Los clientes de Azure usan Service Health para mantenerse informados sobre los
eventos de seguridad que afectan a sus aplicaciones empresariales críticas y no críticas.
Las notificaciones de eventos de seguridad se muestran en Azure Service Health en la
hoja Avisos de seguridad. Los detalles importantes del aviso de seguridad se muestran
en tres pestañas: Resumen, Recursos afectados y Novedades de problemas.

Quién pueden ver avisos de seguridad?

Los avisos de seguridad se muestran a los usuarios en el nivel de suscripción o inquilino.
Usuarios con el rol lector de suscripciones o superior; puede ver los detalles de aviso de
seguridad en las pestañas Resumen y actualización de problemas. Los usuarios con roles
de inquilino que aparecen aquí también pueden acceder a los detalles de aviso de
seguridad de nivel de inquilino en las pestañas Resumen y Actualización de problemas.
¿Qué son los recursos afectados dentro de los
avisos de seguridad?
En 2023, se introdujo la pestaña Recursos afectados para eventos de aviso de seguridad.
Dado que los detalles que se muestran en esta pestaña son confidenciales, se requiere
acceso basado en roles (RBAC) para los clientes que ven los recursos afectados por la
seguridad a través de la interfaz de usuario o la API. Revise este artículo para obtener
más información sobre los requisitos actuales de RBAC para acceder a los recursos
afectados por la seguridad.

７ Nota

Las capturas de pantalla anteriores reflejan la experiencia de RBAC para los avisos
de seguridad a partir de hoy.

¿Qué está cambiando en avisos de seguridad?

En el futuro, el acceso a avisos de seguridad requerirá acceso elevado en las pestañas
Resumen, Recursos afectados y Problema Novedades. Los usuarios que tienen acceso de
lector de suscripciones o roles de inquilino en el ámbito del inquilino no podrán ver los
detalles de aviso de seguridad hasta que obtengan los roles necesarios.

1. En el portal de Service Health

Se mostrará un banner a los usuarios hasta abril de 2024 en las pestañas Resumen y
Problema Novedades que solicitan a los clientes que obtengan los roles adecuados para
ver estas pestañas en el futuro.

Después de abril de 2024, se mostrará un mensaje de error en las pestañas Resumen y

Problema Novedades a los usuarios que no tengan los siguientes roles necesarios:

Nivel de suscripción

Propietario de la suscripción
Subscription Admin
Roles personalizados con permisos
Microsoft.ResourceHealth/events/fetchEventDetails/action o
Microsoft.ResourceHealth/events/action

Nivel de inquilino

Lector de seguridad Administración/Seguridad

Administración global de Administración/inquilino
Roles personalizados con permisos
Microsoft.ResourceHealth/events/fetchEventDetails/action o
Microsoft.ResourceHealth/events/action

2. Cambios en la API de Service Health

Los usuarios de la API de eventos deberán actualizar su código para usar el nuevo
punto de conexión de ARM (/fetchEventDetails) para recibir detalles de notificación de
avisos de seguridad. Si los usuarios tienen los roles mencionados anteriormente, pueden
ver los detalles del evento de un evento específico con el nuevo punto de conexión. El
punto de conexión existente (/events) que devuelve todos los tipos de eventos de
Service Health que afectan a una suscripción o inquilino, ya no devolverá detalles de
notificación de seguridad confidenciales. Esta actualización se realizará en la versión de
API 2023-10-01-preview y versiones futuras.

Los puntos de conexión nuevos y existentes enumerados a continuación devolverán los

detalles de notificación de seguridad de un evento específico.

Nuevos detalles del punto de conexión de API

Para acceder al nuevo punto de conexión siguiente, los usuarios deben estar
autorizados con los roles mencionados anteriormente.
Este punto de conexión devolverá el objeto de evento con todas las propiedades
disponibles para un evento específico.
Esto es como el punto de conexión de recursos afectado a continuación.
Disponible desde la versión de API 2022-10-01

Los

HTTP

https://management.azure.com/subscriptions/227b734f-e14f-4de6-b7fc-
3190c21e69f6/providers/microsoft.ResourceHealth/events/{trackingId}/fetchEve
ntDetails?api-version=2023-10-01-preview

Operación: POST

Recursos afectados para avisos de seguridad

Los clientes autorizados con los roles mencionados anteriormente pueden usar los
siguientes puntos de conexión para acceder a la lista de recursos afectados por un
incidente de seguridad.
Disponible desde la versión de API 2022-05-01

Suscripción

HTTP

https://management.azure.com/subscriptions/4970d23e-ed41-4670-9c19-
02a1d2808ff9/providers/microsoft.resourcehealth/events/{trackingId}/listSecu
rityAdvisoryImpactedResources?api-version=2023-10-01-preview

Operación: POST
Inquilino

HTTP

https://management.azure.com/providers/microsoft.resourcehealth/events/{trac
kingId}/listSecurityAdvisoryImpactedResources?api-version=2023-10-01-preview

Operación: POST

Punto de conexión de API de eventos existentes

Eventos de lista de suscripciones de avisos de seguridad

Con la versión de API 2023-10-01-preview (y versiones futuras de api), el punto de

conexión de la API de eventos existente que devuelve la lista de eventos (incluidos los
eventos de seguridad con eventType: "Seguridad") se restringirá para pasar solo las
propiedades que no distinguen las que se enumeran a continuación para los eventos de
seguridad.

HTTP

https://management.azure.com/subscriptions/227b734f-e14f-4de6-b7fc-
3190c21e69f6/providers/microsoft.ResourceHealth/events?api-version=2023-10-
01-preview&$filter= "eventType eq SecurityAdvisory"

Operación: GET

Los siguientes elementos de la respuesta del objeto de eventos se rellenarán para

eventos de avisos de seguridad mediante este punto de conexión:

Identificador
name
type
nextLink
properties

Solo se rellenarán los siguientes elementos en el objeto properties:

eventType
eventSource
status
title
platformInitiated
Nivel
 eventLevel
isHIR
priority
subscriptionId
lastUpdateTime
impacto

La propiedad impactedService se rellenará para el objeto de impacto, pero solo se

rellenarán las siguientes propiedades del objeto impactedServiceRegion en el objeto de
impacto:

impactedService
impactedSubscriptions
impactedTenants
impactedRegion
status

Pasos siguientes
Manténgase informado sobre los eventos de seguridad de Azure
Introducción a Azure Resource Health
Preguntas más frecuentes sobre Azure Resource Health
Uso de un webhook para configurar las
notificaciones relativas al estado en
sistemas de administración de
problemas
Artículo • 01/06/2023

En este artículo se muestra cómo configurar las alertas de Azure Service Health para que
envíen datos a través de webhooks a un sistema de notificación existente.

Puede configurar las alertas de Service Health para que reciba una notificación,
mediante mensaje de texto o correo electrónico, cuando se produzca algún incidente
que le afecte en algún servicio de Azure.

Pero también es posible que tenga implementado un sistema de notificación externo y

prefiera utilizarlo. En este artículo se identifican las partes más importantes de la carga
del webhook. También se describe cómo crear alertas personalizadas que envíen una
notificación en cuanto se produzca algún problema significativo en un servicio.

Si desea usar una integración preconfigurada, consulte:

Configure alerts with ServiceNow (Configuración de alertas con ServiceNow)

Configure alerts with PagerDuty (Configuración de alertas con PagerDuty)
Configure alerts with OpsGenie (Configuración de alertas con OpsGenie)

Vea un vídeo introductorio:

https://www.microsoft.com/es-es/videoplayer/embed/RE2OtUV?
postJsllMsg=true&autoCaptions=es-es

Configuración de una notificación

personalizada mediante la carga del webhook
de Service Health
Para configurar su propia integración de webhook personalizada, es preciso que analice
la carga JSON que se envía en las notificaciones de Service Health.

Vea un ejemplo de la carga del webhook de ServiceHealth .

Para confirmar que se trata de una alerta de Service Health examine

context.eventSource == "ServiceHealth" . Las siguientes propiedades son las más
importantes:

data.context.activityLog.status
data.context.activityLog.level
data.context.activityLog.subscriptionId
data.context.activityLog.properties.title
data.context.activityLog.properties.impactStartTime
data.context.activityLog.properties.communication
data.context.activityLog.properties.impactedServices
data.context.activityLog.properties.trackingId

Creación de un vínculo al panel de Service

Health en caso de algún incidente
Para crear un vínculo directo al panel de Service Health en cualquier escritorio o
dispositivo móvil, genere una dirección URL especializada. Use trackingId y los tres
primeros y últimos dígitos de subscriptionId con este formato:

https://app.azure.com/h/ <trackingId>/<tres primeros y tres últimos dígitos de

subscriptionId>

Por ejemplo, si subscriptionId es bba14129-e895-429b-8809-278e836ecdb3 y trackingId

es 0DET-URB, la dirección URL del Service Health es:

https://app.azure.com/h/0DET-URB/bbadb3

Uso de level para detectar la gravedad del

problema
De menor a mayor gravedad, la propiedadlevel de la carga puede tener los siguientes
valores: Informational (Información), Warning (Advertencia), Error o Critical (Crítico).

Análisis de los servicios afectados para

determinar el ámbito del incidente
Las alertas de Service Health pueden informar acerca de los problemas que aparecen en
varias regiones y servicios. Para obtener todos los detalles, es preciso analizar el valor de
impactedServices .
El contenido interior es una cadena con caracteres de escape JSON que, cuando no
tiene caracteres de escape, contiene otro objeto JSON que puede analizarse
regularmente. Por ejemplo:

JSON

{"data.context.activityLog.properties.impactedServices": "
[{\"ImpactedRegions\":[{\"RegionName\":\"Australia East\"},
{\"RegionName\":\"Australia Southeast\"}],\"ServiceName\":\"Alerts &
Metrics\"},{\"ImpactedRegions\":[{\"RegionName\":\"Australia
Southeast\"}],\"ServiceName\":\"App Service\"}]"}

se convierte en:

JSON

[
{
"ImpactedRegions":[
{
"RegionName":"Australia East"
},
{
"RegionName":"Australia Southeast"
}
],
"ServiceName":"Alerts & Metrics"
},
{
"ImpactedRegions":[
{
"RegionName":"Australia Southeast"
}
],
"ServiceName":"App Service"
}
]

En este ejemplo se muestran los problemas de:

"Alertas y métricas" en las regiones Este de Australia y Sudeste de Australia.

"App Service" en la región Sudeste de Australia.

Prueba de la integración de un webhook a

través de una solicitud HTTP POST
Siga estos pasos:
 1. Cree la carga de Service Health que desee enviar. Puede ver una carga del
webhook de Service Health de ejemplo en Webhooks para alertas del registro de
actividad de Azure.

2. Cree una solicitud HTTP POST de la siguiente manera:

POST https://your.webhook.endpoint

HEADERS Content-Type: application/json

BODY <service health payload>

Debería recibir la respuesta "2XX - Successful".

3. Vaya a PagerDuty para confirmar que la integración se ha configurado

correctamente.

Pasos siguientes
Revise el Esquema de webhook de alertas del registro de actividad.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre los grupos de acciones.
Envío de alertas de Azure Service Health
con ServiceNow mediante webhooks
Artículo • 01/06/2023

Este artículo muestra cómo integrar las alertas de estado del servicio de Azure con
ServiceNow mediante un webhook. Después de configurar la integración de webhook
con su instancia de ServiceNow, obtendrá alertas a través de la infraestructura de
notificación existente cuando le afecten los problemas de servicio de Azure. Cada vez
que se genera una alerta de Azure Service Health, se llama a un webhook mediante la
API REST con script de ServiceNow.

Creación de una API de REST con script en

ServiceNow
1. Asegúrese de que se ha registrado y ha iniciado sesión en su cuenta de
ServiceNow .

2. Vaya hasta la sección System Web Services (Servicios web del sistema) en
ServiceNow y seleccione Scripted REST APIs (API de REST con script).

3. Seleccione New (Nuevo) para crear un nuevo servicio de REST con script.

4. Agregue un nombre a la API de REST y establezca el identificador de la API en

azureservicehealth .

5. Seleccione Submit (Enviar).

6. Seleccione la API de REST que creó, y, en la pestaña Resources (Recursos),
seleccione New (Nuevo).

7. Nombre el nuevo recurso event y cambie el método HTTP a POST .

8. En la sección Script, agregue el siguiente código JavaScript:

７ Nota

Debe actualizar los valores <secret> , <group> y <email> en el siguiente script.

<secret> debe ser una cadena aleatoria, como un GUID.

<group> debe ser el grupo de ServiceNow al que desea asignar el

incidente.
<email> debe ser la persona específica a la que desea asignar el

incidente (opcional).

JavaScript
(function process( /*RESTAPIRequest*/ request, /*RESTAPIResponse*/
response) {
var apiKey = request.queryParams['apiKey'];
var secret = '<secret>';
if (apiKey == secret) {
var event = request.body.data;
var responseBody = {};
if (event.data.context.activityLog.operationName ==
'Microsoft.ServiceHealth/incident/action') {
var inc = new GlideRecord('incident');
var incidentExists = false;
inc.addQuery('number',
event.data.context.activityLog.properties.trackingId);
inc.query();
if (inc.hasNext()) {
incidentExists = true;
inc.next();
} else {
inc.initialize();
}
var short_description = "Azure Service Health";
if (event.data.context.activityLog.properties.incidentType
== "Incident") {
short_description += " - Service Issue - ";
} else if
(event.data.context.activityLog.properties.incidentType ==
"Maintenance") {
short_description += " - Planned Maintenance - ";
} else if
(event.data.context.activityLog.properties.incidentType ==
"Informational" ||
event.data.context.activityLog.properties.incidentType ==
"ActionRequired") {
short_description += " - Health Advisory - ";
}
short_description +=
event.data.context.activityLog.properties.title;
inc.short_description = short_description;
inc.description =
event.data.context.activityLog.properties.communication;
inc.work_notes = "Impacted subscription: " +
event.data.context.activityLog.subscriptionId;
if (incidentExists) {
if (event.data.context.activityLog.properties.stage ==
'Active') {
inc.state = 2;
} else if
(event.data.context.activityLog.properties.stage == 'Resolved') {
inc.state = 6;
} else if
(event.data.context.activityLog.properties.stage == 'Closed') {
inc.state = 7;
}
inc.update();
 responseBody.message = "Incident updated.";
} else {
inc.number =
event.data.context.activityLog.properties.trackingId;
inc.state = 1;
inc.impact = 2;
inc.urgency = 2;
inc.priority = 2;
inc.assigned_to = '<email>';
inc.assignment_group.setDisplayValue('<group>');
var subscriptionId =
event.data.context.activityLog.subscriptionId;
var comments = "Azure portal Link:
https://app.azure.com/h";
comments += "/" +
event.data.context.activityLog.properties.trackingId;
comments += "/" + subscriptionId.substring(0, 3) +
subscriptionId.slice(-3);
var impactedServices =
JSON.parse(event.data.context.activityLog.properties.impactedServices);
var impactedServicesFormatted = "";
for (var i = 0; i < impactedServices.length; i++) {
impactedServicesFormatted +=
impactedServices[i].ServiceName + ": ";
for (var j = 0; j <
impactedServices[i].ImpactedRegions.length; j++) {
if (j != 0) {
impactedServicesFormatted += ", ";
}
impactedServicesFormatted +=
impactedServices[i].ImpactedRegions[j].RegionName;
}

impactedServicesFormatted += "\n";

}
comments += "\n\nImpacted Services:\n" +
impactedServicesFormatted;
inc.comments = comments;
inc.insert();
responseBody.message = "Incident created.";
}
} else {
responseBody.message = "Hello from the other side!";
}
response.setBody(responseBody);
} else {
var unauthorized = new sn_ws_err.ServiceError();
unauthorized.setStatus(401);
unauthorized.setMessage('Invalid apiKey');
response.setError(unauthorized);
}
})(request, response);
 9. En la pestaña de seguridad, desactive la opción Requires authentication (Requiere
autenticación) y seleccione Submit (Enviar). El <secret> establecido protege esta
API.

10. Si volvemos a la sección Scripted REST APIs (API de REST con script), debe
encontrar la ruta de la API base para la nueva API de REST:

11. La dirección URL completa de integración tiene el siguiente aspecto:

HTTP

https://<yourInstanceName>.service-now.com/<baseApiPath>?apiKey=
<secret>

Creación de una alerta con ServiceNow en

Azure Portal

Para un nuevo grupo de acciones:

1. Siga los pasos del 1 al 8 en este artículo para crear una alerta con un nuevo grupo
de acciones.
 2. Defina la lista de acciones:

a. Tipo de acción: webhook

b. Detalles: la dirección URL de integración de ServiceNow guardada

anteriormente.

c. Nombre: el identificador, alias o nombre de webhook.

3. Seleccione Guardar cuando termine para crear la alerta.

Para un grupo de acciones existentes:

1. En Azure Portal , seleccione Supervisión.

2. En la sección Configuración, seleccione Grupos de acciones.

3. Busque el grupo de acciones que desee editar.

4. Defina la lista de acciones:

a. Tipo de acción: webhook

b. Detalles: la dirección URL de integración de ServiceNow guardada

anteriormente.

c. Nombre: el identificador, alias o nombre de webhook.

5. Cuando termine de actualizar el grupo de acciones, seleccione Guardar.

Prueba de la integración de webhook a través

de una solicitud HTTP POST
1. Cree la carga de estado del servicio que desee enviar. Puede encontrar una carga
de webhook de estado del servicio de ejemplo en Webhooks para alertas del
registro de actividad de Azure.

2. Cree una solicitud HTTP POST de la siguiente manera:

POST https://<yourInstanceName>.service-now.com/<baseApiPath>?
apiKey=<secret>

HEADERS Content-Type: application/json

 BODY <service health payload>

3. Debe recibir una respuesta 200 OK con el mensaje "Incident created" (Incidente
creado).

4. Vaya a ServiceNow para confirmar que la integración se ha configurado

correctamente.

Pasos siguientes
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Revise el Esquema de webhook de alertas del registro de actividad.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre los grupos de acciones.
Envío de alertas de Azure Service Health
con PageDuty mediante webhooks
Artículo • 26/10/2023

Este artículo muestra cómo configurar las notificaciones de estado del servicio de Azure
con PagerDuty mediante un webhook. Mediante el tipo de integración de Microsoft
Azure personalizado de PagerDuty , puede agregar fácilmente alertas de estado del
servicio a los servicios de PagerDuty nuevos o existentes.

Creación de una dirección URL de integración

de estado del servicio en PagerDuty
1. Asegúrese de que se ha registrado y ha iniciado sesión en su cuenta de
PagerDuty .

2. Vaya hasta la sección Services (Servicios) en PagerDuty.

3. Seleccione Add New Service (Agregar nuevo servicio) o abra un servicio existente
que haya configurado.

4. En Integration Settings (Configuración de la integración), seleccione lo siguiente:

a. Integration Type (Tipo de integración): Microsoft Azure

b. Integration Name (Nombre de integración): <nombre>

 5. Rellene los demás campos obligatorios y seleccione Add (Agregar).

6. Abra esta nueva integración y copie y guarde la dirección URL de la integración.

Creación de una alerta con PagerDuty en Azure

Portal

Para un nuevo grupo de acciones:

1. Siga los pasos del 1 al 8 en Creación de una alerta basada en una notificación de
mantenimiento del servicio para un nuevo grupo de acciones con Azure Portal.

2. Defina la lista de acciones:

a. Tipo de acción: webhook

b. Detalles: la dirección URL de integración de OpsGenie guardada anteriormente.

c. Nombre: el identificador, alias o nombre de webhook.

3. Seleccione Guardar cuando termine para crear la alerta.

Para un grupo de acciones existentes:

1. En Azure Portal , seleccione Supervisión.
 2. En la sección Configuración, seleccione Grupos de acciones.

3. Busque el grupo de acciones que desee editar.

4. Defina la lista de acciones:

a. Tipo de acción: webhook

b. Detalles: la dirección URL de integración de OpsGenie guardada anteriormente.

c. Nombre: el identificador, alias o nombre de webhook.

5. Cuando termine de actualizar el grupo de acciones, seleccione Guardar.

Prueba de la integración de webhook a través

de una solicitud HTTP POST
1. Cree la carga de estado del servicio que desee enviar. Puede encontrar una carga
de webhook de estado del servicio de ejemplo en Webhooks para alertas del
registro de actividad de Azure.

2. Cree una solicitud HTTP POST de la siguiente manera:

POST
https://events.pagerduty.com/integration/<IntegrationKey>/enqueue

HEADERS Content-Type: application/json

BODY <service health payload>

3. Debería recibir 202 Accepted con un mensaje que contiene el "identificador del
evento."

4. Vaya a PagerDuty para confirmar que la integración se ha configurado

correctamente.

Pasos siguientes
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Revise el Esquema de webhook de alertas del registro de actividad.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre los grupos de acciones.
Envío de alertas de Azure Service Health
con OpsGenie mediante webhooks
Artículo • 01/06/2023

Este artículo muestra cómo configurar las alertas de estado del servicio de Azure con
OpsGenie mediante un webhook. Mediante el uso de la integración del estado del
servicio de Azure de OpsGenie puede reenviar alertas de estado del servicio de Azure
a OpsGenie. OpsGenie puede determinar las personas adecuadas a las que enviar la
notificación según las programaciones de entrega mediante correo electrónico,
mensajes de texto (SMS), llamadas de teléfono, notificaciones de inserción de iOS y
Android y la escalación de alertas hasta que la alerta se confirma o se cierra.

Creación de una dirección URL de integración

de estado del servicio en OpsGenie
1. Asegúrese de que se ha registrado y ha iniciado sesión en su cuenta de
OpsGenie .

2. Vaya a la sección Integrations (Integraciones) en OpsGenie.

3. Seleccione el botón de integración Azure Service Health (Estado del servicio de

Azure).
 4. Nombre la alerta y especifique el campo Asignado al equipo.

5. Rellene los demás campos como Recipients (Destinatarios), Enabled (Habilitado) y

Suppress Notifications (Suprimir notificaciones).

6. Copie y guarde la dirección URL, ya que debe contener la apiKey anexada al final.

7. Seleccione Save Integration (Guardar integración).

Creación de una alerta con OpsGenie en Azure

Portal

Para un nuevo grupo de acciones:

1. Siga los pasos del 1 al 8 en Creación de una alerta basada en una notificación de
mantenimiento del servicio para un nuevo grupo de acciones con Azure Portal.

2. Defina la lista de acciones:

a. Tipo de acción: webhook

b. Detalles: la dirección URL de integración de OpsGenie guardada anteriormente.

c. Nombre: el identificador, alias o nombre de webhook.

3. Seleccione Guardar cuando termine para crear la alerta.

Para un grupo de acciones existentes:

1. En Azure Portal , seleccione Supervisión.
 2. En la sección Configuración, seleccione Grupos de acciones.

3. Busque el grupo de acciones que desee editar.

4. Defina la lista de acciones:

a. Tipo de acción: webhook

b. Detalles: la dirección URL de integración de OpsGenie guardada anteriormente.

c. Nombre: el identificador, alias o nombre de webhook.

5. Cuando termine de actualizar el grupo de acciones, seleccione Guardar.

Prueba de la integración de webhook a través

de una solicitud HTTP POST
1. Cree la carga de estado del servicio que desee enviar. Puede encontrar una carga
de webhook de estado del servicio de ejemplo en Webhooks para alertas del
registro de actividad de Azure.

2. Cree una solicitud HTTP POST de la siguiente manera:

POST https://api.opsgenie.com/v1/json/azureservicehealth?apiKey=
<APIKEY>

HEADERS Content-Type: application/json

BODY <service health payload>

3. Debe recibir una respuesta 200 OK con el mensaje de estado "correcto".

4. Vaya a OpsGenie para confirmar que la integración se ha configurado

correctamente.

Pasos siguientes
Obtenga información acerca de cómo configurar notificaciones de webhook para
los sistemas de administración de problemas existentes.
Revise el Esquema de webhook de alertas del registro de actividad.
Más información acerca de las Notificaciones del estado del servicio.
Más información sobre los grupos de acciones.
Creación de alertas de Resource Health
en Azure Portal
Artículo • 13/12/2023

En este artículo se explica cómo configurar las alertas del registro de actividad para las
notificaciones de mantenimiento de un recurso en Azure Portal.

Azure Resource Health le mantiene informado sobre el estado actual y pasado de sus
recursos de Azure. Las alertas de Azure Resource Health pueden notificarle cuando estos
recursos tienen un cambio en su estado de mantenimiento. La creación y la
personalización de alertas mediante programación en Resource Health se puede realizar
en bloque.

Las notificaciones de mantenimiento del recurso se almacenan en el registro de

actividad de Azure. Debido al volumen posiblemente grande de la información
almacenada en el registro de actividad, hay una interfaz de usuario independiente que
facilita la visualización y la configuración de alertas en las notificaciones de
mantenimiento del servicio. Puede recibir una alerta cuando el recurso de Azure envía
notificaciones de mantenimiento del recurso a la suscripción de Azure. Puede configurar
la alerta en función de:

La suscripción afectada.
Los tipos de recursos afectados.
Los grupos de recursos afectados.
Los recursos afectados.
Los estados de evento de los recursos afectados.
Los estados afectados de los recursos.
Los tipos de recursos de los recursos afectados.

También puede configurar a quién se debe enviar la alerta:

Seleccione un grupo de acciones existente.

un nuevo grupo de acciones (que se puede usar para futuras alertas).

Para más información sobre los grupos de acciones, consulte y administre grupos de
acciones.

Para obtener información sobre cómo configurar las alertas de notificación de

mantenimiento del recurso mediante plantillas de Azure Resource Manager, consulte
Plantillas de Resource Manager.
Crear una regla de alerta de Resource Health
en Azure Portal
1. En Azure Portal , seleccione Mantenimiento del servicio.

2. En la sección Estado de los recursos, seleccione Service Health.

3. Seleccione Añadir alerta de Resource Health.

4. Se abre ** un asistente para reglas de alertas** en la pestaña Condiciones , con la

pestaña Ámbito ya rellenada. Siga los pasos de las alertas de Resource Health, a
partir de la pestaña Condiciones , en el asistente para nueva regla de alertas.

Pasos siguientes
Más información sobre Resource Health:

Información general sobre Azure Resource Health

Tipos de recursos y comprobaciones de mantenimiento disponibles a través de
Azure Resource Health

Creación de alertas de Service Health:

Configuración de alertas de Service Health

Esquema de eventos del registro de actividad de Azure
Configuración de alertas de estado de los recursos con plantillas de Resource
Manager
Configuración de alertas de estado de
los recursos con plantillas de Resource
Manager
Artículo • 25/03/2023

En este artículo se muestra cómo crear alertas del registro de actividad de Resource
Health mediante programación con plantillas de Azure Resource Manager y Azure
PowerShell.

Azure Resource Health le mantiene informado sobre el estado actual y pasado de sus
recursos de Azure. Además, le notifica casi en tiempo real de los cambios de estado en
estos recursos. La creación y la personalización de alertas mediante programación en
Resource Health se puede realizar en bloque.

７ Nota

Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure.

Consulte Instalación de Azure PowerShell para empezar. Para más información
sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure
PowerShell de AzureRM a Az.

Prerrequisitos
Para seguir las instrucciones que aparecen en esta página, necesita de antemano
algunas cosas:

1. Debe instalar el módulo de Azure PowerShell

2. Debe crear o volver a usar un grupo de acciones configurado para recibir
notificaciones

Instructions
1. Con PowerShell, inicie sesión en su cuenta de Azure y seleccione la suscripción con
la que desee interactuar

Azure PowerShell

Login-AzAccount
Select-AzSubscription -Subscription <subscriptionId>
 Puede usar Get-AzSubscription para enumerar las suscripciones a las que
tiene acceso.

2. Busque y guarde el identificador completo del grupo de acciones de Azure

Resource Manager

Azure PowerShell

(Get-AzActionGroup -ResourceGroupName <resourceGroup> -Name

<actionGroup>).Id

3. Cree y guarde una plantilla de Resource Manager para las alertas de Resource
Health como resourcehealthalert.json (consulte los detalles a continuación)

4. Cree una nueva implementación de Azure Resource Manager con esta plantilla

Azure PowerShell

New-AzResourceGroupDeployment -Name ExampleDeployment -

ResourceGroupName <resourceGroup> -TemplateFile
<path\to\resourcehealthalert.json>

5. Se le pedirá que escriba el nombre de la alerta y el identificador de recurso del

grupo de acciones que copió anteriormente:

Azure PowerShell

Supply values for the following parameters:

(Type !? for Help.)
activityLogAlertName: <Alert Name>
actionGroupResourceId:
/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/provider
s/microsoft.insights/actionGroups/<actionGroup>

6. Si todo fue bien, recibirá una confirmación en PowerShell

Resultados

DeploymentName : ExampleDeployment
ResourceGroupName : <resourceGroup>
ProvisioningState : Succeeded
Timestamp : 11/8/2017 2:32:00 AM
Mode : Incremental
TemplateLink :
Parameters :
 Name Type Value
=============== ========= ==========
activityLogAlertName String <Alert
Name>
activityLogAlertEnabled Bool True
actionGroupResourceId String /...

Outputs :
DeploymentDebugLogLevel :

Tenga en cuenta que si planea automatizar completamente este proceso, basta con
editar la plantilla de Resource Manager para que no solicite los valores del paso 5.

Opciones de la plantilla de Resource Manager

para las alertas de Resource Health
Para crear alertas de Resource Health puede usar esta plantilla base como punto de
partida. Esta plantilla funcionará como se escriba y le permitirá recibir alertas de todos
los eventos de estado de recurso que se activen a partir de ese momento en los
recursos de una suscripción.

En la parte inferior de este artículo hemos incluido también una plantilla de alerta
más compleja que debe aumentar la relación señal/ruido de las alertas de Resource
Health en comparación con esta plantilla.

JSON

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"activityLogAlertName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the
Activity log alert."
}
},
"actionGroupResourceId": {
"type": "string",
"metadata": {
"description": "Resource Id for the Action group."
}
}
},
"resources": [
 {
"type": "Microsoft.Insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlertName')]",
"location": "Global",
"properties": {
"enabled": true,
"scopes": [
"[subscription().id]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "ResourceHealth"
},
{
"field": "status",
"equals": "Active"
}
]
},
"actions": {
"actionGroups":
[
{
"actionGroupId": "[parameters('actionGroupResourceId')]"
}
]
}
}
}
]
}

Sin embargo, una alerta amplia como esta no suele ser recomendable. Aprenda a
reducir el ámbito para que la alerta se centre en los eventos que nos importan a
continuación.

Ajuste del ámbito de alerta

Las alertas de Resource Health se pueden configurar para supervisar eventos en tres
ámbitos distintos:

A nivel de suscripción
A nivel de grupo de recursos
A nivel de recurso

La plantilla de alerta se configura a nivel de suscripción, pero si desea configurarla para

que solo se notifiquen determinados recursos o recursos de un determinado grupo,
basta con modificar la sección scopes en la anterior plantilla.

Para un ámbito a nivel de grupo de recursos, la sección de ámbito tiene este aspecto:

JSON

"scopes": [
"/subscriptions/<subscription id>/resourcegroups/<resource group>"
],

Para un ámbito a nivel de recurso, la sección de ámbito tiene este aspecto:

JSON

"scopes": [
"/subscriptions/<subscription id>/resourcegroups/<resource
group>/providers/<resource>"
],

Por ejemplo: "/subscriptions/d37urb3e-ed41-4670-9c19-

02a1d2808ff9/resourcegroups/myRG/providers/microsoft.compute/virtualmachines/myVm"

Puede ir a Azure Portal y observar la dirección URL del recurso de Azure para
obtener esta cadena.

Ajuste de los tipos de recursos con alertas

Las alertas a nivel de suscripción o de grupo de recursos tienen distintos tipos de
recursos. Si desea limitar las alertas a las que procedan de un determinado subconjunto
de tipos de recursos, puede definirlo en la sección condition de la plantilla de este
modo:

JSON

"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "resourceType",
"equals": "MICROSOFT.COMPUTE/VIRTUALMACHINES",
"containsAny": null
},
{
"field": "resourceType",
"equals": "MICROSOFT.STORAGE/STORAGEACCOUNTS",
 "containsAny": null
},
...
]
}
]
},

Aquí usamos el contenedor anyOf para permitir que la alerta de estado de recurso
coincida con cualquiera de las condiciones especificadas para las alertas se centren en
determinados tipos de recursos.

Ajuste de los eventos de Resource Health con alerta

Cuando se produce un evento de estado en los recursos, pueden pasar por una serie de
fases que representan el estado del evento: Active , In Progress , Updated y Resolved .

Quizá solo desee recibir notificaciones en caso de que el estado del recurso sea
incorrecto, para lo que querrá configurar la alerta para notificar solo cuando status sea
Active . Sin embargo si desea recibir una notificación también en las otras fases, puede

agregar esos detalles de este modo:

JSON

"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "status",
"equals": "Active"
},
{
"field": "status",
"equals": "In Progress"
},
{
"field": "status",
"equals": "Resolved"
},
{
"field": "status",
"equals": "Updated"
}
]
}
]
}
Si desea recibir una notificación para las cuatro fases de los eventos de estado, elimine
esta condición y la alerta le notificará independientemente de la propiedad status .

７ Nota

Cada sección "anyOf" debe contener solo un valor de tipo de campo.

Ajuste de las alertas de Resource Health para evitar

eventos desconocidos
Azure Resource Health puede notificar el estado más reciente de los recursos gracias a
la constante supervisión mediante ejecutores de pruebas. Los estados de
mantenimiento notificados pertinentes son: "Disponible", "No disponible" y
"Degradado". Sin embargo, en situaciones en las que el ejecutor y el recurso de Azure
no se pueden comunicar, se notifica un estado "Desconocido" para el recurso y que se
considera un evento de estado "Activo".

No obstante, cuando un recurso se notifica como "Desconocido", es probable que su

estado no haya cambiado desde el último informe preciso. Si desea eliminar las alertas
de eventos desconocidos, puede especificar esa lógica en la plantilla:

JSON

"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "properties.currentHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field": "properties.currentHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field": "properties.currentHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
 {
"anyOf": [
{
"field": "properties.previousHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field": "properties.previousHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field": "properties.previousHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
]
},

En este ejemplo, solo se notifican los eventos en los que el estado actual y anterior no
son desconocidos. Este cambio puede resultar útil si las alertas se envían directamente
al correo electrónico o teléfono móvil.

Tenga en cuenta que es posible que las propiedades currentHealthStatus y

previousHealthStatus sean null en algunos eventos. Por ejemplo, cuando se produce un
evento Updated, es probable que el estado de mantenimiento del recurso no haya
cambiado desde el último informe y solo está disponible esa información adicional del
evento (por ejemplo, la causa). Por lo tanto, mediante la cláusula anterior puede
provocar que algunas alertas no se desencadenen, ya que los valores de
properties.currentHealthStatus y properties.previousHealthStatus se establecerán en
null.

Ajuste de la alerta para evitar eventos iniciados por el

usuario
Los eventos de Resource Health se pueden desencadenar mediante eventos iniciados
por la plataforma o por el usuario. Puede que tenga sentido solo enviar una notificación
cuando el evento lo genere la plataforma Azure.

Es fácil de configurar la alerta para filtrar solo estos tipos de eventos:

JSON
 "condition": {
"allOf": [
...,
{
"field": "properties.cause",
"equals": "PlatformInitiated",
"containsAny": null
}
]
}

Tenga en cuenta que es posible que el campo de la causa sea null en algunos eventos.
Es decir, una transición de estado tiene lugar (por ejemplo, pasa de disponible a no
disponible) y el evento se registra inmediatamente a fin de evitar que la notificación se
retrase. Por lo tanto, mediante la cláusula anterior puede provocar que una alerta no se
desencadene, ya que el valor de la propiedad properties.cause se establecerá en null.

Completar la plantilla de alerta de Resource

Health
Con los distintos ajustes que se describen en la sección anterior, a continuación se
muestra una plantilla de muestra configurada para maximizar la relación señal/ruido.
Tenga en cuenta las observaciones que se han indicado anteriormente donde los valores
de las propiedades currentHealthStatus, previousHealthStatus y cause pueden ser null
en algunos eventos.

JSON

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"activityLogAlertName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for
the Activity log alert."
}
},
"actionGroupResourceId": {
"type": "string",
"metadata": {
"description": "Resource Id for the Action group."
}
}
},
 "resources": [
{
"type": "Microsoft.Insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlertName')]",
"location": "Global",
"properties": {
"enabled": true,
"scopes": [
"[subscription().id]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "ResourceHealth",
"containsAny": null
},
{
"anyOf": [
{
"field":
"properties.currentHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field":
"properties.currentHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field":
"properties.currentHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field":
"properties.previousHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field":
"properties.previousHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
 "field":
"properties.previousHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field": "properties.cause",
"equals": "PlatformInitiated",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field": "status",
"equals": "Active",
"containsAny": null
},
{
"field": "status",
"equals": "Resolved",
"containsAny": null
},
{
"field": "status",
"equals": "In Progress",
"containsAny": null
},
{
"field": "status",
"equals": "Updated",
"containsAny": null
}
]
}
]
},
"actions": {
"actionGroups": [
{
"actionGroupId": "
[parameters('actionGroupResourceId')]"
}
]
}
}
}
]
}
Sin embargo, usted conoce mejor las configuraciones que necesita; use las herramientas
que le hemos mostrado en esta documentación para la personalización.

Pasos siguientes
Más información sobre Resource Health:

Información general sobre Azure Resource Health

Tipos de recursos y comprobaciones de mantenimiento disponibles a través de
Azure Resource Health

Creación de alertas de Service Health:

Configuración de alertas de Service Health

Esquema de eventos del registro de actividad de Azure
Use Azure Portal para ver las
notificaciones de mantenimiento del
servicio
Artículo • 26/10/2023

Azure publica las notificaciones de mantenimiento del servicio, que contienen

información acerca de los recursos en la suscripción. Estas notificaciones son una
subclase de los eventos del registro de actividad y también se pueden encontrar en el
registro de actividad. En función de la clase, las notificaciones de mantenimiento del
servicio pueden ser meramente informativas o pueden requerir acciones.

Hay varias clases de las notificaciones de mantenimiento del servicio:

Acción requerida: Azure puede haber observado algo inusual en su cuenta y

trabaja con usted para remediarlo. Azure le envía una notificación en la que se
detallan las acciones que debe realizar o se proporciona información sobre cómo
ponerse en contacto con los equipos de ingeniería o soporte técnico de Azure.
Incidente: uno o varios recursos de la suscripción están resultando afectados por
un evento que tiene repercusiones en el servicio.
Mantenimiento: una actividad de mantenimiento planeado que puede afectar a
uno o varios de los recursos de su suscripción.
Información: posibles optimizaciones que puedan ayudar a mejoran el uso de los
recursos.
Seguridad: información urgente relacionada con la seguridad de las soluciones
que se ejecutan en Azure.

Cada notificación del estado de un servicio incluye datos acerca del ámbito y el impacto
en los recursos. Los detalles incluyen:

Nombre de propiedad Descripción

channels Uno de los siguientes valores: Admin u Operation.

correlationId Normalmente, un GUID en formato de cadena. Los eventos

que pertenecen a la misma acción generalmente suelen
compartir el mismo valor de correlationId.

eventDataId Identificador único de un evento.

eventName Título del evento.

level Nivel de un evento

Nombre de propiedad Descripción

resourceProviderName Nombre del proveedor de recursos del recurso afectado.

resourceType Tipo del recurso afectado.

subStatus Normalmente el código de estado HTTP de la llamada REST

correspondiente, pero también puede incluir otras cadenas
que describen un subestado. Por ejemplo: OK (código de
estado HTTP: 200), Created (código de estado HTTP: 201),
Accepted (código de estado HTTP: 202), No Content
(código de estado HTTP: 204), Bad Request (código de
estado HTTP: 400), Not Found (código de estado HTTP:
404), Conflict (código de estado HTTP: 409), Internal Server
Error (código de estado HTTP: 500), Service Unavailable
(código de estado HTTP: 503) y Gateway Timeout (código
de estado HTTP: 504).

eventTimestamp Marca de tiempo de cuándo generó el evento el servicio de

Azure que procesó la solicitud correspondiente al evento.

submissionTimestamp Marca de tiempo de cuándo el evento empezó a estar

disponible para las consultas.

subscriptionId Suscripción de Azure en la que se registró este evento.

status Cadena que describe el estado de la operación. Los valores

son Active y Resolved.

operationName El nombre de la operación.

category Esta propiedad es siempre ServiceHealth.

resourceId Identificador de recurso del recurso afectado.

Properties.title El título localizado de esta comunicación. El valor

predeterminado es inglés.

Properties.communication Los detalles localizados de la comunicación con el formato

HTML. El valor predeterminado es inglés.

Properties.incidentType Uno de los siguientes valores: ActionRequired,

Informational, Incident, Maintenance o Security.

Properties.trackingId El incidente al que está asociado este evento. Se utiliza para

correlacionar los eventos relacionados con un incidente.

Properties.impactedServices Un blob JSON con caracteres de escape que describe los

servicios y regiones a los que afecta el incidente. Una lista
de servicios, cada uno de los cuales tiene un valor de
 Nombre de propiedad Descripción

ServiceName y una lista de regiones afectadas, cada una de

los cuales tiene un valor de RegionName.

Properties.defaultLanguageTitle La comunicación en inglés.

Properties.defaultLanguageContent La comunicación en inglés en formato HTML o como texto

sin formato.

Properties.stage Los valores posibles de Incident y Security son Active,

Resolved o RCA. Para Acción requerida o Informativa, el
único valor es Activo. Para el Mantenimiento son: Activo,
Planificado, En curso, Cancelado, Reprogramado, Resuelto
o Completo.

Properties.communicationId La comunicación con la cual está asociado este evento.

Detalles sobre la información de estado del servicio

Action Required (properties.incidentType == ActionRequired)

Información: Se necesita una acción del administrador para evitar que los servicios
existentes se vean afectados.

Maintenance (properties.incidentType == Maintenance)

Advertencia: Mantenimiento de emergencia

Información: Mantenimiento planeado estándar

Información (properties.incidentType == Informativo )

Información: Se necesita que el administrador evite que los servicios existentes se

vean afectados.

Security (properties.incidentType == Security)

Advertencia: Aviso de seguridad que afecta a los servicios existentes y puede

requerir la acción del administrador.
Información: Aviso de seguridad que afecta a los servicios existentes.

Service Issues (properties.incidentType == Incident)

Error: Problemas generalizados de acceso a varios servicios en distintas regiones

que afectan a numerosos grupos de clientes.
Advertencia: Problemas de acceso a servicios concretos o en regiones concretas
que afectan a un subgrupo de clientes.
Información: Problemas que afectan a las operaciones de administración o de
latencia, sin afectar a la disponibilidad del servicio.
Manténgase informado sobre los
problemas de seguridad de Azure
Artículo • 16/05/2023

Con la mayor adopción de la informática en la nube, los clientes confían cada vez más
en Azure para ejecutar su carga de trabajo para aplicaciones empresariales críticas y no
críticas. Es importante que ustedes, como clientes de Azure, se mantengan informados
sobre los problemas de seguridad de Azure o las vulneraciones de la privacidad y tomen
las medidas adecuadas para proteger su entorno.

En este artículo se muestra dónde los clientes de Azure reciben notificaciones de

seguridad de Azure y tres pasos que puede seguir para asegurarse de que las alertas de
seguridad lleguen a las personas adecuadas de su organización.

Visualización y administración de notificaciones

de seguridad de Azure

Problemas de seguridad que afectan a las cargas de

trabajo de la suscripción de Azure
Recibirá notificaciones relacionadas con la seguridad que afectan a las cargas de trabajo
de suscripción de Azure de dos maneras:

Aviso de seguridad en Azure Service Health

Azure publica las notificaciones de mantenimiento del servicio, que contienen

información acerca de los recursos en la suscripción. Puede revisar estos avisos de
seguridad en la experiencia de Service Health en Azure Portal y recibir notificaciones
sobre avisos de seguridad a través de su canal preferido configurando alertas de Service
Health para este tipo de notificación. Puede crear Alertas del registro de actividad en las
notificaciones del servicio mediante Azure Portal.

７ Nota

En función de los requisitos que pueda tener, puede configurar varias alertas que
usen el mismo grupo de acciones o, por el contrario, grupos de acciones
diferentes. Los tipos de grupos de acciones incluyen el envío de llamadas de voz,
mensajes de texto o correo electrónico. También se puede desencadenar varios
tipos de acciones automatizadas.
Notificación por correo electrónico

Si un problema de seguridad requiere una acción directa realizada por administradores

o propietarios de suscripciones, o es necesario compartir información crítica y
confidencial de recursos, se envía una notificación por correo electrónico a los
administradores o propietarios de suscripciones.

７ Nota

Debe asegurarse de que hay una dirección de correo electrónico a la que se

puede contactar como administrador de suscripciones o propietario de la
suscripción. Esta dirección de correo electrónico se usa para problemas de
seguridad que podrían afectar al nivel de suscripción.

Problemas de seguridad que afectan a las cargas de

trabajo de inquilino de Azure
Normalmente, se comunica información relacionada con la seguridad que afecta a las
cargas de trabajo del inquilino de Azure a través de una Notificación de correo
electrónico. Enviamos una notificación por correo electrónico al administrador global y
a los contactos técnicos

７ Nota

Debe asegurarse de que hay una dirección de correo electrónico a la que se

puede contactar especificada para la Administración global y el Contacto técnico
de su organización en el inquilino. Esta dirección de correo electrónico se usa para
problemas de seguridad que podrían afectar al nivel de inquilino.

Tres pasos para ayudarle a mantenerse

informado sobre los problemas de seguridad
de Azure
1. Compruebe el contacto en el rol de Propietario de administración de suscripción

Asegúrese de que hay una dirección de correo electrónico a la que se puede contactar
como administrador de suscripciones o propietario de la suscripción. Esta dirección de
correo electrónico se usa para problemas de seguridad que podrían afectar al nivel de
suscripción.

2. Compruebe el contacto en el rol de Administrador global de inquilinos y Contacto

técnico

Asegúrese de que hay una dirección de correo electrónico a la que se puede contactar
especificada para la Administración global y el Contacto técnico en el inquilino. Esta
dirección de correo electrónico se usa para problemas de seguridad que podrían afectar
al nivel de inquilino.

3. Cree alertas de Azure Service Health para las notificaciones de suscripción

Cree alertas de Azure Service Health para eventos de seguridad para que su
organización pueda recibir alertas de cualquier evento de seguridad que Microsoft
identifique. Este es el mismo canal que configuraría para recibir alertas de interrupciones
o información de mantenimiento en la plataforma: Creación de alertas del registro de
actividad en notificaciones del servicio mediante Azure Portal.

En función de los requisitos que pueda tener, puede configurar varias alertas que usen
el mismo grupo de acciones o, por el contrario, grupos de acciones diferentes. Los tipos
de grupos de acciones incluyen el envío de llamadas de voz, mensajes de texto o correo
electrónico. También se puede desencadenar varios tipos de acciones automatizadas.

Hay una diferencia importante entre los avisos de seguridad de Service Health y las
notificaciones de seguridad de Microsoft Defender for Cloud. Los avisos de seguridad
de Service Health proporcionan notificaciones relacionadas con vulnerabilidades de la
plataforma e infracciones de seguridad y privacidad en el nivel de suscripción e
inquilino, mientras que las notificaciones de seguridad en Microsoft Defender for Cloud
comunican vulnerabilidades que pertenecen a recursos individuales de Azure afectados.

Puede encontrar más información sobre las notificaciones de Azure Service Health en:
¿Qué son las notificaciones de mantenimiento del servicio de Azure? - Azure Service
Health | Microsoft Learn
Tipos de recursos y comprobaciones de
estado en Azure Resource Health
Artículo • 03/09/2023

A continuación se muestra una lista completa de todas las comprobaciones que se

ejecutan a través de Resource Health por tipos de recursos.

Microsoft.AnalysisServices/servers
Comprobaciones ejecutadas

- ¿El servidor está en funcionamiento?

- ¿El servidor se ha quedado sin memoria?
- ¿Se inicia el servidor?
- ¿Se está recuperando el servidor?

Microsoft.ApiManagement/service
Comprobaciones ejecutadas

- ¿El servicio Api Management está en funcionamiento?

Microsoft.AppPlatform/Spring
Comprobaciones ejecutadas

- ¿Está disponible la instancia de Azure Spring Cloud?

Microsoft.Batch/batchAccounts
Comprobaciones ejecutadas

- ¿La cuenta de Batch está en funcionamiento?

- ¿Se ha superado la cuota del grupo para esta cuenta por lotes?

Microsoft.Cache/Redis
Comprobaciones ejecutadas

- ¿Todos los nodos de caché están en funcionamiento?

- ¿Se puede acceder a la memoria caché desde el centro de datos?
- ¿Ha alcanzado la memoria caché el número máximo de conexiones?
- ¿Ha agotado la memoria caché su memoria disponible?
- ¿La memoria caché experimenta un gran número de errores de página?
- ¿La memoria caché está bajo mucha carga?

Microsoft.CDN/profile
Comprobaciones ejecutadas

- ¿Es accesible el portal complementario para las operaciones de configuración de CDN?

- ¿Hay problemas de entrega en curso con los puntos de conexión de la red CDN?
- ¿Pueden los usuarios cambiar la configuración de sus recursos de cdn?
- ¿Se propagan los cambios de configuración a la velocidad esperada?
- ¿Los usuarios pueden administrar la configuración de la red CDN mediante el Azure Portal,
PowerShell o la API?

Microsoft.classiccompute/virtualmachines
Comprobaciones ejecutadas

- ¿El servidor que hospeda esta máquina virtual está en funcionamiento?

- ¿Se ha aprovisionado y encendido el contenedor de máquinas virtuales?
- ¿Hay conectividad de red entre el host y la cuenta de almacenamiento?
- ¿Hay mantenimiento planeado continuo?
- ¿Hay latidos entre el agente invitado y host (si la extensión de invitado está instalada)?

Microsoft.classiccompute/domainnames
Comprobaciones ejecutadas

- ¿La implementación de ranuras de producción está en buen estado en todas las instancias de
rol?
- ¿El rol está en buen estado en todas sus instancias de máquina virtual?
- ¿Cuál es el estado de mantenimiento de cada máquina virtual dentro de un rol de servicio en la
nube?
- ¿Se cambió el estado de la máquina virtual debido a la operación iniciada por la plataforma o el
cliente?
- ¿Se ha completado el arranque del sistema operativo invitado?
- ¿Hay mantenimiento planeado continuo?
Comprobaciones ejecutadas

- ¿Se degrada el hardware del host y se predice que se producirá un error pronto?
- Más información sobre comprobaciones ejecutadas

Microsoft.cognitiveservices/accounts
Comprobaciones ejecutadas

- ¿Se puede acceder a la cuenta desde el centro de datos?

- ¿Está disponible el proveedor de recursos de servicios de Azure AI?
- ¿Está disponible Cognitive Service en la región adecuada?
- ¿Se pueden realizar operaciones de lectura en la cuenta de almacenamiento que contiene los
metadatos del recurso?
- ¿Se ha alcanzado la cuota de llamadas API?
- ¿Se ha alcanzado el límite de lectura de la llamada API?

Microsoft.compute/hostgroups/hosts
Comprobaciones ejecutadas

- ¿El host está en funcionamiento?

- ¿Se degrada el hardware del host?
- ¿El host está desasignado?
- ¿Se ha curado el servicio de hardware de host en hardware diferente?

Microsoft.compute/virtualmachines
Comprobaciones ejecutadas

- ¿El servidor que hospeda esta máquina virtual está en funcionamiento?

- ¿Se ha aprovisionado y encendido el contenedor de máquinas virtuales?
- ¿Hay conectividad de red entre el host y la cuenta de almacenamiento?
- ¿Hay mantenimiento planeado continuo?
- ¿Hay latidos entre el agente invitado y host (si la extensión de invitado está instalada)?

Microsoft.compute/virtualmachinescalesets
Comprobaciones ejecutadas

- ¿El servidor que hospeda esta máquina virtual está en funcionamiento?

- ¿Se ha aprovisionado y encendido el contenedor de máquinas virtuales?
- ¿Hay conectividad de red entre el host y la cuenta de almacenamiento?
Comprobaciones ejecutadas

- ¿Hay mantenimiento planeado continuo?

- ¿Hay latidos entre el agente invitado y host (si la extensión de invitado está instalada)?

Microsoft.ContainerService/managedClusters
Comprobaciones ejecutadas

- ¿El clúster está en funcionamiento?

- ¿Están disponibles los servicios principales en el clúster?
- ¿Todos los nodos de clúster están listos?
- ¿La entidad de servicio es actual y válida?

Microsoft.datafactory/factories
Comprobaciones ejecutadas

- ¿Se han producido errores de ejecución de canalización?

- ¿El clúster que hospeda Data Factory está en buen estado?

Microsoft.datalakeanalytics/accounts
Comprobaciones ejecutadas

- ¿Los usuarios han experimentado problemas al enviar o enumerar sus trabajos de Data Lake
Analytics?
- ¿No se pueden completar los trabajos de Data Lake Analytics debido a errores del sistema?

Microsoft.datalakestore/accounts
Comprobaciones ejecutadas

- ¿Los usuarios han experimentado problemas al cargar datos en Data Lake Store?
- ¿Los usuarios han experimentado problemas para descargar datos de Data Lake Store?

Microsoft.datamigration/services
Comprobaciones ejecutadas

- ¿No se pudo aprovisionar el servicio de migración de bases de datos?

- ¿Se ha detenido el servicio de migración de base de datos debido a inactividad o solicitud de
usuario?

Microsoft.DataShare/accounts
Comprobaciones ejecutadas

- ¿La cuenta de Data Share está en funcionamiento?

- ¿Está disponible el clúster que hospeda el Data Share?

Microsoft.DBforMariaDB/servers
Comprobaciones ejecutadas

- ¿El servidor no está disponible debido al mantenimiento?

- ¿El servidor no está disponible debido a la reconfiguración?

Microsoft.DBforMySQL/servers
Comprobaciones ejecutadas

- ¿El servidor no está disponible debido al mantenimiento?

- ¿El servidor no está disponible debido a la reconfiguración?

Microsoft.DBforPostgreSQL/servers
Comprobaciones ejecutadas

- ¿El servidor no está disponible debido al mantenimiento?

- ¿El servidor no está disponible debido a la reconfiguración?

Microsoft.devices/iothubs
Comprobaciones ejecutadas

- ¿El centro de IoT está en funcionamiento?

Microsoft.DigitalTwins/DigitalTwinsInstances
Comprobaciones ejecutadas

- ¿La instancia de Azure Digital Twins está en funcionamiento?

Microsoft.documentdb/databaseAccounts
Comprobaciones ejecutadas

- ¿Ha habido alguna solicitud de recopilación o base de datos no atendida debido a una falta de
disponibilidad del servicio Azure Cosmos DB?
- ¿Ha habido solicitudes de documento no atendidas debido a la falta de disponibilidad de un
servicio de Azure Cosmos DB?

Microsoft.eventhub/namespaces
Comprobaciones ejecutadas

- ¿El espacio de nombres de Event Hubs experimenta errores generados por el usuario?
- ¿El espacio de nombres de Event Hubs se está actualizando actualmente?

Microsoft.hdinsight/clusters
Comprobaciones ejecutadas

- ¿Están disponibles los servicios principales en el clúster de HDInsight?

- ¿El clúster de HDInsight puede acceder a la clave para el cifrado BYOK en reposo?

Microsoft.HybridCompute/machines
Comprobaciones ejecutadas

- ¿El agente del servidor está conectado a Azure y envía latidos?

Microsoft.IoTCentral/IoTApps
Comprobaciones ejecutadas

- ¿Está disponible la aplicación de IoT Central?

Microsoft.KeyVault/vaults
Comprobaciones ejecutadas

- ¿Se producen errores en las solicitudes al almacén de claves debido a problemas de la

plataforma Azure KeyVault?
- ¿Se están limitando las solicitudes al almacén de claves debido a demasiadas solicitudes
realizadas por el cliente?

Microsoft.Kusto/clusters
Comprobaciones ejecutadas

- ¿El clúster experimenta bajas tasas de éxito de ingesta?

- ¿El clúster experimenta una alta latencia de ingesta?
- ¿El clúster experimenta un gran número de errores de consulta?

Microsoft.MachineLearning/webServices
Comprobaciones ejecutadas

- ¿El servicio web está en funcionamiento?

Microsoft.Media/mediaservices
Comprobaciones ejecutadas

- ¿El servicio multimedia está en funcionamiento?

Microsoft.network/applicationgateways
Comprobaciones ejecutadas

- ¿Se degrada el rendimiento del Application Gateway?

- ¿Está disponible el Application Gateway?

Microsoft.network/azureFirewalls
Comprobaciones ejecutadas

- ¿Hay suficientes puertos disponibles para realizar la NAT de origen?

- ¿Hay suficientes conexiones disponibles?

Microsoft.network/bastionhosts
Comprobaciones ejecutadas

- ¿El host de Bastion está en funcionamiento?

Microsoft.network/connections
Comprobaciones ejecutadas

- ¿Está conectado el túnel VPN?

- ¿Hay conflictos de configuración en la conexión?
- ¿Las claves previamente compartidas están configuradas correctamente?
- ¿Es accesible el dispositivo VPN local?
- ¿Hay discrepancias en la directiva de seguridad IPSec/IKE?
- ¿La conexión VPN S2S se aprovisiona correctamente o está en estado de error?
- ¿La conexión de red virtual a red virtual se aprovisiona correctamente o tiene un estado de
error?

Microsoft.network/expressroutecircuits
Comprobaciones ejecutadas

- ¿El circuito ExpressRoute está en buen estado?

Microsoft.network/frontdoors
Comprobaciones ejecutadas

- ¿Los back-end de Front Door responden con errores a los sondeos de estado?
- ¿Se retrasan los cambios de configuración?

Microsoft.network/LoadBalancers
Comprobaciones ejecutadas

- ¿Están disponibles los puntos de conexión de equilibrio de carga?

Microsoft.network/natGateways
Comprobaciones ejecutadas

- ¿Están disponibles los puntos de conexión de puerta de enlace NAT?

Microsoft.network/trafficmanagerprofiles
Comprobaciones ejecutadas

- ¿Hay algún problema que afecte al perfil de Traffic Manager?

Microsoft.network/virtualNetworkGateways
Comprobaciones ejecutadas

- ¿Se puede acceder a la puerta de enlace de VPN desde Internet?

- ¿El VPN Gateway está en modo de espera?
- ¿Se ejecuta el servicio VPN en la puerta de enlace?

Microsoft.NotificationHubs/namespace
Comprobaciones ejecutadas

- ¿Se pueden realizar operaciones en tiempo de ejecución como el registro, la instalación o el

envío en el espacio de nombres?

Microsoft.operationalinsights/workspaces
Comprobaciones ejecutadas

- ¿Hay retrasos en la indexación del área de trabajo?

Microsoft.PowerBIDedicated/Capacities
Comprobaciones ejecutadas

- ¿El recurso de capacidad está en funcionamiento?

- ¿Todas las cargas de trabajo están en funcionamiento?

Microsoft.search/searchServices
Comprobaciones ejecutadas

- ¿Se pueden realizar operaciones de diagnóstico en el clúster?

Microsoft.ServiceBus/namespaces
Comprobaciones ejecutadas

- ¿Los clientes experimentan errores de Service Bus generados por el usuario?

- ¿Los usuarios experimentan un aumento en los errores transitorios debido a una actualización
del espacio de nombres de Service Bus?

Microsoft.ServiceFabric/clusters
Comprobaciones ejecutadas

- ¿El clúster de Service Fabric está en funcionamiento?

- ¿Se puede administrar el clúster de Service Fabric mediante Azure Resource Manager?

Microsoft.SQL/managedInstances/databases
Comprobaciones ejecutadas

- ¿La base de datos está en funcionamiento?

Microsoft.SQL/servers/databases
Comprobaciones ejecutadas

- ¿Se produjo un error en los intentos de inicio de sesión en la base de datos porque la base de
datos no estaba disponible?
Microsoft.Storage/storageAccounts
Comprobaciones ejecutadas

- ¿Se producen errores en las solicitudes para leer datos de la cuenta de Storage debido a
problemas de la plataforma de Azure Storage?
- ¿Se producen errores en las solicitudes para escribir datos en la cuenta de Storage debido a
problemas de la plataforma de Azure Storage?
- ¿El clúster de almacenamiento en el que reside la cuenta de almacenamiento no está
disponible?

Microsoft.StreamAnalytics/streamingjobs
Comprobaciones ejecutadas

- ¿Todos los hosts donde se está ejecutando el trabajo?

- ¿No se pudo iniciar el trabajo?
- ¿Hay actualizaciones en tiempo de ejecución en curso?
- ¿El trabajo está en un estado esperado (por ejemplo, en ejecución o detenido por el cliente)?
- ¿Ha encontrado el trabajo excepciones de memoria insuficiente?
- ¿Hay actualizaciones de proceso programadas en curso?
- ¿Está disponible el Administrador de ejecución (plan de control)?

Microsoft.web/serverFarms
Comprobaciones ejecutadas

- ¿El servidor host está en funcionamiento?

- ¿Se está ejecutando Internet Information Services?
- ¿Se ejecuta el equilibrador de carga?
- ¿Se puede acceder al plan de App Service desde el centro de datos?
- ¿La cuenta de almacenamiento que hospeda el contenido de los sitios para serverFarm está
disponible?

Microsoft.web/sites
Comprobaciones ejecutadas

- ¿El servidor host está en funcionamiento?

- ¿Se ejecuta el servidor de Internet Information?
- ¿Se ejecuta el equilibrador de carga?
- ¿Se puede acceder a la aplicación web desde el centro de datos?
- ¿La cuenta de almacenamiento que hospeda el contenido del sitio está disponible?
Microsoft.RecoveryServices/vaults
Comprobaciones ejecutadas

- ¿Se produce un error en las operaciones de copia de seguridad en los elementos de copia de
seguridad configurados en este almacén debido a causas que van más allá del control del
usuario?
- ¿Se produce un error en las operaciones de restauración en los elementos de copia de
seguridad configurados en este almacén debido a causas que van más allá del control del
usuario?

Microsoft.VoiceServices/communicationsgateway
Comprobaciones ejecutadas

- ¿Se ejecutan instancias de transporte de tráfico?

- ¿El servicio puede controlar las llamadas?

Pasos siguientes
Consulte la introducción al panel de Azure Service Health y la introducción a Azure
Resource Health para más información sobre ellos.
Preguntas más frecuentes sobre Azure Resource Health
Configure alertas de forma que se le notifiquen los problemas de estado. Para más
información, consulte el artículo de configuración de alertas para eventos de
Service Health.
Impacto en los recursos de las
interrupciones de Azure
Artículo • 26/10/2023

Azure Service Health ayuda a los clientes a ver los eventos de estado que afectan a
sus suscripciones e inquilinos. En Azure Portal, el panel Problemas de servicio de
Service Health muestra los problemas continuos en los servicios de Azure que afectan a
los recursos. Puede comprender cuándo se inició cada problema y qué servicios y
regiones se ven afectados.

Anteriormente, la pestaña Posible impacto en el panel Problemas de servicio aparecía

en la sección detalles del incidente. Mostró los recursos de una suscripción que podrían
afectar a una interrupción, junto con una señal de Azure Resource Health para ayudarle
a evaluar el impacto.

Para admitir la experiencia de visualización de los recursos afectados, Service Health ha

habilitado una nueva característica para:

Reemplace la pestaña Posible impacto por una pestaña Recursos afectados en el

panel Problemas de servicio.
Mostrar los recursos de los que se ha confirmado que se van a ver afectados por
una interrupción.
Muestra los recursos que no están confirmados para verse afectados por una
interrupción, pero podrían verse afectados porque se encuentran en un servicio o
región que se confirma que se verán afectados.
Proporcione el estado de los recursos confirmados y potenciales afectados para
mostrar su disponibilidad.

En este artículo se detalla qué se comunica Service Health y dónde puede ver
información sobre los recursos afectados.

７ Nota

Esta característica se implementará en fases. Inicialmente, solo los clientes

seleccionados de nivel de suscripción obtendrán la experiencia. El lanzamiento se
expandirá gradualmente al 100 % de la suscripción y a los usuarios de nivel de
inquilino.

Visualización de los recursos afectados

En Azure Portal, en la pestaña Recursos afectados de Service Health Service Issues
(Problemas del servicio Service Health>) se muestran los recursos que son o pueden
verse afectados por una interrupción. Service Health proporciona la información
siguiente a los usuarios cuyos recursos se ven afectados por una interrupción:

Columna Descripción

Nombre del Nombre del recurso. Este nombre es un vínculo en el que se puede hacer clic y
recurso va a la página Resource Health del recurso. Si no hay ninguna señal de Resource
Health disponible para el recurso, este nombre es solo texto.

Estado de los Estado de mantenimiento del recurso:

recursos
Disponible: el recurso está en buen estado, pero es posible que un evento de
servicio se haya visto afectado en un momento dado anterior.

Degradado o no disponible: una acción iniciada por el cliente o una acción

iniciada por la plataforma podría haber causado este estado. Significa que el
recurso se vio afectado, pero ahora podría estar en buen estado, pendiente de
una actualización de estado.

Tipo de Indicación de si el recurso es o podría verse afectado:

impacto
Confirmado: se confirma que el recurso se ve afectado por una interrupción.
Compruebe la sección Resumen para ver los elementos de acción que puede
realizar para corregir el problema.

Potencial: no se confirma que el recurso se ve afectado, pero podría verse

afectado porque está bajo un servicio o región que afecta a una interrupción.
Compruebe la columna Resource Health para asegurarse de que todo funciona
según lo planeado.

Tipo de Tipo de recurso afectado (por ejemplo, máquina virtual).

recurso

Grupo de Grupo de recursos que contiene el recurso afectado.

recursos

Ubicación Ubicación que contiene el recurso afectado.

 Columna Descripción

Id. de Identificador único de la suscripción que contiene el recurso afectado.

suscripción

Subscription Nombre de la suscripción de la suscripción que contiene el recurso afectado.

Name

A continuación se muestra un ejemplo de interrupción de los recursos afectados desde

el ámbito de la suscripción y del inquilino.

７ Nota

No todos los recursos del ámbito de la suscripción mostrarán un estado de

Resource Health. El estado solo aparece en los recursos para los que está
disponible una señal de Resource Health. El estado de los recursos para los que una
señal de Resource Health no está disponible aparece como N/A y el valor de
Nombre de recurso correspondiente es texto en lugar de un vínculo en el que se
puede hacer clic.
 ７ Nota

El estado de Resource Health, el nombre del inquilino y el identificador de inquilino

no se incluyen en el ámbito de nivel de inquilino. El valor de Nombre de recurso
correspondiente es texto solo en lugar de un vínculo en el que se puede hacer clic.

Filtrar resultados
Puede ajustar los resultados mediante estos filtros:

Tipo de impacto: seleccione Confirmado o Potencial.

Identificador de suscripción: muestra todos los identificadores de suscripción a los
que el usuario puede acceder.
Estado: céntrese en el estado de Resource Health seleccionando Disponible, No
disponible, Degradado, Desconocido o N/A.

Exportar a CSV
Para exportar la lista de recursos afectados a un archivo de Excel, seleccione la opción
Exportar a CSV .

Acceso a los recursos afectados mediante

programación a través de una API
Puede obtener información sobre los recursos afectados por la interrupción mediante
programación mediante la API de eventos. Para más información sobre cómo acceder a
estos datos, consulte la documentación de api.

Pasos siguientes
Introducción al panel de Azure Service Health
Introducción a Azure Resource Health
Preguntas más frecuentes sobre Azure Resource Health
Impacto en los recursos del
mantenimiento planeado de Azure
Artículo • 18/10/2023

En compatibilidad con la experiencia para ver los recursos afectados, Service Health ha
habilitado una nueva característica para:

Muestra los recursos afectados por un evento de mantenimiento planeado.

Proporcione información sobre los recursos afectados para el mantenimiento
planeado a través del Portal de Service Health.

En este artículo se detalla lo que se comunica a los usuarios y dónde pueden ver
información sobre los recursos afectados.

７ Nota

Esta característica se implementará en fases. Inicialmente, los recursos afectados

solo se mostrarán para los recursos de SQL con notificaciones avanzadas del
cliente y actualizaciones de reinicio para los recursos de proceso. La cobertura de
recursos afectados por el mantenimiento planeado se expandirá a otros tipos de
recursos y escenarios en el futuro.

Visualización de recursos afectados para

eventos de mantenimiento planeado en el
Portal de Service Health
En Azure Portal, la pestaña Recursos afectados en Mantenimiento planeado de Service
Health>muestra los recursos afectados por un evento de mantenimiento planeado. En
el ejemplo siguiente de la pestaña Recursos afectados se muestra un evento de
mantenimiento planeado con recursos afectados.
Service Health proporciona la información siguiente sobre los recursos afectados por un
evento de mantenimiento planeado:

Campos Descripción

Nombre del recurso Nombre del recurso afectado por el evento de mantenimiento
planeado

Tipo de recurso Tipo de recurso afectado por el evento de mantenimiento

planeado

Grupo de recursos Grupo de recursos que contiene el recurso afectado

Región Región que contiene el recurso afectado

Id. de suscripción Identificador único de la suscripción que contiene el recurso

afectado

Acción(*) Vínculo a la página aplicar actualización durante la ventana

autoservicio (solo para actualizaciones reiniciando en los recursos
de proceso)

Fecha de vencimiento de Fecha de vencimiento de la ventana de autoservicio durante la

mantenimiento de cual el usuario puede aplicar la actualización (solo para
autoservicio(*) actualizaciones reiniciadas en los recursos de proceso)

７ Nota

Los campos con un asterisco * son campos opcionales que están disponibles en
función del tipo de recurso.

Filters
Los clientes pueden filtrar los resultados mediante los filtros siguientes

Region
Id. de suscripción: todos los identificadores de suscripción a los que el usuario
tiene acceso
Tipo de recurso: todos los tipos de recursos de las suscripciones de los usuarios

Exportar a CSV
La lista de recursos afectados se puede exportar a un archivo de Excel si se hace clic en
esta opción.

Pasos siguientes
Introducción al panel de Azure Service Health
Introducción a Azure Resource Health
Preguntas más frecuentes sobre Azure Resource Health
Impacto en los recursos de los
incidentes de seguridad de Azure
Artículo • 19/10/2023

Para admitir la experiencia de visualización de los recursos afectados, Service Health ha

habilitado una nueva característica para:

Visualización de recursos afectados por un incidente de seguridad

Habilitación del control de acceso basado en rol (RBAC) para ver la información de
recursos afectada por incidentes de seguridad

En este artículo se detalla lo que se comunica a los usuarios y dónde pueden ver
información sobre los recursos afectados.

７ Nota

Esta característica se implementará en fases. El lanzamiento se expandirá

gradualmente al 100 % de los clientes de suscripción e inquilino.

Acceso basado en rol (RBAC) para el impacto

en los recursos de incidentes de seguridad
El control de acceso basado en rol de Azure (Azure RBAC) ayuda a administrar quién
tiene acceso a los recursos de Azure, qué puede hacer con esos recursos y a qué áreas
puede acceder. Dada la naturaleza confidencial de los incidentes de seguridad, se
aprovecha el acceso basado en roles para limitar la audiencia de su información de
recursos afectada. Junto con la información de recursos, Service Health proporciona la
siguiente información a los usuarios cuyos recursos se ven afectados por un incidente
de seguridad:

Los usuarios autorizados con los siguientes roles pueden ver la información de recursos
afectada por la seguridad:

Nivel de suscripción

Propietario de la suscripción
Subscription Admin
Roles personalizados con permisos
Microsoft.ResourceHealth/events/fetchEventDetails/action o
 Microsoft.ResourceHealth/events/action

Nivel de inquilino

Lector de seguridad Administración/Seguridad

Administración global de Administración/inquilino
Roles personalizados con permisos
Microsoft.ResourceHealth/events/fetchEventDetails/action o
Microsoft.ResourceHealth/events/action

Visualización de recursos afectados para

incidentes de seguridad en el Portal de Service
Health
En Azure Portal, la pestaña Recursos afectados en Avisos de seguridad de Service
Health>muestra los recursos afectados por un incidente de seguridad. Junto con la
información de recursos, Service Health proporciona la siguiente información a los
usuarios cuyos recursos se ven afectados por un incidente de seguridad:

Column Descripción

Id. de suscripción Identificador único de la suscripción que contiene el recurso afectado

Subscription Name Nombre de la suscripción para la suscripción que contiene el recurso

afectado

Nombre del Nombre de inquilino para el inquilino que contiene el recurso afectado
inquilino

Id. de inquilino Identificador único del inquilino que contiene el recurso afectado

En los ejemplos siguientes se muestra un incidente de seguridad con recursos afectados

del ámbito de la suscripción y del inquilino.

Suscripción
Inquilino

Acceso a recursos afectados mediante

programación a través de una API
La información de recursos afectada para incidentes de seguridad se puede recuperar
mediante programación mediante la API de eventos. Para acceder a la lista de recursos
afectados por un incidente de seguridad, los usuarios autorizados con los roles
mencionados anteriormente pueden usar los puntos de conexión siguientes. Para más
información sobre cómo acceder a estos datos, consulte la documentación de api.

Suscripción

HTTP

https://management.azure.com/subscriptions/(“Subscription
ID”)/providers/microsoft.resourcehealth/events/("Tracking
ID")/listSecurityAdvisoryImpactedResources?api-version=2022-10-01

Inquilino

HTTP

https://management.azure.com/providers/microsoft.resourcehealth/events/("Tra
cking ID")/listSecurityAdvisoryImpactedResources?api-version=2022-10-01

Pasos siguientes
Introducción al panel de Azure Service Health
Introducción a Azure Resource Health
Preguntas más frecuentes sobre Azure Resource Health
P+F sobre Azure Resource Health
Preguntas más frecuentes

Aprenda las respuestas a las preguntas más frecuentes sobre Azure Resource Health.

¿Qué es Azure Resource Health?

Resource Health le ayuda a diagnosticar y obtener soporte técnico cuando un problema
de Azure afecta a sus recursos. Le informa acerca del mantenimiento actual y pasado de
los recursos y le ayuda a mitigar los problemas. Resource Health le proporciona soporte
técnico si necesita ayuda con los problemas de los servicios de Azure.

¿Para qué está pensado Resource

Health?
Cuando se detecta un problema con un recurso, Resource Health puede ayudarle a
diagnosticar la causa principal. Proporciona ayuda para mitigar el problema y el soporte
técnico cuando necesita más ayuda para solucionar los problemas con el servicio de
Azure.

¿Qué comprobaciones de estado realiza

Resource Health?
Resource Health realiza varias comprobaciones según el tipo de recurso. Estas
comprobaciones están diseñadas para implementar tres tipos de problemas:

Eventos no planeados, por ejemplo, un reinicio inesperado del host

Eventos planeados, como actualizaciones programadas del sistema operativo del
host
Eventos desencadenados por acciones de usuario, por ejemplo, un usuario que
reinicia una máquina virtual

¿Qué significa cada uno de los estados

de mantenimiento?
Hay tres estados de mantenimiento distintos:
 Disponible: no hay problemas conocidos en la plataforma de Azure que pudieran
afectar a este recurso
No disponible: Resource Health detectó problemas que afectan al recurso
Desconocido: Resource Health no puede determinar el estado de un recurso
porque dejó de recibir información sobre el mismo.

¿Qué significa el estado desconocido?

¿Hay problemas con mi recurso?
El estado es desconocido cuando Resource Health deja de recibir información sobre un
recurso específico. Si bien este estado no es una indicación definitiva del estado del
recurso, en casos donde experimenta problemas podría indicar que hay un problema
con Azure.

¿Cómo puedo obtener ayuda para un

recurso no disponible?
Puede enviar una solicitud de soporte técnico desde la hoja Resource Health. No
necesita tener un contrato de soporte técnico con Microsoft para abrir una solicitud
cuando el recurso no está disponible debido a eventos de plataforma.

¿Resource Health diferencia entre la no

disponibilidad a causa de problemas de
plataforma y por alguna acción que yo
hice?
Sí, cuando un recurso no está disponible, Resource Health incluye la causa principal en
una de estas categorías:

Acción iniciada por el usuario

Evento planeado
Evento no planeado

En el portal, las acciones iniciadas por el usuario aparecen con un icono de notificación
azul, mientras que los eventos planeados y no planeados se muestran con un icono de
advertencia de color rojo. Se proporcionan más detalles en Información general sobre
Resource Health.
¿Puedo integrar Resource Health con
mis herramientas de supervisión?
Resource Health admite las alertas basadas en el registro de actividad. Las alertas del
registro de actividad usan grupos de acciones para notificar a los usuarios que se ha
desencadenado una alerta. Los grupos de acciones son compatibles con una variedad
de canales de notificación, como correo electrónico, SMS, webhook y acciones de ITSM.

¿Dónde se encuentra Resource Health?

Después de iniciar sesión en Azure Portal, hay varias maneras de acceder a Resource
Health:

Vaya al recurso. En el panel de navegación de la izquierda, seleccione Resource

Health
Vaya a la hoja de Azure Service Health. En el panel de navegación de la izquierda,
seleccione Resource Health.

También puede usar la API de Resource Health para obtener información sobre el
estado de los recursos.

¿Está Resource Health disponible para

todos los tipos de recursos?
La lista de comprobaciones de estado y los tipos de recursos compatibles con Resource
Health se encuentran aquí.

¿Qué debo hacer si mi recurso aparece

como disponible pero creo que no lo
está?
Cuando se comprueba el estado de un recurso, justo debajo del estado de
mantenimiento puede hacer clic en Informe de estado de mantenimiento incorrecto.
Antes de enviar el informe, tiene la opción de proporcionar detalles adicionales sobre
por qué cree que el estado de mantenimiento actual no es correcto.
¿Está Resource Health disponible en
todas las regiones de Azure?
Resource Health está disponible en todas las zonas geográficas de Azure.

¿Cuál es la diferencia entre Resource

Health, estado de Azure y el panel de
Service Health?
La información que Resource Health proporciona es más específica que la que
proporciona el estado de Azure o el panel de Service Health.

Mientras que el estado de Azure y el panel de Service Health le informan sobre

problemas de servicio que afectan a un amplio conjunto de clientes (por ejemplo, una
región de Azure), Resource Health expone eventos más pormenorizados que solo
afectan a un recurso específico. Por ejemplo, si un host se reinicia de improviso,
Resource Health solo alerta a los clientes cuyas máquinas virtuales se ejecutaban en ese
host.

¿Es necesario activar Resource Health

para cada recurso?
No, la información de estado está disponible para todos los tipos de recursos a través
de Resource Health.

¿Es necesario habilitar Resource Health

para la organización?
No. Azure Resource Health es accesible desde Azure Portal, sin requisitos de
configuración.

¿Está Resource Health disponible de

forma gratuita?
Sí. Azure Resource Health es gratuito.
¿Qué recomendaciones proporciona
Resource Health?
Según el estado, Resource Health proporciona recomendaciones con el objetivo de
disminuir el tiempo dedicado a solucionar problemas. En el caso de los recursos
disponibles, las recomendaciones se centran en cómo solucionar los problemas más
comunes que encuentran los clientes. Si el recurso no está disponible debido a un
evento no planeado de Azure, el foco estará en ayudarle durante el proceso de
recuperación y después de este.

¿Por qué veo que la métrica de

disponibilidad de la máquina virtual
refleja el tiempo de inactividad de la
máquina virtual cuando no veo ningún
impacto?
La métrica de disponibilidad de la máquina virtual se calcula como una agregación de
las comprobaciones de estado indicadas aquí. Cuando el agente invitado se instala
incorrectamente o falta por completo, interpretamos la señal de latido de invitado como
incorrecta y, por lo tanto, emite un valor de métrica de 0, que puede ser inexacto.
Tenemos planes para abandonar el modelo de agregación y confiar solo en una señal de
alta confianza unificada del servidor host. Este trabajo ya está en curso y garantizará que
nuestras ofertas de supervisión proporcionen valores coherentes. Esperamos que este
trabajo se complete a lo largo de 2023.

Pasos siguientes
Más información sobre Resource Health:

Información general sobre Azure Resource Health

Tipos de recursos y comprobaciones de mantenimiento disponibles a través de
Azure Resource Health
Anotaciones de estado de máquina virtual de
Resource Health
Artículo • 18/10/2023

Las anotaciones de mantenimiento de máquina virtual (VM) informan a cualquier actividad en curso
que influye en la disponibilidad de las máquinas virtuales (consulte Tipos de recursos y
comprobaciones de estado). Las anotaciones llevan metadatos que ayudan a racionalizar el impacto
exacto en la disponibilidad.

Estos son más detalles sobre los atributos importantes agregados recientemente para ayudar a
comprender las anotaciones siguientes que puede observar en los temas Resource Health, Azure
Resource Graph y Event Grid System :

Contexto: informa de si la disponibilidad de la máquina virtual se ha influenciado debido a la

actividad orquestada por el usuario o Azure. Puede asumir valores de Platform Initiated |
Iniciado por el cliente | Máquina virtual iniciada | Desconocido

Categoría: informa de si la disponibilidad de la máquina virtual se ha influenciado debido a la

actividad planeada o no planeada y solo se aplica a los eventos "Iniciados por la plataforma".
Puede asumir valores de Planned | No planeado | No aplicable | Desconocido

ImpactType: informa al tipo de impacto en la disponibilidad de la máquina virtual. Puede

asumir los valores de:
Reinicio de tiempo de inactividad o Inmovilización de tiempo de inactividad: informa cuando
la máquina virtual no está disponible debido a la actividad orquestada de Azure (por
ejemplo, VirtualMachineStorageOffline, LiveMigrationSucceededed, etc.). La distinción de
reinicio o inmovilización puede ayudarle a distinguir el tipo de impacto en el tiempo de
inactividad al que se enfrenta.
Degradado: informa cuando Azure predice un error de HW en el servidor host o detecta una
posible degradación del rendimiento. (por ejemplo,
VirtualMachinePossiblyDegradedDueToHardwareFailure)
Informativo: informa cuando un usuario o proceso autorizado desencadena una operación
de plano de control (por ejemplo, VirtualMachineDeallocationInitiated,
VirtualMachineRestarted). Esta categoría también captura casos de acciones de plataforma
debido a umbrales o condiciones definidos por el cliente. (por ejemplo,
VirtualMachinePreempted)

７ Nota

Las máquinas virtuales afectan a la hora de inicio y finalización solo se aplica a las anotaciones
degradadas y no se aplican a las anotaciones informativas o de tiempo de inactividad.

En la tabla siguiente se resumen todas las anotaciones que la plataforma emite hoy:
Annotation Descripción Atributos

VirtualMachineRestarted La máquina virtual Contexto:

está realizando un Iniciado por el
reinicio según la cliente
solicitud de una Categoría: no
acción de reinicio aplicable
desencadenada ImpactType:
por un usuario o Informativo
proceso
autorizado desde
la máquina virtual.
No es necesario
que realice
ninguna otra
acción en este
momento. Para
obtener más
información,
consulte la
descripción de los
reinicios de
máquina virtual
en Azure.

VirtualMachineCrashed La máquina virtual Contexto:

está realizando un máquina
reinicio debido a virtual
un bloqueo del iniciada
sistema operativo Categoría: no
invitado. Los aplicable
datos locales no ImpactType:
se ven afectados Reinicio del
durante este tiempo de
proceso. No es inactividad
necesario que
realice ninguna
otra acción en
este momento.
Para obtener más
información,
consulte la
descripción de los
bloqueos de
máquina virtual
en Azure.

VirtualMachineStorageOffline La máquina virtual Contexto:

está actualmente Iniciado por la
realizando un plataforma
reinicio o Categoría: No
experimentando planeada
un bloqueo de la ImpactType:
aplicación debido Reinicio del
a una pérdida
Annotation Descripción Atributos

temporal de tiempo de
acceso al disco. inactividad
No se requiere
ninguna otra
acción en este
momento,
mientras la
plataforma está
trabajando para
restablecer la
conectividad de
disco.

VirtualMachineFailedToSecureBoot Se aplica a Azure Contexto:

Confidential Iniciado por el
Compute Virtual cliente
Machines cuando Categoría: no
la actividad de aplicable
invitado (por ImpactType:
ejemplo, los Informativo
componentes de
arranque sin
firmar) provoca un
problema del
sistema operativo
invitado que
impide que la
máquina virtual
arranque de
forma segura.
Puede intentar
volver a realizar la
implementación
después de
asegurarse de que
editores de
confianza firmen
los componentes
de arranque del
sistema operativo.
Para obtener más
información,
consulta Arranque
seguro.

LiveMigrationSucceeded La máquina virtual Contexto:

se pausó Iniciado por la
brevemente al plataforma
realizarse Categoría: No
correctamente planeada
una operación de ImpactType:
migración en vivo Inmovilización
en la máquina de tiempo de
virtual. Esta inactividad
Annotation Descripción
operación se llevó Atributos
a cabo como una
acción de
reparación, para la
optimización de la
asignación, o
como parte de los
flujos de trabajo
de mantenimiento
rutinario. No es
necesario que
realice ninguna
otra acción en
este momento.
Para obtener más
información,
consulte
Migración en vivo.

LiveMigrationFailure Se intentó realizar Contexto:

una operación de Iniciado por la
migración en vivo plataforma
en la máquina Categoría: No
virtual como una planeada
acción de ImpactType:
reparación, para la Inmovilización
optimización de la de tiempo de
asignación, o inactividad
como parte de los
flujos de trabajo
de mantenimiento
rutinario. Sin
embargo, esta
operación no se
pudo completar
correctamente y
puede haber dado
lugar a una breve
pausa de la
máquina virtual.
No es necesario
que realice
ninguna otra
acción en este
momento.
Tenga en cuenta
también que las
SKU de máquina
virtual de la serie
L, serie L no son
aplicables a la
migración en vivo.
Para obtener más
información,
Annotation Descripción Atributos

consulte
Migración en vivo.

VirtualMachineAllocated La máquina virtual Contexto:

está en proceso Iniciado por el
de configuración cliente
según la solicitud Categoría: no
de un usuario o aplicable
proceso ImpactType:
autorizado. No es Informativo
necesario que
realice ninguna
otra acción en
este momento.

VirtualMachineDeallocationInitiated La máquina virtual Contexto:

está en proceso Iniciado por el
de detención y cliente
desasignación Categoría: no
según la solicitud aplicable
de un usuario o ImpactType:
proceso Informativo
autorizado. No es
necesario que
realice ninguna
otra acción en
este momento.

VirtualMachineHostCrashed La máquina virtual Contexto:

se ha bloqueado Iniciado por la
inesperadamente plataforma
debido a que el Categoría: No
servidor host planeada
subyacente ha ImpactType:
experimentado un Reinicio del
error de software tiempo de
o a causa de un inactividad
componente de
hardware con
errores. Mientras
se reinicia la
máquina virtual,
los datos locales
no se ven
afectados. Puede
intentar volver a
implementar la
máquina virtual
en un servidor
host diferente si
sigue
experimentando
problemas.
Annotation Descripción Atributos

VirtualMachineMigrationInitiatedForPlannedMaintenance La máquina virtual Contexto:

se está migrando Iniciado por la
a un servidor host plataforma
diferente como Categoría:
parte de los flujos Planeada
de trabajo de ImpactType:
mantenimiento Reinicio del
rutinario que tiempo de
organiza la inactividad
plataforma. No es
necesario que
realice ninguna
otra acción en
este momento.
Para obtener más
información,
consulte
Mantenimiento
planeado.

VirtualMachineRebootInitiatedForPlannedMaintenance La máquina virtual Contexto:

está realizando un Iniciado por la
reinicio como plataforma
parte de los flujos Categoría:
de trabajo de Planeada
mantenimiento ImpactType:
rutinario que Reinicio del
organiza la tiempo de
plataforma. No es inactividad
necesario que
realice ninguna
otra acción en
este momento.
Para obtener más
información,
consulte
Mantenimiento y
actualizaciones.

VirtualMachineHostRebootedForRepair La máquina virtual Contexto:

está realizando un Iniciado por la
reinicio debido a plataforma
que el servidor Categoría: No
host subyacente planeada
ha experimentado ImpactType:
errores Reinicio del
inesperados. tiempo de
Mientras se inactividad
reinicia la
máquina virtual,
los datos locales
no se ven
afectados. Para
Annotation Descripción Atributos

obtener más
información,
consulte la
descripción de los
reinicios de
máquina virtual
en Azure.

VirtualMachineMigrationInitiatedForRepair La máquina virtual Contexto:

se está migrando Iniciado por la
a un servidor host plataforma
diferente debido a Categoría: No
que el servidor planeada
host subyacente ImpactType:
ha experimentado Reinicio del
errores tiempo de
inesperados. Dado inactividad
que la máquina
virtual se está
migrando a un
nuevo servidor
host, los datos
locales no se
conservarán. Para
obtener más
información,
consulte
Recuperación del
servicio .

VirtualMachinePlannedFreezeStarted Esta máquina Contexto:

virtual está Iniciado por la
experimentando plataforma
un impacto Categoría:
inmovilizado Planeada
debido a una ImpactType:
actualización Informativo
rutinaria. Esta
actualización es
necesaria para
asegurarse de que
la plataforma
subyacente está
actualizada con
las mejoras más
recientes. No es
necesario que
realice ninguna
acción en este
momento.

VirtualMachinePlannedFreezeSucceeded Esta máquina Contexto:

virtual ha sufrido Iniciado por la
correctamente plataforma
Annotation Descripción Atributos

una actualización Categoría:

rutinaria que dio Planeada
lugar a un ImpactType:
impacto Inmovilización
inmovilizado. Esta de tiempo de
actualización es inactividad
necesaria para
asegurarse de que
la plataforma
subyacente está
actualizada con
las mejoras más
recientes. No es
necesario que
realice ninguna
acción en este
momento.

VirtualMachinePlannedFreezeFailed Esta máquina Contexto:

virtual se ha Iniciado por la
sometido a una plataforma
actualización Categoría:
rutinaria que Planeada
puede haber ImpactType:
provocado un Inmovilización
impacto de tiempo de
inmovilizado. Sin inactividad
embargo, esta
actualización no
se pudo
completar
correctamente. La
plataforma
coordinará
automáticamente
las acciones de
recuperación,
según sea
necesario. Esta
actualización era
para asegurarse
de que la
plataforma
subyacente está
actualizada con
las mejoras más
recientes. No es
necesario que
realice ninguna
acción en este
momento.

VirtualMachineRedeployInitiatedByControlPlaneDueToPlannedMaintenance La máquina virtual Contexto:

se está migrando Iniciado por el
Annotation Descripción Atributos

a un servidor host cliente

diferente como Categoría: no
parte de los flujos aplicable
de trabajo de ImpactType:
mantenimiento Informativo
rutinario
desencadenados
por un usuario o
proceso
autorizado. Dado
que la máquina
virtual se está
migrando a un
nuevo servidor
host, los datos
locales no se
conservarán. Para
obtener más
información,
consulte
Mantenimiento y
actualizaciones.

VirtualMachineMigrationScheduledForDegradedHardware La máquina virtual Contexto:

está Iniciado por la
experimentando plataforma
una disponibilidad Categoría: No
degradada al planeada
ejecutarse en un ImpactType:
servidor host con Degradado
un componente
de hardware
degradado que se
espera que
genere un error
pronto. Se
intentará la
migración en vivo
para migrar de
forma segura la
máquina virtual a
un servidor host
correcto; sin
embargo, se
puede producir un
error en la
operación en
función de la
degradación del
hardware
subyacente.
Le recomendamos
encarecidamente
que vuelva a
Annotation Descripción Atributos

implementar la
máquina virtual
para evitar errores
inesperados antes
de la fecha límite
de la nueva
implementación
especificada. Para
obtener más
información,
consulte Avance
de la predicción y
mitigación de
errores .

VirtualMachinePossiblyDegradedDueToHardwareFailure La máquina virtual Contexto:

está Iniciado por la
experimentando plataforma
un riesgo Categoría: No
inminente para su planeada
disponibilidad al ImpactType:
ejecutarse en un Degradado
servidor host con
un componente
de hardware
degradado que
generará un error
pronto. Se
intentará la
migración en vivo
para migrar de
forma segura la
máquina virtual a
un servidor host
correcto; sin
embargo, se
puede producir un
error en la
operación.
Le recomendamos
encarecidamente
que vuelva a
implementar la
máquina virtual
para evitar errores
inesperados antes
de la fecha límite
de la nueva
implementación
especificada. Para
obtener más
información,
consulte Avance
de la predicción y
Annotation Descripción Atributos

mitigación de
errores .

VirtualMachineScheduledForServiceHealing La máquina virtual Contexto:

está Iniciado por la
experimentando plataforma
un riesgo Categoría: No
inminente para su planeada
disponibilidad al ImpactType:
ejecutarse en un Degradado
servidor host que
está
experimentando
errores
irrecuperables. Se
intentará la
migración en vivo
para migrar de
forma segura la
máquina virtual a
un servidor host
correcto; sin
embargo, se
puede producir un
error en la
operación en
función de la
firma de error
detectada por el
servidor host.
Le recomendamos
encarecidamente
que vuelva a
implementar la
máquina virtual
para evitar errores
inesperados antes
de la fecha límite
de la nueva
implementación
especificada. Para
obtener más
información,
consulte Avance
de la predicción y
mitigación de
errores .

VirtualMachinePreempted Si ejecuta una Contexto:

máquina virtual Iniciado por la
de prioridad baja plataforma
o de acceso Categoría: No
puntual, se ha planeada
aplazado debido a
Annotation Descripción Atributos

la recuperación de ImpactType:
capacidad por la Informativo
plataforma o
debido a la
expulsión basada
en facturación en
la que el costo
superó los
umbrales
definidos por el
usuario. No es
necesario que
realice ninguna
otra acción en
este momento.
Para más
información,
consulte
Máquinas
virtuales de Spot.

VirtualMachineRebootInitiatedByControlPlane La máquina virtual Contexto:

está realizando un Iniciado por el
reinicio según la cliente
solicitud de un Categoría: no
usuario o proceso aplicable
autorizado desde ImpactType:
la máquina virtual. Informativo
No es necesario
que realice
ninguna otra
acción en este
momento.

VirtualMachineRedeployInitiatedByControlPlane La máquina virtual Contexto:

se está migrando Iniciado por el
a un servidor host cliente
diferente según la Categoría: no
solicitud de un aplicable
usuario o proceso ImpactType:
autorizado desde Informativo
la máquina virtual.
No es necesario
que realice
ninguna otra
acción en este
momento. Dado
que la máquina
virtual se está
migrando a un
nuevo servidor
host, los datos
Annotation Descripción Atributos

locales no se
conservarán.

VirtualMachineSizeChanged Se está Contexto:

cambiando el Iniciado por el
tamaño de la cliente
máquina virtual Categoría: no
tal y como ha aplicable
solicitado un ImpactType:
usuario o proceso Informativo
autorizado. No es
necesario que
realice ninguna
otra acción en
este momento.

VirtualMachineConfigurationUpdated La configuración Contexto:

de máquina Iniciado por el
virtual se está cliente
actualizando tal y Categoría: no
como ha aplicable
solicitado un ImpactType:
usuario o proceso Informativo
autorizado. No es
necesario que
realice ninguna
otra acción en
este momento.

VirtualMachineStartInitiatedByControlPlane La máquina virtual Contexto:

se está iniciando Iniciado por el
tal y como ha cliente
solicitado un Categoría: no
usuario o proceso aplicable
autorizado. No es ImpactType:
necesario que Informativo
realice ninguna
otra acción en
este momento.

VirtualMachineStopInitiatedByControlPlane La máquina virtual Contexto:

se está Iniciado por el
deteniendo según cliente
la solicitud de un Categoría: no
usuario o proceso aplicable
autorizado. No es ImpactType:
necesario que Informativo
realice ninguna
otra acción en
este momento.

VirtualMachineStoppedInternally La máquina virtual Contexto:

se está Iniciado por el
deteniendo según cliente
Annotation Descripción Atributos

la solicitud de un Categoría: no
usuario o proceso aplicable
autorizado, o ImpactType:
debido a una Informativo
actividad de
invitado desde la
máquina virtual.
No es necesario
que realice
ninguna otra
acción en este
momento.

VirtualMachineProvisioningTimedOut Se ha producido Contexto:

un error en el Iniciado por la
aprovisionamiento plataforma
de máquina Categoría: No
virtual debido a planeada
problemas del ImpactType:
sistema operativo Informativo
invitado o scripts
de ejecución de
usuarios
incorrectos. Puede
intentar volver a
crear esta
máquina virtual o
bien, si esta
máquina virtual
forma parte de un
conjunto de
escalado de
máquinas
virtuales, puede
intentar volver a
crear su imagen.

AccelnetUnhealthy Aplicable si las Contexto:

redes aceleradas Iniciado por la
están habilitadas plataforma
para la máquina Categoría: No
virtual: hemos planeada
detectado que la ImpactType:
característica Degradado
Redes aceleradas
no funciona según
lo previsto. Puede
intentar volver a
implementar la
máquina virtual
para mitigar
potencialmente el
problema.
Roles con acceso de administrador de
inquilinos
Artículo • 01/06/2023

En este documento se definen todos los roles con acceso de administrador de

inquilinos, que conceden permiso a la vista de ámbito del inquilino.

Para obtener descripciones de cada rol, consulte Roles integrados de Azure AD.

Rol

Administrador de aplicaciones

Administrador de autenticación

Administrador de directivas de autenticación

Administrador de Azure Information Protection

Administrador de conjuntos de claves B2C con IEF

Administrador de directivas B2C con IEF

Administrador de facturación

Administrador de Cloud App Security

Administrador de aplicaciones en la nube

Administrador de dispositivos en la nube

Administrador de cumplimiento

Administrador de datos de cumplimiento

Administrador de acceso condicional

Aprobador del acceso a la Caja de seguridad del cliente

Administrador de análisis de escritorio

Revisor de directorios

Administrador de nombres de dominio

Administrador de Dynamics 365

Administrador de Exchange
Rol

Administrador de destinatarios de Exchange

Administrador de flujos de usuarios con id. externo

Administrador de atributos de flujos de usuarios con id. externo

Administrador de proveedor de identidades externo

Administrador global

Lector global

Administrador de grupos

Administrador del departamento de soporte técnico

Administrador de identidades híbridas

Administrador de Identity Governance

Administrador de Insights

Administrador de Intune

Administrador de Kaizala

Administrador de conocimientos

Administrador de licencias

Lector de privacidad del Centro de mensajes

Lector del Centro de mensajes

Administrador de red

Administrador de aplicaciones de Office

Administrador de contraseñas

Administrador de Power BI

Administrador de Power Platform

Administrador de autenticación con privilegios

Administrador de roles con privilegios

Lector de informes

Administrador de búsqueda
Rol

Administrador de seguridad

Operador de seguridad

Lector de seguridad

Administrador del soporte técnico del servicio

Administrador de SharePoint

Administrador de Skype Empresarial

Administrador de Teams

Administrador de comunicaciones de Teams

Ingeniero de soporte técnico de comunicaciones de Teams

Especialista de soporte técnico de comunicaciones de Teams

Administrador de dispositivos de Teams

Administrador de usuarios