Práticas recomendadas de observabilidade full-stack full-link do TiDB com base no DeepFlow

Resumo: Por ser um excelente software de banco de dados distribuído de código aberto, o TiDB tem recebido cada vez mais atenção e aplicações dos usuários, porém, no processo de garantia de operação e manutenção, também enfrenta ilhas de operação e manutenção, dificuldade de delimitação e posicionamento, e o. sobrecarga de obtenção de dados observáveis ​​Este artigo resume as melhores práticas para usuários do TiDB construir observabilidade full-stack com base no DeepFlow, incluindo como usar a tecnologia de observabilidade de alto desempenho e intrusão zero do DeepFlow para eliminar os pontos cegos do rastreamento de link completo no. o lado do TiDB e como usar a tecnologia de observabilidade de alto desempenho e intrusão zero do DeepFlow para eliminar pontos cegos no lado do TiDB .

01: Desafios de operação e manutenção de bancos de dados distribuídos

Na operação e manutenção diária, os DBAs de bancos de dados distribuídos geralmente enfrentam três desafios:

  • Desempenho de dados de observação em tempo real : Como o método de instrumentação tradicional trará perdas óbvias de desempenho, o DBA só permitirá o recurso de rastreamento distribuído integrado do TiDB após a ocorrência de uma exceção de negócios, que só pode ser feita por meio de pós-análise e recorrência repetida. e posicionamento passivo.
  • Abrangência dos dados de observação : A operação e manutenção tradicional do banco de dados depende principalmente dos próprios dados do banco de dados, faltando dados em tempo real de aplicativos clientes, recursos do sistema, leitura e gravação de arquivos de banco de dados, desempenho da rede do servidor e outras dimensões, e o ambiente circundante está em um ponto cego diagnóstico.
  • Continuidade de observação e diagnóstico : As ferramentas de monitoramento tradicionais possuem separação de dados entre si. O diagnóstico de falhas geralmente precisa ser transferido entre diferentes equipes de operação e manutenção.

Os problemas acima levaram à desconexão entre a operação e manutenção do banco de dados e outras operações e manutenção, formando uma ilha de operação e manutenção. Os riscos da operação comercial são difíceis de detectar, as falhas são difíceis de demarcar, os ciclos de recuperação são longos, a comunicação e a colaboração são numerosas. , e os conflitos de operação e manutenção são numerosos.

DeepFlow fornece ao TiDB recursos de observação full-stack, full-link e prontos para produção por meio de vários recursos principais, como intrusão zero, coleta de dados de observação de alto desempenho, acesso aberto a dados de observação e análise unificada de correlação de dados de observação, ajudando o DBA a construir - monitoramento de link, delineamento rápido de falhas, análise de causa raiz e outros recursos para melhorar efetivamente a eficiência da operação e manutenção de banco de dados distribuído e resolver os pontos problemáticos de operação e manutenção mencionados acima.

02: Solução de implantação de observabilidade TiDB

Figura 1 - Arquitetura geral de implantação de observabilidade do TiDB

No plano de prática de observabilidade TiDB, implantamos automaticamente o DeepFlow Agent no nó do cluster de negócios e no cluster de banco de dados distribuído TiDB para coletar e coletar dados de observação multidimensionais. Os dados de observação estruturados são transmitidos através da rede e processados ​​uniformemente (rotulagem de dados unificada; , dados associados unificados e dados de análise unificados) são armazenados centralmente no DeepFlow Server por meio de um design funcional que segue de perto o cenário de operação e manutenção. Esses dados fornecem recursos flexíveis e multidimensionais de observação e análise de pilha completa, de macro a micro; .

O DeepFlow Agent coleta e coleta dados de observação ricos, incluindo:

  1. Dados de intrusão zero eBPF : rastreamento de cadeia de chamadas, indicadores de desempenho SQL, logs de chamadas SQL, indicadores de desempenho de rede, logs de fluxo de rede, eventos de leitura e gravação de arquivos, desempenho de CPU e outros dados de observação
  2. Dados de instrumentação OpenTelemetry : dados de rastreamento da cadeia de chamadas dentro de cada componente do TiDB
  3. Dados do exportador Prometheus : indicadores do sistema K8s, indicadores de desempenho TiDB

Figura 2 - Coleta de dados de observabilidade do DeepFlow e diagrama de coleta

