Conceptos básicos de monitorización PostgreSQL. Alexey Lesovsky

Suxiro que lea a transcrición do informe de Alexey Lesovsky de Data Egret "Fundamentos do seguimento de PostgreSQL"

Neste informe, Alexey Lesovsky falará dos puntos clave das estatísticas posteriores ao congreso, o que significan e por que deberían estar presentes no seguimento; sobre que gráficos deben estar no seguimento, como engadilos e como interpretalos. O informe será útil para administradores de bases de datos, administradores de sistemas e desenvolvedores que estean interesados ​​na resolución de problemas de Postgres.

Chámome Alexey Lesovsky, represento á empresa Data Egret.

Unhas palabras sobre min. Comecei hai moito tempo como administrador de sistemas.

Administrei todo tipo de sistemas Linux diferentes, traballei en varias cousas relacionadas con Linux, é dicir, virtualización, monitorización, traballei con proxies, etc. Pero nalgún momento empecei a traballar máis con bases de datos, PostgreSQL. Gustoume moito. E nalgún momento comecei a traballar en PostgreSQL a maior parte do meu tempo de traballo. E así pouco a pouco convertínme nun DBA de PostgreSQL.

E ao longo da miña carreira, sempre me interesaron os temas de estatística, seguimento e telemetría. E cando era administrador de sistemas, traballei moi estreitamente con Zabbix. E escribín un pequeno conxunto de guións como extensións de zabbix. Era moi popular na súa época. E alí foi posible supervisar cousas importantes moi diferentes, non só Linux, senón tamén varios compoñentes.

Agora estou traballando en PostgreSQL. Xa estou escribindo outra cousa que che permita traballar coas estatísticas de PostgreSQL. Chámase pgCenter (artigo sobre Habré - Estatísticas post-gresión sen nervios e tensión).

Unha pequena nota introdutoria. Que situacións teñen os nosos clientes, os nosos clientes? Hai algún tipo de accidente relacionado coa base de datos. E cando a base de datos xa foi restaurada, vén o xefe do departamento ou o xefe de desenvolvemento e di: "Amigos, temos que supervisar a base de datos, porque pasou algo malo e hai que evitar que isto suceda no futuro". E aquí comeza o interesante proceso de escoller un sistema de monitorización ou adaptar un sistema de monitorización existente para que poida supervisar a súa base de datos -PostgreSQL, MySQL ou outros. E os compañeiros comezan a suxerir: “Escoitei que hai tal e tal base de datos. Imos usalo". Os compañeiros comezan a discutir entre eles. E ao final resulta que seleccionamos algún tipo de base de datos, pero a monitorización de PostgreSQL preséntase nela bastante mal e sempre temos que engadir algo. Colle algúns repositorios de GitHub, clonalos, adapta scripts e personalízaos dalgún xeito. E ao final acaba sendo unha especie de traballo manual.

Por iso, nesta charla intentarei darvos algúns coñecementos sobre como escoller a monitorización non só para PostgreSQL, senón tamén para a base de datos. E darche os coñecementos que che permitirán completar a túa vixilancia para sacarlle algún beneficio, para que poidas supervisar a túa base de datos con proveito, para evitar con prontitude calquera situación de emerxencia que poida xurdir.

E as ideas que haberá neste informe pódense adaptar directamente a calquera base de datos, xa sexa un DBMS ou noSQL. Polo tanto, non só hai PostgreSQL, senón que haberá moitas receitas sobre como facelo en PostgreSQL. Haberá exemplos de consultas, exemplos de entidades que PostgreSQL ten para supervisar. E se o teu DBMS ten as mesmas cousas que che permiten poñelas en monitorización, tamén podes adaptalas, engadilas e estará ben.

Non estarei no informe
falar sobre como entregar e almacenar métricas. Non vou dicir nada sobre o post-procesamento dos datos e presentalos ao usuario. E non vou dicir nada sobre avisar.
Pero a medida que avance a historia, mostrarei diferentes capturas de pantalla do seguimento existente e criticarei dalgún xeito. Pero con todo, intentarei non nomear marcas para non crear publicidade ou antipublicidade para estes produtos. Polo tanto, todas as coincidencias son aleatorias e déixanse á túa imaxinación.

En primeiro lugar, imos descubrir o que é o seguimento. O seguimento é algo moi importante. Todo o mundo entende isto. Pero ao mesmo tempo, o seguimento non se relaciona cun produto comercial e non afecta directamente aos beneficios da empresa, polo que o tempo sempre se destina ao seguimento de forma residual. Se temos tempo, facemos seguimento; se non temos tempo, está ben, poñémolo no atraso e algún día volveremos a estas tarefas.

Polo tanto, dende a nosa práctica, cando chegamos aos clientes, o seguimento é moitas veces incompleto e non ten ningunha cousa interesante que nos axude a facer un mellor traballo coa base de datos. E, polo tanto, sempre hai que completar o seguimento.

