Última Atualização: 20/Set/2016
Bots, DevOps e Docker
Lições Aprendidas em 48 horas
Autores:
Alessandro Jannuzzi Daniel Semedo Fabio Hara Fabricio Catae Lucas Humenhuk
(c) 2016 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples are for illustration only and are fictitious. No real association is intended or inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
Objetivo: Super Bot Cloud... 4
Visão do Processo Completo... 4
Entregas Consistentes e Confiáveis ... 5
Tecnologias Open Source ... 5
Resultado do Projeto ... 6
Processo de Build ...7
Controle de Versão ... 7
Automação de Build ... 8
Integração com o Slack ... 9
Testes e Cobertura de Código ... 10
Testes Automatizados ... 11
Análise de Código ... 11
Testes Funcionais ... 12
Deployment... 14
Azure Container Services ... 14
Administração ... 15
Docker Client ... 15
Monitoramento da solução ... 16
Implementação ... 17
Instalando as ferramentas do ASP.NET Core para Visual Studio ... 17
Criando um projeto ASP.NET com suporte a .NET Core ... 18
Criando o Bot usando Microsoft Bot Framework ... 20
Adicionando ao Repositório GIT ... 23
Configurando o Build Automatizado ... 25
Customizando o Dashboard do VSTS ... 29
Criando Testes Funcionais com CodedUI ... 31
Criando o Azure Container Service com Docker Swarm ... 33
Configurando o cliente para conectar com o Cluster Docker ... 34
Validando o serviço do Azure Container Service ... 35
Monitorando os serviços com Log Analytics ... 36
I NTRODUÇÃO
Foram 2 longos dias que passamos trabalhando em um Hackathon (maratona de programação) com o objetivo de desenvolver um Bot. Nosso time era composto por pessoas com diferentes especialidades e, por isso, decidimos empregar as técnicas de DevOps para garantir uma entrega ágil e sem perda de qualidade.
Objetivo: Super Bot Cloud
A ideia era criar um Bot para responder dúvidas sobre Azure. No front-end, usamos o Microsoft Bot Framework para conectar o Bot com diferentes canais de comunicação (Skype, SMS, e-mail, etc). No back- end, decidimos colocar robôs de busca rodando em Linux e containers Docker.
Visão do Processo Completo
Nossa preocupação desde o início foi em construir um pipeline de entrega (Build, Release e Teste) para apoiar na automação de processo. O principal objetivo era remover os passos manuais envolvidos desde o processo de compilação até a publicação do aplicativo em produção.
Figura 1 – Dashboard de acompanhamento das entregas
Além da economia de tempo, o pipeline minimizava o risco de incluir erros de aplicação no ambiente produtivo graças aos testes integrados e funcionais. O acompanhamento do pipeline era feito através do Dashboard (Figura 1), que fornecia informações sobre: tarefas pendentes, resultado dos builds, distribuição da aplicação, resultado dos testes, monitoração da aplicação e infraestrutura.
Entregas Consistentes e Confiáveis
Nos 5 minutos finais antes do término do Hackaton, o time de desenvolvimento realizou 4 check-ins de código no repositório. Com base no histórico positivo de alteração de código e deploy para a produção (Figura 2), o time estava confiante no pipeline de entrega e decidiu subir para o ambiente de produção.
Figura 2 - Histórico de sucesso de deployment
Em um cenário sem esse acompanhamento detalhado, talvez o time não se sentisse seguro em executar tais modificações em um momento tão crítico, assim como foi ao final do Hackaton.
Tecnologias Open Source
Desde o começo imaginamos criar um projeto baseado em ASP.NET Core rodando em containers Docker.
Todo o desenvolvimento foi realizado com o Visual Studio 2015 rodando em Windows, porém, utilizamos a versão do .NET Core para garantir compatibilidade com o ambiente Linux (Figura 3).
Figura 3 - Ferramentas de linha de comando do .NET Core
No processo de Build Automation e Release Management, usamos as ferramentas de linha de comando para distribuir o aplicativo para rodar em máquinas Linux no ambiente de produção (Figura 4).
Figura 4 – Build agente rodando o Docker Client para distrbuir a aplicação em containers
A vantagem em usar o Linux em produção é sua integração nativa com o Docker. No caso do Windows, os containers estarão disponíveis a partir do Windows Server 2016.
Resultado do Projeto
Conseguimos finalizar o projeto do Bot usando as tecnologias propostas inicialmente. Ganhamos muito conhecimento ao longo desses dois dias que nos servirá para as próximas semanas e meses. No final, nosso resultado foi positivo e, por isso, decidimos consolidar parte do aprendizado nesse documento.
Convidamos você também a participar de um Hackathon. Essa é uma experiência totalmente diferente da rotina de trabalho, pois você será desafiado a trabalhar com novas tecnologias em um tempo extremamente curto e sob alta pressão.
P ROCESSO DE B UILD
Dedicamos muito tempo para montar o processo de build automatizado. Esse esforço inicial se traduziu em economia de tempo ao longo do projeto.
Controle de Versão
Todos os códigos ficaram armazenados em repositórios GIT, que facilitou muito a colaboração em time (Figura 5).
Figura 5 - Colaboração de código usando GIT
Em um ambiente de desenvolvimento com GIT, é importante que haja commits pequenos e frequentes para evitar os conflitos.
Figura 6 - Visual Studio Team System permite criar múltiplos repositórios GIT
O Visual Studio Team System (VSTS) permite criar vários repositórios GIT privados (Figura 6). A vantagem de usar múltiplos repositórios foi diminuir a quantidade de conflitos em merge.
Automação de Build
Usamos o processo de Build automatizado no Visual Studio Team System (VSTS) para centralizar as compilações de código e rodar os testes unitários. No caso, definimos um processo para cada um dos projetos: Bot, WebCrawler e Worker (Figura 7).
Figura 7 - Definição do Build Automation no Visual Studio Team System (VSTS)
O processo de compilação é realizado em agentes (Figura 8).
Figura 8 - Agente rodando o processo de build
Usamos os Hosted Agents (disponibilizados pelo VSTS) e instalamos agentes adicionais em máquinas Linux para ajudar no empacotamento da aplicação em container Docker. Curiosamente, nosso processo iniciava com a compilação em Windows e terminava na distribuição para máquinas Linux.
Integração com o Slack
Sempre que um novo build era realizado, a equipe recebia notificações via Slack (Figura 9).
Figura 9 - Notificações via Slack
A integração do Visual Studio Team Services (VSTS) com o Slack ocorria sempre que subíamos uma nova versão, alterássemos o status de um Work Item ou ocorresse um novo Deployment (Figura 10).
Figura 10 - Integração entre VSTS e Slack, especificando quais notificações são disparadas
Essa comunicação dava maior visibilidade ao processo de desenvolvimento e deployment, ajudando no nosso trabalho durante o Hackaton.
T ESTES E C OBERTURA DE C ÓDIGO
Faltando 5 minutos para terminar o Hackathon, ainda faltavam recursos cruciais para o funcionamento correto do Bot. Nesses últimos minutos, o time de desenvolvimento disparou 4 check-ins de código – um deles, faltando 5 segundos para acabar o tempo.
Imagine o nosso desespero se o build falhasse logo nos últimos minutos antes de acabar o Hackaton. Após noites mal dormidas, 2 dias intensos de planejamento e trabalho, tudo seria em vão. Entretanto, depois de várias entregas realizadas com sucesso em produção (Figura 11), tínhamos plena certeza de que a versão final chegaria pronta para ser demonstrada aos jurados.
Figura 11 - Histórico do pipeline de entrega
Foi exatamente isso que aconteceu: mais um Deployment feito com sucesso. Os números ajudam a explicar o grau de confiança. O segredo para entregas consistentes e confiáveis é ter Build e testes automatizados (Figura 12).
Figura 12 - Build e testes automatizados
Configuramos os testes unitários, cobertura e qualidade de código para melhorar o sucesso de entrega do build nos ambientes de Desenvolvimento, Homologação e Produção.
Testes Automatizados
Em momentos de extrema urgência, é comum ver desenvolvedores criando “gambiarras” para resolver problemas e terminar sua alteração sem testar. Como efeito colateral, essa prática pode causar comportamentos inesperados, prejudicando o comportamento da aplicação em produção.
O primeiro passo para automatizar testes é, na definição do Build do Visual Studio Team System (VSTS), configurar os testes unitários para rodar junto com a compilação dos binários.
Figura 13 – Definição de Build Automatizados no VSTS
Assim, teremos uma primeira estatística sobre a porcentagem de Builds criados com sucesso (Figura 13).
Análise de Código
Instalamos um servidor SONAR (http://www.sonarqube.org) para auxiliar na análise da qualidade de código (Figura 14).
Figura 14 - Código-fonte analisado pelo SONAR
Essa ferramenta auxilia na identificação de código-fonte duplicado ou mal-feito, ajudando a melhorar a qualidade de entrega.
Figura 15 - Integração do SONAR com o VSTS
A integração do SONAR com o Visual Studio Team System (VSTS) é feita através de passos adicionais na definição do Build (Figura 15).
Testes Funcionais
O Visual Studio Team System (VSTS) permite configurar os ambientes de Desenvolvimento, Stage, Produção com diferentes pipelines de tarefa.
Figura 16 - Ambientes de desenvolvimento, stage e produção
Usamos o ambiente de Stage para rodar os testes funcionais. Nesse caso, referenciamos os artefatos gerados no processo de build e copiamos para o agente de teste (Figura 17).
Figura 17 - Cópia da DLL do projeto de testes funcionais, que foi gerada durante o build
Usamos máquinas virtuais como agentes pré-configurados para permitir rodar testes de UI (Figura 18).
Figura 18 - Rodando os testes automatizados em um agente customizado
Configuramos testes de desempenho para medir o tempo de resposta nas API’s do Bot (Figura 19).
Figura 19 - Teste de desempenho
Durante o Hackaton, criamos um único teste funcional, que validava a conversação do usuário com o Bot.
Essa era a principal funcionalidade do projeto e, por isso, jamais poderia falhar em produção.
D EPLOYMENT
Uma das principais características do projeto era a possibilidade de aumentar o poder de processamento dos robôs com apenas um comando. Decidimos usar containers (Figura 20), orquestrados pelo Docker Swarm e com a infraestrutura disponibilizada pelo Azure Container Services.
Figura 20 - Containers Docker em execução
Azure Container Services
Utilizamos o Azure Container Services para hospedar os microserviços de back-end da aplicação (WebCrawler e Worker). Este serviço possibilita a criação de um cluster de múltiplas máquinas virtuais para hospedar e gerenciar containers Docker, permitindo a implementação de alta disponibilidade e escalabilidade dos containers em execução.
Durante a criação do cluster, o administrador tem a opção de escolher o gerenciador de containers:
DCOS: solução da Mesosphere baseada nos projetos Mesos e Marathon da Apache Foundation.
O serviço possui uma interface web de administração, permitindo que o administrador aumente o número de containers através do portal administrativo do Marathon.
Docker Swarm: solução da própria Docker, que permite agrupar um conjunto de máquinas virtuais executando Docker Engine em uma única visão lógica.
Para este projeto, escolhemos o Docker Swarm, pois nossa intenção foi continuar explorando as ferramentas de administração de linha de comandos do projeto Docker (Figura 21).
Figura 21 - Ferramentas de linha de comando do Docker Swarm
Os componentes de uma implementação de Docker Swarm criada pelo Azure Container Services contém um conjunto de máquinas virtuais no Azure com o Docker Engine instalado, chamados de agentes.
Quando um container é instanciado, sua execução será direcionada para um dos nós (VMs) deste grupo de agentes (Figura 22).
Figura 22 - Componentes do Azure Container Services com Docker Swarm
Há também um grupo de máquinas virtuais de administração. Os nós de administração, chamados de master, são os responsáveis por monitorar os agentes e agrupá-los de forma a prover uma visão centralizada do pool de recursos (CPUs e memória) disponíveis no cluster.
Neste projeto utilizamos um único nó como master, mas poderia ser escolhida uma configuração multi- master para aumentar a disponibilidade de toda a solução.
Administração
Para acessar os serviços e aplicações dentro dos containers em execução nos agentes, o Azure Container Services cria automaticamente um componente de Load Balancer para as portas 80, 443 e 8080 e direcionadas para as mesmas portas das máquinas virtuais. Isso possibilita executarmos containers com essas portas expostas (mapeadas para as mesmas portas que a dos nós).
As VMs dos masters e agentes são hospedadas em diferentes subnets. Para administrar os agentes, o Azure Container Service implementa um NAT com tradução de IP e portas para que qualquer conexão externa para a porta 2200 seja entregue na porta 22 (SSH) do master.
Dentro deste túnel seguro, criamos uma outra conexão para o serviço de administração do Docker Swarm, que utiliza a porta 2375.
Docker Client
Uma vez configurado o Azure Container Services com suporte a SSH, utilizamos no projeto mais um host Linux simples. Esse host tem as ferramentas de Docker Client instaladas e serve como interface de
administração do Docker Swarm. Neste host cliente administrativo, iniciamos o túnel SSH com o endpoint exposto no master para trafegar a comunicação do Docker Swarm – porta 2375 (Figura 23).
Figura 23 - A exposição do serviço da porta 2200 no master serve para fecharmos um túnel SSH
Essa máquina foi usada como agente de build do VSTS.
Monitoramento da solução
A monitoração da solução utilizou o Log Analytics, parte integrante do Operations Management Suite (OMS). Através deste recurso é possível monitorar os principais serviços do Microsoft Azure e, por isso, aplicamos para o cenário do Hackathon.
Figura 24 - Dashboard final da solução de monitoração
Recursos incluídos na monitoração:
Servidor Linux de produção com Docker + Swarm
Servidor Linux do ambiente de Stage
Servidor Windows Server 2016 TP5 com Container Services
Foi utilizado uma Storage Account para armazenar os logs do SYSLOG e Event Viewer dos servidores monitorados. A quantidade de logs recebidos diariamente atingiu a média de 69MB, portanto optamos por utilizar uma subscription grátis do Log Analytics (500MB de log diário e 7 dias de retenção).
I MPLEMENTAÇÃO
Instalando as ferramentas do ASP.NET Core para Visual Studio
O primeiro passo é instalar o Visual Studio 2015 (https://www.visualstudio.com/) e suas dependências:
Visual Studio 2015 Update 3
https://go.microsoft.com/fwlink/?LinkId=691129 .NET Core 1.0.0 - VS 2015 Tooling Preview 2 https://go.microsoft.com/fwlink/?LinkID=824849
Durante a instalação, foi necessário rodar a linha de comando.
DotNetCore.1.0.0-VS2015Tools.Preview2.exe SKIP_VSU_CHECK=1 Para testar a instalação, rodamos o comando dotnet na linha de comando.
Criando um projeto ASP.NET com suporte a .NET Core
Se você já está acostumado ao Visual Studio, a criação do projeto usando o Visual Studio é feita diretamente a partir do Menu: File -> New Project.
Em seguida, podemos escolher o template inicial. No nosso caso, criamos um microserviço baseado em REST API.
Ao invés do Visual Studio, o projeto poderia ser criado via linha de comando:
Em seguida, podemos rodar o site diretamente pela linha de comando. O primeiro passo é restaurar as dependências usando dotnet restore.
Depois rodamos o projeto com dotnet run.
O site está no ar e disponível na porta 5000.
Criando o Bot usando Microsoft Bot Framework
Faça o download do template para Bot Application (http://aka.ms/bf-bc-vstemplate), salvando o arquivo ZIP na pasta Visual Studio 2015 Project Templates.
Crie um novo projeto no Visual Studio usando o template:
O modelo é um Bot funcional que recebe um texto do usuário como entrada e repete o texto como saída.
A lógica do Bot se encontra no MessagesController.cs. Neste caso, o código recebe o texto da mensagem do usuário e cria uma mensagem de resposta.
Podemos testar o código usando o Bot Framework Channel Emulator (https://aka.ms/bf-bc-emulator).
No exemplo abaixo, estamos rodando o Bot no endereço http://localhost:3979 e, por isso, ajustamos o parâmetro Bot URL para apontar para http://localhost:3979/api/messages.
O passo seguinte é publicar a aplicação no Azure. A forma mais fácil é usar a opção “Publish” do projeto e escolher Microsoft Azure App Service.
Depois de publicar a aplicação na Web, podemos entrar no portal https://dev.botframework.com e registrar o Bot.
Um passo importante é configurar o “Messaging endpoint”, apontando para o website publicado nos passos anteriores. Normalmente, o endereço é http://<meu-site>.azurewebsites.net. Em seguida, clique no botão “Create Microsoft App ID and password” para obter a identidade do aplicativo e sua credencial.
Essas informações devem ser copiadas para o arquivo Web.config do projeto.
Por fim, configure os canais de comunicação do Bot.
Adicionando ao Repositório GIT
É importante começar o projeto com controle de versão. Para isso, basta usar a linha de comando no diretório raiz do projeto.
git init
Depois executamos os comandos:
Git add .
Git commit -m "initial commit"
O projeto está versionado em um Git Local na máquina do desenvolvedor.
Podemos replicar o código do repositório local para um repositório remoto. Dessa forma, será possível compartilhar o código com a equipe, além de servir como um backup do código.
Nesse caso, usamos o Visual Studio Team System (VSTS) e começamos com “Create Team Project”.
O novo projeto possui uma série de itens no menu: Code, Work, Build, Test, Release.
Em seguida, selecionamos o Menu -> Code para obter as informações necessárias de como associar o repositório local ao repositório remoto recém criado.
Vamos executar o GIT PUSH do repositório local através dos seguintes comandos.
git remote add origin <url>
git push -u origin --all
Ao finalizar a execução do git push, observamos que a opção Menu -> Code do VSTS apresenta uma interface diferente. Isso significa que o repositório remoto recebeu as alterações do repositório local.
Configurando o Build Automatizado
Antes de começar, é importante certificar que os arquivos .SLN e .CSPROJ existam dentro do projeto. Esses arquivos são gerados automaticamente pelo Visual Studio ao abrir o projeto do ASP.NET Core.
Na opção Menu -> Build do VSTS, existe a possibilidade de configurarmos o Build automatizado.
Iniciamos criando uma nova definição de Build e selecionamos o template “Visual Studio”, que já contempla tarefas associadas com o MSBUILD.
Em seguida configuramos o repositório e branch (master). Podemos configurar com Continuous Integration, ou seja, toda vez que houver um GIT PUSH, haverá uma compilação automática no servidor.
Esse template contém os seguintes passos pré-definidos: restaurar dependências NuGet, build da solution, rodar os binários de teste, publicação dos símbolos, upload do arquivo como artefato.
No caso do ASP.NET Core, podemos modificar os passos e deixar somente as tarefas essenciais. Além disso, é necessário incluir um novo passo de Command Line.
Nesse passo, restauramos as dependências manualmente.
Salvamos a definição do build e enfileiramos sua execução com “Queue new build”.
O resultado será a console do agente de Build:
Se o build rodar com sucesso, o resultado fica armazenado em um repositório denominado artefato.
Os resultados podem ser baixados ou visualizados na interface gráfica:
Customizando o Dashboard do VSTS
A criação do dashboard e integração são recursos nativos do VSTS e em poucos cliques você consegue inseri-los em seus projetos.
Você poderá escolher quais builds, releases, branches e repositórios, requisitos e queries que gostaria de inserir no dashboard, além de customizar views e relatórios.
O nosso dashboard, por exemplo, apresentava um resumo sobre os principais componentes do pipeline.
No canto inferior do dashboard clique nas opções de edição
Escolha o seu widget e adicione
ao dashboard
Além disso, integramos com o PowerBI para trazer informações de segurança do Azure e dados analíticos sobre o uso do Bot
Criando Testes Funcionais com CodedUI
Uma das preocupações que tínhamos era de garantir que o Bot em nenhum momento falaria palavrões ou respondesse aos jurados uma pergunta fora do contexto. Visando atender a este cenário, criamos uma rotina de teste funcional para perguntar e validar as respostas do Bot.
Criamos um projeto de Coded UI utilizando o Visual Studio Enterprise 2015.
No script criamos um método de avaliação para cada pergunta. Assim, analisamos a resposta do Bot com base no histórico.
Uma vez que temos o script e projetos criados no Visual Studio, torna-se necessário inserir o projeto como parte da solução do projeto. Esse código irá gerar uma DLL ao final do processo de build.
Em seguida, criamos um novo plano de testes para definir a ação.
Para integrarmos os testes do Visual Studio Coded UI com o VSTS é preciso criar o plano de testes e um caso de testes, relacionando a DLL do projeto do Coded UI.
Usando os agentes pré-configurados, esse teste roda dentro do Visual Studio Team System (VSTS).
Criando o Azure Container Service com Docker Swarm
No portal do Azure, procuramos pelo template Azure Container Services e clicamos em Create. Precisamos informar os dados do endpoint que permitirá a conexão do tunel SSH. A chave pública de SSH a ser informada deverá ter o comentário “<usuario>@<host-de-origem>” no final.
Na segunda tela do assistente, escolhemos a infraestrutura de serviços para o cluster. Selecionamos o orquestrador Swarm.
Neste momento, definimos o número de agentes e de masters do cluster, bem como o prefixo DNS que será usado como nome do serviço. Este prefixo será usado como base para criação dos hostnames dos componentes do Swarm.
As telas subsequentes são para confirmação das informações e criação do ambiente.
Configurando o cliente para conectar com o Cluster Docker
No nosso projeto, configuramos o host “dxbrstaging” como uma VM Linux para se comunicar com o cluster Docker Swarm. Neste host, no diretório home do usuário root, existe o diretório “.ssh” com a chave privada correspondente a esta chave pública aqui informada.
Após o cluster Docker Swarm ser criado, utilizamos o host de administração (dxbrstaging) para iniciarmos o tunel SSH:
As opções “-N” e “-p”, especificam respectivamente o usuário/host para fechar o tunel e a porta a ser utilizada. A opção “-L”, especifica uma porta local para criar um socket TCP em estado LISTEN, pronto para receber conexões e encaminhá-las para dentro do túnel SSH.
Uma vez entregue a conexão na extremidade do tunel, a conexão é encaminhada para o hostname:porta informado também na opção “-L”. Neste caso, o hostname “localhost” indica que a própria extremidade do tunel receberá a conexão encapsulada na porta 2375.
Esta porta é o serviço do Docker Swarm. Com o tunel criado, o host está pronto para emitir comandos para o Swarm.
Para isso, precisamos indicar ao utilitário de linha de comando do Docker que ele deve se conectar ao Swarm. Isso é feito através do ajuste da variável de ambiente DOCKER_HOST conforme abaixo:
A partir deste momento, podemos executar os comandos tradicionais do Docker.
Validando o serviço do Azure Container Service
Nesse documento, abordamos a configuração dos containers Dockers seguindo os passos:
1. Criação do Azure Container Service com Docker Swarm
2. Definição das chaves SSH no servidor (Portal Azure) e no cliente (diretório .ssh) 3. Configuração do túnel SSH entre o host cliente e o Azure Container Service 4. Configuração da variável ambiente DOCKER_HOST
Ao rodar os comandos do Docker Client, teremos o seguinte comportamento: toda conexão do comando docker ocorrerá no host local na porta 2375. Esta porta, por sua vez, é o socket criado localmente para ser encapsulado via tunel SSH para o host master do Azure Container Services. O mapeamento de porta recebe a conexão encapsulada e conecta à porta 2375 equivalente ao serviço Swarm.
Quando tudo isso estiver funcionando, os comandos tradicionais do Docker vão rodar (Ex: docker run).
Será possível visualizar os containers em execução com docker ps:
Podemos ver toda a configuração do agrupamento de VMs do Swarm com docker info:
Monitorando os serviços com Log Analytics
O processo para habilitar o Log Analytics deve ser realizado pelo Azure Portal:
Clicar em NEW e digitar LOG ANALYTICS
Clicar em CREATE
No setup inicial é importante definir alguns parâmetros:
OMS Workspace: Nome da solução de gerenciamento
Subscription: Selecionar a subscription
Resource Group: Voce pode utilizar o mesmo Resource Group onde estão localizadas as VMs ou criar um novo.
Location: Selecionar a localidade onde possui o serviço.
Pricing Tier: Selecionar o preço de acordo com a necessidade. Por exemplo, Free é suficiente para o nosso ambiente de Hackathon
Depois de criado o serviço, é necessário definir uma Storage Account para receber todos os logs de SYSLOG, Event Viewer, etc.
Após selecionar o Storage Account, basta selecionar quais máquinas virtuais serão monitoradas. Através do próprio portal, você pode selecionar as VMs e marcar para conectar. Desta forma o Log Analytics automaticamente vai instalar o agente dentro da VM e passar a coletar seus dados.
Feito este processo, já teremos os logs sendo enviados para a Storage Account, restando apenas selecionar quais eventos desejamos filtrar e quais monitorações serão utilizadas.
Atraves do portal do OMS, você terá um controle separado do ambiente:
No portal do OMS acesse o menu lateral direito em Settings. Selecione o menu Data em seguida adicione os Facilities (em SYSLOG) ou eventos (em Windows Event Logs).
Em seguida retorne a tela inicial do OMS e clique em Solutions Gallery. Adicione as seguintes Solutions:
Agent Health
Change Tracking
Security and Audit
Antimalware Assessment
Containers
Dashboard final da solução de monitoração
