View a markdown version of this page

Conceitos-chave do DevOps Guru for RDS - DevOps Guru da Amazon

Aviso de fim do suporte: em 30 de setembro de 2027, o suporte para o Amazon DevOps Guru AWS será encerrado. Depois de 30 de setembro de 2027, você não poderá mais acessar o console do Amazon DevOps Guru ou os recursos do Amazon DevOps Guru. Para obter mais informações, consulte Fim do suporte do Amazon DevOps Guru.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Conceitos-chave do DevOps Guru for RDS

Um insight é gerado pelo DevOps Guru quando ele detecta um comportamento anômalo ou problemático em seus aplicativos operacionais. Um insight contém anomalias em um ou mais recursos. Uma anomalia representa uma ou mais métricas relacionadas detectadas pelo DevOps Guru que são inesperadas ou incomuns.

Um insight tem gravidade alta, média ou baixa. A gravidade do insight é determinada pela anomalia mais grave que contribuiu para criar o insight. Por exemplo, se o insight AWS-ECS _ MemoryUtilization _and_others incluir uma anomalia com baixa severidade e outra com alta severidade, a severidade geral do insight será alta.

Se as instâncias de banco de dados do Amazon RDS tiverem o Performance Insights ativado, o DevOps Guru for RDS fornecerá análises e recomendações detalhadas sobre as anomalias dessas instâncias. Para identificar uma anomalia, o DevOps Guru for RDS desenvolve uma linha de base para valores de métricas de banco de dados. DevOpsEm seguida, o Guru for RDS compara os valores métricos atuais com a linha de base histórica.

Insights proativos

Um insight proativo informa você sobre um comportamento problemático antes que ele ocorra. Ele contém anomalias com recomendações e indicadores relacionados para ajudar você a resolver os problemas antes que se tornem maiores.

Cada página proativa de insights fornece detalhes sobre uma anomalia.

Insights reativos

Um insight reativo identifica um comportamento anômalo quando ele ocorre. Contém anomalias com recomendações, métricas relacionadas e eventos para ajudar você a entender e resolver os problemas agora.

Anomalias causais

Uma anomalia causal é uma anomalia de nível superior dentro de um insight reativo. Ela é mostrada como a métrica primária na página de detalhes da anomalia no console do DevOps Guru. A carga do banco de dados (carga do banco de dados) é a anomalia causal do DevOps Guru for RDS. Por exemplo, o insight AWS-ECS _ MemoryUtilization _and_others pode ter várias anomalias métricas, uma das quais é a carga do banco de dados (carga de banco de dados) para o recurso. AWS/RDS

Em um insight, a carga anormal do banco de dados pode ocorrer em várias instâncias de banco de dados do Amazon RDS. A gravidade da anomalia pode ser diferente para cada instância de banco de dados. Por exemplo, a gravidade de uma instância de banco de dados pode ser alta, enquanto a gravidade das outras é baixa. O console usa como padrão a anomalia com a maior gravidade.

Anomalias contextuais

Uma anomalia contextual é uma descoberta em Carga do banco de dados (carga do BD) que é relatada a um insight reativo. Ela é exibida na seção Métricas relacionadas da página de detalhes da anomalia no console do DevOps Guru. Cada anomalia contextual descreve um problema de performance específico do Amazon RDS que requer investigação. Por exemplo, uma anomalia causal pode incluir as seguintes anomalias contextuais:

  • Capacidade da CPU excedida: a fila de execução da CPU ou a utilização da CPU estão acima do normal.

  • Memória baixa do banco de dados: os processos não têm memória suficiente.

  • Conexões de banco de dados aumentaram: o número de conexões de banco de dados está acima do normal.

Recomendações

Cada insight tem pelo menos uma ação sugerida. Os exemplos a seguir são recomendações geradas pelo DevOps Guru for RDS:

  • Ajuste os SQL IDs list_of_IDs para reduzir o uso da CPU ou atualize o tipo de instância para aumentar a capacidade da CPU.

  • Analise o pico associado às conexões atuais do banco de dados. Considere ajustar as configurações do pool de aplicativos para evitar a alocação dinâmica frequente de novas conexões de banco de dados.

  • Procure instruções SQL que executem operações de memória excessivas, como classificação na memória ou junções grandes.

  • Investigue o I/O uso intenso dos seguintes IDs SQL:list_of_IDs.

  • Verifique as instruções que criam grandes quantidades de dados temporários, por exemplo, aquelas que realizam grandes classificações ou usam grandes tabelas temporárias.

  • Verifique os aplicativos para ver o que está causando o aumento na carga de trabalho do banco de dados.

  • Considere a hablitação do esquema de performance do MySQL

  • Verifique se há transações de longa duração e finalize-as com uma confirmação ou reversão.

  • Configure o parâmetro idle_in_transaction_session_timeout para encerrar qualquer sessão que estivesse no estado 'inativo na transação' por mais tempo do que o tempo especificado.