As bases de datos son cousas tan complexas que tamén hai que supervisar, porque as bases de datos son un repositorio de información. E a información é moi importante para a empresa, non se pode perder de ningún xeito. Pero ao mesmo tempo, as bases de datos son pezas de software moi complexas. Constan dunha gran cantidade de compoñentes. E moitos destes compoñentes deben ser supervisados.

Se falamos específicamente de PostgreSQL, pódese representar en forma de esquema que consta dunha gran cantidade de compoñentes. Estes compoñentes interactúan entre si. E ao mesmo tempo, PostgreSQL ten o chamado subsistema Stats Collector, que permite recoller estatísticas sobre o funcionamento destes subsistemas e proporcionar algún tipo de interface ao administrador ou usuario para que poida ver estas estatísticas.

Estas estatísticas preséntanse en forma dun determinado conxunto de funcións e vistas. Tamén se poden chamar táboas. É dicir, usando un cliente psql normal, pode conectarse á base de datos, facer unha selección destas funcións e vistas e obter algúns números específicos sobre o funcionamento dos subsistemas PostgreSQL.

Podes engadir estes números ao teu sistema de seguimento favorito, debuxar gráficos, engadir funcións e obter análises a longo prazo.

Pero neste informe non cubrirei todas estas funcións por completo, porque podería levar todo o día. Abordarei literalmente dúas, tres ou catro cousas e contarei como axudan a mellorar o seguimento.

E se falamos de vixilancia de bases de datos, que hai que supervisar? En primeiro lugar, cómpre vixiar a dispoñibilidade, porque a base de datos é un servizo que proporciona acceso aos datos aos clientes e necesitamos vixiar a dispoñibilidade, e tamén proporcionar algunhas das súas características cualitativas e cuantitativas.

Tamén necesitamos supervisar os clientes que se conectan á nosa base de datos, porque poden ser tanto clientes normais como clientes daniños que poden danar a base de datos. Tamén hai que supervisarlles e facer un seguimento das súas actividades.

Cando os clientes se conectan á base de datos, é obvio que comezan a traballar cos nosos datos, polo que hai que supervisar como traballan os clientes cos datos: con que táboas e, en menor medida, con que índices. É dicir, necesitamos avaliar a carga de traballo que crean os nosos clientes.

Pero a carga de traballo tamén consiste, por suposto, en solicitudes. As aplicacións conéctanse á base de datos, acceden aos datos mediante consultas, polo que é importante avaliar que consultas temos na base de datos, vixiar a súa adecuación, que non estean mal escritas, que hai que reescribir e facer algunhas opcións para que funcionen máis rápido. e con mellor rendemento.

E xa que estamos a falar dunha base de datos, a base de datos é sempre procesos en segundo plano. Os procesos en segundo plano axudan a manter o rendemento da base de datos nun bo nivel, polo que requiren unha certa cantidade de recursos para funcionar. E ao mesmo tempo, poden solaparse cos recursos de solicitudes de clientes, polo que os procesos en segundo plano cobizosos poden afectar directamente o rendemento das solicitudes dos clientes. Polo tanto, tamén deben ser supervisados ​​e rastreados para que non haxa distorsións en canto aos procesos en segundo plano.

E todo isto en canto ao seguimento da base de datos permanece na métrica do sistema. Pero tendo en conta que a maior parte da nosa infraestrutura está a moverse ás nubes, as métricas do sistema dun host individual sempre pasan a un segundo plano. Pero nas bases de datos seguen sendo relevantes e, por suposto, tamén é necesario supervisar as métricas do sistema.

Todo está máis ou menos ben coas métricas do sistema, todos os sistemas de monitorización modernos xa admiten estas métricas, pero en xeral, algúns compoñentes aínda non son suficientes e hai que engadir algunhas cousas. Tamén os tocarei, haberá varias diapositivas sobre eles.

O primeiro punto do plan é a accesibilidade. Que é a accesibilidade? A dispoñibilidade, ao meu entender, é a capacidade da base para dar servizo ás conexións, é dicir, que a base se eleva, que, como servizo, acepta conexións dos clientes. E esta accesibilidade pódese valorar por determinadas características. É moi cómodo mostrar estas características nos cadros de mando.

Todo o mundo sabe o que son os paneis. É entón cando botaches unha ollada á pantalla na que se resume a información necesaria. E pode determinar inmediatamente se hai un problema na base de datos ou non.
En consecuencia, a dispoñibilidade da base de datos e outras características clave deberían mostrarse sempre nos paneis de mando para que esta información estea a man e sempre dispoñible para ti. Algúns detalles adicionais que xa axudan na investigación de incidentes, cando se investigan algunhas situacións de emerxencia, xa teñen que ser colocados en paneis secundarios, ou ocultos en ligazóns de exploración que leven a sistemas de monitorización de terceiros.

Un exemplo dun sistema de vixilancia coñecido. Este é un sistema de vixilancia moi xenial. Ela recolle moitos datos, pero dende o meu punto de vista, ten un concepto estraño de paneis. Hai unha ligazón para "crear un panel". Pero cando creas un panel, creas unha lista de dúas columnas, unha lista de gráficos. E cando precisa mirar algo, comeza a facer clic co rato, a desprazarse, buscando o gráfico desexado. E isto leva tempo, é dicir, non hai paneis como tal. Só hai listas de gráficos.

Que deberías engadir a estes paneis? Podes comezar cunha característica como o tempo de resposta. PostgreSQL ten a vista pg_stat_statements. Está desactivado de forma predeterminada, pero é unha das vistas importantes do sistema que sempre se debe activar e usar. Almacena información sobre todas as consultas en execución que se executaron na base de datos.

En consecuencia, podemos partir do feito de que podemos tomar o tempo total de execución de todas as solicitudes e dividilo polo número de solicitudes usando os campos anteriores. Pero esta é a temperatura media no hospital. Podemos partir doutros campos: tempo mínimo de execución de consulta, máximo e medio. E incluso podemos construír percentiles; PostgreSQL ten as funcións correspondentes para iso. E podemos obter algúns números que caracterizan o tempo de resposta da nosa base de datos para solicitudes xa completadas, é dicir, non executamos a solicitude falsa "seleccionar 1" e miramos o tempo de resposta, senón que analizamos o tempo de resposta para as solicitudes xa completadas e debuxamos. ou ben unha figura separada, ou construímos unha gráfica baseada nela.

Tamén é importante controlar o número de erros que xera actualmente o sistema. E para iso podes usar a vista pg_stat_database. Centrámonos no campo xact_rollback. Este campo mostra non só o número de retrocesos que se producen na base de datos, senón que tamén ten en conta o número de erros. En termos relativos, podemos mostrar esta cifra no noso panel e ver cantos erros temos actualmente. Se hai moitos erros, esta é unha boa razón para mirar os rexistros e ver que tipo de erros son e por que ocorren, e despois investilos e resolvelos.

Podes engadir algo como un tacómetro. Estes son o número de transaccións por segundo e o número de solicitudes por segundo. En termos relativos, pode usar estes números como o rendemento actual da súa base de datos e observar se hai picos nas solicitudes, nas transaccións ou, pola contra, se a base de datos está subcargada porque algún backend fallou. É importante mirar sempre esta cifra e lembrar que para o noso proxecto este tipo de actuación é normal, pero os valores de arriba e debaixo xa son algo problemáticos e incomprensibles, o que significa que hai que ver por que son estes números. tan alto.

Para estimar o número de transaccións, podemos volver consultar a vista pg_stat_database. Podemos engadir o número de commits e o número de rollbacks e obter o número de transaccións por segundo.

Todos entenden que varias solicitudes poden caber nunha mesma transacción? Polo tanto, TPS e QPS son lixeiramente diferentes.

O número de solicitudes por segundo pódese obter de pg_stat_statements e simplemente calcula a suma de todas as solicitudes completadas. Está claro que comparamos o valor actual co anterior, restamos, obtemos o delta e obtemos a cantidade.

Podes engadir métricas adicionais se o desexas, que tamén axudan a avaliar a dispoñibilidade da nosa base de datos e supervisar se houbo algún tempo de inactividade.

Unha destas métricas é o tempo de actividade. Pero o tempo de actividade en PostgreSQL é un pouco complicado. Vouche dicir por que. Cando PostgreSQL comezou, o tempo de actividade comeza a informar. Pero se nalgún momento, por exemplo, algunha tarefa estaba a executarse pola noite, chegou un OOM-Killer e rematou pola forza o proceso fillo de PostgreSQL, entón, neste caso, PostgreSQL finaliza a conexión de todos os clientes, restablece a área de memoria dividida e comeza a recuperación desde o último punto de control. E mentres dura esta recuperación do punto de control, a base de datos non acepta conexións, é dicir, esta situación pódese avaliar como tempo de inactividade. Pero o contador de tempo de actividade non se restablecerá, porque ten en conta o tempo de inicio do postmaster desde o primeiro momento. Polo tanto, tales situacións pódense saltar.

Tamén debe supervisar o número de traballadores do baleiro. Todo o mundo sabe o que é o baleiro automático en PostgreSQL? Este é un subsistema interesante en PostgreSQL. Sobre ela escribíronse moitos artigos, fixéronse moitos informes. Hai moitas discusións sobre o baleiro e como debería funcionar. Moitos considérano un mal necesario. Pero así é. Este é unha especie de análogo dun colector de lixo que limpa versións obsoletas de filas que non son necesarias por ningunha transacción e libera espazo en táboas e índices para novas filas.

Por que é necesario supervisalo? Porque o baleiro ás veces doe moito. Consome unha gran cantidade de recursos e as solicitudes dos clientes comezan a sufrir como resultado.

E debería supervisarse a través da vista pg_stat_activity, da que falarei na seguinte sección. Esta vista mostra a actividade actual na base de datos. E a través desta actividade podemos facer un seguimento do número de aspiradores que están funcionando agora mesmo. Podemos rastrexar os baleiros e ver que se superamos o límite, entón este é un motivo para mirar a configuración de PostgreSQL e optimizar dalgún xeito o funcionamento do baleiro.

