Alto nível, existem duas maneiras:
- Faça o chef escrever arquivos de configuração check_MK válidos (isso já foi feito até agora) e faça disparar o inventário + recarrega através da automação do WATO. Isso é provavelmente mais transparente.
- Faça Check_MK ler os hosts do seu CMDB (se você executar uma configuração profissional, haveria um ...) ou da configuração do Chef. Isso é possível, a configuração Check_MK permite basicamente qualquer coisa que o Python permita. Assim, você pode ler dados do LDAP, alguma API, configuração do Chef ou um arquivo simples. Para mim, é a abordagem mais limpa, pois tem uma interface de dados mais direta.
Eu acho que a longo prazo, a primeira maneira vai funcionar melhor para você de qualquer maneira, uma vez que é mais orientada para a WATO. Eu ainda escolheria o segundo e entraria na lista EC2 vm e tal.
Um híbrido é possível com, por exemplo, alguns daemon ouvem eventos como criações de VMs e gravam a configuração na pasta somente leitura do WATO.
Nota: Seria muito estúpido não checar qualquer fonte de dados. Só porque alguma infraestrutura como Code nutcase adiciona um bug ( infra-estrutura ) e exclui 100% de suas VMs do Chef, elas não devem ser imediatamente removidas do monitoramento.
Certifique-se de que permanece pouco fora da banda.
Um documento de 2010 sobre a interface dinâmica Check_MK pode ser encontrado aqui: link
É muito antigo, mas apresenta bem as ideias básicas.
Eu fiz uma primeira prova de conceito para uma interface config-mgmt --- para ---- Check_MK. Não é tão bom quanto eu gostaria, mas apenas limitado pela minha velocidade / habilidade escrevendo Python. :)
Estou usando com aprox. servidores não baseados em nuvem agora: link