Ciclo de alertas no vROPs

O vRealize Operations nos mostra diversos alarmes referentes ao ambiente. É comum abrir a ferramenta​​ e​​ encontrar +10000​​ de​​ alarmes gerados. Achei que seria uma boa ideia​​ explicar​​ aqui como eles são gerados, cancelados e deletados do ambiente​​ e quais parâmetros controlam essas ações. Ajustá-los​​ pode ajudar bastante a manter a ferramenta focada nos problemas reais do ambiente e evitar os falsos positivos!

Intervalo de​​ Coleta do vROPs

Antes de tudo, temos que entender o que é um ciclo de coleta do vROPs.​​ O vROPs possui um​​ ciclo de coleta de informações que por padrão é de 5 minutos. Então de 5 em 5 minutos ele coleta informações do vCenter.​​ Lembrando que essa​​ coleta (o ponto no gráfico) é uma média de 15 amostras de 20s do vCenter.​​ O Sunny Dua tem um post que explica direitinho essa conta! Confira​​ AQUI.

O valor padrão é adequado para a maior parte dos ambientes.​​ Se você o diminuir​​ irá consumir mais storage e processamento para processar os dados adicionais. Se você o aumentar, irá consumir menos storage e processamento. Na dúvida, não altere!​​ Você pode confirmar essa configuração​​ no caminho mostrado nas Figuras abaixo.​​ 

Alarmes​​ e​​ Sintomas​​ 

Um alarme no vROPs é definido por um ou mais sintomas. Para​​ o​​ alarme ser verdadeiro todas as condições impostas pelos sintomas devem ser verdadeiras.​​ Vamos​​ utilizar​​ o alarme “Virtual Machine CPU Usage is at 100% for an extended period of time”​​ nesse artigo para entender o​​ seu​​ comportamento. ​​ Esse alarme possui somente o sintoma​​ “Virtual Machine sustained​​ CPU Usage is 100%”​​ mostrado na Figura abaixo.

 

Para entender o alarme, temos que ver o que faz o sintoma ser verdadeiro. Para ver essa informação basta seguir o caminho mostrado na Figura abaixo.​​ 

Clique no ícone do lápis para abrir as configurações do sintoma. Irá abrir a tela mostrada na Figura abaixo.​​ Em 1 podemos ver qual métrica está sendo verificada pelo sintoma. Em 2 qual o limiar que está sendo utilizado para causar o sintoma. No caso desse sintoma​​ a condição​​ verificada é​​ a métrica CPU | Usage (%)​​ ser igual ou maior que 100%.​​ Mas ser igual ou​​ maior​​ que 100% ainda não torna o sintoma verdadeiro!​​ 

Wait Cycle e Cancel Cycle

Os alarmes e os sintomas​​ do vROPs possuem​​ duas configurações: o Wait Cycle e o Cancel Cycle.​​ No​​ alerta​​ essas configurações podem ser verificadas no​​ caminho mostrado na Figura abaixo.​​ E no sintoma no caminho mostrado nas Figuras​​ abaixo apontado pelo​​ número 3.

O Wait Cycle​​ informa​​ o​​ número de ciclos​​ no qual o​​ sintoma​​ deverá encontrar a condição verificada​​ para que​​ ele​​ seja​​ verdadeiro.​​ No nosso alarme exemplo, o sintoma​​ é​​ verdadeiro​​ quando a métrica CPU | Usage​​ (%) é igual ou maior que 100% por​​ 6 ciclos. Como cada ciclo é em um intervalo de 5 minutos, podemos dizer que a máquina virtual tem que estar com CPU 100% por 30 minutos para o sintoma​​ ser verdadeiro.​​ 

O Cancel Cycle é o contrário. Ele irá informar o número de ciclos que o sintoma tem que ser falso para que o​​ sintoma​​ seja cancelado.​​ No caso a métrica CPU Usage deverá ser menor que 100% por 6 ciclos para que o sintoma seja falso.

Com o​​ Wait Cycle e Cancel Cycle é possível customizar o quão sensível será a análise do vRealize Operations. Caso você queria um alarme mais sensível, basta diminuir o Wait Cycle. Quer um alarme mais conservador? Aumenta o Wait Cycle.​​ O mesmo vale para o Cancel Cycle.

Vocês devem ter visto que a configuração de Wait Cycle e Cancel Cycle pode ser feita tanto na configuração do​​ sintoma como​​ na configuração do alarme.​​ A melhor forma de controlar a sensitividade é configurando no sintoma.​​ 