Outra cousa sobre PostgreSQL é que PostgreSQL está moi farto de transaccións longas. Especialmente de transaccións que se manteñen durante moito tempo e non fan nada. Esta é a chamada estat inactiva en transacción. Tal transacción mantén peches e impide que o baleiro funcione. E como resultado, as mesas inchan e aumentan de tamaño. E as consultas que funcionan con estas táboas comezan a funcionar máis lentamente, porque cómpre pasar todas as versións antigas das filas da memoria ao disco e viceversa. Polo tanto, tamén hai que supervisar o tempo, a duración das transaccións máis longas e as solicitudes de baleiro máis longas. E se vemos algúns procesos que levan en execución durante moito tempo, xa máis de 10-20-30 minutos para unha carga OLTP, entón debemos prestarlles atención e finalizalos con forza ou optimizar a aplicación para que non se chaman e non colgan tanto tempo. Para unha carga de traballo analítico, 10-20-30 minutos é normal; tamén hai outros máis longos.

A continuación temos a opción con clientes conectados. Cando xa creamos un panel e publicamos nel as métricas de dispoñibilidade clave, tamén podemos engadir alí información adicional sobre os clientes conectados.

A información sobre os clientes conectados é importante porque, desde a perspectiva de PostgreSQL, os clientes son diferentes. Hai bos clientes e hai malos clientes.

Un exemplo sinxelo. Por cliente entendo a aplicación. A aplicación conectouse á base de datos e inmediatamente comeza a enviar as súas solicitudes alí, a base de datos procesa e execútaas e devolve os resultados ao cliente. Estes son clientes bos e correctos.

Hai situacións nas que o cliente conectouse, mantén a conexión, pero non fai nada. Está en estado inactivo.

Pero hai malos clientes. Por exemplo, o mesmo cliente conectouse, abriu unha transacción, fixo algo na base de datos e despois entrou no código, por exemplo, para acceder a unha fonte externa ou para procesar alí os datos recibidos. Pero non pechou a transacción. E a transacción colócase na base de datos e mantense nun bloqueo na liña. Esta é unha mala condición. E se de súpeto falla unha aplicación nalgún lugar dentro de si mesma cunha excepción, entón a transacción pode permanecer aberta durante moito tempo. E isto afecta directamente o rendemento de PostgreSQL. PostgreSQL será máis lento. Polo tanto, é importante rastrexar tales clientes de forma oportuna e terminar o seu traballo con forza. E cómpre optimizar a súa aplicación para que non se produzan tales situacións.

Outros malos clientes están esperando clientes. Pero son malos polas circunstancias. Por exemplo, unha simple transacción inactiva: pode abrir unha transacción, bloquear algunhas liñas, despois nalgún lugar do código fallará, deixando unha transacción pendente. Outro cliente virá e solicitará os mesmos datos, pero atoparase cun bloqueo, porque esa transacción colgante xa ten bloqueos nalgunhas filas obrigatorias. E a segunda transacción quedará esperando a que se complete a primeira transacción ou o peche forzosamente polo administrador. Polo tanto, as transaccións pendentes poden acumularse e cubrir o límite de conexión á base de datos. E cando o límite está cheo, a aplicación xa non pode funcionar coa base de datos. Esta é xa unha situación de emerxencia para o proxecto. Polo tanto, os malos clientes deben ser rastreados e respondidos de forma oportuna.

Outro exemplo de vixilancia. E aquí xa hai un cadro de mandos decente. Hai información sobre as conexións arriba. Conexión DB - 8 pezas. E é todo. Non temos información sobre que clientes están activos, que clientes están sen facer nada. Non hai información sobre transaccións pendentes e conexións pendentes, é dicir, esta é unha cifra que mostra o número de conexións e xa está. E despois adiviña por ti mesmo.

En consecuencia, para engadir esta información á supervisión, cómpre acceder á vista do sistema pg_stat_activity. Se pasas moito tempo en PostgreSQL, esta é unha vista moi boa que debería converterse no teu amigo, porque mostra a actividade actual en PostgreSQL, é dicir, o que está a suceder nel. Para cada proceso hai unha liña separada que amosa información sobre este proceso: desde que host se fixo a conexión, con que usuario, con que nome, cando se iniciou a transacción, que solicitude se está a executar actualmente, que solicitude se executou por última vez. E, en consecuencia, podemos avaliar o estado do cliente usando o campo stat. En termos relativos, podemos agrupar por este campo e obter aquelas estatísticas que están actualmente na base de datos e o número de conexións que teñen esta estatística na base de datos. E podemos enviar os números xa recibidos ao noso seguimento e debuxar gráficos en función deles.
Tamén é importante avaliar a duración da transacción. Xa dixen que é importante avaliar a duración dos baleiros, pero as transaccións avalíanse do mesmo xeito. Hai campos xact_start e query_start. Eles, relativamente falando, mostran a hora de inicio da transacción e a hora de inicio da solicitude. Tomamos a función now(), que mostra a marca de tempo actual, e restamos a marca de tempo da transacción e da solicitude. E obtemos a duración da transacción, a duración da solicitude.