03: Rastreamento da cadeia de chamadas

Na prática de observação full-stack do TiDB do DeepFlow, alcançamos recursos de rastreamento de cadeia de chamadas de link completo, incluindo aplicativos front-end, redes intermediárias, TiDB-Proxy e TiDB por meio da tecnologia eBPF em comparação com a tecnologia APM tradicional, a cadeia de chamadas. implementado pelo DeepFlow Tracking possui os seguintes recursos vantajosos:

  • Sem pontos cegos : elimina pontos cegos de rastreamento em TiDB, middleware de gateway e redes intermediárias;
  • Alto desempenho : Rastreamento de alto desempenho e sem intrusão obtido por meio da tecnologia eBPF cria capacidades de produção e rastreamento sem amostragem prontas para TiDB;
  • Recarga a quente : por meio do recurso de troca a quente de código da tecnologia eBPF, os recursos de rastreamento on-line estão disponíveis em aplicativos e clusters TiDB a qualquer momento . Mesmo pequenas oscilações de desempenho podem ser observadas continuamente em um nível refinado para descobrir e eliminar rapidamente os riscos do sistema.
  • Pilha de tecnologia cruzada : por meio do recurso de rastreamento de pilha completa, o rastreamento unificado e a colaboração unificada de várias pilhas de tecnologia de operação e manutenção, como DBA, desenvolvimento de banco de dados, operação e manutenção de sistema e operação e manutenção de aplicativos, são realizados para determinar rapidamente limites de falha e melhorar a eficiência da colaboração técnica.

1) Rastreamento da cadeia de chamadas sem pontos cegos

Podemos responder a essa pergunta por meio de um diagrama esquemático simples: por que, em comparação com as soluções de instrumentação tradicionais, a coleta de intrusão zero do DeepFlow eBPF realmente alcança o rastreamento da cadeia de chamadas sem pontos cegos?

Figura 3 – Comparação da cobertura de três soluções diferentes de rastreamento de cadeia de chamadas

Instrumentação de aplicação

A tecnologia APM tradicional rastreia a cadeia de chamadas do aplicativo por meio da instrumentação do código do aplicativo. O escopo de observação é limitado ao escopo do aplicativo que pode ser instrumentado. A capacidade de rastreamento forma um ponto cego de observação no lado do TiDB. impossível determinar rapidamente se o TiDB é a origem do problema.

Instrumentação de aplicação + instrumentação TiDB

Para estender o recurso de rastreamento da cadeia de chamadas do aplicativo ao TiDB, enviamos um PR à comunidade TiDB para reparo de código e implementamos o recurso de rastreamento no lado do TiDB. No entanto, descobrimos mais tarde que ainda existem três problemas com a instrumentação no TiDB:

  • A rede no ambiente operacional TiDB está em um ponto cego de rastreamento e o impacto da rede no desempenho do SQL não pode ser diagnosticado;
  • O TiDB-Proxy na frente do TiDB está em um ponto cego de rastreamento e não consegue diagnosticar o impacto do TiDB-Proxy no desempenho do SQL;
  • O desempenho da resposta após a instrumentação TiDB caiu significativamente (veja abaixo dados específicos) e não pode ser usado continuamente em um sistema de produção.

Coleta de intrusão zero DeepFlow eBPF

O recurso de rastreamento da cadeia de chamadas de intrusão zero construído por meio da tecnologia eBPF do DeepFlow elimina os pontos cegos de rastreamento do TiDB e possui recursos completos de rastreamento para os seguintes locais em qualquer processo de chamada de aplicativo: 1) aplicativo front-end 2) TiDB-Proxy 3) TiDB; 4) Rede K8s.

Neste ponto, podemos rastrear uma certa resposta lenta no gráfico em chama de rastreamento da cadeia de chamadas do DeepFlow, observar intuitivamente a proporção de contribuição de cada posição para o atraso de resposta e, assim, determinar rapidamente a localização da fonte de uma certa resposta lenta:

Figura 4 - Gráfico em chama de rastreamento da cadeia de chamadas do DeepFlow

Por exemplo, na figura a seguir, podemos determinar claramente em uma parte de um gráfico em chama de rastreamento da cadeia de chamadas do DeepFlow que a COM_QUERY COMMITchamada do MySQL em um determinado processo de negócios introduz um atraso de 480 ms no processamento do processo tidb-proxy:

Figura 5 - Parte do gráfico em chama de rastreamento da cadeia de chamadas do DeepFlow

2) Rastreamento da cadeia de chamadas de alto desempenho

A questão mais crítica que dificulta a implementação da observabilidade do TiDB em sistemas de produção reais é o desempenho da coleta de dados de observação.

Descobrimos que quando tecnologias como instrumentação no aplicativo e aprimoramento de bytecode do Agente Java são usadas para implementar a coleta de cadeia de chamadas, elas podem causar um consumo adicional de recursos significativo e difícil de definir e podem introduzir perdas significativas de desempenho de negócios, levando a isso. soluções técnicas não podem ser implementadas em sistemas com altos requisitos de simultaneidade, alto desempenho e alta confiabilidade. Muitas empresas só podem ativar esses recursos de rastreamento em sistemas de teste ou sistemas de produção não importantes, enquanto os sistemas de produção mais importantes só podem usar amostragem e rastreamento de alta proporção para reduzir o impacto negativo nos negócios, em particular, nos principais sistemas de produção no setor financeiro. a indústria abrirá mão completamente das capacidades de rastreamento para garantir que o desempenho dos negócios não seja afetado, mas isso leva a fracas capacidades de suporte operacional e a riscos de operação e manutenção fora de controle.

DeepFlow usa a tecnologia eBPF para obter observabilidade de intrusão zero (código zero), que resolve muito bem esses problemas. O atraso de negócios (tempo de resposta) geralmente tem um impacto de nível inferior a um milissegundo e o consumo de recursos do agente é previsível e configurável. Graças à tecnologia Just-in-Time (JIT), a eficiência de execução do código eBPF do DeepFlow Agent pode ser comparável ao desempenho do código nativo do kernel e não afetará o processo de processamento do aplicativo durante o processo de coleta, para que o aplicativo possa chame o processo de processamento de intrusão zero.

Na prática de observação full-stack do TiDB do DeepFlow, testamos e verificamos os diferentes desempenhos do desempenho de negócios do cluster TiDB ao usar a instrumentação Jaeger e usar a tecnologia de intrusão zero eBPF do DeepFlow para prática de observabilidade.

Figura 6 – Comparação de desempenho SQL entre a coleção de instrumentação Jaeger e a coleção DeepFlow eBPF

Atraso de resposta SQL do TiDB durante a coleta de instrumentação Jaeger : ativamos a função OpenTracing do TiDB e observamos o desempenho da resposta do local da instância do aplicativo (ordem svc) acessando o tiproxy. Podemos ver que o atraso médio da resposta SQL é estável em 300 ~ 400 ms . alguns casos, o atraso máximo médio excede 1,5s .

Figura 7 - (Coleção de instrumentação Jaeger) Indicadores de desempenho SQL de svc-order -> tidb-proxy

Atraso de resposta SQL do TiDB durante a coleta do DeepFlow eBPF : usamos o DeepFlow Agent para coletar dados de observação sem amostragem no cluster distribuído do TiDB e observar o desempenho da resposta do local da instância do aplicativo (ordem svc) ao acessar o tiproxy. o atraso médio é reduzido para 3 ~ 5 ms e o atraso máximo não excede 38 ms .

Figura 8 - (coleção eBPF) Indicadores de desempenho SQL de svc-order -> tidb-proxy

A partir dos dados de comparação de desempenho acima, descobrimos que a observabilidade de intrusão zero alcançada pelo DeepFlow por meio da tecnologia eBPF resolve os problemas de desempenho de negócios causados ​​pela solução de instrumentação, para que possa construir uma solução pronta para produção e sem complicações para o TiDB distribuído. banco de dados do principal sistema de produção de TI Capacidades de observação de amostragem e rastreamento.

3) Rastreamento da cadeia de chamadas com carregamento a quente a qualquer momento

