Simple Log Service:SLS Query Skill によるインテリジェントなログクエリと分析

プロンプトのベストプラクティス

プロンプトの品質は、クエリ結果の精度に直接影響します。良いプロンプトには、次の情報が含まれます。

• プロジェクト名と Logstore 名。

• 明確なクエリまたは分析の意図。例：「リクエストレイテンシの前日比の変動を分析し、1 分あたりの平均レイテンシを計算する」

• クエリの時間範囲。例：「過去 15 分間」または「2026 年 4 月 24 日 10:00 から 11:00 (UTC+8)」

• 希望する出力形式。例：「生ログを返す」、「上位 10 件を計算する」、「1 分ごとの傾向を表示する」、「これらのフィールドのみを返す」

クエリの効率を向上させ、コストを削減するには：

• フルスキャンを避けるため、時間範囲をできるだけ狭めてください。

• 曖昧な説明を使用するのではなく、status や request_uri などの正確なフィールド名を指定してください。

• Top-N の結果が必要な場合は、「Top 10」のようにプロンプトで数を指定してください。

シナリオ1：過去 15 分間の 5xx エラーログのクエリ

プロンプト

Query SLS Logstore where Project=prod-web and Logstore=nginx-access for requests with status >= 500 in the last 15 minutes, sorted in descending order by time.

エージェントの出力例

クエリモード：インデックスクエリ。
理由：ユーザーは集計や複雑な分析を伴わない、条件付きの生ログ取得をリクエストしたため、インデックスクエリが選択されました。status フィールドには数値型のインデックスが設定されているため、範囲クエリを直接使用できます。

実行されたコマンド：
aliyun sls get-logs-v2 \
  --project prod-web \
  --logstore nginx-access \
  --from 1777016700 \
  --to 1777017600 \
  --query 'status>=500' \
  --line 100 \
  --offset 0 \
  --reverse true

クエリ結果：
| Time | status | request_uri | upstream_status | request_time | message |
| --- | ---: | --- | ---: | ---: | --- |
| 2026-04-24 15:59:31 | 502 | /api/order/create | 502 | 1.238 | upstream connect timeout |
| 2026-04-24 15:58:44 | 500 | /api/pay/notify | 500 | 0.412 | internal server error |
| 2026-04-24 15:57:09 | 502 | /api/order/create | 502 | 1.104 | bad gateway |

結論：過去 15 分間の 5xx 生ログが時間の降順で返されました。最新のエラーは /api/order/create に集中しています。

シナリオ2：5xx エラーのある上位 10 件の API の検索

プロンプト

Find the top 10 APIs with the most 5xx errors in the last hour in the SLS Logstore prod-web/nginx-access.

エージェントの出力例

クエリモード：インデックスクエリ + SQL。
理由：5xx エラーが最も多い上位 10 件の API を見つけるには、まずインデックスクエリを使用してステータスコード 500 から 599 をフィルターします。次に、SQL を使用して request_uri でグループ化し、エラーをカウントして結果をソートします。

実行されたコマンド：
aliyun sls get-logs-v2 \
  --project prod-web \
  --logstore nginx-access \
  --from 1777014000 \
  --to 1777017600 \
  --query 'status in [500 599] | SELECT request_uri, count(*) AS errors FROM log GROUP BY request_uri ORDER BY errors DESC LIMIT 10'

クエリ結果：
| Rank | request_uri | errors |
| --- | --- | ---: |
| 1 | /api/order/create | 186 |
| 2 | /api/pay/notify | 73 |
.....
| 10 | /api/user/login | 1 |

結論：過去 1 時間で 5xx エラー数が最も多い API は /api/order/create です。そのエラー数は他の API よりも大幅に高くなっています。まずこの API とそのバックエンドの依存関係を調査してください。

シナリオ3：過去 1 時間のレイテンシ傾向を昨日の同時刻と比較

プロンプト

In the SLS Logstore prod-web/nginx-access, analyze the change in average latency over the last hour compared to the same period yesterday. Calculate the average value per minute and determine if there are any significant latency anomalies.

エージェントの出力例

クエリモード：インデックスクエリ + SQL
理由：このリクエストでは、過去 1 時間と昨日の同時刻の両方について、1 分あたりの平均レイテンシを集計する必要があります。その後、結果を分単位で揃えて、変化量と変化率を計算します。

実行されたコマンド (過去 1 時間)：
aliyun sls get-logs-v2 \
  --project prod-web \
  --logstore nginx-access \
  --from 1777014000 \
  --to 1777017600 \
  --query "* | SELECT date_trunc('minute', __time__) AS minute, avg(request_time) AS avg_latency FROM log GROUP BY minute ORDER BY minute LIMIT 60"

