次の方法で共有


Azure Table Storage を監視する

この記事では、次の内容について説明します。

  • このサービスに対して収集できる監視データの種類。
  • そのデータを分析する方法。

Note

このサービスや Azure Monitor を既に使い慣れていて、監視データの分析方法だけを確認したい場合は、この記事で後述する分析に関するセクションをご覧ください。

Azure リソースに依存するクリティカルなアプリケーションやビジネス プロセスがある場合は、システムを監視し、そのアラートを受け取る必要があります。 Azure Monitor サービスでは、システムのすべてのコンポーネントからメトリックとログを収集して集計します。 Azure Monitor を使用すると、可用性、パフォーマンス、回復性を視覚化し、問題に関する通知を受け取ることができます。 Azure portal、PowerShell、Azure CLI、REST API、またはクライアント ライブラリは、監視データの設定および表示に使用できます。

重要

Azure Monitor のメトリックとログでは、Azure Resource Manager ストレージ アカウントのみがサポートされています。 Azure Monitor では、従来のストレージ アカウントはサポートされていません。 従来のストレージ アカウントでメトリックまたはログを使用する場合、Azure Resource Manager ストレージ アカウントに移行する必要があります。 詳細については、Azure Resource Manager への移行に関する記事を参照してください。

分析情報

Azure の一部のサービスについては、サービスを監視するための開始点となる監視ダッシュボードが Azure portal に組み込まれています。 これらのダッシュボードは、"分析情報" と呼ばれており、Azure portal の Azure Monitor の [分析情報ハブ] にあります。

Azure Storage の分析情報では、ストレージのパフォーマンス、容量、可用性の統合ビューを提供します。 「Azure Monitor Storage 分析情報を使用したストレージの監視」をご覧ください。

リソースの種類

Azure では、リソースの種類と ID の概念を使用して、サブスクリプション内のすべてを識別します。 リソースの種類は、Azure で実行されているすべてのリソースのリソース ID の一部でもあります。 たとえば、Microsoft.Compute/virtualMachines は、仮想マシンのリソースの種類の 1 つです。 サービスとそれに関連付けられるリソースの種類の一覧については、リソース プロバイダーに関するページをご覧ください。

同様に、Azure Monitor では、コア監視データがリソースの種類 (名前空間とも呼ばれます) に基づいてメトリックとログに整理されます。 リソースの種類に応じてさまざまなメトリックとログが使用できます。 サービスは、複数のリソースの種類に関連付けられる可能性があります。

データ ストレージ

Azure Monitor の場合:

  • メトリック データは、Azure Monitor メトリック データベースに保存されます。
  • ログ データは、Azure Monitor ログ ストアに保存されます。 Log Analytics は、Azure portal のツールの 1 つであり、このストアに対してクエリを実行することができます。
  • Azure アクティビティ ログは、Azure Portal 内の独自のインターフェイスを持つ別のストアです。

必要に応じて、メトリックおよびアクティビティ ログ データを Azure Monitor ログ ストアにルーティングできます。 次に、Log Analytics を使用してデータのクエリを実行し、他のログ データと関連付けることができます。

多くのサービスで診断設定を使用して、メトリックとログ データを Azure Monitor の外部の他のストレージの場所に送信できます。 たとえば、Azure Storage、ホステッド パートナー システムEvent Hubs を使用する Azure 以外のパートナー システムなどがあります。

Azure Monitor によるデータの保存方法の詳細については、「Azure Monitor データ プラットフォーム」を参照してください。

Azure Monitor プラットフォームのメトリック

Azure Monitor により、ほとんどのサービスに関するプラットフォーム メトリックが提供されます。 これらのメトリックは次のとおりです。

  • 名前空間ごとに個別に定義されます。
  • Azure Monitor 時系列メトリック データベースに保存されます。
  • 軽量であり、凖リアルタイムのアラートをサポートできます。
  • リソースのパフォーマンスを時間の経過と共に追跡するために使用されます。

収集: Azure Monitor では、プラットフォーム メトリックを自動的に収集します。 構成は必要ありません。

