Log serviceを使用すると、NGINXアクセスログを収集および分析できます。 このトピックでは、Webサイトへのアクセスを監視、分析、診断、および最適化する方法について説明します。

始める前に

ログデータを収集済み。 詳細については、「NGINX設定モードでログを収集する」をご参照ください。

インデックス作成機能が有効になり、設定されます。 詳細については、「インデックスの作成」をご参照ください。

このタスクについて

NGINXは、Webサイトの構築とホストに使用できる、無料のオープンソースで高性能なHTTPサーバーです。 NGINXアクセスログを収集して分析できます。 CNZZなどの従来の方法では、JavaScriptスクリプトがWebサイトのフロントエンドページに挿入され、ユーザーがWebサイトにアクセスしたときにトリガーされます。 ただし、この方法ではアクセス要求のみを記録できます。 ストリームコンピューティング、オフラインコンピューティング、およびオフライン分析を使用して、NGINXアクセスログを分析することもできます。 しかし、これらの方法は専用の環境を必要とし、ログ分析中に時間効率と柔軟性のバランスをとることは困難です。

Log Serviceコンソールで、データインポートウィザードを使用してNGINXアクセスログを収集するための収集設定を作成できます。 次に、Log Serviceは、NGINXアクセスログの収集と分析に役立つインデックスとNGINXダッシュボードを作成します。 ダッシュボードには、IPアドレスの分布、HTTPステータスコード、リクエスト方法、ページビュー (PV) と一意の訪問者 (UV) の統計、インバウンドとアウトバウンドトラフィック、ユーザーエージェント、トップ10のリクエストURL、リクエスト数によるトップ10のURI、リクエスト遅延によるトップ10のURIなどのメトリックが表示されます。 クエリ文を使用して、Webサイトのアクセス遅延を分析し、Webサイトのパフォーマンスをできるだけ早く最適化できます。 パフォーマンスの問題、サーバーエラー、トラフィックの変化を追跡するアラートを作成できます。 アラートのトリガー条件が満たされると、指定された受信者にアラート通知が送信されます。

