Simple Log Service は、Nginx アクセスログの多次元分析をサポートしています。本トピックでは、ウェブサイトトラフィックの分析、レイテンシー診断、およびサンプルクエリを使用したアラート設定について説明します。
前提条件
Nginx アクセスログが収集済みである必要があります。Nginx 構成モードを使用したテキストログの収集をご参照ください。
データインポートウィザードにより、ログフィールドに基づいて自動的にインデックスが生成されます。インデックスを変更する場合は、インデックスの作成に従って操作してください。
概要
Nginx ログはウェブサイト運用において不可欠です。従来の CNZZ のような手法ではフロントエンドに JavaScript を埋め込む必要があり、ストリーム処理やオフラインコンピューティングでは複雑なインフラストラクチャが必要となり、リアルタイム性能または分析の柔軟性のいずれかを犠牲にする必要があります。
Simple Log Service はデータインポートウィザードを通じて Nginx ログを収集し、自動的にインデックスとダッシュボードを作成します。nginx_Nginx access log ダッシュボードには、ソース IP の分布、リクエスト状態、ユーザーエージェント、PV/UV の推移、トラフィック統計、上位リファラー、およびアクセス数の多い URL が表示されます。カスタムクエリを記述してレイテンシーを分析したり、エラーやトラフィックの異常に対してアラートを設定したりできます。
ウェブサイトトラフィックの分析
Simple Log Service コンソールにログインします。
[Projects] セクションで、目的のプロジェクトをクリックします。

