Log Analytics ワークスペースでは、ログ データがテーブルに格納されます。 各テーブルは、データの形状を定義する列のコレクションであり、各行はログ レコードです。 テーブル構成では、データの収集方法、スキーマの外観、データの保持期間、格納とクエリにかかるコストを制御します。 この記事では、Azure Monitor ログのテーブルの背後にある主要な概念について説明します。
次の図は、テーブルの主な構成オプションを示しています。
テーブルの種類
Log Analytics ワークスペースには、複数の種類のテーブルが含まれています。 テーブルの種類によって、データ ソース、スキーマの定義方法、およびスキーマを変更できるかどうかが決まります。
| テーブルのタイプ | データ ソース | Schema |
|---|---|---|
| Azure テーブル | Azure リソースからのログ、またはAzureのサービスとソリューションに必要なログ | Azure Monitor ログでは、使用する Azure サービスと、特定のリソースに対して構成する診断設定に基づいて自動的に Azure テーブルが作成されます。 各 Azure テーブルには、事前に定義されたスキーマがあります。 変換またはエンリッチされたデータを格納するカスタム列を追加します。 |
| カスタム テーブル | Azure以外のリソースとその他のデータ ソース (ファイル ベースのログなど) | 収集するデータに基づいてスキーマを定義します。 「Azure Monitor ログのテーブルと列を追加または削除する方法に関する記事を参照してください。 |
| 検索結果 | Log Analytics ワークスペースに格納されているすべてのデータ | スキーマは、 検索ジョブの実行時に定義したクエリに基づいています。 既存の検索結果テーブルのスキーマは編集できません。 |
| 復元されたログ | ワークスペース内の特定のテーブルに格納されているデータ | 復元されたログ テーブルには、 ログを復元するソース テーブルと同じスキーマがあります。 既存の復元されたログ テーブルのスキーマは編集できません。 |
テーブル プラン
テーブル内の データにアクセスする頻度と必要なクエリ機能に基づいて、テーブル プランを構成します。
| 表のレイアウト | 推奨されるユース ケース |
|---|---|
| Analytics | 継続的な監視、リアルタイム検出、パフォーマンス分析。 このプランでは、対話型のマルチテーブル クエリでログ データを使用でき、機能とサービスで 30 日間から 2 年間使用できます。 |
| Basic | トラブルシューティングとインシデント対応。 このプランでは、割引されたインジェストと最適化された単一テーブルのクエリを 30 日間使用できます。 |
| 補助 | 詳細ログなどのロータッチ データと、監査とコンプライアンスに必要なデータ。 このプランでは、低コストでデータを取り込める一方、保持期間全体を通して単一テーブルに対するクエリは最適化されません。 |
テーブル プランの選択の詳細については、「Azure Monitor Logs のテーブル プラン」を参照してください。
Retention
各テーブルには、次の 2 つの保持ステージがあります。
| テーブルの保持ステージ | 説明 |
|---|---|
| [対話型の保持] | クエリ、アラート、およびその他のAzure Monitor機能でデータを使用できる期間。 対話型リテンション期間は、Analytics テーブルの場合は 4 日から 730 日の範囲で、Basic テーブルと補助テーブルでは 30 日で固定されます。 |
| 長期保存 | 継続的なクエリで使用できるようにすることなく、コンプライアンスまたは時折調査するために、ワークスペース内のデータを保持する低コストの拡張機能。 長期保有のデータにアクセスするには、検索ジョブを実行します。 |
テーブル レベルの保持設定を使用して、両方のステージをテーブルごとに個別に設定します。
長期保有期間のデータにアクセスするには、検索ジョブを実行します。 検索ジョブは、ワークスペース内のデータセット全体に対して実行されるオンデマンドの非同期クエリであり、長期的な保有期間のデータも含まれます。 詳細については、Azure Monitor ログでジョブを検索するを参照してください。
テーブル スキーマ
テーブル スキーマは、テーブルが保持できるデータを定義する列のセットです。 スキーマには、列名とデータ型が含まれます。
列のデータ型
Tables API では、Log Analytics ワークスペース テーブル内の列に対して次のデータ型がサポートされています。
| タイプ | 説明 |
|---|---|
string |
テキスト値 |
int |
32 ビット整数 |
long |
64 ビット整数 |
real |
倍精度浮動小数点数 |
boolean |
True または False |
dynamic |
JSON オブジェクトまたは配列 |
datetime |
日付と時刻の値 |
guid |
GUID 値は、次のように格納および照会されます。 string |
データ収集規則 (DCR) は ストリーム宣言でデータ型をサポートしますが、 guid 型はサポートしていません。 Azure Monitor ログでは、GUID 値が string 型として格納されます。 表示される guid ラベルは論理型注釈のみで、すべてのインジェスト操作とクエリ操作の string と同じように動作します。
GUID 値を文字列に変換する必要はありません。 Azure Monitor ログでは、ソース データの作成方法に関係なく、GUID 値が文字列として書き込まれます。
テーブルに一致するようにデータを変換する
ログ データがテーブルに到達する前に、データ収集規則 (DCR) は変換を使用して不要なレコードを除外し、テーブル スキーマに一致させます。 処理されたデータのみが格納されるため、この方法によりコストが削減され、ダウンストリーム クエリが簡略化されます。
詳細については、「 Azure Monitor でのデータ収集変換」を参照してください。