Amazon Athena 및 Cube.js를 사용한 Nginx 로그 분석

일반적으로 Prometheus + Grafana와 같은 상용 제품이나 기성 오픈 소스 대안을 사용하여 Nginx의 작동을 모니터링하고 분석합니다. 이는 모니터링이나 실시간 분석에는 좋은 옵션이지만 기록 분석에는 그다지 편리하지 않습니다. 널리 사용되는 모든 리소스에서는 nginx 로그의 데이터 양이 빠르게 증가하고 있으며, 많은 양의 데이터를 분석하려면 좀 더 전문적인 것을 사용하는 것이 논리적입니다.

이번 글에서는 어떻게 활용하는지 알려드리겠습니다. 아테나 Nginx를 예로 들어 로그를 분석하고, 오픈 소스 Cube.js 프레임워크를 사용하여 이 데이터에서 분석 대시보드를 구성하는 방법을 보여 드리겠습니다. 전체 솔루션 아키텍처는 다음과 같습니다.

TL:DR;
완성된 대시보드에 대한 링크.

우리가 사용하는 정보를 수집하기 위해 유창함, 처리용 - AWS Kinesis 데이터 파이어호스 и AWS 접착제, 저장용 - AWS S3. 이 번들을 사용하면 nginx 로그뿐만 아니라 기타 이벤트 및 기타 서비스의 로그도 저장할 수 있습니다. 일부 부품을 스택과 유사한 부품으로 교체할 수 있습니다. 예를 들어 nginx에서 직접 kinesis에 로그를 작성하거나 fluentd를 우회하거나 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의 데이터로 직접 작업할 수 있으므로 이를 통해 로그를 한 곳에 저장하고 분석할 수 있습니다. 기사 뒷부분에서 로그를 올바르게 추가하고 처리하는 방법을 설명하겠지만 먼저 S3에 아무것도 저장되지 않는 깨끗한 버킷이 필요합니다. 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 콘솔을 열고 "전송 스트림 생성"을 클릭한 후 "전송" 필드에서 "직접 PUT"을 선택합니다.

다음 탭에서 "레코드 형식 변환" - "활성화"를 선택하고 녹음 형식으로 "Apache ORC"를 선택합니다. 일부 연구에 따르면 오웬 오말리, 이는 PrestoDB 및 Athena에 가장 적합한 형식입니다. 위에서 만든 테이블을 스키마로 사용합니다. Kinesis에서는 S3 위치를 지정할 수 있으며 테이블에서는 스키마만 사용됩니다. 그러나 다른 S3 위치를 지정하면 이 테이블에서 해당 레코드를 읽을 수 없습니다.

스토리지로 S3를 선택하고 앞서 생성한 버킷을 선택합니다. 나중에 설명할 Aws Glue Crawler는 S3 버킷의 접두사를 사용할 수 없으므로 비워 두는 것이 중요합니다.

나머지 옵션은 부하에 따라 변경될 수 있는데 저는 주로 기본 옵션을 사용합니다. S3 압축은 사용할 수 없지만 ORC는 기본적으로 기본 압축을 사용합니다.

유창함

이제 로그 저장 및 수신을 구성했으므로 전송을 구성해야 합니다. 우리는 사용할 것이다 유창함, 저는 Ruby를 좋아하기 때문에 Logstash를 사용하거나 로그를 Kinesis로 직접 보낼 수 있습니다. Fluentd 서버는 여러 가지 방법으로 시작할 수 있는데, 간단하고 편리하기 때문에 docker에 대해 말씀드리겠습니다.

먼저 fluent.conf 구성 파일이 필요합니다. 그것을 만들고 소스를 추가하십시오 :

유형 앞으로
포트 24224
바인드 0.0.0.0

이제 Fluentd 서버를 시작할 수 있습니다. 보다 고급 구성이 필요한 경우 다음으로 이동하세요. 도커 허브 이미지를 조립하는 방법을 포함한 자세한 가이드가 있습니다.

$ 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 로그를 그곳으로 보낼 수 있습니다. 우리는 일반적으로 Docker 컨테이너에서 Nginx를 실행합니다. 이 경우 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에 기록된 데이터의 양과 오류를 확인할 수 있습니다. Kinesis 역할에 S3 버킷에 대한 쓰기 액세스 권한을 부여하는 것을 잊지 마십시오. Kinesis가 무언가를 구문 분석할 수 없으면 동일한 버킷에 오류를 추가합니다.

이제 Athena에서 데이터를 볼 수 있습니다. 오류를 반환한 최근 요청을 찾아보겠습니다.

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

각 요청에 대한 모든 기록 검색

이제 로그가 처리되어 ORC의 S3에 저장되었으며 압축되어 분석할 준비가 되었습니다. Kinesis Firehose는 이를 매 시간마다 디렉터리로 구성했습니다. 그러나 테이블이 분할되지 않는 한 Athena는 드문 예외를 제외하고 모든 요청에 ​​대해 전체 시간 데이터를 로드합니다. 이는 다음 두 가지 이유로 큰 문제입니다.

• 데이터의 양이 지속적으로 증가하여 쿼리 속도가 느려집니다.
• Athena는 스캔한 데이터의 양을 기준으로 요금이 청구되며 요청당 최소 10MB입니다.

이 문제를 해결하기 위해 우리는 S3의 데이터를 크롤링하고 Glue Metastore에 파티션 정보를 쓰는 AWS Glue Crawler를 사용합니다. 이를 통해 Athena를 쿼리할 때 파티션을 필터로 사용할 수 있으며 쿼리에 지정된 디렉터리만 스캔합니다.

Amazon Glue 크롤러 설정

Amazon Glue Crawler는 S3 버킷의 모든 데이터를 스캔하고 파티션이 있는 테이블을 생성합니다. AWS Glue 콘솔에서 Glue 크롤러를 생성하고 데이터를 저장할 버킷을 추가합니다. 여러 버킷에 대해 하나의 크롤러를 사용할 수 있으며, 이 경우 지정된 데이터베이스에 버킷 이름과 일치하는 이름을 가진 테이블이 생성됩니다. 이 데이터를 정기적으로 사용할 계획이라면 필요에 맞게 크롤러의 실행 일정을 구성해야 합니다. 우리는 모든 테이블에 대해 매시간 실행되는 하나의 크롤러를 사용합니다.

파티션을 나눈 테이블

크롤러를 처음 시작한 후에는 스캔한 각 버킷에 대한 테이블이 설정에 지정된 데이터베이스에 나타나야 합니다. 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.34MB의 데이터가 있습니다. 파티션별로 필터링해 보겠습니다.

조금 더 빠르지만 가장 중요한 것은 데이터가 1.23MB에 불과하다는 것입니다! 가격이 요청당 최소 10MB가 아니라면 훨씬 저렴할 것입니다. 그러나 여전히 훨씬 더 좋으며 대규모 데이터 세트에서는 그 차이가 훨씬 더 인상적입니다.

Cube.js를 사용하여 대시보드 구축

대시보드를 구성하기 위해 Cube.js 분석 프레임워크를 사용합니다. 꽤 많은 기능이 있지만 우리는 두 가지, 즉 파티션 필터를 자동으로 사용하는 기능과 데이터 사전 집계에 관심이 있습니다. 데이터 스키마를 사용합니다. 데이터 스키마, 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가 일별 오류 수를 계산하려면 다음 요청을 보내야 합니다.

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

NPM을 통해 Cube.js 클라이언트와 React 구성 요소 라이브러리를 설치해 보겠습니다.

$ 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