Recuperar métricas com a API do Performance Insights

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á.

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á.

Quando o Performance Insights está habilitado, a API fornece visibilidade à performance da instância. O Amazon CloudWatch Logs fornece a fonte confiável para métricas de monitoramento de serviços vendidos. AWS

O Performance Insights oferece uma visão específica do domínio da carga do banco de dados medida como sessões ativas médias (AAS). Essa métrica aparece para os consumidores de API como um conjunto de dados bidimensional de séries temporais. A dimensão de tempo dos dados fornece a carga do banco de dados para cada ponto de tempo no intervalo de tempo consultado. Cada ponto de tempo decompõe a carga geral em relação às dimensões solicitadas, como Query, Wait-state, Application ou Host, medidas naquele ponto de tempo.

O Performance Insights do Amazon DocumentDB monitora sua instância de banco de dados do Amazon DocumentDB, para que você possa analisar e solucionar problemas relacionados ao desempenho do seu banco de dados. Uma maneira de visualizar os dados do Performance Insights está no AWS Management Console. O Performance Insights também fornece uma API pública para que você possa consultar seus próprios dados. É possível usar a API para fazer o seguinte:

Para usar a API do Performance Insights, habilite o Performance Insights em uma das suas instâncias do Amazon DocumentDB. Para obter informações sobre como habilitar o Performance Insights, consulte Ativar e desativar o Performance Insights. Para obter mais informações sobre a API do Performance Insights, consulte a Referência de API do Performance Insights.

A API do Performance Insights fornece as operações a seguir.

AWS CLI para Performance Insights

É possível visualizar dados do Performance Insights usando o AWS CLI. Você pode visualizar a ajuda dos comandos da AWS CLI para o Performance Insights, inserindo o seguinte na linha de comando.

aws pi help

Se você não tiver o AWS CLI instalado, consulte Instalando a interface de linha de AWS comando no Guia do AWS CLI usuário para obter informações sobre como instalá-lo.

Recuperar métricas de séries temporais

A operação GetResourceMetrics recupera uma ou mais métricas de séries temporais dos dados do Performance Insights. GetResourceMetrics requer uma métrica e um período de tempo e retorna uma resposta com uma lista de pontos de dados.

Por exemplo, os AWS Management Console usos GetResourceMetrics para preencher o gráfico Counter Metrics e o gráfico Database Load, conforme mostrado na imagem a seguir.

Todas as métricas retornadas por GetResourceMetrics são métricas de séries temporais padrão, com exceção de db.load. Essa métrica é exibida no gráfico Carregamento do banco de dados. A métrica db.load é diferente das outras métricas da série temporal, pois você pode fragmentá-la em subcomponentes chamados de dimensões. Na imagem anterior, db.load é dividido e agrupado pelos estados de espera que compõem o db.load.

Para obter informações sobre as métricas de contador retornadas pelo GetResourceMetrics, consulte Métricas de contadores do Performance Insights.

Os cálculos a seguir são compatíveis com as métricas:

Por exemplo, considere que uma métrica é coletada por 300 segundos (5 minutos) e que a métrica seja coletada uma vez por minuto. Os valores de cada minuto são 1, 2, 3, 4 e 5. Nesse caso, os seguintes cálculos são retornados:

Para obter informações sobre como usar o get-resource-metrics AWS CLI comando, consulte get-resource-metrics.

Para a opção --metric-queries, especifique uma ou mais consultas para as quais deseja obter resultados. Cada consulta consiste em um parâmetro obrigatório Metric e opcional GroupBy e em parâmetros Filter. Veja a seguir um exemplo de uma especificação de opção --metric-queries.

