Нгинк лог аналитика користећи Амазон Атхена и Цубе.јс

Обично се комерцијални производи или готове алтернативе отвореног кода, као што су Прометхеус + Графана, користе за праћење и анализу рада Нгинк-а. Ово је добра опција за праћење или аналитику у реалном времену, али није баш згодна за историјску анализу. На било ком популарном ресурсу, обим података из нгинк дневника брзо расте, а за анализу велике количине података логично је користити нешто специјализованије.

У овом чланку ћу вам рећи како можете користити Атина да анализирам дневнике, узимајући Нгинк као пример, и показаћу како да саставим аналитичку контролну таблу од ових података користећи опен-соурце цубе.јс фрамеворк. Ево комплетне архитектуре решења:

ТЛ:ДР;
Веза до готове контролне табле.

За прикупљање информација које користимо Флуентд, за обраду - АВС Кинесис Дата Фирехосе и АВС лепак, за складиштење - АВС С3. Користећи овај пакет, можете да складиштите не само нгинк евиденције, већ и друге догађаје, као и евиденције других услуга. Можете заменити неке делове сличним за свој стек, на пример, можете писати дневнике у кинесис директно из нгинк-а, заобилазећи флуентд, или користити логстасх за ово.

Прикупљање Нгинк дневника

Подразумевано, Нгинк евиденције изгледају отприлике овако:

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" "-"

Могу се рашчланити, али је много лакше исправити Нгинк конфигурацију тако да производи евиденције у ЈСОН-у:

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;

С3 за складиштење

За складиштење дневника користићемо С3. Ово вам омогућава да чувате и анализирате евиденције на једном месту, пошто Атхена може директно да ради са подацима у С3. Касније у чланку ћу вам рећи како правилно додати и обрадити евиденције, али прво нам је потребна чиста канта у С3, у којој ништа друго неће бити ускладиштено. Вреди унапред размислити у ком региону ћете правити своју корпу, јер Атхена није доступна у свим регионима.

Креирање кола у Атхена конзоли

Хајде да направимо табелу у Атени за дневнике. Потребан је и за писање и за читање ако планирате да користите Кинесис Фирехосе. Отворите Атхена конзолу и креирајте табелу:

Креирање СКЛ табеле

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');

Креирање Кинесис Фирехосе Стреам-а

Кинесис Фирехосе ће податке примљене од Нгинк-а записати у С3 у изабраном формату, поделивши их у директоријуме у формату ГГГГ/ММ/ДД/ХХ. Ово ће вам добро доћи приликом читања података. Можете, наравно, писати директно у С3 из флуентд-а, али у овом случају ћете морати да пишете ЈСОН, а то је неефикасно због велике величине датотека. Поред тога, када користите ПрестоДБ или Атхена, ЈСОН је најспорији формат података. Дакле, отворите Кинесис Фирехосе конзолу, кликните на „Креирај ток испоруке“, изаберите „директно ПУТ“ у пољу „испорука“:

На следећој картици изаберите „Конверзија формата записа“ - „Омогућено“ и изаберите „Апацхе ОРЦ“ као формат снимања. Према неким истраживањима Овен О'Маллеи, ово је оптимални формат за ПрестоДБ и Атхена. Користимо табелу коју смо креирали изнад као шему. Имајте на уму да можете навести било коју С3 локацију у кинези; само се шема користи из табеле. Али ако наведете другу С3 локацију, нећете моћи да читате ове записе из ове табеле.

Бирамо С3 за складиштење и канту коју смо раније креирали. Авс Глуе Цравлер, о коме ћу говорити мало касније, не може да ради са префиксима у С3 канти, па је важно да га оставите празним.

Преостале опције се могу променити у зависности од вашег оптерећења; обично користим подразумеване. Имајте на уму да С3 компресија није доступна, али ОРЦ подразумевано користи изворну компресију.

Флуентд

Сада када смо конфигурисали чување и пријем евиденције, морамо да конфигуришемо слање. Користићемо Флуентд, зато што волим Руби, али можете користити Логстасх или слати дневнике директно у кинесис. Флуентд сервер се може покренути на неколико начина, рећи ћу вам о доцкеру јер је једноставан и згодан.

Прво, потребна нам је конфигурациона датотека флуент.цонф. Направите га и додајте извор:

тип напред
Порт КСНУМКС
везати 0.0.0.0

Сада можете да покренете Флуентд сервер. Ако вам је потребна напреднија конфигурација, идите на Доцкер Хуб Постоји детаљан водич, укључујући како да саставите своју слику.

$ 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 је подразумевани Флуентд порт.

Сада када имамо покренут Флуентд, можемо тамо послати Нгинк евиденције. Обично покрећемо Нгинк у Доцкер контејнеру, у ком случају Доцкер има изворни драјвер за евидентирање за Флуентд:

$ 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

Ако Нгинк покренете другачије, можете користити датотеке евиденције, има Флуентд додатак за реп датотеке.

Хајде да додамо претходно конфигурисану анализу дневника у Флуент конфигурацију:

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

И слање дневника у Кинесис користећи кинесис фирехосе плугин:

<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>

Атина

