有一些同學(xué)覺得監(jiān)控?zé)o非是針對CPU、內(nèi)存 、磁盤進(jìn)行一些簡單的監(jiān)控，其實(shí)不僅僅如此，監(jiān)控涵蓋了眾多知識(shí)的融合，能融會(huì)貫通PostgreSQL監(jiān)控的人，大概率是PostgreSQL高手。

POSTGRESQL的監(jiān)控除了對系統(tǒng)的CPU內(nèi)存磁盤等項(xiàng)目的監(jiān)控，更多是對數(shù)據(jù)庫的監(jiān)控，因此需要對數(shù)據(jù)庫的原理有一定的理解，或者對數(shù)據(jù)庫所操作的業(yè)務(wù)邏輯有一定的了解,才能將相關(guān)工作做好.

監(jiān)控的主要目的

1、在預(yù)訂的問題(閾值)發(fā)生時(shí)或某個(gè)預(yù)訂時(shí)間發(fā)生時(shí)，進(jìn)行報(bào)警

2、針對一段系統(tǒng)運(yùn)行歷史時(shí)期的某項(xiàng)值進(jìn)行跟蹤，對系統(tǒng)的未來進(jìn)行評估

3、通過監(jiān)控的值或收集到的信息，解決系統(tǒng)在運(yùn)行中發(fā)生的問題。

監(jiān)控的性價(jià)比問題，也就是監(jiān)控成本考量

1、監(jiān)控的參數(shù)不一定追求百分之百的精準(zhǔn)，需要與監(jiān)控目標(biāo)，占用資源等情況一起綜合考量

2、監(jiān)控和性能之間有著密切的聯(lián)系

3、獲得監(jiān)控參數(shù)的難度和復(fù)雜度，也決定了監(jiān)控的成本

以下是詳細(xì)說明：

1、提取數(shù)據(jù)是有間隔的,即使在間隔中提取到的數(shù)據(jù)是準(zhǔn)確的,但間隔的跨度，將影響整體數(shù)據(jù)的準(zhǔn)確性。過密影或者提取數(shù)據(jù)的方式復(fù)雜，將影響系統(tǒng)性能，間隔跨度過大又影響分析的準(zhǔn)確性。

2、獲取同一個(gè)數(shù)據(jù)庫性能的參數(shù), 可以選擇不同方法，難易程度、數(shù)據(jù)準(zhǔn)確性、系統(tǒng)耗能等因素都需要考量。有容易但不準(zhǔn)確的方法、也有難度大很準(zhǔn)確又十分消耗系統(tǒng)性能的方法。

3、獲取信息的目的各有不同，目標(biāo)不同，對監(jiān)控方式的選擇不同。是要形成一個(gè)系統(tǒng)的性能曲線圖,還是要進(jìn)行報(bào)警觸發(fā)，顯然對信息獲取的要求是完全不同的。

舉一個(gè)例子，想要獲得當(dāng)前的用戶連接數(shù)，方法有三：

三種方法都可以從某種角度獲得當(dāng)前的POSTGRESQL和用戶之間的連接數(shù), 哪種最適合？

如果要獲得最準(zhǔn)確的當(dāng)前與POSTGRESQL 的連接用戶數(shù)，應(yīng)該用方法3?？墒褂梅椒?，就需要獲得數(shù)據(jù)庫系統(tǒng)的用戶名密碼, 要建立和PG數(shù)據(jù)庫之間的連接, 還要考慮到如果其他的系統(tǒng)也在頻繁查詢pg_stat_activity，是否會(huì)影響PG系統(tǒng)的性能的問題?

方法1 雖然最不準(zhǔn)確, 但消耗資源最小、系統(tǒng)侵入性最小！ 如果僅僅是統(tǒng)計(jì)系統(tǒng)的連接數(shù), 1號(hào)的方式基本可以達(dá)到需求了。

實(shí)際上大家可以看到真正的用戶的連接只有5個(gè)。

監(jiān)控中信息獲得方式與目的通常有三種

1、通過日志進(jìn)行分析。對于系統(tǒng)的優(yōu)化和性能調(diào)優(yōu), 大部分的信息會(huì)來自于日志系統(tǒng)來進(jìn)行分析, 通過日志獲取是對系統(tǒng)侵入性最小,性能影響最小的方式, 缺點(diǎn)是不及時(shí)或者分析上比較困難。

2、通過查詢數(shù)據(jù)庫進(jìn)行相關(guān)數(shù)據(jù)的獲取。多來自需要準(zhǔn)確指標(biāo)的獲取,或與某些報(bào)警的參數(shù)閥值設(shè)定有關(guān). 通過查詢數(shù)據(jù)庫來進(jìn)行數(shù)據(jù)的獲取,對系統(tǒng)的侵入性大, 缺點(diǎn)是很可能會(huì)影響性能。

