Geekly articles weekly

Novos recursos de monitoramento do PostgesSQL PostgreSQL

Boa tarde, leitores habr!


Na primeira observação sobre posgres_exporter , examinei um caso bastante especial ao trabalhar com um novo fitcha da época, a saber, a capacidade de monitorar um conjunto de instâncias e / ou bancos de dados por um exportador. E ele descreveu esse "buquê" de problemas que encontrou e que soluções alternativas ele usou para fazê-lo funcionar.
E assim, em 25 de novembro, o próximo postgres_exporter 0.8.0 foi lançado. Ele resolveu os problemas descritos no artigo anterior e também, o que é especialmente interessante, adicionou novas funcionalidades.


Eu peço um gato ...


Para começar, gostaria de apresentar a postgre_exporter em mais detalhes e escrever uma espécie de guia de início rápido. Vamos examinar os principais pontos:


  1. Variáveis ​​de ambiente e parâmetros de inicialização
  2. O que são métricas padrão?
  3. Como adicionar suas próprias métricas

Descrição do produto


postgres_exporter - um utilitário para coletar métricas de instâncias de um cluster PostgreSQL DBMS em um formato acessível Prometheus, escrito em Go, é de código aberto e distribuído gratuitamente.


Variáveis ​​de ambiente e argumentos de linha de comando


O Postgres_exporter, como tal, não possui um arquivo de configuração e todos os parâmetros são transmitidos ao exportador por meio de variáveis ​​de ambiente ou argumentos de linha de comando. Ao mesmo tempo, os parâmetros para conectar-se ao DBMS podem ser transferidos apenas através de variáveis ​​de ambiente.


Variáveis ​​de ambiente


Como mencionado acima, as variáveis ​​de ambiente podem ser divididas em dois grupos. Os primeiros passam a cadeia de conexão, os segundos duplicam os argumentos da linha de comando.


Vamos começar com o primeiro grupo. Essas variáveis ​​começam com o prefixo DATA_SOURCE_ :


  • DATA_SOURCE_NAME - usado por padrão. Permite gravar a cadeia de conexão no formato = e na forma de um URI e pode conter o logon e a senha da conexão.
    Opções de trabalho válidas para conectar-se ao PostgreSQL:


    • postgresql://rolename@dbhost:dbport/datname?sslmode=disable ;
    • postgresql://rolename:rolpass@dbhost:dbport?sslmode=disable&db=datname ;
    • postgresql://rolename:rolpass@?sslmode=disable&dbname=database&host=dbhost&port=dbport ;
    • postgresql://rolename:rolpass@?sslmode=disable&dbname=database&host=/tmp (conexão através de um soquete UNIX, extraído dos diretórios unix_socket_ de uma instância do PostgreSQL);
    • host=dbhost port=dbport dbname=database user=rolename sslmode=disable ;

    Se você precisar se conectar a várias instâncias (não é permitido usar um espaço após o ponto decimal):


    • postgresql://rolename@dbhost:dbport/datname?sslmode=disable,postgresql://rolename@dbhost:dbport/datname?sslmode=disable ;
    • sslmode=disable dbname=postgres host=127.0.0.1 port=5434 user=postgres,sslmode=disable dbname=postgres port=5432 user=postgres .

  • DATA_SOURCE_URI - Alterne para DATA_SOURCE_NAME. Esta opção é adequada apenas se você deseja se conectar a uma única instância do PostgreSQL).
    A variável DATA_SOURCE_URI define a parte do URI sem um nome de usuário e senha, no formato "dbhost: dbport / dbname? Dbname? Key = value". O nome de usuário e a senha são obtidos das variáveis ​​de ambiente DATA_SOURCE_USER e DATA_SOURCE_PASS ou dos arquivos DATA_SOURCE_USER_FILE DATA_SOURCE_PASS_FILE.
    Quando o nome de usuário e a senha são armazenados em arquivos, seu conteúdo é extraído e reatribuído às variáveis ​​DATA_SOURCE_USER e DATA_SOURCE_PASS. Além disso, no código, tudo isso é coletado em um URI completo do formulário: "postgresql://" + DATA_SOURCE_USER + ":" + DATA_SOURCE_PASS + "@" + DATA_SOURCE_URI
  • DATA_SOURCE_URI_FILE - o mesmo que DATA_SOURCE_URI, somente leitura do arquivo;
  • DATA_SOURCE_USER - ao usar DATA_SOURCE_URI, define o nome de usuário para conectar-se ao DBMS;
  • DATA_SOURCE_USER_FILE - o mesmo que DATA_SOURCE_USER, somente leitura do arquivo;
  • DATA_SOURCE_PASS - ao usar DATA_SOURCE_URI, define a senha do usuário para conectar-se ao DBMS;
  • DATA_SOURCE_PASS_FILE - o mesmo que DATA_SOURCE_PASS, somente leitura do arquivo;