Devido às perdas de desempenho de negócios causadas por meios técnicos, como instrumentação no aplicativo e aprimoramento de bytecode do Agente Java, sistemas de produção importantes basicamente desligarão os recursos de rastreamento nas operações diárias. No entanto, ao encontrar falhas ou exceções, o rastreamento refinado é necessário. , mas descobriu que o processo de inicialização da instrumentação e do Agente Java requer a reinicialização das instâncias do aplicativo e das instâncias do componente TiDB do sistema de produção principal. Neste momento, torna-se uma decisão difícil e dolorosa ativar a função de rastreamento, o que acaba levando a isso. status quo de operação e manutenção:

  • Pequenas falhas passam despercebidas , deixando o sistema funcionando com perigos ocultos.
  • Um grande investimento é feito para falhas intermediárias , o ambiente de teste é testado repetidamente e a causa raiz é determinada pela sorte.
  • Todos os esforços foram feitos para extinguir falhas graves , e toda a equipe trabalhou 24 horas por dia, 7 dias por semana, independentemente do custo, até que o negócio fosse restabelecido.

A Lei de Hayne diz-nos que por trás de qualquer acidente grave, existem 29 acidentes menores e 300 perigos potenciais ocultos. O mesmo padrão existe na operação e manutenção de sistemas de TI. É precisamente por causa das ações de reinicialização necessárias para a inicialização da instrumentação e do Agente Java que um grande número de possíveis perigos ocultos e pequenas falhas no ambiente de produção são difíceis de diagnosticar e localizar. A realocação de falhas intermediárias consome muita mão de obra. falhas graves continuam a ocorrer.

A observabilidade de intrusão zero do DeepFlow resolve perfeitamente esse problema. Quando precisar ativar o recurso de rastreamento de cadeia de chamadas para um sistema de aplicativo ou TiDB, você pode implantar o DeepFlow Agent a qualquer momento com um clique para iniciar o rastreamento da coleta de dados. Ao implantar o Agente, você não precisa invadir o POD e o TiDB do aplicativo. componente POD, nem você precisa reiniciar o aplicativo, TiDB ou sistema operacional. O agente pode carregar instantaneamente no kernel do sistema operacional e começar a rastrear a coleta de dados em cada local apenas por meio da tecnologia eBPF do. Sistema operacional Linux. Mesmo para sistemas de negócios com carga muito alta, quando você deseja desinstalar o recurso de rastreamento, você pode desligar o switch de coleta eBPF do Agente on-line ou desinstalar o Agente, e o código de coleta de dados de rastreamento pode ser desinstalado instantaneamente do kernel do sistema operacional . Durante todo esse processo, o aplicativo da camada superior e o programa do componente TiDB não têm conhecimento.

O recurso de rastreamento da cadeia de chamadas do DeepFlow Agent pode ser carregado a qualquer momento no kernel do sistema operacional, permitindo-nos rastrear e observar recursos on-line e off-line a qualquer momento no sistema de aplicativos e no cluster TiDB, sem nos preocupar com perturbações no aplicativo, e para detectar falhas menores e falhas intermediárias a qualquer momento. Realize observações refinadas para descobrir e eliminar rapidamente os perigos do sistema e evitar falhas graves.

Figura 9 – Implantação de intrusão zero do DeepFlow Agent

4) Rastreamento da cadeia de chamadas para colaboração unificada entre pilhas de tecnologia

O rastreamento APM da tecnologia de instrumentação tradicional é adequado para desenvolvedores de aplicativos e desenvolvedores de TiDB. A cadeia de chamadas reflete mais sobre o relacionamento de chamada de função dentro do processo, que é difícil de entender sem um histórico de desenvolvimento, portanto, durante o processo de delimitação de falhas, DBA e outros. as operações devem As funções dimensionais são de pouca ajuda prática. A plataforma de observabilidade DeepFlow realiza a capacidade de rastreamento full-stack de qualquer chamada de aplicativo do aplicativo para o sistema operacional e a rede subjacente, para que possa construir operação e manutenção de TiDB, desenvolvimento de TiDB, desenvolvimento de aplicativos, operação e manutenção de K8s e operação de middleware e manutenção. Com os recursos de colaboração de operação e manutenção de pilha completa de cada pilha de tecnologia, podemos obter insights claros sobre o desempenho de cada link de processamento em todo o processo de qualquer chamada de aplicativo e determinar rapidamente o limite da falha.

Figura 10 – Colaboração unificada e observação unificada de múltiplas pilhas de tecnologia de operação e manutenção

