Nginx Log Analytics ກັບ Amazon Athena ແລະ Cube.js

ໂດຍປົກກະຕິ, ຜະລິດຕະພັນການຄ້າຫຼືທາງເລືອກທີ່ພ້ອມທີ່ຈະເຮັດແລ້ວ, ເຊັ່ນ: Prometheus + Grafana, ຖືກນໍາໃຊ້ເພື່ອຕິດຕາມແລະວິເຄາະການດໍາເນີນງານຂອງ Nginx. ນີ້ແມ່ນທາງເລືອກທີ່ດີສໍາລັບການຕິດຕາມຫຼືການວິເຄາະໃນເວລາທີ່ແທ້ຈິງ, ແຕ່ບໍ່ສະດວກຫຼາຍສໍາລັບການວິເຄາະປະຫວັດສາດ. ໃນຊັບພະຍາກອນທີ່ນິຍົມໃດກໍ່ຕາມ, ປະລິມານຂໍ້ມູນຈາກບັນທຶກ nginx ແມ່ນການຂະຫຍາຍຕົວຢ່າງໄວວາ, ແລະການວິເຄາະຂໍ້ມູນຈໍານວນຫລາຍ, ມັນມີເຫດຜົນທີ່ຈະໃຊ້ສິ່ງທີ່ພິເສດກວ່າ.

ໃນບົດຄວາມນີ້ຂ້າພະເຈົ້າຈະບອກທ່ານວິທີທີ່ທ່ານສາມາດນໍາໃຊ້ Athena ເພື່ອວິເຄາະບັນທຶກ, ເອົາ Nginx ເປັນຕົວຢ່າງ, ແລະຂ້ອຍຈະສະແດງວິທີການລວບລວມ dashboard ການວິເຄາະຈາກຂໍ້ມູນນີ້ໂດຍໃຊ້ກອບ cube.js open-source. ນີ້ແມ່ນສະຖາປັດຕະຍະກໍາການແກ້ໄຂທີ່ສົມບູນ:

TL:DR;
ເຊື່ອມຕໍ່ກັບ dashboard ສໍາເລັດຮູບ.

ເພື່ອເກັບກໍາຂໍ້ມູນທີ່ພວກເຮົາໃຊ້ ຄ່ອງແຄ້ວ, ສໍາ​ລັບ​ການ​ປຸງ​ແຕ່ງ - AWS Kinesis Data Firehose и ກາວ AWS, ສໍາ​ລັບ​ການ​ເກັບ​ຮັກ​ສາ - AWS S3. ການນໍາໃຊ້ມັດນີ້, ທ່ານສາມາດເກັບຮັກສາບໍ່ພຽງແຕ່ບັນທຶກ nginx, ແຕ່ຍັງເຫດການອື່ນໆ, ເຊັ່ນດຽວກັນກັບບັນທຶກຂອງການບໍລິການອື່ນໆ. ທ່ານສາມາດທົດແທນບາງສ່ວນທີ່ມີສ່ວນທີ່ຄ້າຍຄືກັນສໍາລັບ stack ຂອງທ່ານ, ຕົວຢ່າງ, ທ່ານສາມາດຂຽນບັນທຶກເພື່ອ kinesis ໂດຍກົງຈາກ nginx, bypassing 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 console

ໃຫ້ສ້າງຕາຕະລາງໃນ Athena ສໍາລັບບັນທຶກ. ມັນເປັນສິ່ງຈໍາເປັນສໍາລັບທັງການຂຽນແລະການອ່ານຖ້າທ່ານວາງແຜນທີ່ຈະໃຊ້ Kinesis Firehose. ເປີດ Athena console ແລະສ້າງຕາຕະລາງ:

ການສ້າງຕາຕະລາງ 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 Stream

