No GlueCon 2015, Adrian Cockcroft apresentou uma série de regras para fazer monitoramento de micro serviços e aplicações baseadas em containers e também apontou uma série de desafios para o monitoramento de aplicações baseadas em containers disponibilizados em nuvem, apresentou também o projeto "Spigo", uma ferramenta de simulação e visualização da arquitetura de micro serviços, que pode ajudar os desenvolvedores com o monitoramento de testes de micro serviços em grande escala.
Cockcroft, um parceiro de longa data da Battery Ventures, iniciou sua palestra apresentando uma série de regras para monitoramento de micro serviços e containers, que na verdade trata-se de uma atualização das regras apresentadas em sua palestra durante a Monitorama em 2014:
- Gaste tempo trabalhando em códigos que analisam os resultados das métricas do que códigos que coletam, movem, armazenam e exibem métricas.
- Reduza a latência das métricas chaves do negócio para um valor menor que o tempo de atenção humana (~10s).
- Valide se o seu sistema de medição possui exatidão e precisão suficientes. Colete histogramas dos tempos de respostas.
- Os sistemas de monitoramento devem ser mais disponíveis e escaláveis do que os sistemas (e serviços) que estão sendo monitorados.
- Otimize para que o monitoramento seja distribuído, efêmero, 'cloud-native', micro serviços disponíveis em containers.
- Ajuste as métricas de acordo com os modelos para poder entender seus relacionamentos (esta é uma regra nova).
Cockcroft argumenta que a nova regra, 'Ajuste as métricas de acordo com os modelos', é essencial por que a infraestrutura, o fluxo de dados e a estrutura de domínio/organizacional muitas vezes são ortogonais e precisam ser ligadas para que as métricas façam sentido. Depois de definir micro serviços como 'arquitetura orientada a serviços pouco acoplados e contextos bem definidos', uma série de desafios associados com o monitoramento de micro serviços e tecnologias de container (como o Docker) foram discutidas a fundo.
O primeiro desafio apresentado foi 'complexidade'. Cockcroft afimou que aplicações monolíticas possuem ilimitadas dependências internas e podem ser muito mais complexas do que as dependências de micro serviços que são explicitamente visíveis. O segundo desafio, 'velocidade da mudança, apresenta as dificuldades relacionadas as frequências de mudança que agora são possíveis através da implantação contínua de micro serviços baseados em container:
A medição do uso de CPU uma vez por minuto não faz sentido para os containers. Lidar com a frequência de mudança é o grande desafio para ferramentas de monitoramento.
'Como Escalar' foi citado como o terceiro desafio de monitoramento, o qual inclui mais do que simplesmente o número de containers e máquinas sendo executadas. Os conceitos de 'Cloud-native', tais como regiões e zonas de disponibilidade, precisam ser considerados assim como os próprios serviços e as potenciais múltiplas versões que rodam em paralelo.
Cockcroft explicou que o fluxo de dados também é um desafio inerente a uma arquitetura de micro serviços. Diversas ferramentas como o Atlas do Netflix (e aplicações associadas), a aplicação Application Performance Management da AppDynamics e o Zipkin do Twitter podem mostrar o fluxo de requisições por meio de alguns serviços. Entretanto, arquiteturas interessantes possuem um monte de micro serviços, e isso significa que a visualização é um verdadeiro desafio.
A possibilidade de 'falha' é um desafio presente em aplicações de micro serviços. Isso é piorado pelas falhas que ocorrem em ambientes de nuvem. Por exemplo, o que uma plataforma de análise/monitoramento deve mostrar se ocorrer alguma falha parcial em uma zona de disponibilidade? Pelo desenho, uma aplicação cloud-native vai continuar funcionando com a falha parcial da zona de disponibilidade, por isso não é necessariamente uma 'falha'. Entretanto, os operadores do sistema devem ser informados e potencialmente deve interromper as implantações das aplicações.
O desafio aqui é entender e comunicar os padrões comuns de falhas em micro serviços.
As ferramentas de teste e monitoramento de micro serviços e containers em grande escala podem rapidamente tornar-se custosas e, diante disto, foi sugerido que a simulação poderia ser uma alternativa viável. Cockcroft apresentou o 'spigo' (or 'simianviz'), seu simulador de micro serviços que permite a modelagem e a visualização de arquiteturas de micro serviços interessantes.
Spigo/simianviz é uma aplicação escrita em Go/D3.js que pode gerar sistemas de micro serviços sintético/teste. Configurações de grande escala podem ser simuladas, e o objetivo final é suportar testes de estresse de ferramentas de monitoramento reais. Além disso, Cockcroft planeja adicionar suporte para forçar a variação de código dinamicamente e configurações auto escaláveis, modelagem do Netflix's chaos gorilla para falhas de zona e região e uma conexão WebSocket entre as exibições do spigo e simianviz.
Meu desafio para vocês é: Construam sua arquitetura no Spigo. Estressem ferramentas de monitoramento com esta. Ajudem a corrigir o monitoramento para os micro serviços!
Mais detalhes sobre este assunto e os slides utilizados por Adrian Cockcroft em sua palestra no GlueCon podem ser encontrados em no SlideShare. O código do Spigo/simianviz está hospedado no Github.
GlueCon é uma conferência anual de desenvolvimento que foca em cloud, DevOps, mobile, APIs e big data. Informações sobre o Gluecon podem ser encontradas no site do evento.