Conceitos-chave do DevOps Guru for RDS

Um insight é gerado pelo DevOps Guru quando ele detecta comportamentos anômalos ou problemáticos 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 _e_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 detalhadas e recomendações sobre as anomalias dessas instâncias. Para identificar uma anomalia, o DevOps Guru for RDS desenvolve uma linha de base para os valores métricos do 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 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 do 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 para RDS:

• Ajuste as IDs SQL List_of_IDs para reduzir o uso da CPU ou atualizar 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 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.