Recentemente, apresentamos o IBM Instana Crash Detector, que detecta e relata automaticamente encerramentos anormais de processos em todas as máquinas Linux® que executam o kernel Linux 4.8 e superior. A plataforma IBM Instana utiliza as funcionalidades do Extended Berkeley Packet Filter (eBPF) do kernel Linux para se conectar ao próprio kernel e começar a escutar os encerramentos de processos. Todos os encerramentos anormais são sinalizadas para o host agent, que as compara com os processos que monitora para evitar ruídos sobre processos que não são relevantes e, em seguida, envia as informações para o backend do IBM Instana. Foi demonstrado que essa funcionalidade é um divisor de águas para nossos clientes, pois trabalham na solução de incidentes.

Com o Crash Detector, o software IBM Instana entrega os dados críticos para muitos dos problemas que afetam o desempenho das aplicações de nossos clientes. Agora estamos aprimorando essa funcionalidade adicionando eventos de encerramento por memória insuficiente (OOM Killer) ao Crash Detector, o que é uma inclusão incrivelmente valiosa devido à sua relevância para aplicativos conteinerizados.

A nuvem pode fazer parecer que, se você tiver orçamento suficiente, terá um poder de computação infinito à sua disposição. No entanto, esse poder de computação vem em fatias. Servidores (físicos e virtuais), contêineres e funções, todos trazem limitações quanto à quantidade de memória que pode ser alocada.

No Linux, o encerramento por memória insuficiente (OOM) é um processo encarregado de impedir que outros processos esgotem coletivamente a memória do host. Se um processo tentar alocar mais memória do que a disponível, o processo com pontuação negativa geral mais alta, com base, por exemplo, na quantidade de memória alocada acima do permitido, receberá um sinal OOM. Isso significa fundamentalmente: "Você saiu da linha. Saia ou faça alguns dos seus processos filhos pararem, ou as luzes se apagarão".

Observe que o processo que aciona o OOM pode não ser o processo que recebe o sinal de OOM. Uma aplicação que não aumentou recentemente seu uso de memória pode, de repente, receber um sinal de OOM porque muitos outros aplicativos foram iniciados no mesmo host.

A mecânica de um sinal de OOM parece rígida, mas na verdade é um mecanismo muito eficaz para evitar o esgotamento da memória nos servidores, especialmente no caso de aplicativos não dimensionados corretamente ou de muitos aplicativos executados em paralelo (ou seja, os hosts não são dimensionados corretamente para a carga de trabalho).

Para plataformas conteinerizadas, como Kubernetes, Cloud Foundry e Nomad, o uso da memória, tanto em termos de dimensionamento adequado das aplicações quanto de quantidade de aplicações a serem executadas a qualquer momento em um servidor, é ainda mais importante. Geralmente, você não planeja em detalhes quais aplicativos estão sendo executados em um único nó. Em muitas configurações, os contêineres serão alocados de acordo com alguma lógica pelo orquestrador. Aplicar o consumo máximo de memória é crítico para contêineres e grupos de controle (cgroups), a base de praticamente todas as tecnologias de contêiner no Linux. Elas também utilizam o sistema matador OOM para garantir que os processos executados no mesmo grupo (ou seja, um contêiner) não aloquem mais memória do que o permitido. Quando os processos em seus contêineres tentam alocar mais memória do que o permitido, alguns serão encerrados, muitas vezes derrubando seus contêineres com eles.

Em escala, tudo é mais difícil, inclusive o dimensionamento. Quanto mais contêineres você executar em seus ambientes, mais difícil será entender quando, como e por que alguns deles ficam inativos. O encerramento por falta de memória pode criar situações não saudáveis para suas aplicações nas quais algo está sempre falhando em algum lugar e depois é reiniciado, criando uma quantidade contínua de erros para seus usuários finais que distorcem seus objetivos de nível de serviço (SLOs) e são muito difíceis de solucionar.

Descobrir por que um único processo foi descartado pelo OOM killer depende muito da tecnologia que você usa. Alguns pacotes de software o registrarão em seus próprios registros. Ou você pode acabar executando algum comando como o seguinte em seus servidores, em cada um deles:

     #CentOS
     grep -i "out of memory" /var/log/messages
     #Debian / Ubuntu
     grep -i "out of memory" /var/log/kern.log

Parece pouco, mas definitivamente não é o tipo de tarefa que você deseja executar em sua frota de produção para tentar entender por que o MySQL chutou o balde novamente às 3 da manhã. Especialmente quando é um palpite, já que nada mais parece explicar por que o processo de banco de dados não está mais lá.

Em outras palavras, o encerramento por memória insuficiente é um sistema de inegável importância e eficácia para a confiabilidade que não consegue oferecer observabilidade suficiente. Mas a plataforma IBM Instana está aqui para corrigir isso para você.

Expandindo sobre a base eBPF que trouxe o Crash Detector, o software IBM Instana agora vem com um detector de encerramento por memória insuficiente pronto para uso. Quando seu processo é monitorado pelo software IBM Instana, ele recebe um sinal de OOM em tempo real. Não apenas que aconteceu, mas também como a situação foi resolvida (ou seja, qual processo foi interrompido).

Semelhante à maioria dos recursos do IBM Instana, tudo o que você precisa fazer é instalar o agente de host do IBM Instana e observar o OOM killer cuidar de seus negócios sombrios. Ele também mostra quanta memória o processo eliminado alocou no momento do evento, para você saber por que ele foi marcado pelo encerramento por memória insuficiente como "ruim".

Determinar como e por que um processo foi encerrado ou por que um processo foi morto com um OOM killer pode levar horas — se não dias — para ser descoberto sem as ferramentas adequadas. Com o IBM Instana Crash Detector, os usuários agora têm imediatamente a causa raiz de cada término anormal de processo e de cada processo bem-sucedido que elimina o OOM.

Precisa saber por que um contêiner parou? Sem problemas. Com o IBM Instana Crash Detector OOM Killer, você saberá que talvez sua Máquina Virtual Java (JVM), que está executando um trabalho em lote muito importante, alocou mais recursos do que era permitido. Ou talvez você precise determinar a causa por estar tendo tantas falhas de solicitação do Hypertext Preprocessor (PHP) ou por que seu banco de dados sumiu. Novamente, com o IBM Instana Crash Detector OOM killer você terá acesso imediato à causa raiz desses problemas.

Para começar a poupar tempo para você e suas equipes de DevOps na solução de problemas de eventos de OOM, basta instalar o agente IBM Instana no seu sistema operacional Linux hoje mesmo. Se você ainda não tem uma instância do IBM Instana, pode ver como funciona o IBM Instana Crash Detector com detecção de encerramento por memória insuficiente com uma avaliação sem custo.