Durante o processo de desenvolvimento de software, a identificação de interferências e falhas é um desafio complexo. Esses problemas muitas vezes surgem durante o processamento de transações e consomem recursos do sistema, o que dificulta a detecção por meio da depuração tradicional. Além disso, nem sempre o "waiting" (espera) e a "contention" (contenção) são indicativos de falhas; eles podem ser processos normais dentro da operação do sistema. No entanto, quando esses fenômenos se tornam frequentes ou prolongados, tornam-se anômalos e requerem investigação para identificar e resolver suas causas.

As causas raiz de falhas podem ser amplas, mas existem nove tipos principais relacionadas ao uso de recursos do sistema. As exceções, erros, contenções, esperas, interrupções, saturações, congestionamentos, bugs e falhas são os principais tipos de causas que podem impactar o desempenho e a estabilidade do sistema. Essas causas, apesar de parecerem semelhantes, possuem características distintas que tornam sua identificação essencial para a correção eficaz do problema. Cada uma dessas causas, quando ocorre, tende a produzir sinais e padrões de comportamento que podem ser analisados e medidos com ferramentas apropriadas.

Quando as exceções não são tratadas adequadamente, elas podem se transformar em erros, levando à falha do sistema. As exceções e erros são algumas das causas raiz mais comuns com as quais os desenvolvedores se deparam. O uso excessivo de recursos do sistema, como a saturação da largura de banda de rede ou cache, resulta em congestionamento e espera. Além disso, interrupções em discos e Ethernet são formas de interferência que também podem contribuir para a contenção e o atraso no sistema. No entanto, essas situações podem se sobrepor e dificultar a categorização clara dos problemas. Embora a distinção entre essas causas nem sempre seja essencial, a compreensão de como elas se inter-relacionam e a capacidade de identificar a origem do problema são vitais para a resolução.

Quando se fala sobre o "waiting", é importante notar que esse tipo de atraso pode ocorrer não apenas na CPU, mas também em outros componentes do sistema, como disco, rede e memória. Esperas podem acontecer devido a vários fatores, incluindo problemas de agendamento, E/S ou bloqueios. O objetivo é minimizar tanto o número quanto a duração das esperas desnecessárias. Nos sistemas com CPUs multithreaded, os gargalos podem ser causados pela unidade de execução de instruções, pelo cache ou pela memória compartilhada entre os núcleos. No caso de um único thread, o gargalo geralmente ocorre devido à memória compartilhada ou cache. Se os threads filhos não recebem uma fatia justa de tempo de CPU, ou se não iniciam corretamente, o programa enfrentará atrasos. Isso pode incluir pequenas esperas relacionadas ao uso completo de todos os núcleos da CPU, a retomada de núcleos inativos ou problemas de agendamento que não distribuem o tempo de maneira justa entre os threads.

A medição e monitoramento do comportamento de cada núcleo da CPU em intervalos de nanosegundos podem ser feitas por ferramentas como o KUtrace. O KUtrace permite capturar o comportamento de cada thread, incluindo loops de espera, falhas de página, threads do núcleo e interrupções que podem causar latências significativas no sistema. Ao observar o comportamento dinâmico entre threads, é possível identificar o impacto do agendamento de threads no desempenho geral do programa.

Um exemplo claro desse comportamento é quando cinco processos filhos são agendados para execução em quatro núcleos da CPU. A alocação de tempo não é feita de forma uniforme, resultando em atrasos. Alguns threads podem ser alocados para execução consecutiva antes de retornar ao estado de espera. O agendamento não é sempre constante, variando conforme o comportamento do sistema. No caso de um thread precisar ser movido para outro núcleo da CPU, ele pode sofrer um "cache miss" (falha de cache), o que resulta em um atraso. Essa mudança de núcleo também pode ocorrer devido ao processo de troca de contexto, onde o thread é movido de um núcleo inativo para outro núcleo que está pronto para ser utilizado. Se o novo núcleo não compartilhar o cache, o thread enfrentará um atraso até que os dados necessários sejam carregados novamente.

Além disso, o comportamento do agendador de threads também pode ignorar momentos de ociosidade, o que causa outro tipo de ineficiência. O agendador pode tomar decisões autônomas baseadas na carga de trabalho do sistema, muitas vezes sem considerar as melhores opções de alocação de tempo de CPU.

