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 DevOps do Guru for RDS
Uma visão é gerada pelo DevOps Guru quando ele detecta um comportamento anômalo ou problemático em seus aplicativos operacionais. Uma visão contém anomalias de 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 uma severidade de alta, média ou baixa. A gravidade do insight é determinada pela anomalia mais grave que contribuiu para a criação do 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 é 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 métricos do banco de dados. DevOpsO Guru for RDS então 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 métricas relacionadas para ajudá-lo a resolver os problemas antes que eles se tornem problemas maiores.
Cada página de insights proativos fornece detalhes sobre uma anomalia.
Insights reativos
Um insight reativo identifica um comportamento anômalo quando ele ocorre. Ele 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 métrica primária na página de detalhes da anomalia no console do DevOps Guru. Carga do banco de dados é a anomalia causal do DevOps Guru para 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.
Dentro de um insight, a anomalia da carga do banco de dados (carga de banco de dados) pode ocorrer em várias instâncias de banco de dados 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 severidade das outras é baixa. O console usa como padrão a anomalia com a maior severidade.
Anomalias contextuais
Uma anomalia contextual é uma descoberta em Carga do banco de dados (carga do BC) 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 do banco de dados baixa — Os processos não têm memória suficiente.
-
Conexões de banco de dados aumentadas — O número de conexões de banco de dados está acima do normal.
Recomendações
Cada visão tem pelo menos uma ação sugerida. Os exemplos a seguir são recomendações geradas pelo DevOps Guru para RDS:
-
Ajuste a
lista de IDs
SQL 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 uso intenso de E/S dos seguintes IDs SQL:
List_of_IDs
. -
Verifique se há declarações que criam grandes quantidades de dados temporários, por exemplo, aquelas que realizam classificações grandes 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 habilitar o esquema de desempenho 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 esteja no estado “inativa na transação” por mais tempo do que o tempo especificado.