3、通過操作系統(tǒng)獲取?；旧显诒容^粗淺的系統(tǒng)性能參數(shù),并繪制出相關(guān)較底層的性能曲線。此方式對于系統(tǒng)的侵入性不大。

接下來我們就分別說說這三種方式。。。

1、通過日志進(jìn)行分析：

如果需要日志記錄信息，配置信息主要分為以下幾種

1、日志的格式

2、日志的輸出信息的標(biāo)準(zhǔn)

3、日志的位置,及日志的名字

4、廢棄日志的處理

POSTGRESQL本身日志提供的數(shù)據(jù)比較集中,并且相對的配置項(xiàng)也比較多

例如信息輸出的目的地, 收集是否打開還是關(guān)閉, 日志的存儲(chǔ)的目錄,日志數(shù)據(jù)的文件名格式,以及數(shù)據(jù)是否要進(jìn)行rotation等等。還有日志內(nèi)部的格式是什么, 這都與后面要如何分析日志有關(guān),有些日志分析軟件是要指定日志的格式.

5、日志需要記錄的信息

Checkpoints信息

Connection信息

Disconnection信息

Lock信息

臨時(shí)表在系統(tǒng)中的產(chǎn)生的信息

例如我們收集信息的錯(cuò)誤類型, 慢查詢?nèi)罩? checkpoint connection的一些信息,主機(jī)名,鎖信息 等等。

介紹個(gè)相關(guān)工具Pgbadger,Pgbadger是一個(gè)開源的分析POSTGRESQL日志的工具,通過這個(gè)工具可以對POSTGRESQL 日志進(jìn)行分析,Ppgbadger是通過perl語言撰寫的根據(jù)固定格式日志,來產(chǎn)生WEB 分析報(bào)告的一個(gè)開源的軟件。其中主要對連接, checkpoint 臨時(shí)文件, vacuum 以及鎖慢查詢等等進(jìn)行一個(gè)頁面展示,并進(jìn)行一些分析.

Postgresql 如何分析日志 -- Pgbadger

Postgresql 如何分析日志 -- Pgbadger

上圖的相關(guān)展示還是比較詳細(xì)的。還可以進(jìn)行二次開發(fā)將信息通過網(wǎng)站發(fā)布,方便查看。

通過日志可以分析更多的信息,這里就不再展開了, 另外我們其實(shí)是可以通過數(shù)據(jù)庫系統(tǒng)本身來獲取信息, 數(shù)據(jù)庫本身的提供的信息也分兩種。

1與數(shù)據(jù)庫底層有關(guān)的信息 ,也就是數(shù)據(jù)庫與系統(tǒng)有關(guān)的信息2與數(shù)據(jù)庫本身有關(guān)的信息, 這里PG中有一部分是pg_catalog schema 信息,其中包含了大量 與PG有關(guān)的信息。

2、通過語句獲取postgresql 信息：

SELECT'index hit rate' AS name,(sum(idx_blks_hit)) / nullif(sum(idx_blks_hit + idx_blks_read),0) AS ratioFROM pg_statio_user_indexesUNION ALLSELECT'table hit rate' AS name,sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read),0) AS ratioFROM pg_statio_user_tables;

這條語句獲取的信息, 有兩個(gè)點(diǎn) ：

1系統(tǒng)的內(nèi)存是否有短缺的可能。

2是否缺少索引。

pg_statio_user_indexes是一個(gè)視圖，其中包含了數(shù)據(jù)庫中的表中的index的讀取和命中的數(shù)字, 將這兩個(gè)數(shù)字進(jìn)行加工就可以得到一個(gè)比率,通過這個(gè)比率就可以, 下邊的是pg_statio_user_tables這里也是展示在內(nèi)存中獲取到信息和整體讀取數(shù)據(jù)的數(shù)字, 這兩個(gè)的比率也是可以展示表數(shù)據(jù)讀取 在內(nèi)存中HIT 的情況.

BLOAT膨脹這個(gè)詞在postgresql中是一個(gè)比較敏感的詞, 你的數(shù)據(jù)庫中的表的是否膨脹你是要清楚了,如果POSTGRESQL 中一個(gè)表任意膨脹.

1、會(huì)占據(jù)大量的數(shù)據(jù)庫存儲(chǔ)的空間

2、會(huì)影響對此表的數(shù)據(jù)查詢性能

所以表膨脹一直是對POSTGRESQL 的監(jiān)控中的一個(gè)要點(diǎn)