O segundo grupo inclui argumentos duplicados variáveis. I.e. na inicialização, você pode escolher, definir os parâmetros operacionais do aplicativo na forma de variáveis ​​de ambiente ou passar como argumentos na inicialização. Comece com o prefixo PG_EXPORTER_ :


  • PG_EXPORTER_WEB_LISTEN_ADDRESS - define o endereço e a porta através da qual o exportador receberá solicitações do Prometheus. Por padrão :9187 ;
  • PG_EXPORTER_WEB_TELEMETRY_PATH - o caminho ao longo do qual as métricas são fornecidas. Por padrão /metrics ;
  • PG_EXPORTER_DISABLE_DEFAULT_METRICS - desativa a coleção de métricas por padrão. O fato de que essas métricas estarão abaixo. Somente true ou false aceita valores. Falso por padrão (a coleta de métricas é permitida);
  • PG_EXPORTER_DISABLE_SETTINGS_METRICS - desativa a coleção de métricas da visualização pg_settings. O fato de que essas métricas estarão abaixo. Somente true ou false aceita valores. Falso por padrão (a coleta de métricas é permitida);
  • PG_EXPORTER_AUTO_DISCOVER_DATABASES - detecta todos os bancos de dados de uma instância de cluster para coletar suas métricas. Somente true ou false aceita valores. Por padrão, false (as métricas são coletadas apenas no banco de dados especificado nos parâmetros de conexão);
  • PG_EXPORTER_EXCLUDE_DATABASES - exclui o banco de dados da lista de bancos de dados cujas métricas são coletadas se PG_EXPORTER_AUTO_DISCOVER_DATABASES=true . Representa uma lista separada por vírgula de nomes de banco de dados. O padrão é uma sequência vazia. IMPORTANTE :
    • templates template0 e template1 - não é necessário excluir, portanto eles são cortados no estágio de obtenção de uma lista de bancos de dados a partir de pg_databases;
    • não pode excluir o banco de dados especificado no URI.
  • PG_EXPORTER_EXTEND_QUERY_PATH - O caminho para o arquivo YAML que contém consultas do usuário. O arquivo queries.yaml contém exemplos;
  • PG_EXPORTER_CONSTANT_LABELS - etiqueta (constante) adicionada a todas as métricas. Está escrito como uma lista de pares = , separados por vírgula.

Argumentos da linha de comando


  • O endereço web.listen é o mesmo que PG_EXPORTER_WEB_LISTEN_ADDRESS;
  • web.telemetry-path - o mesmo que PG_EXPORTER_WEB_TELEMETRY_PATH;
  • desativar métricas padrão é o mesmo que PG_EXPORTER_DISABLE_DEFAULT_METRICS;
  • desativar-configurações-métricas é o mesmo que PG_EXPORTER_DISABLE_SETTINGS_METRICS;
  • os bancos de dados de descoberta automática são os mesmos que PG_EXPORTER_AUTO_DISCOVER_DATABASES;
  • exclude-database é o mesmo que PG_EXPORTER_EXCLUDE_DATABASES;
  • extend.query-path - o mesmo que PG_EXPORTER_EXTEND_QUERY_PATH;
  • constantLabels - o mesmo que PG_EXPORTER_CONSTANT_LABELS;
  • dumpmaps - exibe o conteúdo interno do mapa de métricas. Usado para depurar solicitações de usuário. Não inicia o aplicativo;
  • log.level - define um dos níveis de log possíveis: debug , info , warn , error fatal ;
  • log.format - define o método e o formato da saída do log. Por exemplo: logger:syslog?appname=bob&local=7 ou logger:stdout?json=true . Por padrão, logger:stderr .

Métricas padrão


