すべてのプロダクト
Search
ドキュメントセンター

Simple Log Service:Logstore の管理

最終更新日:Aug 25, 2026

ログストアは、 Simple Log Service (SLS) のストレージユニットで、ログデータの収集、保存、クエリを行います。

コアコンセプト

Logstore とは

Logstore は Simple Log Service (SLS) のデータコンテナです。プロジェクト配下に複数の Logstore を作成し、異なるアプリケーションやソースからのログを分離して管理できます。

また、一部の Alibaba Cloud サービスや SLS 機能は、特定の目的のために専用の Logstore を自動的に作成します。これらの Logstore は、他の種類のデータを受け入れることはできません。例は次のとおりです。

Logstore の仕様比較

SLS は、機能 とコストが異なる Standard と Query の 2 種類の Logstore タイプを提供します。

タイプ

コスト (インデックストラフィック料金の比較)

シナリオ

Standard

USD 0.0875 / GB

このタイプは、インタラクティブ分析、リアルタイムモニタリング、可視化、または可観測性システムの構築に使用します。

Query

USD 0.0146 / GB

このタイプは分析をサポートしていません。分析なしで高速なキーワード検索のみを必要とする、ログアーカイブ、監査ログストレージ、またはトラブルシューティングのシナリオに使用します。代表的なユースケースには、低頻度アクセスでの長期保存 (数か月または数年) が含まれます。

スコープと権限

権限に関する注記 (展開可能)

  • Alibaba Cloud アカウントを使用してログインする場合、デフォルトで完全な権限が付与されており、Logstore を直接管理できます。

  • RAM ユーザーとしてログインするには、必要に応じて Alibaba Cloud アカウントの所有者に、次の 2 つの SLS システムポリシーを要求できます:

    • AliyunLogFullAccess: SLS の完全な管理権限を付与します。

    • AliyunLogReadOnlyAccess: SLS への読み取り専用アクセス権を付与します。

    システムポリシーが要件を満たさない場合は、カスタムポリシーを作成して、きめ細かい権限管理を行ってください。

    操作

    必要な権限

    Logstore の管理

    • log:ListProject

    • log:GetAcceleration

    • log:ListDomains

    • log:GetLogging

    • log:ListTagResources

    • log:GetProject

    • log:ListLogStores

    • log:*LogStore

    • log:*Index

    • log:ListShards

    • log:GetLogStoreHistogram

    • log:GetLogStoreContextLogs

    Logstore のクエリ

    • log:ListProject

    • log:GetAcceleration

    • log:ListDomains

    • log:GetLogging

    • log:ListTagResources

    • log:GetProject

    • log:ListLogStores

    • log:GetLogStore

    • log:GetLogStoreHistogram

    • log:GetIndex

    • log:CreateIndex

    • log:UpdateIndex

    • log:ListShards

    • log:GetLogStoreContextLogs

基本的な Logstore の作成