Todos os alarmes possuem a configuração de Wait Cycle com o valor 1 para garantir que​​ o alarme será ativado​​ assim que todos os sintomas que formam o alarme forem verdadeiros.​​ No nosso exemplo, assim que o sintoma for verdadeiro, o alarme será ativado e irá aparecer na aba de Alarms com o status Active.

​​ Todos os alarmes​​ também possuem o Cancel Cycle com o valor 1 para garantir que o alarme será cancelado assim que todos os sintomas não forem mais verdadeiros.

Milhões de alarmes Inativos

Entendemos como os alarmes ficam ativos e como eles são cancelados. Após o alarme ser cancelado ele​​ aparecerá com status inativo​​ conforme​​ apontado na​​ Figura abaixo.

O problema é que você pode começar a ver diversos alarmes nesse estado aparecendo na sua aba de alarmes.​​ O vROPs irá guardar alarmes e sintomas cancelados por 45 dias após os mesmos serem cancelados (pelo Cancel Cycle ou manualmente por um usuário). Caso 45 dias seja demais para o seu ambiente, você pode mudar esse valor no caminho mostrado na Figura abaixo.​​ No meu vROPs​​ eu já havia alterado essa retenção para 2 dias​​ (um valor bem baixo só para eu testar que os alarmes inativos sumiam).​​ Qual valor utilizar vai depender das políticas de retenção de informação da sua empresa​​ 😊​​ 

​​ 

Espero que esse artigo facilite um pouco o entendimento dos alarmes do vROPs. Caso algo tenha ficado confuso ou você possua alguma dúvida não seja tímido, pode usar a sessão de comentários abaixo!

vRealize Operations 7.0 – Licenciamento

Olá pessoal, tudo bem?

Hoje eu queria esclarecer o licenciamento da versão 7.0 do vROps. O vRealize Operations Manager já está na versão 7.0 e, para quem estava acompanhando, sabe que a solução passou por uma mudança grande na versão 6.7.

Cadê as métricas??

Para quem estava acostumado e usava bastante as métricas disponíveis percebeu que a partir da versão 6.7 foi feita uma limpa nas métricas. O objetivo era deixar a ferramenta mais intuitiva e fácil de gerenciar e administrar. Depois do trauma de perder algumas métricas, eu acredito que a mudança foi para o melhor. A ferramenta ficou mais simples de entender e trouxe consigo a precificação de nuvem privada! Essa funcionalidade estava disponível somente no vRealize Business e agora, se você já fez o upgrade para o vROPs 6.7 você já pode usufruir também da funcionalidade! Existem outras funcionalidades também, posso comentá-las em um post futuro.

Se você está interessado em saber quais métricas deixaram de existir ou foram substituídas é só checar esse link AQUI.

Mas voltando ao foco! O upgrade da versão 6.6 para a versão 6.7 pode ser feita sem problemas porque não é uma mudança de versão. Ambos estão em 6.X. Agora para a versão 7.0 temos que tomar cuidado.

Posso fazer o upgrade para a versão 7.0?

Se você está nas versões 6.X e possui um contrato de subscrição e suporte (SnS) ativo com a VMware, você pode fazer o upgrade da ferramenta. Como isso vai acontecer depende de como o seu vROPs é licenciado.

Se o seu vROPs é licenciado pela licença vSOM, não é necessário fazer nenhuma mudança pois essa licença não é invalidada de acordo com o Release Notes do vROPs 7.0. Mas eu deixo aqui um ponto de atenção: o licenciamento vSOM foi descontinuado! (Leia AQUI sobre esse End Of Availability)

Se você possui a licença vRealize Suite 6.0 a mesma será invalidada. Então ao realizar o upgrade o seu novo vROPs irá aparecer em Evaluation Mode (o trial de 60 dias). Se você possui o SNS ativo com a VMware você irá conseguir realizar o upgrade da licença do vROPs para a versão 7.0 a partir do portal MyVMware! Após gerar a nova licença, basta aplica-la no vROps.

Segue KB que explica com mais detalhes as licenças com direito de upgrade: KB 2142365

Caso você não tenha o SNS ativo, será necessário adquirir uma nova licença antes da finalização dos 60 dias de teste para continuar usufruindo da ferramenta na versão 7.0.

Leia o Release Notes!

É extremamente importante ler o Release Notes antes de realizar qualquer upgrade. Além de trazer as novidades, problemas resolvidos e problemas conhecidos esse documento irá informar quais os caminhos de upgrade possíveis e se tem algum ponto importante que deverá ser levado em consideração no planejamento do upgrade. É uma leitura rápida que poderá te poupar bastante dor de cabeça! Então não esqueça de checar o Release Notes vROPS 7.0 !