View a markdown version of this page

Monitoramento de clusters do Aurora DSQL com o Aurora DSQL Database Insights - Amazon Aurora DSQL

Monitoramento de clusters do Aurora DSQL com o Aurora DSQL Database Insights

Os insights de banco de dados do Aurora DSQL fornece acesso a dados amostrados por segundo de cada sessão ativa do cluster, coletados pelo amostrador DSQL Active Session History (DASH), que registra o estado de espera e a instrução SQL normalizada que cada sessão está executando. Os resultados agregados por minuto do DASH são publicados como métricas do CloudWatch OpenTelemetry (OTel). Use esses dados para entender a carga do banco de dados, encontrar as consultas que consomem mais recursos e diagnosticar problemas de desempenho.

Você não precisa configurar o DASH. Ele é habilitado automaticamente para todos os clusters do Aurora DSQL, e os dados agregados por minuto estão disponíveis pelo Amazon CloudWatch Database Insights e por meio de consultas à Prometheus Query Language (PromQL) executadas nas métricas do CloudWatch OTel, sem custo adicional.

O que é o DASH?

Uma sessão ativa representa uma única conexão com o cluster que possui uma transação aberta. A qualquer momento, cada sessão ativa está em um de três estados:

  • Uso da CPU

  • Aguardando a conclusão de uma operação externa, como uma leitura do armazenamento ou uma confirmação de confirmação

  • Ociosa na transação, aguardando a próxima instrução da aplicação em uma transação aberta

O DASH acompanha somente as sessões que possuem uma transação aberta. O DASH captura essa atividade fazendo uma amostragem de todas as sessões ativas do cluster uma vez por segundo. Cada amostra registra duas informações:

  • O evento de espera: o estado em que a sessão estava no momento da amostragem. Consulte a lista completa em Eventos de espera do DASH.

  • A instrução SQL: os primeiros 256 caracteres do SQL que a sessão estava executando, o que é suficiente para identificar a maioria das consultas.

O DASH agrega essas amostras por segundo e as publica no CloudWatch uma vez por minuto, discriminadas por evento de espera e por instrução SQL. O resultado é uma única métrica de série temporal, db.active_sessions.avg, que registra o número médio de sessões ativas durante cada período de amostragem. Esse valor também é conhecido como Média de sessões ativas (AAS).

O AAS é o sinal fundamental para a análise de desempenho do Aurora DSQL. A divisão por evento de espera mostra em que suas sessões passam o tempo, e não apenas o quanto o cluster está ocupado. A divisão por SQL atribui a carga a consultas individuais.

dica

O Aurora DSQL escala a CPU de forma elástica, portanto o sinal de diagnóstico mais útil é a forma do perfil de espera, ou seja, a distribuição proporcional do tempo das sessões entre os eventos de espera, e não o AAS em relação a um limite fixo de vCPUs. Compare essa distribuição com a referência observada durante a operação normal. Uma alteração nessas proporções indica uma mudança na workload ou no comportamento do sistema.

Métricas e eventos de espera do DASH

O DASH expõe uma única métrica cujas dimensões permitem segmentar a carga do banco de dados por evento de espera e por instrução SQL. A tabela a seguir descreve a métrica do DASH.

Métrica Unidade Descrição
db.active_sessions.avg Count The average number of active sessions on the cluster over the sample period (AAS). Each active session is either running on CPU or in a named wait state.

A métrica apresenta as seguintes dimensões (rótulos), que você usa para agrupar e filtrar os dados.

Dimensão Descrição
db.wait.class The broader classification of wait events to identify the general type of resource contributing to the database load. For example, class:oncpu means the statement is actively running on the CPU, and class:io means that the statement is waiting for an input/output operation to complete.
db.wait.event The wait state the sampled sessions were in. See Eventos de espera do DASH for the full list of values.
db.session.state The session state – active (executing a statement) or ociosa na transação (waiting for the next command from the application while the transaction remains open).
db.query.id The fingerprint of the normalized SQL text of the statement the sessions were running.
db.query.normalized_text The normalized SQL text of the statement the sessions were running. DASH removes literal values so that it groups statements that differ only in their parameters.
aws.auroradsql.session.role.arn The IAM role ARN assumed to connect to the Aurora DSQL cluster.
application.name The application name that you set in connection parameters. You can override it at connect time. DASH includes this dimension only when you explicitly set it.

Eventos de espera do DASH

