edit-icon download-icon

アラーム - リアルタイムでNginxのアクセスログを監視する

最終更新日: Mar 14, 2018

現在、 Log Service は、クエリステートメントを保存済み検索として保存したり、クエリのトリガサイクル(間隔)を設定したり、実行結果の判定条件を設定したり、アラームを送信することができます。アラームアクション、つまり、Saved Search を定期的に実行した結果、アラーム条件が発生したときに通知する方法を設定することもできます。

現在、次の 3 つの通知方法がサポートされています。

  • 通知センター:Alibaba Cloud 通知センターで複数の連絡先を設定できます。通知は、電子メールとテキストメッセージを使用して送信されます。
  • WebHook:DingTalk ロボットとカスタム WebHook を含む。

アラーム機能の設定と使用の詳細については、アラームルールの設定を参照してください。Log Service を使用して監視と警告に加えて、Alibaba Cloud CloudMonitor を使用して Log Service メトリックを監視することもできます。アラーム状態が発生すると、通知メッセージが送信されます。

1

シナリオ

Nginx ログを例にして、 Log Service を使用して、収集されたログ情報を定期的に照会および分析し、LogSearch の結果に基づいて以下のビジネス問題を特定する方法を示します。

  • エラーが存在するかどうか。
  • パフォーマンスの問題が存在するかどうか。
  • トラフィックが急激に減少または増加しているかどうか。

準備(Nginx ログアクセス)

  1. ログデータを収集します。

    1. ログ格納一覧 ページで データソースアクセスウィザード を入力し、 Nginx アクセスログ を選択します。
    2. 構成名ログパス Nginx ログフォーマット Nginx キー名を入力し、必要に応じて詳細設定を設定します。
    3. [次へ] をクリックしてインデックスを設定します。
  2. インデックスを設定します。

    詳細については、クエリログおよびビジュアライゼーションまたは分析 - Nginx アクセスログを参照してください。

  3. 主要メトリックのビューとアラームを設定します。

    2

サンプルビュー:

3

手順

1. エラーが存在するかどうかを判断する

一般的なエラーは次のとおりです:404 (要求はアドレスを見つけることができません)/502/500 (サーバーのエラー)。一般に、我々は 500 (サーバー上のエラー)にのみ焦点を当てています。

500 エラーが存在するかどうかを確認します。次のクエリを使用して、単位時間内のエラー(c)の数をカウントし、アラームが送信される c > 0のようにアラームルールを設定できます。

  1. status:500 | select count(1) as c

この方法は比較的シンプルですが敏感すぎます。比較的高いビジネス圧力に直面するサービスでは、数 500 のエラーが一般的です。このような状況に対応して、アラーム条件でトリガ数を 2 に設定すると、条件が 2 回連続して満たされた場合にのみアラームがトリガーされます。

2. パフォーマンス上の問題が存在するかどうかを判断する

サーバーの操作でエラーは発生しませんが、遅延が増加する可能性があります。待ち時間のアラームを設定できます。

たとえば、次の方法を使用して、インターフェイス(「/adduser」)のすべての書き込み要求(「Post」)待ち時間を計算できます。アラームルールを l > 300000 と設定します。これは、平均値が 300 ms を超えるとアラームが送信されることを意味します。

  1. Method:Post and URL:"/adduser" | select avg(Latency) as l

平均値を使用したアラーム送信は単純で直接的ですが、この方法では個々の要求レイテンシを平均化することができますが、これは問題を反映できません。たとえば、時間間隔のレイテンシの数学的な分布を計算することができます。つまり、20 の区間に分割し、各区間の数を計算することができます。ヒストグラムでは、ほとんどのリクエストレイテンシが低い( < 20 ミリ秒)が、最も高い値は 2.5 秒であることがわかります。

  1. Method:Post and URL:"/adduser" | select numeric_histogram(20, Latency)

64278-4

