Como identificar discrepantes nos dados de desempenho do tempo de atividade do servidor?


8

Eu tenho um script python que cria uma lista de listas de tempo de atividade do servidor e dados de desempenho, onde cada sub-lista (ou 'linha') contém estatísticas de um cluster específico. Por exemplo, bem formatado, é algo como isto:

-------  -------------  ------------  ----------  -------------------
Cluster  %Availability  Requests/Sec  Errors/Sec  %Memory_Utilization
-------  -------------  ------------  ----------  -------------------
ams-a    98.099          1012         678          91
bos-a    98.099          1111         12           91
bos-b    55.123          1513         576          22
lax-a    99.110          988          10           89
pdx-a    98.123          1121         11           90
ord-b    75.005          1301         123          100
sjc-a    99.020          1000         10           88
...(so on)...

Portanto, em forma de lista, pode parecer com:

[[ams-a,98.099,1012,678,91],[bos-a,98.099,1111,12,91],...]

Minha pergunta:

  • Qual é a melhor maneira de determinar os valores discrepantes em cada coluna? Ou os discrepantes não são necessariamente a melhor maneira de atacar o problema de encontrar 'maldade'?

Nos dados acima, eu definitivamente gostaria de saber sobre bos-be ord-b, bem como ams-a, pois a taxa de erro é muito alta, mas os outros podem ser descartados. Dependendo da coluna, uma vez que maior não é necessariamente pior nem menor, estou tentando descobrir a maneira mais eficiente de fazer isso. Parece que numpy é mencionado muito nesse tipo de coisa, mas não sei por onde começar (infelizmente, sou mais administrador do sistema do que estatístico ...). Quando perguntei no Stack Overflow, alguém mencionou o uso da função percentual de pontuação do numpy e jogou algo acima do percentil 99 - isso parece uma boa idéia?

(Publicado em crossoverflow, aqui: /programming/4606288 )

Respostas:


13

Com base na maneira como você formula a pergunta

os discrepantes não são necessariamente a melhor maneira de atacar o problema de encontrar 'maldade'?

Não está claro que você está procurando discrepantes. Por exemplo, parece que você está interessado em máquinas com desempenho acima / abaixo de algum limite.

±

Por outro lado, pode haver boas razões para querer ser notificado de qualquer servidor com menos de 95% de disponibilidade, independentemente de haver ou não um ou muitos servidores abaixo desse limite.

Por esse motivo, uma pesquisa de outliers pode não fornecer as informações de seu interesse. Os limites podem ser determinados estatisticamente com base em dados históricos, por exemplo, modelando a taxa de erro como poisson ou a porcentagem de disponibilidade como variáveis ​​beta. Em uma configuração aplicada, esses limites provavelmente podem ser determinados com base nos requisitos de desempenho.


2
+1 para abordar a questão aparente (e não a declarada), que é muito mais objetiva.
whuber

4

Uma maneira simples de encontrar servidores anômalos seria assumir que eles estão distribuídos de forma idêntica, estimar os parâmetros da população e classificá-los de acordo com suas probabilidades, aumentando. As probabilidades da coluna seriam combinadas com o produto ou com o mínimo (ou alguma outra norma T). Isso funciona muito bem, desde que os outliers sejam raros. Para a detecção de outlier propriamente dita, os parâmetros estáveis ​​da população geralmente são estimados de forma iterativa, eliminando quaisquer outliers descobertos, mas isso não é vital desde que você inspecione manualmente a lista e evite limiares.

Para as probabilidades, você pode tentar Beta para as proporções e Poisson para as taxas.

Conforme apontado por David, a detecção de outlier não é a mesma coisa que análise de confiabilidade, que sinalizaria todos os servidores que excederem algum limite. Além disso, algumas pessoas abordariam o problema através das funções de perda - definindo a dor que você sente quando algum servidor está com disponibilidade de 50% ou taxa de erro de 500 e, em seguida, classifica-as de acordo com essa dor.


2

Identificar um dado ponto de dados como um outlier implica que há algum processo ou modelo de geração de dados do qual se espera que os dados venham. Parece que você não sabe ao certo quais são esses modelos para as métricas e os clusters que lhe interessam. Então, aqui está o que eu consideraria explorar: gráficos estatísticos de controle de processos .

A idéia aqui seria coletar a
-% Disponibilidade
- Solicitações / s
- Erros / s
-% Memory_Utilization

métricas para cada um de seus clusters. Para cada métrica, crie um subconjunto dos dados que inclua apenas valores "razoáveis" ou sob controle. Crie os gráficos para cada métrica com base nesses dados em controle. Em seguida, você pode começar a alimentar dados ao vivo com seu código de gráficos e avaliar visualmente se as métricas estão sob controle ou não.

Obviamente, fazer isso visualmente para várias métricas em muitos clusters pode não ser viável, mas isso pode ser uma boa maneira de começar a aprender sobre a dinâmica que você enfrenta. Você pode criar um serviço de notificação para clusters com métricas que ficam fora de controle. Nessa linha, eu brinquei com o uso de redes neurais para classificar automaticamente os padrões dos gráficos de controle como OK versus algum tipo específico de fora de controle (por exemplo,% de disponibilidade descendente ou comportamento cíclico em erros / s). Isso fornece as vantagens dos gráficos estatísticos de controle de processo (há muito usados ​​nas configurações de fabricação), mas diminui o ônus de ter que gastar muito tempo realmente analisando os gráficos, pois você pode treinar uma rede neural para classificar padrões com base na sua interpretação especializada.

Quanto ao código, existe o pacote spc no pypi, mas não tenho nenhuma experiência em usá-lo. Meu exemplo de uso de redes neurais (também ingênuo Bayes) pode ser encontrado aqui .


Obrigado por um ponteiro para algum código de exemplo, vou dar uma olhada!
septagram
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.