このクイックスタートでは、Simple Log Service (SLS) LoongCollector を使用して、Elastic Compute Service (ECS) インスタンスから NGINX アクセスログを収集および分析します。次の方法を学習します。
LoongCollector を使用してログ収集を構成する。
SQL を使用してログデータをクエリおよび分析する。
モニタリングアラートを設定する。
始める前に
アカウント権限の設定
Alibaba Cloud アカウント
Alibaba Cloud アカウントは、デフォルトで SLS への完全かつ無制限のアクセス権を持っています。操作は必要ありません。
Resource Access Management (RAM) ユーザー
RAM ユーザーはデフォルトでは権限を持たず、Alibaba Cloud アカウントによって明示的にアクセスを許可される必要があります。これには 2 つの方法があります。
次のシステムポリシーをアタッチします。
AliyunLogFullAccess: プロジェクトや Logstore などの SLS リソースを作成および管理します。AliyunECSFullAccess: ECS インスタンスに収集エージェントをインストールします。AliyunOOSFullAccess: CloudOps Orchestration Service (OOS) を使用して ECS インスタンスに収集エージェントを自動的にインストールします。
カスタムポリシーの作成とアタッチ
よりきめ細かい制御を行うには、カスタムポリシーを作成してアタッチし、最小権限の原則に基づいて RAM ユーザーに権限を付与します。
ECS インスタンスの準備
ECS インスタンスがない場合は、「このドキュメント」を参照して作成してください。インスタンスのセキュリティグループには、ポート 80 (HTTP) とポート 443 (HTTPS) のトラフィックを許可するアウトバウンドルールが必要です。
プロジェクトと Logstore の作成
Simple Log Service コンソールにログインします。
[Create Project] をクリックします:
リージョン: ECS インスタンスと同じリージョンを選択します。これにより、Alibaba Cloud 内部ネットワーク経由でログを収集でき、ログ収集が高速化されます。
プロジェクト名: Alibaba Cloud 内でグローバルに一意の名前 (例:
nginx-quickstart-abc) を入力します。
「その他の構成」はデフォルト設定のままにし、[作成] をクリックします。
確認ページで、[Create Logstore] をクリックします。
Logstore 名 (例:
nginx-access-log) を入力します。他のパラメーターはデフォルト設定のままにし、[OK] をクリックします。デフォルトでは、標準 Logstore が作成され、取り込まれたデータの量に応じて課金されます。
ステップ 1. モックログの生成
generate_nginx_logs.shという名前のスクリプトファイルを作成し、次の内容をファイルに貼り付けます。このスクリプトは、標準の NGINX アクセスログエントリを 5 秒ごとに/var/log/nginx/access.logファイルに書き込みます。ファイルに実行権限を付与します:
chmod +x generate_nginx_logs.sh。バックグラウンドでスクリプトを実行します:
nohup ./generate_nginx_logs.sh &。
ステップ 2. LoongCollector のインストール
Logstore が作成されたことを確認するダイアログボックスで、[OK] をクリックして [クイックデータインポート] パネルを開きます。
[単一行 - テキストログ] カードで、[今すぐ統合] をクリックします。
マシングループを構成します。
シナリオ: サーバー
インストール環境: ECS
[マシングループの作成] をクリックします。[マシングループの作成] パネルで、ECS インスタンスを選択します。
[インストールしてマシングループを作成] をクリックします。インストールが完了したら、マシングループの名前 (例:
my-nginx-server) を入力し、[OK] をクリックします。説明インストールが失敗した場合、または保留状態のままの場合は、ECS インスタンスとプロジェクトが同じリージョンにあることを確認してください。
[次へ] をクリックして、マシングループのハートビートステータスを確認します。
新しいマシングループの場合、ハートビートステータスが FAIL の場合は、[自動再試行] をクリックします。ステータスは約 2 分で OK に変わります。
ステップ 3. 収集構成の作成
ハートビートステータスが OK になったら、[次へ] をクリックして [Logtail 構成] ページを開き、次のパラメーターを構成します。
構成名: 名前 (例:
nginx-access-log-config) を入力します。ファイルパス: ログ収集パス
/var/log/nginx/access.logを入力します。処理構成:
ログサンプル: [ログサンプルの追加] をクリックし、サンプルログエントリを貼り付けます。
192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"
プロセッサーメソッド: [データ解析 (NGINX モード)] を選択します。[NGINX ログ構成] フィールドで、
log_formatを構成します。次の内容をコピーして貼り付け、[OK] をクリックします。log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" $request_time $request_length';本番環境では、この
log_formatは NGINX 構成ファイル (通常は/etc/nginx/nginx.confにあります) の定義と一致している必要があります。ログ解析の例:
生ログ
構造化ログ
192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"body_bytes_sent: 368 http_referer: - http_user_agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.x.x Safari/537.36 remote_addr:192.168.*.* remote_user: - request_length: 514 request_method: GET request_time: 0.000 request_uri: /nginx-logo.png status: 200 time_local: 15/Apr/2025:16:40:00
[次へ] をクリックして [クエリと分析の構成] ページに移動します。収集構成が有効になるまで約 1 分かかります。[自動更新] をクリックします。プレビューデータが表示されると、構成は有効です。
ステップ 4. ログのクエリと分析
[次へ] をクリックして最終ページに進み、[ログのクエリ] をクリックします。システムはターゲット Logstore のクエリおよび分析ページにリダイレクトします。SQL 分析ステートメントを記述して、構造化ログから主要なビジネスおよび運用メトリックを抽出します。時間範囲を [過去 15 分] に設定します。
エラーメッセージが表示された場合、インデックスはまだ構成されていません。ダイアログボックスを閉じて約 1 分待ちます。その後、access.log ファイルからログの内容を表示します。
例 1: ウェブサイトの合計ページビュー (PV)
指定された時間範囲内のログエントリの総数をカウントします。
* | SELECT count(*) AS pv例 2: 1 分あたりのリクエスト数とエラー率
1 分あたりのリクエスト総数、エラーリクエスト数 (HTTP ステータスコード ≥ 400)、およびエラー率を計算します。
* | SELECT date_trunc('minute', __time__) as time, count(1) as total_requests, count_if(status >= 400) as error_requests, round(count_if(status >= 400) * 100.0 / count(1), 2) as error_rate GROUP BY time ORDER BY time DESC LIMIT 100例 3: リクエストメソッド別の PV 統計
分単位およびリクエストメソッド (GET や POST など) 別にページビューをグループ化してカウントします。
* | SELECT date_format(minute, '%m-%d %H:%i') AS time, request_method, pv FROM ( SELECT date_trunc('minute', __time__) AS minute, request_method, count(*) AS pv FROM log GROUP BY minute, request_method ) ORDER BY minute ASC LIMIT 10000
ステップ 5. モニタリングアラートの設定
モニタリングアラートを設定して、エラーの急増など、サービスの異常が発生したときに自動的に通知を送信します。
左側のナビゲーションウィンドウで、
[アラート] をクリックします。アクションポリシーを作成します。
タブで、[作成] をクリックします。
[ID] (例:
send-notification-to-admin) と [名前] を設定します。[プライマリアクションポリシー] で、
[アクショングループ] をクリックします。[通知方法] (例: [SMS メッセージ]) を選択し、[受信者] を構成し、[アラートテンプレート] を選択します。
[確認] をクリックします。
アラートルールを作成します。
[アラートルール] タブで、[アラートの作成] をクリックします。
ルール名 (例:
Too many server 5xx errors) を入力します。[クエリ統計] フィールドで、[作成] をクリックしてクエリ条件を設定します。
Logstore:
nginx-access-logを選択します。時間範囲: 15 分 (相対)。
クエリ:
status >= 500 | SELECT *を入力します。[プレビュー] をクリックしてデータを確認し、[OK] をクリックします。
トリガー条件: クエリ結果に 100 を超えるエントリが含まれている場合に重大なアラートをトリガーするようにルールを構成します。
この構成では、15 分以内に 100 を超える 5xx エラーが発生した場合にアラートがトリガーされます。
: [Simple Log Service 通知] を選択して有効にします。
[アクションポリシー] で、前のステップで作成したアクションポリシーを選択します。
[繰り返し間隔]: 過剰な通知を避けるために 15 分に設定します。
[OK] をクリックしてアラートルールを保存します。
構成の確認: アラート条件が満たされると、構成された通知チャネルにアラートが送信されます。トリガーされたすべてのアラートレコードは [アラート履歴] ページで表示できます。
ステップ 6. リソースのクリーンアップ
課金を避けるため、操作完了後に作成したすべてのリソースをクリーンアップしてください。
ログ生成スクリプトの停止
ECS インスタンスに接続し、次のコマンドを実行してログ生成スクリプトを停止します。
kill $(ps aux | grep '[g]enerate_nginx_logs.sh' | awk '{print $2}')LoongCollector のアンインストール (オプション)
実行を高速化するには、次のコマンドの
${region_id}を、お使いの ECS インスタンスの リージョン ID に置き換えます。wget https://aliyun-observability-release-${region_id}.oss-${region_id}.aliyuncs.com/loongcollector/linux64/latest/loongcollector.sh -O loongcollector.sh;アンインストールコマンドを実行します。
chmod +x loongcollector.sh; sudo ./loongcollector.sh uninstall;
プロジェクトの削除
警告プロジェクトを削除すると、そのすべてのログデータと構成情報が完全に削除されます。データ損失を避けるため、削除する前に操作を慎重に確認してください。
Simple Log Service コンソール のプロジェクトリストページで、作成したプロジェクト (例:
nginx-quickstart-abc) を見つけます。[操作] 列で、[削除] をクリックします。
表示されるパネルで、プロジェクト名を入力し、削除理由を選択します。
[OK] をクリックします。この操作により、プロジェクトとその関連リソース (Logstore、収集構成、アラートルールなど) がすべて削除されます。
よくある質問
収集後に表示される時刻が元のログ時刻と異なる場合はどうすればよいですか?
デフォルトでは、SLS の時刻フィールド (__time__) には、ログがサーバーに到着した時刻が記録されます。元のログエントリの時刻を使用するには、収集構成に 時刻解析プラグイン を追加します。
プロジェクトと Logstore を作成するだけで課金されますか?
はい。Logstore を作成すると、SLS はデフォルトでシャードリソースを予約するため、アクティブなシャードリース料金が発生する場合があります。詳細については、「アクティブなシャードリースに対して課金されるのはなぜですか?」をご参照ください。
ログ収集の失敗をトラブルシューティングするにはどうすればよいですか?
ログ収集は、ハートビートの異常、収集エラー、または LoongCollector (Logtail) 構成の誤りが原因で失敗する可能性があります。「Logtail 収集の失敗のトラブルシューティング」をご参照ください。
ログはクエリできますが、分析できないのはなぜですか?
ログを分析するには、関連するフィールドのフィールドインデックスを構成し、統計を有効にする必要があります。Logstore の インデックス構成 を確認してください。
SLS の課金を停止するにはどうすればよいですか?
SLS は有効化後に無効にすることはできません。サービスを今後使用しない場合は、アカウント配下のすべてのプロジェクトを削除して 課金を停止 してください。