Portanto, o entendimento de como o sistema de agendamento de threads e o gerenciamento de recursos interagem é crucial para a identificação e solução de problemas. O impacto das escolhas de agendamento no desempenho do sistema pode ser sutil, mas sua análise cuidadosa permite que o desenvolvedor detecte falhas e otimize o uso dos recursos de maneira mais eficaz.

Como o Ftrace e Ferramentas de Observabilidade Ajudam na Análise de Causa Raiz no Kernel

O método __schedule() é responsável pela troca de contexto no kernel, e é nele que se encontra a execução da função context_switch(), responsável por alternar entre processos. O comportamento do escalonamento de processos pode ser monitorado através do uso de ferramentas como o ftrace, que facilita a análise de eventos importantes relacionados à execução de tarefas no kernel. Para utilizar o ftrace, é necessário modificar as configurações de Kernel hacking > tracers no menuconfig e recompilar o kernel. Caso o kernel tenha sido compilado e instalado durante a instalação do KUtrace, o ftrace pode ser utilizado sem configurações adicionais.

A observabilidade no kernel é construída com base em convenções de nomenclatura que ajudam a entender o código e a diagnosticar problemas de maneira mais rápida. Entre os eventos gerados pelo ftrace, dois dos mais comuns são os eventos sys_enter e sys_exit, que indicam a entrada e saída de chamadas de sistema. Para coletar esses eventos, é preciso habilitá-los com comandos específicos e iniciar a captura com a instrução tracing_on.

No momento em que uma chamada de sistema é executada, o fluxo de execução transita do espaço do usuário para o espaço do kernel, e o manipulador da chamada de sistema chama um método interno. Esse processo é finalizado com a execução do ret_fast_syscall, que retorna ao espaço do usuário. Através do ftrace, podemos observar o número da chamada de sistema através de mensagens, como NR 120, indicando o número da chamada, e o método associado, como o sys_clone() para a chamada de sistema número 120. Este método está presente no arquivo unistd-common.h e segue a convenção de nomenclatura sys_, sendo um exemplo de como o sistema lida com chamadas de clonagem de processos.

Para facilitar a interpretação das informações geradas pelo ftrace, existem ferramentas de código aberto como o Traceshark, que oferecem uma interface gráfica para visualizar eventos do ftrace e do Perf. Entre os eventos mais importantes monitorados estão o cpu_frequency, sched_process_fork, sched_switch, e sched_wakeup. Esses eventos ajudam a entender como o sistema lida com mudanças no estado dos processos e no escalonamento de tarefas.

O Perfetto é outra ferramenta útil que pode ser empregada para a visualização de traces e eventos do kernel. Ambas as ferramentas, Traceshark e Perfetto, são recomendadas para análise mais profunda de como o kernel lida com as tarefas e chamadas de sistema, facilitando a observação de gargalos de performance e identificando problemas durante o processo de execução.

A análise de causa raiz, no entanto, não depende apenas de ferramentas como o ftrace, mas também de utilitários do sistema. Ferramentas como jstack, vmstat, lsof, perf, mpstat e top são essenciais para o diagnóstico preciso de problemas relacionados ao desempenho do sistema. O jstack, por exemplo, permite a coleta de rastros de pilha para identificar threads problemáticas, enquanto o vmstat fornece uma visão geral da saúde do sistema, incluindo informações sobre a CPU e I/O de memória e disco. Ferramentas como o top e o ps ajudam a monitorar a utilização da CPU, indicando se há sobrecarga no espaço do kernel ou do usuário, o que pode indicar um alto número de trocas de contexto ou chamadas de sistema intensivas.

Além disso, a compreensão do impacto de diferentes chamadas de sistema é fundamental. Por exemplo, a utilização de algoritmos de criptografia, como o AES para conexões HTTPS, pode aumentar significativamente a carga no espaço do kernel, devido ao processamento intensivo realizado pelo servidor. Em ambientes onde há muitas conexões HTTPS, o valor de sy (uso de CPU no espaço do kernel) pode aumentar, refletindo a quantidade de trabalho que o kernel está realizando.