Webサイトへのアクセスを分析する

  1. Log Service コンソールにログインします。
  2. [プロジェクト] セクションで、表示するプロジェクト名をクリックします。
  3. 左側のナビゲーションウィンドウで、[ログ管理] > [ログストア] を選択します。 Logstoreを見つけて、その横にある > アイコンをクリックします。
  4. [Visual Dashboards] の横にある [>] アイコンをクリックし、[LogstoreName_Nginx_access_log] をクリックします。
    ダッシュボードには、次のメトリックが表示されます。
    • IPアドレスの分布: 次のSQL文を実行して、IPアドレスの分布に関する統計を収集します。 
      * | カウント (1) をc、ip_to_province(remote_addr) をアドレスグループとしてアドレス制限100
    • HTTPステータスコード: 次のSQL文を実行して、過去24時間に返された各HTTPステータスコードの割合を計算します。 
       * | select count(1) as pv,
         status
         group by status
      HTTPステータスコード
    • リクエストメソッド: 次のSQL文を実行して、過去24時間に使用された各リクエストメソッドの割合を計算します。 
      * | select count(1) as pv ,request_method group by request_method
      リクエスト方法
    • ユーザーエージェント: 次のSQL文を実行して、過去24時間に使用された各ユーザーエージェントの割合を計算します。 
      * | pvとしてcount (1) を選択し、「 % Chrome % 」のようなhttp_user_agentの場合、「Chrome」、「 % Firefox % 」のようなhttp_user_agentの場合、「Firefox」、「 % Safari % 」のようなhttp_user_agentが「 % Chrome % 」のような場合、「Safari' 」、「UnKnown」はhttp_user_agentグループとして終了します。% % http_user_agentが「Firefox」のようになり」のような場合、「のような場合、「 % % 」のような」のような場合
      ユーザーエージェント
    • 上位10個のリクエストURL: 次のSQL文を実行して、過去24時間で最も多くのPVを持つ上位10個のリクエストURLを示します。 
      * | select count(1) as pv , http_referer group by http_referer order by pv desc limit 10
      トップ10のリクエストURL
    • インバウンドトラフィックとアウトバウンドトラフィック: 次のSQL文を実行して、インバウンドトラフィックとアウトバウンドトラフィックの統計を収集します。 
      * | sum(body_bytes_sent) をnet_outとして、sum(request_length) をnet_inとして、date_format(date_trunc('hour', __time__), '% m-% d % H:% i') をdate_formatによるタイムグループとして選択します (date_trunc('hour', __time________)))), '時間制限 % d % 10000% i), ' 時間_time % % i'
      受信および送信トラフィック
    • PVおよびUV統計: 次のSQL文を実行して、PVおよびUVの数を計算します。 
      * | select approx_distinct(remote_addr) as uv ,count (1) as pv , date_format(date_trunc('hour', __time__), '% m-% d % H:% i) as time group by date_format(date_trunc('hour', __time__), ' % m-% d % H:% i ')
      PVおよびUV統計
    • 予測PV: 次のSQL文を実行して、次の4時間のPV数を予測します。
      * | select ts_predicate_simple(stamp, value, 6,1, 'sum') from (select __time__ - __time__ % 60 as stamp, COUNT(1) as value from log GROUP BY stamp order by stamp) LIMIT 1000
      予測PV
    • リクエスト数による上位10個のURL: 次のSQL文を実行して、過去24時間に最も多くのPVを持つリクエストされたURLの上位10個を示します。
      * | select count(1) as pv, split_part(request_uri,'?',1) as path group by path order by pv desc limit 10
      リクエスト数による上位10のURL

Webサイトへのアクセスの診断と最適化

一部のデフォルトのアクセス指標に加えて、NGINXアクセスログに基づいてアクセス要求を診断する必要もあります。 これにより、特定のページでレイテンシーの高いリクエストを見つけることができます。 クイック分析機能は、検索と分析ページで使用できます。 詳細については、「データのクエリと分析」をご参照ください。

  • 次のSQL文を実行して、5分ごとに平均レイテンシと最大レイテンシをカウントし、全体のレイテンシを取得します。
      * | select from_unixtime(__time__ -__time__% 300) as time, 
          avg(request_time) as avg_latency ,
          max(request_time) as max_latency  
          group by __time__ -__time__% 300
  • 次のSQL文を実行して、レイテンシが最も高い要求されたページを見つけ、ページの応答速度を最適化します。
      * | select from_unixtime(__time__ - __time__% 60) , 
          max_by(request_uri,request_time)  
          group by __time__ - __time__%60
  • 次のSQL文を実行して、すべてのリクエストをアクセスレイテンシで10のグループに分割し、異なるレイテンシ範囲に基づいてリクエストの数をカウントします。
    * |select numeric_histogram(10,request_time)
  • 次のSQL文を実行して、レイテンシが最も高い上位10件のリクエストと各リクエストのレイテンシを数えます。 
    * | select max(request_time,10)
  • 要求されたページを最大のレイテンシで最適化します。

    /url2ページのレイテンシが最も高いとします。 /url2ページの応答速度を最適化するには、/url2ページの次のメトリックをカウントします。PVおよびUVの数、各リクエストメソッドが使用された回数、各HTTPステータスコードが返された回数、各ブラウザータイプが使用された回数、平均レイテンシ、および最大レイテンシ。

       request_uri:"/url2" | select count(1) as pv,
          approx_distinct(remote_addr) as uv,
          histogram(method) as method_pv,
          histogram(status) as status_pv,
          histogram(user_agent) as user_agent_pv,
          avg(request_time) as avg_latency,
          max(request_time) as max_latency

アラートルールの作成

アラートルールを作成して、パフォーマンスの問題、サーバーエラー、トラフィックの変更を追跡できます。 詳細については、「アラームの設定」をご参照ください。

  • Serverアラート
    HTTPステータスコードが500のサーバーエラーに注目する必要があります。 次のSQL文を実行して、単位時間あたりのエラー数cを照会し、アラートルールのトリガー条件をc > 0に設定できます。
    status:500 | select count(1) as c
    説明 アクセストラフィックの多いサービスでは、500エラーが発生することがあります。 この場合、通知トリガーしきい値パラメーターを2に設定できます。 It示しアラートは場合にのみトリガ条件が連続した2回。
    サーバー警告
  • Performanceアラート
    サーバーの実行中にレイテンシが増加した場合は、アラートルールを作成できます。 たとえば、次のSQL文を実行することで、操作 /adduserのすべての書き込み要求Postのレイテンシを計算できます。 次に、アラートルールをl > 300000に設定します。 平均レイテンシが300ミリ秒を超えるとアラートが送信されることを示します。
    Method:Post and URL:"/adduser" | select avg(Latency) as l
    平均レイテンシ値を使用してアラートを作成できます。 しかしながら、高いレイテンシ値はより低い値に平均化されるため、これは真の状況を反映しない可能性がある。 トリガー条件として、数学統計のパーセンタイル (最大のレイテンシは99%) を使用できます。
    Method:Post and URL:"/adduser" | select approx_percentile(Latency, 0.99) as p99
    1日の1分ごとのレイテンシ (1,440分) 、50パーセンタイルのレイテンシ、および90パーセンタイルのレイテンシを計算できます。
    * | select avg(Latency) as l, approx_percentile(Latency, 0.5) as p50, approx_percentile(Latency, 0.99) as p99, date_trunc('minute', time) as t group by t order by t desc limit 1440
    パフォーマンスの問題が存在するかどうかを確認する
  • 交通アラート
    短時間でのトラフィックの急激な減少または増加は異常です。 トラフィックの変化率を計算し、突然のトラフィックの変化を監視するアラートルールを作成できます。 突然のトラフィックの変化は、次のメトリックに基づいて検出されます。
    • 前の期間: 現在の期間のデータと前の期間のデータを比較します。
    • 前日の同じ期間: 現在の期間のデータと前日の同じ期間のデータを比較します。
    • 前の週の同じ期間: 現在の期間のデータを前の週の同じ期間のデータと比較します。
    最後のウィンドウは、トラフィック変化率を計算するために次の例で使用されます。 この例では、時間範囲は5分に設定されています。
    1. 計算ウィンドウを定義します。
      1 分間のウィンドウを定義して、この時間の受信トラフィックサイズを計算します。
      * | select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60  as window_time from log group by window_time order by window_time limit 15
      結果は、平均インバウンドトラフィックがすべてのウィンドウで均等に分散されることを示しています。計算ウィンドウの定義
    2. ウィンドウで値の違いを計算します。
      • Calculate最大または最小交通差サイズと平均交通サイズで。 max_ratioメトリックは例として使用されます。
        The計算max_ratioは1.02。 アラートルールをmax_ratio > 1.5に設定できます。 変更率が50% を超えるとアラートが送信されることを示します。 
         * | select max(inflow)/avg(inflow) as max_ratio from (select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60  as window_time from log group by window_time order by window_time limit 15)
        ウィンドウで値の違いを計算する
      • latest_ratioメトリックを計算して、最新の値が変動するかどうかを確認します。
        ウィンドウ内の最大トラフィックサイズを計算するには、max_by関数を使用します。 この例では、lastest_ratioは0.97です。 
         * | select max_by(inflow, window_time)/1.0/avg(inflow) as lastest_ratio from (select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60  as window_time from log group by window_time order by window_time limit 15)
        説明 max_by関数の計算結果は文字型です。 数値型に変換する必要があります。 変更の相対比率を計算するには、SELECT句を (1.0-max_by(inflow, window_time)/1.0/avg(inflow)) as lastest_ratioに置き換えます。
        ウィンドウで値の違いを計算する
      • 変動率を計算します。 これは、現在の値とウィンドウの前の値との間の変化比である。ウィンドウで値の違いを計算する
        計算にはウィンドウ関数 (lag) を使用します。 現在のインバウンドトラフィックと前のサイクルのインバウンドトラフィックを抽出し、lag(inflow, 1, inflow)over() を使用して差を計算します。 そして、算出した差分値を電流値で除算して変化率を求める。 この例では、11:39にトラフィックが比較的大幅に減少し、変化率は40% を超えています。
        説明 絶対変化率を定義するには、ABS関数を使用して絶対値を計算し、計算結果を統合します。
         * | select (inflow- lag(inflow, 1, inflow)over() )*1.0/inflow as diff, from_unixtime(window_time) from (select sum(inflow)/(max(__time__)-min(__time__)) as inflow , __time__-__time__%60  as window_time from log group by window_time order by window_time limit 15)
        ウィンドウ内の値の違いを計算する (2)