我建議你閱讀 Data Egret 的 Alexey Lesovsky 的報告《PostgreSQL 監控基礎》的文字記錄
在本報告中，Alexey Lesovsky 將討論會後統計數據的要點、它們的含義以及為什麼它們應該出現在監測中； 關於監控中應包含哪些圖表、如何添加它們以及如何解釋它們。 該報告對於資料庫管理員、系統管理員和對 Postgres 故障排除感興趣的開發人員非常有用。
我叫 Alexey Lesovsky，我代表 Data Egret 公司。
關於我自己的幾句話。 很久以前，我就開始擔任系統管理員。
我管理各種不同的 Linux 系統，從事與 Linux 相關的各種工作，即虛擬化、監控、使用代理等。但在某個時候，我開始更多地使用資料庫、PostgreSQL。 我真的很喜歡他。 從某個時候起，我開始將大部分工作時間都花在 PostgreSQL 上。 就這樣我逐漸成為了 PostgreSQL DBA。
在我的職業生涯中，我一直對統計、監控和遙測等主題感興趣。 當我擔任系統管理員時，我與 Zabbix 密切合作。 我寫了一小組腳本，例如 。 他在他那個時代很受歡迎。 在那裡可以監視非常不同的重要事物，不僅是 Linux，還包括各種組件。
現在我正在研究 PostgreSQL。 我已經在寫另一篇文章，讓你可以使用 PostgreSQL 統計資料。 它被稱為 （關於哈布雷的文章 - ).
一點介紹性的說明。 我們的客戶、我們的客戶有什麼狀況？ 存在某種與資料庫相關的事故。 當資料庫已經恢復後，部門主管或開發主管過來說道：“朋友們，我們需要監控資料庫，因為發生了一些不好的事情，我們需要防止這種情況再次發生。” 這裡開始了選擇監控系統或調整現有監控系統的有趣過程，以便您可以監控您的資料庫 - PostgreSQL、MySQL 或其他資料庫。 同事開始建議：「聽說有這樣那樣的資料庫。 我們就用它吧。” 同事們開始互相爭論。 最後發現我們選擇了某種資料庫，但其中的 PostgreSQL 監控表現得相當差，我們總是需要增加一些東西。 從 GitHub 取得一些儲存庫，克隆它們，調整腳本，並以某種方式自訂它們。 最終它變成了某種手工工作。
因此，在本次演講中，我將嘗試為您提供一些有關如何選擇監控的知識，不僅適用於 PostgreSQL，也適用於資料庫。 並為您提供知識，使您能夠完成您的監控，以便從中獲得一些好處，以便您可以受益地監控您的資料庫，以便及時預防任何即將發生的緊急情況。
本報告中的想法可以直接適用於任何資料庫，無論是 DBMS 還是 noSQL。 因此，不僅有 PostgreSQL，而且還會有許多關於如何在 PostgreSQL 中做到這一點的食譜。 將會有查詢範例、PostgreSQL 用於監控的實體範例。 如果您的 DBMS 具有相同的功能，可讓您將它們置於監控中，那麼您也可以調整它們，添加它們，那就太好了。
我不會出現在報告中
討論如何交付和儲存指標。 我不會說任何關於數據後處理並將其呈現給用戶的事情。 我不會說任何關於警報的事情。
但隨著故事的進展，我會展示現有監控的不同截圖，並以某種方式批評它們。 但儘管如此，我會盡量不提及品牌，以免為這些產品製造廣告或反廣告。 因此，一切巧合都是隨機的，留給你想像。
首先我們先來了解什麼是監控。 監控是一件非常重要的事。 每個人都明白這一點。 但同時，監控與業務產品無關，不會直接影響公司的利潤，因此始終將時間分配給剩餘的監控。 如果我們有時間，那麼我們會進行監控；如果我們沒有時間，那麼好吧，我們會將其放入待辦事項中，有一天我們會返回這些任務。
因此，從我們的實踐來看，當我們來到客戶那裡時，監控往往是不完整的，沒有任何有趣的東西可以幫助我們更好地處理資料庫。 因此監控始終需要完成。
資料庫是如此複雜，也需要監控，因為資料庫是資訊儲存庫。 資訊對公司來說非常重要；它不能以任何方式丟失。 但同時，資料庫是非常複雜的軟體。 它們由大量組件組成。 其中許多組件都需要監控。
如果我們具體談論 PostgreSQL，那麼它可以以由大量元件組成的方案的形式表示。 這些組件相互作用。 同時，PostgreSQL還有所謂的Stats Collector子系統，它允許您收集有關這些子系統運行情況的統計數據，並為管理員或用戶提供某種接口，以便他可以查看這些統計數據。
這些統計數據以一組特定的函數和視圖的形式呈現。 它們也可以稱為表格。 也就是說，使用常規的 psql 客戶端，您可以連接到資料庫，對這些函數和視圖進行選擇，並取得有關 PostgreSQL 子系統操作的一些具體數字。
您可以將這些數字添加到您最喜歡的監控系統中、繪製圖表、添加功能並獲得長期分析。
但在本報告中，我不會完整介紹所有這些功能，因為這可能需要一整天的時間。 我將逐字討論兩、三或四件事，並告訴您它們如何幫助更好地進行監控。
如果我們談論資料庫監控，那麼需要監控什麼？ 首先，我們需要監視可用性，因為資料庫是一種向客戶端提供資料存取的服務，我們需要監視可用性，並提供其一些定性和定量特徵。
我們還需要監視連接到資料庫的客戶端，因為它們既可以是正常客戶端，也可以是可能損害資料庫的有害客戶端。 他們還需要受到監控並追蹤他們的活動。
當客戶端連接到資料庫時，很明顯地它們開始使用我們的數據，因此我們需要監視客戶端如何使用數據：使用哪些表，以及在較小程度上使用哪些索引。 也就是說，我們需要評估客戶所建立的工作負載。
但工作量當然也包括請求。 應用程式連接到資料庫，使用查詢存取數據，因此評估資料庫中的查詢、監控它們的充分性、確保它們沒有被歪曲編寫、需要重寫和製定一些選項以便它們運行得更快非常重要並且具有更好的性能。
由於我們談論的是資料庫，因此資料庫始終是後台進程。 後台進程有助於將資料庫效能維持在良好的水平，因此它們本身需要一定的資源來運作。 同時，它們可以與客戶端請求資源重疊，因此貪婪的後台程序可以直接影響客戶端請求的效能。 因此，還需要對它們進行監視和跟踪，以便後台進程不會出現扭曲。
而資料庫監控方面的所有這些仍然保留在系統指標中。 但考慮到我們的大部分基礎設施正在遷移到雲端，單一主機的系統指標總是淡出背景。 但在資料庫中它們仍然相關，當然，也有必要監控系統指標。
系統指標的一切或多或少都很好，所有現代監控系統都已經支援這些指標，但總的來說，一些組件仍然不夠，需要添加一些東西。 我也會談到它們，會有幾張關於它們的幻燈片。
該計劃的第一點是可及性。 什麼是可及性？ 我理解的可用性是基礎服務連結的能力，即基礎被提升，它作為服務接受來自客戶端的連結。 這種可訪問性可以透過某些特徵來評估。 在儀表板上顯示這些特徵非常方便。
大家都知道什麼是儀表板。 這是當您看一眼總結了必要資訊的螢幕時。 並且可以立即判斷資料庫是否有問題。
因此，資料庫的可用性和其他關鍵特徵應始終顯示在儀表板上，以便您隨時掌握這些資訊。 一些額外的細節已經有助於事件調查，在調查某些緊急情況時，它們已經需要放置在輔助儀表板上，或隱藏在通往第三方監控系統的深入連結中。
一個眾所周知的監控系統的範例。 這是一個非常酷的監控系統。 她收集了大量數據，但從我的角度來看，她對儀表板有一個奇怪的概念。 有一個“創建儀表板”的連結。 但是，當您建立儀表板時，您會建立一個包含兩列的列表，即一個圖表列表。 當您需要查看某些內容時，您可以開始用滑鼠點擊、捲動，尋找所需的圖表。 這需要時間，即沒有儀表板本身。 只有圖表列表。
您應該在這些儀表板中添加什麼？ 您可以從反應時間等特徵開始。 PostgreSQL 有 pg_stat_statements 視圖。 預設情況下它是禁用的，但它是應始終啟用和使用的重要係統視圖之一。 它儲存有關資料庫中已執行的所有正在運行的查詢的資訊。
因此，我們可以從以下事實開始：我們可以使用上述欄位將所有請求的總執行時間除以請求數。 但這是醫院的平均溫度。 我們可以從其他欄位開始——最小查詢執行時間、最大值和中位數。 我們甚至可以建立百分位數；PostgreSQL 有對應的函數。 我們可以得到一些數字來表徵資料庫對已完成請求的回應時間，即我們不執行假請求「select 1」並查看回應時間，但我們分析已完成請求的回應時間並繪製要么是一個單獨的圖，要么我們基於它建立一個圖表。
監控系統目前產生的錯誤數量也很重要。 為此，您可以使用 pg_stat_database 視圖。 我們重點關注 xact_rollback 欄位。 此欄位不僅顯示資料庫中發生的回溯次數，還考慮了錯誤次數。 相對而言，我們可以在儀表板中顯示這個數字，看看我們目前有多少錯誤。 如果有很多錯誤，那麼這是一個很好的理由來查看日誌，看看它們是什麼類型的錯誤以及它們發生的原因，然後投入並解決它們。
您可以添加轉速表之類的東西。 這些是每秒的交易數和每秒的請求數。 相對而言，您可以將這些數字作為資料庫目前的效能，並觀察是否存在請求峰值、交易峰值，或者相反，是否由於某些後端出現故障而導致資料庫負載不足。 重要的是要始終查看這個數字並記住，對於我們的專案來說，這種性能是正常的，但是上面和下面的值已經是某種有問題且難以理解的，這意味著我們需要看看為什麼這些數字是好高。
為了估計交易數量，我們可以再次參考pg_stat_database視圖。 我們可以將提交次數和回滾次數相加，得到每秒的交易數。
每個人都明白一筆交易可以容納多個要求嗎？ 因此TPS和QPS略有不同。
每秒的請求數可以從 pg_stat_statements 中取得，並簡單計算所有已完成請求的總和。 很明顯，我們將當前值與前一個值進行比較，減去它，得到增量，並得到數量。
如果需要，您可以新增其他指標，這也有助於評估我們資料庫的可用性並監控是否有任何停機時間。
這些指標之一是正常運作時間。 但 PostgreSQL 的正常運作時間有點棘手。 我會告訴你原因。 PostgreSQL 啟動後，正常運作時間開始報告。 但如果在某個時刻，例如晚上執行某個任務，出現 OOM-killer 強行終止 PostgreSQL 子進程，那麼在這種情況下 PostgreSQL 會終止所有客戶端的連接，重置分片記憶體區域並開始恢復最後一個檢查站。 雖然從檢查點的恢復持續，但資料庫不接受連接，即這種情況可以評估為停機。 但正常運行時間計數器不會重置，因為它從一開始就考慮了郵局管理員的啟動時間。 因此，此類情況可以跳過。
您還應該監控真空工人的數量。 大家知道PostgreSQL中的autovacuum是什麼嗎？ 這是 PostgreSQL 中一個有趣的子系統。 關於她的文章很多，報導也很多。 關於真空及其如何工作有很多討論。 許多人認為這是必要的罪。 但事實就是這樣。 這類似於垃圾收集器，可以清除任何交易不需要的行的過時版本，並為新行釋放表和索引中的空間。
為什麼需要監控它？ 因為真空有時會造成很大的傷害。 它消耗大量資源，並且客戶端請求開始受到影響。
並且應該透過 pg_stat_activity 視圖來監控，我將在下一節中討論。 此視圖顯示資料庫中的目前活動。 透過此活動，我們可以追蹤目前正在工作的吸塵器的數量。 我們可以追蹤 Vacuum 並查看是否超出了限制，那麼這就是研究 PostgreSQL 設定並以某種方式優化 Vacuum 操作的原因。
關於 PostgreSQL 的另一件事是 PostgreSQL 非常厭倦長事務。 尤其是那些長時間徘徊且不執行任何操作的交易。 這就是所謂的statididle-in-transaction。 這樣的事務會持有鎖並阻止真空工作。 結果，桌子膨脹並增大。 使用這些表的查詢開始運行速度變慢，因為您需要將所有舊版本的行從記憶體移至磁碟並移回。 因此，時間、最長事務的持續時間、最長的真空請求也需要監控。 如果我們看到一些進程已經運行了很長時間，對於OLTP負載來說已經超過10-20-30分鐘，那麼我們需要關注它們並強制終止它們，或者優化應用程式以便它們不會被調用，也不會掛那麼久。 對於分析工作負載，10-20-30 分鐘是正常的；也有更長的時間。
接下來我們可以選擇連線客戶端。 當我們已經建立了儀表板並在其上發布了關鍵可用性指標時，我們還可以在其中添加有關已連接客戶端的其他資訊。
有關已連接客戶端的資訊很重要，因為從 PostgreSQL 的角度來看，客戶端是不同的。 有好的客戶，也有壞的客戶。
一個簡單的例子。 透過客戶我了解該應用程式。 應用程式已連接到資料庫並立即開始向資料庫發送請求，資料庫處理並執行它們，並將結果傳回給客戶端。 這些都是好的、正確的客戶。
在某些情況下，客戶端已連接，它保持連接，但不執行任何操作。 它處於空閒狀態。
但也有不好的客戶。 例如，同一個客戶端連線、開啟交易、在資料庫中執行某些操作，然後進入程式碼，例如存取外部來源或處理接收到的資料。 但他並沒有完成交易。 並且事務掛在資料庫中並在線上被鎖定。 這是一個糟糕的狀況。 如果應用程式內部某個地方突然因異常而失敗，則交易可以在很長一段時間內保持開啟。 而這直接影響PostgreSQL的效能。 PostgreSQL 會更慢。 因此，及時追蹤此類客戶並強制終止其工作非常重要。 並且您需要優化您的應用程序，以免發生此類情況。
其他不良客戶正在等待客戶。 但他們會因為環境而變壞。 例如，一個簡單的空閒事務：它可以開啟一個事務，在某些行上鎖定，然後在程式碼中的某個地方它將失敗，留下一個掛起的事務。 另一個客戶端將請求相同的數據，但他將遇到鎖，因為該掛起的交易已經在某些所需的行上持有鎖。 第二個事務將等待第一個事務完成或被管理員強制關閉。 因此，掛起的交易可能會累積並填滿資料庫連線限制。 當限制已滿時，應用程式將無法再使用資料庫。 這已經是該專案的緊急情況。 因此，需要及時追蹤不良客戶並做出回應。
另一個監控的例子。 這裡已經有一個不錯的儀表板了。 上面有關於連接的資訊。 DB 連線 – 8 個。 僅此而已。 我們沒有關於哪些客戶端處於活動狀態、哪些客戶端處於閒置狀態、什麼都不做的資訊。 沒有有關待處理事務和待處理連接的信息，即，這是一個顯示連接數量的數字，僅此而已。 然後自己猜。
因此，要將這些資訊新增至監控中，您需要存取pg_stat_activity系統視圖。 如果您在 PostgreSQL 上花費了大量時間，那麼這是一個非常好的視圖，應該成為您的朋友，因為它顯示了 PostgreSQL 中當前的活動，即其中正在發生的事情。 對於每個進程，都有一個單獨的行顯示有關該進程的資訊：從哪個主機建立連接、在什麼用戶下、在什麼名稱下、事務何時啟動、當前正在運行什麼請求、上次執行什麼請求。 因此，我們可以使用 stat 欄位來評估客戶端的狀態。 相對而言，我們可以按此欄位進行分組，並取得資料庫中目前的統計資料以及資料庫中具有此統計資料的連接數。 我們可以將已經收到的數字發送到我們的監控並根據它們繪製圖表。
評估交易的持續時間也很重要。 我已經說過評估真空的持續時間很重要，但交易也以同樣的方式評估。 有 xact_start 和 query_start 欄位。 相對而言，它們顯示了事務的開始時間和請求的開始時間。 我們採用顯示目前時間戳記的 now() 函數，並減去事務和請求時間戳記。 我們得到交易的持續時間，請求的持續時間。
如果我們看到長交易，我們應該已經完成它們。 對於 OLTP 負載，長事務已超過 1-2-3 分鐘. 對於 OLAP 工作負載，長事務是正常的，但如果它們需要兩個多小時才能完成，那麼這也表明我們在某個地方存在偏差。
一旦客戶連接到資料庫，他們就開始使用我們的資料。 他們訪問表，訪問索引以從表中獲取資料。 評估客戶如何與這些數據互動非常重要。
為了評估我們的工作量並大致了解哪些表對我們來說“最熱門”，這是必要的。 例如，當我們想要將「熱」表放置在某種快速 SSD 儲存空間上時，就需要這樣做。 例如，一些我們很長時間沒有使用的歸檔表可以移動到某種“冷”歸檔，移動到SATA驅動器並讓它們住在那裡，它們將根據需要被訪問。
這對於在任何發布和部署後檢測異常也很有用。 假設該項目發布了一些新功能。 例如，我們新增了使用資料庫的新功能。 如果我們繪製表格使用情況圖表，我們可以輕鬆地偵測到這些圖表上的這些異常情況。 例如，更新突發或刪除突發。 它將非常明顯。
您也可以偵測「浮動」統計資料中的異常。 這是什麼意思？ PostgreSQL 有一個非常強大且非常好的查詢排程器。 並且開發人員投入了大量的時間來開發它。 他如何工作？ 為了做好計劃，PostgreSQL會以一定的時間間隔和一定的頻率來統計表中資料的分佈。 這些是最常見的值：唯一值的數量、表中有關 NULL 的資訊、大量資訊。
根據這些統計信息，規劃器建立多個查詢，選擇最優的一個，並使用該查詢計劃來執行查詢本身並傳回資料。
而且統計數據恰好「浮動」。 表中的質量和數量數據發生了某種變化，但沒有進行統計。 而且制定的計劃可能不是最佳的。 如果根據收集到的監控結果，根據表格，我們的計劃不是最理想的，我們將能夠看到這些異常情況。 例如，在某個地方資料發生了質的變化，開始使用順序遍歷表而不是索引，即如果一個查詢只需要傳回 100 行（限制為 100 行），那麼將為該查詢執行完整搜尋。 而這總是對性能產生非常糟糕的影響。
我們可以在監控中看到這一點。 並且已經查看了這個查詢，為其運行解釋，收集統計信息，構建一個新的附加索引。 並且已經對這個問題做出了回應。 這就是為什麼它很重要。
另一個監控的例子。 我想很多人認識他是因為他很受歡迎。 誰在他們的專案中使用它 ？ 誰將此產品與 Prometheus 結合使用？ 事實上，在這個監控的標準儲存庫中，有一個用於使用 PostgreSQL 的儀表板 - 普羅米修斯。 但有一個細節不好。
有幾個圖表。 位元組以單位表示，即有 5 個圖。 它們是插入資料、更新資料、刪除資料、獲取資料和返回資料。 測量單位是位元組。 但問題是 PostgreSQL 中的統計資料傳回元組（行）中的資料。 因此，這些圖是多次、數十次低估工作量的好方法，因為元組不是位元組，元組是字串，它有很多位元組並且總是可變長度。 也就是說，使用元組以位元組為單位計算工作負載是一項不切實際的任務或非常困難。 因此，當您使用儀表板或內建監控時，了解其正常工作並傳回正確評估的資料始終很重要。
如何取得這些表的統計資料？ 為此，PostgreSQL 有一系列特定的視圖。 主要觀點是 。 User_tables - 這表示代表使用者建立的表。 相比之下，PostgreSQL 本身使用一些系統視圖。 還有一個匯總表Alltables，其中包括系統表和用戶表。 您可以從您最喜歡的任何一個開始。
使用上述字段，您可以估計插入、更新和刪除的數量。 我使用的儀表板範例使用這些欄位來評估工作負載的特徵。 因此，我們也可以在它們的基礎上繼續發展。 但值得記住的是，這些是元組，而不是字節，所以我們不能只以位元組為單位。
基於這些數據，我們可以建立所謂的 TopN 表。 例如，前 5 名、前 10 名。 您可以追蹤那些比其他表回收更多的熱表。 例如，插入 5 個「熱門」表。 使用這些 TopN 表，我們可以評估我們的工作負載，並可以評估任何發布、更新和部署後的工作負載爆發。
評估表的大小也很重要，因為有時開發人員推出新功能，我們的表開始變得很大，因為他們決定添加額外的資料量，但沒有預測這會如何影響資料庫的大小。 這樣的案例也讓我們感到驚訝。
現在問你一個小問題。 當您注意到資料庫伺服器上的負載時，會出現什麼問題？ 您的下一個問題是什麼？
但實際上問題是這樣出現的。 負載會引起什麼請求？ 也就是說，查看由負載引起的進程並不有趣。 很明顯，如果主機有資料庫，那麼資料庫就在那裡運行，並且很明顯地只有資料庫會在那裡被處理。 如果我們打開 Top，我們將看到 PostgreSQL 中正在執行某些操作的進程清單。 Top 並不清楚他們在做什麼。
因此，您需要找到那些導致最高負載的查詢，因為調整查詢通常比調整 PostgreSQL 或作業系統配置，甚至調整硬體帶來更多的利潤。 據我估計，這個比例大約是80-85-90%。 而且這個過程完成得更快。 更正請求比更正配置、安排重新啟動（尤其是資料庫無法重新啟動）或新增硬體更快。 在某處重寫查詢或添加索引以從此查詢獲得更好的結果會更容易。
因此，有必要監控請求及其充分性。 我們再舉一個監控的例子。 這裡似乎也有出色的監控。 有關於複製的信息，有關於吞吐量、阻塞、資源利用率的信息。 一切都很好，但沒有關於請求的資訊。 目前尚不清楚我們的資料庫中正在運行哪些查詢、它們運行了多長時間以及這些查詢中有多少。 我們始終需要在監控中包含這些資訊。
要獲取此信息，我們可以使用 pg_stat_statements 模組。 基於它，您可以建立各種圖表。 例如，您可以獲得有關最頻繁查詢的信息，即有關執行最頻繁的查詢的信息。 是的，部署後查看它並了解請求是否激增也非常有用。
您可以監控最長的查詢，也就是那些花費最長時間才能完成的查詢。 它們在處理器上運行，消耗 I/O。 我們也可以使用欄位total_time、mean_time、blk_write_time 和blk_read_time 來評估這一點。
我們可以評估和監控資源使用方面最繁重的請求，即從磁碟讀取的請求、使用記憶體的請求，或相反，創建某種寫入負載的請求。
我們可以評估最慷慨的請求。 這些是傳回大量行的查詢。 例如，這可能是他們忘記設定限制的某些請求。 它只是返回表的全部內容或跨查詢表的查詢。
您也可以監視使用臨時檔案或臨時表的查詢。
而且我們仍然有後台進程。 後台進程主要是檢查點，或者也稱為檢查點，它們是自動清理和複製。
另一個監控的例子。 左側有一個“維護”選項卡，進入它並希望看到一些有用的東西。 但這裡只是真空操作和統計數據的時間，僅此而已。 這是非常糟糕的訊息，因此我們總是需要了解後台進程如何在我們的資料庫中運作以及它們的工作是否存在任何問題。
當我們查看檢查點時，我們應該記住檢查點將髒頁從分片記憶體區域刷新到磁碟，然後建立檢查點。 如果 PostgreSQL 在緊急情況下突然終止，這個檢查點可以用作復原位置。
因此，為了將所有「髒」頁刷新到磁碟，您需要進行一定量的寫入。 通常，在具有大量記憶體的系統上，這已經很多了。 如果我們在短時間內頻繁地創建檢查點，那麼磁碟效能將會顯著下降。 客戶端請求將因缺乏資源而受到影響。 他們會爭奪資源並缺乏生產力。
因此，透過 pg_stat_bgwriter 使用指定的字段，我們可以監視發生的檢查點的數量。 如果我們在一段時間內（10-15-20分鐘，半小時）有很多檢查點，例如3-4-5，那麼這可能已經是一個問題了。 您已經需要查看資料庫，查看配置，是什麼導致瞭如此豐富的檢查點。 也許正在進行某種大型錄音。 我們已經可以評估工作負載，因為我們已經新增了工作負載圖表。 我們已經可以調整檢查點參數並確保它們不會極大地影響查詢效能。
我再次回到 autovacuum，因為正如我所說，它可以輕鬆地增加磁碟和查詢效能，因此估計 autovacuum 的量始終很重要。
資料庫中 autovacuum 工作人員的數量是有限的。 預設情況下，有三個，所以如果我們總是有三個工作人員在資料庫中工作，這意味著我們的 autovacuum 沒有配置，我們需要提高限制，修改 autovacuum 設定並進入配置。
評估我們擁有哪些真空工人非常重要。 要么是由用戶啟動，要么是 DBA 來手動啟動某種真空，這會產生負載。 我們遇到了一些問題。 或者這是擰開交易櫃檯的真空吸塵器的次數。 對於某些版本的 PostgreSQL 來說，這是非常嚴重的真空。 他們可以輕鬆地增加效能，因為他們讀取整個表，掃描該表中的所有區塊。
當然，還有真空的持續時間。 如果我們有運行很長時間的長效吸塵器，那麼這意味著我們再次需要注意吸塵器的配置，並且可能需要重新考慮其設定。 因為當vacuum長時間（3-4小時）在表上工作時，可能會出現一種情況，但在vacuum工作期間，表中又再次累積了大量的死行。 一旦吸塵完成，他就需要再次吸塵這張桌子。 我們遇到了一種情況——無盡的真空。 在這種情況下，真空無法應對其工作，並且表的大小逐漸開始膨脹，儘管其中的有用資料量保持不變。 因此，在長時間的真空期間，我們總是查看配置並嘗試最佳化它，但同時確保客戶端請求的效能不會受到影響。
現在幾乎沒有 PostgreSQL 安裝不具備串流複製功能。 複製是將資料從主伺服器移動到副本的過程。
PostgreSQL 中的複製是透過交易日誌完成的。 此精靈會產生交易日誌。 交易日誌透過網路連線傳輸到副本，然後在副本上再現。 這很簡單。
因此，pg_stat_replication 視圖用於監視複製延遲。 但對她來說，一切並不簡單。 在版本 10 中，視圖發生了一些變化。 首先，一些字段已重新命名。 並且添加了一些字段。 在版本 10 中，出現了一些字段，可讓您以秒為單位估計複製延遲。 非常舒服。 在版本 10 之前，可以以位元組為單位估計複製延遲。 此選項保留在版本 10 中，即您可以選擇對您來說更方便的選項 - 以位元組為單位估計延遲或以秒為單位估計延遲。 很多人兩者都做。
但儘管如此，為了評估複製延遲，您需要知道日誌在交易中的位置。 而這些交易日誌位置正好在pg_stat_replication視圖中。 相對而言，我們可以使用 pg_xlog_location_diff() 函數在交易日誌中取得兩個點。 計算它們之間的增量並獲取複製延遲（以位元組為單位）。 非常方便、簡單。
在版本 10 中，函數被重新命名為 pg_wal_lsn_diff()。 一般來說，在所有出現「xlog」一詞的函數、視圖和實用程式中，它都會被值「wal」取代。 這適用於視圖和函數。 這是一個創新。
另外，在版本 10 中，新增了專門顯示滯後的行。 它們是寫入延遲、刷新延遲、重播延遲。 也就是說，監控這些事情很重要。 如果我們發現複製滯後，那麼我們需要調查它出現的原因、它來自哪裡並解決問題。
幾乎一切都符合系統指標。 當任何監控開始時，都會從系統指標開始。 這是處理器、記憶體、交換器、網路和磁碟的處置。 但是，許多參數預設情況下並不存在。
如果回收過程一切正常，那麼磁碟回收就會出現問題。 通常，監控開發人員會添加有關吞吐量的資訊。 它可以以 iops 或位元組為單位。 但他們忘記了磁碟設備的延遲和利用率。 這些是更重要的參數，使我們能夠評估磁碟的負載情況以及速度有多慢。 如果延遲很高，則表示磁碟存在一些問題。 如果利用率很高，則表示磁碟無法應對。 這些是比吞吐量更好的特性。
此外，這些統計資料也可以從 /proc 檔案系統中獲得，就像回收處理器一樣。 不知道為什麼這個訊息沒有加入監控中。 但儘管如此，將其納入監控中還是很重要的。
這同樣適用於網路介面。 有關於網路吞吐量（以資料包、位元組為單位）的信息，但是沒有關於延遲的信息，也沒有關於利用率的信息，儘管這也是有用的信息。
任何監控都有缺點。 而且無論你採取什麼樣的監控，它總是不符合某些標準。 但儘管如此，它們正在開發，正在添加新功能和新事物，所以選擇一些東西並完成它。
為了完成任務，您必須始終了解所提供的統計數據的含義以及如何使用它們來解決問題。
以及幾個關鍵點：
- 您應該始終監控可用性並擁有儀表板，以便您可以快速評估資料庫的一切是否正常。
- 您始終需要了解哪些客戶端正在使用您的資料庫，以便清除不良客戶端並將其擊落。
- 評估這些客戶如何處理數據非常重要。 您需要了解自己的工作量。
- 重要的是要在哪些查詢的幫助下評估此工作負載的形成方式。 您可以評估查詢，可以優化它們，重構它們，為它們建立索引。 這是非常重要的。
- 後台程序可能會對客戶端請求產生負面影響，因此監視它們是否使用太多資源非常重要。
- 系統指標可讓您制定擴展和增加伺服器容量的計劃，因此追蹤和評估它們也很重要。
如果您對這個主題感興趣，那麼您可以點擊這些連結。
- 這是統計收集器的官方文件。 有所有統計視圖的描述和所有欄位的描述。 您可以閱讀、理解和分析它們。 並基於它們建立您的圖表並將其添加到您的監控中。
請求範例：
這是我們的公司儲存庫，也是我自己的儲存庫。 它們包含範例查詢。 那裡沒有來自 select* from 系列的查詢。 已經有現成的帶有連接的查詢，使用有趣的函數，允許您將原始數字轉換為可讀的、方便的值，即這些是位元組、時間。 您可以拿起它們，查看它們，分析它們，將它們添加到您的監控中，並基於它們建立您的監控。
問題
Q：你說你不會為品牌做廣告，但我還是很好奇——你在專案中使用什麼樣的儀表板？
答：因人而異。 碰巧我們遇到一個客戶，他已經有了自己的監控。 我們會向客戶建議需要在監控中加入哪些內容。 最糟糕的情況是 Zabbix。 因為它不具備建構TopN圖的能力。 我們自己用 ，因為我們正在與這些人就監控問題進行協商。 他們根據我們的技術規格監控 PostgreSQL。 我正在編寫自己的寵物項目，它透過 Prometheus 收集數據並將其呈現在 。 我的任務是在 Prometheus 中創建我自己的匯出器，然後在 Grafana 中渲染所有內容。
問題：是否有 AWR 報告或...聚合的類似物？ 你知道這樣的事情嗎？
答：是的，我知道 AWR 是什麼，這是一件很酷的事。 目前有多種自行車大致採用以下型號。 在某個時間間隔，有些基準會寫入同一個 PostgreSQL 或單獨的儲存中。 你可以在互聯網上谷歌搜尋它們，它們就在那裡。 這種東西的開發者之一坐在 sql.ru 論壇的 PostgreSQL 線程中。 你可以在那裡抓住他。 是的，有這樣的東西，它們可以使用。 再加上其 我也在寫一個東西，讓你可以做同樣的事情。
PS1 如果您使用 postgres_exporter，您使用什麼儀表板？ 其中有好幾個。 它們已經過時了。 也許社群會創建一個更新的模板？
PS2 刪除了 pganalyze，因為它是一種專有的 SaaS 產品，專注於效能監控和自動調整建議。
只有註冊用戶才能參與調查。 ， 請。
您認為哪種自架 postgresql 監控（附儀表板）最好？
-
企業排放佔全球 30,0%Zabbix + 來自 Alexey Lesovsky 或 zabbix 4.4 或 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 是專有 SaaS - 我無法刪除它1
-
企業排放佔全球 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
10 位用戶投票。 26 名用戶棄權。
來源： www.habr.com