[レポート]PostgreSQLの監視運用を楽にするツールのご紹介 ～ pg_monz と fluentd ～ in OSC2015 Hokkaido #osc15do

こんにちは、せーのです。今日は昨日、今日と2日間にわたって行われている「Open Source Confference」の北海道版、「OSC Hokkaido 2015」よりPostgreSQLで監視運用を行う際のツールを速報としてレポート致します。スピーカーはTIS OSS推進室の中西 剛紀氏。

レポート

今回の動作確認

• PostgreSQL9.4.3
• Zabbix 2.4.5
• Fluentd 0.12.7
• CentOS 6.6

データベースの運用管理

• 目的は「DBの状態を把握して健全な状態に保つ」ため
• 種類
• 死活監視
• リソース監視
• 性能監視/分析/チューニング
• バックアップ/リストア

• 監視が運用管理の基本なので、正しく現状を把握する

POstgreSQL標準機能を使った運用

監視に使うPostgreSQLの機能

稼働統計情報

• 内部のアクティビティ情報を蓄積
• stats_collectorというプロセスが記録している
• ユーザーはビューを通して参照が可能となる
• pg_stat_activity, pg_stat_database, pg_stat_user_tablesが代表的な可動統計情報用のビュー

稼働統計情報の難点

• SQLを書くのがダルい。取得したい情報をどういうSQLを書けば取れるのか、という
• サーバーを起動してからの累積値が溜まっているので障害を最新の値だけでは判断できない。過去の値と比べないと

pg_monzを使ったPostgreSQLの監視

Zacbbixとpg_monzを使って楽にする

• 正式名称はPostgreSQL monitorning template for Zabbix
• 入手先　- http://pg-monz.github.io/pg_monz/
• ZabbixにPostgreSQLの監視機能を追加するテンプレート&スクリプト
• 2015/04にver.2.0リリース

pg_monzでできること

PostgreSQLサーバーの監視

• 死活状況、接続数、接続状態、トランザクション量、ログのエラーメッセージ、チェックポイントの実行状況

データベース状況の監視

• 容量とゴミの領域の回収率（VACUUMの状況）、DBの稼働状況の確認

アップデートしたところ

クラスタの監視

• ストリーミングレプリケーションの監視。どのサーバーがプライマリでどれがスタンバイなのかは意外とわかりにくい。pg_monzで可視化出来る。
• プライマリ障害のフェイルオーバー発生の様子をイベントとして通知
• スタンバイえのデータ転送の遅延状況
• 同期レプリケーションのプライオリティ

pgpool_IIの状態監視

• フロント/バックエンドの接続数
• pgpoolから見たバックエンドの稼働状況
• クエリキャッシュ使用時のキャッシュ状況
• watchdog構成での仮想IP保持状況
• クラスタとしてのサービス状態。「クラスタ全体としてみた時にサービスを提供できていない」といった不整合が起きていないか監視する。
• Activeなpgpoolが2つ存在したりすると異常なので、そういう状態になっていないか監視する
• ストリーミングレプリケーションのプライマリが複数ないか監視
• 同期レプリケーションのスタンバイサーバーが全てダウンしていると更新が不可能になるので検知する。
• サーバー単体の監視では気づきにくいクラスタ特有の障害を監視

pg_monzの仕組み

• PogtreSQLにZabbixのAgentとSenderを入れスクリプト(user-local-bin/*)を実行、Zabbix側にPostgrteSQL用のテンプレート(Template_App_PostgreSQL)を入れておく。そのテンプレートからモニター要求をPostgreSQLに出して、結果を受け取る。

pg_monzの特徴

• Zabbix標準機能を活用している。特別なモジュールが要らない
• 環境に合わせて監視設定を自動で作成(Zabbixローレベルディスカバリ機能を活用)。DBが増えたタイミングで自動的にZabbixが監視設定をいれこんでくれる

ログ

ログからわかること

• 異常が発生した際に深刻なレベル（PANIC,FATAL）から影響ないもの(INFO)までわかる
• スロークエリ、監査目的で全てのSQLを出力することも可能

ログの難点

• 古いログのメンテ機能がない。ローテーションは可能だがクリーンアップ機能はない。
• 障害メッセージ出現時にログを出すだけで警告してくれるわけではない。別途監視ツールが必要
• ログをルーティングする機能がない。全てのログが一つのログファイルに吐き出されるため、ログから見たい情報を探すのが面倒

pg_monzでのログ監視

• 深刻なエラーレベルのログを検知して深刻を出すことは出来る
• Zabbixの制限として細かいログ監視はやりずらい（正規表現で書けるところまで）。
• 検出した後色々な用途に使いづらい

PostgreSQLログを活用

ログにしか出せない情報を性能分析/チューニング用途で有効に使いたい。 - スロークエリ - チェックポイントの実行時間 - デッドロックの発生状況 - ロック待ちの発生状況 - 一時ファイルの生成情報

Fluentdを使ったPostgreSQLのログ監視

Fluentdとは

• 軽量でプラガブルなログ収拾ツール
• 用途に応じたプラグインを組み合わせて使う

tail Input Plugin

• 生のCSVログをぱーすしてJSON形式に編j校

fluent-plugin-rewrite-tag-filter

• ログの種類に応じてタグを分別、付け替える。

fluent-polugin-parser

• スロークエリログにかます
• 処理時間とSQLを分解して要素として最後につける

fulent-plugin-record_reformer

• ホスト名を付与する

fluent-plugin-pgjson

• ログ集約側でデータをJSON型のカラムを利用してPostgreSQLのテーブルに格納する tag,time,record(Jsonb型)

PostgreSQLのJSON

-9.4ではJSON型、jsonb型が選択可 - スキーマレスなデータの格納先に使える - JSONのいち部分だけを更新できない。ログの蓄積は代表的なユースケースとなる

qiitaに構築手順をアップしました。

まとめ

いかがでしたでしょうか。fluentdは私もログ収拾でよく使うツールです。pg_monzがちょっと気になりますね。一度触ってみたいと思いました。