Simple Log Service:SLS クエリスキルを使用したインテリジェントログクエリと分析

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

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

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

• 明確なクエリまたは分析の意図。例：「リクエストレイテンシの前年比の変化を分析し、分単位で平均レイテンシを計算する。」

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

• 希望する出力形式。例：「生ログを返す」「上位 10 件を計算する」「分単位でトレンドを表示する」「これらのフィールドのみを返す」。

クエリの効率を向上させ、コストを削減するには次のようにします。

• できるだけ時間範囲を絞り込み、フルスキャンを回避します。

• status や request_uri など、正確なフィールド名を指定し、曖昧な記述を避けます。

• Top-N の結果が必要な場合は、プロンプトで「上位 10 件」など件数を指定します。

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

プロンプト

Project=prod-web かつ Logstore=nginx-access の SLS Logstore で、過去 15 分間のステータスが 500 以上のリクエストを、時刻の降順でクエリします。

エージェント出力の例

クエリモード：インデックスクエリ
理由：ユーザーが条件に基づいて生ログをリクエストしており、集計、ソート、分析、フィールドプロジェクションは含まれていません。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-25 15:59:31 | 502 | /api/order/create | 502 | 1.238 | upstream connect timeout |
| 2026-04-25 15:58:44 | 500 | /api/pay/notify | 500 | 0.412 | internal server error |
| 2026-04-25 15:57:09 | 502 | /api/order/create | 502 | 1.104 | bad gateway |

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

シナリオ 2：5xx エラーが最も多い上位 10 件の API の検索

プロンプト

SLS Logstore prod-web/nginx-access で、過去 1 時間で 5xx エラーが最も多かった上位 10 件の API を見つけます。

エージェント出力の例

クエリモード：インデックスクエリ + 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 時間のレイテンシトレンドと前日同時刻との比較

プロンプト

SLS Logstore prod-web/nginx-access で、過去 1 時間の平均レイテンシを、前日同時刻と比較して分析します。分単位で平均値を計算し、レイテンシに大きな異常があるかどうかを判断します。

エージェント出力の例

クエリモード：インデックスクエリ + SQL
理由：リクエストでは、過去 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-25 15:00 | 0.132s | 0.118s | +14ms | +11.9% |
| 2026-04-25 15:01 | 0.141s | 0.116s | +25ms | +21.6% |
| 2026-04-25 15:02 | 0.338s | 0.129s | +209ms | +162.0% |
| 2026-04-25 15:03 | 0.351s | 0.131s | +220ms | +167.9% |

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

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

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

最初のプロンプト

SLS Logstore prod-web/nginx-access で、過去 1 時間で 5xx エラーが最も多かった上位 5 件の API を見つけます。

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

/api/order/create API について、分単位でエラー数のトレンドを表示し、エラーがバースト的に発生したか、均等に分散していたかを確認します。

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

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

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

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

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

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

Alibaba Cloud アカウントの認証情報を設定する方法

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

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

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

クエリ結果が不正確な場合の対処方法

次の点を確認して最適化してください。

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

• プロンプトで明確なフィールド名、時間範囲、希望する形式を指定し、曖昧さを回避します。

• エージェントが返したクエリ文を確認し、ロジックが正しいかどうかを確認します。フォローアップ質問を使用してクエリ条件を絞り込みます。

IndexConfigNotExist エラー

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

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

Unauthorized エラー

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

解決策：現在のアカウントに次の権限を付与します。

ProjectNotExist エラー

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

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

• プロジェクト名は正確ですか。

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

• ネットワーク環境では、内部同一リージョンエンドポイントが必要ですか。