コンソール

  1. Simple Log Service (SLS) コンソールにログインします。プロジェクトリストで、対象のプロジェクトをクリックします。

  2. ログ管理 > Logstores タブで、+ アイコンをクリックします。

  3. Logstore の作成 ページで、設定を行い、OK をクリックします。

    1. Logstore タイプ:デフォルトは Standard です。

    2. 課金モード:

      • 機能別課金:使用する各リソース (ストレージ、インデックス、読み取り/書き込み操作など) に対して個別に課金され、月次の無料枠が提供されます。小規模なシナリオでのコスト管理に役立ちます。

      • 取り込みデータ量課金:取り込まれた生データ量に対してのみ課金されます。ストレージとコア機能は 30 日間無料で、よりシンプルでコスト効率の高い料金モデルを提供します。

      クイックヒント:データ保持期間が 30 日に近く、インデックスを作成するフィールドが多いほど (特に全文インデックス)、取り込みデータ量課金が適しています。
    3. Logstore 名:プロジェクト内でグローバルに一意である必要があり、作成後は変更できません。

    4. データ保持期間:デフォルトは 30 日です。

    5. その他のすべての設定はデフォルト値のままにします。

    Logstore パラメータ一覧 (展開可能)

    パラメータ

    説明

    Logstore タイプ

    SLS の Logstore は、Standard と Query の 2 つのタイプをサポートしています。シナリオに基づいて選択することで、コストを最適化できます。

    • Standard には、SLS のすべての分析機能が含まれており、リアルタイムモニタリング、インタラクティブ分析、オブザーバビリティシステムの構築に最適です。

    • Query のインデックストラフィック料金は、Standard の 29% です。同じ予算で、Query を使用すると、より低コストでより多くのフィールドにインデックスを作成できます。ただし、Query はキーワード検索のみをサポートし、統計分析はサポートしていません。

    課金モード

    • 機能別課金:SLS の従来の課金モデルです。リソース (ストレージやインデックスなど) および機能 (データ変換やデータ配信など) の実際の使用量に対して、従量課金制で課金されます。

    • 取り込みデータ量課金:取り込まれた生データ量のみに課金される、簡素化された SLS 課金モデルです。取り込み後、30 日間の無料ストレージと、データ変換やデータ配信などの機能への無料アクセスが提供されます。このモデルは、SLS を深く活用する場合にシンプルで予測可能、かつコスト効率に優れています。

    Logstore 名

    Logstore 名は、プロジェクト内でグローバルに一意である必要があり、作成後は変更できません。

    WebTracking

    WebTracking を使用すると、ブラウザ、iOS/Android アプリ、フロントエンドアクセスログを迅速に収集できます。デフォルトでは無効になっています。

    データ保持期間

    保持期間 (日数)。有効な値:1~3650。3650 に設定すると、永続的な保持を意味します。ログは、設定された保持期間に達すると削除されます。

    インテリジェント階層化

    ライフサイクル管理を使用してデータを自動的に階層化します。

    • ホットストレージ:

      • ホットストレージは、頻繁にアクセスされるデータに対応した、スケーラブルで可用性の高いソリューションです。

      • リアルタイムアクセスをサポートし、高性能なログクエリと分析が可能です。頻繁なクエリと分析のシナリオに最適です。

    • 低頻度アクセスストレージクラス

      • 低頻度アクセスストレージクラス (旧コールドストレージ) は、クエリ、分析、可視化、アラート、配信、変換の全機能を維持しながら、長期ストレージコストを削減します。

      • 問題のバックトレースなど、低頻度のクエリと分析のシナリオに適しています。

    • アーカイブストレージ

      • アーカイブストレージは、ホットストレージや低頻度アクセスストレージよりもさらに低コストな、クエリと分析が可能な長期ストレージオプションです。

      • 長期的な監査ログの保持に最適です。

    シャード数

    各シャードは、5 MB/s の書き込みスループットと 10 MB/s の読み取りスループットに対応しています。データトラフィックがシャードの容量を超える場合は、シャードを分割できます。データトラフィックがシャードの最大読み取り/書き込み容量を下回る場合は、シャードを結合してコストを節約できます。

    自動シャーディング

    書き込みトラフィックが既存のシャードの読み取り/書き込み容量を 5 分以上超える場合、自動シャーディングを有効にすると、データ量に基づいてシャード数が増加します。

    最大シャード数

    自動シャーディングを有効にすると、最大 256 個のシャードを自動的に作成できます。

    パブリック IP の記録

    ログを受信すると、システムは自動的にクライアントのパブリック IP アドレスとログ到着時刻を追加します。

API

Logstore の作成

Logstore 設定の変更

次のパラメータは、作成時に設定できます。このセクションでは、Logstore の設定変更を例に説明します。

  1. image [ログストレージ] をクリックします。[Logstores] ページで、対象の Logstore にカーソルを合わせ、変更 を選択します。

  2. Logstore のプロパティで、シナリオに応じて関連する設定を変更します。