ルーティング: また、いくつかのプラットフォーム メトリックを Azure Monitor ログまたは Log Analytics にルーティングして、他のログ データを使用してクエリを実行することもできます。 各メトリックの DS エクスポート設定を確認して、診断設定を使用してメトリックを Azure Monitor ログまたは Log Analytics にルーティングできるかどうかを確認します。

Azure Monitor ですべてのリソースに対して収集できるすべてのメトリックの一覧については、Azure Monitor でサポートされるメトリックに関する記事を参照してください。

Azure Table Storage で使用可能なメトリックの一覧については、「Azure Table Storage 監視データ リファレンス」を参照してください。

重要

2024 年 1 月 9 日をもって、Storage Analytics メトリック (別称 "クラシック メトリック") は廃止されました。 クラシック メトリックを使用していた場合は、Storage Analytics のメトリックから Azure Monitor のメトリックへの移行に関するページを参照してください。 必要に応じて、クラシック ログを引き続き使用することができます。 ただし、Storage Analytics ログの代わりに、Azure Monitor の Azure Storage ログを使用するように切り替えることをお勧めします。

Note

マネージド ディスクおよびアンマネージド ディスクに関するメトリックは、Azure Storage ではなく Azure Compute でサポートされています。 詳細については、マネージド ディスクと非管理ディスクのディスクあたりのメトリックに関するページをご覧ください。

Azure Monitor リソース ログ

リソース ログでは、Azure リソースによって実行された操作に関する分析情報を提供します。 ログは自動的に生成されますが、保存するかクエリを実行するには、Azure Monitor ログにルーティングする必要があります。 ログはカテゴリに分類されています。 特定の名前空間に複数のリソース ログ カテゴリが含まれる場合があります。

収集: リソース ログは、"診断設定" を作成してログを 1 つ以上の場所にルーティングするまでは収集および保存されません。 診断設定を作成するときは、収集するログのカテゴリを指定します。 診断設定を作成して管理するには、Azure portal、プログラム、Azure Policy など、複数の方法があります。

ルーティング: 既定で推奨されるのは、リソース ログを Azure Monitor ログにルーティングして、他のログ データを使用してクエリを実行できるようにすることです。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。 詳細については、「Azure リソース ログ」およびリソース ログの送信先に関するページを参照してください。

リソース ログの収集、保存、ルーティングの詳細については、「Azure Monitor の診断設定」を参照してください。

Azure Monitor で使用可能なすべてのリソース ログ カテゴリの一覧については、Azure Monitor でサポートされているリソース ログに関するページを参照してください。

Azure Monitor 内のすべてのリソース ログには、同じヘッダー フィールドの後にサービス固有のフィールドがあります。 共通のスキーマの概要については、Azure Monitor リソース ログのスキーマに関する記事をご覧ください。

使用可能なリソース ログ カテゴリ、関連する Log Analytics テーブル、Azure Table Storage のログ スキーマについては、「Azure Table Storage 監視データ リファレンス」を参照してください。

Azure Table Storage の診断設定

診断設定を作成するときに、ログを有効にするストレージの種類として [テーブル] を選択します。 次に、ログ収集の対象とする操作のカテゴリを次のいずれかから指定します。

カテゴリ 説明
StorageRead オブジェクトに対する読み取り操作。
StorageWrite オブジェクトに対する書き込み操作。
StorageDelete オブジェクトに対する削除操作。

監査リソース ログ カテゴリ グループを使用すると、Microsoft がリソースの監査に必要と見なすリソース ログのベースラインを収集できます。 収集される内容は動的であり、新しいリソース ログ カテゴリが使用可能になるにつれて、Microsoft によって時間の経過とともに変更される可能性があります。 監査カテゴリ グループを選択した場合、収集するログがシステムによって決定されるため、他のリソース カテゴリを指定することはできません。 詳細については、「Azure Monitor の診断設定: リソース ログ」を参照してください。

宛先の制限事項