{
   "Metric": "string",
   "GroupBy": {
     "Group": "string",
     "Dimensions": ["string", ...],
     "Limit": integer
   },
   "Filter": {"string": "string"
     ...}

AWS CLI exemplos de Performance Insights

Os exemplos a seguir mostram como usar o AWS CLI for Performance Insights.

Recuperar métricas de contador

A captura de tela a seguir mostra dois gráficos de métricas de contador no AWS Management Console.

O exemplo a seguir mostra como reunir os mesmos dados que o AWS Management Console usa para gerar os dois gráficos de métricas de contador.

Para Linux, macOS ou Unix:

aws pi get-resource-metrics \
   --service-type DOCDB \
   --identifier db-ID \
   --start-time 2022-03-13T8:00:00Z \
   --end-time   2022-03-13T9:00:00Z \
   --period-in-seconds 60 \
   --metric-queries '[{"Metric": "os.cpuUtilization.user.avg"  },
                      {"Metric": "os.cpuUtilization.idle.avg"}]'

Para Windows:

aws pi get-resource-metrics ^
   --service-type DOCDB ^
   --identifier db-ID ^
   --start-time 2022-03-13T8:00:00Z ^
   --end-time   2022-03-13T9:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries '[{"Metric": "os.cpuUtilization.user.avg"  },
                      {"Metric": "os.cpuUtilization.idle.avg"}]'

Você também pode tornar um comando mais fácil de ler, especificando um arquivo para a opção --metrics-query. O exemplo a seguir usa um arquivo chamado query.json para a opção. O arquivo tem o seguinte conteúdo.

[
    {
        "Metric": "os.cpuUtilization.user.avg"
    },
    {
        "Metric": "os.cpuUtilization.idle.avg"
    }
]

Execute o seguinte comando para usar o arquivo.

Para Linux, macOS ou Unix:

aws pi get-resource-metrics \
   --service-type DOCDB \
   --identifier db-ID \
   --start-time 2022-03-13T8:00:00Z \
   --end-time   2022-03-13T9:00:00Z \
   --period-in-seconds 60 \
   --metric-queries file://query.json

Para Windows:

aws pi get-resource-metrics ^
   --service-type DOCDB ^
   --identifier db-ID ^
   --start-time 2022-03-13T8:00:00Z ^
   --end-time   2022-03-13T9:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries file://query.json

O exemplo anterior especifica os seguintes valores para as opções:

Ele consulta um intervalo de tempo de uma hora:

A resposta é semelhante à seguinte.