- métricas - são um determinado conjunto de métricas de monitoramento, cuja coleção é estabelecida diretamente no código. A coleção - pode ser desativada especificando os parâmetros da linha de comandos --disable-default-metrics e / ou --disable-settings-metrics ou definindo as variáveis ​​de ambiente apropriadas.
Observo que, na versão atual, o problema do uso de métricas foi resolvido quando a descoberta automática foi ativada, devido à duplicação de métricas, que levou a erros.


Por padrão, as métricas das seguintes visualizações são enviadas para o monitoramento:


  • pg_stat_bgwriter;
  • pg_stat_database;
  • pg_stat_database_conflicts;
  • pg_locks;
  • pg_stat_replication;
  • pg_stat_activity;
  • pg_settings.

Pelo que você deve prestar atenção, são pg_stat_replication e pg_stat_activity, pois o conjunto de campos retornados depende da versão do PostgreSQL. Para isso, a versão do DBMS é verificada no exportador e a solicitação correspondente é selecionada. Você não pode especificar uma versão nas consultas do usuário. Supõe-se que o administrador saiba antecipadamente qual versão a instância será monitorada. Também podem surgir problemas se você tentar coletar métricas de um exportador a partir de instâncias de versões diferentes.
Com as métricas de configuração da instância (pg_settings), tudo é um pouco mais simples, elas são formadas pela solicitação:


 SELECT name, setting, COALESCE(unit, ''), short_desc, vartype FROM pg_settings WHERE vartype IN ('bool', 'integer', 'real');

Assim, por padrão, um conjunto de métricas é formado apenas a partir de valores numéricos.


Além disso, consideraremos a conclusão do exportador, incluindo como entenderemos por que as métricas codificadas têm seu direito de existir. Por exemplo, tome duas métricas: shared_buffers e wal_sender_timeout. Na saída do exportador, para cada métrica, temos três linhas.
A primeira linha - representa a dica e consiste no nome da métrica em postgres_exporter, uma descrição (a coluna short_desc da visualização pg_settings) e se o tipo foi convertido para o tipo base, é indicado qual (o valor entre colchetes).
A segunda linha indica o tipo de valor, em termos de Prometeu. E a terceira linha, uma métrica com um conjunto de rótulos e um valor atribuído.


Retorne valores para shared_buffers.


 # HELP pg_settings_shared_buffers_bytes Sets the number of shared memory buffers used by the server. [Units converted to bytes.] # TYPE pg_settings_shared_buffers_bytes gauge pg_settings_shared_buffers_bytes{server="127.0.0.1:5432"} 1.34217728e+08

pg_settings_shared_buffers_bytes - o nome da métrica. De acordo com as regras de boa forma, é composto pelo nome da tabela, o nome da métrica e a unidade de medida. Em seguida, vem uma breve descrição da tabela pg_settings. E, finalmente, uma indicação de que o valor da métrica foi convertido em uma unidade de bytes (unidades convertidas em bytes). Por que vale a pena prestar atenção a este último, porque diretamente no banco de dados o valor parece um pouco diferente, a saber:


  name | setting | unit | short_desc ----------------+---------+------+-------------------------------------------------------------- shared_buffers | 16384 | 8kB | Sets the number of shared memory buffers used by the server.

O tipo de métrica que temos é GAUGE, o que significa que ela pode assumir valores arbitrários ao longo do tempo. No nosso caso, o número de buffers, quando ajustado, pode mudar nas duas direções.
Você pode aprender mais sobre os tipos de métricas e suas diferenças na documentação do Prometheus.


A seguinte métrica é wal_sender_timeout. Os campos de informações são coletados de acordo com o mesmo princípio descrito acima. Somente nesse caso, o valor da métrica é convertido em segundos e o banco de dados é armazenado em milissegundos. Com esse recurso, você precisa ter cuidado e considerar ao plotar gráficos.


 # HELP pg_settings_wal_sender_timeout_seconds Sets the maximum time to wait for WAL replication. [Units converted to seconds.] # TYPE pg_settings_wal_sender_timeout_seconds gauge pg_settings_wal_sender_timeout_seconds{server="127.0.0.1:5432"} 60

O valor armazenado no banco de dados:


 demo=# SELECT name, setting, COALESCE(unit, ''), short_desc, vartype FROM pg_settings WHERE name='wal_sender_timeout'; name | setting | coalesce | short_desc | vartype --------------------+---------+----------+----------------------------------------------------+--------- wal_sender_timeout | 60000 | ms | Sets the maximum time to wait for WAL replication. | integer