Tomemos a figura acima como exemplo, na plataforma observável DeepFlow:

  • Desenvolvimento, operação e manutenção de aplicativos de negócios : diagnostique e descubra rapidamente perigos ou falhas ocultos em aplicativos de negócios por meio do atraso de chamada de microsserviços de aplicativos de negócios;
  • Operação e manutenção do K8s : através do atraso de chamada da placa de rede entre cada instância de microsserviço para descobrir perigos ou falhas ocultas na plataforma K8s;
  • Operação e manutenção de middleware : Diagnostique e descubra rapidamente perigos ou falhas ocultas no middleware por meio do atraso de chamada do local TiDB-Proxy;
  • DBA : Use o atraso de chamada do TiDB coletado pelo eBPF para diagnosticar rapidamente perigos ou falhas ocultas no lado do TiDB;
  • Desenvolvimento de banco de dados : depois de ativar os dados de instrumentação OpenTelemetry do TiDB sob demanda, os desenvolvedores de banco de dados podem diagnosticar rapidamente perigos ocultos ou falhas nas principais funções internas do TiDB.

04: Observação geral

Além do rastreamento da cadeia de chamadas, durante a operação e manutenção diária do TiDB, o panorama de negócios, o desempenho da rede, o desempenho dos recursos do sistema, o desempenho de leitura e gravação de arquivos do sistema operacional e o desempenho da função do aplicativo são dimensões que precisam ser exaustivamente observadas e analisadas para encontrar rapidamente o problema A causa raiz é que a prática de observabilidade deve abrir os silos de vários tipos de dados de observação, estabelecer conexões entre os dados de observação e projetar um fluxo de operação de observação suave, para que o pessoal de operação e manutenção de pilha completa possa de forma eficiente e eficiente. execute suavemente o processo de operação e manutenção de observação Observe os dados completos e encontre conclusões nos dados de forma mais rápida e fácil.

Na prática de observabilidade do TiDB, implementamos a coleta e análise unificadas de vários tipos de dados na plataforma DeepFlow e, por meio de fluxos de operação suaves, podemos acessar com eficiência vários tipos de dados e obter uma gama completa de capacidades de observação, incluindo:

  1. Observação panorâmica de negócios
  2. Observação de desempenho de rede
  3. Rastreamento de instrução SQL
  4. Observação de desempenho de recursos do sistema
  5. Observação de desempenho de leitura e gravação de arquivos
  6. Observação de desempenho de função (perfil de CPU)

1) Observação panorâmica de negócios

O DeepFlow obtém dinamicamente tags de recursos e tags de negócios por meio de acoplamento em tempo real com interfaces API nativas da nuvem e chama tags de tags de dados para aplicativos coletados em tempo real, realizando assim a capacidade de construir um panorama de negócios que é automatizado e atualizado dinamicamente com o negócio .

Na prática de observabilidade TiDB baseada em DeepFlow, construímos um panorama de negócios ponta a ponta, desde clusters de aplicativos nativos da nuvem até clusters de bancos de dados distribuídos TiDB (conforme mostrado abaixo):

Figura 11 – Panorama Empresarial

Ao construir uma topologia panorâmica de negócios de clusters de aplicativos nativos da nuvem e clusters de banco de dados TiDB, podemos observar o quadro geral do sistema de negócios de TI de uma perspectiva macro. Quando anormalidades de desempenho de negócios locais são encontradas no panorama de negócios, podemos explorar gradualmente microscopicamente e. encontre rapidamente desconhecidos desconhecidos.

2) Observação do desempenho da rede

Perda de pacotes de rede e atraso de rede são frequentemente suspeitos de problemas no processo de diagnóstico de falhas de cluster de banco de dados TiDB. O DeepFlow pode determinar rapidamente se uma determinada falha de negócios de banco de dados distribuído é causada por uma falha de rede por meio da observação do desempenho da rede.

Na observação do desempenho da rede, podemos observar o desempenho da interação da rede do acesso externo ao cluster TiDB e do acesso mútuo dos componentes internos do cluster TiDB por meio dos seis indicadores a seguir, e diagnosticar e determinar diferentes tipos de problemas de transmissão de rede:

  • Bytes (taxa de rendimento) - observe a pressão de rendimento da rede
  • Taxa de retransmissão TCP - observe a perda de pacotes de rede
  • Proporção de janela zero TCP - observando congestionamento TCP
  • Proporção de falha no estabelecimento de conexão – observe anomalias no estabelecimento de conexão TCP
  • Atraso médio no estabelecimento da conexão TCP - RTT da rede observada
  • Latência média do sistema TCP/ICMP - observe a velocidade de resposta do sistema operacional