{
    "AlignedStartTime": "2022-03-13T08:00:00+00:00",
    "AlignedEndTime": "2022-03-13T09:00:00+00:00",
    "Identifier": "db-NQF3TTMFQ3GTOKIMJODMC3KQQ4",
    "MetricList": [
        {
            "Key": {
                "Metric": "os.cpuUtilization.user.avg"
            },
            "DataPoints": [
                {
                    "Timestamp": "2022-03-13T08:01:00+00:00", //Minute1
                    "Value": 3.6
                },
                {
                    "Timestamp": "2022-03-13T08:02:00+00:00", //Minute2
                    "Value": 2.6
                },
                //.... 60 datapoints for the os.cpuUtilization.user.avg metric
        {
            "Key": {
                "Metric": "os.cpuUtilization.idle.avg"
            },
            "DataPoints": [
                {
                    "Timestamp": "2022-03-13T08:01:00+00:00",
                    "Value": 92.7
                },
                {
                    "Timestamp": "2022-03-13T08:02:00+00:00",
                    "Value": 93.7
                },
                //.... 60 datapoints for the os.cpuUtilization.user.avg metric 
            ]
        }
    ] //end of MetricList
} //end of response

A resposta tem Identifier, AlignedStartTime e AlignedEndTime. Se o valor de --period-in-seconds fosse 60, as horas de início e término seriam alinhadas ao minuto. Se --period-in-seconds fosse 3600, as horas de início e término teriam sido alinhadas à hora.

O MetricList na resposta tem um número de entradas, cada uma com uma entrada Key e DataPoints. Cada DataPoint tem um Timestamp e um Value. Cada lista Datapoints tem 60 pontos de dados, pois as consultas são para dados por minuto ao longo de uma hora, com Timestamp1/Minute1, Timestamp2/Minute2 e assim por diante, até Timestamp60/Minute60.

Como a consulta é para duas métricas de contador diferentes, há dois elementos na resposta MetricList.

Recuperar a média de carga de banco de dados para eventos de espera superior

O exemplo a seguir é a mesma consulta AWS Management Console usada para gerar um gráfico de linha de área empilhada. Este exemplo recupera o db.load.avg para a última hora com carga dividida de acordo com os sete principais eventos de espera. O comando é o mesmo que o comando em Recuperar métricas de contador. No entanto, o arquivo query.json tem o seguinte conteúdo.

[
    {
        "Metric": "db.load.avg",
        "GroupBy": { "Group": "db.wait_state", "Limit": 7 }
    }
]

Execute o seguinte comando.

Para Linux, macOS ou Unix:

aws pi get-resource-metrics \
   --service-type DOCDB \
   --identifier db-ID \
   --start-time 2022-03-13T8:00:00Z \
   --end-time   2022-03-13T9:00:00Z \
   --period-in-seconds 60 \
   --metric-queries file://query.json

Para Windows:

aws pi get-resource-metrics ^
   --service-type DOCDB ^
   --identifier db-ID ^
   --start-time 2022-03-13T8:00:00Z ^
   --end-time   2022-03-13T9:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries file://query.json

O exemplo especifica a métrica de db.load.avg e um GroupBy dos sete principais estados de espera. Para obter detalhes sobre valores válidos para esse exemplo, consulte DimensionGroupa Referência da API Performance Insights.

A resposta é semelhante à seguinte.

{
    "AlignedStartTime": "2022-04-04T06:00:00+00:00",
    "AlignedEndTime": "2022-04-04T06:15:00+00:00",
    "Identifier": "db-NQF3TTMFQ3GTOKIMJODMC3KQQ4",
    "MetricList": [
        {//A list of key/datapoints
            "Key": {
                //A Metric with no dimensions. This is the total db.load.avg
                "Metric": "db.load.avg"
            },
            "DataPoints": [
                //Each list of datapoints has the same timestamps and same number of items
                {
                    "Timestamp": "2022-04-04T06:01:00+00:00",//Minute1
                    "Value": 0.0
                },
                {
                    "Timestamp": "2022-04-04T06:02:00+00:00",//Minute2
                    "Value": 0.0
                },
                //... 60 datapoints for the total db.load.avg key
                ]
        },
        {
            "Key": {
                //Another key. This is db.load.avg broken down by CPU
                "Metric": "db.load.avg",
                "Dimensions": {
                    "db.wait_state.name": "CPU"
                }
            },
            "DataPoints": [
                {
                    "Timestamp": "2022-04-04T06:01:00+00:00",//Minute1
                    "Value": 0.0
                },
                {
                    "Timestamp": "2022-04-04T06:02:00+00:00",//Minute2
                    "Value": 0.0
                },
                //... 60 datapoints for the CPU key
            ]
        },//... In total we have 3 key/datapoints entries, 1) total, 2-3) Top Wait States
    ] //end of MetricList
} //end of response
			

Nessa resposta, há três entradas no MetricList. Há uma entrada para o db.load.avg total, e três entradas cada para o db.load.avg, divididas de acordo com um dos três principais eventos de espera. Ao contrário do primeiro exemplo, como havia uma dimensão de agrupamento, deve haver uma chave para cada agrupamento da métrica. Não pode haver apenas uma chave para cada métrica, como no caso de uso de métricas de contador.

Recuperar a média de carga de banco de dados para consulta principal

O exemplo a seguir agrupa db.wait_state pelas 10 principais instruções de consulta. Existem dois grupos diferentes para instruções de consulta:

Ao analisar a performance do banco de dados, pode ser útil considerar instruções de consulta que diferem apenas por seus parâmetros como um item lógico. Então, você pode usar db.query_tokenized ao consultar. No entanto, especialmente quando você está interessado em explain(), às vezes é mais útil examinar instruções de consulta completas com parâmetros. Existe um relacionamento pai-filho entre as consultas tokenizadas e completas, com várias consultas completas (filhos) agrupadas sob a mesma consulta tokenizada (pai).

O comando neste exemplo é semelhante ao comando em Recuperar a média de carga de banco de dados para eventos de espera superior. No entanto, o arquivo query.json tem o seguinte conteúdo.

[
    {
        "Metric": "db.load.avg",
        "GroupBy": { "Group": "db.query_tokenized", "Limit": 10 }
    }
]

O exemplo a seguir usa db.query_tokenized.

Para Linux, macOS ou Unix:

aws pi get-resource-metrics \
   --service-type DOCDB \
   --identifier db-ID \
   --start-time 2022-03-13T8:00:00Z \
   --end-time   2022-03-13T9:00:00Z \
   --period-in-seconds 3600 \
   --metric-queries file://query.json 

Para Windows:

aws pi get-resource-metrics ^
   --service-type DOCDB ^
   --identifier db-ID ^
   --start-time 2022-03-13T8:00:00Z ^
   --end-time   2022-03-13T9:00:00Z  ^
   --period-in-seconds 3600 ^
   --metric-queries file://query.json 

Este exemplo faz consultas em mais de 1 hora, com um minuto period-in-seconds.

O exemplo especifica a métrica de db.load.avg e um GroupBy dos sete principais estados de espera. Para obter detalhes sobre valores válidos para esse exemplo, consulte DimensionGroupa Referência da API Performance Insights.

A resposta é semelhante à seguinte.

{
    "AlignedStartTime": "2022-04-04T06:00:00+00:00",
    "AlignedEndTime": "2022-04-04T06:15:00+00:00",
    "Identifier": "db-NQF3TTMFQ3GTOKIMJODMC3KQQ4",
    "MetricList": [
        {//A list of key/datapoints
            "Key": {
                "Metric": "db.load.avg"
            },
            "DataPoints": [
                //... 60 datapoints for the total db.load.avg key
                ]
        },
               {
            "Key": {//Next key are the top tokenized queries
                "Metric": "db.load.avg",
                "Dimensions": {
                    "db.query_tokenized.db_id": "pi-1064184600",
                    "db.query_tokenized.id": "77DE8364594EXAMPLE",
                    "db.query_tokenized.statement": "{\"find\":\"customers\",\"filter\":{\"FirstName\":\"?\"},\"sort\":{\"key\":{\"$numberInt\":\"?\"}},\"limit\"
:{\"$numberInt\":\"?\"},\"$db\":\"myDB\",\"$readPreference\":{\"mode\":\"primary\"}}"
                }
            },
            "DataPoints": [
            //... 60 datapoints 
            ]
        },
        // In total 11 entries, 10 Keys of top tokenized queries, 1 total key 
    ] //End of MetricList
} //End of response

Essa resposta tem 11 entradas no MetricList (1 total, 10 principais consultas tokenizadas), e cada entrada com 24 DataPoints por hora.

Para consultas tokenizadas, existem três entradas em cada lista de dimensões:

Ao consultar, pode ser conveniente especificar Group em GroupBy. No entanto, para um controle mais refinado sobre os dados retornados, especifique a lista de dimensões. Por exemplo, se tudo o que for necessário for o db.query_tokenized.statement, um atributo Dimensions poderá ser adicionado ao arquivo query.json.

[
    {
        "Metric": "db.load.avg",
        "GroupBy": {
            "Group": "db.query_tokenized",
            "Dimensions":["db.query_tokenized.statement"],
            "Limit": 10
        }
    }
]

Recuperação da média de carga de banco de dados filtrada por Consulta

A consulta da API correspondente neste exemplo é semelhante ao comando em Recuperar a média de carga de banco de dados para consulta principal. No entanto, o arquivo query.json tem o seguinte conteúdo.

[
 {
        "Metric": "db.load.avg",
        "GroupBy": { "Group": "db.wait_state", "Limit": 5  }, 
        "Filter": { "db.query_tokenized.id": "AKIAIOSFODNN7EXAMPLE" }
    }
]

Nessa resposta, todos os valores são filtrados de acordo com a contribuição da consulta tokenizada AKIAIOSFODNN7 EXAMPLE especificada no arquivo query.json. As chaves também podem seguir uma ordem diferente de uma consulta sem um filtro, porque são os cinco principais estados de espera que afetaram a consulta filtrada.