このガイドでは、Simple Log Service (SLS) の LoongCollector を使用して、Elastic Compute Service (ECS) インスタンスから NGINX ログを収集する方法について説明します。ログ収集の設定、SQL を使用したデータクエリ、可視化ダッシュボードの表示、アラートの設定、および料金を回避するためのリソースのクリーンアップ方法を学びます。
前提条件
サービスの有効化とアカウントの準備
SLS の有効化:初めて SLS を使用する場合は、Simple Log Service コンソールにログインし、プロンプトに従ってサービスを有効化します。
アカウントの準備:
Alibaba Cloud アカウントでログイン:このアカウントはデフォルトですべての権限を持っており、直接使用できます。
RAM ユーザーでログイン:Alibaba Cloud アカウントは、RAM ユーザーに必要なアクセスポリシーを付与する必要があります:
AliyunLogFullAccess:プロジェクトや Logstore などの SLS リソースを作成および管理するために使用します。AliyunECSFullAccess:ECS インスタンスに収集エージェントをインストールするために使用します。AliyunOOSFullAccess:Alibaba Cloud Operation Orchestration Service (OOS) を通じて ECS インスタンスに収集エージェントを自動的にインストールするために使用します。
本番環境では、RAM ユーザーのより詳細な権限管理のために、カスタム権限ポリシーを作成できます。
ECS インスタンスの準備
ECS インスタンスのセキュリティグループで、ポート 80 (HTTP) とポート 443 (HTTPS) のアウトバウンドトラフィックが許可されていることを確認してください。
モックログの生成
ECS インスタンスにログインします。
generate_nginx_logs.shという名前のスクリプトファイルを作成し、次の内容をファイルに貼り付けます。このスクリプトは、5 秒ごとに標準の NGINX アクセスログエントリを/var/log/nginx/access.logファイルに書き込みます。実行権限を付与します:
chmod +x generate_nginx_logs.sh。スクリプトをバックグラウンドで実行します:
nohup ./generate_nginx_logs.sh &。
プロジェクトと Logstore の作成
プロジェクトは SLS のリソース管理単位であり、異なるプロジェクトのデータを分離するために使用されます。Logstore はログデータのストレージ単位です。
Simple Log Service コンソールにログインします。
[プロジェクトの作成] をクリックします:
リージョン:ご利用の ECS インスタンスと同じリージョンを選択します。これにより、Alibaba Cloud の内部ネットワーク経由でログを収集でき、ログ収集が高速化されます。
プロジェクト名:Alibaba Cloud 内でグローバルに一意な名前を入力します。例:
nginx-quickstart-abc。
その他の設定はデフォルトのままにし、[作成] をクリックします。
プロジェクトが作成されたことを示すページで、[Logstore の作成] をクリックします。
[Logstore 名] を入力し (例:
nginx-access-log)、その他の設定は変更せずに [OK] をクリックします。デフォルトでは、中間 Logstore が作成され、これは書き込まれたデータ量に基づいて課金されます。
LoongCollector のインストール
Logstore の作成後に表示されるダイアログボックスで [OK] をクリックし、[データ高速インポート] パネルを開きます。
[Nginx - テキストログ] カードで、[今すぐ統合] をクリックします。
マシングループの設定:
シナリオ:サーバー
インストール環境: ECS
[マシングループの作成] をクリックします。表示されるパネルで、ターゲットの ECS インスタンスを選択します。
[インストールしてマシングループを作成] をクリックします。インストールが成功したら、マシングループの[名前] を設定し (例:
my-nginx-server)、[OK] をクリックします。説明インストールが失敗するか保留中のままである場合は、ECS のリージョンがプロジェクトのリージョンと同じであるかを確認してください。
[次へ] をクリックして、マシングループのハートビートステータスを確認します。
マシングループを初めて作成したときに、ハートビートステータスが FAIL の場合は、[自動リトライ] をクリックします。約 2 分後にステータスが OK に変わります。
収集設定の作成
ハートビートステータスが OK になったら、[次へ] をクリックして[Logtail 設定] ページに進みます:
:設定名を入力します。例:
nginx-access-log-config。:ログ収集のパスです。最初の入力ボックスにディレクトリパス (例:
/var/log/nginx) を入力し、2 番目の入力ボックスにファイル名 (例: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 分かかります。[自動更新] をクリックします。プレビューデータが表示されれば、設定は適用されています。
ログのクエリと分析
[次へ] をクリックして最終ページに進みます。[ログのクエリ] をクリックすると、ターゲット Logstore のクエリ・分析ページにリダイレクトされます。SQL 分析文を記述して、解析されたログから主要なビジネスおよび O&M メトリックを抽出できます。時間範囲を[過去 15 分] に設定します:
エラーのポップアップが表示された場合、インデックスがまだ設定されていないことが原因です。ポップアップを閉じて 1 分間待ってください。その後、access.log ファイルのログ内容を表示できます。
例 1:Web サイトのページビュー (PV)
指定された時間範囲内のログエントリの総数をカウントします。
* | SELECT count(*) AS pv例 2:分ごとのリクエスト数とエラー率の統計
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:リクエストメソッド (GET、POST など) 別の 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
ダッシュボードでのデータ可視化
NGINX 解析プラグインを設定すると、SLS は自動的に nginx-access-log_NGINX Access Log という名前のプリセットダッシュボードを作成します。
左側のナビゲーションウィンドウで
をクリックし、を選択します。ダッシュボード名を見つけてクリックし、ページビュー (PV)、ユニークビジター (UV)、エラー率、リクエストメソッドの分布などのコアメトリックのチャートを表示します。
すべてのチャートは、必要に応じてカスタマイズおよび変更できます。
監視とアラートの設定
エラー数が急増した場合など、サービスに異常が発生したときに自動的に通知を送信するアラートルールを設定します。
左側のナビゲーションウィンドウで
[アラート] をクリックします。アクションポリシーの作成:
タブで、[作成] をクリックします。
[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] をクリックしてアラートルールを保存します。
検証:アラート条件が満たされると、設定された通知チャネルがアラートを受信します。トリガーされたすべてのアラートレコードは、[アラート履歴] ページで表示できます。
リソースのクリーンアップ
不要な課金を避けるため、作業が完了したら作成したすべてのリソースをクリーンアップしてください。
ログ生成スクリプトの停止
ECS インスタンスにログインし、次のコマンドを実行してバックグラウンドで実行中のログ生成スクリプトを停止します。
kill $(ps aux | grep '[g]enerate_nginx_logs.sh' | awk '{print $2}')LoongCollector のアンインストール (任意)
サンプルコードでは、
${region_id}をcn-hangzhouに置き換えることができます。実行を高速化するには、${region_id}をご利用の ECS インスタンスのリージョンに置き換えます。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-xxx) を見つけます。操作列で、[削除] をクリックします。
削除パネルで、プロジェクト名を入力し、削除理由を選択します。
[OK] をクリックします。プロジェクトを削除すると、その関連リソース (Logstore、収集設定、ダッシュボード、アラートルールなど) もすべて削除されます。
警告プロジェクトを削除すると、そのすべてのログデータと設定情報が解放され、回復できなくなります。プロジェクトを削除する前に、データ損失を防ぐために操作を確認してください。
次のステップ
これで、ログの収集、クエリと分析、ダッシュボードの可視化、アラート設定のプロセスが完了しました。ビジネスニーズに基づいてログリソースシステムを計画し、コアコンセプトをよりよく理解するために、次のドキュメントを読むことを推奨します:
データ収集方法をよく理解し、ビジネスシナリオに適したものを選択する。
ストレージリソースの階層を理解し、リソースのライフサイクルを計画し、適切な数のシャードを割り当てる。
よくある質問
収集後、表示される時刻が元のログの時刻と一致しない場合はどうすればよいですか?
デフォルトでは、SLS の時間フィールド (__time__) は、ログがサーバーに到着した時間を使用します。元のログの時間を使用するには、コレクション構成に時間解析プラグインを追加します。
プロジェクトと Logstore を作成するだけで課金されますか?
Logstore を作成すると、SLS はデフォルトでシャードリソースを予約します。これにより、アクティブなシャードのリース料金が発生する場合があります。詳細については、「アクティブなシャードのリース料金はなぜ発生するのですか?」をご参照ください。
ログ収集の失敗をトラブルシューティングするにはどうすればよいですか?
Logtail を使用したログ収集は、Logtail のハートビートの異常、収集エラー、または不正な Logtail 収集設定などの理由で失敗することがあります。トラブルシューティング情報については、「Logtail のログ収集の失敗のトラブルシューティング」をご参照ください。
ログはクエリできますが、分析できないのはなぜですか?
ログを分析するには、関連するフィールドのフィールドインデックスを設定し、統計機能を有効にする必要があります。Logstore のインデックス設定を確認してください。
SLS の課金を停止するにはどうすればよいですか?
SLS は一度有効化すると無効にできません。SLS を使用しなくなった場合は、アカウント配下のすべてのプロジェクトを削除することで課金を停止してください。