Universidade Federal de Pernambuco

Centro de Informática

Bacharelado em Sistemas de Informação

Mangue Beat! Investigando soluções para Monitoramento

de Aplicações Orientadas a Microsserviços

Trabalho de Graduação

LUCAS SERRA DA CUNHA ASSAD

Recife, Julho de 2019

 LUCAS SERRA DA CUNHA ASSAD

Mangue Beat! Investigando soluções para Monitoramento de Aplicações

Orientadas a Microsserviços

Trabalho de conclusão de curso

apresentado como parte das atividades para
obtenção do título de Bacharel em
Sistemas da Informação do Centro de
Informática da Universidade Federal de
Pernambuco

Professor Orientador: Vinicius Cardoso Garcia

Recife, 2019

1
 ASSINATURAS

Este trabalho é o resultado dos esforços do estudante Lucas Serra da Cunha

Assad, sob a orientação do Prof. Vinicius Cardoso Garcia, intitulado “Mangue Beat!
Investigando soluções para Monitoramento de Aplicações Orientadas a
Microsserviços” e conduzido no Centro de Informática da Universidade Federal de
Pernambuco (CIn-UFPE). As pessoas listadas abaixo reconhecem o conteúdo deste
documento e os resultados do Trabalho de Graduação.

______________________________________________________________
Lucas Serra da Cunha Assad

______________________________________________________________
Vinicius Cardoso Garcia

2
 AGRADECIMENTOS

Sou imensamente grato aos meus pais que desde pequeno se esforçaram
para que eu estudasse, buscando sempre dar o melhor do ensino possível pra mim.
Agradeço também a cada conselho, dica, bronca que foi dada. Acredito que
sem nenhum dos pontos citados anteriormente este trabalho não seria possível.
Gostaria de agradecer também a todos os meus amigos do CIn que me fizeram não
desistir da faculdade, tornando o ambiente sempre descontraído. Dos amigos do
CIn eu gostaria de agradecer principalmente a Lerisson por estar sempre antenado
nos trabalhos e prazos, creio que sem este ponto eu não estaria nem perto de
escrever este trabalho.
Por fim, gostaria de agradecer ao meu orientador Vinicius Garcia por todos os
seus ensinamentos, não só durante a escrita do meu TG, como durante as cadeiras
de Engenharia de Software que fui monitor por 2 anos e Microsserviços. Creio que
sem esses ensinamentos talvez nem o tema do meu trabalho fosse este.

3
 RESUMO

Com o surgimento de novas tecnologias, metodologias e ferramentas como,

por exemplo, Computação em Nuvem, Lean Startup, Docker e Kubernetes, o
processo de criação de startups na área de TI foi ficando cada vez mais facilitado.
Adicionalmente, com uma necessidade cada vez maior de construir aplicações de
baixo custo e alta escalabilidade, tornou-se de suma importância a adoção de uma
arquitetura de software rapidamente escalável, resiliente, flexível, segura e voltada a
economicidade (uso otimizado de recursos para melhor gestão dos custos). Neste
contexto, a abordagem de microsserviços emerge como uma excelente proposta de
solução.
A adoção de uma arquitetura baseado em microsserviços permite que
aplicações sejam construídas de forma independente e isoladas. Os problemas
passam a ser tratados mais a nível de arquitetura de software, passando cada vez
mais autonomia para os times de desenvolvimento utilizarem a stack de tecnologia
apropriadas para a solução(i.e. linguagem de programação, banco de dados, etc)
independente da forma como os outros microsserviços desenvolvidos por outras
equipes foram implementados, tudo por meio de APIs REST ou integração dom
brokers​ como por exemplo RabbitMQ1, Kafka2.
Entretanto, essa natureza heterogênea e intrinsecamente distribuída traz
desafios cada vez mais complexos para o monitoramento destes sistemas e, por
sua vez, a identificação de pontos de melhoria e possíveis falhas. Decisões de
centralizar ou não o log, coletar ou não isoladamente as métricas de cada
microsserviço e principalmente como agregar e processar essa massa de dados
passam a ser decisões críticas para a construção de sistemas inerentemente
distribuídos e escaláveis, ou seja, sistemas nativos de computação em nuvem.
Neste trabalho serão demonstradas algumas soluções que atacam diretamente as
problemáticas citadas anteriormente.

1
URL: ​https://www.rabbitmq.com/​. Último acesso em 30/06/2019.
2
URL: ​https://kafka.apache.org/​. Último acesso em 30/06/2019.

4
Palavras-chave: Monitoramento, microsserviços, métricas, escalabilidade,
kubernetes, monitoramento de kubernetes.

5
 ABSTRACT

With the emergence of new technologies, methodologies and tools such as

Cloud Computing, Lean Startup, Docker and Kubernetes, the process of creating IT
startups has become increasingly easier. In addition, with a growing need to build
low-cost, high-scalability applications, the adoption of a rapidly scalable, resilient,
flexible, secure and cost-effective software architecture (optimal use of resources for
management of costs). In this context, the micro-service approach emerges as an
excellent solution proposal.
The adoption of a microservice-based architecture allows applications to be
built independently and in isolation. Problems start to be dealt with more in terms of
software architecture, with more and more autonomy for development teams to use
the appropriate technology stack for the solution (ie programming language,
database, etc.) regardless of how other microservices developed by other teams
were implemented, all through REST APIs or integration dom brokers such as
RabbitMQ, Kafka.
However, this heterogeneous and intrinsically distributed nature presents
increasingly complex challenges for the monitoring of these systems and, in turn, the
identification of points of improvement and possible failures. Decisions to centralize
or not to log, whether or not to collect the metrics of each microservice, and
especially how to aggregate and process this mass of data, are critical decisions for
the construction of inherently distributed and scalable systems, that is, native a
cloud. In this work some solutions will be demonstrated that directly attack the
problems mentioned above.

Keywords: Monitoring, micro-service, metrics, scalability, kubernetes, monitoring

kubernetes.

6
 LISTA DE ILUSTRAÇÕES

2.​1​ ​Foto do computador ENIAC 15

2.​2.​ ​Foto do computador PDP-8 16

2.3​. ​Foto do computador IBM 360/91 17

2.4​. ​Foto da distribuição de aplicações em microsserviços 19

2.5​. ​Divisão de microsserviços em cluster 19

2.6​. ​ ​Foto do log do monitoramento do estado de uma aplicação no Kubernetes 21

2.7​. ​Foto do monitoramento do tempo de resposta de um app no kubernetes 22

2.8​. ​Foto da quantidade de recurso consumido por pod no kubernetes 23

3.1​. ​Agente para coleta de logs dos nós 26

3.​2. ​Arquitetura do Fluentd 27

3.3​. ​Armazenamento das informações Beats 28

3.4​. ​Arquitetura de monitoramento MangueBeat 30

3.5​. ​Scale e informações de deployment via TelegramBot 31

5.1​. ​Informações de CPU por instância. 39

5.2​.​ ​Informações de Memória por instância. 39

5.3​. ​Informações de CPU por instância. 40

7
 ​LISTA DE TABELAS

3.​1 ​O Escopo de cada solução de monitoramento 31

4.​1 ​Configuração de Hardware 31

4.​2. ​Configuração de Software 32

8
 SUMÁRIO

1. Introdução 11

1.1 Contexto 11

1.2 Objetivos 13

1.3 Organização do trabalho 13

2. Contexto Histórico 15

2.1 Evolução das Máquinas 15

2.1.1 Primeira Geração 15

2.1.2 Segunda Geração 16

2.1.3 Terceira Geração 18

2.1.4 Da Quarta Geração até os dias atuais 19

2.2 Tipos de Monitoramento 21

2.2.1 Monitoramento por Tempo de Atividade 21

2.2.2 Monitoramento de Desempenho 22

2.2.3 Monitoramento de Recursos 23

2.2.4 Monitoramento de Log 24

2.3 Sumário do Capítulo 25

3. Análise das Soluções Utilizadas no Trabalho 26

3.1 Monitoramento de Logs no Kubernetes 26

3.2 Fluentd 27

3.3 Beats 28

3.4 Problemas das Soluções apresentadas 29

3.5 MangueBeat 29

3.6 Sumário do Capítulo 32

4. Configuração 34

9
 4.1 Configurações de Ambiente 34

4.1.1 Configuração de Hardware 34

4.1.2 Configuração de Software 34

4.2 Configuração das Soluções utilizadas 35

4.3 Sumário do Capítulo 36

5. Comparando as Soluções 37

6. Conclusão e Trabalhos Futuros 41

6.1 Conclusão 41

6.2 Limitações 42

6.3 Trabalhos Futuros 42

7. Referências 43

10
1. Introdução

Durante muito tempo o monitoramento das aplicações era apenas utilizado

para identificar onde estavam os erros, identificar quando um sistema estava fora do
ar ou notar possíveis gargalos de desempenho [Computerworld, 2006].
Porém, com o avanço do poder computacional das máquinas e a
possibilidade da criação de arquiteturas de software cada vez mais robustas foi
necessário que os sistemas passassem a ser desenvolvidos de forma cada vez
mais distribuída e redundante, evoluindo também na forma como o monitoramento é
feito. Partindo para um paradigma onde cada vez mais o monitoramento é feito de
forma descentralizado e cada vez mais focado na otimização da utilização dos
recursos de máquina, tais como CPU, Memória e Disco.
Com base nisso muitas soluções começaram a surgir para suprir essa
demanda não só arquitetural como de identificação de pontos críticos em sistemas e
possíveis gargalos.

1.1 Contexto

A partir do paradigma da arquitetura de microsserviços foram surgindo

diversas soluções, e uma em especial será abordada por esse trabalho que é o
Kubernetes3.
Abordar uma arquitetura de microsserviços implica eventualmente em
distribuir a carga de recursos computacionais e de rede em diversos ​Nodes/Virtual
Machines(VM’s)​[1] c​ om diferentes configurações. Os ​nodes podem ser divididos em
2 categorias como Worker nodes,​ que são os nodes que recebem toda a carga de
trabalho, e ​Master nodes que exercem papel controladores sobre as ações que
acontecem nos ​Worker nodes​. Distribuir a carga entre ​nodes pode ser resolvido com
load balancers e adaptações nas aplicações, porém, fazer com que o desempenho
seja equivalente independente da configuração da ​vm t​ ornou-se um grande desafio

3
URL: ​https://kubernetes.io/​. Último acesso em 27/06/2019.

11
das implantações, visto que, as ​VMS podem ter diferentes versões para diferentes
pacotes e dependências do sistema operacional.
Com o intuito de solucionar a problemática de configuração de ambiente para
implantação surgiram os contêineres, que resumidamente, são isolamentos de
ambientes previamente configurados que executam como processos pelo Sistema
Operacional. Segundo o livro Kubernetes in the Enterprise[2] os contêineres acabam
também por solucionar alguns outros problemas como:
● São muito mais rápidos para iniciar do que uma ​VM;
○ Iniciar um contêiner é o equivalente a iniciar um processo;
● Construir uma nova imagem para um contêiner é muito mais rápido que
construir uma imagem de uma ​VM;​
○ Basicamente para contêineres para qualquer atualização só são
escritas as mudanças, aproveitando as dependências, imagens bases
​ necessária a re-escrita do
que já houverem no disco. Para ​VMS é
disco por completo;
● As imagens de contêineres são muito mais leves que as imagens de ​VM’S.
De acordo com as facilidades impostas pelos contêineres surgiram algumas
ferramentas para ajudar na orquestração das aplicações em contêineres.
Ferramentas essas que auxiliam com escala, atualização, distribuição de carga,
regras de tráfego, e alguns outros artifícios para monitoramento do estado das
aplicações. O Kubernetes atualmente(2019) é o maior expoente quando nos
referimos aos Orquestradores de Contêineres [3].
Colocar as aplicações de forma distribuída e uniforme se tornou mais fácil e
escalável através desta ferramenta. Porém, com o crescimento de ​clusters de
máquinas virtuais, distribuídos por múltiplas zonas de disponibilidade, pode até
resolver a problemática de termos aplicações redundantes e mitigar possíveis
indisponibilidades dos sistemas.
Mas como saber o tamanho de recurso (i.e. CPU/Memória) ideal para que
sua aplicação seja executada? Como visualizar os logs das aplicações de forma
centralizada? E como identificar o momento certo para escalar as aplicações. Tudo
isso se tornou possível através das soluções de monitoramento do consumo dos
recursos dos softwares/microsserviços/programas isolados.

12
 O objetivo principal deste trabalho é investigar e expor algumas soluções
possíveis e o melhor caso para a(s) sua(a) utilização(ões) no universo do
Kubernetes.

1.2 Objetivos

Neste contexto, este trabalho tem como objetivo fazer um “​benchmark​” entre
soluções de monitoramento de microsserviços comumente utilizados pelo mercado
como, por exemplo, o prometheus4 da Cloud Native Computing Foundation5, beats6
do Elasticsearch7, e MangueBeat que será desenvolvida durante este trabalho.
Desta forma, pretende-se conduzir uma avaliação de desempenho das soluções
citadas anteriormente em 3 cenários:
● Principais características (funcionalidades e capacidades);
● Consumo de recursos, tanto Memória quanto CPU e rede;
● Granularidade das informações;
Facilitando assim, uma análise de qual seria o melhor cenário para a
aplicação de cada uma das soluções analisadas, e onde elas poderiam melhor se
enquadrar de acordo com o que se propoẽm a fazer.

1.3 Organização do trabalho

Este trabalho está organizado conforme a seguinte sequência:

Primeiro Capítulo voltado para uma contextualização da problemática
abordada e apontando os pontos analisados durante o decorrer dos capítulos 3 e 4.
O Capítulo 2 apresenta uma breve contextualização dos avanços das
máquinas e dos tipos de monitoramento, com o intuito de facilitar o entendimento
dos pontos apresentados nos capítulos subsequentes.

4
URL: ​https://prometheus.io/​. Último acesso em 30/06/2019.
5
URL: ​https://www.cncf.io/​. Último acesso em 30/06/2019.
6
URL: ​https://www.elastic.co/products/beats​. Último acesso em 30/06/2019.
7
URL ​https://www.elastic.co/​. Último acesso em 30/06/2019.

13
 O terceiro capítulo apresenta uma análise de como o monitoramento deve ser
feito segundo a documentação oficial do Kubernetes, e como as soluções
analisadas neste trabalho fazem para coletar as métricas e ​logs. Além disso, neste
capítulo é apresentada a justificativa para o desenvolvimento de uma solução de
monitoramento única para múltiplos clusters Kubernetes.
O Capítulo 4 detalha como o ambiente para o desenvolvimento do trabalho
foi configurado e como instalar cada solução utilizada durante o trabalho.
Durante o quinto Capítulo é feita uma comparação entre as soluções,
buscando fazer ressalvas aos diferenciais de cada uma.
Por fim, o capítulo 6 apresenta as conclusões chegadas pelo autor durante o
desenvolvimento do trabalho, e um levantamento de possíveis trabalhos futuros.

14
2. Contexto Histórico

Antes de partir para a análise das soluções de monitoramento para

microsserviços, é necessário entender o que causou a descentralização das
aplicações, o histórico e os impactos na computação. Assim, este capítulo
apresenta detalhes sobre os conceitos e um pouco do contexto histórico. Este
capítulo estará dividido em 2 seções onde uma apresenta uma breve evolução das
máquinas e suas gerações, e a outra discute alguns tipos de monitoramento de
sistemas.

2.1 Evolução das Máquinas

Partindo para uma abordagem da computação moderna que foi marcada pelo
uso de computadores digitais[4], ou seja que utilizavam componentes analógicos
como viés para funcionamento, podemos notar a existência de quatro gerações que
serão descritas a seguir.

2.1.1 Primeira Geração

A primeira geração (1946-1959) iniciou-se o uso de válvulas para eletrônicas

e caracterizou-se pela escrita de programas direto em linguagem de máquina,
houveram alguns expoentes na época e abordaremos aqui o ENIAC (​Electrical
Numerical Integrator and Calculator)​ . O ENIAC foi desenvolvido pelos cientistas
americanos John Eckert e John Mauchly e chegou a ser considerada como mil
vezes mais rápida que qualquer outra máquina e existia na época [5]. Um dos seus
principais diferenciais são o fato de não serem necessários manipulações manuais,
tais como movimentações de válvulas, para que sejam executadas as operaçẽos.
As máquinas chegavam a ter 25 metros de comprimento por 5,50 metros de altura.
Durante esta geração o monitoramento é quase nenhum, a falta de recursos
para armazenamento de dados sensíveis e o fato de as máquinas apenas

15
receberem uma entrada junto ao programa e devolver uma saída dificultavam todo o
processo.

Figura 2.1. Foto do computador ENIAC

Fonte: welivesecurity, 2017.
A Figura 2.1 busca ilustrar o computador ENIAC, maior expoente de sua
época.

2.1.2 Segunda Geração

A partir da Segunda geração (1959-1964) foram substituídas as válvulas

eletrônicas por transistores[6] o que causou um impacto no tamanho das máquinas,
reduziram muito o tamanho. Foram criados duas categorias de computadores para
essa época: microcomputadores e supercomputadores.
Na categoria dos supercomputadores o IBM 7030 foi o primeiro a ser lançado,
criado pela IBM. Foi ao mercado em 1961 e custava cerca de 13 milhões de dólares
e chegava a executar operações em microssegundos[7], ou seja até um milhão de
operações por segundo. Muitas linguagens foram criadas para os computadores da
segunda geração como por exemplo: cobol, fortran e Algol. Facilitando assim o
desenvolvimento de softwares e a manutenibilidade dos mesmos, muitos dos

16
softwares escritos nessas linguagens são mantidos até hoje, como sistemas de
grande bancos.
O PDP-8 foi um microcomputador desenvolvido pela ​Digital Equipment
Corporation lançado em 1965​. ​Chegou a ter mais de 50 mil exemplares vendidos e
custava cerca de 18,500 dólares[8], era considerado uma versão bem mais básica
dos supercomputadores.
Para essa geração foi iniciado o uso de algumas linguagens de programação
citadas anteriormente, e criação de algumas sub rotinas facilitando o
armazenamento de alguns poucos logs do sistema. Facilitando assim o processo de
debug das operações realizadas. Fora isso, o desenvolvimento de testes para
validação de funcionalidades poderiam auxiliar no processo pré execução dos
códigos.

Figura 2.2. Foto do computador PDP-8

Fonte: Wikipedia, 2019
A Figura 2.2 busca ilustrar o computador PDP-8, que fazia parte da categoria
dos microcomputadores de sua geração.

17
2.1.3 Terceira Geração

A terceira geração de computadores ​novamente houve a diminuição do

tamanho, foram construídos circuitos integrados de silício no lugar dos
transistores[9], impactando ainda mais no tempo de processamentos das
operaçẽos[10]. Seu preço também caiu muito o que tornou os computadores desta
geração cada vez mais acessíveis. Como exemplo de máquina desta geração existe
o IBM 360/91, que chegou a permitir a programação da CPU por microcódigo
fazendo com que os circuitos não precisassem mais ser projetados de forma
manual.
Esta geração também fica marcada pelo início da utilização dos
computadores por universidades e empresas de médio porte, deixando de ser de
uso exclusivo militar e de grandes universidades.
Nesta geração não houve um salto importante com relação ao monitoramento
dos sistemas,

Figura 2.3. Foto do computador IBM 360/91

Fonte: Wikipedia, 2019
A Figura 2.3 busca ilustrar o computador IBM 360/91, primeiro computador da
IBM a executar instruções fora de ordem e era muito utilizado para fins científicos.

18
2.1.4 Da Quarta Geração até os dias atuais

Na quarta geração foi concebido os microprocessadores e a popularização

dos computadores pessoais. Houve novamente uma redução enorme de preço e
tamanho. Pela primeira vez as CPU’s chegavam a executar bilhões de
operações[11] por segundo. Foi criada também uma escala de integração de
circuitos LSI (​Large Scale of Integration)​ , VLSI (​Very Large Scale of Integration​) e
ULSI (​Ultra Large Scale of Integration​). Marcando assim o início da utilização dos
computadores pessoais[12], costuma-se dizer que nesta geração o desenvolvimento
do software se equiparava ao hardware.
Com o decorrer do tempo os circuitos foram se tornando cada vez mais
integrados, aumentando muito a capacidade dos processadores e a divisão dos
mesmos em núcleos possibilitando a execução de múltiplas tarefas em paralelo,
fazendo com que a usabilidade se tornasse um fator chave para sucesso dos
computadores pessoais. Existiam máquinas com capacidade de executar tarefas
robustas, sistemas cada vez mais complexos, mas o dilema de como entregar valor
para os “usuários comuns” persistia.
Com o advento dos computadores, laptops e smartphones os sistemas
começaram a ter de processar cada vez mais informações[13], de diferentes
escalas, em diferentes regiões e vários paradigmas da computação começaram a
ser desenvolvidos.
Os sistemas distribuídos são diferentes dos sistema de multi processamento
paralelo (SMP), “​Para um sistema ser de processamento distribuído, uma ou várias
unidades de processamento (CPU) estará separada fisicamente da(s) outra(s),
enquanto que num sistema SMP todas as unidades de processamento se
encontram na mesma máquina”​ [14]. Logo, para sistemas que são desenvolvidos de
forma distribuída poderiam estar rodando em diferentes ​nodes,​ com diferentes
capacidades de processamento. Isolar esses “​pontos de processamentos​” tornou-se
a chave para questão, qual modulo eu devo isolar, quanto de recurso eu devo alocar
para este módulo.
Exemplos de locação de hotéis são muito usados para explicar este caso[15].

19
Podemos dividir o sistema de locação em módulos de pesquisa, módulo de compra,
módulo de listagem, módulo de cadastro. Ao dividir o sistema em módulos
garantimos que caso um desses microsserviços do módulo fiquem sobrecarregados
apenas o microsserviço que foi sobrecarregado cresça e não necessariamente a
aplicação/módulo inteiro, evitando custos excessivos de forma desnecessária. Se
algum módulo entrar em loop, de algum erro, apenas a parte referente a este
módulo ficará indisponível. Caso nosso sistema fosse um grande monolítico como
ilustrado no lado esquerdo da Figura 2.4, ou seja, com todos os módulos juntos, ao
passo que seja necessário escalar a aplicação precisaríamos levantar todos os
módulos de uma vez. Consideramos a divisão da aplicação em módulos como
distribuição de aplicação em micro serviços.

Figura 2.4. Foto da distribuição de aplicações em microsserviços.

Fonte: thoughtworks, 2015.

20
 Figura 2.5 Divisão de microsserviços em cluster.
Fonte: thoughtworks, 2015.

2.2 Tipos de Monitoramento

Com a evolução dos recursos computacionais e por consequência disso a

evolução das arquiteturas de softwares, cada vez mais identificar falhas prematuras
e possíveis otimizações de software são encarados como fator crítico para que
empresas economizem com gastos que poderiam ser evitados. Afinal, toda falha
tem um custo, e todo custo pode ser reduzido. Será exposto a seguir alguns tipos de
monitoramento que mais se aproximam nativamente ao universo do Kubernetes,
são eles: Tempo de atividade, Monitoramento de desempenho, Monitoramento de
recursos, Monitoramento de log.

2.2.1 Monitoramento por Tempo de Atividade

O monitoramento por Tempo de atividade, é um dos mais básicos e consiste

em mandar requisições para um endereço previamente configurado. Basicamente o
desenvolvedor/analista configura o endereço para onde será feita a requisição, a

21
porta de destino, o path da requisição, a resposta esperada pela requisição e um
timer para que se repita. É de costume e boa prática que sejam criados paths para
health-check da aplicação que tenham um retorno simples, as vezes apenas um
STATUS 200 na requisição HTTP. Geralmente são utilizadas aplicações como
zabbix​, ​appbeat,​ ​pingdom,​ ​uptime e muitas outras soluções. Para Kubernetes há um
componente nativo do próprio sistema que pode ser configurado para desempenhar
esse papel e chama-se readinessprobe.

Figura 2.6. Foto do log do monitoramento do estado de uma aplicação no

Kubernetes

De acordo com a Figura 2.6, é possível notar o ​output de uma aplicação do

nginx8 que estava rodando expondo os ​outputs de monitoramento do kubernetes
para entender o estado a aplicação. Caso a resposta seja diferente da estipulado,
no exemplo 200, o status da aplicação muda para ​failed​.

2.2.2 Monitoramento de Desempenho

Partindo do princípio de que o monitoramento do tempo de atividade (tópico

2.1.1) garante que a aplicação está sempre operacional, não significa que os
usuários estão tendo uma boa experiência. Possíveis demoras para devolver uma
resposta a suas ações, lentidão para navegação podem frustrar a experiência do
usuário. Para isso, o Monitoramento de desempenho é utilizado como forma de
mitigar esses gargalos.
Esta técnica consiste em analisar cada trecho ou método contido no código
fonte, buscando compreender sua performance/tempo de resposta. No caso de um

8
URL: ​https://www.nginx.com/​. Último acesso em 30/06/2019.

22
loop quantas repetições acontecem, quanto de memória está sendo consumido, e
se é factível que aconteçam ​overflows​. Os relatórios e ​traces capturados são
utilizados como base para as possíveis mudanças, com o intuito de garantir o
melhor desempenho do software.
Para Kubernetes não há nenhuma solução nativa. Isto não significa que não
dê para se fazer, por exemplo, se configurarmos o Ingress Nginx podemos
identificar o tempo de resposta para cada requisição e com base nos logs tomar as
devidas medidas para solucionar o problema. Existem também diversas ferramentas
onde pode-se o uso desta técnica como por exemplo: ​Java Profilers,​ JHM, ​Java
Application Performance Management​ (APM).

Figura 2.7. Foto do monitoramento do tempo de resposta de uma aplicação no

kubernetes

Na Figura 2.7 é possível observar o tempo de resposta para a média de

requisição em milissegundos de acordo com um range de horário, no caso
específico da Figura 2.7 o range foi estipulado em 1 hora.

2.2.3 Monitoramento de Recursos

Analisar a quantidade de Recurso que está sendo dedicado ao software é

uma peça fundamental para garantir sua estabilidade. Definir pontos máximos e
mínimos de consumo de CPU/Memória ou disco de sistemas distribuídos podem ser
um fator chave para sua escalabilidade. Seja ela horizontal, onde são adicionadas

23
novas réplicas idênticas que executam o mesmo papel das já existentes. Seja ela
vertical, onde são elevados os pontos de máximo e mínimo de consumo de
CPU/Memória ou disco.
Para fazer este monitoramento é necessário atentar sempre ao consumo
atual dos recursos de cada microsserviço do sistema, identificando futuros pontos
de elevação de uso. Como, por exemplo, no caso de ​black fridays,​ onde as
empresas preparam seus sistemas para crescer de forma ordenada,
desordenadamente.
No Kubernetes, o monitoramento do cluster é feito por meio do ​metric-server9
onde é possível coletar algumas informações sensíveis referentes às aplicações
embarcadas que estão rodando, como consumo de CPU, Memória, tráfego de rede
e com base nessas informações criar o escaladores horizontais de pods10.

Figura 2.8. Foto da quantidade de recurso consumido por pod no kubernetes

Na Figura 2.8 nota-se que são informadas instâncias de uma aplicação

fluentd, a qual apresenta o consumo em tempo real de CPU em cores e Memória
em bytes. De acordo com o caso anterior 1000m correspondem a 1 core e 1000Mi
correspondem a 1 Mega segundo a documentação oficial do Kubernetes na seção
de ​Managing Compute Resources for Containers.​

2.2.4 Monitoramento de Log

O Monitoramento dos logs de um sistema é imprescindível para a

identificação de falhas e onde elas ocorreram. Programadores usam do artifício

9
URL: ​https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/​. Último
acesso em 30/06/2019.
10
URL: ​https://kubernetes.io/docs/concepts/workloads/pods/pod/​. Último acesso em 30/06/2019.

24
colocando alguns ​outputs do sistema para facilitar a detecção de possíveis erros.
Fora isso alguns outros artifícios de linguagens compiladas podem ser utilizados
para que quando erros aconteçam, sejam indicados qual linha, em qual método e
qual o motivo do erro.
Quando lidamos com sistemas distribuídos, identificar de qual serviço/ori é o
log e onde centralizar os logs destes serviços é um ponto chave para identificação
do problema e tomada de decisão eficiente.
Seguindo as boas práticas no Kubernetes, os logs devem ser armazenados
de forma centralizada guardando sempre as referências de qual serviço eles vieram,
permitindo assim aplicar filtros para facilitar essa análise. Estes filtros podem ser por
tipo de ​output(stdout, stderr),​ conteúdo da mensagem de log, deployment o qual
pertencia o log.
Existem diversas soluções para essa problemática no kubernetes, algumas
delas são: a Stack EFK(Elasticsearch11, Fluentd12, Kibana13), beats do elasticsearch
dentre várias outras soluções.

2.3 Sumário do Capítulo

Este capítulo teve como objetivo apresentar alguns dos tipos de
monitoramento mais utilizados para aplicações, tanto antes de executa-las em
Kubernetes quanto depois. Mostrando os tipos de falhas que podem ser
identificadas por cada uma, e como elas identificam a existência de anomalias.
Neste contexto, o próximo Capítulo apresenta algumas soluções de
monitoramento já existentes e uma visão geral de como cada uma funciona, adoção
da comunidade, pontos fortes e fracos.

11
URL: ​https://www.elastic.co/​. ​Último acesso em 13/06/2019.
12
URL: ​https://www.fluentd.org/​. ​Último acesso em 13/06/2019.
13
URL: ​https://www.elastic.co/products/kibana​. ​Último acesso em 13/06/2019.

25
3. Análise das Soluções Utilizadas no Trabalho

Para este trabalho foram adotadas as soluções citadas ao fim do capítulo

anterior, sendo elas: a Stack EFK (Elasticsearch, Fluentd, Kibana), beats do
elasticsearch e uma solução desenvolvida pelo autor deste trabalho.
Com o intuito de abordar estas 3 soluções, este capítulo está divido em 4
seções, uma delas destinada a forma como os ​logs devem ser coletados no
Kubernetes e as demais destinadas para a análise das soluções. Nas seções
destinadas as soluções serão apresentados os seus pontos positivos e negativos,
adoção da comunidade, linguagem utilizada para desenvolvimento e uma breve
análise da arquitetura.
Antes de tudo, vale ressaltar que existem dois pontos em comum entre todas
as soluções utilizadas que é o banco de dados, o elasticsearch, e o Kibana que é
um ​framework open-source ​ mpregado
e para visualização de dados do
elasticsearch.
O Elasticsearch é um banco de dados não relacional, orientado a
documentos, comumente utilizado para fazer consultas complexas em cima de
grandes volumes de dados[16].

3.1 Monitoramento de Logs no Kubernetes

Com a possibilidade de distribuir as aplicações em diferentes ​vm’s rodando

em diferentes ambientes, a forma sugerida pela documentação oficial do
Kubernetes[17] para coleta de ​logs no Kubernetes é levantar um agente/operador
em cada ​node​ onde existam aplicações rodando no cluster.
Basicamente cada agente fica responsável por coletar os logs de cada
contêiner que estejam rodando na ​vm e direcionar para um um ​backend​. ​Backend
esse que fica responsável por esta centralização dos logs.
A Figura 3.1, retirada da documentação oficial do Kubernetes, ilustra a forma
como o cenário anterior deve ser implementado.

26
 Figura 3.1. Agente para coleta de logs dos nós.

Na Figura 3.1 é ilustrado o processo de como devem ser feitas as coletas de

logs no Kubernetes, analisando da ótica de um operador.

3.2 Fluentd

Fluentd é uma solução ​open source desenvolvida para centralização de ​logs

[18][19], que busca armazenar os dados em forma de JSON14 como forma de
facilitar as consultas e agrupamentos que podem ser feitos nos bancos de dados.
Sua configuração não é feita de forma trivial, tendo uma variedade grande de
parâmetros que podem ser configurados. E dentre as soluções apresentadas é a
mais desafiadora de configurar em ambientes produtivos, devido a diversidade de
integrações de plugins e a diferença na forma como são configurados. Por exemplo:
configurar onde serão salvas as informações, a ferramenta de alerta e outros varios
plugins15.
Desenvolvida na linguagem de programação Ruby16, e no dia 23/06/2019
tinha 7.983 estrelas no github e 207 ​issues​ abertas.
A Figura 3.2 apresenta de forma simplória e resumida sua arquitetura.

14
URL: ​https://tools.ietf.org/html/rfc7159​. ​Último acesso em 23/06/2019.
15
URL: ​https://www.fluentd.org/plugins​. ​Último acesso em 09/07/2019.
16
URL:​https://www.ruby-lang.org/pt/documentation/​. ​Último acesso em 23/06/2019.

27
 Figura 3.2. Arquitetura do Fluentd.

A Figura 3.2 busca ilustrar as possíveis integrações para a ferramenta,

abordando desde de tipos de dados, configuração de buffer, rotas, filtros. Expondo
também integração com ferramentas de alertas como Nagios17.

3.3 Beats

O Beats faz parte do grupo do elasticsearch, e é responsável pela tecnologia

de monitoramento de aplicações. É facilmente integrável com o logstash18 e com o
banco de dados elasticsearch. Desenvolvida na linguagem de programação GO19, e
no dia 23/06/2019 tinha 7.414 estrelas no github e 1.180 issues abertas.
Dentro do agrupamento do beats há o metricbeat e o Filebeat. O Metricbeat é
a solução voltada para coleta de métricas das aplicações, e o Filebeat é a solução
utilizada para monitoramento dos ​logs dos contêineres[20]. Ambas são ​open source
e assim como o Fluentd armazenam os ​logs​ em forma de JSON.
Um diferencial do Beats é que o Kibana já vem com um dashboard pronto
para visualização das métricas coletadas [21], basta apenas importá-lo na página
inicial do Kibana. Na contramão das facilidades, as ferramentas do Beats

17
URL: ​https://www.nagios.org/​. ​Último acesso em 23/06/2019.
18
URL: ​https://www.elastic.co/products/logstash​. ​Último acesso em 23/06/2019.
19
URL: ​https://golang.org/doc/​. ​Último acesso em 23/06/2019.

28
consomem cerca de 80MB de memória a mais que o Fluentd por operador, o que
em um servidor com 1000 máquinas pode chegar a 80GB [22].
A Figura 3.3 apresenta a forma como o beats armazena as informações,
juntamente com a utilização de alguns filtros destacados.

Figura 3.3. Armazenamento das informações Beats

A Figura 3.3 mostra a granularidade das informações coletadas de uma

aplicação rodando no Kubernetes pela solução filebeat, pertencente ao Beats.

3.4 Problemas das Soluções apresentadas

Analisando as informações apresentadas nas 2 seções anteriores é notório

que as soluções apresentadas, por serem operadores, precisam estar rodando em
todos os ​workers de todos os ​clusters onde se faça necessário o monitoramento.
Outro ponto que é de importante ressalva está no fato de que são coletadas muitas
informações por vez. Pode-se encarar como um ponto positivo pelo fato de trazer
uma granularidade e diversidade maior de informações a respeito das aplicações,
porém, muitas das informações estão repetidas como por exemplo: nome da
​ iversas formas de se extrair informações como o
aplicação. Porém, existem ​N d
nome nos outros dados coletados. Se o intuito for apenas coletar as informações de
consumo de recursos computacionais e de rede acaba por ser a utilização de uma
solução complexa de monitoramento para a resolução de um problema simples.

3.5 MangueBeat

29
 O MangueBeat foi uma solução desenvolvida, pelo autor deste trabalho, em
NodeJS20, cuja propriedade intelectual pertence a Ustore21. Além disso, a Ustore
mantém o agente em código fechado e de uso interno.
Ao contrário das demais soluções o MangueBeat integra-se com o servidor
de métricas mantido pelo Kubernetes, não precisando ser um operador rodando em
cada ​node do ​cluster​. O fato de não ser um operador reduz drasticamente seu
consumo de recursos computacionais por ​node no cluster, visto que são
necessárias apenas uma instância do MangueBeat operacional para que o
monitoramento seja feito. O que implica diretamente no custo financeiro para manter
a infraestrutura do cluster.
Sua configuração é feita por meio de variáveis de ambiente, definindo por
exemplo: tempo entre o intervalo da coleta das métricas, servidor onde está o
elasticsearch, servidor onde está o servidor de métricas.
Além disso, o serviço de monitoramento do MangueBeat possibilita o
monitoramento de mais de um cluster por vez, podendo haver a centralização do
agente de monitoramento, e salvando as informações de forma descentralizada.
Podendo partir para abordagens como, criar um cluster dedicado para
monitoramento, alocar ​resource quotas [​ 23] e
​ specíficas para o ​namespace22 de
monitoramento.

20
URL: ​https://nodejs.org/en/docs/​. Ú​ ltimo acesso em 23/06/2019.
21
URL: ​http://ustore.com.br/​. Ú
​ ltimo acesso em 23/06/2019.
22
URL: ​https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/​. ​Último
acesso em 23/06/2019.

30
 Figura 3.4. Arquitetura de monitoramento MangueBeat

A Figura 3.4 ilustra o cenário do agente do MangueBeat coletando métricas

de consumo de recursos computacionais e de rede de múltiplos clusters integrados
a solução.
Como o MangueBeat integra-se apenas com o servidor de métricas, seu uso
fica restrito apenas a coleta de informações como consumo de CPU, memória e
rede das aplicações.
Um ponto interessante para a solução do MangueBeat é a facilidade de
integração como outros microsserviços, para que sejam feitos por exemplo, alertas
em caso de anomalias. Para o caso citado anteriormente de alertas, foi
desenvolvida uma integração com um TelegramBot23, onde são enviados alertas
informando anomalias nos microsserviços e são possíveis a execução de algumas
operações com base nas métricas coletadas.
Para enviar as mensagens foi desenvolvido uma Função como
Serviço(​FaaS)​ [24] que fica encarregada de enviar as mensagens ao telegram, essa
função deve receber como parâmetros o ​ChatID,​ a mensagem e o token de
segurança do bot. Este último parâmetro pro segurança deve ser criado como ​secret
24
no Kubernetes[25].

23
URL: ​https://telegram.org/blog/bot-revolution​. ​Último acesso em 23/06/2019.
24
URL: ​https://kubernetes.io/docs/concepts/configuration/secret/​. ​Último acesso em 23/06/2019.

31
 Figura 3.5 Scale e informações de deployment via TelegramBot

A Figura 3.5 busca ilustrar o processo de notificação de excesso de consumo

de memória por um ​mysql25 e o processo de scale de um microsserviço monitorado
pelo MangueBeat.

3.6 Sumário do Capítulo

25
URL: ​https://www.mysql.com/​. Ú
​ ltimo acesso em 23/06/2019.

32
 Este capítulo teve como objetivo mostrar como a documentação oficial do
Kubernetes sugere que o monitoramento de métricas e ​logs devem ser feitos no
orquestrador, e como as ferramentas analisadas por este trabalho funcionam.
Buscando uma abordagem mais visual para a análise do que cada solução
contempla foi desenvolvida a Tabela 3.1.

Logs CPU Memória

Beats X X X

Fluentd X X X

MangueBeat X X

Tabela 3.1. O Escopo de cada solução de monitoramento

A partir da Tabela 3.1 fica claro que a ferramenta do Manguebeat ao contrário
das demais soluções não contempla o monitoramento de Logs das aplicações de
um cluster Kubernetes.
Foi analisado também durante o capítulo a adoção pela comunidade,
arquitetura, linguagem de programação que a solução foi desenvolvida, formato que
as informações são salvas nos bancos de dados.
Neste contexto, o próximo Capítulo apresenta como o ambiente utilizado
nesta pesquisa foi configurado tanto na parte de ​hardware como ​software.
Mostrando como configurar cada solução no orquestrador.

33
4. Configuração

Durante o desenvolvimento deste capítulo, serão demonstradas como foram

feitas as implementações das soluções de monitoramento, a configuração do
ambiente utilizado e fazendo ressalvas sobre os melhores cenários para o uso das
soluções aqui apresentadas.

4.1 Configurações de Ambiente

Nesta seção serão abordadas as escolhas para a configuração do ambiente

onde serão implementadas as soluções, dividida em 2 sub-seções sendo elas
respectivamente ​Configuração de Hardware ​e​ Configuração de Software.

4.1.1 Configuração de Hardware

Para configuração de Hardware do ambiente foram utilizadas seis ​VM’S.

​ orker.
Sendo três delas no papel Master e três delas no papel de​ W
A opção por manter um cluster com seis máquinas virtuais deve-se ao fato de
garantir alta disponibilidade ao cluster em caso de falha em algum dos nós.

CPU 4 Cores

Memória RAM 8 GB

Disco 50 GB

Tabela 4.1. Configuração de Hardware

4.1.2 Configuração de Software

Para a configuração de Software, será apresentada na tabela a seguir as

escolhas para a apresentação deste trabalho.

34
Sistema Operacional Ubuntu Server 16.04

Etcd v3.2.18

Kubernetes API Server v1.11.3

Kubernetes Controller v1.11.3

Kubernetes Scheduler v1.11.3

Kubelet v1.11.3

Kube Proxy v1.11.3

Docker 17.06

Elasticsearch 6.5.0

MetricBeat 7.1.1

Kibana 6.4.3

Fluentd v1.0