Kinesis Firehose ຈະຂຽນຂໍ້ມູນທີ່ໄດ້ຮັບຈາກ Nginx ຫາ S3 ໃນຮູບແບບທີ່ເລືອກ, ແບ່ງອອກເປັນໄດເລກະທໍລີໃນຮູບແບບ YYYY/MM/DD/HH. ນີ້ຈະເປັນປະໂຫຍດໃນເວລາອ່ານຂໍ້ມູນ. ທ່ານສາມາດ, ແນ່ນອນ, ຂຽນໂດຍກົງກັບ S3 ຈາກ fluentd, ແຕ່ໃນກໍລະນີນີ້ທ່ານຈະຕ້ອງຂຽນ JSON, ແລະນີ້ບໍ່ມີປະສິດທິພາບເນື່ອງຈາກຂະຫນາດໃຫຍ່ຂອງໄຟລ໌. ນອກຈາກນັ້ນ, ເມື່ອໃຊ້ PrestoDB ຫຼື Athena, JSON ແມ່ນຮູບແບບຂໍ້ມູນຊ້າທີ່ສຸດ. ສະນັ້ນເປີດ Kinesis Firehose console, ຄລິກ "ສ້າງການຈັດສົ່ງກະແສ", ເລືອກ "ເອົາໂດຍກົງ" ໃນຊ່ອງ "ການຈັດສົ່ງ":

ໃນແຖບຕໍ່ໄປ, ເລືອກ "ການແປງຮູບແບບການບັນທຶກ" - "ເປີດໃຊ້ງານ" ແລະເລືອກ "Apache ORC" ເປັນຮູບແບບການບັນທຶກ. ອີງຕາມການຄົ້ນຄວ້າບາງຢ່າງ Owen O'Malley, ນີ້ແມ່ນຮູບແບບທີ່ດີທີ່ສຸດສໍາລັບ PrestoDB ແລະ Athena. ພວກເຮົາໃຊ້ຕາຕະລາງທີ່ພວກເຮົາສ້າງຂ້າງເທິງເປັນ schema. ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ​ທ່ານ​ສາ​ມາດ​ກໍາ​ນົດ​ສະ​ຖານ​ທີ່ S3 ໃດ​ຫນຶ່ງ​ໃນ kinesis​; ພຽງ​ແຕ່ schema ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ຈາກ​ຕາ​ຕະ​ລາງ​. ແຕ່ຖ້າທ່ານລະບຸສະຖານທີ່ S3 ທີ່ແຕກຕ່າງກັນ, ຫຼັງຈາກນັ້ນທ່ານຈະບໍ່ສາມາດອ່ານບັນທຶກເຫຼົ່ານີ້ຈາກຕາຕະລາງນີ້.

ພວກເຮົາເລືອກ S3 ສໍາລັບການເກັບຮັກສາແລະຖັງທີ່ພວກເຮົາສ້າງກ່ອນຫນ້ານີ້. Aws Glue Crawler, ທີ່ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບເລັກນ້ອຍຕໍ່ມາ, ບໍ່ສາມາດເຮັດວຽກກັບຄໍານໍາຫນ້າໃນຖັງ S3, ສະນັ້ນມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປ່ອຍໃຫ້ມັນຫວ່າງເປົ່າ.

ທາງ​ເລືອກ​ທີ່​ຍັງ​ເຫຼືອ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ປ່ຽນ​ແປງ​ໂດຍ​ອີງ​ໃສ່​ການ​ໂຫຼດ​ຂອງ​ທ່ານ​; ໂດຍ​ປົກ​ກະ​ຕິ​ຂ້າ​ພະ​ເຈົ້າ​ໃຊ້​ໃນ​ຕອນ​ຕົ້ນ​. ໃຫ້ສັງເກດວ່າການບີບອັດ S3 ບໍ່ສາມາດໃຊ້ໄດ້, ແຕ່ ORC ໃຊ້ການບີບອັດແບບເດີມໂດຍຄ່າເລີ່ມຕົ້ນ.

ຄ່ອງແຄ້ວ

