Simple Log Service:データビュー (ストアビュー) の概要

ストアビューとは

Simple Log Service プロジェクトにおいて、StoreView、LogStore、MetricStore はすべて重要なリソースです。しかし、ストアビューはログを保存するための物理的なリソースではありません。これは、複数の Logstore または Metricstore 間の関連付けを管理・保存するために、Logstore と Metricstore に基づいて作成される仮想リソースです。ストアビューを使用すると、異なる Logstore または Metricstore のログに対して統一されたクエリを実行できます。ただし、ストアビューはログの変更操作をサポートしていません。ストアビューは、ログタイプのストアビューと時系列タイプのストアビューに分類されます。ログタイプのストアビューは、異なる Logstore からのデータのクエリと分析をサポートし、Structured Process Language (SPL) 構文を使用して関連ストアを事前定義できます。時系列タイプのストアビューは、異なる Metricstore をまたいだデータクエリのみをサポートします。

[ログタイプの StoreView]/[時系列タイプの StoreView] では、異なる [Logstore]/[Metricstore] からのログの内容に対して関連クエリを実行できます。 たとえば、age フィールドが Logstore1 と Logstore2 に含まれており、その 2 つの Logstore が StoreView1 に関連付けられている場合、StoreView1 での age フィールドのクエリは、Logstore1 と Logstore2 からのすべての結果を返します。

権限

ストアビューを Resource Access Management (RAM) ユーザーとして、または RAM ロールを引き受けて使用する場合、必要な権限を持っている必要があります。Alibaba Cloud アカウントを使用して RAM ユーザーまたは RAM ロールに権限を付与する方法の詳細については、「RAM ユーザーの作成と権限付与」、「信頼できる Alibaba Cloud サービスに対する RAM ロールの作成と権限付与」、および「RAM ロールを使用した Alibaba Cloud アカウントをまたいだリソースへのアクセス」をご参照ください。

ユーザーには、システムポリシーまたはカスタムポリシーを付与できます。

• システムポリシー：Alibaba Cloud によって作成および維持されます。システムポリシーは使用できますが、変更はできません。

  • Simple Log Service の読み取り専用権限：AliyunLogReadOnlyAccess。

  • Simple Log Service の管理権限：AliyunLogFullAccess。

• カスタムポリシー：カスタムポリシーは作成、更新、削除が可能です。ポリシーのバージョンはご自身で管理する必要があります。

  • ストアビューを作成したり、ストアビューでデータをクエリしたりする場合、RAM ユーザーまたは RAM ロールは、関連するすべての Logstore および Metricstore に対してLogstore 内のログをクエリする権限を持っている必要があります。権限を付与するには、カスタムポリシーに以下の内容を追加します。

    重要

    • アクセスポリシー内の Logstore には、Logstore と Metricstore が含まれます。このポリシーは、操作対象が Metricstore の場合にも適用されます。

    • アクセスポリシー内の storeview には、ログタイプのストアビューと時系列タイプのストアビューが含まれます。

    {
      "Version": "1",
      "Statement": [
        {
          "Action": "log:GetLogStoreLogs",
          "Resource":[
            "acs:log:*:*:project/${projectName}/Logstore/*",
            "acs:log:*:*:project/${projectName}/storeview/*"
          ],
          "Effect": "Allow"
        }
      ]
    }

制限事項

• 各 Simple Log Service プロジェクトは、合計で最大 10 個のログタイプのストアビュー/時系列タイプのストアビューをサポートします。

• 各ログタイプのストアビュー/時系列タイプのストアビューは、最大 50 個の Logstore/Metricstore に関連付けることができます。

• ログタイプのストアビュー/時系列タイプのストアビュー内のすべての Logstore/Metricstore は、同じ Alibaba Cloud アカウントに属している必要があります。

• ストアビューは、中国本土内のリージョン間でのみアソシエーション分析をサポートします。国境を越えるシナリオでのクロスリージョン分析はサポートされていません。

事前定義機能

概念

ログタイプのストアビューは、ストアビューの作成時に SPL 構文を使用して関連ストアを事前定義することをサポートします。事前定義された SPL は、SPL の命令と関数およびSPL の命令と関数のキーワードのみをサポートします。事前定義は、一部のデータをフィルタリングしたり、集計と分析でフィールド名が一致しない問題を解決したりするシナリオで使用できます。集計と分析には、一貫したフィールドキーが必要です。例えば、Logstore1 の a フィールドと Logstore2 の b フィールドを集計するには、extend a = b を使用して列名を統一する必要があります。詳細については、「例」をご参照ください。

制限事項

現在、ログタイプのストアビューは事前定義をサポートしています。時系列タイプのストアビューは事前定義をサポートしていません。

サポートされる命令

ログタイプのストアビューの事前定義は、SPL の命令と関数およびSPL の命令と関数の演算子をサポートします。

SQL と SPL がサポートする関数の詳細については、「関数概要」をご参照ください。

例

ログタイプのストアビューを作成または変更するには、「ログタイプのデータビューの作成」をご参照ください。

例えば、Logstore1 の a フィールドと Logstore2 の b フィールドを集計する場合、ストアビューの作成または変更時に extend a = b (事前定義) を使用して列名を統一できます。

例 1

Logstore1 で * | where a>1 を事前定義します。これは、ストアビューでは a>1 の条件を満たすログのみが対象となり、後続の分析で使用されることを意味します。

例 2

ストアビュー内の LogStore 1 に対して事前定義された SPL 文 * | extend b = a は、LogStore 1 に a フィールドと同じ値を持つ b フィールドを追加し、後続の集計に使用します。

クエリ機能

ログタイプのストアビュー

ログタイプの StoreView は、Logstore 間クエリをサポートします。たとえば、[ログタイプの StoreView] が Logstore-1 および Logstore-2 の 2 つのストアと関連付けられており、両方のストアに request_method フィールドが含まれている場合、クエリ文 (request_method:GET or request_method:POST) and status in [200 299] は、Logstore-1 および Logstore-2 の両方から該当するログ結果を返します。ログタイプの StoreView でのクエリの詳細については、「クエリ構文および関数」をご参照ください。

ログ型 [StoreView] に、同一のログ内容を持つ 2 つの Logstore が含まれているとします。キーワードをクエリすると、異なる Logstore のすべての結果が返されます。ログがどの Logstore から来たかを判断するために、タグフィールドを使用できます。

時系列タイプのストアビュー

時系列タイプのストアビューは、クロスストアクエリをサポートします。例えば、ある時系列タイプのストアビューが metricstore1 と metricstore2 の 2 つのストアに関連付けられている場合、クエリボックスに Prometheus Query Language (PromQL) 文を直接入力できます。バックエンドの計算エンジンが自動的にクロス Metricstore 計算を完了します。時系列タイプのストアビューでのクエリの詳細については、「時系列データのクエリと分析の構文」をご参照ください。時系列タイプのストアビューを作成または変更するには、「Metricstore をまたいだデータのクエリ」をご参照ください。

分析機能

基本概念

データビューは、クロスストアの集計と統計分析をサポートします。例えば、あるストアビューが LogStore-1 と LogStore-2 に関連付けられており、両方の Logstore にフィールド a が含まれている場合、クエリ文 * | select a, count(1) group by a は、LogStore-1 と LogStore-2 の両方からのフィールド `a` の合計カウントを返します。

集計と分析には一貫したフィールドキーが必要なため、事前定義を使用して一部のデータをフィルタリングし、ログの内容は同じでもキー名が異なるシナリオでフィールド名を変更できます。詳細については、「事前定義機能」をご参照ください。

制限事項

現在、ログタイプのストアビューはデータ分析をサポートしています。時系列タイプのストアビューはデータ分析をサポートしていません。

サポートされる関数

SQL と SPL がサポートする関数の詳細については、「関数概要」をご参照ください。

例

例 1

[ログタイプの StoreView] は、同じサービスの異なる Logstore に関連付けられており、Logstore 内のログの内容は同一です。 このシナリオでは、まず、異なる Logstore のインデックス構成が同じであるかどうかを確認します。 たとえば、すべての Logstore にフルテキストインデックスがあるか、または必要なフィールドインデックス構成に一貫性があるかどうかを確認します。 次に、関連付ける Logstore を [ログタイプの StoreView] に追加します。

[ログタイプ StoreView] を作成すると、通常どおり SQL を使用して分析できます。 次の図は、過去 15 分間のさまざまな status 値の統計が、2 つの Logstore のすべてのログの集約であることを示しています。

例 2

[ログタイプ StoreView] は、同じサービスの異なる Logstore に関連付けられていますが、Logstore 内の一部のログフィールドの名前が異なります。 この場合、事前定義された SPL 文を使用して新しいフィールドを再定義し、他の Logstore のキー名に合わせることができます。 次の図に示すように、SPL 文 *|extend request_method = method を使用して、method フィールドの名前を request_method に変更します。 プレビューデータをクリックして、事前定義された結果データをプレビューします。

その後、 request_method を使用してクエリと分析を行うことができます。

ストアビューと通常のストアの違い

参考

• Logstore をまたいだデータのクエリと分析

• Metricstore をまたいだデータのクエリ