BT

Entendendo o comportamento de sistemas e softwares com Machine Learning e dados de séries temporais

| por Roland Meertens Seguir 8 Seguidores , traduzido por Leonardo Muniz Seguir 0 Seguidores em 09 out 2018. Tempo estimado de leitura: 11 minutos |

Pontos Principais

  • Antes de entrar em machine learning para o comportamento sistêmico de softwares, deve-se ter conhecimento sobre os conceitos de séries temporais.
  • Dados faltantes na sua série temporal podem levar a resultados inesperados enquanto estiver analisando-os. A "biblioteca Pandas" pode ajudar a trabalhar com o preenchimento destes valores de uma forma sensata.
  • Quando humanos estão usando seu serviço, espere pela sazonalidade em seus dados. Leve em conta este detalhe quando for desenhar seus algoritmos preditivos.
  • Tome cuidado com o limite definido no momento da detecção de anomalia. Eventos que são improváveis para um simples servidor, tornam-se muito prováveis quando estiver dimensionando sua aplicação.
  • Entenda o que estiver tentando alcançar quando estiver analisando séries temporais. Tenha certeza de não usar análises determinísticas como a linguagem SQL permite. Conheça o comportamento de seu algoritmo em uma escala matemática e se realmente está automatizando a interpretação deste, ou se está transformando dados em resíduos preditivos e os usando em suas análises.

No QCon.ai 2018, David Andrzejewski apresentou "Entendendo o Comportamento Sistêmico de Softwares com Machine Learning e dados de séries temporais". David é gerente de engenharia na Sumo Logic, uma plataforma em nuvem para análise de dados de máquinas. Os desenvolvedores que já estiverem rodando um software (como um app ou cluster em nuvem) podem usar a Sumo Logic como backend de seus logs de sistemas. A Sumo Logic proporciona inteligência contínua para dados de máquina.

Muitas coisas rodam em softwares, e técnicas de inteligência artificial estão entrando no mundo de softwares. Antes de entrar a fundo no impacto que o machine learning proporciona no comportamento sistêmico de softwares, é preciso entender as abordagens tradicionais relacionadas às séries temporais. Conhecer as limitações dos métodos tradicionais permite que faça trocas conscientes ao optar por alguma técnica. Primeiro, pergunte a você mesmo se conhece o que está tentando realizar. Uma vez que saiba, se questione se é possível cumprir isto com uma análise simples ou determinística. Olhe apenas para o machine learning quando os outros métodos forem impossíveis.

Entender o que seu software está fazendo e o porquê de estar falhando pode ser difícil. As empresas que implantam serviços que dependem de muitos outros microsserviços em vários servidores podem se beneficiar de um diagrama que lista as dependências entre estes microsserviços. Ao desenhá-lo, pode-se ter uma imagem do que as pessoas chamam de "estrela da morte" de microsserviços:

 

Muitas aplicações geram terabytes de logs por dia, que consistem de gigabytes de código fonte e geram milhões de métricas por minuto. Analisar este dado manualmente é impossível, então é preciso a inteligência de máquina. Entretanto, analisar os dados e encontrar apenas o que o seu sistema estiver REALMENTE fazendo é uma tarefa difícil senão impossível. Um artigo que vai mais a fundo na granularidade do dado e em qual momento você precisa dele é o "Poderia um neurocientista entender um microprocessador?". Os autores deste artigo usam um simulador para jogar uma versão antiga de Donkey Kong. Por possuírem a memória da simulação, tiveram acesso aos estado completo do sistema. Teoricamente, isto significa que é possível analisar o dado e tentar fazer uma engenharia reversa no que estiver acontecendo com um nível maior de entendimento, apenas por olhar o dado em detalhe. Embora essa tática possa proporcionar insights pequenos, é improvável que apenas olhar os dados permitirá você a entender completamente um nível maior de Donkey Kong.

Esta analogia torna-se importante para quando estiver usando apenas dados brutos para entender sistemas multiescala, dinâmicos e complexos. Agregar os dados brutos em visões de séries temporais torna o problema mais acessível. Uma boa fonte sobre isso é o livro "Site Reliability Engineering", que pode ser lido gratuitamente.

Entender sistemas multiescalas, dinâmicos e complexos é especialmente importante para um engenheiro em serviço. Quando um sistema cai, é preciso descobrir o que o sistema está realmente fazendo naquele momento. Por este motivo, o engenheiro precisa dos dados brutos e dos meios para visualizá-los, assim como métricas de alto nível que conseguem sumarizar os dados. Um engenheiro nesta situação normalmente quer entender como este servidor está se comportando quando comparado a outro servidor, ou a ele mesmo no dia anterior, ou a ele mesmo antes de uma atualização do software.

 