Todos os valores com unidades são reduzidos para dois tipos: métricas de volume em bytes; métricas de tempo para segundos.


Conjunto de métricas personalizadas


Além das métricas padrão ou no lugar delas, você pode usar as suas. Para fazer isso, basta definir o caminho do arquivo, com consultas do usuário, através do argumento --extend.query-path = query.yaml ou através da variável de ambiente PG_EXPORTER_EXTEND_QUERY_PATH.
O repositório do projeto possui um arquivo YAML com exemplos: queries.yaml


Observo que, em comparação com a versão anterior, na 0.8.0, novas chaves master e cache_seconds foram adicionadas. No exemplo abaixo, analisamos o formato de gravação e a finalidade dos campos.


Conteúdo de amostra do arquivo queries.yaml


 pg_database: query: "SELECT pg_database.datname, pg_database_size(pg_database.datname) as size_bytes FROM pg_database" master: true cache_seconds: 30 metrics: - datname: usage: "LABEL" description: "Name of the database" - size_bytes: usage: "GAUGE" description: "Disk space used by the database"

Chaves e valores do exemplo acima:


  • pg_database - um prefixo arbitrário para as métricas retornadas pela solicitação (obrigatório);
  • query - contém uma consulta SQL (obrigatório);
  • master - execute a solicitação apenas no banco de dados especificado ao conectar-se ao URI (banco de dados mestre). Necessário ao iniciar o exportador com o sinalizador --auto-discover-database. Aceita verdadeiro ou falso. Falso por padrão. (Opcional);
  • cache_seconds - tempo durante o qual os dados em cache serão retornados. É definido em segundos;
  • metrics - contém uma lista de tags e métricas;
  • datname , size_bytes - item da lista. O nome do item da lista deve corresponder ao nome da coluna na consulta;
  • usage - tipo de valor. Aceita COUNTER, GAUGE, LABLE (mais na documentação do Prometheus)
  • description - Descrição da métrica personalizada

Métricas de retorno de exemplo:


 # HELP pg_database_size_bytes Disk space used by the database # TYPE pg_database_size_bytes gauge pg_database_size_bytes{datname="dbtest1",server="localhost:5432"} 1.0105503e+07 pg_database_size_bytes{datname="demo",server="localhost:5432"} 2.813719199e+09 pg_database_size_bytes{datname="postgres",server="localhost:5432"} 4.735491e+06 pg_database_size_bytes{datname="template0",server="localhost:5432"} 7.758339e+06 pg_database_size_bytes{datname="template1",server="localhost:5432"} 7.758339e+06

Sumário


Bem, resumimos tudo o que temos na versão mais recente do postgres_exporter 0.8.0. Basicamente, todas as melhorias estão relacionadas ao monitoramento de várias instâncias e / ou vários bancos de dados em uma instância.


  • O argumento excluir bancos de dados (exibido em 0.6.0) permite excluir bancos de dados da lista de bancos de dados para os quais as métricas serão coletadas. Mas você não pode excluir o banco de dados especificado na conexão URI, pois é uma base principal;
  • Agora você pode usar consultas personalizadas para visualizações globais (pg_stat_activity, pg_stat_database, etc.) junto com o argumento de descoberta automática de bancos de dados. Para isso, foi adicionado um campo mestre adicional, indicando que a solicitação deve ser executada apenas no banco de dados mestre;
  • Agora você pode usar as métricas padrão com o argumento descoberta automática de bancos de dados;
  • Para solicitações do usuário, o campo cache_seconds foi adicionado, o que permite definir o tempo (em segundos) pelo qual a resposta do servidor à solicitação correspondente será armazenada em cache.

Fontes


  • Prometheus [ 1 ] é um aplicativo de código aberto usado para monitorar e alertar eventos. Ele grava métricas em tempo real em um banco de dados de séries temporais criado usando o modelo de solicitação HTTP, com consultas flexíveis e alertas em tempo real.
  • O postgres_exporter é um exportador de métricas do PostgreSQL para o Prometheus.
    Versão, no momento da redação, v 0.5.1. Versões suportadas do PostgreSQL 9.4+ (mas como a prática demonstrou, ele funciona na 9.3).

Source: https://habr.com/ru/post/pt480902/

More articles:


All Articles