Nginx лог анализи с помощта на Amazon Athena и Cube.js

Обикновено търговски продукти или готови алтернативи с отворен код, като Prometheus + Grafana, се използват за наблюдение и анализ на работата на Nginx. Това е добра опция за наблюдение или анализи в реално време, но не е много удобна за исторически анализи. Във всеки популярен ресурс обемът на данните от регистрационните файлове на nginx нараства бързо и за анализиране на голямо количество данни е логично да се използва нещо по-специализирано.

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

TL:DR;
Линк към готовото табло.

За събиране на информация, която използваме fluentd, за обработка - AWS Kinesis Data Пожарен маркуч и AWS лепило, за съхранение - AWS S3. Използвайки този пакет, можете да съхранявате не само регистрационни файлове на nginx, но и други събития, както и регистрационни файлове на други услуги. Можете да замените някои части с подобни за вашия стек, например можете да пишете регистрационни файлове в kinesis директно от 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 не се предлага във всички региони.

Създаване на схема в конзолата 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 в избрания формат, като ги раздели на директории във формат ГГГГ/ММ/ДД/ЧЧ. Това ще бъде полезно при четене на данни. Можете, разбира се, да пишете директно в S3 от fluentd, но в този случай ще трябва да пишете JSON, а това е неефективно поради големия размер на файловете. Освен това, когато използвате PrestoDB или Athena, JSON е най-бавният формат за данни. Така че отворете конзолата Kinesis Firehose, щракнете върху „Създаване на поток за доставка“, изберете „директно ПОСТАВЯНЕ“ в полето „доставка“:

В следващия раздел изберете „Преобразуване на формат на запис“ - „Активирано“ и изберете „Apache ORC“ като формат на запис. Според някои изследвания Оуен О'Мали, това е оптималният формат за PrestoDB и Athena. Използваме таблицата, която създадохме по-горе, като схема. Моля, обърнете внимание, че можете да посочите произволно местоположение на S3 в kinesis; използва се само схемата от таблицата. Но ако посочите различно S3 местоположение, тогава няма да можете да прочетете тези записи от тази таблица.

Избираме S3 за съхранение и кофата, която създадохме по-рано. Aws Glue Crawler, за който ще говоря малко по-късно, не може да работи с префикси в кофа S3, така че е важно да я оставите празна.

Останалите опции могат да се променят в зависимост от вашето натоварване; обикновено използвам тези по подразбиране. Имайте предвид, че S3 компресията не е налична, но ORC използва собствена компресия по подразбиране.

fluentd

Сега, след като сме конфигурирали съхраняването и получаването на регистрационни файлове, трябва да конфигурираме изпращането. Ще използваме fluentd, защото обичам 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 логове там. Обикновено изпълняваме 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;

Сканиране на всички записи за всяка заявка

Сега нашите регистрационни файлове са обработени и съхранени в S3 в ORC, компресирани и готови за анализ. Kinesis Firehose дори ги организира в директории за всеки час. Въпреки това, докато таблицата не е разделена, Athena ще зарежда данни за всички времена при всяка заявка, с редки изключения. Това е голям проблем поради две причини:

• Обемът на данните непрекъснато расте, забавяйки заявките;
• Athena се таксува въз основа на обема на сканираните данни, с минимум 10 MB на заявка.

За да коригираме това, използваме AWS Glue Crawler, който ще обходи данните в S3 и ще запише информацията за дяла в Glue Metastore. Това ще ни позволи да използваме дялове като филтър при запитване към Athena и ще сканира само директориите, посочени в заявката.

Настройване на Amazon Glue Crawler

Amazon Glue Crawler сканира всички данни в кофата S3 и създава таблици с дялове. Създайте Glue 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 предоставя 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"
    }
  ]
}

Нека инсталираме клиента 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