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

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

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

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

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

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

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

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

• フルスキャンを避けるため、可能な限り時間範囲を狭めます。

• あいまいな説明ではなく、status や request_uri などの正確なフィールド名を指定します。

• トップ N の結果が必要な場合は、「トップ 10」のようにプロンプトで数を指定します。

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

プロンプト

SLS Logstore (Project=prod-web, Logstore=nginx-access) で、過去 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

クエリ結果：
| 時刻 | 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 エラーが最も多い API トップ 10 の検索

プロンプト

SLS Logstore prod-web/nginx-access で、過去 1 時間に 5xx エラーが最も多かった API のトップ 10 を検索します。

エージェントの出力例

クエリモード：インデックス クエリ + SQL。
理由：5xx エラーが最も多い API トップ 10 を見つけるには、まずインデックス クエリを使用してステータスコード 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'

クエリ結果：
| 順位 | request_uri | エラー数 |
| --- | --- | ---: |
| 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"

クエリ結果：
| 分 | 現在の平均レイテンシ | 平均レイテンシ (昨日) | 変化 | 変化率 |
| --- | ---: | ---: | ---: | ---: |
| 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 クエリ スキルは複数ターンの会話をサポートしています。以前の結果に基づいてフォローアップの質問をすることで、調査範囲を段階的に絞り込むことができます。

最初のプロンプト

SLS Logstore prod-web/nginx-access で、過去 1 時間に 5xx エラーが最も多かった API のトップ 5 を検索します。

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

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

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 など、複数の認証情報設定方法がサポートされています。詳細については、「認証情報の設定と管理」をご参照ください。

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

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

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

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

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

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

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

IndexConfigNotExist エラー

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

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

Unauthorized エラー

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

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

ProjectNotExist エラー

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

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

• プロジェクト名が正しいことを確認してください。

• リージョンがプロジェクトのリージョンと一致していることを確認してください。

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