在執(zhí)行完腳本后,我們就可以觀察到bloat的比率 和膨脹占用的空間, 如果我們的可以將這些數(shù)據(jù),例如將一些關(guān)鍵表的數(shù)據(jù)進(jìn)行歷史留存,并且使用一些通過一些前端程序展示某些曲線, 就很容易發(fā)現(xiàn)潛在的問題,

例如經(jīng)常有大型的SQL 占用某些核心表, 導(dǎo)致無法進(jìn)行有效的 dead tuple 回收,造成某個(gè)表的 waste 空間一漲再漲

例如我們可以擴(kuò)展CREATE EXTENSION pgstattuple; 對 dead_tuple_count /tuple_count*100 來看一下當(dāng)前POSTGRESQL的 dead_typle_count的一個(gè)百分比, 也可以對這些關(guān)鍵的表設(shè)定一些警告,當(dāng)超過多少百分比后

我們就進(jìn)行相關(guān)的報(bào)警或觸發(fā)一些操作.

與其他的數(shù)據(jù)庫比較, POSTGRESQL 在buffer利用上的統(tǒng)計(jì)和展示是比較明確的,也是比較方便的, 上面的腳本我們使用POSTGRESQL的擴(kuò)展 pg_buffercache , 通過這個(gè)插件配合系統(tǒng)表,我們可以實(shí)時(shí)的查看postgresql在buffer hit 方面的狀態(tài), buffer hit 大致的意思就是在數(shù)據(jù)處理時(shí)，數(shù)據(jù)庫中的處理的數(shù)據(jù)在內(nèi)存中是否都能被命中, 如果這個(gè)命中比較低的情況下,說明我們的內(nèi)存短缺,或者我們有一些系統(tǒng)的實(shí)際SQL不合理的.就需要我們更深層次的分析了.

同時(shí)通過延伸, 對整體的buffer_percent進(jìn)行一個(gè)累計(jì),后就可以得到我們的內(nèi)存和數(shù)據(jù)之間的BUFFER HIT 的比率。

3、通過系統(tǒng)獲得監(jiān)控?cái)?shù)據(jù):

通過postgresql的命令pg_isready來判斷是否可以和POSTGRESQL數(shù)據(jù)庫進(jìn)行連接,并通過返回的數(shù)字來判斷釋放可以連接 還是不可以連接 0 可以連接 1 拒絕連接2 無響應(yīng)

大家可以注意到,與系統(tǒng)的狀態(tài), 簡單的信息的獲取可以通過 系統(tǒng)的命令 + 簡單的過濾 就可以了而詳細(xì)需要分析的以及歷史數(shù)據(jù)分析等等 大多是要通過其他的方式來進(jìn)行

圖中是通過PSQL 命令執(zhí)行簡單的SQL 語句獲得當(dāng)前PG的連接占總的運(yùn)行連接的比率, 所以大多數(shù)簡單的信息大部分都是要提供給圖形化或監(jiān)控報(bào)警的.

監(jiān)控誤區(qū)

誤區(qū)1、人家監(jiān)控哪里我就監(jiān)控哪里。例如某保險(xiǎn)公司的監(jiān)控參數(shù), 我直接拿來, 可能部分常規(guī)的監(jiān)控參數(shù)是可以通用的,但與特性有關(guān)的監(jiān)控指標(biāo)照搬就有點(diǎn)多此一舉了。業(yè)務(wù)量及業(yè)務(wù)內(nèi)容，業(yè)務(wù)需求都不同，照搬來的監(jiān)控，有些內(nèi)容即耗費(fèi)你的系統(tǒng)的性能,來提取無用的性能點(diǎn), 又耗費(fèi)你的精力,導(dǎo)致后期監(jiān)控疲勞.

誤區(qū)2、監(jiān)控的內(nèi)容要全。一個(gè)數(shù)據(jù)庫監(jiān)控的指標(biāo)可能有上百,甚至上千個(gè)。都要監(jiān)控,毫無重點(diǎn),最終出了事情,不知道哪個(gè)監(jiān)控點(diǎn)應(yīng)該被響應(yīng).

誤區(qū)3、監(jiān)控的閾值要低。越早報(bào)警越好。如果你的系統(tǒng)中你負(fù)責(zé)的數(shù)據(jù)庫只有幾個(gè),十幾個(gè)還好說,實(shí)際上如果你有上百個(gè)數(shù)據(jù)庫要負(fù)責(zé),這樣的做法,只能是狼來了,最終導(dǎo)致監(jiān)控沒人看，出了事情再后悔莫及。