As sessões do Aurora DSQL podem apresentar os seguintes eventos de espera. Os eventos de espera relacionados ao armazenamento, SequentialScanRead, ScatteredBatchRead, SingleRead, UniqueConstraintCheck e FkExistenceCheck, representam a comunicação entre a camada de processamento de consultas e a camada de armazenamento, e Commit representa a comunicação com o serviço de confirmação. Essa lista pode aumentar com o tempo à medida que o Aurora DSQL identifica novos eventos de espera.

Eventos de espera Classe de espera Descrição
OnCpu class:oncpu The session isn't waiting for external input and is actively executing on CPU – parsing, planning, evaluating expressions, or processing results.
ClientRead class:client The session is idle within an open transaction, waiting for the application to send the next SQL statement or a commit/rollback command. Frequent or long ClientRead waits often indicate excessive application round-trips or transactions that you hold open longer than necessary.
ClientWrite class:client The database sends results to the application over the network. High ClientWrite can indicate large result sets or network latency between the application and the database.
SequentialScanRead class:io The session is reading a contiguous range of keys from storage. This isn't necessarily a full table scan – it might cover a relatively small range of contiguous keys.
ScatteredBatchRead class:io The session is performing batched reads from storage, retrieving multiple non-contiguous keys in a single call to storage.
SingleRead class:io The session is reading a single tuple (point lookup) from storage. ScatteredBatchRead with a batch size of 1 largely replaces this event, which is uncommon in current Aurora DSQL versions.
UniqueConstraintCheck class:io The session is validating unique key constraints, which requires storage reads to check for duplicates. This applies to both unique constraints on non-primary-key columns and primary key constraints during the insertion of new rows.
FkExistenceCheck class:io The session is validating that a referenced foreign key row exists, which requires reads to confirm the relationship.
StartTransaction class:io The session is preparing for the distributed transaction to begin.
Confirmar class:io The session has initiated a commit and is waiting for acknowledgment from the commit service. The response is either a success or an abort (serialization error); a Confirmar wait precedes both outcomes.
PgSleep class:timeout The session is sleeping because the application explicitly called pg_sleep(). This is an application-initiated wait, not a database-imposed one.

Acessar dados do DASH

É possível acessar os dados do DASH de três maneiras:

  • Amazon CloudWatch Database Insights: uma interface de usuário (UI) selecionada, no-code, para explorar a carga do banco de dados e as principais instruções SQL. Esse é o ponto de partida para a maioria das investigações.

  • PromQL: consulte a métrica db.active_sessions.avg subjacente de forma programática para integração com ferramentas de monitoramento de terceiros ou para exploração interativa.

  • Skill de diagnóstico do sistema do Aurora DSQL baseada em IA: um agente de verificação de integridade baseado em inteligência artificial (IA) que analisa automaticamente os dados do DASH, compara a distribuição dos eventos de espera entre períodos e gera relatórios de diagnóstico.

Todos esses métodos de acesso leem do mesmo conjunto de dados do DASH.

Usar o CloudWatch Database Insights

O Amazon CloudWatch Database Insights apresenta os dados do DASH por meio de um painel selecionado específico do Aurora DSQL. Seus clusters do Aurora DSQL aparecem automaticamente no Database Insights. Você não precisa fazer nenhuma configuração além de criar o cluster e executar transações nele.

Como visualizar os dados do DASH no Database Insights

  1. Abra o console do CloudWatch e selecione Database Insights no painel de navegação à esquerda.

  2. Na visualização Integridade da frota, localize o cluster do Aurora DSQL na lista de Recursos do banco de dados. Como alternativa, você pode navegar diretamente até a página Instância de banco de dados e selecionar seu cluster no painel à esquerda.

  3. Selecione o Identificador de banco de dados para abrir o Painel de instância de banco de dados.

  4. Use o gráfico Carga de banco de dados para visualizar a média de sessões ativas ao longo do tempo. O gráfico é uma visualização empilhada na qual cada faixa representa um evento de espera; portanto, a altura total mostra o nível de atividade do cluster e as faixas mostram em que as sessões estão passando o tempo.

  5. Use o controle Dividir por no gráfico Carga de banco de dados para alternar entre Eventos de espera e Texto SQL.

  6. A seção Análise de carga de banco de dados mostra a média de sessões ativas por Principais eventos de espera e o SQL principal, classificado de acordo com sua contribuição para a média de sessões ativas.

  7. Use o seletor de intervalo de tempo na parte superior da página para se concentrar em uma janela de monitoramento específica, como o período em que ocorreu uma redução de desempenho relatada.

Usar o PromQL

O DASH expõe os dados como a métrica db.active_sessions.avg do CloudWatch, que você pode consultar com PromQL no CloudWatch Query Studio.

Os exemplos a seguir funcionam no Query Studio, no qual o espaço de trabalho ativo já limita os resultados à sua conta e região, e o seletor de tempo define a janela de avaliação. Como o nome da métrica contém pontos, os exemplos usam a forma de seletor de nome entre aspas do PromQL, {"db.active_sessions.avg"}.

nota

Todos os exemplos incluem um filtro de rótulo @resource.aws.auroradsql.cluster_id para limitar os resultados a um único cluster. Substitua cluster-id pelo identificador do cluster. Se você tiver apenas um cluster, poderá omitir esse filtro ou usar os filtros da UI do Query Studio. Para descobrir todos os rótulos disponíveis para a métrica no ambiente, execute {"db.active_sessions.avg"} como uma consulta de série e inspecione o conjunto de rótulos em cada série retornada.

Carga do banco de dados por evento de espera

Retorna o número médio de sessões ativas agrupado por evento de espera, a mesma visualização de AAS por evento de espera disponível no gráfico Carga de banco de dados do Database Insights, mas acessível de forma programática.

avg by ("db.wait.event") ( { "db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="cluster-id" } )

O resultado apresenta uma série para cada valor distinto de db.wait.event, cada uma contendo a contribuição média para a média de sessões ativas desse estado de espera.

SQL principal por média de sessões ativas

Classifica as instruções SQL de acordo com sua contribuição média para a carga do banco de dados. Este é o equivalente em PromQL da visualização SQL principal do Database Insights.

topk(5, avg by ("db.query.normalized_text") ( { "db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="cluster-id" } ) )

Para ver as combinações do SQL principal e dos eventos de espera de acordo com sua contribuição para a carga, adicione db.wait.event à cláusula de agrupamento. Como essa classificação considera todas as combinações juntas, os resultados podem incluir vários eventos de espera para a mesma instrução com alta contribuição:

topk(5, avg by ("db.query.normalized_text", "db.wait.event") ( { "db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="cluster-id" } ) )
Instruções SQL que realizam o maior número de leituras do armazenamento

Retorna as cinco principais instruções SQL que passam mais tempo em operações de leitura do armazenamento, filtrando pelos eventos de espera de leitura do armazenamento.

topk(5, sum by ("db.query.normalized_text") ( { "db.active_sessions.avg", "db.wait.event"=~"S.*Read|.*Check", "@resource.aws.auroradsql.cluster_id"="cluster-id" } ) )

A expressão regular S.*Read corresponde aos eventos de leitura do armazenamento cujos nomes começam com S e terminam com Read (SequentialScanRead, ScatteredBatchRead, SingleRead). O padrão inclui .*Check explicitamente porque os eventos de espera UniqueConstraintCheck e FkExistenceCheck não correspondem ao primeiro padrão, mas também são eventos de espera de leitura do armazenamento.

Usar a skill de diagnóstico do sistema do Aurora DSQL

A skill de diagnóstico do sistema do Aurora DSQL automatiza a análise de verificação de integridade do cluster do Aurora DSQL lendo dados do DASH, comparando a distribuição dos eventos de espera entre períodos e gerando um relatório de diagnóstico. A skill faz parte do plugin databases-on-aws no Agent Plugins for AWS, no repositório awslabs/agent-plugins, e funciona com qualquer agente de codificação de IA compatível.

Para analisar a integridade do cluster, emita um prompt como:

“Verifique o desempenho do meu cluster do Aurora DSQL cluster-id em us-east-1 e escreva um relatório em Markdown.”

A skill usa o servidor do protocolo de contexto para modelos (MCP) do CloudWatch para analisar a métrica db.active_sessions.avg em uma seleção de períodos e retorna um relatório em Markdown. Você pode definir a janela de comparação de desempenho no prompt:

“Verifique o desempenho das últimas quatro horas e compare com a última segunda-feira.”

Quando consultas específicas parecem apresentar problemas, a skill inicia um fluxo de trabalho de diagnóstico mais aprofundado, focado em SQL, e informa possíveis soluções para essa instrução. Ela decide se deve aprofundar a análise de uma consulta com base na mudança no evento de espera que detecta, portanto você não precisa fornecer prompts adicionais.