Ако сте све исправно конфигурисали, након неког времена (подразумевано, Кинесис снима примљене податке сваких 10 минута) требало би да видите датотеке евиденције у С3. У менију „мониторинг“ Кинесис Фирехосе-а можете видети колико података је забележено у С3, као и грешке. Не заборавите да дате приступ за писање у С3 буцкет улози Кинесис. Ако Кинесис не може да анализира нешто, додаће грешке у исту канту.

Сада можете да видите податке у Атени. Хајде да пронађемо најновије захтеве за које смо вратили грешке:

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

Скенирање свих записа за сваки захтев

Сада су наши дневници обрађени и ускладиштени у С3 у ОРЦ-у, компримовани и спремни за анализу. Кинесис Фирехосе их је чак организовао у директоријуме за сваки сат. Међутим, све док табела није партиционисана, Атена ће учитавати податке свих времена на сваки захтев, са ретким изузецима. Ово је велики проблем из два разлога:

• Обим података стално расте, успоравајући упите;
• Атхена се наплаћује на основу количине скенираних података, са најмање 10 МБ по захтеву.

Да бисмо ово поправили, користимо АВС Глуе Цравлер, који ће индексирати податке у С3 и записати информације о партицији у Глуе Метасторе. Ово ће нам омогућити да користимо партиције као филтер када постављамо упите за Атхену, и скенираће само директоријуме наведене у упиту.

Подешавање Амазон Глуе Цравлер-а

Амазон Глуе Цравлер скенира све податке у С3 канти и креира табеле са партицијама. Креирајте Глуе Цравлер са АВС Глуе конзоле и додајте канту где чувате податке. Можете да користите један пописивач за неколико група, у ком случају ће креирати табеле у наведеној бази података са именима која одговарају називима буцкетс. Ако планирате да редовно користите ове податке, обавезно конфигуришите распоред покретања Цравлер-а тако да одговара вашим потребама. Користимо један Цравлер за све табеле, који ради сваког сата.

Партиционисани столови

Након првог покретања пописивача, табеле за сваку скенирану корпу треба да се појаве у бази података наведеној у подешавањима. Отворите Атхена конзолу и пронађите табелу са Нгинк евиденцијама. Хајде да покушамо нешто да прочитамо:

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

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

Мало брже, али најважније - само 1.23 мегабајта података! Било би много јефтиније да нема минималних 10 мегабајта по захтеву у цени. Али и даље је много боље, а на великим скуповима података разлика ће бити много импресивнија.

Прављење контролне табле помоћу Цубе.јс

За склапање контролне табле користимо Цубе.јс аналитички оквир. Има доста функција, али нас занимају две: могућност аутоматског коришћења партиционих филтера и претходно агрегирање података. Користи шему података шема података, написан у Јавасцрипт-у за генерисање СКЛ-а и извршавање упита базе података. Само треба да назначимо како да користимо филтер партиције у шеми података.

Хајде да направимо нову апликацију Цубе.јс. Пошто већ користимо АВС стек, логично је да користимо Ламбда за примену. Можете користити експресни шаблон за генерисање ако планирате да угостите позадину Цубе.јс у Хероку или Доцкер-у. Документација описује друге методе хостовања.

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

Променљиве окружења се користе за конфигурисање приступа бази података у цубе.јс. Генератор ће креирати .енв датотеку у којој можете одредити своје кључеве за Атина.

Сада нам треба шема података, у којој ћемо тачно навести како се чувају наши дневники. Тамо такође можете одредити како израчунати метрику за контролне табле.

У именику schema, креирајте датотеку Logs.js. Ево примера модела података за нгинк:

Шифра модела

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`
    }
  }
});

Овде користимо променљиву ФИЛТЕР_ПАРАМСда генеришете СКЛ упит са филтером партиција.

Такође постављамо метрике и параметре које желимо да прикажемо на контролној табли и наводимо пре-агрегације. Цубе.јс ће креирати додатне табеле са унапред агрегираним подацима и аутоматски ће ажурирати податке како стигну. Ово не само да убрзава упите, већ и смањује трошкове коришћења Атхене.

Хајде да додамо ове информације у датотеку шеме података:

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`
      )
    }
  }
}

У овом моделу наводимо да је потребно претходно агрегирати податке за све коришћене метрике и користити партиционисање по месецима. Партиционисање пре агрегације може значајно убрзати прикупљање и ажурирање података.

Сада можемо саставити контролну таблу!

Цубе.јс бацкенд пружа РЕСТ АПИ и скуп клијентских библиотека за популарне фронт-енд оквире. Користићемо Реацт верзију клијента да направимо контролну таблу. Цубе.јс пружа само податке, па ће нам требати библиотека за визуелизацију – свиђа ми се рецхартс, али можете користити било који.

Цубе.јс сервер прихвата захтев у ЈСОН формат, који наводи потребне метрике. На пример, да бисте израчунали колико је грешака Нгинк дневно дао, потребно је да пошаљете следећи захтев:

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

Хајде да инсталирамо Цубе.јс клијента и Реацт библиотеку компоненти преко НПМ-а:

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

Извори контролне табле су доступни на ЦодеСандбок.

Извор: ввв.хабр.цом