一般的な宛先の制限については、「宛先の制限事項」を参照してください。 次の制限は、Azure Storage アカウントの監視にのみ適用されます。

  • この設定で監視している対象と同じストレージ アカウントにログを送信することはできません。 この状況では、ログ エントリが別のログ エントリの書き込みを記述する再帰的なログになります。 ログ情報を格納するために、アカウントを作成するか、別の既存のアカウントを使う必要があります。

  • アイテム保持ポリシーを設定することはできません。

    ログをストレージ アカウントにアーカイブする場合、ライフサイクル管理ポリシーを定義することにより、ログ コンテナーの保持ポリシーを管理できます。 その方法については、「データ ライフサイクルを自動管理してコストを最適化する」をご覧ください。

    ログを Log Analytics に送信する場合は、ワークスペース レベルで Log Analytics のデータ保有期間を管理したり、データの種類ごとに異なる保持設定を指定したりすることもできます。 方法については、「データ保有期間 の変更」を参照してください。

Azure activity log

アクティビティ ログには、Azure リソースごとに操作を追跡する、そのリソースの外から見たサブスクリプションレベルのイベント (新しいリソースの作成や仮想マシンの起動など) が含まれます。

収集: アクティビティ ログ イベントは、Azure portal で表示するために、個別のストアに自動的に生成および収集されます。

ルート指定: アクティビティ ログ データを Azure Monitor ログに送信して、他のログ データと共に分析できます。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。 アクティビティ ログをルーティングする方法の詳細については、Azure アクティビティ ログの概要に関するページをご覧ください。

監視データを分析する

監視データを分析するためのツールは多数あります。

Azure Monitor ツール

Azure Monitor は、次の基本的なツールをサポートします。

より複雑な視覚化を可能にするツールは次のとおりです。

  • ダッシュボードを使用すると、さまざまな種類のデータを組み合わせて、Azure portal 内の 1 つのペインに表示できます。
  • ブック。Azure portal で作成できるカスタマイズ可能なレポート。 ブックには、テキスト、メトリック、ログ クエリを含めることができます。
  • Grafana。運用ダッシュボードに優れたオープン プラットフォーム ツール。 Grafana を使用して、Azure Monitor 以外の複数のソースからのデータを含むダッシュボードを作成できます。
  • Power BI。さまざまなデータ ソースにわたって対話型の視覚化を提供するビジネス分析サービス。 Azure Monitor からログ データを自動的にインポートするように Power BI を構成して、これらの視覚化を利用できます。

Azure Monitor エクスポート ツール

次の方法を使用して、Azure Monitor から他のツールにデータを取得できます。

Azure Monitor 用 REST API の使用を開始するには、「Azure 監視 REST API のチュートリアル」を参照してください。

Azure Table Storage のメトリックを分析する

Azure Table Storage のメトリックは、次の名前空間にあります。

  • Microsoft.Storage/storageAccounts
  • Microsoft.Storage/storageAccounts/tableServices

Azure Table Storage を含め、Azure Monitor でサポートされているすべてのメトリックの一覧については、「Azure Monitor でサポートされているメトリック」を参照してください。

メトリックス エクスプローラーを使用して、他の Azure サービスのメトリックと共に Azure Storage のメトリックを分析できます。 メトリックス エクスプローラーを開くには、 [Azure Monitor] メニューの [メトリック] を選択します。 このツールの使用方法の詳細については、「Azure Monitor メトリック エクスプローラーでメトリックを分析する」を参照してください。

次の例は、アカウント レベルでトランザクションを表示する方法を示しています。

Azure Portal でのメトリック アクセスのスクリーンショット

ディメンションをサポートするメトリックについては、目的のディメンション値でメトリックをフィルター処理できます。 次の例は、 [API 名] ディメンションの値を選択することで特定の操作に対するアカウント レベルのトランザクションを表示する方法を示しています。

Azure Portal におけるディメンションでのメトリック アクセスのスクリーンショット

Azure Storage でサポートされるディメンションの完全な一覧については、「メトリックのディメンション」をご覧ください。

Azure Table Storage のログを分析する

リソース ログには、ストレージ アカウント内の BLOB として、イベント データとして、または Log Analytics クエリを使用してアクセスできます。 これらのログを見つける方法については、「Azure リソース ログ」を参照してください。

ログに記録された SMB と REST の各操作の一覧を取得するには、Storage によって記録される操作やステータス メッセージに関するページを参照してください。