MangueBeat v0.9
Tabela 4.2. Configuração de Software

A escolha por utilizar o docker na versão 17.06 foi feita pelo fato de ser a
versão mais estável para o Ubuntu Server 16.04 segundo a documentação oficial do
docker[26]. A versão escolhida para o Kubernetes foi a v1.11.3 por ter sido
aproveitado um cluster já pronto para testes de soluções do autor deste trabalho.

4.2 Configuração das Soluções utilizadas

Durante esta seção serão apresentadas a forma como as soluções foram

implementadas, as escolhas de versões, e os arquivos de configuração utilizados
para montar o ambiente.
Para estas implementações foram utilizadas apenas um ​namespace no
Kubernetes onde ficaram dispostas todas as soluções.

35
 Os arquivos utilizados para deploy das ferramentas de monitoramento e do
banco de dados encontram-se no pastebin26.

4.3 Sumário do Capítulo

Este capítulo teve como objetivo apresentar as configurações de ​hardware

para o ambiente utilizado, apresentando um cenário para alta disponibilidades e as
configurações de ​software para que fossem possíveis as instalações das
ferramentas no Kubernetes .
Neste contexto, o próximo Capítulo apresenta um comparativo das soluções
analisadas buscando identificar os diferenciais de cada uma, e em que cenário elas
teriam sua melhor performance.

26
URL: ​https://pastebin.com/X1FJcZmB​. Último acesso em 09/07/2019.

36
5. Comparando as Soluções

Partindo para uma análise das soluções apresentadas fica evidente que
existem diversas formas para implementar e manter o monitoramento de aplicações
no cenário de sistemas distribuídos em Kubernetes.
Vendo pelo ponto de vista de alocação dos sistemas de monitoramento em
VM’S é possível identificar 2 possibilidades: a instalação de operadores em cada
Worker ou a integração do sistemas de monitoramento ao servidor de métricas do
Kubernetes. As soluções do Beats e o Fluentd utilizam dos operados nos ​workers
como mecanismo de coleta de logs e métricas, coletando periodicamente os dados
e salvando-os no banco de dados. Já a solução do MangueBeat, é integrada ao
servidor de métricas do Kubernetes, sendo assim, necessita apenas de uma
instância operacional para monitorar as aplicações.
Analisando por esta ótica, pode-se fazer uma análise de consumo de CPU,
Memória e Network por unidade de monitoramento (​operators e servidores de
monitoramento) utilizando as métricas coletadas por eles. No gráfico abaixo são
sumarizadas as soluções e as suas respectivas médias de consumo em um
intervalo de 30 minutos, para clusters com uma média de 10 aplicações
instaladas(​backends,​ ​frontends e bancos de dados). Para o caso do Beats não
foram usadas todas as soluções de monitoramento, apenas o MetricBeat e o
Filebeat.

37
 Figura 5.1. Informações de consumo de CPU por instância.

Figura 5.2. Informações de consumo de Memória por instância.

38
 Figura 5.3. Informações de consumo de Rede por instância.

A partir dos gráficos 5.1, 5.2 e 5.3 é notório que as soluções Beats e Fluentd
consomem mais recursos computacionais e de rede que a ManguetBeat. Vale
ressaltar que essa quantidade de recurso é por unidade de monitoramento, sendo
assim para o Beats e Fluentd o consumo total de recurso seria a multiplicação da
quantidade de ​VM’S workers por quantidade de recursos computacionais e rede.
Logo, seguindo as instruções anteriores e a documentação oficial do Kubernetes27 é
possível obter a seguinte equação:

Σ = Qtd Recursos * QtdV M

Qtd Recursos = quantidade de recurso | QtdVM = quantidade de vms workers

Partindo para a análise da granularidade das informações capturadas por

cada ferramenta, observa-se que as soluções do Beats e Fluentd apresentam um
alto grau de detalhamento apresentando desde informações como a VM a qual a

27
URL: ​https://kubernetes.io/pt/docs/home/​. Último acesso em 09/07/2019.

39
aplicação está até o tempo que a aplicação está rodando, Logs, métricas de
recursos computacionais. Já a solução MangueBeat atém se apenas na coleta de
métricas do consumo de recursos computacionais como CPU, Memória e de rede.
Pelo fato da ferramenta desenvolvida pelo autor ater-se apenas para o
monitoramento mais a fundo dos consumos de recursos computacionais e de rede,
pode-se justificar a disparidade encontrada no consumo de recursos da ferramenta.
Vale ressaltar que em um cenário de múltiplos clusters, onde há a
necessidade de monitoramento de recursos de computacionais e de rede,
unicamente, a solução do MangueBeat pode ser encarada como unanimidade. Visto
que, seria necessário apenas uma instância em alta disponibilidade do serviço de
monitoramento para monitorar todos os clusters.
Outro caso interessante é a facilidade de integração com serviços de
terceiros ou implementação de funcionalidades simples como de alerta. No caso da
ferramenta do MangueBeat podem ser cadastrados alertas via TelegramBot para
avisar a permanência acima da média dos recursos de uma aplicação do cluster.

40
6. Conclusão e Trabalhos Futuros

Este capítulo apresenta a conclusão deste trabalho e perspectivas de

trabalhos futuros, dividido em 2 seções. A primeira referente a conclusão e a
segunda apresentará abordagens para possíveis trabalhos futuros.

6.1 Conclusão

Os conceitos básicos para o desenvolvimento deste trabalho foram vistos,

tais como a evolução das máquinas até a atualidade, alguns tipos de
monitoramento, o problema da segmentação em detalhes e uma proposta de
solução voltada para centralização de logs de aplicações distribuídas em
Kubernetes em um ou mais clusters.
Todo esse conhecimento descrito, aliado a conhecimento técnico adquirido
ao longo do curso e em atividades extra-curriculares, tornaram possível a
implementação de um agente que consuma menos recurso computacional que as
soluções mais comumente utilizadas para monitoramento em Kubernetes.
Para o desenvolvimento deste trabalho focou-se na granularidade das
informações coletadas aliando o consumo de recursos computacionais por
microsserviços. Ficou claro que agentes de monitoramento em forma de operadores
acabam por consumir muito mais recursos do cluster, do que, uma solução capaz
de centralizar o monitoramento dos recursos de CPU, Memória e rede no próprio
servidor de métricas do Kubernetes.
Outro ponto importante analisado durante o desenvolvimento da solução é
que no caso do agente que aponta para o servidor de métricas do Kubernetes é
possível que ele faça o monitoramento de múltiplos clusters a partir de uma única
instância operacional do agente. Evitando assim que para todo novo cluster seja
necessária a instalação de um nova ferramenta de monitoramento.

41
6.2 Limitações

Para as análises realizadas durante o desenvolvimento deste trabalho, foram

levados em consideração 5 clusters Kubernetes, com no máximo 36 ​nodes Workers.
Seria interessante uma análise com mais clusters Kubernetes cadastrados e mais
nodes workers, para que pudessem ser validados cenários onde a carga de
processamentos e tráfego de rede fossem maior. Porém, devido ao fato de serem
difíceis de conseguir recursos computacionais para que essa análise fosse feita,
este trabalho não contemplou esta abordagem.