特定ログの削除またはデータ保持期間の設定

コンソール

基本情報変更 をクリックし、データ保持期間を調整してから 保存 をクリックします。

Simple Log Service では、[ログの論理削除] 機能を使用して特定のログエントリを削除できます。LogStore の [クエリと分析] ページで、クエリ条件を入力し、時間範囲を選択してから [ログの論理削除] をクリックして、削除タスクを送信します。削除されたログエントリは、その後のクエリ結果に表示されなくなり、保持期間の終了後に完全に削除されます。また、データ保持期間を変更して期限切れログを一括削除することも、課金の停止または LogStore の削除によってすべてのログを削除することもできます。
  • 日数限定:有効値は 1~3650 です。値を 3650 に設定すると、永久保持が有効になります。ログは、保持期間の終了時に削除されます。

  • 恒久的な保管::Logstore 内のログを無期限に保持します。

説明

変更はすぐに有効になりますが、期限切れデータの削除には時間がかかる場合があります。

変更が有効になったことの確認

変更を保存した後、LogStore に再度カーソルを合わせて 変更 をクリックします。LogStore のプロパティで、[データ保持期間] に表示される日数が設定した値になっていることを確認します。これにより、設定が適用されたことを確認できます。LogStore で永久保持が有効になっている場合、カスタムの日数は表示されません。これは、この LogStore のログが設定を変更するまで保持されることを意味します。

データ保持期間を変更できない、または保存に失敗する場合のトラブルシューティング

[データ保持期間] を編集できない (保持期間の編集ボタンがグレーアウトしている、または保存期間を選択できない) 場合、または変更を保存するとエラーが返されてライフサイクル設定を完了できない場合は、次の項目を順序どおりに確認してください:

  • LogStore が、クラウドサービスまたは Simple Log Service によって自動的に作成された専用 Logstore である場合。自動作成は、Redis 専用 Logstore、MongoDB 専用 Logstore、および Simple Log Service 管理専用 Logstore に適用されます。これらのデータ保持期間は、対応するクラウドサービスによって管理されます。Simple Log Service コンソールで変更を保存すると、該当するクラウドサービスのコンソールで操作するように促すメッセージが表示されます。カスタムの保持期間を使用するには、対応するクラウドサービスのコンソールで調整するか、業務ログ用に標準の LogStore を作成してください。

  • LogStore が、internal- プレフィックスを持つシステム予約 Logstore である場合。例:internal-operation_loginternal-alert-historyinternal-etl-log。このような LogStore は、特定のデータ取り込み設定にすでにバインドされています。コンソールには、現在の LogStore が特定のデータ取り込み用に設定されていることが示されるため、設定項目をカスタマイズできません。

  • 現在のアカウントに十分な権限がない場合。LogStore の設定変更には、対象プロジェクトに対する LogStore 管理権限、つまり本トピックの [スコープと権限] セクションに記載されている log:*LogStore などの権限が必要です。RAM ユーザーとしてログインしている場合は、Alibaba Cloud アカウントの所有者に、AliyunLogFullAccess システムポリシー、またはこれらの権限を含むカスタムポリシーをリクエストしてください。

  • コンソールページが正しく表示されていない場合。ページを更新するか、別のブラウザに切り替え、対象の LogStore に再度カーソルを合わせて 変更 をクリックし、[データ保持期間] をもう一度変更してください。

  • 標準の LogStore の場合、このセクションの [API] タブで説明しているように ttl を変更して設定を完了することもできます。前述の専用 Logstore の場合は、引き続き対応するクラウドサービスのコンソールで保持期間を調整する必要があります。

API

UpdateLogstore API の ttl 値を更新してデータ保持期間を調整します。

ティアリングによるストレージコストの最適化