Vantagens e desvantagens dos percentis

Quando olhamos um longo histórico de dados (log), não entramos nos detalhes de milissegundos contínuos. Seus dados são quantificados em tempo. O caminho mais básico para fazer isso é utilizar funções como min, max, average (média), sum (soma) e count (contagem). Muitas pessoas que agregam dados gostam de usar percentis também. A vantagem dos percentis é que podem expressar seus dados em uma linguagem não ambígua. Um exemplo de sentença sem percentil é "O tempo máximo para carregar uma solicitação foi 4.300 milissegundos." Esta sentença é precisa mas não ajuda a determinar quão distante está dos padrões de uma operação normal que falhará. Porém, diga-se que "p99 é menos do que 2.000 milissegundos" indica que não mais que 1% das solicitações de clientes levam mais do que dois segundos para carregar.

A desvantagem dos percentis é que dificultam a combinação de dados em algo significativo. Embora os valores em torno do 50º percentil tendam a ser estáveis, os percentis mais altos variarão muito e têm uma distribuição longa de valores possíveis. Outro problema é ser fácil agregar as análises simples de vários conjuntos de dados. Pode-se calcular o mínimo de dois conjuntos de dados observando apenas os mínimos de ambos. No entanto, não se pode simplesmente usar os métodos com percentis. É matematicamente impossível combinar a p95 do dataset X e a p95 do dataset Y. Isso significa que é difícil dizer algo significativo sobre uma combinação de vários conjuntos de dados sem muito trabalho.

Conceitos importantes de séries temporais

Um aspecto básico de monitoramento para séries temporais são as comparações com mudança de periodicidade. Isso é particularmente importante se quiser comparar a latência de escrita de um cluster com a latência de escrita do mesmo host no dia anterior. Isso também pode ser combinado com "windowing data" (dados de janela), conhecido como "agrupamento ao longo do tempo". Mais informações podem ser encontradas na palestra do Tyler Akidau durante o QCon San Francisco 2016, na qual esse conceito foi discutido no contexto do Apache Beam.

O manuseio de dados faltantes também é importante. Antes de aplicar qualquer machine learning, é preciso saber como deseja lidar com os valores ausentes. Colocar valores constantes, como zeros ou infinitos, no lugar de valores ausentes provavelmente levará a resultados inesperados. No entanto, não colocar nada lá provavelmente fará com que tenha exceções de runtime posteriormente no loop. Isso pode ser prevenido usando pandas, uma biblioteca Python de análise de dados, que é um verdadeiro canivete suíço para manipulação de dados. Pode ser usado o método fillna(), que possui alguns valores padrão que são realísticos e sensatos. Observe que há muitas maneiras interessantes de preencher lacunas em seus dados e há muitas formas e métodos que podem ser usados. Algumas áreas chamam isso de "predição" de dados faltantes, outras áreas chamam de "imputação", "inferência" ou "amostragem". Você pode usar métodos de preenchimento, simplesmente preenchê-los ou interpolá-los.

 

Agindo nos dados

Uma coisa simples de se pensar ao configurar um sistema de logs é o alerta de limite fixo. O objetivo dos alertas é alertar alguém quando o site cair ou outro evento inesperado. Muitas pessoas iniciam o desenvolvimento de alertas contratando um especialista que pode definir limites sensatos para vários aspectos do sistema. Por exemplo, poderia ser definido um alerta para disparar assim que 5% das solicitações demorarem mais de dois segundos, notificando o engenheiro que está em serviço naquele momento.

Contudo, os especialistas humanos não escalam bem. Talvez queira automaticamente comparar o comportamento de algumas máquinas com as de outras máquinas, especialmente quando se tem muitas máquinas disponibilizando muitas séries temporais. Não se pode analisar e comparar todas essas séries temporais sozinho, e um grande número de máquinas pode impedir a comparação entre séries temporais. Este é o ponto onde pode-se tentar aplicar o machine learning.

Modelos preditivos e outliers

Uma abordagem possível é a detecção de outliers usando modelagem preditiva. Ao prever o comportamento normal de suas máquinas, também pode-se detectar quando suas máquinas agem fora da saída esperada. No entanto, é preciso levar muito em consideração antes de se fazer isso. Existem quatro perguntas-chave a se fazer:

  • O comportamento é realmente regular?
  • Como o comportamento pode ser modelado?
  • Como pode ser definido um grande desvio do que é esperado?
  • É realmente valioso detectar surpresas e desvios do que é esperado?

