Get best of the week

Avaliação integrada de métricas de carga do servidor

Trabalhando em um dos maiores bancos do país, tive que lidar com a tarefa de avaliar a eficiência do uso de recursos de aproximadamente 16 mil servidores. A tarefa foi formulada com muita simplicidade - era necessário desenvolver uma metodologia para avaliar as métricas de carga do servidor por um período. Idealmente, a carga do servidor por período deve ser estimada usando um ou vários (não mais que 8) números.

Algumas palavras sobre os recursos do uso de servidores virtuais


Grandes organizações (especialmente bancos) têm um zoológico heterogêneo de aplicativos herdados implantados em diferentes servidores, usando uma variedade de tecnologias de virtualização. Uma nuvem privada é uma tecnologia promissora, mas, na realidade, grandes organizações usarão por muito tempo várias plataformas de virtualização para implantar uma variedade de aplicativos.

À medida que as plataformas de virtualização evoluem, chega um momento em que ninguém na empresa consegue entender com que eficiência os recursos são usados. Mesmo as ferramentas de monitoramento mais avançadas não fornecem uma resposta para essa pergunta devido a vários cenários de uso do servidor. Por exemplo, um departamento pode ter um servidor de relatório que será totalmente carregado por apenas um período limitado. Diga 3-4 horas no final do mês. Em cenários da vida real, ninguém aloca recursos dinamicamente para esses servidores - isso é difícil técnica e organizacionalmente. Os recursos são alocados especificamente para a carga máxima periódica do servidor, embora isso ocorra com pouca frequência.

Como resumo, em grandes organizações, os recursos do farm virtual são gastos de maneira extremamente ineficiente.

A seguir, proponho uma metodologia com a qual você pode facilmente justificar o aumento e a diminuição de recursos alocados ao servidor virtual, independentemente do cenário.

Metodologia


Para avaliar a carga de recursos, é necessário coletar estatísticas de vários contadores; para avaliar a carga de recursos, várias métricas serão usadas. Convencionalmente, os contadores podem ser divididos em 2 tipos (de acordo com a taxa de variação): "rápido" e "lento". Um bom exemplo de contador "rápido" é o contador de carga do processador (% de CPU). Um exemplo de contador lento é a porcentagem de espaço livre no disco rígido (% FreeSpace).
A avaliação de contadores lentos consiste em calcular o valor extremo (mínimo ou máximo) da métrica para o período. Essa abordagem permite (por exemplo, ao avaliar o espaço livre em disco) estimar o recurso livre e, se necessário, alocar volumes adicionais ou reduzir os atuais.

Para contadores rápidos, uma abordagem diferente é usada. As desvantagens do uso de métricas integrais simples (média, máxima, mínima e mediana) para avaliar a dinâmica de tais contadores estão bem descritas aqui . As desvantagens comuns incluem a falta de informações sobre o aumento de cargas (médio e pico). Se considerarmos o valor máximo do período como uma métrica integral, a presença de outliers (por exemplo, carregamento instantâneo da CPU de até 100% quando o programa for iniciado) não fornecerá informações objetivas.

No artigoPropõe-se usar o quantil 0,9 para estimar a métrica rápida (este é um valor que indica o nível abaixo do qual o valor observado em 90% das amostras se encontra). Com uma carga uniforme do servidor de acordo com essa métrica, podemos estimar adequadamente a carga média do processador. Mas essa abordagem tem as mesmas desvantagens - a falta de informações sobre o aumento de cargas (médio e pico).

Abaixo, como ilustração, o gráfico semanal e diário do contador de% de CPU. O valor máximo do contador nos gráficos foi de 100%.





O gráfico mostra que, durante o período indicado, há uma explosão de carga, que dura cerca de 3 horas. Para esse contador, várias métricas foram calculadas para a semana. A Figura 2 mostra que a mediana (linha verde, valor de 5%), a média (amarelo, valor de 12%) e o quantil 0,9 (vermelho, valor de 27%) filtram a alteração da carga e as informações sobre ela são perdidas.

Como um desenvolvimento da idéia de quantis, eu gostaria de propor a idéia de um quantil deslizante. Este é um análogo da média móvel.mas o quantil 0,9 é usado como uma função de janela. Além disso, usaremos 2 quantis deslizantes para estimar o nível do contador - rápido em um curto período (1 hora) e lento em um longo período (24 horas). Um quantil rápido filtrará as emissões instantâneas e fornecerá informações de pico de carga. Um quantil lento permitirá estimar a carga média.

