Azure SQL Database の各種メトリックを取得する方法ですがいくつかの方法が提供されており、簡単に使いだすことができます。
どのようなものがあり、どこから確認するかを忘れるときが結構ありますので、一度まとめておこうかと。
Contents
サービスの正常性
SQL Database に特化したものではありませんが「Azure のサービスの正常性」という観点で、SQL Database の状態を取得しておく必要もあるのではないでしょうか。
そのような場合は、Service Health (サービスの正常性) を使用することで、アラートの把握をすることができます。
SQL Server ベースのサービス単位でアラートルールを設定することができますので、サービス基盤として問題が発生していないかの確認を行いたい場合にはサービス正常性を使用すると良いのではないでしょうか。
基本メトリック
基本情報として直近のメトリックについては自動的に取得が行われています。
長期間、データを保持しておきたい場合は、「診断設定」と組み合わせる必要がありますが、直近の情報であれば、該当のデータベースのブレードを開き、「メトリック」から情報を確認することができます。
基本メトリックのベースとなる情報については、次の情報となるかと。
- sys.dm_db_resource_stats
- 15 秒間隔で 1 時間保持
- sys.resource_stats
- 5 分間隔で 14 日間保持
どのようなリソースの利用のされ方をしているのかを把握する場合には、この情報が活用できます。
診断設定
メトリックの情報を長期間保持しておきたい場合や、自分で任意に加工をしたい場合などは、メトリックの情報を「診断設定」を使用して、保存することができます。
診断設定については、該当のデータベースのブレードを開き「診断設定」から設定をすることができます。
保存先としては、次の 3 種類を指定できます。
- BLOB ストレージ
- イベント ハブ
- Log Analytics
BLOB ストレージについては同一のリージョンのストレージに出力することになりますが、それ以外は異なるリージョンのリソースも使用することができます。
私は、イベントハブを使って何かをするというのは今まで対応したことがなく、大抵は BLOB ストレージか Log Analytics が使われているケースが多いですね。
BLOB の場合は、リテンション期間を設定することができるのですが、出力については JSON ファイルに時間単位に出力が行われています。
分析の容易性ということでしたら Log Analytics に出力した方が楽ではないでしょうか。
Log Analytics に診断データを出力するように設定すると、「AzureDiagnostics」「AzureMetrics」テーブルに SQL Database 向けのカテゴリが作成されてデータの取得が行われます。
情報の確認は Kusto Query Language (KQL) 行う必要があります。
SQL Database の管理者であれば、SQL を使用した情報の取得には慣れているかと思いますので、「今まで SQL で書いていたものを KQL で書くにはどうすればよいか？」については次の情報が参考になるかと。
カスタムログとして、任意の情報を送信したい場合には、次の情報を元に送信を行うと、標準では取得されていない項目についても連携することができます。
Log Analytics に出力をした場合、「Azure SQL Analytics」というソリューションを使用して分析を行うこともできます。
Azure SQL Analytics
Azure SQL Analytics ですが、「診断設定」により、Log Analytics に出力されたメトリックスデータの可視化を容易に行うことができる機能となります。
- Azure SQL Analytics へのストリーム
- Azure SQL Analytics (プレビュー) を使用した Azure SQL Database の監視
- AZURE SQL DB AND LOG ANALYTICS BETTER TOGETHER ? PART #1
Azure SQLAnalytics ですが、単一の機能というわけではなく「Log Analytics に出力されている診断データを可視化するためのソリューション」という扱いになっています。
リソースの作成から、Azure SQL Analytics を追加すると、Log Analytics のワークスペースを選択することで利用可能になります。
選択した Log Analytics に出力されている SQL Database のデータベースが分析の対象となりますので、このリソースを追加した際に、明示的に「どのデータベースを分析するか？」というような選択を行う必要はありません。
Azure SQL Analytics へのアクセス方法ですがいくつかの方法があります。
一つ目の方法としては、ソリューションからのアクセスです。
Azure SQL Analytics を追加すると、リソースグループのソリューションが追加されます。
概要のブレードの中に、「概要の表示」というリンクがありますので、こちらをクリックすると、
表示が切り替わりますので、ここから Azure SQL Analytics の情報にアクセスすることができます。
もう一つの方法がソリューションを追加した Log Analytics ワークスペースからのアクセスです。
「ワークスペースの概要」をクリックすることで、Azure SQL Analytics が表示されますので、ここからアクセスをすることができます。
Azure SQL Analytics では次のように、Log Analytics に取得されている診断設定の情報が表示されますので、ここからメトリックスを確認することができます。
ここで取得されているログのベースとなる情報は、Log Analytics のテーブルのデータですので、独自の集計軸で分析を行いたい場合には、Log Analytics で Kusto を記述することで、確認することもできます。
Intelligent Insights
Intelligent Insights も「診断設定」で取得されているデータを活用した機能となります。
- AI を使用してデータベース パフォーマンスの監視とトラブルシューティングを行う Intelligent Insights
- Intelligent Insights を使用した Azure SQL Database のパフォーマンスに関する問題のトラブルシューティング
診断設定で「SQLInsights」を取得することで、Intelligent Insights による SQL Database の様々な洞察を得ることができるようになります。
SQLInsights:データベースのパフォーマンスに対する Intelligent Insights が含まれます。 詳細については、Intelligent Insights に関するページを参照してください。
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-metrics-diag-logging#supported-diagnostic-logging-for-azure-sql-databases-and-instance-databases より
SQL Dataase で発生している事象を自動的に分析することができるようになります。
分析の結果については、SQL Analytics に表示が行われますので、ここでも Log Analytics が活用できるかと。
Query Performance Insight
SQL Database には、Query Performance Insight という機能があります。
この機能は「クエリストア」という機能と連動しているため、使用するためにはクエリストアを有効にしておく必要があります。
Query Performance Insight では、 クエリ ストア がデータベース上で実行されている必要があります。 既定では、自動的にすべての Azure SQL データベースに対して有効になります。 クエリ ストアが実行されていない場合、Azure portal で有効にするように求められます。
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-query-performance#prerequisites より
数年前から、SQL Databae ではクエリストアは既定で有効になっていたはずですので、新規に作成したデータベースについては、この機能は既定で利用できると考えてよいかと。。
既定の設定としては次のような内容となっています。
サイズ : 10MB / 古いクエリの保持期間 : 7 日 となっていますので、実行されるクエリのパターンが多い環境では、設定を変更し、格納される情報を多くしても良いのではないでしょうか。
Query Performance Insight は Azure のポータルから、クエリストアの情報を確認することができる機能となります。
クエリストアはクエリの情報を解析するのに強力な機能であり、この機能を簡単に活用することができるのが Query Performance Insight となります。
クエリストアを単体で使用した場合と異なり、Query Performance Insight では、SQL Database のリソースの使用状況とクエリの実行状況をマッピングしながら、解析対象となるクエリを調査することができますので、SQL Database に最適化されたクエリの調査方法と言えるのではないでしょうか。
監査
SQL Database の「監査」の機能も状態を取得するための機能として活用することができるのではないでしょうか。
出力先については、診断設定と同様に次の 3 種類に出力することができます。
- BLOB ストレージ
- イベント ハブ
- Log Analytics
BLOB ストレージについては、同一のリージョンのリソースを指定する必要があります。
サーバーレベルとデータベースレベルの二つのレベルで監査の設定を行うことができ、サーバー単位で全 DB に統一的な設定を行うことも、DB 単位で独立した設定を行うこともできます。
サーバー レベルおよびデータベース レベルの監査ポリシーを定義する に記載されていますが、サーバーレベルとデータベースレベルの両方で設定をすると、各レベルで監査ログが重複して取得されますので、どのレベルで取得を行うかは検討が必要かと。
教えてもらうまで気づいていなかったのですが、Set-AzSqlDatabaseAudit を使用すると、取得する項目を選択することができるようになります。
ポータルから監査を有効化した場合は、一律の設定ですが、監査ログの出力内容が膨大になる場合などは、PowerShell から設定することで、監査ログの出力内容を調整することができます。
BLOB ストレージ出力した監査ログは拡張イベントの形式で出力されますので、診断情報と異なり、BLOB ストレージに出力しても加工しやすいかと。
Log Analytics に出力した場合は「AzureDiagnostics」に「SQLSecurityAuditEvents」の Category として出力が行われます。
どのような情報が出力されているかについては次のような KQL で確認できます。
セカンダリの情報取得
SQL Database では 2 種類のセカンダリがあります。
- Premium / Business Critical / Hyperscale で使用可能な読み取り専用レプリカ
- Geo レプリケーションによって同期されている Geo セカンダリ
読み取り専用レプリカでは、一部の情報を取得することはできません。
これについては、読み取り専用レプリカを使用して読み取り専用クエリ ワークロードを負荷分散する に記載されています。
読み取り専用レプリカでは、クエリ データ ストア、拡張イベント、SQL Profiler、および監査の各機能はサポートされていません。
診断設定や、監査については、読み取り専用レプリカではなく、「Geo セカンダリ」にすることで取得することはできそうですが、クエリストア (Query Performance Insight) や拡張イベントのような、DB 側の機能を使用しているものについては、Geo セカンダリでも取得することはできず、一部の情報がプライマリの情報になってしまうということは避けることができません。
監査を厳密に行わなければいけない場合は、読み取り専用レプリカではなく Geo セカンダリを構成上使用しなくてはいけないということもあるのではないでしょうか。
(Geo セカンダリ側の読み取り専用レプリカだと監査が取得できないというような悩みは出てきそうですが…)
BLOB ストレージと Log Analytics の使い分け
KQL で検索ができるので、様々な情報を Log Analytics に集約したいところではあるのですが、BLOB ストレージと Log Analytics では料金に差があります。
データベースに関連する情報は結構サイズが膨らみやすい傾向にあり、大量の情報を取得すると、Log Analytics のサイズもかなりのサイズになる可能性があります。
サイズ当たりの容量単価は BLOB ストレージの方が安価ですので、取得するデータの特性や、データの確認容易性に応じて、どちらのストレージをメインに使用するかを考慮しても良いのではないでしょうか。
拡張イベントで出力されている情報や、クエリストアの情報については、SQL Server Management Studio を使うことで検索の容易性は向上しますので、これらの情報については Log Analytics への連携を設定しないことで、Log Analytics 側の課金を抑えることもできますので。
SQL Database ではポータルの操作で取得できる情報の他にも、DMV / システムビュー / 拡張イベントを使用することで様々な情報を取得することができます。
情報は取得するだけでなく、活用することで取得している内容が生きてきます。
「情報を取得したのはよいが見方がわからない」ということにならないように、様々な観点で情報を解析するのが DB 管理者の腕の見せ所の一つだと思いますので「取得した情報をどのように活用するか？」についての勉強は継続して続けていきたいものですね。