Ativar Boot Diagnostics em todas as VMs do Azure com um script Python — terminal mostrando o script habilitando o recurso na frota de VMs

Ativar Boot Diagnostics em Todas as VMs do Azure com Python

Deixe um comentário / Microsoft Azure / Por
Twittar
Compartilhar
Pin
Compartilhar
0 Compart.

Ativar Boot Diagnostics em Todas as VMs do Azure com Python

Quando uma VM do Azure não inicializa, o Boot Diagnostics é o primeiro lugar onde você olha: ele captura a screenshot da tela de boot e o log serial da máquina, mesmo sem acesso via SSH ou RDP. O problema é que, em ambientes com dezenas ou centenas de máquinas, ativar Boot Diagnostics VM por VM não escala.

Neste tutorial você vai ativar Boot Diagnostics em todas as máquinas virtuais de uma subscription de uma só vez, usando um script Python com o Azure SDK. Em 6 seções, cobrimos o que o recurso faz, o modo gerenciado versus storage account, o código completo, a execução com --dry-run e a verificação — tudo com outputs reais capturados em um laboratório de 5 VMs.

Leitura relacionada

Sumário

O que é e por que ativar Boot Diagnostics

O Boot Diagnostics é um recurso de depuração das máquinas virtuais do Azure que registra dois artefatos durante a inicialização: uma captura de tela do console (útil para ver a tela de login, um kernel panic ou uma BSOD) e o log serial do sistema operacional. Portanto, quando uma VM fica presa no boot e você não consegue acessá-la remotamente, é esse recurso que revela o que está acontecendo por baixo.

Por padrão, uma VM criada sem ativar Boot Diagnostics não guarda nenhuma dessas informações — no exato momento em que você mais precisa depurar, não há dados. Por isso, ativar Boot Diagnostics em toda a frota é uma prática recomendada de operação. Além disso, ele é pré-requisito para o Serial Console do portal, que dá acesso a um shell de emergência direto no console da máquina.

Modo gerenciado vs. storage account

Existem duas formas de armazenar os artefatos do Boot Diagnostics. A escolha entre elas define a simplicidade da operação:

ModoOnde os dados ficamQuando usar
Gerenciado (recomendado)Storage account gerenciado pela Azure, transparente para vocêPadrão para a maioria dos casos — sem contas para criar ou manter
Storage customizadoUm storage account seu, informado via URIRequisitos de compliance/rede que exigem controle da conta de armazenamento

Neste guia vamos ativar Boot Diagnostics no modo gerenciado por padrão, que é a recomendação atual da Microsoft: você não cria nem paga por um storage account dedicado e não precisa gerenciar chaves. O script também aceita um storage customizado via parâmetro, caso o seu ambiente exija. Dessa forma, cobrimos os dois cenários com o mesmo código.

Pré-requisitos

  • Python 3.10+ instalado
  • Azure CLI autenticado (az login) ou um Service Principal configurado
  • Permissão de Virtual Machine Contributor (ou Contributor) no escopo desejado
  • As bibliotecas azure-identity, azure-mgmt-compute e azure-mgmt-resource
Segurança: O script se autentica com DefaultAzureCredential e nunca embute credenciais no código. Em automações (CI/CD), prefira uma Managed Identity ou um Service Principal com as variáveis AZURE_TENANT_ID, AZURE_CLIENT_ID e AZURE_CLIENT_SECRET — jamais versione esses valores.

Instalação e autenticação

Primeiro, instale as dependências e autentique-se no Azure. O DefaultAzureCredential reaproveita automaticamente a sessão do az login na sua máquina:

# Dependências
pip install azure-identity azure-mgmt-compute azure-mgmt-resource

# Autenticação (usa a sessão do Azure CLI)
az login

# Opcional: fixar a subscription alvo
export AZURE_SUBSCRIPTION_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Com o ambiente pronto, o próximo passo é entender o código que vai ativar Boot Diagnostics em cada máquina virtual.