コンソール

  1. 基本情報変更 をクリックし、インテリジェントティアリングを有効にします。

  2. ストレージポリシー を設定します。3 つのティアすべての日数の合計は、データ保持期間と一致する必要があります。

    • ホットストレージ:最小 7 日。

    • IA ストレージクラス:最小 30 日。

    • アーカイブストレージ:最小 60 日。

    [データ保持期間][指定日数] に設定し、[インテリジェントティアリング] を有効にして、[ストレージポリシー] でティア移行を設定します。ホットストレージは期間終了後に IA ストレージクラスへ自動的に移行し、IA ストレージクラスはアーカイブストレージへ移行します。アーカイブストレージは期間終了後に自動的に削除されます。

  3. 保存 をクリックします。詳細については、「インテリジェントティアリング」をご参照ください。

API

Update Logstorettlhot_ttlinfrequentAccessTTL の値を更新して、ストレージティアの保持ポリシーを動的に調整します。

フロントエンドログの収集

Simple Log Service は、ミニプログラム、モバイルアプリ (iOS/Android)、ブラウザーからログを収集するための WebTracking を提供します。

この機能は 2 つの方法で使用できます。

  • 送信に STS 認証を使用します。この方法は本番環境に適しており、Logstore の設定変更は不要です。

  • OpenAPI 経由で匿名送信を使用します。この方法はテスト専用であり、下記のとおり、Logstore で設定を有効にする必要があります。

コンソール

基本プロパティで 変更 をクリックして WebTracking を有効にし、保存 をクリックします。

API

Update Logstoreenable_tracking パラメーターを true に設定することで、WebTracking を有効にします。

パブリック IP アドレスとログ到着時間の自動追加

有効化すると、以降のログの取り込み時に以下が自動的に追加されます。

  • __tag__:__client_ip__: ログソースデバイスのパブリック IP アドレス。

  • __tag__:__receive_time__: ログが Simple Log Service サーバーに到着した時間。UNIX タイムスタンプ (1970-01-01 00:00:00 UTC からの秒数) 形式。

コンソール

「基本プロパティ」で、変更 をクリックして「パブリック IP の記録」を有効にし、「保存」をクリックします。

API

Update Logstore API で appendMeta パラメーターを設定すると、パブリック IP の記録が有効になります。

シャードによる取り込みパフォーマンスの調整

各シャードは、取り込みでは 5 MB/s または 500 書き込み/秒、消費では 10 MB/s または 100 読み取り/秒をサポートします。 これらはソフトリミットです。システムはこれらの制限を超えるリクエストにも対応しようとしますが、サービス品質は保証されません。トラフィックがシャードの容量を超える場合は、シャードを分割して容量を増やしてください。

コンソール

[基本プロパティ] で 変更 をクリックし、[自動シャーディング] を有効にし、シャードの上限を設定し、保存 をクリックします。

Simple Log Service (SLS) は、個々のシャードの分割とマージ をサポートしています。

API

シャードの分割

シャードのマージ

課金の停止または Logstore の削除

警告

一度削除されると、Logstore 内のすべてのログデータは完全に失われ、回復できません。操作は慎重に行ってください。

コンソール

  1. 削除前のクリーンアップ

    1. Logstore を削除する前に、関連するすべての Logtail 収集設定を削除してください。これは、コンソールが Logstore を削除する際に実行する唯一の厳格な前提条件チェックです。Logstore が Logtail 収集設定にまだ関連付けられている場合、コンソールは Logtail 設定が存在し、最初に削除する必要があることを報告するため、削除は続行できません。したがって、Logstore を削除できない場合は、まずその Logstore のすべての Logtail 収集設定を削除してから、再度 Logstore を削除してください。

    2. この Logstore で LogShipper が有効になっている場合は、削除する前に、新しいデータの書き込みを停止し、既存のすべてのデータが正常に転送されたことを確認してください。

    3. プロジェクトの [リソースリリース保護] はプロジェクト自体に適用されます。有効にした後、プロジェクトを削除するには、手動で無効にする必要があります。単一の Logstore の削除はこの機能の影響を受けないため、無効にする必要はありません。

  2. 削除手順

    1. ログ管理 > Logstores タブで、対象の Logstore にカーソルを合わせ、削除 を選択します。

    2. 警告 ダイアログボックスで、削除してもよろしいですか。 をクリックします。

  3. 削除後の注意事項

    1. 削除当日もストレージ料金は発生します。翌日以降、料金は発生しません。削除の 3 日後から、この Logstore の請求書は届かなくなります。

    2. 削除後、この Logstore をソースとして使用するすべてのエクスポートタスク、データ変換タスク、スケジュールされた SQL タスク、およびこの Logstore をターゲットとするインポートタスクは削除されます。

API

Logstore の削除

実運用シナリオ向けの設定例

大規模ワークロード向けのリアルタイムモニタリングと分析

オンラインアプリケーションが大量のログをリアルタイムで生成します。障害が発生した場合は、エラーログを迅速に特定し、リアルタイムアラートを使用してパフォーマンスメトリクス (QPS や応答レイテンシなど) を監視する必要があります。

推奨構成Standard Logstore + 取り込みデータ量課金 + 自動シャーディング

理由Standard Logstore は、分析、リアルタイムモニタリング、可視化をサポートします。取り込み量が多く、大規模なインデックスが必要になる可能性がある場合は、取り込みデータ量課金 の方がコスト効率に優れ、自動シャーディング により取り込みと分析のパフォーマンスを安定させられます。

コンプライアンス、監査、規制対応のシナリオ

業界規制により、監査のためにユーザー操作ログとセキュリティログを 6 か月以上保存する必要がありますが、日次のクエリと分析の頻度は非常に低いです。

推奨構成Query Logstore + インテリジェント階層化

理由Query Logstore は、Standard よりも低いインデックス トラフィックコストで検索専用のワークロードをサポートします。インテリジェント階層化 は、古いログを低コストのストレージティアへ自動的に移動することで、長期的なストレージコストを削減します。

関連リファレンス

機能別課金における Logstore の比較

Query Logstore は機能別課金のみをサポートします。このモデルにおける Standard Logstore と Query Logstore の比較は次のとおりです:

比較項目

Standard

Query Logstore

コスト

インデックス トラフィック

USD 0.0875/GB

USD 0.0146/GB

機能

データ取り込み (アプリケーションログのみ)

対応

クラウド製品ログの取り込みはサポートされません。

インテリジェント階層化の有効化

対応

対応

検索

対応

対応

分析 (SQL ステートメント)

対応

非対応

コンテキストクエリ

対応

対応

LiveTail

対応

対応

LogReduce

対応

非対応

リインデックス

対応

対応

ダッシュボード

対応

非対応

アラート

対応

クエリベースのアラートのみをサポートします。

スケジュールされた SQL

対応

非対応

データ変換

対応

対応

データ転送

対応

対応

標準消費

対応

対応

制限事項

取り込みデータ量課金では、SLS のすべての機能セットをサポートします。クエリと分析、データ変換、インテリジェントアラート、消費/転送などの付加価値機能は追加料金なしで利用できますが、次のとおりクォータ制限があります。

クォータの上限

説明

データ変換量

Logstore あたり最大 100 TB/月。

スケジュールされた SQL データ量

Logstore あたり最大 20 TB/月。

転送データ量

Logstore あたり最大 100 TB/月。

消費データ量

Logstore あたり最大 100 TB/月。

アラートタスクの計算量

Logstore あたり最大 100 TB/月。

課金概要

Logstore の料金は、主に選択した 課金モード によって決まります。

  • 機能別課金:ストレージ容量、インデックス トラフィック、読み取り/書き込み操作、シャード数など、リソースの実際の使用量に対して個別に課金されます。

  • 取り込みデータ量課金:取り込んだ未加工データ量に対してのみ課金され、30日間の無料ストレージと複数の無料機能が含まれます。