Algo importante a se considerar ao fazer a modelagem preditiva é a sazonalidade ou o ritmo de seus dados. Qualquer serviço que tenha humanos no circuito tem potencial para um ritmo. Por exemplo, a maioria das pessoas usa a Sumo Logic no trabalho, o que significa que os dados de uso da Sumo Logic para qualquer país mostrarão muita atividade durante o horário normal de trabalho, mas não tanto fora desse horário. Porém, os dados de uso do Netflix provavelmente mostram uma tendência inversa. Isso pode ser modelado ajustando manualmente seus dados ou usando transformadas de Fourier. Outra opção que muitas pessoas usam são os modelos ocultos de Markov.

 

Mineração de dados de séries temporais baseada em distância

Quando se tem várias máquinas, provavelmente é desejável comparar o comportamento das máquinas entre si. Se nota-se um comportamento estranho em uma máquina, é desejável descobrir se outras máquinas estão se comportando da mesma maneira. Talvez cada uma esteja executando versões diferentes de software, talvez estejam no mesmo data center ou talvez alguma outra coisa esteja acontecendo. Para analisar isso, deve-se comparar a distância entre as séries temporais.

 

Qual métrica deve ser usada para determinar a similaridade entre duas séries temporais? Simplesmente diferenciá-las de hora em hora subtraindo uma da outra obrigatoriamente dará resultados errados. Na imagem acima, embora as séries temporais sejam bastante semelhantes, essa métrica dirá que são completamente diferentes.

Existe todo um universo de métricas que pode ser usado. Uma técnica popular é a distorção dinâmica do tempo, que basicamente questiona como se pode transformar, deformar ou distorcer sua série temporal para colocá-los no melhor alinhamento e qual penalidade terá que ser paga por essa modificação. Com essa métrica, pode-se localizar os N hosts que se comportam de maneira mais semelhante ou pode-se criar um gráfico de similaridade de host. O uso de clustering espectral pode fornecer uma imagem que informa sobre qualquer estrutura em seus hosts.

 

Detecção de anomalias e classificação de eventos com dados de log

Existem maneiras de transformar seus dados de log em uma série temporal. Quando se tem um alto volume de strings semi-estruturadas, pode-se contar as mensagens ou extrair informações delas. Esses logs são um rastreamento aproximado da execução de programa. Como não se pode inserir um depurador para suas máquinas depois de estarem em produção, só é possível deduzir o comportamento do seu software por meio dessas mensagens de log. Se o seu programa imprimir uma string toda vez que uma solicitação expirar, será possível contar o número de tempos limite a cada hora. Isso resultará em uma série temporal, que você acabou de aprender a analisar!

Talvez seja tentado a definir um limite nos valores de certas séries temporais. No entanto, não queira se enganar pensando que encontrou um evento interessante quando, na verdade, o evento não tinha nada demais. Imagine que tenha um modelo super-preciso e deseja enviar um alerta sempre que houver apenas 0,01% de chance de ocorrer um padrão. Com um serviço com um milhão de séries temporais, pode-se esperar cerca de cem falsos positivos. Baron Schwartz, em sua palestra "Por que ninguém se importa com sua detecção de anomalias", entra em mais detalhes sobre quais técnicas deveriam ser usadas para determinar um limite.

Com todos os avanços recentes em deep learning, talvez queira usar isso para ajudar nas previsões e detecção de anomalias, mas o deep learning ainda não consegue nos livrar da compreensão do domínio do problema. Ainda é preciso encontrar uma maneira de enquadrar seus problemas. Uma abordagem possível é o uso de redes neurais recorrentes para prever. Essa é uma ótima ideia se tiver acesso a muitos dados de treinamento. Se não, sua primeira prioridade deveria ser a agregação dos dados antes de tentar fazer algo com eles.

Para concluir, a toca do coelho no quesito de dados de inspeção é muito funda. Temos máquinas controlando nossas vidas. E essas máquinas produzem dados, mas analisar os dados é complicado, por isso temos as ferramentas de machine learning, que são delicadas. É de grande importância evitar ruídos e falsos positivos, e para fazer isso, é preciso ter certeza de que se entende o que se está tentando fazer. Saiba por que não está usando análises determinísticas semelhantes ao SQL e entenda os métodos usados em escala matemática. Por fim, saiba se está automatizando a interpretação ou transformando dados em resíduos preditivos e usando isso para previsão de anomalias.

Sobre o Autor

Roland Meertens é engenheiro de visão computacional e trabalha com inteligência artificial para a percepção lateral de veículos autônomos na Autonomous Intelligent Driving, uma subsidiária da Audi. Trabalhou em coisas interessantes como tradução de máquina neural, prevenção de obstáculos para pequenos drones e um robô social para pessoas idosas. Além de publicar notícias sobre machine learning no InfoQ, às vezes publica em seu blog PinchofIntelligence e Twitter. Em seu tempo livre, gosta de correr pela floresta e participar de corridas de obstáculos.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT