OpenStack: monitoramento e bilhetagem na prática
Em um ambiente OpenStack, cada recurso consumido, como CPU, memória ou rede, gera dados que o sistema coleta, organiza e utiliza no processo de cobrança. É exatamente isso que o monitoramento e bilhetagem no OpenStack permitem: acompanhar o uso da infraestrutura e preparar essas informações para uso no processo de cobrança. Mais do que visualizar métricas, esse processo mostra como diferentes componentes trabalham juntos para registrar e organizar o consumo de recursos dentro da nuvem.
Esse processo não acontece de forma isolada. No OpenStack, diferentes serviços estruturam esse processo e atuam em sequência, cada um com uma função bem definida dentro do fluxo de monitoramento e bilhetagem no OpenStack. Desde a coleta dos dados até a preparação dessas informações para uso no processo de cobrança, Ceilometer, Gnocchi e CloudKitty se conectam para dar suporte a esse funcionamento.
Ao longo deste conteúdo, você vai entender como esse fluxo acontece na prática.
Ceilometer: onde o monitoramento começa no OpenStack
O Ceilometer é o serviço de telemetria do OpenStack responsável pela coleta de estatísticas de diferentes componentes da nuvem. Os processos de monitoramento e bilhetagem no OpenStack utilizam os dados obtidos para auditoria, análise e planejamento da capacidade da infraestrutura. Entretanto, o serviço não realiza diretamente a cobrança dos recursos consumidos. Na prática, o Ceilometer executa a medição e o pré-processamento das métricas, enquanto outros componentes da plataforma utilizam essas informações posteriormente. Além disso, a arquitetura do Ceilometer prioriza escalabilidade horizontal, permitindo adicionar workers e nós conforme a necessidade do ambiente.
Arquitetura do Ceilometer
O Ceilometer divide sua arquitetura em três componentes principais: ceilometer compute, ceilometer central e ceilometer notification. O ceilometer compute executa nos nós computacionais e realiza a coleta de estatísticas diretamente no virtualizador. Já o ceilometer central executa no control plane e realiza consultas em APIs do OpenStack e serviços de terceiros. Por fim, o ceilometer notification consome dados da fila de mensageria, realiza o pré-processamento dos dados e os publica em um sistema de armazenamento externo ao Ceilometer.
De forma geral, a coleta de dados acontece periodicamente. Enquanto os agentes do ceilometer compute e ceilometer central obtêm os dados brutos do virtualizador, APIs do OpenStack e serviços de terceiros, o ceilometer notification consome as mensagens da fila, normaliza e transforma essas informações antes de publicá-las em um sistema de armazenamento externo ao Ceilometer.
Pollsters dinâmicos no Ceilometer
Uma das funcionalidades do Ceilometer é permitir a configuração dinâmica da coleta de métricas utilizando arquivos YAML. Assim, esses arquivos definem quais APIs o Ceilometer consulta para obter os dados, além das informações que o serviço processa durante a coleta. Além disso, esse modelo permite coletar métricas tanto de serviços do OpenStack quanto de serviços externos à plataforma.
Gnocchi: onde o OpenStack armazena as métricas
O Gnocchi é um banco de dados desenvolvido para armazenar e indexar métricas e recursos em larga escala dentro de ambientes OpenStack. O serviço lida com grandes quantidades de dados armazenados, mantendo desempenho, escalabilidade e tolerância a falhas. Diferente de outros bancos de dados de séries temporais, o Gnocchi realiza agregações durante a ingestão dos dados, permitindo uma recuperação extremamente rápida por meio de resultados pré-computados. Inicialmente utilizado como backend do Ceilometer, o Gnocchi se tornou a API padrão para armazenamento dos dados de telemetria no OpenStack.
Arquitetura do Gnocchi
A arquitetura do Gnocchi é dividida em dois componentes principais: gnocchi-api e gnocchi-metricd. O gnocchi-api é responsável por receber, salvar e atualizar dados coletados por serviços como o Ceilometer, além de disponibilizar dados agregados. Já o gnocchi-metricd atua como um daemon responsável por processar dados recebidos recentemente e armazená-los em soluções definidas pelo usuário, como Ceph, Redis, OpenStack Swift ou sistemas de arquivos locais.
O Gnocchi suporta diferentes tipos de armazenamento para incoming storage e persistent storage, incluindo Ceph, Redis, OpenStack Swift, Amazon S3 e Local folder (file). A SC Clouds recomenda utilizar Redis para incoming storage e Ceph para armazenamento permanente, devido à escalabilidade e confiabilidade dessas soluções. Além disso, o componente Index é responsável por armazenar índices de recursos, métricas e políticas de arquivo, utilizando bancos relacionais como PostgreSQL e MySQL.
Archive policies no Gnocchi
O Gnocchi não armazena permanentemente os dados brutos recebidos. Para reduzir o volume de informações, o serviço trabalha com intervalos de tempo definidos por granularidade e métodos de agregação, formando o que é chamado de archive policy. Nesse processo, o Gnocchi armazena os dados utilizando agregações como média, mínimo, máximo, somatório, contagem e desvio padrão. De forma resumida, sempre que o Ceilometer envia samples ao Gnocchi, o serviço processa essas informações, associa os dados a uma metric e aplica as regras definidas na archive policy antes do armazenamento permanente.
CloudKitty: onde a bilhetagem acontece no OpenStack
O CloudKitty é o serviço de rating do OpenStack, desenvolvido para atribuir valores monetários ao consumo de recursos da nuvem com base em regras de precificação. Para isso, o serviço consulta métricas e metadados por meio de endpoints específicos e aplica regras de bilhetagem customizáveis sobre os dados coletados. Além disso, o CloudKitty permite definir valores para recursos consumidos e gerar relatórios. Entretanto, processos como emissão de boletos, notas fiscais e integração com gateways de pagamento ficam fora do domínio do OpenStack.
Arquitetura do CloudKitty
A arquitetura do CloudKitty é dividida em dois componentes principais: cloudkitty-api e cloudkitty-processor. O cloudkitty-api é responsável por criar e ler as regras de bilhetagem, além de disponibilizar os dados já processados. Já o cloudkitty-processor obtém os dados brutos, processa essas informações de acordo com as regras de bilhetagem e salva os dados em um armazenamento configurado.
Contudo, dentro do cloudkitty-processor, o fluxo é dividido em módulos como orchestrator, fetcher, collector e rating modules. O fetcher obtém os escopos que serão processados, o collector realiza a coleta das métricas e os rating modules aplicam as regras de bilhetagem sobre os dados coletados, utilizando módulos como Hashmap e pyscripts. Após o processamento, os dados ficam disponíveis para consulta através do cloudkitty-api.
Conclusão
Por fim, o monitoramento e bilhetagem no OpenStack dependem da integração entre diferentes serviços para coletar, processar, armazenar e precificar os dados gerados pela infraestrutura. Nesse fluxo, o Ceilometer realiza a coleta e o pré-processamento das métricas, o Gnocchi organiza e armazena essas informações, enquanto o CloudKitty aplica as regras de bilhetagem sobre os recursos consumidos.
Na prática, essa integração permite maior controle operacional da nuvem, além de oferecer uma estrutura mais eficiente para auditoria, acompanhamento de consumo e criação de modelos de cobrança personalizados dentro de ambientes OpenStack.
Logo, se a sua empresa busca mais controle, escalabilidade e suporte especializado em ambientes OpenStack, fale com a equipe da SC Clouds e conheça as soluções desenvolvidas para provedores e infraestruturas cloud.