料金の主なポイント

  • Standard Logstore のインデックス トラフィックUSD 0.0875/GB。

  • Query Logstore のインデックス トラフィックUSD 0.0146/GB。

コスト最適化のヒント

  • ログの保持期間が 30 日に近い、または 30 日を超える場合は、通常 取り込みデータ量課金 の方がコスト効率に優れています。

  • アーカイブおよび取得専用のシナリオでは、Query Logstore を使用してインデックスコストを削減します。

  • インテリジェント階層化 を使用して、アクセス頻度の低いデータを低コストのストレージティアへ移動します。

よくある質問

Logstore を作成できない

デフォルトでは、プロジェクトあたり最大 200 個の Logstore を作成できます。未使用の Logstore を削除するか、次の手順でクォータの引き上げをリクエストしてください。

  1. Simple Log Service コンソールにログインし、プロジェクトリストで対象のプロジェクトをクリックします。

  2. プロジェクト ページで、概要 > 基本情報 > リソースクォータ に移動し、管理 をクリックします。リソースのクォータ パネルで、Logstore のクォータ上限を調整し、保存 をクリックしてリクエストを送信します。変更が反映されるまで約 1 時間かかります。

SLS でログが見つからない

  • プロジェクトまたは Logstore が見つからない

    Project または Logstore を手動で削除した場合、ログは復旧できません。ActionTrail を使用して、過去 90 日以内の削除イベントを確認してください。

  • アカウントの支払い遅延が 7 日を超えて継続すると、サービスは放棄されたと見なされます。プロジェクトは回収され、データは完全に削除されます。詳細については、「Overdue payments」をご参照ください。

ログストレージコストを削減する方法

LogStore に収集されたログのデータソースを特定する方法

プロジェクトに自分が作成していない LogStore が含まれている場合、またはどのクラウドサービスが LogStore にログを書き込んでいるのか分からない場合は、次の方法を使用してデータソースとログソースサービスを確認してください:

  • LogStore のデータ取り込み設定を確認します。Logtail 収集設定、およびクラウドサービスログの転送またはインポート設定は、LogStore に書き込むデータソースに直接対応します。これはソースを確認する最も直接的な方法です。

  • LogStore の [クエリと分析] ページで Raw ログ を表示します。各ログエントリには、ソース識別子フィールド __source__ が表示されます。ファイルから Logtail が収集するログには、__tag__:__path__ のような予約済みフィールドも含まれます。これらの名前は SLS の予約語であり、これらのフィールドを使用してログの実行時ソースを特定できます。

  • プロジェクトの説明を確認します。クラウドサービスによって自動的に作成されたプロジェクトには、通常、説明に用途とソースが記載されています。

  • internal- プレフィックスを持つ LogStore (例: internal-operation_loginternal-alert-historyinternal-etl-log) は、特定のデータ取り込み用に SLS によって予約されています。これらの LogStore では、コンソールに現在の LogStore が特定のデータ取り込み用に設定されており、設定項目をカスタマイズできないことが表示されます。

  • GetLogStore が返す productType フィールドをソースの判定に使用しないでください。このフィールドは SLS OpenAPI で定義されておらず、値も標準化されていません。補助的な情報としてのみ使用し、結論の唯一の根拠にしないでください。

LogStore では、Raw ログの保存はデフォルトで有効ですか?

はい。Raw ログの保存はデフォルトで有効であり、手動での設定は不要です。ログが LogStore に書き込まれると、Raw ログが保存されます。また、SLS では Raw ログの保存に関する個別のスイッチは提供されません。ログの保持期間は、LogStore の データ保持期間 によって決まります。

確認するには、Simple Log Service コンソールにログインし、対象の LogStore の [クエリと分析] ページに移動して時間範囲を選択し、[Raw Logs] タブで書き込まれたログを確認します。[Raw Logs] タブは、LogStore でインデックスが無効になっている場合でも使用できます。ページにインデックスが有効になっていないと表示されている場合、インデックスが有効になった後に書き込まれたデータのみクエリできます。