O script Python para ativar Boot Diagnostics

A lógica é direta: listar todas as VMs, verificar quais estão sem o recurso e aplicar um patch apenas onde necessário. O coração do script usa begin_update com um DiagnosticsProfile — passar storage_uri=None ativa o modo gerenciado:

from azure.identity import DefaultAzureCredential
from azure.mgmt.compute import ComputeManagementClient
from azure.mgmt.compute.models import (
    VirtualMachineUpdate, DiagnosticsProfile, BootDiagnostics,
)

credential = DefaultAzureCredential()
compute = ComputeManagementClient(credential, subscription_id)

def esta_habilitado(vm) -> bool:
    diag = getattr(vm, "diagnostics_profile", None)
    if diag and diag.boot_diagnostics:
        return bool(diag.boot_diagnostics.enabled)
    return False

# list_all() percorre TODAS as VMs da subscription, em qualquer resource group
for vm in compute.virtual_machines.list_all():
    rg = vm.id.split("/")[4]
    if esta_habilitado(vm):
        continue  # idempotente: não mexe no que já está ok

    update = VirtualMachineUpdate(
        diagnostics_profile=DiagnosticsProfile(
            boot_diagnostics=BootDiagnostics(enabled=True, storage_uri=None)
        )
    )
    compute.virtual_machines.begin_update(rg, vm.name, update).result()
    print(f"[✓] {vm.name} — Boot Diagnostics habilitado")

Repare em dois detalhes importantes. Primeiro, usamos begin_update (um PATCH) em vez de recriar a VM: só o perfil de diagnóstico é alterado, sem tocar em disco, rede ou tamanho. Segundo, a função esta_habilitado torna o script idempotente — rodá-lo várias vezes é seguro, pois ele pula o que já está configurado. A versão completa no GitHub ainda traz --dry-run, filtro por resource group, suporte a storage customizado e um resumo final.

Executar o script em todas as VMs

Antes de alterar qualquer coisa, rode com --dry-run. Ele mostra exatamente o que seria feito, sem escrever nada. No laboratório usado neste artigo (5 VMs, uma já com o recurso ativo), a saída foi:

$ python ativar-boot-diagnostics.py --dry-run

Subscription : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Modo         : gerenciado
Dry-run      : sim
------------------------------------------------------------------------------
[=] vm-bootdiag-01           (rg-bootdiag-lab-eus) — já habilitado
[»] vm-bootdiag-02           (rg-bootdiag-lab-eus) — seria habilitado
[»] vm-bootdiag-03           (rg-bootdiag-lab-eus) — seria habilitado
[»] vm-bootdiag-04           (rg-bootdiag-lab-eus) — seria habilitado
[»] vm-bootdiag-05           (rg-bootdiag-lab-eus) — seria habilitado
------------------------------------------------------------------------------
Total de VMs .......... 5
Já habilitadas ........ 1
A habilitar (dry-run) ... 4
Erros ................. 0

Confirmado o plano, execute sem a flag para ativar Boot Diagnostics de fato. O script aplica o patch só nas quatro VMs que estavam sem o recurso:

$ python ativar-boot-diagnostics.py

Subscription : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Modo         : gerenciado
Dry-run      : não
------------------------------------------------------------------------------
[=] vm-bootdiag-01           (rg-bootdiag-lab-eus) — já habilitado
[✓] vm-bootdiag-02           (rg-bootdiag-lab-eus) — Boot Diagnostics habilitado
[✓] vm-bootdiag-03           (rg-bootdiag-lab-eus) — Boot Diagnostics habilitado
[✓] vm-bootdiag-04           (rg-bootdiag-lab-eus) — Boot Diagnostics habilitado
[✓] vm-bootdiag-05           (rg-bootdiag-lab-eus) — Boot Diagnostics habilitado
------------------------------------------------------------------------------
Total de VMs .......... 5
Já habilitadas ........ 1
Habilitadas agora ... 4
Erros ................. 0

