Анализа на евиденција на Nginx користејќи Amazon Athena и Cube.js

Обично, комерцијалните производи или готови алтернативи со отворен код, како што се Prometheus + Grafana, се користат за следење и анализа на работата на Nginx. Ова е добра опција за следење или аналитика во реално време, но не е многу погодна за историска анализа. На кој било популарен ресурс, обемот на податоци од дневниците на nginx рапидно расте, а за да се анализира голема количина на податоци, логично е да се користи нешто поспецијализирано.

Во оваа статија ќе ви кажам како можете да го користите Атена да ги анализираме дневниците, земајќи го Nginx како пример, и ќе покажам како да составам аналитичка контролна табла од овие податоци користејќи ја рамката со отворен код cube.js. Еве ја целосната архитектура на решението:

TL:DR;
Врска до завршената контролна табла.

За собирање информации што ги користиме Течно, за обработка - AWS Kinesis Data Firehose и AWS лепак, за складирање - AWS S3. Користејќи го овој пакет, можете да складирате не само дневници на nginx, туку и други настани, како и дневници на други услуги. Можете да замените некои делови со слични за вашиот стек, на пример, можете да напишете логови во кинезис директно од nginx, заобиколувајќи го 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" "-"

Тие можат да се анализираат, но многу е полесно да се коригира конфигурацијата на Nginx за да произведува дневници во JSON:

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 не е достапна во сите региони.

Создавање коло во конзолата Атина

Ајде да создадеме табела во Атина за дневници. Потребен е и за пишување и за читање доколку планирате да користите 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 во избраниот формат, поделувајќи ги во директориуми во формат ГГГГ/ММ/ДД/ВВ. Ова ќе ви помогне при читање податоци. Се разбира, можете да пишувате директно на S3 од fluentd, но во овој случај ќе мора да напишете JSON, а тоа е неефикасно поради големата големина на датотеките. Дополнително, кога користите PrestoDB или Athena, JSON е најбавниот формат на податоци. Затоа, отворете ја конзолата Kinesis Firehose, кликнете „Креирај поток за испорака“, изберете „директно PUT“ во полето „испорака“:

Во следното јазиче, изберете „Конверзија на формат за снимање“ - „Овозможено“ и изберете „Apache ORC“ како формат за снимање. Според некои истражувања Овен О'Мали, ова е оптималниот формат за PrestoDB и Athena. Ја користиме табелата што ја создадовме погоре како шема. Ве молиме имајте предвид дека можете да наведете која било локација S3 во кинеза; само шемата се користи од табелата. Но, ако наведете друга локација на S3, тогаш нема да можете да ги читате овие записи од оваа табела.

Избираме S3 за складирање и корпата што ја создадовме претходно. Aws Glue Crawler, за кој ќе зборувам малку подоцна, не може да работи со префикси во кофа S3, па затоа е важно да го оставите празен.

Останатите опции може да се променат во зависност од вашето оптоварување; јас обично ги користам стандардните. Забележете дека компресијата S3 не е достапна, но ORC стандардно користи мајчин компресија.

Течно

Сега кога конфигуриравме складирање и примање дневници, треба да го конфигурираме испраќањето. Ние ќе користиме Течно, затоа што ја сакам Руби, но можете да користите Logstash или директно да испраќате логови на кинезис. Серверот 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 таму. Ние обично работиме 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 не може да анализира нешто, ќе ги додаде грешките во истата кофа.

Сега можете да ги видите податоците во Атина. Ајде да ги најдеме најновите барања за кои вративме грешки:

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

Скенирање на сите записи за секое барање

Сега нашите дневници се обработени и складирани во S3 во ORC, компресирани и подготвени за анализа. Kinesis Firehose дури ги организираше во директориуми за секој час. Сепак, се додека табелата не е поделена, Athena ќе вчита податоци за сите времиња на секое барање, со ретки исклучоци. Ова е голем проблем од две причини:

• Обемот на податоци постојано расте, забавувајќи ги барањата;
• Атина се наплаќа врз основа на обемот на скенирани податоци, со минимум 10 MB по барање.

За да го поправиме ова, користиме AWS Glue Crawler, кој ќе ги индексира податоците во S3 и ќе ги запише информациите за партицијата во Glue Metastore. Ова ќе ни овозможи да користиме партиции како филтер при барањето на Athena и ќе ги скенира само директориумите наведени во барањето.

Поставување на Amazon Glue Crawler

Amazon Glue Crawler ги скенира сите податоци во корпата S3 и создава табели со партиции. Создадете лепак Crawler од конзолата AWS Glue и додадете кофа каде што ги складирате податоците. Може да користите еден робот за неколку корпи, во тој случај ќе создаде табели во наведената база на податоци со имиња што одговараат на имињата на корпите. Ако планирате редовно да ги користите овие податоци, не заборавајте да го конфигурирате распоредот за стартување на Crawler за да одговара на вашите потреби. Ние користиме еден Crawler за сите табели, кој работи секој час.

Поделени табели

По првото стартување на роботот, табелите за секоја скенирана корпа треба да се појават во базата на податоци наведена во поставките. Отворете ја конзолата 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 година. Но, колку е ова поефикасно од само читање од непартиционирана табела? Ајде да дознаеме и да ги избереме истите записи, филтрирајќи ги по временски печат:

3.59 секунди и 244.34 мегабајти податоци на база на податоци со само една недела дневници. Ајде да пробаме филтер по партиција:

Малку побрзо, но најважно - само 1.23 мегабајти податоци! Тоа би било многу поевтино ако не за минималните 10 мегабајти по барање во цената. Но, сепак е многу подобро, а кај големите збирки на податоци разликата ќе биде многу поимпресивна.

Изградба на контролна табла користејќи Cube.js

За да ја составиме контролната табла, ја користиме аналитичката рамка Cube.js. Има доста функции, но ние сме заинтересирани за две: способност за автоматско користење на филтри за партиции и пред-агрегација на податоци. Таа користи податочна шема податочна шема, напишана во Javascript за да генерира SQL и да изврши барање за базата на податоци. Треба само да покажеме како да го користиме филтерот за партиции во шемата за податоци.

Ајде да создадеме нова апликација Cube.js. Бидејќи веќе го користиме стекот AWS, логично е да се користи Lambda за распоредување. Можете да го користите експресниот шаблон за генерирање ако планирате да го хостирате заднината на Cube.js во Heroku или Docker. Документацијата опишува други методи за хостирање.

$ 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 backend обезбедува ОСТАНАТОТО API и збир на библиотеки на клиенти за популарни рамки од предниот дел. Ќе ја користиме верзијата React на клиентот за да ја изградиме контролната табла. Cube.js обезбедува само податоци, така што ќе ни треба библиотека за визуелизација - ми се допаѓа пресликувања, но можете да користите било кој.

Серверот Cube.js го прифаќа барањето во JSON формат, кој ги специфицира потребните метрики. На пример, за да пресметате колку грешки даваше Nginx на ден, треба да го испратите следново барање:

{
  "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>
        );
      }}
    />
  )
}

Изворите на контролната табла се достапни на шифра со песок.

Извор: www.habr.com