この状況に対処するには、アラーム条件として数学統計のパーセンタイル(最大レイテンシは 99 %)を使用できます。このようにして、誤った高レイテンシによって引き起こされた誤ったアラームを除外し、レイテンシの全体的な状況を反映させることができます。次の文は、99 パーセンタイルのレイテンシ、approx_percentile (レイテンシ、0.99)を計算します。2 番目のパラメータを変更して、50 パーセンタイルの要求レイテンシ approx_percentile(Latency、0.5)など、他のパーセンタイルのレイテンシを計算することもできます。

  1. Method:Post and URL:"/adduser" | select approx_percentile(Latency, 0.99) as p99

監視のシナリオでは、平均レイテンシ、50 パーセンタイルレイテンシ、および 90 パーセンタイルレイテンシをグラフ化することができます。以下は、1 日の 1 分ごとの待ち時間 (1440分)を示すチャートです。

  1. * | 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

64278-5

3. トラフィックに急激な減少または増加があるかどうかを判断する

サーバ上の自然なトラフィックは通常、確率分布に沿っているため、ゆっくりと増加または減少するプロセスが存在します。トラフィックの急激な減少または増加は、通常は異常であり、特別な注意が必要な短期間の大きな変化を示します。

次の監視図に示すように、トラフィックは 2 分以内に 30 %以上減少し、2 分以内に急速に再開します。

64278-6

突然の減少または増加は、通常、次の参照フレーム内にあります。

  • 前の時間枠:前の期間と比較したリンク相対比率。
  • 前日と同じ期間のウィンドウ:前日と比較したリンク相対比率。
  • 前週と同じ期間のウィンドウ:リンク相対比率が前週と比較されます。

この記事の例として最初の参照フレームを取り、流入データの変化率を計算します。QPS などの他のトラフィックデータも計算できます。

3.1 計算ウィンドウを定義する

この分の流入をカウントするための 1 分のウィンドウを定義します。以下は 5 分間隔の統計結果です。

  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

結果分布から、すべてのウィンドウ sum(inflow)/(max(__time__)-min(__time__))の平均流入が偶数であることがわかります。

64278-7

3.2 計算ウィンドウの分散 (max_ratio)

ここでサブクエリを使用します。クエリを作成して、最大値または最小値と前回の結果の平均値 (max_ratio) との間の変化の割合を計算します。たとえば、次の計算結果では、max_ratio は 1.02 です。アラームルールを定義することができます。たとえば、max_ratio> 1.5 (変化率が 50 %を超える場合)の場合、アラームが送信されます。

  1. * | 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)

1

3.3 計算ウィンドウの分散(latest_ratio)

いくつかのシナリオでは、最新の価値の変動(回収されたかどうかにかかわらず)にもっと注意を払う。max_by メソッドを使用して最大 windows_time に流入させることによって決定します。ここでは、lastest_ratio = 0.97 です。

注: max_by の関数計算結果は文字型であり、数値型に変換する必要があります。相対変化率を計算するには、(1.0-max_by(inflow、window_time)/1.0/avg(inflow))を lastest_ratio と置き換えることができます。

  1. * | 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)

1

3.4 計算ウィンドウの分散(現在の値と以前の値の変化率の比率を定義する)

変動率を計算するもう 1 つの方法は、数学では、現在のウィンドウの値と前のウィンドウの値との間の変化の比率である第 1 導関数である。

1

計算にはウィンドウ関数(ラグ)を使用します。ウィンドウ関数から、現在の流入量と前期の流入量を抽出し、 lag(inflow,1,inflow)over()を用いて差を計算し、計算された差分値を現在の値で除算して変化します。

  1. * | 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)

この例では、11:39 のトラフィックが比較的大きく減少します(ウィンドウ間の変化率は 40 %を超えています)。

絶対変化率を定義するには、abs 関数(絶対値)を使用して計算結果を統一することができます。

64278-11

結論

Log Service のクエリと解析機能は、さまざまな数学的な統計と計算をサポートする完全な SQL92 です。SQL を使用できる人は誰でも高速分析を実行できます。試してみてください!