Amazon Athena と Cube.js を使用した Nginx ログ分析

通常、商用製品や、Prometheus + Grafana などの既製のオープンソース代替品が、Nginx の動作の監視と分析に使用されます。 これは監視やリアルタイム分析には良いオプションですが、履歴分析にはあまり便利ではありません。 一般的なリソースでは、nginx ログのデータ量が急速に増加しているため、大量のデータを分析するには、より特化したものを使用するのが合理的です。

この記事ではその使い方を紹介します アテナ Nginx を例としてログを分析し、オープンソースの cube.js フレームワークを使用してこのデータから分析ダッシュボードを組み立てる方法を示します。 完全なソリューション アーキテクチャは次のとおりです。

TL：DR;
完成したダッシュボードへのリンク.

当社が使用する情報を収集するため 流暢、加工用 - AWS Kinesis データ ファイアホース и AWSグルー、保管用 - AWS S3。 このバンドルを使用すると、nginx ログだけでなく、他のイベントや他のサービスのログも保存できます。 スタックの一部の部分を同様のものに置き換えることができます。たとえば、fluentd をバイパスして nginx から直接 kinesis にログを書き込んだり、これに logstash を使用したりできます。

Nginx ログの収集

デフォルトでは、Nginx ログは次のようになります。

4/9/2019 12:58:17 PM1.1.1.1 - - [09/Apr/2019:09:58:17 +0000] "GET /sign-up HTTP/2.0" 200 9168 "https://example.com/sign-in" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36" "-"
4/9/2019 12:58:17 PM1.1.1.1 - - [09/Apr/2019:09:58:17 +0000] "GET /sign-in HTTP/2.0" 200 9168 "https://example.com/sign-up" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36" "-"

これらは解析できますが、JSON でログが生成されるように Nginx 構成を修正する方がはるかに簡単です。

log_format json_combined escape=json '{ "created_at": "$msec", '
            '"remote_addr": "$remote_addr", '
            '"remote_user": "$remote_user", '
            '"request": "$request", '
            '"status": $status, '
            '"bytes_sent": $bytes_sent, '
            '"request_length": $request_length, '
            '"request_time": $request_time, '
            '"http_referrer": "$http_referer", '
            '"http_x_forwarded_for": "$http_x_forwarded_for", '
            '"http_user_agent": "$http_user_agent" }';

access_log  /var/log/nginx/access.log  json_combined;

ストレージ用のS3

ログを保存するには、S3 を使用します。 これにより、Athena は S3 内のデータを直接操作できるため、ログを 3 か所に保存して分析できます。 この記事の後半では、ログを正しく追加して処理する方法について説明しますが、最初に、他に何も保存されない、SXNUMX 内のクリーンなバケットが必要です。 Athena はすべてのリージョンで利用できるわけではないため、どのリージョンでバケットを作成するかを事前に検討する価値があります。

Athena コンソールでの回路の作成

Athena にログ用のテーブルを作成しましょう。 Kinesis Firehose を使用する場合は、書き込みと読み取りの両方に必要です。 Athena コンソールを開いてテーブルを作成します。

SQLテーブルの作成