ໃນປັດຈຸບັນທີ່ພວກເຮົາໄດ້ຕັ້ງຄ່າບັນທຶກການເກັບຮັກສາແລະການຮັບ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກໍານົດການສົ່ງ. ພວກເຮົາຈະນໍາໃຊ້ ຄ່ອງແຄ້ວ, ເພາະວ່າຂ້ອຍຮັກ Ruby, ແຕ່ທ່ານສາມາດນໍາໃຊ້ Logstash ຫຼືສົ່ງບັນທຶກໄປຫາ kinesis ໂດຍກົງ. ເຊີບເວີ Fluentd ສາມາດຖືກເປີດຕົວໃນຫຼາຍວິທີ, ຂ້ອຍຈະບອກທ່ານກ່ຽວກັບ docker ເພາະວ່າມັນງ່າຍດາຍແລະສະດວກ.

ກ່ອນອື່ນ, ພວກເຮົາຕ້ອງການໄຟລ໌ການຕັ້ງຄ່າ fluent.conf. ສ້າງມັນແລະເພີ່ມແຫຼ່ງ:

ປະເພດ ໄປຂ້າງຫນ້າ
port 24224
ຜູກມັດ 0.0.0.0

ໃນປັດຈຸບັນທ່ານສາມາດເລີ່ມຕົ້ນເຄື່ອງແມ່ຂ່າຍ Fluentd. ຖ້າທ່ານຕ້ອງການການຕັ້ງຄ່າຂັ້ນສູງ, ໃຫ້ໄປທີ່ ສູນກາງ docker ມີຄູ່ມືລາຍລະອຽດ, ລວມທັງວິທີການປະກອບຮູບພາບຂອງທ່ານ.

$ 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 ເພື່ອ cache ບັນທຶກກ່ອນທີ່ຈະສົ່ງ. ທ່ານສາມາດເຮັດໄດ້ໂດຍບໍ່ມີການນີ້, ແຕ່ຫຼັງຈາກນັ້ນເມື່ອທ່ານ restart, ທ່ານສາມາດສູນເສຍທຸກສິ່ງທຸກຢ່າງທີ່ເກັບໄວ້ໃນຖານຄວາມຈໍາດ້ວຍແຮງງານ back-breaking. ທ່ານຍັງສາມາດໃຊ້ພອດໃດກໍໄດ້; 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 ມີ plugin ຫາງໄຟລ໌.

ມາເພີ່ມການແຍກວິເຄາະບັນທຶກທີ່ກຳນົດໄວ້ຂ້າງເທິງໃສ່ການຕັ້ງຄ່າທີ່ຄ່ອງແຄ້ວ:

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

ແລະການສົ່ງບັນທຶກໄປຫາ Kinesis ໂດຍໃຊ້ plugin 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 ຈາກ console AWS Glue ແລະເພີ່ມ bucket ບ່ອນທີ່ທ່ານເກັບຂໍ້ມູນ. ທ່ານສາມາດນໍາໃຊ້ຕົວກວາດເວັບຫນຶ່ງສໍາລັບຫຼາຍໆ buckets, ໃນກໍລະນີນີ້ມັນຈະສ້າງຕາຕະລາງໃນຖານຂໍ້ມູນທີ່ລະບຸໄວ້ດ້ວຍຊື່ທີ່ກົງກັບຊື່ຂອງ buckets. ຖ້າທ່ານວາງແຜນທີ່ຈະໃຊ້ຂໍ້ມູນນີ້ເປັນປົກກະຕິ, ໃຫ້ແນ່ໃຈວ່າກໍານົດເວລາການເປີດຕົວຂອງ Crawler ໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງທ່ານ. ພວກເຮົາໃຊ້ຕົວກວາດເວັບອັນດຽວສໍາລັບຕາຕະລາງທັງຫມົດ, ເຊິ່ງດໍາເນີນການທຸກໆຊົ່ວໂມງ.

ຕາຕະລາງແບ່ງສ່ວນ

ຫຼັງຈາກການເປີດຕົວຄັ້ງທໍາອິດຂອງຕົວກວາດເວັບ, ຕາຕະລາງສໍາລັບແຕ່ລະຖັງທີ່ສະແກນຄວນຈະປາກົດຢູ່ໃນຖານຂໍ້ມູນທີ່ລະບຸໄວ້ໃນການຕັ້ງຄ່າ. ເປີດ Athena console ແລະຊອກຫາຕາຕະລາງທີ່ມີບັນທຶກ 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 megabytes ຂອງຂໍ້ມູນໃນຊຸດຂໍ້ມູນທີ່ມີບັນທຶກພຽງແຕ່ຫນຶ່ງອາທິດ. ມາລອງໃຊ້ການກັ່ນຕອງຕາມການແບ່ງສ່ວນ:

ໄວຂຶ້ນເລັກນ້ອຍ, ແຕ່ສໍາຄັນທີ່ສຸດ - ພຽງແຕ່ 1.23 megabytes ຂອງຂໍ້ມູນ! ມັນຈະມີລາຄາຖືກກວ່າຫຼາຍຖ້າບໍ່ແມ່ນສໍາລັບຕໍາ່ສຸດທີ່ 10 megabytes ຕໍ່ຄໍາຮ້ອງຂໍຢູ່ໃນລາຄາ. ແຕ່ມັນຍັງດີກວ່າຫຼາຍ, ແລະໃນຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່, ຄວາມແຕກຕ່າງຈະປະທັບໃຈຫຼາຍ.

ການສ້າງ dashboard ໂດຍໃຊ້ Cube.js

ເພື່ອປະກອບ dashboard, ພວກເຮົາໃຊ້ກອບການວິເຄາະ Cube.js. ມັນມີຫນ້າທີ່ຂ້ອນຂ້າງຫຼາຍ, ແຕ່ພວກເຮົາສົນໃຈສອງຢ່າງ: ຄວາມສາມາດໃນການນໍາໃຊ້ຕົວກອງການແບ່ງປັນອັດຕະໂນມັດແລະການລວບລວມຂໍ້ມູນລ່ວງຫນ້າ. ມັນໃຊ້ schema ຂໍ້ມູນ ໂຄງ​ການ​ຂໍ້​ມູນ​, ຂຽນໃນ Javascript ເພື່ອສ້າງ SQL ແລະດໍາເນີນການສອບຖາມຖານຂໍ້ມູນ. ພວກ​ເຮົາ​ພຽງ​ແຕ່​ຕ້ອງ​ການ​ທີ່​ຈະ​ຊີ້​ບອກ​ວິ​ທີ​ການ​ນໍາ​ໃຊ້​ຕົວ​ກອງ​ການ​ແບ່ງ​ປັນ​ໃນ​ໂຄງ​ການ​ຂໍ້​ມູນ​.

ມາສ້າງແອັບພລິເຄຊັນ Cube.js ໃໝ່. ເນື່ອງຈາກພວກເຮົາໃຊ້ AWS stack ຢູ່ແລ້ວ, ມັນສົມເຫດສົມຜົນທີ່ຈະໃຊ້ Lambda ສໍາລັບການຕິດຕັ້ງ. ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ແມ່​ແບບ​ສະ​ແດງ​ອອກ​ສໍາ​ລັບ​ການ​ຜະ​ລິດ​ໄດ້​ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ວາງ​ແຜນ​ທີ່​ຈະ​ເປັນ​ເຈົ້າ​ພາບ backend Cube.js ໃນ Heroku ຫຼື Docker​. ເອກະສານອະທິບາຍຄົນອື່ນ ວິທີການໂຮດຕິ້ງ.

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

ຕົວແປສະພາບແວດລ້ອມແມ່ນໃຊ້ເພື່ອຕັ້ງຄ່າການເຂົ້າເຖິງຖານຂໍ້ມູນໃນ cube.js. ເຄື່ອງກໍາເນີດຈະສ້າງໄຟລ໌ .env ທີ່ທ່ານສາມາດລະບຸລະຫັດຂອງທ່ານສໍາລັບ Athena.

ໃນປັດຈຸບັນພວກເຮົາຕ້ອງການ ໂຄງ​ການ​ຂໍ້​ມູນ​, ໃນທີ່ພວກເຮົາຈະຊີ້ບອກວິທີການບັນທຶກຂອງພວກເຮົາຖືກເກັບໄວ້. ຢູ່ທີ່ນັ້ນທ່ານຍັງສາມາດກໍານົດວິທີການຄິດໄລ່ metrics ສໍາລັບ dashboards.

ໃນ​ລະ​ບົບ​ 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 ທີ່ມີຕົວກອງພາທິຊັນ.

ພວກເຮົາຍັງກໍານົດ metrics ແລະຕົວກໍານົດການທີ່ພວກເຮົາຕ້ອງການທີ່ຈະສະແດງຢູ່ໃນ dashboard ແລະກໍານົດການລວບລວມລ່ວງຫນ້າ. Cube.js ຈະສ້າງຕາຕະລາງເພີ່ມເຕີມທີ່ມີຂໍ້ມູນລວມລ່ວງຫນ້າແລະຈະປັບປຸງຂໍ້ມູນອັດຕະໂນມັດເມື່ອມັນມາຮອດ. ນີ້ບໍ່ພຽງແຕ່ເລັ່ງການສອບຖາມ, ແຕ່ຍັງຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍຂອງການນໍາໃຊ້ Athena.

ໃຫ້ເພີ່ມຂໍ້ມູນນີ້ໃສ່ໄຟລ໌ schema ຂໍ້ມູນ:

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

ພວກເຮົາລະບຸໃນຮູບແບບນີ້ວ່າມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະລວບລວມຂໍ້ມູນລ່ວງຫນ້າສໍາລັບທຸກ metrics ທີ່ໃຊ້, ແລະໃຊ້ການແບ່ງປັນໂດຍເດືອນ. ການແບ່ງສ່ວນທາງສ່ວນຫນ້າຂອງການລວບລວມ ສາມາດເລັ່ງການເກັບກຳຂໍ້ມູນ ແລະອັບເດດໄດ້ຢ່າງມີໄນສໍາຄັນ.

ໃນປັດຈຸບັນພວກເຮົາສາມາດປະກອບ dashboard ໄດ້!

Cube.js backend ໃຫ້ REST API ແລະຊຸດຂອງຫ້ອງສະຫມຸດລູກຄ້າສໍາລັບກອບຫນ້າທີ່ນິຍົມ. ພວກເຮົາຈະໃຊ້ React ເວີຊັນຂອງລູກຄ້າເພື່ອສ້າງ dashboard. Cube.js ໃຫ້ຂໍ້ມູນເທົ່ານັ້ນ, ດັ່ງນັ້ນພວກເຮົາຈະຕ້ອງການຫ້ອງສະໝຸດພາບ - ຂ້ອຍມັກມັນ ຕາຕະລາງໃຫມ່, ແຕ່ທ່ານສາມາດນໍາໃຊ້ອັນໃດກໍ່ໄດ້.

ເຊີບເວີ Cube.js ຍອມຮັບການຮ້ອງຂໍໃນ ຮູບແບບ JSON, ເຊິ່ງກໍານົດ metrics ທີ່ຕ້ອງການ. ຕົວຢ່າງ, ເພື່ອຄິດໄລ່ຈໍານວນຂໍ້ຜິດພາດທີ່ 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ເພື່ອດາວໂຫລດຂໍ້ມູນ, ແລະເກັບກໍາ dashboard:

ລະຫັດ dashboard

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 ມີຢູ່ sandbox ລະຫັດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com