tccV-10.tex

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Universidade Federal de Santa Catarina             
% Biblioteca Universitária                     
%----------------------------------------------------------------------
% Exemplo de utilização da documentclass ufscThesis
%----------------------------------------------------------------------                                                           
% (c)2013 Roberto Simoni (roberto.emc@gmail.com)
%         Carlos R Rocha (cticarlo@gmail.com)
%         Rafael M Casali (rafaelmcasali@yahoo.com.br)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{ufscThesis} % Definicao do documentclass ufscThesis	


%----------------------------------------------------------------------
% Pacotes usados especificamente neste documento
\usepackage{graphicx} % Possibilita o uso de figuras e gráficos
\usepackage{color}    % Possibilita o uso de cores no documento
\usepackage{listings}
\usepackage{algorithm2e}
\usepackage{float}
%----------------------------------------------------------------------
% Comandos criados pelo usuário
\newcommand{\afazer}[1]{{\color{red}{#1}}} % Para destacar uma parte a ser trabalhada
\newcommand{\ABNTbibliographyname}{REFERÊNCIAS} % Necessário para abnTeX 0.8.2
%----------------------------------------------------------------------
% Identificadores do trabalho
% Usados para preencher os elementos pré-textuais
\instituicao[a]{Universidade Federal de Santa Catarina} % Opcional
\curso[o]{Ciências da Computação}
\documento[a]{Trabalho de conclusão de curso} % [o] para dissertação [a] para tese
\titulo{Proposta de um modelo autônomo para monitoramento de ambientes de computação em nuvem }
\subtitulo{} % Opcional
\autor{Pedro Henrique Pereira Martins}
\grau{Bacharel em Ciências da Computação}
\local{Florianópolis} % Opcional (Florianópolis é o padrão)
\data{22}{julho}{2016}
\orientador[Orientador\\Universidade Federal de Santa Catarina]{Prof. Dr. Carlos Becker Westphall}
\coorientador[Coorientador\\Universidade Federal de Santa Catarina]{Me. Rafael Weingärtner}
\coordenador[Coordenador\\Universidade Federal de Santa Catarina]{Prof. Dr. Carlos Becker Westphall}

\numerodemembrosnabanca{4} % Isso decide se haverá uma folha adicional
\orientadornabanca{nao} % Se faz parte da banca definir como sim
\coorientadornabanca{sim} % Se faz parte da banca definir como sim
\bancaMembroA{Profa. Dra. Carla Merkle Westphall\\Universidade Federal de Santa Catarina } %Nome do presidente da banca
%\bancaMembroB{Segundo membro\\Universidade ...}      % Nome do membro da Banca
%\bancaMembroC{Terceiro membro\\Universidade ...}     % Nome do membro da Banca
%\bancaMembroD{Quarto membro\\Universidade ...}       % Nome do membro da Banca
%\bancaMembroE{Quinto membro\\Universidade ...}       % Nome do membro da Banca
%\bancaMembroF{Sexto membro\\Universidade ...}        % Nome do membro da Banca
%\bancaMembroG{Sétimo membro\\Universidade ...}       % Nome do membro da Banca

\dedicatoria{Este trabalho é dedicado aos meus colegas de classe e aos meus queridos pais.}

\agradecimento{Inserir os agradecimentos aos colaboradores à execução do trabalho.}

\epigrafe{Texto da Epígrafe. Citação relativa ao tema do trabalho. É opcional. A epígrafe pode também aparecer na abertura de cada seção ou capítulo.}
{(Autor da epígrafe, ano)}

\textoResumo {No cenário atual as ferramentas de orquestração de ambientes de computação em nuvem como Apache CloudStack, OpenStack e outras não possuem um módulo nativo de monitoramento do ambiente. Para monitorar o ambiente de computação em nuvem, são utilizadas normalmente extensões destas ferramentas ou outras aplicações como Nagios, Zenoss e outras que satisfazem parcialmente a necessidade de monitoramento. Contudo, estas ferramentas são incompletas ou possuem outros problemas como dados incorretos, violam as máquinas virtuais dos usuários (injetando scripts ou aplicações nas máquinas virtuais) além de possuírem uma deficiência de autonomia. Logo, os administradores do ambiente precisam ficar monitorando constantemente o ambiente para conseguir configurar a ferramenta de monitoramento para se adequar ao ambiente monitorado. Esta proposta consiste em especificar e implementar uma plataforma autônoma para monitorar a infraestrutura de ambientes de computação em nuvem.
	Palavras-chave:}
\palavrasChave {Computação em nuvem. Monitoramento autônomo. Apache CloudStack. Plataforma de monitoramento.}

\textAbstract {Cloud computing orchestration tools such as Apache CloudStack, OpenS- tack and others do not have a comprehensive native monitoring module. To monitor the cloud environment we normally use plugins or applications such as Nagios, Zenoss, and others that satisfy partially the monito- ring needs. However, they are incomplete or have problems such as accuracy, intrusiveness ( injecting scripts or applications in the users virtual machine), and a lack of autonomy. Therefore system ad- ministrators have to constantly monitor and configure all of the aplications/plugins parameters to best fit the environment. The goal of this proposal is the specification and development of an autonomous monitoring platform for cloud computing infrastructure.}
\keywords {Cloud computing. Autonomous monitoring. Apache CloudStack. Monitoring Platform.}
\usepackage{array}
\newcolumntype{L}[1]{>{\raggedright\let\newline\\\arraybackslash\hspace{0pt}}m{#1}}
\newcolumntype{C}[1]{>{\centering\let\newline\\\arraybackslash\hspace{0pt}}m{#1}}
\newcolumntype{R}[1]{>{\raggedleft\let\newline\\\arraybackslash\hspace{0pt}}m{#1}}

%----------------------------------------------------------------------
% Início do documento                                
\begin{document}
	\graphicspath{{C:/Users/Pedro Henrique/Desktop/modelo/figuras}}
	%--------------------------------------------------------
	% Elementos pré-textuais
	\capa  
	\folhaderosto[comficha] % Se nao quiser imprimir a ficha, é só não usar o parâmetro
	\folhaaprovacao
	%\paginadedicatoria
	%\paginaagradecimento
	%\paginaepigrafe
	\paginaresumo
	\paginaabstract
	%\pretextuais % Substitui todos os elementos pre-textuais acima
	\listadefiguras % as listas dependem da necessidade do usuário
	\listadetabelas 
	\listadeabreviaturas
	%\listadesimbolos
	\sumario
	%--------------------------------------------------------
	% Elementos textuais
	
	\chapter{Introdução}
	Computação em nuvem vem sendo cada vez mais utilizada devido ao seu modelo permitir um melhor aproveitamento dos recursos de hardware e software, acarretando em redução de custos, melhor eficiência energética, elasticidade, flexibilidade e disponibilidade de recursos por demanda \cite{armbrust2010view} e \cite{singh2011cm}.
	
	Com o aumento da demanda por serviços prestados pela nuvem, há um constante crescimento da infraestrutura de modo a atender a demanda \cite{singh2011cm} e \cite{weingartner2015cloud}. O crescimento constante dos ambientes da nuvem acaba aumentando a complexidade de sua gerência tornando esta inviável de ser realizada por administradores sem auxilio de ferramentas apropriadas \cite{weingartner2015cloud}, \cite{hall2012opportunities} e \cite{urgaonkar2002resource}. 
	
	\citeonline{kephart2003vision} apresentam um modelo de computação autônoma como uma solução para lidar com grandes ambientes computacionais heterogêneos e complexos como ambientes de computação em nuvem.	Adicionalmente \citeonline{kephart2003vision} definem um elemento autônomo constituído de quatro (4) fases, monitoramento, análise, planejamento e execução, onde cada fase depende da anterior. Cada fase é detalhada a seguir.
	\begin{itemize}
		\item Monitoramento: durante este processo são coletadas informações sobre os recursos alocados e utilizados. Este processo é realizado periodicamente de modo a criar um histórico de alocação e uso de recursos;
		\item Análise: após ter os dados coletados, são iniciados os processos de análise em busca de tendências de consumo e comportamento das cargas e problemas referentes a carga que competem por recursos no mesmo servidor físico;
		\item Planejamento: depois de identificar as tendências de comportamento das cargas do ambiente, e possíveis problemas de degradação de serviço, pode-se traçar ações de modo a evitar as degradações de serviço e viabilizar a otimização do ambiente;
		\item Execução: após ter traçado uma sequência de ações serem tomadas é necessário executar todas as ações que foram previamente planejadas de modo a buscar atender aos objetivos do sistema de gerenciamento.
	\end{itemize} 
	
	Os processos descritos anteriormente são executados constantemente, de modo que seja possível para o sistema de gerenciamento identificar o contexto em que se encontra e adaptar-se ao ambiente a ser gerenciado de modo a atender aos objetivos gerenciais.
	
	Uma das necessidades para se efetuar o monitoramento do uso de recursos de ambientes de nuvem se dá para fins comerciais, como cobrança relativa a serviços prestados. O valor a ser cobrado pode ser acordado entre o usuário e o fornecedor de recursos da nuvem ou pode ser pré-definido pelo fornecedor \cite{aceto2012cloud}. Além disso, o monitoramento também pode ser usado para viabilizar técnicas de otimização e auxiliar numa melhor gerência dos ambientes de computação em nuvem. Para viabilizar tais otimizações é importante que o monitoramento forneça dados precisos e em tempo hábil sem afetar o funcionamento da nuvem \cite{aceto2012cloud} e \cite{viratanapanu2010demand}.
	
	O monitoramento em tempo real da nuvem é desafiador. Deve-se levar em conta o grande número de serviços e usuários,  que torna a nuvem um ambiente com um grande volume de informação para ser coletada e analisada \cite{shao2010runtime} e \cite{clayman2010monitoring}. 
	
	Outro fator que contribui para a complexidade de monitorar os ambientes de nuvem é a heterogeneidade dos seus componentes. Ambientes de nuvem são constituídos de diferentes clusters de servidores, cada um com seus respectivos processadores, memória, placa de rede, periféricos e virtualizadores. Deste modo, é necessário implementar meios para monitorar cada um desses elementos distintos \cite{shao2010runtime}. Os elementos que compõem o ambiente de computação em nuvem, podem estar dispersos geograficamente, o que gera a necessidade de ter um sistema de monitoramento distribuído, com nodos colhendo informações em cada elemento e enviando para um repositório de dados.
	
	O processo de monitoramento pode vir a sobrecarregar os recursos da nuvem se não for devidamente implantado, sendo este um dos principais desafios para o monitoramento dos recursos  \cite{shao2010runtime} e \cite{clayman2010monitoring}. Além disso, após implantado o sistema de monitoramento, qualquer modificação necessária deve ser feita sem a necessidade de desligar ou reiniciar o ambiente \cite{clayman2010monitoring}.
	
	Problemas resultantes de um monitoramento mal sucedido são:
	\begin{itemize}
		\item {A queda de desempenho da nuvem devido a sobrecargas de processamento com monitoramento;}
		\item {Ações de gerência mal sucedidas devido a dados inconsistentes advindos do processo de monitoramento;}
		\item {Perda de dados e/ou obtenção de dados corrompidos durante o processo de atualização dos componentes de monitoramento.}
	\end{itemize}   
	
	Atualmente as ferramentas de orquestração de computação em nuvem (levantadas durante o desenvolvimento deste trabalho) em sua maioria, não realizam o monitoramento dos recursos utilizados ou realizam mas não armazenam de modo histórico os dados monitorados. O que estas ferramentas costumam adotar é o monitoramento momentâneo do ambiente para indicar aos administradores o estado corrente deste, sem a criação de um histórico de uso dos recursos. 
	
	Hoje em dia existem ferramentas que realizam o monitoramento e podem ser acopladas a ferramentas de orquestração. Porém são de difícil instalação e dependentes de \abreviatura{API}{\textit{Appication Programming Interface}} APIs (\textit{Appication Programming Interface}) de dos orquestradores que não são completas pois não permitem o monitoramento de uma série de recursos físicos. Algumas ferramentas de monitoramento costumam apresentar dados inconsistentes com o ambiente, além de ser mais uma camada de software para gerenciar.
	
	O Zenoss \cite{zenoss2015} é um exemplo de ferramenta de monitoramento que apresentam alguns problemas. No caso do Zenoss, e sua extensão para monitoramento do Apache CloudStack \cite{cloudstack2015}, o CloudStack ZenPack \cite{CSzenPack2015}, existe um problema no monitoramento de uso de memória do servidor físico. A ferramenta faz uma requisição do uso de memória para o Xen \cite{xenProject2015} e projeta o retorno como se fosse o uso total de memória das máquinas virtuais alocadas no servidor. O problema é que esta requisição do Xen, retorna apenas o uso de memória relativo ao \textit{dom0}. Deste modo o Zenoss acaba fornecendo dados de apenas uma máquina virtual específica e não do servidor monitorado como um todo, o que pode levar a decisões inconsistentes no momento de gerenciamento e otimização dos ambientes.
	
	É necessário fazer uso de boas técnicas de manipulação de dados devido ao grande volume de informações que podem ser monitoradas em ambientes de nuvem. Adicionalmente a ferramenta de monitoramento necessita ser o menos invasiva possível, ou seja, ser invisível para os usuários de ambientes de computação em nuvem. Além disso, deve-se tratar a precisão das informações capturadas, os dados fornecidos devem condizer com o ambiente monitorado \cite{aceto2012cloud}. Quanto mais rápidas as informações sobre o estado do ambiente forem disponibilizadas, mais eficientemente se conseguirá administrá-lo.
	
	\section{Motivação}
	O monitoramento é de fundamental importância para ambientes de nuvem, pois proporciona um melhor entendimento do estado em que o ambiente se encontra, do estado das aplicações que estão hospedadas, do uso/disponibilidade de recursos físicos do ambiente e também para determinar se os acordos de prestação de serviço estão sendo devidamente cumpridos.
	
	Como apresentado em \cite{aceto2013cloud}, existe uma carência de autonomia nas ferramentas de monitoramento atuais. Assim, toda vez que novos recursos são inseridos no ambiente, deve-se informar às ferramentas que tais recursos devem ser monitorados, quando o ideal era a ferramenta detectar e passar a monitorar os recursos autonomamente.
	
	Outro ponto sobre as ferramentas atuais, é que a proposta delas em sua maioria, é monitorar desde a camada de aplicação até o nível de infraestrutura. Com isso, as ferramentas de monitoramento acabam se tornando complexas, com uma instalação complicada e consumindo mais recursos do ambiente do que se fossem específicas para apenas um modelo de serviço de nuvem.
	
	Motivado pela carência de ferramentas de monitoramento  pouco intrusivas, autônomas, com foco apenas na infraestrutura de ambientes de computação em nuvem, compatível com as ferramentas de orquestração atuais e de fácil instalação. Surgiu o interesse no projeto de uma abordagem que supra a necessidade de monitoramento da infraestrutura da nuvem. Dessa forma ferramentas como Apache CloudStack, podem fornecer todo o suporte para o monitoramento da infraestrutura do ambiente de nuvem sem interferência nos serviços por ela já fornecidos de modo autônomo e,  sem configurações adicionais e dependência de administradores dos ambientes de nuvem.     
	
	\section{Objetivos}
	Esta seção irá tratar dos objetivos que este trabalho pretende alcançar.
	\subsection{Objetivo geral}
	
	Este trabalho busca analisar o tema de monitoramento de ambientes de computação em nuvem e elementos autônomos. Com isso, será proposto um modelo de monitoramento autônomo para ambientes de computação em nuvem que fornecem infraestrutura como serviço.
	\subsection{Objetivos específicos}
	
	Os objetivos específicos deste trabalho são:
	\begin{itemize}
		
		\item Levantar trabalhos relacionados e fazer um estudo sobre monitoramento de ambientes de computação em nuvem;
		\item Definir um modelo para realização de monitoramento autônomo de um ambiente de nuvem que forneça infraestrutura como serviço;
		\item Criar um \textit{framework} a partir do modelo definido para viabilizar a implantação em ferramentas de orquestração de nuvem;
		\item Verificar o impacto que o \textit{framework} pode causar no ambiente de nuvem monitorado.
		
	\end{itemize}
	
	\section{Organização do texto}
	
	O conteúdo deste trabalho é disposto nos seguintes capítulos:
	
	\begin{enumerate}
		\item Introdução: apresentação do o trabalho, motivação da escolha do tema, definição dos objetivos e organização do texto;
		\item Fundamentação Teórica: proporciona um conhecimento básico sobre conceitos e tecnologias utilizados para o desenvolvimento do trabalho;
		\item Trabalhos relacionados: apresenta trabalhos cuja proposta seja semelhante à proposta apresentada;
		\item Proposta: é apresentado o problema e uma solução com base nos trabalhos relacionados, Bibliografia científica e ferramentas existentes;
		\item Implementação: capítulo que descreve como a proposta foi implementada;
		\item Conclusão: encerra o trabalho apresentando as contribuições, resultados finais e levantamento de trabalhos futuros.
	\end{enumerate}
	
	\chapter{Fundamentação Teórica}
	Neste capítulo são apresentados os conceitos e tecnologias utilizadas para o desenvolvimento deste trabalho.
	
	
	\section{Computação em Nuvem}
	A computação em nuvem é um modelo ubíquo, conveniente e de acesso compartilhado
	a recursos computacionais como servidores, armazenamento, aplicações e redes \cite{mell2011nist}. Estes recursos compartilhados podem ser rapidamente provisionados e liberados com um esforço mínimo de gestão ou interação com o provedor de serviços \cite{mell2011nist}.
	
	\subsection{Características}
	Em \cite{mell2011nist} são definidas como características básicas de um ambiente de computação em nuvem: 
	\begin{enumerate}{
			\item Acesso aos recursos sob demanda - o usuário pode escolher quais serviços/componentes ele irá usar dentro do que é disponibilizado pela nuvem sem a necessidade de interação com administradores;
			
			\item Disponibilidade - ambientes de computação em nuvem devem estar sempre disponíveis para o usuário pela internet independente da plataforma de acesso ($tablet$, $smartphone$, $desktop$ e outros);
			
			\item Recursos compartilhados - os recursos físicos da nuvem devem poder atender diferentes usuários simultaneamente;
			
			\item Elasticidade - conforme um usuário solicita mais recursos, a nuvem deve alocar mais recursos para este usuário evitando a degradação dos serviços prestados, assim como se um usuário deixar de usar recursos, a nuvem pode remover recursos desnecessários;
			
			\item Monitoramento de serviços - a nuvem deve ser capaz de monitorar o uso de recursos por cada serviço, proporcionando transparência  aos fornecedores e usuários do serviço.}
	\end{enumerate}
	\subsection{Modelos de serviço}
	\citeonline{mell2011nist} descrevem os modelos de serviço disponibilizados pela nuvem como sendo:
	
	\begin{enumerate}
		
		
		\item \textit{Software as a Service} (SaaS) \abreviatura{SaaS}{\textit{Software as a Service}}: o provedor de nuvem fornece uma aplicação final via rede para usuários. O usuário não tem controle algum sobre a infraestrutura que hospeda a aplicação ou da plataforma que a aplicação usa, ele apenas consegue usar a aplicação;
		
		\item \textit{Platform as a Service} (PaaS) \abreviatura{PaaS}{\textit{Platform as a Service}}: são disponibilizadas diferentes plataformas para o usuário desenvolver e hospedar suas próprias aplicações. Neste nível o usuário tem controle total das aplicações, e pode configurar por completo a plataforma. O usuário não possui acesso a recursos do sistema operacional que hospeda a plataforma;
		
		\item \textit{Infrastructure as a Service} (IaaS) \abreviatura{IaaS}{\textit{Infrastructure as a Service}}: a nuvem fornece toda a infraestrutura para o usuário, como processador, disco, memória e rede. Neste nível o usuário tem uma máquina virtual pronta para uso, ele define quais plataformas ele irá usar e quais aplicações ele irá executar em cada plataforma, porém o usuário não tem acesso e controle dos componentes físicos do ambiente.
		
		Cada modelo de nuvem descrito visa um público diferente com diferentes propósitos, o software como serviço visa mais usuários de aplicações. O modelo de plataforma como serviço procura atender os  desenvolvedores que usarão as plataformas para hospedar suas aplicações. Em contrapartida, o modelo de fornecimento de infraestrutura como serviço tem como foco empresas que desenvolvem serviços e os hospedam na infraestrutura de ambientes de computação em nuvem para minimizar seus custos com infraestrutura. Este trabalho tem como foco ambientes de nuvem computacional que atuam fornecendo infraestrutura como serviço.
	\end{enumerate}
	
	\section{Virtualização}
	
	
	
	A virtualização é um processo que foi primeiramente desenvolvido pela IBM com intuito de particionar um \textit{mainframe} com alta capacidade computacional \cite{sahoo2010virtualization}.
	
	 O processo de virtualização consiste na existência de um virtualizador que gerencia sistemas operacionais convidados e intermedeia toda a comunicação entre hardware e esses sistemas \cite{menasce2005virtualization}. Sistemas operacionais convidados são executados sobre o virtualizador como se fossem aplicações em um sistema operacional qualquer. Portanto os sistemas operacionais convidados, não possuem acesso direto aos dispositivos físicos.
	
	
	O uso da virtualização possibilita que os mesmos componentes de hardware suportem diferentes sistemas operacionais como sendo diversas unidades lógicas. Estas unidades lógicas em que o hardware é dividido são nomeadas de \textit{Virtual Machine} (VM)\abreviatura{VM}{\textit{Virtual Machine}}, em português, máquina virtual. Os sistemas operacionais e aplicações dentro das máquinas virtuais detectam esses ambientes como reais. Ao final do processo de virtualização, para o usuário final, ter uma máquina virtual ou uma máquina física não irá mudar sua experiência de uso do computador \cite{sahoo2010virtualization}.
	
	\subsection{Vantagens e desvantagens da virtualização} 
	
	
	A virtualização permite um melhor aproveitamento dos recursos de hardware disponíveis. Permite a alteração de peças de hardware sem a necessidade de parar o funcionamento das VMs por longos períodos, bastando migrar a VM para outro servidor físico. O custo alugar uma máquina virtual em um servidor de computação em nuvem é menor que manter uma máquina física equivalente. \cite{sahoo2010virtualization}. 
	
	Como problemas temos uma sobrecarga de processamento para gerenciar a inúmera quantidade de máquinas virtuais. Além disso o desenvolvimento de virtualizadores não é algo simples e é de grande importância ter redundância de hardwares pois se ocorrer defeito em um componente, todas as VMs vinculadas a tal componente serão penalizadas \cite{popek1974formal} .
	
	\subsection{Tipos de virtualização} 
	
	Nesta seção, serão discutidos os tipos de virtualizações segundo \cite{virtualization2010}, e suas principais características.
	
	\begin{itemize}
		
		\item{Virtualização por contêiner: este tipo de virtualização precisa de um sistema operacional base. Neste caso, o virtualizador irá criar instâncias virtuais do sistema operacional base, isoladas logicamente. Estas instâncias são nada mais que ponteiros para os endereços físicos das rotinas do sistema operacional base. Isto gera um problema que não existe nos outros tipos de virtualização, que é o fato de todas as aplicações das instâncias dividirem os mesmos endereços físicos para suas chamadas de sistema, com isso, se o sistema operacional base for sucetível a algum ataque, uma aplicação maliciosa pode danificar o sistema operacional base, e com isso, prejudicar todas as outras instâncias virtuais desse sistema. Esse tipo de virtualização consome menos memória que as demais, pois usa apenas uma instância física de sistema operacional. Neste tipo de virtualização, os clientes só tem a possibilidade de criar VMs exclusivamente do mesmo tipo do sistema operacional base;}
		
		\item{Virtualização do tipo 1: este tipo de virtualização executa diretamente sobre o hardware, neste caso o virtualizador irá gerar abstrações de hardware completas para poder hospedar um sistema operacional qualquer. Isto cria um consumo extra de memória, pois cada instância irá ter seu próprio sistema operacional em memória. Este tipo de virtualização, possui a melhor performance de uso do processador dentre os tipos aqui apresentados. Neste tipo de virtualização, os clientes podem escolher seus próprios sistemas operacionais para serem instaladas nas VMs;}
		
		
		\item{Virtualização do tipo 2: esta virtualização assim como a virtualização por contêiner, precisa de um sistema operacional como base. Porém nesse caso, o virtualizador irá emular um hardware que será usado pelas instâncias virtuais criadas. Isso possibilita que as instâncias tenham seus próprios sistemas operacionais independentemente de qual é o sistema operacional base. O virtualizador não tem acesso direto ao hardware, podendo assim ser um virtualizador mais simples que da virtualização do tipo 1, já que é o sistema operacional base que irá tratar da comunicação com o mesmo. Esse tipo de virtualização é um meio termo entre a virtualização do tipo 1 e por contêiner.  }
		
	\end{itemize}
	
	Cada tipo de virtualização possui vantagens e desvantagens. O tipo 1, é o mais complexo entre os tipos de virtualização e o com menor penalidade de processamento. O tipo 2 usa um sistema operacional nativo como base para o funcionamento do virtualizador, o que remove parte da complexidade do virtualizador, porém acaba prejudicando o desempenho devido a camada de software extra. A virtualização por contêiner é o tipo com menor uso de memória, porém ela amarra os usuários ao sistema operacional base onde é executado o virtualizador. 
	
	
	
	\subsection{Virtualizadores}
	
	O virtualizador é responsável pela gerência dos recursos de hardware e fornecimento desses recursos para as máquinas virtuais. O responsável de fato pela gerência, criação e destruição das máquinas virtuais, é o \textit{Virtual Machine Monitor} (VMM)\abreviatura{VMM}{\textit{Virtual Machine Monitor}} \cite{vmware2007}. Portanto, toda vez que uma VM é criada, antes, é criado um VMM, e este passa a gerenciar a VM, e destruí-la quando necessário. Logo, existe um VMM para cada VM.  
	
	O Xen \cite{xenProject2015} é um virtualizador do tipo 1 de código aberto disponibilizado pela Citrix \cite{citrix2015}, que da suporte as arquiteturas x86 \cite{x86}, x86 64 \cite{x8664}, IA32 \cite{IA32}, IA64 \cite{IA64} e PowerPC \cite{POWERPC}. 
	As VMs instanciadas com esse virtualizador, são denominadas de domínio sem privilégios (DomU) \cite{xenProject2015domu}. Além disso, existe uma VM que cuida de todo o fluxo de entrada e saída de dados dos DomU, que é denominada de domínio de controle (Dom0) \cite{xenProject2015dom0}. 
	Além de intermediar o acesso a entrada e saída de dados dos DomU, o Dom0 também fornece uma série de comandos para destruir, criar ou modificar cada DomU. Esses comandos de gerência disponibilizados no Dom0, são nativos da biblioteca XL \cite{xenProject2015xl}, porém, são de difícil usabilidade. O Xapi \cite{xenProject2015xapi}, é uma abstração para esses comandos que torna mais simples o uso dos recursos de criação de VMs, clusters e migração de VMs entre servidores de um mesmo cluster.
	
	O KVM \cite{kvm2015} assim como o Xen, é um virtualizador do tipo 1 de código aberto. Suportado pela Red Hat \cite{redhat2015}. O KVM é uma extenção do kernel do linux que permite a criação e gerência de VMs. O KVM usa o QEMU \cite{qemu2015} para emular o hardware que as VMs instanciadas irão usar. Um dos diferenciais do KVM é o fato dele não se preocupar com a gestão de diferentes servidores presentes em cluster, não tendo assim, qualquer custo de processamento para gerência dos servidores em um cluster. Usar esta abordagem no controle dos clusters, torna o KVM dependente de uma ferramenta de orquestração que dê suporte a gerência de servidores dentro de um cluster.  
	
	O ESXi \cite{esxi2015} é um virtualizador de código fechado e licença gratuíta que foi desenvolvido pela VMware \cite{vmware2015}. Tem suporte apenas para arquiteturas x86 de 32 e 64 bits. É um virtualizador do tipo 1. Este virtualizador é usado no vSphere que é uma ferramenta de criação de ambientes de nuvem criada pela VMware. O ESXi só permite a migração de VMs para diferentes servidores em sua versão comercial.
	
	O LXC \cite{lxc2015} é um virtualizador por contêiner gratuito de código aberto suportado pela Canonical \cite{canonical2015}. O LXC da suporte para criação de instâncias de distribuições linux, logo este virtualizador suporta todas as arquiteturas suportadas pelo linux. Instâncias criadas pelo LXC não possuem privilégios de root. O LXC está no repositório de software de distribuições linux, a instalação dele é bem simples. 
	
	VirtualBox \cite{virtualbox2015} é um virtualizador de código aberto do tipo 2 mantido pela Oracle \cite{oracle2015}. Este virtualizador pode ser instalado em distribuições Windows, Linux, Macintosh, Solaris e da suporte para instâncias de Windows (NT 4.0, 2000, XP, Server 2003, Vista, Windows 7, Windows 8), DOS/Windows 3.x, Linux (2.4, 2.6 e 3.x), Solaris e OpenSolaris, OS/2, e OpenBSD.
	
	\begin{table}[h]
		\centering
		\small
		\caption{Comparação entre virtualizadores analizados}
		\label{my-label}
		\resizebox{\columnwidth}{!}{
			\begin{tabular}{|l|l|l|c|c|}
				\hline
				& Empresa Responsável & Arquiteturas Suportadas     & \multicolumn{1}{l|}{Tipo de virtualização} & \multicolumn{1}{l|}{Tipo de Licensa} \\ \hline
				Xen & Citrix Systems      & x86, x86-64, IA 64, PowerPC & 1                                          & Código aberto                              \\ \hline
				KVM       & Red Hat             & x86, x86-64, IA 64, PowerPC & 1                                          & Código aberto                              \\ \hline
				ESXi      & VMware              & x86, x86-64                 & 1                                          & Gratuita/Comercial                         \\ \hline
				LXC      &  Canonical               & x86, x86-64, IA 64, PowerPC                & Contêiner                                          & Código aberto                         \\ \hline
				VirtualBox      &  Oracle               & x86, x86-64, IA 64                & 2                                          & Código aberto                         \\ \hline
			\end{tabular}
		}
	\end{table}
	
	Dentre os virtualizadores analizados, será utilizado neste trabalho o Xen devido a ser um virtualizador de código aberto e suportado por uma comunidade amplamente ativa. O fato do Xen ter seu código aberto, possibilita que toda uma comunidade interaja e possa contribuir com melhorias tanto na documentação quanto em correções de \textit{bugs} e evolução de suas funcionalidades.
	
	\section{Orquestração de ambientes de computação em nuvem} 
	As ferramentas de orquestração na nuvem servem para abstrair do administrador toda a parte de interação com os virtualizadores, serviços de armazenamento, dispositivos de redes e outros. Deste modo, permite-se que o administrador não precise de amplos conhecimentos nas tecnologias de virtualização, rede, armazenamento e outras utilizadas para se criar o ambiente de nuvem.
	
	Essas abstrações proporcionadas pelas ferramentas de orquestração tornam possível que o administrador da nuvem possa delimitar recursos físicos para cada usuário facilmente. Assim como também possibilita que usuários sem conhecimento nenhum de computação possam criar suas próprias máquinas virtuais.
	
	\subsection{Ferramentas de orquestração} 
	
	Seguindo a análise realizada no trabalho \cite{tccgabriel2015}, foram verificadas as seguintes ferramentas de orquestração para uso no decorrer deste trabalho.
	
	\begin{itemize}
		
		\item Apache CloudStack: o Apache CloudStack \cite{cloudstack2015} é uma ferramenta de orquestração de código aberto, suportada pela fundação Apache \cite{apache2015} e desenvolvida em java. O Apache CloudStack da suporte para virtualizadores como KVM, VM-ware , Xen e Hyper-V \cite{hyper-v2015}. Esta ferramenta da suporte aos sistemas de arquivos \textit{Internet Small Computer System Interface} (iSCSI) \abreviatura{iSCSI}{\textit{Internet Small Computer System Interface}} \cite{iscsi2015} e \textit{Network File System} (NFS) \abreviatura{NFS}{\textit{Network File System}} \cite{nfs2015};
		
		\item Eucalyptus: o Eucalyptus \cite{eucalyptus2015}, assim como o Apache CloudStack, é uma ferramenta de orquestração de ambientes de computação em nuvem. Suportada pela HP \cite{hp2015} e desenvolvida em java e C. O Eucalyptus, usa o Walrus como sistema de arquivo e tem suporte ao virtualizador KVM;  
		
		\item OpenStack: O OpenStack \cite{openstack2015}, da suporte aos mesmos virtualizadores que o Apache CloudStack, é uma ferramenta de código aberto desenvolvida em Python. Suporta os sistemas de arquivo Swift e Cinder.  
		
	\end{itemize}
	
	\begin{table}[h]
		\centering
		\caption{Comparação entre ferramentas de orquestração analisadas}
		\label{orchestration}
		\small
		\begin{tabular}{|l|c|l|l|}
			\hline
			& \multicolumn{1}{l|}{Linguagem Suportada} & Sistema de Arquivos & Tipo de Licensa \\ \hline
			CloudStack & Java                                     & iSCSI , NFS         & Código aberto   \\ \hline
			OpenStack  & Python                                   & Swift , Cinder      & Código aberto   \\ \hline
			Eucalyptus & Java , C                                 & Walrus              & Código fechado   \\ \hline
		\end{tabular}
	\end{table}
	
	
	
	Dentre essas ferramentas de orquestração em nuvem, foi optado o uso do Apache CloudStack devida a uma série de motivos, tais como:
	\begin{itemize}
		
		\item	Suportado por uma fundação e uma comunidade amplamente ativa;
		\item	Possui uma documentação detalhada;
		\item	É codificada em java que é uma linguagem de programação bem conhecida para futuras extensões;
		\item	Tem suporte para sistemas de arquivos conhecidos;
		\item	É uma ferramenta de código aberto, o que possibilita um melhor conhecimento da ferramenta e implantação de melhorias. 
		
	\end{itemize}
	
	
	\section{Monitoramento de ambientes de computação em nuvem} 
	
	Nesta seção serão abordadas as dificuldades relacionadas ao monitoramento na nuvem, sua importância, as características que o monitoramento deve possuir e algumas ferramentas que realizam monitoramento de ambientes de computação em nuvem. 
	
	%definicao de monitoramento%
	
	\subsection{Características de ferramentas de monitoramento para ambientes de computação em nuvem}
	
	Segundo \citeonline{aceto2012cloud} existem 11 características que uma ferramenta de monitoramento para ambientes de computação em nuvem deve possuir para ter um funcionamento correto e sem degradar os serviços fornecidos:
	\begin{enumerate}
		\item Escalabilidade: a ferramenta pode ser considerada escalável se ela consegue suportar uma larga quantidade de objetos a serem monitorados \cite{clayman2010monitoring}. Na nuvem, tal característica tem importância devido a grande gama de componentes que podem existir;
		\item Elasticidade: para uma ferramenta ser considerada elástica, ela deve conseguir suportar mudanças ocorridas no ambiente monitorado, tais como novos objetos para serem monitorados ou objetos deixando de ser monitorados \cite{clayman2010monitoring}. Isto é de fundamental importância para ambientes de nuvem, pois o ambiente vive em contínua mudança com a adição e remoção de recursos dinamicamente;
		\item {Adaptabilidade: uma ferramenta de monitoramento é adaptável, se ela consegue se ajustar a mudanças de cargas impostas ao ambiente sem que este seja penalizado e mantendo o seu serviço de monitoramento ativo e funcionando corretamente \cite{clayman2010monitoring}. Para realizar o monitoramento do ambiente, a ferramenta consome recursos de rede, armazenamento e processamento. A ferramenta deve se ajustar para consumir menos recursos em ocasiões que o ambiente se encontra sobrecarregado;}
		\item Pontualidade: a ferramenta pode ser considerada pontual, se ela é capaz de relatar eventos que acontecem no ambiente, como perda repentina de um recurso, ou sobrecarga de outro, em tempo hábil para estes serem tratados \cite{wang2011flexible};
		\item Autonomia: para a ferramenta ser considerada autônoma, ela deve ser capaz de se gerenciar, conseguindo responder a mudanças repentinas do ambiente sem a necessidade de uma outra entidade a supervisionando. Ao mesmo tempo em que torna a complexidade do seu funcionamento discreta para usuários e gerentes do ambiente;
		\item Abrangente: uma ferramenta de monitoramento é abrangente, se ela consegue monitorar diferentes tipos de recursos e capturar diferentes métricas destes recursos \cite{hasselmeyer2010towards}. Isto é importante, já que ambientes de nuvem costumam ser heterogêneos;
		\item Extensividade: a ferramenta pode ser considerada extensível, se ela suporta a adição de novas métricas para monitorar, sem a necessidade de modificações no código fonte da ferramenta.
		\item Não intrusiva: para a ferramenta não ser considerada intrusiva, ela deve poder ser implantada no ambiente sem precisar de modificações significativas neste \cite{katsaros2011building};
		\item Confiabilidade: uma ferramenta de monitoramento é dita confiável, se mesmo com falhas em diversos componentes, ela ainda continua fornecendo seu serviço normalmente com os componentes que ainda lhe restam \cite{laprie2008dependability};
		\item Disponibilidade: a ferramenta de monitoramento deve estar disponível sempre que os seus serviços forem solicitados. Isto é importante para ambientes da nuvem, pois estes estão em constante atividade \cite{shirey2007internet};
		\item Precisão: a ferramenta é considerada precisa se as informações disponibilizadas pela ferramenta contêm valores que expressem o mais aproximadamente possível o estado em que o objeto monitorado se encontra no momento que a medida foi realizada. 
		
	\end{enumerate}
	
	Além das características levantadas por \cite{aceto2012cloud}, também são descritas algumas dificuldades na área de monitoramento da nuvem.
	\begin{itemize}
		
		
		\item{Grande volume de informação:}
		a nuvem possui diversos usuários, assim como componentes e um grande tráfego de rede. Com isso, algumas horas de monitoramento contínuo, podem gerar Tera Bytes de informações para serem armazenadas; 
		
		\item{Mudança constante do ambiente:}
		devido a elasticidade de um ambiente de computação em nuvem, as métricas a serem monitoradas podem mudar a qualquer momento, pode haver a necessidade de monitorar um novo elemento que não estava previsto; 
		
		\item{Sensibilidade de ambientes carregados:}
		em ambientes de computação em nuvem muito carregados, a presença do monitoramento pode acarretar em sobrecarga de processamento, e acabar comprometendo o funcionamento de todo o ambiente;
		
		\item{Garantir autonomia da ferramenta:}
		esta demanda a possível exis-tência de um laço que irá receber informações do ambiente de tempos em tempos (a própria ferramenta que deve obter essas informações), processar essas informações e repassar as ações que cada nodo deve executar (no caso de uma ferramenta distribuída);
		
		\item{Heterogeneidade do ambiente:}
		 ambiente de computação em nuvem possui inúmeros dispositivos com diferentes arquiteturas e tecnologias. Deve-se conseguir prover suporte de monitoramento para cada um desses dispositivos e ainda manter um bom isolamento entre eles;
		
		\item{Rastreamento de elementos da nuvem:}
		o ambiente de nuvem permite que seus recursos sejam migrados de um dispositivo físico para outro. Deve-se garantir que a ferramenta consiga detectar a nova localização de um recurso migrado e continuar monitorando este recurso em sua nova localização, em vez de apenas acusar uma falta do recurso em um local e a detecção de um novo recurso em outro.
		
	\end{itemize}
	
	O monitoramento na nuvem é de grande importância tanto para os clientes quanto para os fornecedores de serviços de nuvem. O monitoramento é um meio para se garantir um melhor controle dos dispositivos de hardware e das aplicações que são executadas nos ambientes de nuvem \cite{aceto2012cloud}. 
	
	O constante monitoramento do ambiente, auxilia na garantia da qualidade do serviço prestado para os usuários do ambiente, como por exemplo: disponibilidade e tempo de resposta das aplicações hospedadas. Para os fornecedores de serviços, o monitoramento é um modo de mensurar os recursos utilizados pelo usuário e então poder ser cobrada uma taxa referente ao uso dos mesmos \cite{aceto2012cloud}. Para ambos os casos, o monitoramento auxilia na prevenção e até mesmo correção de desvios no termo de prestação de serviços acordado por usuário e provedor \cite{aceto2012cloud}.   
	
	
	\subsection{Ferramentas de monitoramento}
	
	Nesta seção serão descritas ferramentas de monitoramento de código aberto que são comumente usadas para monitorar ambientes de computação em nuvem.
	
	\begin{itemize}
		
		\item Nagios: o Nagios \cite{nagios2015} suporta o monitoramento de máquinas virtuais e serviços de armazenamento \cite{caron2012auto}. O Nagios é uma ferramenta de código aberto que possui inúmeras extensões. Existem extensões que possibilitam o Nagios monitorar sistemas como Eucalyptus, CloudStack\cite{CSnagios2015} e OpenStack \cite{OSnagios2015};
		
		\item Zenoss: O Zenoss \cite{zenoss2015} é uma ferramenta opensource escrita em Java com suporte a diversos virtualizadores, como por exemplo, KVM, XenServer e VMware. Usuários do CloudStack, tem a possibilidade de usar o Zenoss ao instalar a extensão \cite{CSzenPack2015}, usuários de OpenStack podem usar a extensão \cite{OSzenPack2015}.  Estas extensões ficam limitadas pelas funcionalidades disponibilizadas através das APIs das ferramentas de orquestração;
		
		\item Nimbus: a Nimbus \cite{nimbus2015} é uma ferramenta de criação e gerência de ambientes de computação em nuvem, Suporta virtualizadores como Xen ou KVM e da suporte para monitoramento do ambiente através do\textit{ Simple Network Management Protocol} (SNMP) \abreviatura{SNMP}{\textit{Simple Network Management Protocol}}\cite{snmp2015}. Esta ferramenta é voltada especialmente para projetos relacionados a comunidade científica. A Nimbus visa autonomia no monitoramento tanto de aplicações do ambiente quanto na infraestrutura como um todo, no caso, ela não suporta monitoramento de clusters, apesar de monitorar aplicações sendo executadas nas VMs. 
		
		\item Zabbix: o Zabbix \cite{zabbix2015} é uma ferramenta de monitoramento de infraestrutura e aplicações. Esta ferramenta da suporte para abordagens multi agente ou sem nenhum agente (centralizado). Esta ferramenta é compatível com vCenter \cite{vCenter2015} permitindo monitoramento destes ambientes. Além de ser compatível com o vCenter, o Zabbix permite o monitoramento de qualquer dispositivo de hardware que suporte \textit{Intelligent Platform Management Interface} (IPMI) \abreviatura{IPMI}{\textit{Intelligent Platform Management Interface}} \cite{IPMI2015} e dispositivos que suportem SNMP, conseguindo capturar as mesmas métricas suportadas por ambos os protocolos IPMI e SNMP. Usuários de CloudStack podem usar o Zabbix através da extensão \cite{zabbix-cloudstack2015} e usuários de OpenStack através da extensão \cite{zabbix-openstack2015} 
		
		\item Icinga: o Icinga \cite{icinga2015} é uma ferramenta que pode ser instalada em qualquer distribuição Linux. Nesta ferramenta, o usuário deve especificar o que deve ser monitorado antes de inicializar a ferramenta, ou seja, qualquer novo item a ser monitorado, irá requerer uma reinicialização da ferramenta. Assim como o Nagios, esta ferramenta promete uma fácil extensibilidade, possibilitando que os usuários criem plugins para expandir o funcionamento da ferramenta, além de suportar todos os plugins desenvolvidos para o Nagios. Esta ferramenta monitora serviços de rede e consumo de recursos de hardware, como CPU e memória. Ela possui uma extensão para usuário do OpenStack \cite{icingaOpenstack2015}, usuários de CloudStack não tem suporte ainda para uso do Icinga e acabam adotando o Nagios como substituto já que ambas as ferramentas são similares.
	\end{itemize}
	
	\begin{table}[h]
		\centering
		\caption{Características suportadas pelas ferramentas analisadas em \cite{aceto2013cloud}}
		\label{comparacaoFerramentas}
		\begin{tabular}{|l|c|c|c|c|c|}
			\hline
			& \multicolumn{1}{l|}{Nagios} & \multicolumn{1}{l|}{Zenoss} & \multicolumn{1}{l|}{Nimbus} & \multicolumn{1}{l|}{Zabbix} & \multicolumn{1}{l|}{Icinga} \\ \hline
			Escalabilidade  &                             &                             &                             &                             &                             \\ \hline
			Elasticidade    &                             &                             &                             &                             &                             \\ \hline
			Adaptabilidade  &                             &                             &                             &                             &                             \\ \hline
			Pontualidade    &                             & X                           &                             & X                           &                             \\ \hline
			Autonomia       &                             &                             & X                           &                             &                             \\ \hline
			Abrangencia     &                             &                             &                             &                             &                             \\ \hline
			Extensividade   & X                           &                             &                             & X                           & X                           \\ \hline
			Não intrusiva   &                             &                             &                             &                             &                             \\ \hline
			Confiabilidade  &                             &                             &                             & X                           &                             \\ \hline
			Disponibilidade &                             &                             &                             &                             &                             \\ \hline
			Precisão        &                             &                             &                             &                             &                             \\ \hline
		\end{tabular}
	\end{table}
	

	Dentre as ferramentas analisadas, todas suportam monitoramento de recursos de hardware usando protocolos padrões de monitoramento como SNMP e IPMI, além de usar estes protocolos, usam também APIs de ferramentas de orquestração. Uma característica em comum dessas ferramentas, é a abordagem de coletar os dados e armazená-los de modo histórico. Todas usam o mesmo conceito de ter uma entidade centralizada que de tempos em tempos, envia mensagens para os nodos que estão nos servidores físicos coletarem os dados e enviarem para o nó central. 
	
	Como apresentado na tabela \ref{comparacaoFerramentas}, as ferramentas analisadas não dão suporte a inúmeras das características abortadas em \cite{aceto2012cloud}, isso acontece porque as ferramentas em si não interagem diretamente com os Virtualizadores dos ambientes de computação em nuvem e sim com APIs das ferramentas de orquestração. Essas APIs muitas vezes são incompletas e inconsistentes, ou seja, não disponibilizam alguns tipos de métricas e alguns dados coletados não são condizentes com o real estado dos elementos monitorados. Outro ponto que as ferramentas adotam é a inserção de agentes dentro das máquinas virtuais para coletar os dados de cada máquina virtual e então juntar esses dados para obter as métricas de todo o ambiente, o que torna a ferramenta intrusiva.
	
	A proposta deste trabalho será de criar uma ferramenta que suporte as características apresentadas na Tabela 3 e seção 2.4.1. A ferramenta irá usar a API dos Virtualizadores para conseguir obter os dados dos ambientes em vez de usar APIs das ferramentas de orquestração. Outra abordagem diferente da ferramenta proposta neste trabalho, será uma inversão do paradigma adotado pelas ferramentas analisadas, que é o fato de um nodo central fazer requisições para os nodos folhas coletarem os dados e retornarem estes para o nodo central.
	
	 A proposta deste trabalho consiste em os nodos folhas enviarem periodicamente os dados coletados para o nodo central sem o nodo central precisar requisitar, isso gera um menor fluxo de rede e torna a ferramenta menos impactante para o ambiente. Outro diferencial da proposta deste trabalho será a autonomia da ferramenta. A ferramenta irá se ajustar continuamente ao ambiente de computação em nuvem que ela está monitorando, deixando de monitorar recursos removidos ou passando a monitorar novos recursos.
	 
	 A ferramenta de monitoramento proposta será uma extensão
	 para o Apache CloudStack. O Apache CloudStack conhece todo o ambiente onde ele foi instalado, possibilitando que suas extensões também conheçam o ambiente. Com estas informações a ferramenta poderá a detectar mudanças no ambiente de computação em nuvem e então se auto ajustar para realizar o monitoramento do mesmo.
	
	\chapter{Trabalhos relacionados}
	
	Este capitulo aborda sobre modelos de monitoramento de ambientes de computação em nuvem, pontos fortes e fracos de cada modelo, e por fim, uma comparação entre os modelos apresentados e o modelo proposto neste trabalho.
	
	Em \cite{katsaros2012self} é proposto um modelo para monitorar todas as camadas (aplicação, plataforma e infraestrutura) de um ambiente de computação em nuvem. O modelo consiste de 6 componentes constituindo a ferramenta de monitoramento como um todo, cada componente é descrito a seguir:
		\begin{itemize}
			\item Framework de serviço de monitoramento: é o principal componente, responsável por orquestrar os outros componentes e disponibilizar os resultados do monitoramento para o usuário;
			\item Repositório central: responsável por organizar e guardar todos os dados do monitoramento;
			\item Serviço de monitoramento de infraestrutura: responsável por obter dados do uso de recursos da infraestrutura;
			\item Serviço de monitoramento de instancia: responsável por obter dados do uso de recursos de cada VM de um servidor através do coletor de dados e guardar no repositório central;
			\item Repositório local: responsável por armazenar os dados de monitoramento de uma única VM;
			\item Coletor de dados: coleta os dados de uso de recursos de uma única VM e guarda no repositório local.
		\end{itemize}
	
	As principais características abordadas no modelo de \cite{katsaros2012self} é a elasticidade e acurácia, o modelo permite reconfigurar todas as métricas de monitoramento sem a necessidade de reiniciar o sistema ou proporcionar algum impacto de desempenho para o ambiente. O principal problema encontrado é que cada instancia de máquina virtual irá gerar uma instancia de coletor de dados e repositório local, o que gera um uso extra de memória; é uma solução invasiva, pois insere software dentro da VM do usuário.
	
	\citeonline{andreozzi2005gridice} propõem um modelo de monitoramento de serviços distribuídos. O modelo proposto é dividido em 5 módulos independentes para facilitar extensões e manutenção. É apresentado um módulo de coleta de dados que usa sensores (o tipo de sensor ou como são implementados não é especificado) para medir tráfego de rede, desempenho do serviço monitorado, disponibilidade do mesmo e uso de recursos físicos. O segundo módulo é o responsável por analisar quais dados são mais interessantes para cada tipo de serviço, para tal fim foi usado o Globus MDS \cite{globus2015} para fazer a análise dos dados capturados e classificá-los . O terceiro módulo armazena cada tipo de dados em uma base de dados relacional, no caso o postgreSQL \cite{postgre2015}. O quarto módulo serve para informar quando algum serviço está sobrecarregado/inacessível. E o ultimo módulo é responsável pela apresentação dos dados através de uma página web.
	
	Este modelo foi feito com a intenção de monitorar serviços web e informar aos usuários as condições de cada serviço. O banco de dados para persistência dos dados separa cada tipo de dado em tabelas diferentes para agilizar consultas. O diferencial deste modelo é o fato de conseguir peneirar os dados não relevantes para cada tipo de serviço e não armazenar tal dado, porem ele ainda continua monitorando tal tipo de dado.
	
	O modelo apresentado por \cite{andreozzi2005gridice} permite adições de novos módulos e métricas de monitoramento, sendo que novos módulos requerem a reinicialização do sistema e novas métricas não precisam de reinicialização. Usa banco de dados relacional para persistir os dados e persiste apenas dados considerados relevantes. A visualização dos dados pode ser feita usando um histórico de 1, 5 e 15 minutos, históricos superiores a esses intervalos não são descartados.
	
	\citeonline{shao2010runtime} propõem um modelo de monitoramento baseado em agentes que opera em todas as camadas de computação em nuvem e tem como principal característica balancear a capacidade de monitoramento da ferramenta com o aumento ou redução da carga dos servidores, de modo a ajustar a coleta de dados baseado na carga do ambiente. A ferramenta realiza isso medindo a carga do ambiente e ajustando a frequência de obtenção dos dados, com o ambiente com pouca carga a frequência de coleta de dados aumenta e vice-versa.
	
	Para realizar a coleta de dados de cada VM, são instanciados agentes (Aplicações Java), dentro de cada máquina virtual, ou seja, cada máquina virtual vai ter uma \textit{Java Virtual Machine} (JVM) \abreviatura{JVM}{\textit{Java Virtual Machine}} executando um agente para obter os dados da VM. Este agente por sua vez, utiliza uma biblioteca nativa escrita em C \cite{sigar2015}.
	
	O balanceamento da carga do ambiente com a coleta de dados da ferramenta ocorre de modo manual, usando uma ferramenta do Java 6 \textit{hotswap} que permite trocar uma classe java por uma outra versão dessa mesma classe em tempo de execução, assim se torna possível alterar os agentes em tempo de execução de forma a possibilitar um melhor controle de consumo de recursos pela ferramenta. A persistência dos dados ocorre num banco de dados relacional onde não são separados tipos de dados como no trabalho anterior. 
	
	\begin{table}[]
		\centering
		\caption{Comparação dos Trabalhos relacionados}
		\label{compTrabRela}
		\begin{tabular}{|L{2cm}|L{2cm}|L{2cm}|L{2cm}|}
			\hline
			& \cite{katsaros2012self} & \cite{andreozzi2005gridice} & \cite{shao2010runtime}        \\ \hline
			Modo de guardar dados                           & Banco relacional          & Banco relacional              & Banco relacional                \\ \hline
			Mantém histórico de dados                       & Sim                       & Por no máximo 15 min          & Sim                             \\ \hline
			Filtro de métricas                              & Não                       & Sim                           & Não                             \\ \hline
			Área de atuação                                 & IaaS, PaaS e SaaS         & Serviços distribuidos         & IaaS, PaaS e SaaS               \\ \hline
			Modo de obtenção dos dados                      & Script injetado nas VMs   & Sensores                      & Aplicação Java injetada nas VMs \\ \hline
			Permite ajustar intervalo de exibição dos dados & Não                       & Sim                           & Não                             \\ \hline
		\end{tabular}
	\end{table}
	
	Como mostrado na Tabela 4 dentre os trabalhos analisados, todos optam por uma abordagem de banco de dados relacional para a persistência dos dados coletados, talvez uma abordagem não relacional seja mais adequada para esse tipo de problema pois bancos não relacionais tendem a se tornar mais rápidos que relacionais quando o volume de dados se torna grande \cite{li2013performance}. Uma diferenca desses trabalhos em relação as ferramentas mostradas, é o fato que eles propõem um modelo em que os dados coletados por cada nodo são enviados para um repositório periodicamente em vez de uma entidade central solicitar que tais nodos enviem os dados, como é feito nas ferramentas analisadas. Além disso, um problema encontrado nos modelos propostos é o fato de como eles obtém os dados das máquinas virtuais. Usando métodos invasivos de inserção de scripts ou aplicações dentro das máquinas virtuais dos usuários, além desses métodos serem invasivos, eles são pouco práticos, pois acabam ficando presos ao sistema operacional que o usuário escolher, um script para obter dados num Unix por exemplo, vai ser diferente do script de um Windows.
	
	Além disso, como mostrado na Tabela 4 todas as propostas tendem a manter um histórico dos dados armazenados, porém não disponibilizam um meio de configurar por quanto tempo o usuário gostaria que os dados ficassem armazenados. Outra coisa apontada na Tabela 4 é o uso de um filtro de métricas pela proposta de \cite{andreozzi2005gridice} que permite otimizar a coleta de dados do ambiente sem deixar de capturar a essência do comportamento do mesmo. 
	
	\chapter{Proposta}
	
	Conforme apresentado por Aceto et al. em \cite{aceto2012cloud},
	o cenário de ferramentas de monitoramento para ambientes de computação em nuvem não atende as necessidades de gerência, seja por falta de precisão nos resultados do monitoramento, falta de extensibilidade da aplicação ou o fato de injetarem código nas máquinas virtuais dos usuários.
	
	A proposta deste trabalho consiste na criação de uma plataforma de monitoramento de ambientes de computação em nuvem que possa atender às características de monitoramento elencadas em \cite{aceto2013cloud} de modo autônomo e sem prejudicar o ambiente de computação em nuvem e seus usuários. Deste	modo, será utilizada uma arquitetura orientada a serviços, onde cada	serviço é responsável por garantir uma funcionalidade da ferramenta, sendo possível a adição de novos serviços em tempo de execução para complementar a plataforma de monitoramento de ambientes de computação em nuvem em nível de IaaS. Além disso, o uso de agentes para realizar a configuração autônoma do componente de monitoramento, permite que a plataforma se ajuste autonomamente ao comportamento do ambiente, possibilitando um melhor uso de recursos.

\section{ARQUITETURA DA PLATAFORMA DE MONITORAMENTO}
	
	As ferramentas de orquestração de ambientes de computação em
	nuvem possuem 5 elementos básicos como descrito em \cite{tccgabriel2015}
	
	\begin{itemize}
		\item Gerente de identidades - é responsável por definir quais privilégios sobre cada recurso do ambiente cada usuário possui;
		\item Gerente de alocação - trata da alocação de máquinas virtuais para os usuários assim que estas são solicitadas;	
		\item Componente virtualizador - intermedeia a comunicação entre diferentes tipos de virtualizadores e a ferramenta de orquestração;
		\item Componente de armazenamento - efetua o gerenciamento e compartilhamento de imagens das máquinas virtuais entre servidores
		do ambiente;
		\item Componente de rede - responsável por toda a configuração de rede do ambiente.
	\end{itemize}
	
	A plataforma proposta neste trabalho pode ser vista como um sexto elemento da ferramenta de orquestração que será a responsável por gerenciar o monitoramento das máquinas virtuais e servidores do ambiente de nuvem. Ao fim da implantação da plataforma de monitoramento, a distribuição dos elementos que compõe a ferramenta de orquestração ficará como ilustrado na Figura 1.
	
	\begin{figure}[h]
		
		
		\centering
		\includegraphics[scale=1]{figuras/ferramentaOrquestracao.png} % leia abaixo
		\label{figura:ferramentaOrquestracao}
		\caption{Ferramenta de orquestração estendida com a plataforma
			autônoma de monitoramento}
	\end{figure}
	
	\section{COMPONENTES DA PLATAFORMA DE MONITORAMENTO}
	
	Nesta sessão sã descritos os elementos existentes na plataforma
	de monitoramento, como eles são constituídos e qual papel de cada um.
	Ilustrada na Figura 2, a plataforma de monitoramento é composta de
	3 componentes: o componente de monitoramento, de configuração e de
	armazenamento.
	
	\subsection{Componente de Monitoramento}
	
	Este componente é responsável por coletar os dados referentes ao
	consumo de recursos de cada máquina virtual e servidores do ambiente
	em que ele foi designado para atuar. Este componente é constituído de
	um ou mais serviços de captura de dados que podem monitorar as mesmas ou diferentes métricas como ilustrado na Figura 3 Cada serviço de
	captura poderá a coletar uma ou mais variáveis do ambiente, poderão haver múltiplas instâncias do mesmo serviço no ambiente, monitorando
	o mesmo conjunto de métricas de servidores e máquinas virtuais diferentes, assim como também poderão haver diferentes serviços que	monitoram conjuntos de métricas distintos.
	
		\begin{figure}[H]
			
			
			\centering
			\includegraphics[scale=1]{figuras/ambienteComPlataforma} % leia abaixo
			\label{figura:ambienteComFerramenta}
			\caption{Ambiente de computação em nuvem com a plataforma de monitoramento}
		\end{figure}
		
		\begin{figure}[H]
			
			
			\centering
			\includegraphics[scale=1]{figuras/componenteMonitoramento} % leia abaixo
			\label{figura:componenteMonitoramento}
			\caption{Componente de monitoramento}
		\end{figure}
		
		Após ter obtido os dados, os serviços do componente de monitoramento realizam o envio dos mesmos para um repositório de armazenamento através do componente de armazenamento. Os dados obtidos
		serão organizados no formato \textit{JavaScript Object Notation} (JSON) \abreviatura{JSON}{\textit{JavaScript Object Notation}}, um exemplo dos dados coletados pode ser encontrado nas Figuras 4 e 5. Como ilustrado nas Figuras 4 e 5, cada JSON contem 6 propriedades:
		
		\begin{enumerate}
			\item \textit{resourceType} - o tipo de recurso coletado;
			\item \textit{resourceUsage} - o quanto deste tipo de recurso a máquina virtual está usando no momento da coleta;
			\item \textit{virtualMachineName} - o identificador da máquina virtual monitorada;
			\item \textit{timestamp} - a data em que ocorreu a coleta;
			\item \textit{host} - o servidor cuja máquina virtual está sendo executada;
			\item \textit{cluster} - o cluster onde o servidor da máquina virtual se encontra.
		\end{enumerate}
		
		\begin{figure}[H]
			
			
			\centering
			\includegraphics[scale=0.8]{figuras/json1} % leia abaixo
			\label{figura:json1}
			\caption{Exemplo de JSON gerado através de dados coletados relativos ao uso de cpu.}
		\end{figure}
		
		\begin{figure}[H]
			
			
			\centering
			\includegraphics[scale=0.8]{figuras/json2} % leia abaixo
			\label{figura:json2}
			\caption{Exemplo de JSON gerado através de dados coletados relativos ao uso de memória.}
		\end{figure}
		
		\subsubsection{Serviço de captura de dados}
		
		O serviço de captura de dados irá conter uma aplicação que através da API do virtualizador obtém as métricas de consumo ou alocação de recursos para as máquinas virtuais e desempenho dos servidores físicos como ilustrado na Figura 6. Deste modo, o serviço de captura de dados garante que não seja necessário a injeção de qualquer tipo de código nas máquinas virtuais dos usuários ao mesmo tempo em que caso algum novo dispositivo de hardware seja inserido no servidor, este possa ser monitorado por algum serviço de monitoramento existente no ambiente, pois esse dispositivo só poderá ser usado após ser reconhecido pelo virtualizador, que por sua vez irá disponibilizar o acesso aos recursos do dispositivo através da sua API. 
		
		O serviço de captura de dados deverá se cadastrar na plataforma de monitoramento	disponibilizando as métricas que este suporta. O serviço de captura de dados também deverá verificar se o servidor que foi designado para ser	monitorado está ativo (isto deverá ser feito toda vez que o serviço for	coletar as métricas do servidor); se o servidor não estiver disponível, o serviço deverá remover esse servidor da sua lista de servidores para monitorar. Além do cadastro, o serviço de captura de dados deverá disponibilizar os seguintes endpoints que irão dar forma a seguinte \textit{Uniform Resource Locator} (URL) \abreviatura{URL}{\textit{Uniform Resource Locator}} \textit{''http://ip-serviço:8080/$<$endpoint$>$''}:
		
		\begin{itemize}
			\item \textit{timeSpent} - retorna o tempo médio que o serviço leva para coletar os dados de cada servidor que ele é responsável;
			\item \textit{hosts} - retorna todos os servidores monitorados pelo serviço;
			\item \textit{addHost/host} - adiciona um servidor para ser monitorado pelo serviço;
			\item \textit{removeHost} - remove um servidor qualquer da lista de servidores monitorados pelo serviço;
			\item \textit{setDataRetrieveInterval/value} - altera o valor do intervalo entre coletas de dados;
			\item \textit{getDataRetrieveInterval} - retorna o valor do intervalo entre coletas de dados.
		\end{itemize}
		
		\begin{figure}[H]
			
			
			\centering
			\includegraphics[scale=1]{figuras/servicoCaptura} % leia abaixo
			\label{figura:servicoCaptura}
			\caption{Exemplo de um serviço de captura de dados}
		\end{figure}
		
		\subsection{Componente de armazenamento Ocomponente}
		
		Ocomponente de armazenamento será constituído de uma aplicação e uma base de dados como como ilustrado na Figura 7. Este componente realiza o armazenamento e gerência dos dados oriundos do monitoramento através de uma aplicação que recebe requisições \textit{Hypertext Transfer Protocol} (HTTP) \abreviatura{HTTP}{\textit{Hypertext Transfer Protocol}} contendo um JSON com as informações sobre uma máquina virtual ou servidor para persistir no banco de dados. Além disso, a aplicação disponibiliza métodos para consultar informações sobre o ambiente monitorado, como: recursos utilizados por máquinas virtuais, recursos alocados e utilizados dos servidores físicos, percentual de recursos ociosos em um cluster e outros. 
		
		Ambientes de computação em nuvem possuem milhares de máquinas virtuais, servidores e outros componentes como dispositivos de rede e armazenamento. Deste modo, como modelo de banco de dados será utilizado uma base de dados não relacional orientada a documentos, visto que esses tipos de banco de dados possuem um desempenho melhor em leitura e escrita num grandes volumes de dados como apresentado em \cite{li2013performance}. Para a modelagem do banco de dados não relacional foi criado um modelo \textit{Enhanced Entity-Relantionship} 
		(EER)\abreviatura{EER}{\textit{Enhanced Entity-Relantionship}} ilustrado na Figura 8. O modelo definem 7 entidades:
		
		\begin{enumerate}
			\item \textit{Host} - entidade que irá conter informações relativas a um servidor;
			\item \textit{VM} - entidade que irá armazenar informações de máquinas virtuais;
			\item \textit{HostResource} - esta entidade armazena dados relativos ao monitoramento de servidores;
			\item \textit{VMResource} - esta entidade irá armazenar os dados obtidos ao monitorar máquinas virtuais;
			\item \textit{ServiceRegistry} - entidade responsável por armazenar o registro de cada tipo de serviço de captura de dados da plataforma;
			\item \textit{HostActivity} - entidade que irá armazenar um histórico de atividades dos servidores, se foram ligados ou desligados e quando isto ocorreu;
			\item \textit{ServiceSupport} - esta entidade armazena as características dos	serviços, os virtualizadores e métricas que eles suportam.
		\end{enumerate}
		
		\begin{figure}[h]
			
			
			\centering
			\includegraphics[scale=1]{figuras/armazenamento} % leia abaixo
			\label{figura:armazenamento}
			\caption{Componente de armazenamento de dados}
		\end{figure}
		
		\begin{figure}[h]
			
			
			\includegraphics[scale=0.9]{figuras/modeloRelacional} % leia abaixo
			\label{figura:modeloRelacional}
			\caption{Modelo do banco de dados}
		\end{figure}
	
	\subsection{Componente de Configuração}
	
	O componente de configuração é composto por dois agentes apresentados na Figura 9. O agente de configuração determina a frequência de coleta de dados dos serviços de captura. Ele contém uma lista com	todos os serviços disponíveis no ambiente e fará requisições periódicas para o serviço de armazenamento a fim de obter métricas do ambiente para poder definir melhores configurações de intervalo de monitoramento para cada serviço de captura de dados. O procedimento que o agente irá a usar para a melhoria da configuração dos serviços é descrito no Algoritmo 1.
	
	\begin{figure}[h]
		
		
		\includegraphics[scale=1]{figuras/componenteConfiguracao} % leia abaixo
		\label{figura:componenteConfiguracao}
		\caption{Componente de configuração dos serviços de monitoramento}
	\end{figure}
	
	O Algoritmo 1 tem como objetivo melhorar o intervalo de funcionamento de cada serviço de coleta de dados, fazendo uso da variação dos dados coletados por esses serviços. Esta variação consiste na relação	entre os valores das métricas obtidos em diferentes períodos, se esta variação for grande, significa que as máquinas virtuais dos servidores monitorados por esse serviço estão sofrendo mais variações, deste modo seria mais interessante que o serviço passe a coletar os dados	destas máquinas virtuais mais frequentemente para conseguir obter dados mais condizentes com seu estado. Do mesmo modo, se a variação for pequena, significa que as máquinas virtuais monitoradas por esse serviço estão com um comportamento estável. Assim, o serviço de captura pode levar mais tempo para realizar a coleta dos dados dessas máquinas virtuais, reduzindo os custos com processamento, coleta e armazenamento de dados.
	
	Descrição de cada variável e função presentes no Algoritmo 1:
	
	\begin{itemize}
		\item \textit{servicoArmazenamento}[Linha: 1] - uma referência para o serviço responsável por realizar a persistência e consulta de dados no repositório da plataforma de monitoramento;
		\item \textit{servicosConhecidos}[Linhas: 1 e 4] - uma lista contendo todas as instâncias dos serviços de captura de dados existentes na plataforma de monitoramento;
		\item \textit{servico}[Linhas: 4,5,6,11,12 e 13] - uma instância de um serviço	de captura de dados qualquer;
		\item \textit{listaJson1 e listaJson2} [Linhas: 5,6,7 e 8] - listas de JSONs que armazenam todos os JSONs referentes as máquinas virtuais monitoradas num determinado período;
		\item \textit{servidores}[Linhas: 5 e 6] - variável contendo os servidores em que o serviço atua;
		\item \textbf{dataAtual}()[Linhas: 2 e 3] - função que irá retornar o momento	corrente;
		\item \textit{período}[Linhas: 2 e 3] - variável que irá conter um tempo que será subtraído da data atual para gerar uma data no passado. O
		período pode ser configurado pelo administrador do sistema;
		\item \textbf{consultar}()[Linhas: 5 e 6] - método que irá retornar uma lista de JSON contendo todos os dados do banco de dados cujo atributo servidor esteja contido na lista de servidores e que as datas estejam dentro do intervalo de dados calculado com o uso do parâmetro período;
		\item \textbf{separarPorMetrica}()[Linhas: 7 e 8] - método que irá retornar uma lista de lista de JSON onde cada elemento é uma sublista
		da lista de JSONs passada por parâmetro para o método, os elementos dessa sublista terão todos a mesma métrica e não poderão haver sublistas distintas contendo a mesma métrica;
		\item \textbf{obterMedias}()[Linhas: 9 e 10] - método que retorna um conjunto onde cada elemento é a média aritmética de todos as valores
		de uma métrica contida na lista de valores de métricas passada
		por parâmetro;
		\item \textit{mediasDeMetricas1}[Linhas: 9 e 12] - array que contem a média dos valores de cada tipo de métrica coletada num passado próximo;
		\item \textit{mediasDeMetricas2}[Linhas: 10 e 12] - array que contem a média dos valores de cada tipo de métrica coletadas num momento presente;
		\item \textbf{obterFrequencia}()[Linha: 11] - método que retorna a frequência com que um serviço de captura de dados está coletando os dados;
		\item \textbf{coefFreq}[Linhas: 12 e 13] - valor ao qual será multiplicada a frequência de coleta de um serviço de captura de dados para tornar o serviço mais eficiente;
		\item \textbf{coeficienteDeFrequencia}()[Linha: 12] - método que calcula o coeficiente de frequência utilizando como base a Função 4.1;
		\item \textbf{frequênciaInicial}()[Linha: 13] - método que retorna a frequência inicialmente definida no serviço de captura de dados;
		\item \textbf{nMetricas}()[Linha: 12] - método que retorna o número de métricas capturadas por um serviço de captura de dados;
		\item \textbf{definirFrequenciaDeCapturaDeDados}()[Linha: 13] - altera o valor da frequência de captura de dados do serviço de captura de dados usando a Fórmula 4.3 com os parâmetros passados.
	\end{itemize}
	
	\begin{center}
		\hspace*{-1cm}
		\includegraphics[scale=.6]{figuras/algoritmo1}  % leia abaixo
		\label{alg:algorithm1}
	\end{center}
	
	Para realizar o ajuste da frequência foram definidas três Fórmulas
	4.1, 4.2 e 4.3. 
	
	A Fórmula 4.1 receberá três valores, sendo eles:
	
	\begin{itemize}
		\item \textit{A e B} - vetores de médias de métricas obtidas em diferentes
		períodos;
		\item \textit{h} - número de métricas monitoradas pelo serviço;
		\item \textit{i} - índice de iterações, valor que inicia em um (1) e sofrerá acréscimo de uma (1) unidade a cada iteração do produtório,
		podendo atingir um valor máximo de \textit{h}.
	\end{itemize}
	
	A Fórmula 4.1 é constituída de um produtório sobre a Fórmula
	4.2, passando o valor do i-ésimo elemento dos vetores \textit{A} e \textit{B} para a Fórmula 4.2 em cada iteração, ao final, teremos um valor \textit{y} onde $0 \leq
	y \leq 2$. A escolhe deste limite 2 foi tomada para evitar que o período
	entre uma coleta e outra aumente rapidamente, possibilitando assim que várias avaliações do ambiente sejam feitas antes de chegar em longos períodos entre cada coleta de dados, uma forma de evitar configurações	radicais.
	
	\begin{center}
		\hspace*{0cm}
		\includegraphics[scale=0.6]{figuras/formula1}  % leia abaixo
		\label{alg:formula1}
	\end{center}
	
	A Fórmula 4.2 receberá 3 valores, sendo eles:
	
	\begin{itemize}
		\item \textit{a} e \textit{b} - médias de uma métrica obtidas em diferentes períodos;
		\item \textit{h} - número de métricas monitoradas pelo serviço.
	\end{itemize}
	
	\begin{center}
		\hspace*{1.2cm}
		\includegraphics[scale=0.6]{figuras/formula3}  % leia abaixo
		\label{alg:formula3}
	\end{center}
	
	A Fórmula 4.3 receberá 2 valores, sendo eles:
	
	\begin{itemize}
		\item \textit{x} - coeficiente de frequência de captura de dados derivado com a Fórmula 4.1;
		\item \textit{y} - intervalo de captura de dados inicialmente definida.
	\end{itemize}
	
	A Fórmula 4.3 calcula de fato a frequência de captura de dados do serviço usando a variável \textit{x}, que é obtido na Fórmula 4.1, e a variável
	\textit{y} que é configurada pelo administrador da plataforma. Esta fórmula resulta num valor que pode ser até cem vezes maior ou até duas vezes
	menor que o valor de \textit{y}, ou seja, com essa fórmula, o intervalo $\delta$ entre cada captura de dados de um serviço pode variar de $y/2 \leq \delta \leq 100 ? y$. Vale lembrar que esta fórmula usa como valor de entrada o coeficiente calculado na Fórmula 4.1, que como mencionado, pode
	escalar em no máximo duas vezes e com um mínimo não definido. Com isso, esta fórmula tende a ter um comportamento onde o limite inferior não varia tanto do valor inicial porém pode ser rapidamente alcançado, enquanto o limite superior pode chegar a valores cem vezes maiores que o valor inicial porém numa velocidade menor.
	
	\begin{center}
		\hspace*{-0.3cm}
		\includegraphics[scale=0.6]{figuras/formula2}  % leia abaixo
		\label{alg:formula2}
	\end{center}
	
	Além do agente de configuração da frequência de coleta de dados
	dos serviços de captura, o componente de configuração possui também um agente de distribuição de servidores para serviços de captura de dados. Este agente é responsável por verificar a carga de cada serviço	e com base nessa carga, decidir quais servidores serão monitorados por	cada serviço. Esta carga será uma relação entre o tempo que o servição leva para obter as métricas de um servidor e suas máquinas virtuais e o intervalo de tempo em que este serviço deve disponibilizar as métricas obtidas. O procedimento que o agente de distribuição de servidores para serviços de captura de dados irá usar está descrito no Algoritmo 2.
	
	O Algoritmo 2 tem como objetivo distribuir melhor as cargas do monitoramento dos servidores entre os serviços de captura de dados disponíveis e, quando for necessário este agente irá instanciar mais
	serviços de captura de dados. Para realizar tal procedimento o Algoritmo 2 tem como entrada uma lista com os serviços de captura de dados disponíveis no ambiente e outra lista com os servidores sem monitoramento [Linha: 1], esta lista de servidores sem monitoramento irá inicializar vazia e será preenchida a medida que os servidores são removidos da lista de servidor a ser monitorado dos serviços de captura de dados. Exceto na inicialização da plataforma, neste momento todos os servidores estarão sem monitoramento, logo esta lista estará cheia e o tempo de captura dos serviços serão todos 0, a lista de serviços conhecidos será preenchida no momento que os serviços de captura realizam seu cadastro na plataforma. As métricas que deverão ser monitoradas	de cada servidor na inicialização do sistema, serão configuradas pelo administrador na base de dados da aplicação. Portando o administrador deverá ter ciência das métricas suportadas pelos serviços de captura de dado disponíveis para evitar que servidores não sejam monitorados.
		
	O algoritmo percorre cada serviço de captura de dados recolhendo informações sobre o tempo médio que o serviço está levando	para realizar a captura de suas métricas e a frequência de captura configurada no mesmo, com esses 2 valores, o algoritmo pode identificar serviços sobrecarregados ou com pouca carga [Linhas 3 a 17]; no caso	de pouca carga, será adicionado um novo servidor sem monitoramento (caso exista) para o serviço de captura de dados passar a monitorar	[Linhas 9 a 16].
	
	Caso o serviço de captura de dados esteja sobrecarregado, será então removido 1 servidor de sua lista de servidores a serem monitorados [Linhas 6 a 8]. Um serviço é definido como sobrecarregado quando o tempo médio para realizar a captura das métricas é superior a frequência com que o serviço deve capturar os dados, o serviço é definido com pouca carga caso este tempo médio de captura seja inferior a metade da frequência com que o serviço irá capturar os dados.
	
	Definidos os serviços de captura de dados disponíveis, o próximo passo do algoritmo será a migrar os servidores de serviços disponíveis menos saturados para serviços disponíveis equivalentes mais saturados	[Linhas 19 a 27]. Esta ação irá a permitir esvaziar alguns serviços e aproveitar ao máximo a capacidade de processamento de outros serviços, podendo assim remover os serviços vazios da plataforma como é feito adiante.
	
	Após realizar o balanceamento dos serviços de monitoramento, se ainda existirem servidores não monitorados e não existirem serviços de captura vagos, será então instanciado um novo serviço de captura de	dados para suprir os servidores sem monitoramento. O procedimento acaba quando não existirem servidores sem monitoramento, monitorar um servidor inclui monitorar todas as máquinas virtuais existentes	naquele servidor [Linhas 28 a 34].	
	
	Quando não existirem mais servidores sem monitoramento, será verificado se existe algum serviço de captura de dados sem monitorar nenhum servidor, caso exista, este será removido da plataforma [Linhas 35 a 40].
		
	Descrição de cada variável e métodos presentes no Algoritmo 2:
	
	\begin{itemize}
		\item \textit{servicosConhecidos}[Linha: 1] - lista com todos os serviços de captura de dados existentes no ambiente;
		\item \textit{servidoresNaoMonitorados}[Linha: 1] - lista onde cada elemento é o identificador de um servidor e as métricas desse servidor que	devem ser monitoradas;
		\item \textit{servicosDisponiveis}[Linha: 2] - serviços que podem ser designados para monitorar algum servidor caso sejam compatíveis;
		\item \textit{servico} - um serviço de captura de dados qualquer;
		\item \textbf{obterTiposMetricasMonitoradas}()[Linha: 4] - método que
		retorna uma lista com todas as métricas que o serviço de captura de dados monitora;
		\item \textit{tempoGasto}[Linha: 5] - tempo em que um serviço de captura
		de dados leva para obter o valor das métricas de todos os seus servidores e máquinas virtuais;
		\item \textit{frequencia}[Linha: 6] - a frequência com que o serviço de captura
		de dados realiza a coleta dos dados dos servidores e máquinas virtuais pelos quais ele é responsável;
		\item \textbf{adicionar}()[Linha: 7] - função que adiciona um servidor e as métricas que devem ser monitoradas na lista de servidores não monitorados;
		\item \textbf{removeServidor}()[Linha: 7] - método que remove e retorna um servidor da lista de servidores a monitorar de um serviço de captura de dados;
		\item \textbf{procurarServidor}()[Linha: 10] - procura por um servidor na lista de servidores não monitorados que possa ser monitorado	pelo serviço passado por parâmetro, se encontrado, o servidor será removido da lista e retornado, senão será retornando vazio. Um servidor pode ser monitorado por um serviço se este serviço suporta algumas das métricas do antigo serviço que monitorava o servidor;
		\item \textbf{adicionarServidor}()[Linha: 14] - adiciona um servidor passado por parâmetro na lista de servidores que serão monitorados pelo serviço de captura de dados;
		\item \textbf{obterServicoEquivalente}()[Linha: 21] - método que retorna
		um serviço que monitore métricas equivalentes a do serviço passado por parâmetro e que esteja dentro da lista de serviços também passada por parâmetro;
		\item \textbf{transfereServidor}()[Linha: 23] - método que irá remover um servidor a ser monitorado do serviço menos carregado (com menor diferença entre o período em que os dados devem ser obtidos e o
		tempo levado para obter os dados) e adicionar no mais carregado;
		\item \textit{alterados}[Linha: 24]- lista contendo serviços disponíveis que já sofreram alterações na sua lista de servidores;
		\item \textbf{obterServidorEmetricas}()[Linha: 29] - método que retorna um objeto servidor qualquer e as métricas que devem ser monitoradas
		desse servidor;
		\item \textbf{procurarServicos}()[Linha: 32] - função que irá procurar um conjunto de serviços cuja união das métricas monitoradas por esses serviços seja igual às métricas passadas por parâmetro. Se não existirem serviços suficientes para suprirem todas as métricas, novos serviços serão instanciados, isto garante que todas as métricas serão monitoradas. Os serviços retornados serão removidos da lista de serviços disponíveis mesmo que estes possam suportar mais um servidor para monitorar (o algoritmo considera que o serviço disponível tem capacidade para apenas mais um servidor), se por ventura o serviço de captura ainda tiver capacidade para monitorar mais um servidor, este pode ser designado para monitorar mais um servidor na próxima vez que o algoritmo for executado;
		\item \textbf{adicionarTodos}()[Linha: 33] - método que adiciona um servidor na lista de servidores a monitorar de um conjunto de serviços
		de captura de dados, além de remover estes serviços da lista de
		serviços disponíveis e o servidor da lista de servidores sem monitoramento;
		\item \textbf{obterServidores}()[Linha: 36] - método que retorna uma lista com todos os servidores que um serviço de captura de dados monitora;
		\item \textbf{destruir}() [Linha: 38]- método que destrói a instância de um serviço de captura de dados (este método é chamado quando o serviço não possui nenhum servidor para monitorar).
	\end{itemize}
	
	\begin{center}
		\hspace*{-1cm}
		\includegraphics[scale=1]{figuras/algoritmo2}  % leia abaixo
		\label{alg:algorithm2}
	\end{center}
	
	O Algoritmo 2 não realiza um balanceamento em cada serviço analisando quantos servidores podem ser adicionados ou removidos, busca-se apenas a adição ou remoção de um servidor em cada serviço e conforme sucessivas execuções do algoritmo, os serviços tenderão a ficar distribuídos.
	
	\section{Fluxos de execução}
	
	A plataforma é constituída de 3 principais fluxos de interação
	entre os seus componentes. (I) O fluxo de captura de dados que além
	de obter os dados de cada máquina virtual, persiste os mesmos num repositório de dados; (II) fluxo de configuração de frequência de captura dos dados que irá melhorando a frequência com que cada serviço
	do componente de monitoramento obtém os valores das métricas dos
	servidores e suas máquinas virtuais; (III) o fluxo de distribuição de
	servidores para serviços de captura de dados que irá decidir quais servidores serão monitorados por cada instância dos serviços de captura.
	
	No fluxo de captura de dados ilustrado na Figura 10, cada servi¸
    ço do componente de monitoramento irá percorrer a sua lista de servidores e para cada servidor, irá capturar o uso de recursos de cada máquina virtual através da API do virtualizador ao mesmo tempo em que será mensurado o tempo utilizado para realizar tal coleta. Após realizar e temporizar as coletas, o componente de monitoramento então irá persistir as informações obtidas no componente de armazenamento.
	Cada serviço do componente de monitoramento irá atuar em uma fatia
	de tempo diferente, pois cada um possui sua própria frequência de
	obtenção de dados.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{figuras/fluxoCaptura}  % leia abaixo
		\label{fig:fluxoCaptura}
		\caption{Fluxo de captura dos dados}
	\end{figure}
	
	No fluxo de configura¸ao da frequência de captura dos dados	ilustrado na Figura 11, o componente de configura¸ao irá coletar os dados do ambiente relativos a 2 períodos diferentes, e com esses dados ele irá  redefinir a frequência com que cada serviço do componente de monitoramento deve coletar os dados dos servidores e máquinas virtuais, aumentando ou diminuindo a frequência de coleta dependendo da variação dos dados obtidos pelo serviço nesses 2 períodos distintos, conforme apresentado no Algoritmo 1.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{figuras/fluxoConf}  % leia abaixo
		\label{fig:fluxoConf}
		\caption{Fluxo de configuração da frequência de captura dos serviços do componente de monitoramento}
	\end{figure}
	
	No fluxo de distribuição de servidores para serviços de captura	de dados apresentado na Figura 12, o componente de configuração irá percorrer todos os serviços do componente de monitoramento e irá consultar o tempo que o serviço leva para concluir sua tarefa de monitoramento e a frequência que a mesma deve ser realizada. Com essas
	duas métricas, o componente de configuração define se este serviço está sobrecarregado, normal ou pouco carregado. Se o serviço estiver pouco carregado, o componente de configuração irá tentar alocar mais um servidor para o serviço monitorar. Se o serviço estiver sobrecarregado, o componente de configuração irá tentar migrar um servidor deste serviço para outro que realize o mesmo trabalho, caso não seja possível, o componente de configuração irá instanciar um novo serviço para realizar o	monitoramento deste servidor a ser migrado. Esse procedimento completo e em detalhes é descrito no Algoritmo 2.
	
	A proposta apresentada utiliza de uma arquitetura modularizada que permite que as funcionalidades da plataforma sejam totalmente independentes, tornando-a extensível e menos suscetível a falhas. A escolha deste tipo de arquitetura também permite a adição de novas funcionalidades para a plataforma de monitoramento em tempo de execução.
	
	Além disso, o uso de agentes para tratar das configurações da plataforma permite maior independência em relação a necessidade de intervenções de administradores para a gerência do sistema. Com isso
	a responsabilidade de gerenciar e configurar a plataforma fica a cargo dos agentes e não de administradores humanos, possibilitando com que
	o sistema se adapte ao ambiente em que ele se encontra.
	
	Outro ponto interessante é o fato da plataforma usar o protocolo
	HTTP e a representação de objeto JSON para troca de mensagens, o que permite que a implementação dos serviços seja independente de linguagem de programação, ou seja, pode-se ter serviços em diferentes
	linguagens de programação, como Java, C, Perl e outras. Isto torna
	a plataforma receptível para qualquer tipo de extensão em qualquer
	linguagem e \textit{hardware}.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=1]{figuras/fluxoPersist}  % leia abaixo
		\label{fig:fluxoPersist}
		\caption{Fluxo de distribuição de servidores para serviços de captura de dados}
	\end{figure}
	
	\chapter{Implementação}
	
	Este capítulo trata da implementação da plataforma de monitoramento na plataforma de orquestração Apache CloudStack desde as tecnologias usadas até o desenvolvimento da plataforma autônoma de	monitoramento e a integração com o orquestrador. Parte do que será descrito neste capítulo já existia de outros trabalhos e foi reaproveitado para integração com o Apache CloudStack.
	
	Como linguagem de programação foi utilizada o Java \cite{java2015} por ser a mesma linguagem utilizada pelo Apache CloudStack, além de ser bem dominada pelo autor desta proposta, o que poupa	tempo com aprendizado de novas linguagens de programação. Para fazer tanto a gerência das instâncias dos novos objetos criados pela plataforma de monitoramento, e a utilização de instâncias de objetos criados pelo Apache CloudStack, foi utilizado o Spring Framework \cite{spring2015}.
	
	Para realizar a coleta de informações dos servidores e de suas máquinas virtuais, foi utilizada a API do virtualizador Xen \cite{xenProject2015}. Após a coleta das informações, foi utilizado o MongoDB \cite{mongo2015} para realizar a persistência dos dados capturados por ser uma base de dados não relacional bem conhecida e de fácil usabilidade. Por fim, para realizar a criação de \textit{webservices} por onde seria possível fazer o	acesso às aplicações, foi utilizado o Spring Boot \cite{boot2015} pelo fato de ser uma tecnologia de rápido aprendizado e de desenvolvimento ágil.
	
	A Figura 13 ilustra a hierarquia de projetos que foram usados/criados para a realização deste trabalho. Como podemos ver, não existem setas ligando o Java e o Spring, pois ambas as tecnologias estão presentes em todos os projetos, logo não há a necessidade de uma ligação em cada projeto com estas tecnologias. Na Figura 13, as setas em vermelho representam relações de dependência de compilação entre projetos, ou seja, o projeto filho herda do projeto pai, somente parâmetros de configuração de compilação e não classes.
	
	As setas pretas por sua vez, indicam dependências de classes ou de funcionalidades, ou seja, o projeto filho depende de uma ou mais classes do projeto pai ou de um ou mais serviços do projeto pai. Serviços neste caso são requisições HTTP que uma aplicação de um projeto faz para outra aplicação de outro projeto.
	
	Outra observação sobre a Figura 13 é a existência do MySQL \cite{mysql2015}, mesmo ele não tendo sido citado como uma tecnologia utilizada na plataforma, isto ocorre pelo fato que ele é utilizado por um projeto que não foi criado juntamente com a plataforma de monitoramento, assim não se teve nenhuma iteração com a tecnologia MySQL. Porém a figura contêm ela apenas para evidenciar sua existência no projeto como um todo.
	
	\begin{figure}[H]
		\hspace*{-1cm}
		\includegraphics[scale=0.85]{figuras/hierarquia}  % leia abaixo
		\label{fig:hierarquia}
		\caption{Hierarquia de projetos da plataforma autônoma de monitoramento}
	\end{figure}
	
	Dentre os projetos já existentes e utilizados temos:
	
	\begin{itemize}
		\item Autonomic platform, Autonomic algorithms commons e Autonomic administration algorithms - estes projetos foram meramente utilizados apenas para realizar a compilação da plataforma;
		
		\item Autonomic plugin common - foi utilizado deste projeto, instâncias
		das classes \textit{HostService} - responsável por disponibilizar uma lista
		com todos os servidores ativos do ambiente; \textit{HttpUtils} - que realiza requisições HTTP POST e GET; \textit{SshUtils} - que realiza comandos em \textit{secure shell} num servidor ou máquina virtual qualquer; \textit{AutonomiccsSystemVmDeploymentService} - essa classe é responsável por realizar a procura de um servidor no ambiente para fazer a hospedagem de uma máquina virtual de sistema e instanciar uma máquina virtual de sistema num servidor escolhido para hospedar os serviços de monitoramento e agentes de configuração.
		
	\end{itemize}
	
	\section{PROJETOS CRIADOS PARA A IMPLEMENTAÇÃO DA PLATAFORMA DE MONITORAMENTO}
	
	Esta seção descreve cada projeto que compõem a plataforma autônoma de monitoramento.
	
	\subsection{Autonomic monitoring pojo common}
	
	Este projeto serve para padronizar as estruturas dos \textit{Plain Old Java Objects} (POJO) \abreviatura{POJO}{\textit{Plain Old Java Objects}}, que são objetos javas simples, sem lógica, com apenas métodos \textit{get} e \textit{set} e o construtor padrão do Java, sua única função é de armazenar e transportar variáveis. Estas estruturas são descritas no modelo entidade relacional apresentado na Figura 8.

	\subsection{Autonomic monitoring storage system manager}
	
	Este projeto tem como objetivo criar uma máquina virtual no	ambiente, instalar o MongoDB e a aplicação de armazenamento nesta	máquina virtual, além de verificar periodicamente se a máquina virtual e a aplicação estão funcionando normalmente.
	
	Para hospedar a máquina virtual criada, primeiramente será preciso de um servidor com capacidade suficiente para suportar a máquina virtual. Deste modo é utilizado o método \textit{searchForRandomHostInCloudToDeployAutonomiccsSystemVm} da \textit{classeAutonomiccsSystemVmDeploymentService}, que irá	a procurar por um servidor qualquer no ambiente que suporte uma máquina virtual de sistema como ilustrado na Figura 14 número 1. Tendo o servidor para hospedar a máquina virtual, o próximo passo é subir a máquina virtual no servidor usando o método \textit{deploySystemVmWithJava} também da classe \textit{AutonomiccsSystemVmDeploymentService}, que	irá alocar e iniciar a máquina virtual no servidor informado por parâmetro e instalar o Java nesta máquina virtual, depois disso irá retornar a instância que representa a máquina virtual recentemente criada como ilustrado na Figura 14 número 2.
	
	Com a máquina virtual executando no servidor, é instalada a	aplicação de armazenamento. Esta instalação ocorre através de comandos \textit{secure shell} usando a classe \textit{SshUtils}, o endereço de IP\abreviatura{IP}{\textit{Internet Protocol}} da máquina virtual de sistema e uma chave de criptografia que foi configurada no \textit{template} da máquina virtual de sistema. Após ter instalado a aplicação de armazenamento na máquina virtual e ter configurado ela como serviço no sistema operacional da VM, esta então é reiniciada. Esta VM jamais poderá ser destruída, pois isso acarretaria na	perda de todo o histórico de monitoramento do ambiente.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=1]{figuras/criacaoSystemVMs}  % leia abaixo
		\label{fig:criacaoSystemVMs}
		\caption{Fluxo de criação de \textit{System VMs}}
	\end{figure}
	
	Para verificar se a máquina virtual e a aplicação ainda estão em
	operação como mostrado na Figura 15 número 1, é analisado o estado da máquina virtual no Apache CloudStack, se o estado estiver como Running, então são enviados pings para as portas 8080(aplicação), 27017(MongoDB) e 22 (ssh), se algum desses pings não retornar, então será feita a reinicialização da máquina	virtual como ilustrado na Figura 15 número 2. Se o estado estiver diferente de Running, então será a feita a tentativa de inicialização da máquina virtual. Em caso de nenhuma das tentativas funcionarem, então será destruída a máquina virtual e instanciada uma nova (Figura 15, número 3). Para evitar transtornos de perda de dados, deverá ser criada uma rotina de backup da base de dados e outra rotina de restauração na nova máquina virtual criada.
	
	\begin{figure}[h]
		\centering
		\includegraphics[scale=0.85]{figuras/verificacaoVMArmazenamento}  % leia abaixo
		\label{fig:verificacaoVMArmazenamento}
		\caption{Fluxo de verificação da VM de armazenamento}
	\end{figure}
	
	\subsection{Autonomic monitoring data collector system manager}
	
	Este projeto é similar ao anterior, o que difere são as aplicações que serão instaladas na máquina virtual de sistema, em vez de instalar a aplicação de armazenamento, será instalada a aplicação de coleta de dados, além disto, este projeto irá permitir que existam mais de uma máquina virtual de coleta de dados no ambiente como ilustrado na Figura 16. Para realizar o monitoramento do funcionamento das máquinas virtuais, será feito um processo similar ao do projeto anterior, diferindo que nestas VMs, a porta 27017 não será monitorada, e caso a máquina virtual não responda ou não possa ser reinicializada, a mesma poderá ser então destruída e dar espaço para uma outra máquina virtual.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.9]{figuras/verificacaoVMcoleta}  % leia abaixo
		\label{fig:verificacaoVMcoleta}
		\caption{Fluxo de verificação das VMs de coleta de dados}
	\end{figure}
	
	\subsection{Autonomic monitoring agent data collector configuration}
	
	Este projeto é o responsável por realizar as ações do agente de configuração especificado no capítulo de proposta na seção 4.2.3, além de ser onde é implementado o Algoritmo 1. Este projeto contem duas classes principais \textit{DataCollectorConfigurationAgent} e \textit{DataCollectorConfigurationAgentService}
	
	Na classe DataCollectorConfigurationAgentService é onde foram implementados todos os métodos usados pelo agente que foram especificados no capítulo de proposta seção 4.2.3. Para popular sua lista de serviços de captura de dados esta classe irá fazer requisições \textit{HTTP GET} periódicas para a aplicação de armazenamento da plataforma como ilustrado na Figura 17 número 2.
	
	A classe \textit{DataCollectorConfigurationAgent} irá a usar os métodos implementados pela classe \textit{DataCollectorConfigurationAgentService} para criar um método que implemente o Algoritmo 1. Esta classe que fará o papel do agente de configuração de serviços de coleta de dados proposto. É usado o \textit{Spring Schedule} para fazer a execução periódica do método implementado por esta classe, assim emulando o ciclo de vida de um agente que atua constantemente no ambiente.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.9]{figuras/ajustarFrequenciaCaptura}  % leia abaixo
		\label{fig:ajustarFrequenciaCaptura}
		\caption{Fluxo de ajuste da frequência de captura}
	\end{figure}
	
	\subsection{Autonomic monitoring agent host distribution}
	
	Este projeto trata da implementação do agente de distribuição de servidores para serviços de captura de dados proposto. Assim como no projeto anterior, foram criadas duas classes para a implementação	deste agente, a classe \textit{HostDistributionAgent} e a classe \textit{HostDistributionAgentService}.
	
	O \textit{HostDistributionAgentService} trata de implementar todos os
	métodos especificados no Algoritmo 2. Para fazer a detecção de novos servidores adicionados no ambiente de computação em nuvem, esta classe
	usa uma instância da classe \textit{HostService} do projeto \textit{Autonomic plugin common} que provê um serviço de obtenção de uma lista com todos os servidores ativos existentes no ambiente de computação em nuvem (Figura 18, número 1).
	
	A classe \textit{HostDistributionAgent} usa uma instância da classe \textit{HostDistributionAgentService} para realizar a implementação do Algoritmo	2, além de usar o \textit{Spring Schedule} para fazer a execução periódica do Algoritmo 2, e assim emular o ciclo de vida de um agente.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.9]{figuras/ajustarServidores}  % leia abaixo
		\label{fig:ajustarServidores}
		\caption{Fluxo de ajuste da alocação de servidores para serviços de captura}
	\end{figure}
	
	\subsection{Autonomic monitoring data collector application}
	
	Este projeto é responsável pela coleta dos dados do ambiente, para isso ele irá usar a XAPI do Xen, esta API permite a coleta de inúmeros dados das máquinas virtuais e do servidor como mostrado na Figura 19 número 1. Para ter acesso à API, é preciso fornecer um usuário com permissão de administrador e sua senha no servidor. A API retorna um documento XML como resposta às requisições.
	
	Neste projeto existe a classe \textit{DataCollectorEndPoints} que é responsável por tratar os \textit{EndPoints} do servidor \textit{REST} do serviço de captura de dados para o agente de configuração poder requisitar e atualizar	as variáveis deste serviço. Este projeto também possui a classe \textit{CaptureService} que irá fazer uso da API do Xen para consultar os dados de cada servidor e máquina virtual pelo qual este serviço é responsável.
	
	A classe \textit{CaptureService} também implementa a interface do Spring \textit{InitializingBean}, esta interface provê o método afterPropertiesSet, este
	método é executado logo após a criação do objeto que é gerenciado pelo \textit{Spring}. É neste método que o serviço irá se cadastrar na base de dados da plataforma e poderá então ser configurado corretamente pelos agentes da plataforma.
	
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.9]{figuras/capturaDados}  % leia abaixo
		\label{fig:capturaDados}
		\caption{Fluxo de coleta de dados}
	\end{figure}
	
	\subsection{Autonomic monitoring storage application}
	
	Este projeto é responsável pela criação do serviço de armazenamento da plataforma, assim como por instalar corretamente o MongoDB na VM onde a aplicação for instalada.
	
	Este projeto possui a classe \textit{StorageApplicationEndPoint} que irá tratar as requisições HTTP GET e POST feitas para esta aplicação. A classe \textit{StorageService} trata da realização de consultas e persistências	na base de dados através da classe \textit{StorageDao}. Além disso, esta classe	implementa o \textit{InitializingBean} e realiza a instalação do MongoDB no método \textit{afterPropertiesSet}, caso necessário.
	
	Para realizar a instala¸ao do MongoDB é usada uma instância da classe \textit{ShellCommandUtils} para a execução de um \textit{ShellScript} que	foi inserido na máquina virtual na hora da instalação da aplicação na mesma pelo \textit{Autonomic monitoring storage system manager}.
	
	A classe \textit{StorageDAO} é quem irá fazer a comunicação direta com a base de dados usando para isso a API Java do MongoDB.
	
	\chapter{CONCLUSÃO}
	
	Este trabalho de conclusão de curso resultou na criação de um modelo de plataforma de monitoramento de ambientes de computação em nuvem autônoma que pode ser implementada em qualquer ferramenta de orquestração. Contudo, como validação foi criado um plugin, que implementa a proposta e a introduz na ferramenta de orquestração Apache CloudStack.
	
	Foi desenvolvido um plugin para o Apache CloudStack que permite o monitoramento autônomo e criação de um histórico de métricas relativo a alocação e uso de recursos em ambientes orquestrados pelo Apache CloudStack. Para isto foi incluído no fluxo de inicialização do	Apache CloudStack, funções que irão criar e instanciar os serviços e agentes necessários para o funcionamento da plataforma de monitoramento autônoma. A integração da plataforma de monitoramento com o Apache CloudStack se deu através do uso de projetos já existentes que continham inúmeras abstrações para uso de funções do Apache CloudStack. Outro ponto sobre a implementação foi o uso da API do	Xen para a coleta dos dados das máquinas virtuais e servidores.
	
	O uso de agentes para a configuração autônoma do ambiente resulta num melhor uso dos recursos computacionais para realizar o monitoramento do ambiente sem prejuízos na acurácia dos resultados. Entretanto, devido ao prazo para conclusão do presente trabalho, não foi possível realizar experimentos e mensurar a eficiência, acurácia e outros aspectos da ferramenta proposta.
	
	Este trabalho possui as seguintes contribuições:
	\begin{itemize}
		
		\item Criação de um modelo para uma plataforma de monitoramento	que pode ser replicado em outras ferramentas de orquestração;
		
		\item Extensão de uma ferramenta de código livre para aplicação e experimentação da proposta;
		
		\item Criação de base de código que pode ser usado para futuras pesquisas na área de monitoramento de ambientes de computação em nuvem.
		
	\end{itemize}		
	
	Em uma breve comparação deste trabalho com outras ferramentas de monitoramento de ambientes de computação em nuvem, tem-se como principal ponto a autonomia da ferramenta desta proposta em relação a das demais soluções existentes. Enquanto as soluções atuais necessitam que os administradores do ambiente realizem ajustes em seus parâmetros para melhor adequar a ferramenta ao ambiente, esta proposta independe de administradores para alcançar tal façanha, atribuindo esta responsabilidade aos agentes modelados.
	
	Como trabalho futuros têm-se as seguintes atividades:
	
	\begin{itemize}
		\item Melhorar o código fonte desenvolvido com documentação e test cases;
		
		\item Disponibilizar a implementação da plataforma a comunidade;
		
		\item Realizar testes comparando esta solução com as já existentes;
		
		\item Criar um artigo científico com a proposta desta plataforma.
	\end{itemize}
	
	
	\bibliographystyle{ufscThesis/ufsc-alf}
	\bibliography{bibliografia}
	
	%--------------------------------------------------------
	% Elementos pós-textuais
	
\end{document}