CREATE EXTERNAL TABLE `kinesis_logs_nginx`(
  `created_at` double, 
  `remote_addr` string, 
  `remote_user` string, 
  `request` string, 
  `status` int, 
  `bytes_sent` int, 
  `request_length` int, 
  `request_time` double, 
  `http_referrer` string, 
  `http_x_forwarded_for` string, 
  `http_user_agent` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.orc.OrcSerde' 
STORED AS INPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat'
LOCATION
  's3://<YOUR-S3-BUCKET>'
TBLPROPERTIES ('has_encrypted_data'='false');

Kinesis Firehose ストリームの作成

Kinesis Firehose は、Nginx から受信したデータを選択した形式で S3 に書き込み、YYYY/MM/DD/HH 形式のディレクトリに分割します。 データを読み取るときに便利です。 もちろん、fluentd から S3 に直接書き込むこともできますが、この場合は JSON を書き込む必要があり、ファイル サイズが大きいため非効率です。 さらに、PrestoDB または Athena を使用する場合、JSON は最も遅いデータ形式です。 そこで、Kinesis Firehose コンソールを開き、「配信ストリームの作成」をクリックし、「配信」フィールドで「direct PUT」を選択します。

次のタブで、「記録フォーマット変換」-「有効」を選択し、記録フォーマットとして「Apache ORC」を選択します。 ある研究によると オーウェン・オマリー、これは PrestoDB と Athena に最適な形式です。 上で作成したテーブルをスキーマとして使用します。 kinesis では任意の S3 の場所を指定できますが、テーブルからはスキーマのみが使用されることに注意してください。 ただし、別の S3 の場所を指定すると、このテーブルからこれらのレコードを読み取ることができなくなります。

ストレージとして S3 を選択し、前に作成したバケットを選択します。 Aws Glue Crawler は、後ほど説明しますが、S3 バケット内のプレフィックスを処理できないため、空のままにしておくことが重要です。

残りのオプションは負荷に応じて変更できますが、通常はデフォルトのオプションを使用します。 S3 圧縮は利用できませんが、ORC はデフォルトでネイティブ圧縮を使用することに注意してください。

流暢

ログの保存と受信を構成したので、送信を構成する必要があります。 我々は使用するだろう 流暢、私は Ruby が大好きなので、Logstash を使用したり、ログを kinesis に直接送信したりすることもできます。 Fluentd サーバーはいくつかの方法で起動できますが、簡単で便利な docker について説明します。

まず、fluent.conf 設定ファイルが必要です。 それを作成してソースを追加します。

type フォワード
ポート24224
バインド0.0.0.0

これで、Fluentd サーバーを起動できるようになりました。 より高度な構成が必要な場合は、次のサイトにアクセスしてください。 Dockerハブ 画像の組み立て方法を含む詳細なガイドがあります。

$ docker run 
  -d 
  -p 24224:24224 
  -p 24224:24224/udp 
  -v /data:/fluentd/log 
  -v <PATH-TO-FLUENT-CONF>:/fluentd/etc fluentd 
  -c /fluentd/etc/fluent.conf
  fluent/fluentd:stable

この構成ではパスを使用します /fluentd/log 送信前にログをキャッシュします。 これを行わなくても大丈夫ですが、再起動すると、骨の折れる作業でキャッシュされたすべてが失われる可能性があります。 任意のポートを使用することもできます。24224 がデフォルトの Fluentd ポートです。

Fluentd が実行されているので、そこに Nginx ログを送信できます。 通常、Nginx を Docker コンテナーで実行します。この場合、Docker には Fluentd 用のネイティブ ロギング ドライバーが含まれています。

$ docker run 
--log-driver=fluentd 
--log-opt fluentd-address=<FLUENTD-SERVER-ADDRESS>
--log-opt tag="{{.Name}}" 
-v /some/content:/usr/share/nginx/html:ro 
-d 
nginx

Nginx を別の方法で実行する場合は、ログ ファイルを使用できます。Fluentd には、 ファイルテールプラグイン.

上記で設定したログ解析を Fluent 設定に追加してみましょう。

<filter YOUR-NGINX-TAG.*>
  @type parser
  key_name log
  emit_invalid_record_to_error false
  <parse>
    @type json
  </parse>
</filter>

そして、次を使用してログをKinesisに送信します kinesis firehose プラグイン:

<match YOUR-NGINX-TAG.*>
    @type kinesis_firehose
    region region
    delivery_stream_name <YOUR-KINESIS-STREAM-NAME>
    aws_key_id <YOUR-AWS-KEY-ID>
    aws_sec_key <YOUR_AWS-SEC_KEY>
</match>

アテナ

すべてが正しく設定されている場合は、しばらくすると (デフォルトでは、Kinesis は受信データを 10 分ごとに記録します)、S3 にログファイルが表示されます。 Kinesis Firehose の「モニタリング」メニューでは、S3 に記録されているデータの量とエラーを確認できます。 S3 バケットへの書き込みアクセスを Kinesis ロールに付与することを忘れないでください。 Kinesis が何かを解析できなかった場合、同じバケットにエラーを追加します。

これで、Athena でデータを表示できるようになりました。 エラーを返した最新のリクエストを見つけてみましょう。

SELECT * FROM "db_name"."table_name" WHERE status > 499 ORDER BY created_at DESC limit 10;

リクエストごとにすべてのレコードをスキャンする

これでログが処理され、ORC の S3 に保存され、圧縮されて分析できるようになりました。 Kinesis Firehose では、時間ごとにディレクトリに整理することもできました。 ただし、テーブルがパーティション化されていない限り、Athena は、まれな例外を除いて、すべてのリクエストで常時データを読み込みます。 これは次の XNUMX つの理由から大きな問題です。

• データ量は常に増加しており、クエリの速度が遅くなります。
• Athena はスキャンされたデータの量に基づいて課金され、リクエストごとに最低 10 MB が使用されます。

これを修正するには、AWS Glue Crawler を使用します。これは、S3 内のデータをクロールし、パーティション情報を Glue Metastore に書き込みます。 これにより、Athena にクエリを実行するときにパーティションをフィルターとして使用できるようになり、クエリで指定されたディレクトリのみがスキャンされます。

Amazon Glue クローラーのセットアップ

Amazon Glue Crawler は、S3 バケット内のすべてのデータをスキャンし、パーティションを含むテーブルを作成します。 AWS Glue コンソールから Glue クローラーを作成し、データを保存するバケットを追加します。 複数のバケットに対して XNUMX つのクローラーを使用できます。その場合、指定されたデータベースにバケットの名前と一致する名前のテーブルが作成されます。 このデータを定期的に使用する予定がある場合は、ニーズに合わせて Crawler の起動スケジュールを構成してください。 すべてのテーブルに対して XNUMX つのクローラーを使用し、XNUMX 時間ごとに実行します。

パーティション化されたテーブル

クローラーを初めて起動すると、スキャンされた各バケットのテーブルが設定で指定されたデータベースに表示されます。 Athena コンソールを開き、Nginx ログが含まれるテーブルを見つけます。 何かを読んでみましょう:

SELECT * FROM "default"."part_demo_kinesis_bucket"
WHERE(
  partition_0 = '2019' AND
  partition_1 = '04' AND
  partition_2 = '08' AND
  partition_3 = '06'
  );

このクエリは、6 年 7 月 8 日の午前 2019 時から午前 XNUMX 時までに受信したすべてのレコードを選択します。 しかし、これは、パーティション化されていないテーブルから単に読み取るよりもどれだけ効率的でしょうか? 同じレコードを見つけて選択し、タイムスタンプでフィルターしてみましょう。

わずか 3.59 週間のログを含むデータセット上の 244.34 秒、XNUMX メガバイトのデータ。 パーティションごとにフィルターを試してみましょう。

少し高速ですが、最も重要なのは、データ量がわずか 1.23 メガバイトであることです。 価格設定にリクエストあたり最低 10 メガバイトがなければ、はるかに安くなります。 しかし、それでもはるかに優れており、大規模なデータセットではその違いはさらに印象的になります。

Cube.js を使用したダッシュボードの構築

ダッシュボードを組み立てるには、Cube.js 分析フレームワークを使用します。 非常に多くの機能がありますが、私たちが注目しているのは XNUMX つです。パーティション フィルターとデータの事前集計を自動的に使用する機能です。 データスキーマを使用します データスキーマ、SQL を生成し、データベース クエリを実行するために Javascript で記述されています。 データ スキーマでパーティション フィルターの使用方法を指定するだけで済みます。

新しい Cube.js アプリケーションを作成しましょう。 すでに AWS スタックを使用しているため、デプロイメントに Lambda を使用するのは論理的です。 Heroku または Docker で Cube.js バックエンドをホストする予定がある場合は、Express テンプレートを生成に使用できます。 ドキュメントではその他について説明しています ホスティング方法.

$ npm install -g cubejs-cli
$ cubejs create nginx-log-analytics -t serverless -d athena

環境変数は、cube.js でデータベース アクセスを構成するために使用されます。 ジェネレーターは、キーを指定できる .env ファイルを作成します。 アテナ.

今必要なのは データスキーマここでは、ログがどのように保存されるかを正確に示します。 そこでは、ダッシュボードのメトリクスを計算する方法を指定することもできます。

ディレクトリ内 schema、ファイルを作成します Logs.js。 nginx のデータ モデルの例を次に示します。

型式コード

const partitionFilter = (from, to) => `
    date(from_iso8601_timestamp(${from})) <= date_parse(partition_0 || partition_1 || partition_2, '%Y%m%d') AND
    date(from_iso8601_timestamp(${to})) >= date_parse(partition_0 || partition_1 || partition_2, '%Y%m%d')
    `

cube(`Logs`, {
  sql: `
  select * from part_demo_kinesis_bucket
  WHERE ${FILTER_PARAMS.Logs.createdAt.filter(partitionFilter)}
  `,

  measures: {
    count: {
      type: `count`,
    },

    errorCount: {
      type: `count`,
      filters: [
        { sql: `${CUBE.isError} = 'Yes'` }
      ]
    },

    errorRate: {
      type: `number`,
      sql: `100.0 * ${errorCount} / ${count}`,
      format: `percent`
    }
  },

  dimensions: {
    status: {
      sql: `status`,
      type: `number`
    },

    isError: {
      type: `string`,
      case: {
        when: [{
          sql: `${CUBE}.status >= 400`, label: `Yes`
        }],
        else: { label: `No` }
      }
    },

    createdAt: {
      sql: `from_unixtime(created_at)`,
      type: `time`
    }
  }
});

ここでは変数を使用しています FILTER_PARAMSパーティション フィルターを使用して SQL クエリを生成します。

また、ダッシュボードに表示するメトリクスとパラメータを設定し、事前集計を指定します。 Cube.js は、事前に集計されたデータを含む追加のテーブルを作成し、データが到着すると自動的に更新します。 これにより、クエリが高速化されるだけでなく、Athena の使用コストも削減されます。

この情報をデータ スキーマ ファイルに追加しましょう。

preAggregations: {
  main: {
    type: `rollup`,
    measureReferences: [count, errorCount],
    dimensionReferences: [isError, status],
    timeDimensionReference: createdAt,
    granularity: `day`,
    partitionGranularity: `month`,
    refreshKey: {
      sql: FILTER_PARAMS.Logs.createdAt.filter((from, to) => 
        `select
           CASE WHEN from_iso8601_timestamp(${to}) + interval '3' day > now()
           THEN date_trunc('hour', now()) END`
      )
    }
  }
}

このモデルでは、使用されるすべてのメトリクスのデータを事前に集計し、月ごとにパーティション分割を使用する必要があることを指定します。 事前集約パーティショニング データの収集と更新を大幅に高速化できます。

これでダッシュボードを組み立てることができます！

Cube.js バックエンドが提供するもの REST API また、一般的なフロントエンド フレームワーク用のクライアント ライブラリのセットも含まれます。 React バージョンのクライアントを使用してダッシュボードを構築します。 Cube.js はデータのみを提供するため、視覚化ライブラリが必要になります - 私はそれが好きです 再チャート, しかし、どれでも使えます。

Cube.js サーバーはリクエストを受け入れます。 JSON形式、必要なメトリクスを指定します。 たとえば、Nginx が XNUMX 日に発生したエラーの数を計算するには、次のリクエストを送信する必要があります。

{
  "measures": ["Logs.errorCount"],
  "timeDimensions": [
    {
      "dimension": "Logs.createdAt",
      "dateRange": ["2019-01-01", "2019-01-07"],
      "granularity": "day"
    }
  ]
}

Cube.js クライアントと React コンポーネント ライブラリを NPM 経由でインストールしましょう。

$ npm i --save @cubejs-client/core @cubejs-client/react

コンポーネントを輸入しています cubejs и QueryRendererデータをダウンロードし、ダッシュボードを収集するには:

ダッシュボードコード

import React from 'react';
import { LineChart, Line, XAxis, YAxis } from 'recharts';
import cubejs from '@cubejs-client/core';
import { QueryRenderer } from '@cubejs-client/react';

const cubejsApi = cubejs(
  'YOUR-CUBEJS-API-TOKEN',
  { apiUrl: 'http://localhost:4000/cubejs-api/v1' },
);

export default () => {
  return (
    <QueryRenderer
      query={{
        measures: ['Logs.errorCount'],
        timeDimensions: [{
            dimension: 'Logs.createdAt',
            dateRange: ['2019-01-01', '2019-01-07'],
            granularity: 'day'
        }]
      }}
      cubejsApi={cubejsApi}
      render={({ resultSet }) => {
        if (!resultSet) {
          return 'Loading...';
        }

        return (
          <LineChart data={resultSet.rawData()}>
            <XAxis dataKey="Logs.createdAt"/>
            <YAxis/>
            <Line type="monotone" dataKey="Logs.errorCount" stroke="#8884d8"/>
          </LineChart>
        );
      }}
    />
  )
}

ダッシュボードのソースは次の場所から入手できます。 コードサンドボックス.

出所： habr.com