Se vemos transaccións longas, xa deberíamos completalas. Para unha carga OLTP, as transaccións longas xa son máis de 1-2-3 minutos. Para unha carga de traballo OLAP, as transaccións longas son normais, pero se tardan máis de dúas horas en completarse, isto tamén é un sinal de que temos un sesgo nalgún lugar.

Unha vez que os clientes se conectaron á base de datos, comezan a traballar cos nosos datos. Acceden a táboas, acceden a índices para obter datos da táboa. E é importante avaliar como interactúan os clientes con estes datos.

Isto é necesario para avaliar a nosa carga de traballo e comprender de forma aproximada cales son as táboas máis "quentes" para nós. Por exemplo, isto é necesario nas situacións nas que queremos colocar táboas "quentes" nalgún tipo de almacenamento SSD rápido. Por exemplo, algunhas táboas de arquivo que non usamos durante moito tempo pódense mover a algún tipo de arquivo "frío", a unidades SATA e deixalas vivir alí, accederase a elas segundo sexa necesario.

Isto tamén é útil para detectar anomalías despois de calquera lanzamento e despregamento. Digamos que o proxecto lanzou algunha función nova. Por exemplo, engadimos unha nova funcionalidade para traballar coa base de datos. E se trazamos gráficos de uso das táboas, podemos detectar facilmente estas anomalías nestes gráficos. Por exemplo, actualizar ráfagas ou eliminar ráfagas. Será moi visible.

Tamén pode detectar anomalías nas estatísticas "flotantes". Qué significa? PostgreSQL ten un programador de consultas moi forte e moi bo. E os desenvolvedores dedican moito tempo ao seu desenvolvemento. Como traballa? Para facer bos plans, PostgreSQL recolle estatísticas sobre a distribución de datos en táboas nun determinado intervalo de tempo e cunha determinada frecuencia. Estes son os valores máis comúns: o número de valores únicos, información sobre NULL na táboa, moita información.

En base a estas estatísticas, o planificador constrúe varias consultas, selecciona a máis óptima e usa este plan de consultas para executar a propia consulta e devolver datos.

E ocorre que as estatísticas "flotan". Os datos de calidade e cantidade cambiaron dalgún xeito na táboa, pero non se recolleron as estatísticas. E os plans formados poden non ser óptimos. E se os nosos plans resultan infraóptimos en función do seguimento recollido, a partir das táboas, poderemos ver estas anomalías. Por exemplo, nalgún lugar os datos cambiaron cualitativamente e no canto do índice, comezouse a utilizar un paso secuencial pola táboa, é dicir. se unha consulta precisa devolver só 100 filas (hai un límite de 100), entón realizarase unha busca completa para esta consulta. E isto sempre ten un efecto moi malo no rendemento.

E iso podemos ver no seguimento. E xa mira esta consulta, executa unha explicación para ela, recolle estatísticas, crea un novo índice adicional. E xa responde a este problema. Por iso é importante.

Outro exemplo de vixilancia. Creo que moita xente o recoñeceu porque é moi popular. Quen o utiliza nos seus proxectos Prometeu? Quen usa este produto en conxunto con Prometheus? O caso é que no repositorio estándar deste seguimento hai un panel para traballar con PostgreSQL - postgres_exporter Prometeo. Pero hai un mal detalle.

Hai varios gráficos. E os bytes indícanse como unidade, é dicir, hai 5 gráficos. Estes son Inserir datos, Actualizar datos, Eliminar datos, Obter datos e Devolver datos. A unidade de medida son bytes. Pero o caso é que as estatísticas en PostgreSQL devolven datos en tuplas (filas). E, en consecuencia, estes gráficos son unha moi boa forma de subestimar a súa carga de traballo varias veces, decenas de veces, porque unha tupla non é un byte, unha tupla é unha cadea, son moitos bytes e sempre é de lonxitude variable. É dicir, calcular a carga de traballo en bytes mediante tuplas é unha tarefa pouco realista ou moi difícil. Polo tanto, cando usa un panel de control ou un monitor integrado, sempre é importante entender que funciona correctamente e que lle devolve os datos avaliados correctamente.

Como obter estatísticas sobre estas táboas? Para este fin, PostgreSQL ten unha determinada familia de vistas. E a vista principal é pg_stat_user_tables. Táboas_usuarios: isto significa táboas creadas en nome do usuario. En cambio, hai vistas do sistema que son usadas polo propio PostgreSQL. E hai unha táboa de resumo Alltables, que inclúe tanto as de sistema como de usuario. Podes comezar por calquera deles que máis che guste.

Usando os campos anteriores pode estimar o número de insercións, actualizacións e eliminacións. O exemplo dun panel que usei utiliza estes campos para avaliar as características dunha carga de traballo. Polo tanto, tamén podemos construír sobre eles. Pero vale a pena lembrar que se trata de tuplas, non de bytes, polo que non podemos facelo só en bytes.

En base a estes datos, podemos construír as chamadas táboas TopN. Por exemplo, Top-5, Top-10. E podes rastrexar esas mesas quentes que se reciclan máis que outras. Por exemplo, 5 táboas "quentes" para a inserción. E usando estas táboas TopN avaliamos a nosa carga de traballo e podemos avaliar as ráfagas de carga de traballo despois de calquera lanzamento, actualización e implantación.

Tamén é importante avaliar o tamaño da táboa, porque ás veces os desenvolvedores lanzan unha nova función, e as nosas táboas comezan a aumentar nos seus grandes tamaños, porque decidiron engadir unha cantidade adicional de datos, pero non predixiron como isto sería. afectar o tamaño da base de datos. Estes casos tamén nos sorprenden.

E agora unha pequena pregunta para ti. Que pregunta xorde cando notas a carga no teu servidor de base de datos? Cal é a seguinte pregunta que tes?

Pero en realidade a pregunta xorde do seguinte xeito. Que solicitudes provoca a carga? É dicir, non é interesante mirar os procesos que son provocados pola carga. Está claro que se o host ten unha base de datos, entón a base de datos está a executarse alí e está claro que só se eliminarán as bases de datos. Se abrimos Top, veremos alí unha lista de procesos en PostgreSQL que están facendo algo. De arriba non quedará claro o que están a facer.

En consecuencia, cómpre atopar aquelas consultas que causan a maior carga, porque as consultas de axuste, por regra xeral, dan máis beneficios que axustar a configuración de PostgreSQL ou do sistema operativo, ou incluso axustar o hardware. Segundo a miña estimación, isto é aproximadamente do 80-85-90%. E isto faise moito máis rápido. É máis rápido corrixir unha solicitude que corrixir a configuración, programar un reinicio, especialmente se non se pode reiniciar a base de datos ou engadir hardware. É máis fácil reescribir a consulta nalgún lugar ou engadir un índice para obter un mellor resultado desta consulta.

En consecuencia, é necesario controlar as solicitudes e a súa adecuación. Poñamos outro exemplo de vixilancia. E aquí tamén parece haber un excelente seguimento. Hai información sobre a replicación, hai información sobre o rendemento, o bloqueo, o uso de recursos. Todo está ben, pero non hai información sobre as solicitudes. Non está claro que consultas se están a executar na nosa base de datos, canto tempo se están a executar, cantas son estas consultas. Sempre necesitamos ter esta información no noso seguimento.

E para obter esta información podemos usar o módulo pg_stat_statements. Con base nel, podes construír unha variedade de gráficos. Por exemplo, pode obter información sobre as consultas máis frecuentes, é dicir, sobre aquelas consultas que se executan con máis frecuencia. Si, despois dos despregamentos tamén é moi útil miralo e comprender se hai algún aumento das solicitudes.

Pode supervisar as consultas máis longas, é dicir, aquelas consultas que tardan máis en completarse. Corren no procesador, consumen E/S. Tamén podemos avaliar isto usando os campos total_time, mean_time, blk_write_time e blk_read_time.

Podemos avaliar e supervisar as solicitudes máis pesadas en canto ao uso de recursos, as que len desde o disco, que traballan con memoria ou, pola contra, crean algún tipo de carga de escritura.

Podemos avaliar as solicitudes máis xenerosas. Estas son as consultas que devolven un gran número de filas. Por exemplo, esta podería ser algunha solicitude na que esqueceron establecer un límite. E simplemente devolve o contido completo da táboa ou consulta a través das táboas consultadas.

E tamén pode supervisar consultas que usan ficheiros temporais ou táboas temporais.

E aínda temos procesos en segundo plano. Os procesos en segundo plano son principalmente puntos de control ou tamén se denominan puntos de control, estes son o baleiro automático e a replicación.

Outro exemplo de vixilancia. Hai unha pestana de mantemento á esquerda, vai a ela e espera ver algo útil. Pero aquí só está o momento da operación ao baleiro e da recollida de estatísticas, nada máis. Esta é unha información moi pobre, polo que sempre necesitamos ter información sobre como funcionan os procesos en segundo plano na nosa base de datos e se hai algún problema co seu traballo.

Cando miramos os puntos de control, debemos lembrar que os puntos de control eliminan as páxinas sucias da área de memoria fragmentada ao disco e, a continuación, crean un punto de control. E este punto de control pódese usar como lugar para a recuperación se PostgreSQL foi rescindido de súpeto nunha emerxencia.

En consecuencia, para limpar todas as páxinas "sucias" no disco, cómpre escribir unha certa cantidade. E, por regra xeral, en sistemas con grandes cantidades de memoria, isto é moito. E se facemos puntos de control con moita frecuencia nun intervalo curto, o rendemento do disco caerá de forma moi significativa. E as solicitudes dos clientes sufrirán a falta de recursos. Competirán polos recursos e carecerán de produtividade.

En consecuencia, mediante pg_stat_bgwriter usando os campos especificados podemos supervisar o número de puntos de control que se producen. E se temos moitos puntos de control durante un determinado período de tempo (en 10-15-20 minutos, en media hora), por exemplo, 3-4-5, entón isto xa pode ser un problema. E xa cómpre buscar na base de datos, buscar na configuración, o que provoca tanta abundancia de puntos de control. Quizais haxa algún tipo de gravación grande. Xa podemos avaliar a carga de traballo, porque xa engadimos gráficos de carga de traballo. Xa podemos axustar os parámetros do punto de control e asegurarnos de que non afecten moito o rendemento da consulta.

Vou volver ao baleiro automático de novo porque, como dixen, é algo que pode sumar facilmente o rendemento tanto do disco como da consulta, polo que sempre é importante estimar a cantidade de baleiro automático.

O número de traballadores do baleiro automático na base de datos é limitado. Por defecto, hai tres, polo que se sempre temos tres traballadores traballando na base de datos, isto significa que o noso autovacuum non está configurado, hai que aumentar os límites, revisar a configuración do autovacuum e entrar na configuración.
É importante avaliar que traballadores do baleiro temos. Ou foi lanzado dende o usuario, chegou o DBA e lanzou manualmente algún tipo de baleiro, e isto creou unha carga. Temos algún tipo de problema. Ou este é o número de baleiros que desenroscan o contador de transaccións. Para algunhas versións de PostgreSQL estes son baleiros moi pesados. E poden sumar facilmente o rendemento porque len toda a táboa, escanean todos os bloques desa táboa.

E, por suposto, a duración dos baleiros. Se temos aspiradores de longa duración que funcionan durante moito tempo, isto significa que volvemos a prestar atención á configuración do baleiro e quizais reconsiderar a súa configuración. Porque pode xurdir unha situación cando o baleiro funciona na mesa durante moito tempo (3-4 horas), pero durante o tempo que o baleiro estivo funcionando, unha gran cantidade de filas mortas logrou acumularse de novo na mesa. E en canto remate o baleiro, ten que aspirar de novo esta mesa. E chegamos a unha situación: un baleiro sen fin. E neste caso, o baleiro non fai fronte ao seu traballo e as táboas comezan a aumentar gradualmente de tamaño, aínda que o volume de datos útiles segue sendo o mesmo. Por iso, durante longos baleiros, miramos sempre a configuración e intentamos optimizala, pero ao mesmo tempo para que o rendemento das solicitudes dos clientes non se vexa afectado.

Hoxe en día non hai practicamente ningunha instalación de PostgreSQL que non teña replicación por streaming. A replicación é o proceso de mover datos dun mestre a unha réplica.

A replicación en PostgreSQL realízase mediante un rexistro de transaccións. O asistente xera un rexistro de transaccións. O rexistro de transaccións viaxa pola conexión de rede ata a réplica e, a continuación, reprodúcese na réplica. É sinxelo.

En consecuencia, a vista pg_stat_replication úsase para supervisar o atraso de replicación. Pero non todo é sinxelo con ela. Na versión 10, a vista sufriu varios cambios. En primeiro lugar, algúns campos foron renomeados. E engadíronse algúns campos. Na versión 10, apareceron campos que permiten estimar o atraso de replicación en segundos. É moi cómodo. Antes da versión 10, era posible estimar o atraso de replicación en bytes. Esta opción permanece na versión 10, é dicir, podes escoller o que che convén: estima o atraso en bytes ou estima o atraso en segundos. Moita xente fai as dúas cousas.

Pero, con todo, para avaliar o atraso de replicación, cómpre coñecer a posición do rexistro na transacción. E estas posicións do rexistro de transaccións están exactamente na vista pg_stat_replication. Relativamente falando, podemos tomar dous puntos no rexistro de transaccións usando a función pg_xlog_location_diff(). Calcula o delta entre eles e obtén o atraso de replicación en bytes. É moi cómodo e sinxelo.

Na versión 10, esta función foi renomeada a pg_wal_lsn_diff(). En xeral, en todas as funcións, vistas e utilidades onde apareceu a palabra "xlog", substituíuse polo valor "wal". Isto aplícase tanto ás vistas como ás funcións. Esta é tal innovación.

Ademais, na versión 10, engadíronse liñas que mostran especificamente o atraso. Estes son retraso de escritura, retraso de descarga, retraso de reprodución. É dicir, é importante controlar estas cousas. Se vemos que temos un atraso de replicación, entón necesitamos investigar por que apareceu, de onde veu e solucionar o problema.

Case todo está en orde coas métricas do sistema. Cando comeza calquera monitorización, comeza coas métricas do sistema. Esta é a disposición dos procesadores, memoria, intercambio, rede e disco. Non obstante, moitos parámetros non están alí por defecto.

Se todo está en orde co proceso de reciclaxe, entón hai problemas coa reciclaxe do disco. Como regra xeral, os desenvolvedores de seguimento engaden información sobre o rendemento. Pode estar en iops ou bytes. Pero esquécense da latencia e da utilización dos dispositivos de disco. Estes son parámetros máis importantes que nos permiten avaliar o que están cargados os nosos discos e o que son lentos. Se temos alta latencia, isto significa que hai algúns problemas cos discos. Se temos unha alta utilización, significa que os discos non están a facer fronte. Estas son mellores características que o rendemento.

Ademais, estas estatísticas tamén se poden obter a partir do sistema de ficheiros /proc, como se fai para os procesadores de reciclaxe. Non sei por que esta información non se engade ao seguimento. Pero, con todo, é importante ter isto no seu seguimento.

O mesmo aplícase ás interfaces de rede. Hai información sobre o rendemento da rede en paquetes, en bytes, pero non obstante non hai información sobre a latencia nin sobre a utilización, aínda que esta tamén é información útil.

Calquera seguimento ten inconvenientes. E non importa o tipo de seguimento que fagas, sempre non cumprirá algúns criterios. Pero, con todo, están a desenvolver, vanse engadindo novas funcións e cousas novas, así que escolle algo e remata.

E para rematar, sempre debes ter unha idea do que significan as estatísticas proporcionadas e de como podes usalas para resolver problemas.

E algúns puntos clave:

• Sempre debes supervisar a dispoñibilidade e ter paneis de control para que poidas avaliar rapidamente que todo está en orde coa base de datos.
• Sempre debes ter unha idea de que clientes están a traballar coa túa base de datos para eliminar os malos clientes e acabar con eles.
• É importante avaliar como estes clientes traballan cos datos. Debes ter unha idea sobre a túa carga de traballo.
• É importante avaliar como se forma esta carga de traballo, coa axuda de que consultas. Podes avaliar consultas, optimizalas, refactorizarlas, construír índices para elas. É moi importante.
• Os procesos en segundo plano poden afectar negativamente ás solicitudes dos clientes, polo que é importante supervisar que non estean utilizando demasiados recursos.
• As métricas do sistema permítenche facer plans para escalar e aumentar a capacidade dos teus servidores, polo que tamén é importante rastrexalos e avalialos.

Se estás interesado neste tema, podes seguir estas ligazóns.
http://bit.do/stats_collector - Esta é a documentación oficial do recollidor de estatísticas. Hai unha descrición de todas as vistas estatísticas e unha descrición de todos os campos. Podes lelos, entendelos e analizalos. E en base a eles, crea os teus gráficos e engádeos ao teu seguimento.

Exemplos de solicitudes:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Este é o noso repositorio corporativo e o meu. Conteñen consultas de exemplo. Non hai consultas da selección* da serie alí. Xa hai consultas preparadas con unións, utilizando funcións interesantes que permiten converter números brutos en valores lexibles e cómodos, é dicir, son bytes, tempo. Podes recollelos, miralos, analizalos, engadilos ao teu seguimento, construír o teu seguimento en función deles.

preguntas

Pregunta: Dixeches que non anunciarás marcas, pero aínda teño curiosidade: que tipo de paneis usas nos teus proxectos?
Resposta: varía. Ocorre que chegamos a un cliente e el xa ten o seu propio seguimento. E aconsellamos ao cliente sobre o que hai que engadir ao seu seguimento. A peor situación é con Zabbix. Porque non ten a capacidade de construír gráficos TopN. Nós mesmos usamos Okmeter, porque estivemos consultando con estes rapaces sobre o seguimento. Monitorizaron PostgreSQL en función das nosas especificacións técnicas. Estou escribindo o meu propio proxecto para mascotas, que recolle datos a través de Prometheus e os procesa grafana. A miña tarefa é crear o meu propio exportador en Prometheus e logo renderizar todo en Grafana.

Pregunta: Hai algún análogo de informes AWR ou... agregación? Sabes algo así?
Resposta: Si, sei o que é AWR, é unha cousa xenial. Nestes momentos hai unha variedade de bicicletas que implementan aproximadamente o seguinte modelo. Nalgún intervalo de tempo, algunhas liñas de base escríbense no mesmo PostgreSQL ou nun almacenamento separado. Podes buscalos en Google en Internet, están alí. Un dos desenvolvedores de tal cousa está sentado no foro sql.ru no fío de PostgreSQL. Podes collelo alí. Si, hai tales cousas, pódense usar. Ademais no seu pgCenter Tamén estou escribindo unha cousa que che permite facer o mesmo.

PS1 Se estás a usar postgres_exporter, que panel estás a usar? Hai varios deles. Xa están desfasados. Quizais a comunidade cree un modelo actualizado?

PS2 Eliminouse pganalyze porque é unha oferta propietaria de SaaS que se centra no seguimento do rendemento e suxestións de axustes automatizados.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Que monitorización postgresql autoaloxada (con panel) consideras o mellor?

• 30,0%Zabbix + adicións de Alexey Lesovsky ou zabbix 4.4 ou libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze é un SaaS propietario; non podo eliminalo1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

Votaron 10 usuarios. 26 usuarios abstivéronse.

Fonte: www.habr.com