ログ エントリが作成されるのは、サービス エンドポイントに対して行われた要求がある場合に限られます。 たとえば、ストレージ アカウントのテーブル エンドポイントにはアクティビティが存在するが、キューまたは BLOB のエンドポイントには存在しない場合、Table Storage に関連したログのみが作成されます。 Azure Storage ログには、ストレージ サービスに対する要求の成功と失敗についての詳細な情報が含まれています。 この情報を使って個々の要求を監視したり、ストレージ サービスに関する問題を診断したりできます。 要求は、ベスト エフォートでログに記録されます。

Azure portal でストレージ アカウントを表示すると、ポータルによって呼び出された操作もログに記録されます。 このため、ストレージ アカウントに何もデータを書き込んでいないのにアカウントに操作が記録されていることがあります。

認証済み要求をログに記録する

次のタイプの認証済み要求が記録されます。

  • 成功した要求
  • 失敗した要求 (タイムアウト、スロットル、ネットワーク、承認などに関する各種エラー)
  • Shared Access Signature (SAS) または OAuth を使用した要求 (失敗した要求と成功した要求を含む)
  • 分析データ ( $logs コンテナーの従来のログ データと、 $metric テーブルのクラス メトリック データ) に対する要求

Table Storage サービス自体で作成された要求 (ログの作成や削除など) はログされません。 ログに記録されるデータの完全な一覧については、ストレージのログに記録された操作とステータス メッセージに関するページと、ストレージのログの形式に関するページをご覧ください。

匿名要求をログに記録する

次のタイプの匿名要求が記録されます。

  • 成功した要求
  • サーバー エラー
  • クライアントとサーバーの両方のタイムアウト エラー
  • エラーコード 304 (Not Modified) で失敗した GET 要求

Kusto クエリ

Kusto クエリ言語 (KQL) を使用して、Azure Monitor ログ/Log Analytics ストアの監視データを分析できます。

重要

ポータルでサービスのメニューから [ログ] を選択すると、クエリ スコープが現在のサービスに設定された状態で Log Analytics が開きます。 このスコープは、ログ クエリにその種類のリソースのデータのみが含まれることを意味します。 他の Azure サービスのデータを含むクエリを実行する場合は、[Azure Monitor] メニューから [ログ] を選択します。 詳細については、「Azure Monitor Log Analytics のログ クエリのスコープと時間範囲」を参照してください。

いずれかのサービスに関する一般的なクエリの一覧については、Log Analytics クエリ インターフェイスに関するページを参照してください。

ここでは、Table Storage の監視に役立つ、[ログ検索] バーに入力できるクエリの一部を紹介します。 これらのクエリは新しい言語で使用できます。 詳細については、「Log Analytics のチュートリアル」を参照してください。

  • 過去 3 日間に発生した 10 件の最も一般的なエラーの一覧を表示します。

    StorageTableLogs
    | where TimeGenerated > ago(3d) and StatusText !contains "Success"
    | summarize count() by StatusText
    | top 10 by count_ desc
    
  • 過去 3 日間で最も多く発生したエラーの原因となった上位 10 件の操作を一覧表示します。

    StorageTableLogs
    | where TimeGenerated > ago(3d) and StatusText !contains "Success"
    | summarize count() by OperationName
    | top 10 by count_ desc
    
  • 過去 3 日間でエンドツーエンドの待機時間が最も長かった上位 10 個の操作を一覧表示します。

    StorageTableLogs
    | where TimeGenerated > ago(3d)
    | top 10 by DurationMs desc
    | project TimeGenerated, OperationName, DurationMs, ServerLatencyMs, ClientLatencyMs = DurationMs - ServerLatencyMs
    
  • 過去 3 日間にサーバー側の調整エラーの原因となったすべての操作を一覧表示します。

    StorageTableLogs
    | where TimeGenerated > ago(3d) and StatusText contains "ServerBusy"
    | project TimeGenerated, OperationName, StatusCode, StatusText
    
  • 過去 3 日間の匿名アクセスを含むすべての要求を一覧表示します。

    StorageTableLogs
    | where TimeGenerated > ago(3d) and AuthenticationType == "Anonymous"
    | project TimeGenerated, OperationName, AuthenticationType, Uri
    
  • 過去 3 日間に使用された操作の円グラフを作成します。

    StorageTableLogs
    | where TimeGenerated > ago(3d)
    | summarize count() by OperationName
    | sort by count_ desc 
    | render piechart
    
    