Como você pode ver nos gráficos, quantis móveis de 0,9 são características dinâmicas (marrom - rápido, roxo - lento). Para simplificar, avaliando o status do contador como métricas, propõe-se usar:

  • o valor máximo do quantil com um período de 1 hora, que mostra a carga máxima contínua do servidor para o período,
  • o valor médio do quantil com um período de 24 horas, que mostra a carga média do servidor para o período.

No gráfico, o valor máximo do quantil rápido é a linha preta em 85%, o valor médio do quantil lento é a linha rosa em 30%.

Assim, ao analisar a carga de recursos do servidor (de acordo com o contador de% de CPU), se considerarmos a média do mês (12%) como uma métrica, podemos tomar uma decisão errônea de reduzir os recursos alocados. A métrica dupla de quantil de movimentação rápida / lenta (85 e 30%) mostra que há recursos alocados suficientes, mas não há superávits.

Decisão


A implementação da avaliação da eficiência do uso de recursos foi decomposta em três tarefas:

  1. coleção de dados
  2. desenvolvimento de metodologia de avaliação
  3. implementação de metodologia na arquitetura atual

Acima, examinei a tarefa 2 desta implementação; abaixo, falaremos um pouco sobre a terceira tarefa.

Os dados foram coletados no banco de dados ClickHouse. Esta coluna DBMS é ideal para armazenar dados de séries temporais. Isso foi discutido em detalhes no ClickHouse Meetup em 5 de setembro de 2019. Uma comparação do ClickHouse com outros DBMS de séries temporais pode ser encontrada aqui .
Como resultado da coleta de dados, formamos várias tabelas nas quais os dados foram organizados linha por linha (os valores de cada contador foram gravados em uma linha separada). E, claro, houve problemas com dados brutos.

O primeiro problema é a irregularidade dos intervalos entre as entradas do contador. Por exemplo, se o período de gravação do contador padrão fosse de 5 minutos, às vezes havia lacunas e o próximo registro ficava a mais de 5 minutos (até 20 minutos) do registro anterior.

O segundo problema é que, algumas vezes, os dados do contador vieram 2 ou mais vezes (com valores diferentes) com o mesmo registro de data e hora.

E o terceiro problema - o ClickHouse não possui funções de janela.

Para resolver o primeiro problema, você pode usar ASOF JOIN. A idéia é bastante simples - para cada contador de cada servidor criar uma tabela uniformemente com intervalos de tempo igualmente preenchidos. O uso do ASOF JOIN permite o preenchimento dos valores da nova tabela com os valores mais próximos da tabela de dados brutos (as opções de preenchimento semelhantes ao preenchimento e preenchimento podem ser configuradas).

A solução para o segundo problema é a agregação com a escolha do valor máximo em um determinado momento.

Para resolver o terceiro problema, várias soluções foram consideradas. Primeiro, o script Python foi rejeitado devido ao desempenho insuficiente. A segunda solução - copiar dados brutos para um banco de dados MSSQL, calcular métricas e copiar de volta - parecia muito complicada de implementar. O MSSQL também possui funções de janela, mas não é necessária nenhuma função agregada. Pode-se ficar confuso e escrever sua própria função SQL CLR. Mas essa opção foi rejeitada devido à complexidade excessiva.

Uma solução funcional pode ser um script SQL para ClickHouse. Um exemplo deste script é dado abaixo. Para simplificar, considerei calcular apenas o quantil rápido de um único contador para vários servidores. A solução não parece muito simples e nem muito conveniente, mas funciona.

Como resultado, um relatório de teste foi criado no PowerBI para demonstrar a metodologia.





Conclusão


Concluindo, gostaria de especular sobre o desenvolvimento da solução. Se você observar a solução do ponto de vista dos data warehouses, poderá ver que dessa maneira a tarefa de criar um data warehouse (Data Warehouse) a partir de uma camada de dados brutos (Staging Area) é resolvida. Você pode discutir a arquitetura, mas para o ClickHouse como banco de dados de colunas, a normalização não é crítica (ou talvez até prejudicial).

Desenvolvimento adicional do repositório é visto na criação de tabelas agregadas (dia \ semana \ mês) com diferentes vidas úteis (TTL). Isso evitará o inchaço excessivo do armazenamento.
A próxima etapa pode ser usar dados para análises preditivas.

PS

O código e os dados para teste estão publicados aqui .

More articles:


All Articles