6.3 Trabalhos Futuros

Olhando para um cenário de trabalhos futuros podem ser feitas a utilização

das métricas para derivações de soluções do MangueBeat. Nesta seção serão
apresentados dois tópicos detalhando possíveis trabalhos.

1. ​Modelo de negócio voltado para ​Platform as a Service(​ PaaS)

O Intuito desta proposta de trabalho futuro é inovar no modelo de tarifação
por infraestrutura como serviço, alavancando uma nova forma de bilhetagem para
aplicações em produção. Será feita a utilização das métricas coletadas pela solução
do MangueBeat para construir um modelo de negócio voltado para ​Platform as a
Service(​ PaaS) onde seriam tarifados o consumo de recursos das aplicações.
Viabilizando assim, uma redução de custos para consumo de infraestrutura como
serviço.
2. Uso das métricas para propor escalabilidade vertical ou horizontal de
aplicações
Através das coletas das métricas pelo MangueBeat, pode ser desenvolvida
uma ferramenta que quando acoplada a solução de métricas faça uma série de
análises de picos de consumo de recursos computacionais, identificando pontos de
inflexão e propondo caso necessária uma escalabilidade vertical, ou seja, o

42
aumento do consumo de recursos destinado à aplicação ou uma escalabilidade
horizontal, ou seja, aumentar a quantidade de instâncias da aplicação sendo
executadas no orquestrador.

43
7. Referências

[1] ​ANDR​É VASCONCELOS CARRUSCA. Gestão de micro-serviços na cloud e

edg​e. Gesto de micro-serviços na cloud e edge. Lisboa, 14 jul. 2018​.
[2] ​MICHAEL ELDER. ​Kubernetes in the enterprise : Deploying and Operating
Production Applications on Kubernetes in Hybrid Cloud Environments. New York,
Eua, 27 sep. 2018.
[3] ​BUYYA, Rajkumar; RODRIGUEZ, Maria A.; TOOSI, Adel Nadjaran.
Cost-Efficient Orchestration of Containers in Clouds: A Vision, Architectural
Elements, and Future Directions. ​2015. 13 f. Tese (Doutorado) - Curso de
Computing And Information Systems, School Of Computing And Information
Systems The University Of Melbourne, Melbourne, 2015 .
[4] ​GADELHA, Julia. ​A EVOLUÇÃO DOS COMPUTADORES. ​2016. 1 v.
Monografia (Especialização) - Curso de Ciência da Computação, Universidade
Federal Fluminense, Rio de Janeiro, 2016. Disponível em:
<http://www2.ic.uff.br/~aconci/evolucao>. Acesso em: 23 jun. 2019.
[5] ​ANDRÉ DE CARVALHO. ​Introdução à computação - hardware, software e
dados.​ Brasil, 20 nov. 2016.
[6] ​NELSON DE OLIVEIRA. ​Geração 90. manuscritos de computador. Brasil, 01
jan. 2006.
[7] IBM Archives​. Disponível/ em:
<https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7030.html>
Acesso em: 23 jun 2019.
[8] Wikipédia: a enciclopédia livre​. Disponível em:
<https://pt.wikipedia.org/wiki/PDP-8> Acesso em: 23 jun 2019.
[9] Histórico e Evolução dos computadores​. Disponível em:
<https://histricoeevolucaodoscomputadores.wordpress.com/2016/> Acesso em: 23
jun 2019.
[10] ​ANDRÉ DE CARVALHO. ​Introdução à computação - hardware, software e
dados​. Brasil, 20 nov. 2016.

44
[11] ​Histórico e Evolução dos computadores​. Disponível em:
<https://histricoeevolucaodoscomputadores.wordpress.com/2016/> Acesso em: 23
jun 2019.
[12] ​CHANDLER, A. D. ​Século eletrônico: A história da evolução da indústria
eletrônica e de Informática​. São Paulo: Campus, 2002.
[13] ​COUTINHO, Gustavo Leuzinger. ​Histórico e Evolução Era dos
Smartphones: Um estudo Exploratório sobre o uso dos Smartphones no
Brasil​. 2014. 67 f., Universidade de Brasília, Brasília, 2014.
[14] Wikipédia: a enciclopédia livre​. Disponível em:
<https://pt.wikipedia.org/wiki/Sistema_de_processamento_distribu%C3%ADdo>
Acesso em: 23 jun 2019.
[15] ​JARWAR, Muhammad Aslam; KIBRIA, Muhammad Golam; ALI, Sajjad.
Microservices in Web Objects Enabled IoT Environment for Enhancing
Reusability​. 2017. Hankuk University Of Foreign Studies, Seoul, 2017.
[16] Comparando: Elasticsearch vs MongoDB​. Disponível em:
<https://medium.com/data-hackers/comparando-elasticsearch-vs-mongodb-4b5932c
613d9> Acesso em: 23 jun 2019.
[17] Kubernetes the official documentation​. Disponível em:
<https://kubernetes.io/docs/concepts/cluster-administration/logging/#cluster-level-log
ging-architectures> Acesso em: 23 jun 2019.
[18] ​YANG, Kaichuang. Aggregated Containerized Logging Solution with
Fluentd, Elasticsearch and Kibana​. 2016. 150 v. Monografia (Especialização) -
Curso de Computer Applications, University Of International Relations, Beijing, 2016.
[19] Fluentd vs. Logstash: A Comparison of Log Collectors​. Disponível em: <
https://logz.io/blog/fluentd-logstash/> Acesso em: 23 jun 2019.
[20] ​JAMES HAMILTON. ​Scada statistics monitoring using the elastic stack
(elasticsearch, logstash, kibana)​. Barcelona, Spain, 20 apr. 2017.
[21] Loading the Beats Dashboards. Disponível em:
<https://www.elastic.co/guide/en/beats/libbeat/1.3/load-kibana-dashboards.html>
Acesso em: 23 jun 2019.
[22] Fluentd vs. Logstash: A Comparison of Log Collectors​. Disponível em:
<https://logz.io/blog/fluentd-logstash/> Acesso em: 30 jun 2019.

45
[23] Kubernetes the official documentation. Disponível em:
<https://kubernetes.io/docs/concepts/policy/resource-quotas/> Acesso em: 16 jun
2019.
[24] ​Fox, Geoffrey & Ishakian, Vatche & Muthusamy, Vinod & Slominski, Aleksander.
(2017). ​Status of Serverless Computing and Function-as-a-Service(FaaS) in
Industry and Research​. 10.13140/RG.2.2.15007.87206.
[25] Building a Telegram Message Sender with OpenFaaS. Disponível em:
<https://medium.com/@lucasscassad/building-a-telegram-message-sender-with-ope
nfaas-1b7a5138998c> Acesso em: 16 jun 2019.
[26] Docker the official documentation. Disponível em:
<https://docs.docker.com/v17.09/engine/installation/linux/docker-ce/ubuntu/#set-up-t
he-repository> Acesso em: 16 jun 2019.

46