Como o script é idempotente, rodá-lo novamente não repete o trabalho — todas aparecem como já habilitado e nenhuma alteração é feita. Essa é a garantia que permite agendá-lo (por exemplo, num pipeline diário) sem efeitos colaterais.

Verificar a configuração

Para confirmar o resultado sem depender do script, consulte o estado direto pela Azure CLI. Todas as VMs agora reportam True:

$ az vm list -g rg-bootdiag-lab-eus \
    --query "sort_by([].{VM:name, BootDiagnostics:diagnosticsProfile.bootDiagnostics.enabled}, &VM)" -o table

VM              BootDiagnostics
--------------  -----------------
vm-bootdiag-01  True
vm-bootdiag-02  True
vm-bootdiag-03  True
vm-bootdiag-04  True
vm-bootdiag-05  True

No portal, o mesmo resultado aparece em cada VM sob Ajuda → Boot diagnostics, onde você já vê a screenshot e o log serial. Ou seja, ao ativar Boot Diagnostics por código, o portal reflete imediatamente o estado. A captura de tela e o log são populados no próximo ciclo de boot da máquina, então pode levar alguns minutos após a ativação para o primeiro artefato surgir.

Ativar Boot Diagnostics tem custo?

  • Modo gerenciado: o armazenamento dos artefatos é gerenciado pela Azure e o custo é irrelevante — são poucos KB por VM (uma imagem e um log de texto).
  • Storage customizado: você paga o armazenamento no seu storage account, também desprezível pelo volume envolvido.
  • Boa prática: por ser barato e essencial ao diagnóstico, vale ativar Boot Diagnostics em toda a frota — o custo de não ter os dados durante um incidente é muito maior.

Troubleshooting

ProblemaCausaSolução
AuthorizationFailed ao atualizar a VMFalta a role de escrita no escopoAtribua Virtual Machine Contributor à identidade no resource group ou subscription
Nenhuma VM listadaSubscription errada ou credencial de outro tenantConfirme az account show e use --subscription ou AZURE_SUBSCRIPTION_ID
Screenshot vazia após ativarA VM ainda não passou por um novo bootAguarde o próximo ciclo de boot ou reinicie a VM para forçar a captura
DefaultAzureCredential failedSem az login nem variáveis de Service PrincipalRode az login ou exporte AZURE_TENANT_ID/CLIENT_ID/CLIENT_SECRET
VM com storage customizado inacessívelURI de storage inválido ou sem permissãoVerifique o URI e conceda acesso à identidade da VM; ou use o modo gerenciado

Limpeza dos recursos

Se você criou VMs apenas para testar o script, remova tudo com um único comando apagando o resource group do laboratório:

az group delete --name rg-bootdiag-lab-eus --yes --no-wait

Conclusão

Com poucas linhas de Python foi possível ativar Boot Diagnostics em toda uma subscription de forma idempotente, segura e sem tocar em nenhuma outra configuração das VMs. Portanto, você deixa de depender de cliques manuais no portal e passa a garantir, por código, que nenhuma máquina fique sem dados de diagnóstico quando um incidente acontecer. O próximo passo natural é agendar o script num pipeline (Azure DevOps, GitHub Actions ou um Azure Automation Runbook) com uma Managed Identity, para que novas VMs sejam corrigidas automaticamente. Assim, a governança do Boot Diagnostics deixa de ser reativa e passa a ser contínua.

Referências oficiais

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

🚀 Vamos nos conectar?

Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.

Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!

💬 Dúvidas ou Problemas?

Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!

Muito obrigado pela visita e até o próximo post!

Jefferson Castilho Especialista em Cloud & DevOps.

Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.

 

Twittar
Compartilhar
Pin
Compartilhar
0 Compart.

Posts relacionados

Deixe uma resposta

Rolar para cima

Descubra mais sobre Blog do Castilho - Tecnologia | FinOps | DevOps | Cloud

Assine agora mesmo para continuar lendo e ter acesso ao arquivo completo.

Continuar lendo