Exemplo 1: Observe rapidamente o desempenho de interação de rede do cliente acessando o portal TiDB

Figura 12 - svc-user -> observação do indicador de desempenho da rede tidb-proxy

Exemplo 2: Observe rapidamente o desempenho da interação de rede entre os componentes internos do TiDB

Figura 13 – Observação dos indicadores de desempenho da rede tidb -> pd

3) Rastreamento de instrução SQL

Instruções SQL irracionais ocuparão uma grande quantidade de recursos de CPU e memória, aumentarão o atraso de resposta do TiDB e reduzirão o desempenho geral do TiDB. Portanto, retroceder rapidamente instruções SQL ineficientes é uma parte importante da operação e manutenção do banco de dados. Consultas que não usam índices, varreduras completas de tabelas, consultas excessivamente complexas e o uso de funções ou tipos de dados inadequados são todos tipos de "SQL incorreto" que exigem retrocesso e foco em instruções SQL.

Na prática de observabilidade do TiDB, o DeepFlow usa recursos de coleta de desvio de intrusão para registrar completamente os detalhes de cada instrução SQL, incluindo instruções SQL, atrasos de resposta, tempos de ocorrência, nós de origem, etc., que podem ser recuperados durante a recuperação do log de chamadas e. rastreie a frequência de ocorrência de SQL incorreto em tempo real e determine a origem do SQL.

Figura 14 – Rastreamento do log de chamadas SQL

4) Observação do desempenho dos recursos do sistema

A utilização excessiva da CPU e da memória do sistema operacional ou o congestionamento da taxa de transferência da interface de rede durante o mesmo período podem levar à ocorrência de SQL lento. Portanto, para encontrar a causa raiz dos problemas de SQL lento com mais rapidez e precisão, analise rapidamente o TiDB. componentes durante o processo de diagnóstico de falhas Os indicadores de CPU, memória e interface de rede de uma instância são uma parte fundamental para melhorar os recursos de observação, recursos de operação e manutenção e eficiência de solução de problemas de bancos de dados distribuídos.

Na prática da observabilidade do TiDB, coletamos indicadores do sistema por meio do Agente Grafana e importamos uniformemente os dados para a plataforma de observabilidade DeepFlow. Os dados são marcados, correlacionados e apresentados uniformemente para obter a capacidade de observar os dados do indicador POD do componente TiDB. descobrindo o POD de origem do SQL lento no rastreamento da cadeia de chamadas, você pode visualizar a curva de mudança de uso da CPU, a curva de mudança de uso de memória e a curva de mudança de taxa de transferência de rede do POD com um clique e determinar facilmente o evento SQL lento por meio dos valores do indicador ​​durante o período do problema. Correlação com CPU do sistema, memória e desempenho de recursos da interface de rede.

Figura 15 - Observação de desempenho de recursos do sistema de instância de banco de dados TiDB

5) Observação do desempenho de leitura e gravação de arquivos

O desempenho de leitura e gravação de arquivos terá um impacto significativo no desempenho de resposta SQL do TiDB. Embora o uso de recursos de armazenamento de alto desempenho possa evitar ao máximo a possibilidade de leitura e gravação lenta de arquivos, duas perguntas ainda precisam ser respondidas com frequência durante. Operação e manutenção do TiDB:

  • Quando ocorre SQL lento esporádico, como determinar se a leitura e gravação lenta esporádica de arquivos é a causa raiz do problema?
  • Quando ocorre alguma leitura ou gravação desconhecida de arquivos grandes ou leituras e gravações frequentes de arquivos no sistema, como descobrir o processo de origem da leitura e gravação de arquivos?

DeepFlow realiza coleta e observação completas de eventos de leitura e gravação de arquivos do sistema operacional por meio do recurso eBPF do kernel Linux e oferece suporte a vários modos de coleta, como coleta completa e coleta parcial.

Figura 16 - Diagrama esquemático do princípio de coleta do eBPF de eventos de IO do sistema operacional

