PostgreSQL, RED, Golden Signals: um guia para ação

Métodos de observação Golden Signals e RED são modelos para a construção de monitoramento de serviço e definem as principais métricas que são necessárias para o monitoramento. Anteriormente, apenas os administradores de monitoramento ou engenheiros de SRE conheciam esses métodos. Agora o tópico de instrumentação de aplicativos não é mais algo novo e quase todo mundo conhece esses métodos.

Neste artigo irei discutir como cobrir o PostgreSQL no monitoramento usando os métodos RED e Golden Signals. O subsistema de monitoramento no Postgres foi implementado na época em que RED e Golden Signals ainda não existiam, e na minha humilde opinião existem algumas desvantagens nele, e pode parecer uma tarefa difícil colocar RED ou Golden Signals no Postgres imediatamente. Neste artigo, tentarei revisar brevemente as possibilidades que o Postgres fornece para a implementação de observação usando métodos RED / Golden Signals e darei instruções específicas para a implementação. Além disso, não é tão difícil quanto você pode imaginar.

Estou familiarizado com o RED e Golden Signals há relativamente muito tempo e há vários motivos pelos quais você deve usar esses métodos:

• o monitoramento usando esses métodos permite que você determine rapidamente (mas superficialmente) se tudo está em ordem com o serviço. 

• se houver uma ampla cobertura de outras métricas, ao investigar o problema, você pode ir mais fundo na direção certa, excluindo as menos importantes.

• eles são mais ou menos universais e aplicáveis ​​tanto a serviços da Web quanto a serviços de sistema que não têm como foco o trabalho direto com o usuário.

• são um bom começo para cobrir as necessidades básicas de monitoramento de qualquer serviço.

Em geral, se você tem um serviço incompreensível à sua frente que precisa ser monitorado, então nós apenas pegamos RED ou Golden Signals e, conforme a lista, montamos a coleta das informações necessárias e o retorno das métricas. Na saída, obtemos um mínimo básico (na forma de um painel) que, em geral, dá uma ideia suficiente se o serviço está funcionando bem ou mal. Além disso, já é possível implementar coisas mais detalhadas ou específicas do serviço. No entanto, esses métodos também têm desvantagens, então você não deve pensar que esses métodos cobrirão todas as necessidades possíveis de métricas.

Bem, espero que tenha sido convincente, vamos prosseguir para o Postgres.

A essência do RED e Golden Signals é medir as características quantitativas do tráfego que passa pelo serviço, por exemplo, RED é:

• Taxa de solicitação - o número de solicitações por segundo.

• Erros de solicitação - número de solicitações erradas por segundo.

• Request duration - ( ).

Golden Signals ( ), (Latency, Traffic, Errors), Saturation - , , .

HTTP (), - , . (Requests), (Errors), (Duration), (Saturation).

. , "". SQL- SQL-? SQL-, .. , 1 = 1 SQL-. RED SQL- (request_id, , / ..).

Requests

, R - requests. , - . Postgres (views). .

pg_stat_statements. . per-statement , statement () calls . calls . pg_stat_statements .

pg_stat_statements . - pg_stat_statements.track . 2 . "top" . "all" . "top", .. , , .

pg_stat_statements.

SELECT sum(calls) FROM pg_stat_statements;

. Prometheus, , Zabbix UserParameter.

pg_stat_activity pg_stat_database. , pg_stat_activity , .. (snapshot) , . xact_commit, .. . , .

Errors

" " pg_stat_database. xact_rollback . - , . . , SQL- ( BEGIN .. END) xact_rollback. xact_rollback .

SQL.

SELECT sum(xact_rollback) FROM pg_stat_database;

, . , . , . Postgres .

Duration

pg_stat_statements total_time. ( ) . total_time .

SELECT sum(total_time) FROM pg_stat_statements;

, , .. Prometheus . , pg_stat_statements . total_time min_time, max_time, mean_time, stddev_time. 13 . DBA-specific , - .

Saturation

(saturation), RED , Golden Signals. ( ) , ( ).

pg_stat_activity. , , .

GAUGE, . , . :

• (active, idle in transaction, waiting).

SELECT
	count(*) FILTER (WHERE state IS NOT NULL) AS total,
	count(*) FILTER (WHERE state = 'idle') AS idle,
	count(*) FILTER (WHERE state IN ('idle in transaction', 'idle in transaction (aborted)')) AS idle_in_xact,
	count(*) FILTER (WHERE state = 'active') AS active,
	count(*) FILTER (WHERE wait_event_type = 'Lock') AS waiting,
	count(*) FILTER (WHERE state IN ('fastpath function call','disabled')) AS others
FROM pg_stat_activity WHERE backend_type = 'client backend';

. xact_start - , state_change - - active .

• .

SELECT coalesce(max(extract(epoch FROM clock_timestamp() - xact_start)),0) AS max_idle_seconds
FROM pg_stat_activity
WHERE state IN ('idle in transaction', 'idle in transaction (aborted)');

• .

SELECT coalesce(max(extract(epoch FROM clock_timestamp() - state_change)),0) AS max_idle_seconds
FROM pg_stat_activity
WHERE wait_event_type = 'Lock';

, . . :

• idle in transactions waiting .

• idle .

• .

Postgres' RED Golden Signals SQL . , , . , request rate pg_stat_statements.calls. Request errors pg_stat_database.xact_rollback. Request duration pg_stat_statements.total_time. Saturation state, wait_event_type, xact_start, state_change pg_stat_activity.

6 , - drilldown- /. Postgres'.

?

1. Requests. , . , , .

2. Errors. , - / .

3. Duration. , . .

4. Saturation. idle waiting , . , ad-hoc idle .

- .

Weaponry Postgres , idle , Weaponry .

- -Postgres', .