Embora as ferramentas mencionadas ofereçam uma visão poderosa sobre o comportamento do sistema, o uso contínuo dessas ferramentas pode se tornar difícil de automatizar e colaborar, especialmente quando se trata de análise em ambientes de AIOps (Automated IT Operations) e detecção de anomalias. Contudo, elas desempenham um papel essencial quando se trata de investigar problemas em sistemas onde a observabilidade é limitada, proporcionando as informações necessárias para realizar uma análise detalhada de causa raiz.

Como Detectar Anomalias Sem Limites e Configurar Alertas e Dashboards

A observabilidade da infraestrutura e a detecção de anomalias são tecnologias complementares. Ao invés de utilizar a detecção de anomalias baseada apenas em aprendizado de máquina, a validação utilizando SQL pode fornecer resultados mais precisos. O OpenSearch oferece uma ampla gama de funcionalidades. Além da análise básica de texto, a observabilidade, a detecção de anomalias e os bancos de dados vetoriais são recursos valiosos. Este capítulo explora a detecção de anomalias no OpenSearch e os bancos de dados vetoriais.

Escolhi o OpenSearch para detecção de anomalias pelas seguintes razões:

  • Oferece uma variedade de APIs e facilita a configuração da detecção de anomalias.

  • É simples configurar dashboards e alertas de detecção de anomalias.

  • Com o notebook fornecido, é fácil desenvolver com outros frameworks de aprendizado de máquina.

  • Possui força na análise de logs e pode combinar rastros e métricas gerenciadas pela observabilidade.

A detecção de anomalias deve ser configurada de maneira a permitir validação incremental e precisão progressiva. Não recomendo utilizar a detecção de anomalias do OpenSearch de forma isolada para configurar a detecção baseada em inferências. O SQL proporciona boas capacidades para detecção de anomalias, e a combinação de SQL com as inferências fornecidas pelo OpenSearch oferece uma solução mais robusta.

Anomalia é uma característica que difere das demais de um mesmo grupo. Em termos de dados, ela se refere a registros que são diferentes do restante dos dados e causam suspeitas; palavras semelhantes incluem outliers, novidades, ruídos e desvios. A detecção de anomalias pode ser feita literalmente para identificar tais anomalias ou como um passo intermediário em um projeto de análise maior. O processo de encontrar anomalias é o mesmo, independentemente do que as causou, mas, para resolvê-las, é preciso entender com precisão qual é a causa raiz da anomalia para que se possa responder de forma adequada.

As anomalias podem sinalizar transações incomuns, intrusões na rede, falhas estruturais no produto, fraquezas nas políticas ou o uso do sistema de maneiras não previstas pelos desenvolvedores. Podem ser causadas por usuários mal-intencionados que abusam do sistema ou por clientes que usam o produto de maneiras não previstas.

O SQL é uma linguagem versátil e poderosa, útil para uma ampla gama de análises de dados. Escrever detecção de anomalias em SQL tem a vantagem de ser mais fácil de entender porque um registro específico foi processado como um outlier, em comparação com regras ou aprendizado de máquina. Mesmo se o banco de dados mudar, o SQL permanece imune e sempre executa o mesmo comportamento.

Existem situações em que o SQL não é útil. O SQL não fornece análise estatística sofisticada como o Python, embora ofereça alguns métodos estatísticos padrão. Em alguns bancos de dados, até cálculos estatísticos moderadamente complexos podem ser demorados. Além disso, levará tempo para carregar os dados durante a análise no banco de dados, tornando o SQL inadequado quando for necessário detectar rapidamente uma anomalia, como na detecção de transações anômalas ou intrusões. Nesses casos, um procedimento típico de detecção de anomalias é realizar uma análise inicial em SQL para determinar os valores mínimo, máximo e médio dentro do escopo normal, e então realizar o monitoramento em tempo real com dados atualizados. Se um padrão de outlier for detectado durante o monitoramento, o serviço de streaming pode ser configurado para processá-lo.

Uma outra situação em que o SQL não é apropriado para detecção de anomalias é quando o código SQL opera com uma base de regras estáticas. Embora seja ótimo para lidar com dados de campos bem conhecidos, ele não consegue adaptar automaticamente suas condições de análise para tipos de padrões anômalos que mudam rapidamente. Aqui, entram as regras e o aprendizado de máquina. Existem várias maneiras de detectar outliers no conjunto de dados:

  • Usando a cláusula ORDER BY para classificar os dados e encontrar outliers.

  • Usando a cláusula GROUP BY para encontrar outliers ao determinar a frequência de cada valor armazenado em um campo.

Esses métodos permitem utilizar os métodos estatísticos do SQL para encontrar outliers que estão fora do escopo usual.

Ao trabalhar com conjuntos de dados, a primeira tarefa é entender os dados. Isso é feito através de uma técnica chamada profiling (perfilamento), que permite uma compreensão profunda dos dados antes de realizar qualquer análise.

Detecção de Anomalias com SQL

Para detectar anomalias, a melhor forma de entender os campos específicos no seu conjunto de dados é verificar a frequência de ocorrência de cada valor por campo. Verificar as frequências é útil para descobrir se um determinado valor tende a ocorrer mais ou menos, ou se há valores inesperados e como eles surgiram. Isso pode ser aplicado a qualquer tipo de dado, incluindo strings, números e datas, e também é eficaz para encontrar dados esparsos. Basta especificar o campo a ser analisado com a cláusula GROUP BY e utilizar o comando count(*) para obter o número de ocorrências de cada valor. Gráficos de frequência podem ser usados para visualizar a distribuição dos valores, com o valor no eixo X e a frequência no eixo Y.

A maneira básica de identificar outliers com SQL é ordenar os dados utilizando a cláusula ORDER BY. Essa cláusula permite ordenar os dados em ordem crescente ou decrescente, e você pode ordenar por uma ou mais colunas, de forma que os outliers mais evidentes apareçam no topo ou no final da lista.

Outro método é utilizar o conceito de percentil. Visualizar os resultados da ordenação dos dados é uma excelente maneira de encontrar anomalias, especialmente quando existem valores extremos misturados com os dados normais. Quantificar a distribuição dos dados proporciona uma nova perspectiva sobre o conjunto. Existem diversas maneiras de calcular percentis, como a mediana, o percent_rank, o percentile_cont, o percentile_disc e o ntile. O percentil indica a porcentagem de dados que é menor do que um determinado valor. A mediana, que corresponde ao percentil 50, é o valor que divide os dados ao meio, com metade maior e metade menor.

Ao verificar a distribuição dos dados, frequentemente desejamos checar a mediana. Muitos bancos de dados oferecem um método de mediana, que retorna o valor correspondente à mediana dos dados no campo especificado. Caso o banco de dados não ofereça esse método, pode-se utilizar o método ntile. Ambos os métodos são considerados métodos de janela, pois realizam operações sobre múltiplas linhas e retornam um único valor como resultado.

A criação de intervalos para valores contínuos também é uma maneira útil de analisar dados. Em vez de contar a ocorrência de cada valor, você agrupa os dados com base em intervalos de valores. Esses intervalos, chamados de "buckets", podem ser ajustados dependendo do objetivo da análise. O método ntile é ideal para intervalos, enquanto o percent_rank pode ser utilizado para criar uma visualização contínua dos dados e gerar relatórios para análises futuras.

Como Aplicar Práticas de Observabilidade em Sistemas Legados: Integração com Tuxedo e CICS

A implementação de práticas de observabilidade em sistemas legados pode ser um desafio significativo, mas é um passo crucial para a melhoria da análise de desempenho e resolução de problemas. No contexto de servidores como o Tuxedo e o CICS, o processo de integração de tecnologias modernas de monitoramento exige uma abordagem cuidadosa para não comprometer a integridade e o funcionamento das aplicações. Neste capítulo, exploraremos como a observabilidade pode ser aplicada em servidores como o Tuxedo, bem como em sistemas legados, como o CICS utilizado no setor bancário.

O Tuxedo, um servidor de transações distribuídas, pode ser integrado a ferramentas de observabilidade modernas através da utilização de APIs e adaptadores específicos. O TIBCO Tuxedo Adapter, por exemplo, utiliza o formato de mensagem FML32 para comunicar-se com o servidor Tuxedo. Ao configurar o ambiente para iniciar o servidor Tuxedo, é essencial definir variáveis de ambiente como TUXDIR, WSNADDR e APPDIR, além de executar o comando tmboot para iniciar os processos necessários. O processo de inicialização envolve a ativação de três processos principais: o BBL (processo de administração), o WSL (processo de servidor) e o servidor de aplicação propriamente dito.

Ao aplicar práticas de observabilidade, a instrumentação do cliente é fundamental. A medição da latência entre o cliente e o servidor pode ser realizada por meio da instrumentação no cliente, permitindo a criação de spans que capturam cada etapa do processo. Através do OpenTelemetry, é possível monitorar todos os passos de comunicação com o servidor Tuxedo, medindo latência, taxa de erros e throughput. A criação de spans para cada etapa do processo é uma parte essencial dessa prática. Esse processo permite uma análise detalhada do desempenho e facilita a identificação das causas-raiz de falhas, o que era uma tarefa difícil sem a tecnologia de rastreamento de ponta a ponta (E2E) que temos hoje.

Outro ponto a ser destacado é a integração com a base de dados. Ao medir as chamadas do servidor para o banco de dados, é possível gerar spans adicionais que capturam detalhes cruciais para a análise de desempenho. No entanto, é importante notar que essa abordagem exige testes rigorosos, pois a instrumentação excessiva pode afetar o desempenho do servidor. A observabilidade, portanto, não se limita apenas à monitorização do servidor, mas envolve também a coleta de dados a partir de todos os componentes envolvidos no processo, incluindo o banco de dados.

De maneira análoga, o sistema CICS (Customer Information Control System), frequentemente utilizado em ambientes bancários, também exige uma abordagem cuidadosa quando se trata de integração com práticas de observabilidade. O CICS, que foi projetado para ambientes mainframe e tradicionalmente opera com a linguagem Cobol, apresenta desafios únicos quando se trata de instrumentação. O OpenTelemetry, por exemplo, não oferece suporte direto para a instrumentação de aplicações desenvolvidas em Cobol. A resistência à alteração de sistemas bancários legados e a dificuldade de modificar o código-fonte de Cobol tornam o processo ainda mais complexo.

Neste cenário, a abordagem recomendada é instrumentar o cliente CICS em vez de tentar modificar diretamente o código Cobol. O CICS Transaction Gateway (CTG), que pode ser utilizado como uma interface entre o cliente e o CICS, é uma solução eficiente. Além disso, é possível utilizar sockets ou a API SNA para estabelecer a comunicação com o CICS, sem necessidade de modificar a aplicação Cobol diretamente. A utilização de adaptadores, como o TIBCO CICS Adapter, também é uma maneira eficaz de integrar sistemas legados ao moderno ambiente de monitoramento de observabilidade.

A instrumentação de sistemas legados, como o CICS e o Tuxedo, exige um planejamento cuidadoso para garantir que a performance do sistema não seja impactada. Em sistemas bancários, onde a segurança e a confiabilidade são cruciais, a integração de novas tecnologias deve ser feita de maneira gradual e com validações constantes. Os operadores de sistemas legados, especialmente no setor bancário, tendem a ser conservadores e relutantes em modificar suas infraestruturas, o que torna a implementação de soluções de observabilidade um processo que deve ser bem planejado.

Para alcançar a observabilidade completa em sistemas como o CICS, além de monitorar a comunicação entre os servidores e os clientes, é importante considerar a instrumentação de todas as etapas do processo de transação. Isso inclui medir a latência em cada transação, monitorar a taxa de erro e garantir que o throughput esteja dentro dos limites estabelecidos. A coleta de dados sobre o desempenho da rede e dos bancos de dados também é essencial para garantir que todas as falhas sejam identificadas e corrigidas de maneira eficaz.

Endtext

Como a Função Ventricular Direita é Afetada em Pacientes com Implante de LVAD
Como a inteligência artificial transforma a detecção de incêndios e fumaça em ambientes urbanos
Como tratar mordidas de animais e crises asmáticas graves: abordagens e terapias eficazes
A Aplicação de Phasores em Microscopia de Localização de Molécula Única e Análises Multidimensionais
Como o Ensino Pode Ser Mais Eficaz ao Entender os Princípios Fundamentais do Aprendizado