ការវិភាគកំណត់ហេតុ Nginx ដោយប្រើ Amazon Athena និង Cube.js

ជាធម្មតា ផលិតផលពាណិជ្ជកម្ម ឬជម្រើសប្រភពបើកចំហដែលត្រៀមរួចជាស្រេច ដូចជា Prometheus + Grafana ត្រូវបានប្រើដើម្បីតាមដាន និងវិភាគប្រតិបត្តិការរបស់ Nginx ។ នេះគឺជាជម្រើសដ៏ល្អសម្រាប់ការត្រួតពិនិត្យ ឬការវិភាគតាមពេលវេលាជាក់ស្តែង ប៉ុន្តែមិនងាយស្រួលសម្រាប់ការវិភាគប្រវត្តិសាស្រ្តនោះទេ។ នៅលើធនធានដ៏ពេញនិយមណាមួយ បរិមាណនៃទិន្នន័យពីកំណត់ហេតុ nginx កំពុងតែកើនឡើងយ៉ាងឆាប់រហ័ស ហើយដើម្បីវិភាគទិន្នន័យមួយចំនួនធំ វាសមហេតុផលក្នុងការប្រើអ្វីដែលពិសេសជាងនេះ។

នៅក្នុងអត្ថបទនេះខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលអ្នកអាចប្រើ Athena ដើម្បីវិភាគកំណត់ហេតុ ដោយយក Nginx ជាឧទាហរណ៍ ហើយខ្ញុំនឹងបង្ហាញពីរបៀបប្រមូលផ្តុំផ្ទាំងគ្រប់គ្រងវិភាគពីទិន្នន័យនេះដោយប្រើ open-source cube.js framework។ នេះគឺជាស្ថាបត្យកម្មដំណោះស្រាយពេញលេញ៖

TL:DR;
ភ្ជាប់ទៅផ្ទាំងគ្រប់គ្រងដែលបានបញ្ចប់.

ដើម្បីប្រមូលព័ត៌មានយើងប្រើ ស្ទាត់សម្រាប់ដំណើរការ - AWS Kinesis Data Firehose и កាវអេវសម្រាប់ការផ្ទុក - អេស។ អេស ៣. ដោយប្រើកញ្ចប់នេះ អ្នកអាចរក្សាទុកមិនត្រឹមតែកំណត់ហេតុ nginx ប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានព្រឹត្តិការណ៍ផ្សេងទៀត ក៏ដូចជាកំណត់ហេតុនៃសេវាកម្មផ្សេងទៀតផងដែរ។ អ្នកអាចជំនួសផ្នែកខ្លះដោយផ្នែកស្រដៀងគ្នាសម្រាប់ជង់របស់អ្នក ឧទាហរណ៍ អ្នកអាចសរសេរកំណត់ហេតុទៅកាន់ kinesis ដោយផ្ទាល់ពី nginx រំលងស្ទាត់ជំនាញ ឬប្រើ 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 ក្នុងទម្រង់ដែលបានជ្រើសរើស ដោយបែងចែកវាទៅជាថតក្នុងទម្រង់ YYYY/MM/DD/HH។ វានឹងមានប្រយោជន៍នៅពេលអានទិន្នន័យ។ ជាការពិតណាស់អ្នកអាចសរសេរដោយផ្ទាល់ទៅ S3 ពីស្ទាត់ជំនាញ ប៉ុន្តែក្នុងករណីនេះអ្នកនឹងត្រូវសរសេរ JSON ហើយវាមិនមានប្រសិទ្ធភាពដោយសារតែទំហំធំនៃឯកសារ។ លើសពីនេះទៀត នៅពេលប្រើ PrestoDB ឬ Athena JSON គឺជាទម្រង់ទិន្នន័យយឺតបំផុត។ ដូច្នេះបើកកុងសូល Kinesis Firehose ចុច "បង្កើតការចែកចាយ" ជ្រើសរើស "ដោយផ្ទាល់ PUT" នៅក្នុងវាល "ការដឹកជញ្ជូន"៖

នៅក្នុងផ្ទាំងបន្ទាប់ ជ្រើសរើស "ការបម្លែងទ្រង់ទ្រាយថត" - "បានបើកដំណើរការ" ហើយជ្រើសរើស "Apache ORC" ជាទម្រង់ថត។ នេះ​បើ​តាម​ការ​ស្រាវជ្រាវ​មួយ​ចំនួន Owen O'Malleyនេះគឺជាទម្រង់ដ៏ល្អប្រសើរសម្រាប់ PrestoDB និង Athena ។ យើងប្រើតារាងដែលយើងបានបង្កើតខាងលើជាគ្រោងការណ៍។ សូមចំណាំថាអ្នកអាចបញ្ជាក់ទីតាំង S3 ណាមួយនៅក្នុង kinesis មានតែគ្រោងការណ៍ប៉ុណ្ណោះដែលត្រូវបានប្រើពីតារាង។ ប៉ុន្តែប្រសិនបើអ្នកបញ្ជាក់ទីតាំង S3 ផ្សេង នោះអ្នកនឹងមិនអាចអានកំណត់ត្រាទាំងនេះពីតារាងនេះបានទេ។

យើងជ្រើសរើស S3 សម្រាប់ការផ្ទុក និងធុងដែលយើងបានបង្កើតមុន។ Aws Glue Crawler ដែលខ្ញុំនឹងនិយាយអំពីបន្តិចក្រោយមក មិនអាចដំណើរការជាមួយបុព្វបទនៅក្នុងធុង S3 បានទេ ដូច្នេះវាជាការសំខាន់ក្នុងការទុកវាឱ្យនៅទទេ។

ជម្រើសដែលនៅសល់អាចត្រូវបានផ្លាស់ប្តូរអាស្រ័យលើបន្ទុករបស់អ្នក ជាធម្មតាខ្ញុំប្រើជម្រើសលំនាំដើម។ ចំណាំថាការបង្ហាប់ S3 មិនមានទេ ប៉ុន្តែ ORC ប្រើការបង្ហាប់ដើមតាមលំនាំដើម។

ស្ទាត់

ឥឡូវ​នេះ​យើង​បាន​កំណត់​រចនាសម្ព័ន្ធ​ការ​រក្សា​ទុក និង​ទទួល​បាន​ហើយ យើង​ត្រូវ​កំណត់​រចនាសម្ព័ន្ធ​ការ​ផ្ញើ។ យើងនឹងប្រើ ស្ទាត់ដោយសារតែខ្ញុំស្រលាញ់ Ruby ប៉ុន្តែអ្នកអាចប្រើ Logstash ឬផ្ញើកំណត់ហេតុទៅកាន់ kinesis ដោយផ្ទាល់។ ម៉ាស៊ីនមេ Fluentd អាចត្រូវបានបើកដំណើរការតាមវិធីជាច្រើន ខ្ញុំនឹងប្រាប់អ្នកអំពី docker ព្រោះវាសាមញ្ញ និងងាយស្រួល។

ដំបូងយើងត្រូវការឯកសារកំណត់រចនាសម្ព័ន្ធ fluent.conf ។ បង្កើតវា ហើយបន្ថែមប្រភព៖

ប្រភេទ ទៅមុខ
កំពង់ផែ 24224
ចង ៩

ឥឡូវនេះអ្នកអាចចាប់ផ្តើមម៉ាស៊ីនមេ 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 container ក្នុងករណីនេះ 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 មាន កម្មវិធីជំនួយកន្ទុយឯកសារ.

តោះបន្ថែមការញែកកំណត់ហេតុដែលបានកំណត់រចនាសម្ព័ន្ធខាងលើទៅការកំណត់រចនាសម្ព័ន្ធស្ទាត់ជំនាញ៖

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

Athena

ប្រសិនបើអ្នកបានកំណត់រចនាសម្ព័ន្ធគ្រប់យ៉ាងបានត្រឹមត្រូវ បន្ទាប់មកមួយសន្ទុះ (តាមលំនាំដើម កំណត់ត្រា 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 ឱ្យសមនឹងតម្រូវការរបស់អ្នក។ យើងប្រើ 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 backend នៅក្នុង Heroku ឬ Docker។ ឯកសារពិពណ៌នាអំពីអ្នកដទៃ វិធីសាស្រ្តបង្ហោះ.

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

អថេរបរិស្ថានត្រូវបានប្រើដើម្បីកំណត់រចនាសម្ព័ន្ធការចូលប្រើមូលដ្ឋានទិន្នន័យនៅក្នុង cube.js ។ ម៉ាស៊ីនភ្លើងនឹងបង្កើតឯកសារ .env ដែលអ្នកអាចបញ្ជាក់សោរបស់អ្នកសម្រាប់ Athena.

ឥឡូវនេះយើងត្រូវការ គ្រោងការណ៍ទិន្នន័យដែលក្នុងនោះយើងនឹងបង្ហាញយ៉ាងច្បាស់ពីរបៀបដែលកំណត់ហេតុរបស់យើងត្រូវបានរក្សាទុក។ នៅទីនោះ អ្នកក៏អាចបញ្ជាក់ពីរបៀបគណនាម៉ែត្រសម្រាប់ផ្ទាំងគ្រប់គ្រងផងដែរ។

នៅក្នុងថត 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>
        );
      }}
    />
  )
}

ប្រភព Dashboard មាននៅ ប្រអប់ខ្សាច់កូដ.

ប្រភព: www.habr.com