警告

Azure Monitor のアラートにより、監視データで特定の状態が見つかったときに事前に通知を受け取ります。 アラートにより、ユーザーが気付く前に、管理者が問題を識別して対処できます。 詳細については、Azure Monitor アラートに関するページを参照してください。

Azure リソースに関する一般的なアラートのソースは数多くあります。 Azure リソースに関する一般的なアラートの例については、ログ アラート クエリのサンプルに関するページをご覧ください。 Azure Monitor ベースライン アラート (AMBA) サイトには、重要なプラットフォーム メトリック アラート、ダッシュボード、ガイドラインを実装するための半自動化された方法が用意されています。 このサイトは、Azure ランディング ゾーン (ALZ) の一部であるすべてのサービスを含む、Azure サービスの継続的に拡張されるサブセットに適用されます。

共通アラート スキーマを使用すると、Azure Monitor のアラート通知の使用を標準化できます。 詳細については、「共通アラート スキーマ」をご覧ください。

アラートの種類

Azure Monitor データ プラットフォームでは、任意のメトリックまたはログ データ ソースに対してアラートを生成できます。 監視するサービスと収集する監視データに応じて、さまざまな種類のアラートがあります。 アラートの種類に応じて、さまざまな利点と欠点があります。 詳細については、適切な種類の監視アラートの選択に関するページをご覧ください。

次の一覧では、作成できる Azure Monitor アラートの種類について説明します。

  • メトリック アラートでは、リソース メトリックを定期的に評価します。 メトリックはプラットフォーム メトリック、カスタム メトリック、メトリックに変換された Azure Monitor からのログまたは Application Insights メトリックにすることができます。 メトリック警告では、複数の条件と動的しきい値を適用することもできます。
  • ログ アラートでは、ユーザーは Log Analytics クエリを使用して、定義済みの頻度でリソース ログを評価できます。
  • アクティビティ ログ アラートは、定義された条件と一致する新しいアクティビティ ログ イベントが発生したときにトリガーされます。 Resource Health アラートと Service Health アラートは、サービスとリソースの正常性を報告するアクティビティ ログ アラートです。

一部の Azure サービスでは、スマート検出アラートPrometheus アラート推奨されるアラート ルールもサポートされています。

一部のサービスでは、同じ Azure リージョン内に存在する同じ種類の複数のリソースに同じメトリック警告ルールを適用することで、大規模に監視することができます。 監視対象リソースごとに個別の通知が送信されます。 サポートされている Azure サービスとクラウドについては、「1 つのアラート ルールで複数のリソースを監視する」を参照してください。

Azure Table Storage 警告ルール

次の表に、Azure Table Storage の推奨される一般的な警告ルールと、アラートに使用する適切なメトリックを示します。

アラートの種類 条件 説明
メトリック Table Storage サービスが調整されます。 トランザクション
ディメンション名:応答の種類
メトリック Table Storage 要求は 99% の割合で成功します。 可用性
ディメンション名: Geo 型、API 名、認証
メトリック Table Storage エグレスが 1 日に 500 GiB を超えた。 エグレス
ディメンション名: Geo 型、API 名、認証

Advisor の推奨事項

一部のサービスでは、リソースの操作中にクリティカルな条件や差し迫った変更が発生した場合は、ポータルのサービス [概要] ページにアラートが表示されます。 アラートの詳細と推奨される修正は、左側のメニューの [監視] の下の [アドバイザーのレコメンデーション] に表示されます。 通常の操作中、アドバイザーのレコメンデーションは表示されません。

Azure Advisor の詳細については、Azure Advisor の概要に関するページをご覧ください。

Table Storage の監視に関するその他のコンテンツ:

Azure Storage の監視に関する全般的なコンテンツ:

Azure Monitor に関するコンテンツ: