Todos os componentes do sistema expõem umaAPI. O protocolo usado para a comu- nicação entre componentes foi HTTP. Assim, cada componente recebe pedidos HTTP
que indicam a ação a ser executada para um dado recurso. De seguida, detalham-se as comunicações possíveis entre componentes no sistema e o tipo de dados que envolvem.
Figura 3.8: Instanciação exemplo do sistema com comunicações
• Prometheus e EdgeMon (A): Relação cliente-servidor, onde o Prometheus é o cli- ente. O EdgeMon pode constituir um dos alvos de monitorização do Prometheus. Com isto, o Prometheus envia, periodicamente, um pedido de obtenção de métricas para o endpoint do EdgeMon /metrics. Este responde devolvendo-lhe as métri- cas. Estas podem ser métricas recolhidas no momento, a última versão armazenada nacache, ou a união das duas, dependendo do modo ScrapeMode configurado no EdgeMon. A periodicidade de interação é parametrizável.
• EdgeMon e Alerts Pushgateway (B): Relação unidirecional onde o sentido do fluxo de dados é sempre EdgeMon-Alerts Pushgateway. Todas as regras ativadas com valores das métricas referentes a micro-serviços fazem com que o motor de regras despolete o envio do respetivo alerta para o Alerts Pushgateway.
• EdgeMon e alvo de monitorização (C): Relação que pode ser unidirecional ou cliente-servidor. No primeiro caso, o alvo de monitorização injeta os seus dados diretamente no monitor (push). No segundo caso, o monitor interroga o alvo das suas métricas através doendpoint /metrics (pull). As métricas retornadas são esta- tísticas referentes à aplicação.
• EdgeMon e EdgeMon (D): Relação cliente-servidor. Os EdgeMons que monitori- zam micro-serviços alojados noutro nó que não o seu mas que contém pelo menos um EdgeMon, obtém as métricas dos containers e do host que alojam o alvo de monitorização a partir deste último através dos endpoints /containermetrics e /nodemetrics.
• EdgeMon e cScraper (E): Relação cliente-servidor onde o monitor é cliente. O Edge- Mon interroga o cScraper pelas métricas a partir doendpoint /docker/containerID.
3 . 7 . I N T E R AÇ ÃO E N T R E O S C O M P O N E N T E S D O S I S T E M A
O cScraper obtém os dados relacionados com o estado doscontainers que alojam os alvos indicados pelo monitor e retorna-os.
• EdgeMon e Node Exporter (F): Relação cliente-servidor onde o monitor é cliente. Este interroga o Node Exporter pelas métricas a partir do endpoint /metrics. O Node Exporter coleta as estatísticas acerca dohost que aloja o alvo de monitorização e retorna-as.
• EdgeMon e CGSM (G): As interações entre estes componentes são variadas: CGSM informa o EdgeMon dos alvos de monitorização que é responsável, enviando-lhe uma lista com objetos que representam micro-serviços em formato JavaScriptObject Notation (JSON); CGSM interroga o EdgeMon acerca do seu estado atual para recu- perar de falhas, retornando-lhe uma lista dos seus alvos de monitorização também emJSON; CGSM envia os objetos que representam alvos de monitorização e regras em formatoJSONpara o EdgeMon no momento imediatamente a seguir à migração ou replicação do mesmo; EdgeMon envia alertas para o CGSM quando as regras que indicam sobrecarga são ativadas, resultado da avaliação de métricas durante o processo de auto-monitorização.
• CGSM e Alerts Pushgateway (H): Quando o CGSM não reconhece o alerta recebido de um EdgeMon, envia o mesmo para o Alerts Pushgateway.
• Prometheus e micro-serviço (I): Relação que pode ser unidirecional ou cliente- servidor. No primeiro caso, o alvo de monitorização injeta os seus dados diretamente no Prometheus (push). No segundo caso, o Prometheus interroga periodicamente o alvo das suas métricas através doendpoint /metrics (pull). As métricas retornadas são estatísticas referentes à aplicação.
• Prometheus e Alerts Pushgateway (J): Relação cliente-servidor onde o Prometheus é o cliente. O Prometheus recolhe, periodicamente, os alertas em forma de métricas armazenados no Alerts Pushgateway.
• Prometheus e Alertmanager (K): Relação unidirecional em que o Prometheus en- via os alertas gerados, resultado da avaliação de regras, para o Alertmanager.
C
a
p
í
t
u
l
o
4
I m p l e m e n ta ç ã o
4.1
Tecnologias usadas
Os dois componentes estão escritos em Go. Go ou Golang foi desenvolvido pela Google em 2007. É uma linguagem estaticamente tipada e compilada, com garbage collection e runtime reflection. Apresenta-se como uma linguagem eficiente e rápida com mecanismos de concorrência que maximizam o uso de máquinasmulticore ou interligadas pela rede. Permite também construir código flexível e modular. A escolha do Golang deveu-se essen- cialmente pela facilidade de integração com o Prometheus e restantes componentes exis- tentes. Os objetivos que levaram à criação desta linguagem moldam-se às características que o sistema visa apresentar, principalmente facilidade dedeployment e compatibilidade com ambientes distribuídos. O Golang para além de diminuir os problemas comuns rela- cionados com a gestão de dependências e concorrência, facilita também odeployment já que, tipicamente, um programa compilado é facilmente executado em servidores remotos que tenham o Go instalado, sem necessidade de bibliotecas adicionais. As tecnologias de virtualização simplificam ainda mais este processo. Foi escolhido o Docker para criar e gerircontainers principalmente pelas características e vantagens apresentadas na sec- ção 2.6.2.2e pela facilidade de manipulação a partir do Go. Os componentes/serviços executam emcontainers Docker e, de maneira a criar e gerir os mesmos, e beneficiar de informações que o Docker oferece, o CGSM, CGP, EdgeMon e cScraper interagem com o Docker Engine instalado na máquina que os aloja. Para tal, foi usado oSoftware Develop- ment Kit (SDK) para Go do cliente1para aAPIdo Docker Engine. A partir deste cliente, é possível executar todas as operações do Docker que equivale a executar os comandos na linha de comandos. Para tudo isto ser possível, é necessário, no lançamento de cada serviço, usar obind mount do ficheiro docker.sock (demonstrado na listagem4.3). Como
explicado na secção2.6.2, este constitui osocket Unix que o Docker Engine escuta por padrão e por onde osendpointsHTTPpodem ser consumidos. Uma vez estando o Docker instalado na máquina que aloja ocontainer onde são executadas as operações, o bind mount permite que o ficheiro docker.sock seja mounted dentro do container, possibilitando a comunicação com o Docker Engine a partir do interior docontainer.
Os Dockerfiles usados na construção das imagens dos componentes estão apresen- tados nas listagens4.1e 4.2. Ambos utilizam uma imagem base Ubuntu, declarado no comando FROM. Depois, através do comando COPY, é copiado o ficheiro executável dohost para ocontainer. De seguida, o RUN permite mudar as permissões e tornar o ficheiro anteri- ormente copiado efetivamente executável. Finalmente o comando CMD define o comando que é executado e respetivos argumentos quando é iniciado umcontainer.
Listagem 4.1: Dockerfile do componente EdgeMon
1 FROM ubuntu : latest
2
3 COPY . / edgethesis
4 RUN chmod a+x / edgethesis / edgemonclient
5
6 EXPOSE 9999
7 CMD ["/ edgethesis / edgemonclient " , " -- rules . reactive " , " -- swarm . environment " ,
8 " -- alert . address =192.168.10.1:9091 "]
Listagem 4.2: Dockerfile do componente CGSM
1 FROM ubuntu : latest
2
3 COPY . / compDiscovery
4 RUN chmod a+x / compDiscovery / cgsm
5
6 EXPOSE 8000
7 CMD ["/ compDiscovery / cgsm " , " discover "]
Para criar a imagem a partir dos Dockerfiles, é executado o seguinte comando: docker build -t <nome-imagem> <caminho para o Dockerfile>
Para definir o estado inicial do sistema, é usado um ficheiro YAML. Na listagem4.3, é possível ver um exemplo de instanciação do sistema. Neste caso, são definidos quatro serviços: CGSM, EdgeMon, Prometheus e Alertmanager. Para cada um deles, primeiro são definidas as imagens (cgsm:1 e edgemon:1, prom/prometheus e prom/alertmanager), depois os volumes (socket do Docker, ficheiro YAML com os targets do Prometheus, entre outros), seguido do mapeamento de portas entre ohost e container, respetivamente. Por fim, declaram-se as restrições de posicionamento doscontainers. O ficheiro contém tam- bém a referência da rede usada para a comunicação entre containers. Neste caso, está a ser usada uma rede overlay previamente criada (daí ser external) denominada “overlay- network-fase2”.
4 . 1 . T E C N O L O G I A S U S A DA S 1 2 version : ’3 ’ 3 4 networks : 5 default : 6 external :
7 name : overlay - network - fase2
8 9 services : 10 11 CGSM : 12 image : cgsm :1 13 volumes :
14 - / var / run / docker . sock :/ var / run / docker . sock
15 ports : 16 - 8000:8000 17 18 EdgeMon : 19 image : edgemon :1 20 volumes :
21 - / var / run / docker . sock :/ var / run / docker . sock
22 ports :
23 - 9999:9999
24
25 Prometheus :
26 image : prom / prometheus
27 volumes :
28 - ./ prometheus . yml :/ etc / prometheus / prometheus . yml
29 - ./ swarm - endpoints . json :/ etc / swarm - endpoints / endpoints . json
30 - ./ rules / alert . rules_nodes . yml :/ etc / prometheus / alert . rules_nodes . yml
31 - ./ rules / alert . rules_tasks . yml :/ etc / prometheus / alert . rules_tasks . yml
32 command :
33 - ’ -- config . file =/ etc / prometheus / prometheus . yml ’
34 ports :
35 - 9090:9090
36 deploy :
37 placement :
38 constraints :
39 - node . hostname == cloudmachine
40
41 Alertmanager :
42 image : prom / alertmanager
43 ports :
44 - 9093:9093
45 volumes :
46 - ./ alertmanager . yml :/ etc / alertmanager / config . yml
47 command :
Tabela 4.1: Estruturas de dados em memória de cada componente
Componente Nome Tipo Descrição
EdgeMon targets sync.Map Armazena alvos de monitorização
EdgeMon rules sync.Map Armazena regras
EdgeMon ms github.com/prometheus/
pushgateway/storage Armazena métricas
CGSM emds sync.Map Armazena EdgeMons
CGSM notscrapedds sync.Map Armazena alvos de monitorização
não monitorizados
CGSM scrapedds sync.Map Armazena alvos de monitorização
monitorizados
CGSM cscrapers Map Armazena as localizações
dos cScrapers
CGSM nexporters Map Armazena as localizações
dos Node Exporters
Para fazer o deployment dos serviços com recurso a este, é executado o seguinte co- mando:
docker stack deploy -c <nome-ficheiro> <nome-stack>