本質的にPostgreSQL固有ではないが、顧客のシステムの問題を調査したり、それらのシステムの「サポート性」を評価したりするときに定期的に遭遇するトピックについて説明します。システムメトリックの監視ソリューションを用意し、合理的に構成することが重要です。 、およびその理由sar まだ私のお気に入りのツールです（少なくともLinuxでは）。
監視の重要性について
まず、基本的なシステムメトリック（CPU、I / O、メモリ）の監視は非常に重要です。他のエンジニアとの話し合いでこれを指摘しなければならないのは少し奇妙ですが、エンジニアの10人に1人は実際に監視する必要はないと考えています。推論は通常、次のようになります。
本当の監視はオーバーヘッドを追加します、それについては間違いありません。ただし、アプリケーションが実行していることと比較すると、無視できる可能性があります。実際、sar 実際には追加のインストルメンテーションを追加するのではなく、単にnernelからカウンターを読み取り、デルタを計算してそれをディスクに書き込むだけです。ディスク容量とI/O（CPUとディスクの数によって異なります）が必要になる場合がありますが、それだけです。
たとえば、32コアと複数のディスクを備えたマシンで1秒あたりの統計を収集すると、1日あたり最大5 GBの生データが生成されますが、非常によく圧縮され、多くの場合、最大5〜10％になります。そして、それはtopではほとんど見えません 。 1秒あたりの解像度は少し極端であり、5秒または10秒を使用すると、オーバーヘッドがさらに削減されます。
したがって、いいえ、オーバーヘッドは実際には監視を有効にしない正当な理由ではないことがわかりました。
コストとメリット
さらに重要なのは、「監視を有効にしないことで、どのくらいのオーバーヘッドを排除できるか」ということです。質問するのは間違った質問です。代わりに、「モニタリングからどのようなメリットが得られますか？」と尋ねる必要があります。メリットはコストを上回りますか？」
コスト（オーバーヘッド）がかなり小さいか、完全に無視できることはすでにわかっています。メリットは何ですか？私の経験では、監視データを持つことは事実上非常に貴重です。
まず、問題を調査することができます。一連のグラフを見て、突然の変化を探すことは驚くほど効果的であり、多くの場合、適切な問題に直接つながります。同様に、現在のデータ（問題の間に収集されたもの）をベースライン（すべてが正常なときに収集されたもの）と比較することは非常に便利であり、問題が発生したときにのみ監視を有効にした場合は不可能です。
次に、実際に問題が発生する前に、傾向を評価して潜在的な問題を特定できます。どのくらいのCPUを使用していますか？ CPU使用率は時間の経過とともに増加していますか？メモリ使用量に疑わしいパターンはありますか？モニタリングを実施している場合にのみ、これらの質問に答えることができます。
なぜsar 私のお気に入りのツールです
監視が重要であり、必ず実行する必要があると私が確信したとしましょう。しかし、なぜsar オンプレミスとクラウドベースの両方で、さまざまな派手な選択肢がある場合、私たちのお気に入りのツールはありますか？
- すべてのディストリビューションに含まれているため、インストール/セットアップは簡単です。これにより、人々にそれを有効にするよう説得するのはかなり簡単になります。
- それはマシン上にあります。したがって、マシンにSSHで接続すると、監視データも取得できます。
- 単純なテキスト出力を使用しています。データを簡単に処理–データベースにインポートし、分析して、サポートチケットに添付します。これは、一般的にデータを簡単にエクスポートできない、グラフを表示する、実行できる分析を大幅に制限するなど、他のツールではかなり困難です。
私は他の会社にPostgreSQLサービスを提供している会社（24時間365日のサポートまたはリモートDBA）で働いているという事実から、これの一部を認めます。したがって、通常、顧客システム（ほとんどはデータベースサーバーのみ）へのアクセスは非常に限られています。つまり、データベースサーバー自体にすべての重要なデータを保持し、プレーンSSH経由でアクセスできることは非常に便利であり、他のシステムから別のデータを要求するためだけに不要なラウンドトリップを排除します。これにより、時間と健全性の両方が節約されます。両側に。
管理するシステムが多数ある場合は、多くのマシンから1か所にデータを収集する監視ソリューションをお勧めします。しかし、私にとっては、sar まだ勝ちます。
では、どのように構成しますか？
sarのインストールと有効化について説明しました （またはsysstat 、これはsarを含むパッケージです ）はとても簡単です。残念ながら、デフォルトの構成はやや悪いです。 sysstatをインストールした後 、/etc/cron.d/sysstatに次のようなものがあります （またはディストリビューションがcronを格納している場所 構成）：
*/10 * * * * root /usr/lib64/sa/sa1 1 1
これは事実上sa1を言います コマンドは10分ごとに実行され、1秒間に1つのサンプルを収集します。ここには2つの問題があります。まず、10分はかなり低い解像度です。次に、サンプルは600のうち1秒しかカバーしていないため、残りの9:59は実際には含まれていません。これは、低解像度のランダムサンプリングで十分な長期トレンドの場合はある程度問題ありません。他の目的では、おそらく代わりに次のようなことをする必要があります：
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
これは1分あたり1つのサンプルを収集し、すべてのサンプルが1分をカバーします。 -S XALL 割り込み、個々のブロックデバイス、パーティションなどを含むすべての統計を収集する必要があることを意味します。man sadcを参照してください。 詳細については。
概要
したがって、この投稿をいくつかの簡単なポイントにまとめると、次のようになります。
- 必要ないと思われる場合でも、監視する必要があります。問題が発生したら、手遅れです。
- 監視のコストはおそらくごくわずかですが、監視データを持つことのメリットよりも確かにはるかに低くなります。
-
sar便利で非常に効率的です。将来的には別のものを使用するかもしれませんが、それは良い第一歩です。 - デフォルトの構成は特に優れていません（低解像度、1秒のサンプル）。解像度を上げることを検討してください。
私が言及していないことの1つは、sar システムメトリック（CPU、ディスク、メモリ、プロセス）のみを扱い、PostgreSQL統計は扱いません。もちろん、スタックのその部分も確実に監視する必要があります。