SQL Server監視ツールを検討する前に、特定の環境について考えてください。
- 監視するインスタンスの数はいくつですか？
- これらは1つの場所にありますか、それとも分散していますか？
- オペレーティングシステムやハイパーバイザーを監視する必要がありますか？
- インスタンスの操作の境界を正確に把握するには、どのくらいの履歴が必要ですか？
- それらはすべてオンプレミスですか、それとも一部はクラウドにありますか？
- チームは分散していますか？
- 設備投資または運用費の予算でソフトウェアを購入しますか？
- インフラストラクチャとライセンスに前もって一括投資する余裕はありますか、それとも時間の経過とともにコストを分散することを好みますか？
- 監視ツール専用のインフラストラクチャとデータベースインスタンスを利用できますか？
- 監視インフラストラクチャを構築する時間はありますか？
- チーム全体で一貫して高い専門知識を持っていますか？
- 最初のトリアージにジュニアリソースを利用しますか、それともすべてを専門家に依存しますか？
- 監視インフラストラクチャを維持するための時間またはリソースが社内にありますか？
自分で転がす必要がありますか？
ここで私たちの偏見を宣言することができます。 Quest Softwareは、過去20年間、パフォーマンス監視ツールを構築してきました。私たちや私たちのような他の多くの人々がこのセグメントに長く留まっている理由と、顧客ベースが拡大している理由は素晴らしいものです。パフォーマンスの監視は簡単ではありません！
いくつか言及すると、PerfMon、トレース、DMV、およびXEventsを使用してSQLServerからメトリックを収集するための優れた方法がいくつかあります。単一の問題に対して1回限りでこれを行うことは、その問題のデータをどこでどのように収集するかを調査するために投資する時間があれば、うまくいきます。問題が増え始め、インスタンスの数が増えると、これは急速にスケーラブルになります。
SQL Serverのパフォーマンスの健全性の全体像を把握するために追跡する価値のある、数百のメトリックが利用可能です。それに加えて、実行されるSQLコードと、その実行ごとに関連付けられたクエリプランがあります。一部のメトリックは毎秒、一部は1時間ごとに収集する必要があり、一部はコードの実行時期に基づいて収集する必要があります。一部の収集方法は、監視対象のインスタンスに影響を与える可能性があるため、回避する必要があります。
各メトリックには、そのステータスを定義するさまざまなしきい値があります。特定のインスタンスには、非標準のレベルがある場合があります。次に、これらすべてを保存する必要があります。データの量は非常に速く加算されます。詳細なデータを定期的に削除する戦略を立ててから、傾向分析が必要な場合は、このデータを集計してレポートを作成する必要があります。
これは多くの作業です…そしてもちろん、新しいSQL Serverバージョンがリリースされるたびに、対処する必要のあるリグレッションの頭痛の種があります。実際に監視ツールを販売したい場合を除いて、問題の量が少なく、解決しなければならない問題が非常に具体的でない限り、自分でロールすることは強くお勧めします。
無料ツールはどうですか？
無料のツールは、特に重要度の低いインスタンスを持つ小規模なチームの場合、検討する価値があります。これは、「自分でロール」した後のスケーラビリティのはしごの次のステップと考えてください。エントリーレベルの商用SQLサーバー監視ツールの多くは、同様の考慮事項を持っている必要があります。次のことを考慮してください：
- ツールは、監視対象のインスタンス全体のすべてのユースケースに適切なカバレッジを提供するのに十分な範囲のメトリックをカバーしていますか？多くの無料ツールは、独自のメトリックを追加するためのある種の「カスタマイズ」を提供します。機能のギャップを埋めるために「カスタマイズ」が使用されている場合、チームが必要な気晴らしとメンテナンスの頭痛の種で「自分自身を転がして」しまうことにすぐに気付くでしょう。
- ツールはアラートをサポートしていますか？事前設定されていますか？アラートの構成には非常に時間がかかる場合があります。すぐに使用できるアラートは、他の人のツールを構成するために多くの工数が失われるのを防ぐために必須です。また、デフォルトに準拠していないエッジケースのアラートのカスタマイズも容易になります。
- データはどこにどのように保存されますか？ほとんどの無料ツールは、パフォーマンスデータのストレージを管理することをあなたに任せています。クラウドベンダーからの「無料」の監視には注意してください。彼らはストレージの料金を請求します、そしてこれは大きくて高価になる可能性があります！
ですから、ぜひとも、そこにある無料のツールを利用してください。それらの制限に注意し、次のようなチーム内の古典的なアンチパターンに注意してください。
- ツールを使用して問題を修正するよりも、ツールの修正または保守に多くの時間を費やしました
- インフラストラクチャとストレージにより多くのお金が費やされます
- 大量のデータがありますが、洞察はありません
- 問題を解決するための診断の深さが不十分です
- ニーズに合うほどスケーラブルではありません
上記のいずれかに気付いた場合は、より堅牢なソリューションにアップグレードする必要があることを示しているはずです。
SQLServer監視システムの一般的なアーキテクチャ
従来のオンプレミスソリューションとサービスとしてのホスト型ソフトウェア（SaaS）ソリューションのどちらを採用するかを検討する場合は、監視アプリケーションアーキテクチャを検討することが役立ちます。主要なアーキテクチャコンポーネントの概要は次のとおりです。
SaaSとオンプレミスの主な違いは、パフォーマンスデータの保存場所と、このリポジトリの管理者に関係しています。オンプレミスソリューションの場合、これはエンドユーザーの責任です。これらのリポジトリは急速に大きくなる可能性があるため、慎重に管理する必要があります。インフラストラクチャを計画し、予算を立てる必要があります（詳細は以下を参照）。
SQL Server監視用のSaaSソリューションでは、これらの主要なインフラストラクチャコンポーネントがホストされ、管理されます。
| 従来のオンプレミスソリューション | SaaSソリューション |
|
|
詳細については、ブログ「データベース監視システムアーキテクチャ」をご覧ください。