誤區(qū)4、監(jiān)控軟件越新越好。監(jiān)控本身就是獲取監(jiān)控端的數(shù)據(jù)為基礎(chǔ)的, 新的監(jiān)控軟件是否在這方面有更改革新, 如果僅僅是展示方式或者其他附屬功能上的提升,應(yīng)考慮升級(jí)的花費(fèi)以及相關(guān)精力的付出。

監(jiān)控原理

1復(fù)制的服務(wù)是否持續(xù)的進(jìn)行 2復(fù)制是否有延遲

一個(gè)問題： 如果邏輯復(fù)制停止了, 我們要不要當(dāng)做一個(gè)緊急的任務(wù)來報(bào)警？如果我們不考慮業(yè)務(wù),或者說如果復(fù)制停止了, 業(yè)務(wù)在一定時(shí)間是可以承受的,或不是很在乎這里就要介入到PG的數(shù)據(jù)庫的原理, 如果邏輯復(fù)制停止了, 則會(huì)最終導(dǎo)致主庫的wal無法被清除, 占滿磁盤空間, 最終導(dǎo)致主庫停庫的問題, 說到這里如果此時(shí)有邏輯復(fù)制的PG ,我們并未監(jiān)控邏輯復(fù)制是否中斷后立即報(bào)警, 但這臺(tái)機(jī)器的WALLOG 磁盤空間報(bào)警了, 可能第一就會(huì)想看邏輯復(fù)制是否還正常那么就會(huì)繼續(xù)這個(gè)問題問, 如果是standby的庫不穩(wěn)定, 經(jīng)常DOWN 掉, 那針對邏輯復(fù)制, 如果我設(shè)置了報(bào)警, 怎么辦, 經(jīng)常性的報(bào)警那就需要

1 增大WAL LOG 的空間, 設(shè)置相關(guān)的邏輯復(fù)制停止后的 多長時(shí)間進(jìn)行報(bào)警 比如 5分鐘以后報(bào)警還是 1分鐘以后報(bào)警 這都要看 standby經(jīng)常多長時(shí)間內(nèi)恢復(fù),并正常工作.

在知道監(jiān)控什么, 并且知道一些如果logical replication 停止后會(huì)觸發(fā)什么的情況下, 你可能會(huì)選擇 ,當(dāng)邏輯復(fù)制停止后,選擇報(bào)警,并開始關(guān)注磁盤空間尤其是涉及 wal log 的那部分,但事情并沒有到此為止, 如果你的客戶告訴你, 經(jīng)常獲取的的數(shù)據(jù)和主庫有不同的時(shí)候,怎么來解決,通過pg_stat_replication對你所在的通道中的sent_lsn write_lsn flush_lsn replay_lsn 這四個(gè)參數(shù)進(jìn)行比對

通過對比這四個(gè)參數(shù)的的diff 就可以得出幾種情況

1sent_lsn和write_lsn之間有延遲

2write_lsn和flush_lsn之間有延遲

3replya_lsn和flush_lsn有延遲

4sent_lsn和replay_lsn之間有沒有延遲

Sent_lsn和write_lsn之間有延遲是不是網(wǎng)絡(luò)方面有問題, 可以著重關(guān)注

Write_lsn和flush_lsn之間有延遲查看I/O 方面的壓力大不大

Replay_lsn和flush之間有延遲,可以關(guān)注是否經(jīng)常有批操作或大事務(wù)的存在

Sent_lsn和 replay之間沒有延遲說明復(fù)制正常性能OK

總結(jié)一個(gè)相關(guān)的PG 數(shù)據(jù)庫或者說是數(shù)據(jù)庫監(jiān)控方面的一個(gè)思維導(dǎo)圖:

分別從監(jiān)控的模式,監(jiān)控的目的,監(jiān)控的方式以及監(jiān)控與性能之間的關(guān)系進(jìn)行了一個(gè)初步的總結(jié).

最后，介紹幾種PG 監(jiān)控的工具：

?PG_ADMIN

?Solarwinds

?Pganalyze

?PGWATCH

?PMM2

?PGHERO

?PGCLUU

?PGBADGER

?PGTOP

以上內(nèi)容有對應(yīng)視頻授課內(nèi)容，請近期關(guān)注，我剪輯完就上傳。

以上內(nèi)容由東方瑞通資深講師 Austin原創(chuàng)，Austin老師13年專業(yè)DBA經(jīng)驗(yàn)，曾任互聯(lián)網(wǎng)金融公司Senior DBA、500強(qiáng)制藥企業(yè)Senior DBA，精通Mysql、PostgreSQL、Mongo DB、SQLServer

#PostgreSQL#

總結(jié)

以上是生活随笔為你收集整理的postgresql参数化查询_一个能融会贯通PostgreSQL监控的人，大概率是高手的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。