実行されたコマンド (昨日の同時刻)：
aliyun sls get-logs-v2 \
  --project prod-web \
  --logstore nginx-access \
  --from 1776927600 \
  --to 1776931200 \
  --query "* | SELECT date_trunc('minute', __time__) AS minute, avg(request_time) AS avg_latency FROM log GROUP BY minute ORDER BY minute LIMIT 60"

クエリ結果：
| Minute | Current average latency | Average latency (yesterday) | Change | Change rate |
| --- | ---: | ---: | ---: | ---: |
| 2026-04-24 15:00 | 0.132s | 0.118s | +14ms | +11.9% |
| 2026-04-24 15:01 | 0.141s | 0.116s | +25ms | +21.6% |
| 2026-04-24 15:02 | 0.338s | 0.129s | +209ms | +162.0% |
| 2026-04-24 15:03 | 0.351s | 0.131s | +220ms | +167.9% |

結論：過去 1 時間の全体的な平均レイテンシは、昨日の同時刻よりも高くなっています。最も顕著な増加は 15:02 から 15:03 の間に発生し、平均レイテンシは 160% 以上増加しました。request_uri、upstream_addr、またはサービスディメンションでドリルダウンして、レイテンシ増加の原因を特定してください。

シナリオ4：クエリ結果に基づくフォローアップの質問

SLS Query Skill はマルチターンの会話をサポートしています。以前のクエリ結果に基づいてフォローアップの質問をすることで、調査範囲を段階的に絞り込むことができます。

最初のプロンプト

SLS Logstore の prod-web/nginx-access で、過去 1 時間に 5xx エラーが最も多かった上位 5 件の API を検索してください。

2 番目のプロンプト (最初の結果に基づくフォローアップ)

/api/order/create API について、エラーが集中して発生したか、均等に分散していたかを確認するために、1 分ごとのエラー数の傾向を表示してください。

3 番目のプロンプト (さらなるドリルダウン)

15:02 から 15:05 の間の /api/order/create の 5xx 生ログを表示し、upstream_addr と message フィールドを返してください。

フォローアップの質問をすることで、高レベルの統計から特定の期間の生ログまでドリルダウンし、障害の根本原因を迅速に特定できます。

Alibaba Cloud CLI と SLS プラグインを手動でインストールする必要がありますか？

ほとんどの場合、手動でのインストールは不要です。エージェントでクエリリクエストを送信すると、エージェントは自動的に環境 (aliyun version) を確認し、AI モードを有効にし、User-Agent を設定し、プラグインを更新します。

Alibaba Cloud CLI がローカルマシンにインストールされていない、またはバージョンが古すぎる場合、エージェントはインストールまたはアップグレードの手順を提示します。エージェントが提供するコマンドをローカル環境で実行して、セットアップを完了してください。

Alibaba Cloud アカウントの認証情報を設定するにはどうすればよいですか？

エージェントのプロンプトに従ってアカウントの認証情報を設定するか、aliyun configure コマンドを手動で実行できます。AK、StsToken、OAuth、RamRole など、複数の認証情報設定方法がサポートされています。詳細については、「ID と認証情報の設定と管理」をご参照ください。

内部の同一リージョンエンドポイント、アクセラレーションエンドポイント、カスタムドメインはサポートされていますか？

はい。プロンプトに --endpoint <domain_name> パラメーターを含めることで、特定のエンドポイントを使用するようエージェントに指示できます。

クエリ結果が不正確な場合はどうすればよいですか？

以下を確認し、最適化してください。

• 対象のフィールドのインデックスが正しく設定されており、フィールドタイプがクエリ条件と一致していることを確認します。たとえば、status フィールドは text 型ではなく long 型である必要があります。

• 曖昧さを避けるため、プロンプトで明確なフィールド名、時間範囲、および希望する形式を指定してください。

• エージェントから返されたクエリ文を確認し、ロジックが正しいかチェックしてください。フォローアップの質問を使用して、クエリ条件を絞り込んでください。

IndexConfigNotExist エラー

このエラーは、対象の Logstore にインデックス設定がないか、インデックス設定が空であることを示します。

解決策：Simple Log Service コンソールで、対象の Logstore のインデックスを作成します。インデックスが作成された後、新しいデータがインデックス付けされるのを待ってから、再度クエリを実行します。

Unauthorized エラー

このエラーは、現在のアカウントまたは RAM ユーザーに必要な権限がないことを示します。

解決策：現在のアカウントに以下の権限を付与してください。

ProjectNotExist エラー

このエラーは通常、プロジェクト名が正しくない、リージョンが間違っている、または間違ったエンドポイントにアクセスしている場合に発生します。

解決策：以下の情報を確認してください。

• プロジェクト名が正確かどうか。

• リージョンがプロジェクトのリージョンと一致しているかどうか。

• お使いのネットワーク環境が、内部の同一リージョンエンドポイントを必要とするかどうか。