Quando um aplicativo apresenta resposta lenta, o DeepFlow pode recuperar todos os eventos de leitura e gravação de arquivos no cliente e no servidor durante o período do problema com um clique e bloquear rapidamente eventos de operação de arquivo e processos de origem na lista. Quando ocorre uma resposta SQL lenta, o DBA pode determinar em segundos se há um evento de IO lento associado quando há comportamento desconhecido de leitura e gravação de arquivo, a operação e manutenção do sistema podem bloquear a fonte de IO do arquivo em segundos:

Figura 17 – Recuperação de eventos de IO de arquivo

6) Observação de desempenho de função (perfil de CPU)

Durante o processo de solução de problemas de SQL lento, quando se descobre que a CPU se tornou o gargalo do desempenho do negócio, a próxima coisa a fazer é analisar a situação de agendamento da CPU do componente TiDB POD, descobrir as funções quentes no componente TiDB programa e, em seguida, encontre o programa O ponto de entrada para otimização. DeepFlow implementa a coleta de dados de desempenho da CPU e os recursos de observação do processo de aplicação por meio da tecnologia eBPF do kernel Linux. Ao analisar o desempenho da CPU do processo de aplicação do componente TiDB, os desenvolvedores podem bloquear facilmente as funções do kernel, funções de biblioteca e funções de aplicação. cada programa de componente TiDB.

Na prática de observabilidade do TiDB, usamos DeepFlow para analisar o desempenho da CPU dos componentes TiDB, PD e TiKV. Entre eles, no seguinte gráfico de chama de análise de desempenho da CPU do processo TiDB, podemos observar claramente que a instrumentação Jaeger traz uma sobrecarga significativa de recursos da CPU para o processo TiDB :

Figura 18 - Resultados da análise de desempenho da CPU do processo TiDB

05: Resumo do valor

Boas capacidades de suporte de operação e manutenção são um pré-requisito para a operação estável do banco de dados distribuído TiDB. Nesta prática de observabilidade, o DeepFlow usa tecnologia líder de coleta de dados de intrusão zero eBPF de alto desempenho, tecnologia de rastreamento de cadeia de chamadas com instrumentação zero e multi-fonte. a tecnologia de observação unificada de dados cria uma solução de observabilidade para pilha completa, link completo, carregamento a quente a qualquer momento e implementação de produção do TiDB, o que melhora significativamente as capacidades gerais de operação e manutenção do TiDB, auxilia com eficiência a operação estável do banco de dados TiDB e ajuda os usuários a criar um serviço de banco de dados mais confiável e estável.

06: O que é DeepFlow

DeepFlow é um produto de observabilidade desenvolvido pela Yunshan Network, com o objetivo de fornecer observabilidade profunda para infraestruturas de nuvem complexas e aplicativos nativos de nuvem. Com base no eBPF, o DeepFlow realiza a coleta de sinais de observação de intrusão zero (código zero), como indicadores de desempenho de aplicativos, rastreamento distribuído e análise contínua de desempenho, e combina-a com a tecnologia de rótulo inteligente (SmartEncoding) para realizar a correlação Full Stack e integração de todos os sinais de observação. Usando o DeepFlow, os aplicativos nativos da nuvem podem ter observabilidade profunda automaticamente, eliminando assim a pesada carga de instrumentação contínua sobre os desenvolvedores e fornecendo às equipes de DevOps/SRE recursos de monitoramento e diagnóstico do código à infraestrutura.

Endereço GitHub: https://github.com/deepflowio/deepflow

Visite o DeepFlow Demo para experimentar zero instrumentação, cobertura completa e observabilidade totalmente relevante.

Decidi desistir do software industrial de código aberto . Grandes eventos - OGG 1.0 foi lançado, a Huawei contribuiu com todo o código-fonte do Ubuntu 24.04 LTS foi oficialmente demitido . ". O Fedora Linux 40 foi lançado oficialmente. Uma conhecida empresa de jogos lançou novos regulamentos: os presentes de casamento dos funcionários não devem exceder 100.000 yuans. A China Unicom lança a primeira versão chinesa Llama3 8B do mundo do modelo de código aberto. Pinduoduo é condenado a compensar 5 milhões de yuans por concorrência desleal Método de entrada na nuvem doméstica - apenas a Huawei não tem problemas de segurança de upload de dados na nuvem.
{{o.nome}}
{{m.nome}}

Acho que você gosta

Origin my.oschina.net/u/3681970/blog/11062627
Recomendado
Clasificación