-
左側のナビゲーションウィンドウで、 を選択します。目的の Logstore の左側にある > アイコンをクリックします。
-
視覚ダッシュボード の下で、nginx_Nginx access log をクリックします。
nginx_Nginx access log ダッシュボードには、以下のチャートが含まれます。
-
ソース IP アドレスの分布 チャートは、過去 1 日間におけるリクエスト IP の地理的分布を示します。クエリ:
* | select count(1) as c, ip_to_province(remote_addr) as address group by address limit 100 -
リクエスト状態の分布 チャートは、過去 1 日間における各 HTTP ステータスコードの割合を示します。クエリ:
* | select count(1) as pv, status group by status
-
リクエストメソッドの分布 チャートは、過去 1 日間における各リクエストメソッドの割合を示します。クエリ:
* | select count(1) as pv ,request_method group by request_method
-
ユーザーエージェントの分布 チャートは、過去 1 日間におけるブラウザ別の割合を示します。クエリ:
* | select count(1) as pv, case when http_user_agent like '%Chrome%' then 'Chrome' when http_user_agent like '%Firefox%' then 'Firefox' when http_user_agent like '%Safari%' then 'Safari' else 'unKnown' end as http_user_agent group by case when http_user_agent like '%Chrome%' then 'Chrome' when http_user_agent like '%Firefox%' then 'Firefox' when http_user_agent like '%Safari%' then 'Safari' else 'unKnown' end order by pv desc limit 10
-
上位 10 件のリファラー チャートは、過去 1 日間における PV 数が最も多い上位 10 件のリファラーページを示します。クエリ:
* | select count(1) as pv , http_referer group by http_referer order by pv desc limit 10
-
インバウンドおよびアウトバウンドトラフィック統計 チャートは、過去 1 日間におけるインバウンドおよびアウトバウンドトラフィックを示します。クエリ:
* | select sum(body_bytes_sent) as net_out, sum(request_length) as net_in ,date_format(date_trunc('hour', __time__), '%m-%d %H:%i') as time group by date_format(date_trunc('hour', __time__), '%m-%d %H:%i') order by time limit 10000
-
PV/UV 統計 チャートは、過去 1 日間における 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') order by time limit 1000
-
PV 予測 チャートは、今後 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
-
アクセス数の多い上位 10 件の URL チャートは、過去 1 日間における PV 数が最も多い上位 10 件の URL を示します。クエリ:
* | select count(1) as pv, split_part(request_uri,'?',1) as path group by path order by pv desc limit 10
-
ウェブサイトパフォーマンスの診断と最適化
遅いページを特定するためにリクエストレイテンシーをモニタリングします。カスタムクエリを使用してレイテンシーパターンを分析します。クエリ構文については、「検索と分析のクイックスタート」をご参照ください。
-
全体的なレイテンシー傾向を把握するために、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 -
最適化の優先順位をつけるために、レイテンシーが最も高いページを特定します。
* | select from_unixtime(__time__ - __time__% 60) , max_by(request_uri,request_time) group by __time__ - __time__%60 -
レイテンシー値を 10 個のビンにグループ化して、その分布を分析します。
* |select numeric_histogram(10,request_time) -
上位 10 件のレイテンシー値とそれに対応するリクエストを取得します。
* | select max(request_time,10) -
レイテンシーが最も高いページを最適化します。
たとえば、/url2 のレイテンシーが最も高い場合、/url2 ページについて、/url2 の PV、UV、リクエストメソッド、ステータスコード、ブラウザ、平均レイテンシー、および最大レイテンシーを計算して最適化を行います。
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 -
今日のページビュー (PV) を昨日の PV と比較します (Debug)。
* | select diff [1] as today, round((diff [3] -1.0) * 100, 2) as growth FROM ( SELECT compare(pv, 86400) as diff FROM ( SELECT COUNT(1) as pv FROM log ) ) -
ページビュー (PV) の前日比変化を計算します。
* | select t, diff [1] as today, diff [2] as yestoday, diff [3] as percentage from( select t, compare(pv, 86400) as diff from ( select count(1) as pv, date_format(from_unixtime(__time__), '%H:%i') as t from log group by t limit 10000 ) group by t order by t limit 10000 )
アラートの設定
レイテンシーの急増、サーバーエラー、トラフィックの異常に対してアラートを設定します。手順の詳細については、「アラートの設定」をご参照ください。
-
エラーアラート
500 (サーバーエラー) 応答をモニタリングします。以下のクエリは、時間単位あたりのエラー数 (c) をカウントします。アラートトリガー条件を c > 0 に設定します。
status:500 | select count(1) as c説明トラフィック量が多いサービスで偶発的な 500 エラーが発生することが予想される場合は、通知のトリガーしきい値 を 2 に設定します。これにより、連続 2 回条件が満たされた場合にのみアラートがトリガーされます。
アラート作成ダイアログボックスで、Alert Name を
Error Alertに設定します。Add to Dashboard では Create を選択し、ダッシュボード名をNginxと指定します。Chart Name はError Alert、Query Interval は 1 Day (On the Hour)、Check Frequency は Fixed Interval の 15 Minutes に設定します。最後に、Notification Interval を 5 Minutes に設定します。 -
パフォーマンスアラート
レイテンシーアラートを作成します。以下のクエリは、
Postリクエストを/adduserエンドポイントに送信した際の平均レイテンシーを計算します。トリガー条件を l > 300000 に設定すると、平均レイテンシーが 300 ms を超えた際にアラートがトリガーされます。Method:Post and URL:"/adduser" | select avg(request_time) as l平均値に基づくアラートでは、個別の高レイテンシーのリクエストがマスクされる可能性があります。代わりに、パーセンタイル (例:P99) をトリガー条件として使用することを推奨します。以下のクエリは、99 パーセンタイルのレイテンシーを計算します。
Method:Post and URL:"/adduser" | select approx_percentile(request_time, 0.99) as p99モニタリングのために、1 日間 (1,440 分) のウィンドウ内で 1 分ごとの平均、P50、および P99 レイテンシーを計算します。
* | select avg(request_time) as l, approx_percentile(request_time, 0.5) as p50, approx_percentile(request_time, 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結果には
window_timeおよびinflowの 2 つの列が含まれます。inflow列には、各 1 分間ウィンドウのトラフィック値が表示されます。 -
ウィンドウ内での差分を計算します。
-
最大値または最小値と平均値の比率を計算します。この例では、最大比率 (max_ratio) を使用します。
この例では、
max_ratioは 1.02 です。変化率が 50% を超えた場合にアラートをトリガーするには、アラート条件を max_ratio > 1.5 に設定します。* | 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) -
最新の値の変化率を計算して、トラフィックが変動しているか、または正常に戻っているかを確認します。
max_by 関数を使用して、ウィンドウ内の最大トラフィックを取得します。
latest_ratioが 0.97 の場合、最新のトラフィックは平均の 97% であることを意味します。* | select max_by(inflow, window_time)/1.0/avg(inflow) as latest_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 関数の結果は文字列型であるため、数値型にキャストする必要があります。相対的な変化率を計算したい場合は、(1.0-max_by(inflow, window_time)/1.0/avg(inflow)) as latest_ratio を使用できます。
-
ボラティリティ (現在のウィンドウと直前のウィンドウの値の変化) を計算します。
lagウィンドウ関数を使用して、現在のトラフィック inflow と直前の期間の inflow "lag(inflow, 1, inflow)over() " の差分を現在の inflow で除算します。大幅な低下 (例: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)
-
-