🥇Nginx لاگ اينالائيٽڪس استعمال ڪندي Amazon Athena ۽ Cube.js

عام طور تي، تجارتي پراڊڪٽس يا تيار ٿيل اوپن سورس متبادل، جهڙوڪ Prometheus + Grafana، Nginx جي آپريشن جي نگراني ۽ تجزيو ڪرڻ لاء استعمال ٿيندا آهن. هي هڪ سٺو اختيار آهي مانيٽرنگ يا حقيقي وقت جي تجزيي لاءِ، پر تاريخي تجزيي لاءِ تمام آسان ناهي. ڪنهن به مشهور وسيلن تي، نينڪس لاگز مان ڊيٽا جو مقدار تيزيء سان وڌي رهيو آهي، ۽ ڊيٽا جي وڏي مقدار جو تجزيو ڪرڻ لاء، اهو منطقي آهي ته ڪجهه وڌيڪ خاص استعمال ڪرڻ لاء.

هن آرٽيڪل ۾ آئون توهان کي ٻڌايان ٿو ته توهان ڪيئن استعمال ڪري سگهو ٿا ايٿينا لاگز جو تجزيو ڪرڻ لاءِ، Nginx کي مثال طور وٺي، ۽ مان ڏيکاريندس ته ڪيئن ان ڊيٽا مان تجزياتي ڊيش بورڊ کي گڏ ڪجي اوپن سورس cube.js فريم ورڪ استعمال ڪندي. هتي مڪمل حل فن تعمير آهي:

TL:DR؛
مڪمل ٿيل ڊيش بورڊ سان ڳنڍيو.

معلومات گڏ ڪرڻ لاءِ اسان استعمال ڪندا آهيون روانيپروسيسنگ لاء - AWS Kinesis ڊيٽا فائر هز и AWS گلواسٽوريج لاء، AWS S3. هن بنڊل کي استعمال ڪندي، توهان نه صرف nginx لاگز، پر ٻين واقعن، ۽ ٻين خدمتن جا لاگ پڻ محفوظ ڪري سگهو ٿا. توھان ڪجھ حصن کي پنھنجي اسٽيڪ لاءِ ساڳين حصن سان مٽائي سگھو ٿا، مثال طور، توھان سڌو سنئون nginx کان kinesis ڏانھن لاگ لکي سگھو ٿا، fluentd کي پاس ڪري، يا ھن لاءِ logstash استعمال ڪريو.

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. هي توهان کي هڪ جڳهه تي لاگز کي ذخيرو ۽ تجزيو ڪرڻ جي اجازت ڏئي ٿو، ڇاڪاڻ ته ايٿينا سڌو سنئون S3 ۾ ڊيٽا سان ڪم ڪري سگهي ٿي. بعد ۾ آرٽيڪل ۾ آئون توهان کي ٻڌايان ٿو ته ڪيئن صحيح طريقي سان لاگ ان کي شامل ڪرڻ ۽ پروسيس ڪرڻ، پر پهريان اسان کي S3 ۾ هڪ صاف بالٽ جي ضرورت آهي، جنهن ۾ ٻيو ڪجهه به ذخيرو نه ڪيو ويندو. اهو اڳ ۾ ئي غور ڪرڻ جي قابل آهي ته توهان ڪهڙي علائقي ۾ پنهنجو بالٽ ٺاهيندا، ڇاڪاڻ ته ايٿينا سڀني علائقن ۾ موجود ناهي.

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 تي fluentd کان لکي سگھو ٿا، پر ھن صورت ۾ توھان کي JSON لکڻو پوندو، ۽ اھو فائلن جي وڏي سائيز جي ڪري غير موثر آھي. اضافي طور تي، جڏهن استعمال ڪندي PrestoDB يا Athena، JSON آهي سستي ڊيٽا فارميٽ. تنهن ڪري کوليو Kinesis Firehose ڪنسول، ڪلڪ ڪريو "ترسيل وارو وهڪرو ٺاهيو"، "ترسيل" فيلڊ ۾ "سڌو پوٽو" چونڊيو:

ايندڙ ٽئب ۾، چونڊيو "ريڪارڊ فارميٽ ڪنورشن" - "فعال" ۽ چونڊيو "Apache ORC" کي رڪارڊنگ فارميٽ طور. ڪجهه تحقيق موجب اوون اوملي, هي آهي بهترين فارميٽ PrestoDB ۽ Athena لاءِ. اسان مٿي ڏنل جدول کي اسڪيما طور استعمال ڪريون ٿا. مهرباني ڪري نوٽ ڪريو ته توهان ڪينيسس ۾ ڪنهن به S3 هنڌ بيان ڪري سگهو ٿا؛ صرف اسڪيما ٽيبل مان استعمال ڪيو ويندو آهي. پر جيڪڏهن توهان هڪ مختلف S3 هنڌ بيان ڪريو ٿا، ته پوءِ توهان هن ٽيبل تان اهي رڪارڊ پڙهي نه سگهندا.

اسان چونڊيو S3 اسٽوريج لاءِ ۽ بالٽ جيڪو اسان اڳ ۾ ٺاهيو آهي. Aws Glue Crawler، جنهن بابت مان ٿوري دير بعد ڳالهائيندس، S3 بالٽ ۾ اڳياڙين سان ڪم نٿو ڪري سگهي، تنهنڪري اهو ضروري آهي ته ان کي خالي ڇڏي ڏيو.

باقي اختيارن کي تبديل ڪري سگھجي ٿو توھان جي لوڊ جي لحاظ سان؛ مان عام طور تي ڊفالٽ استعمال ڪندو آھيان. نوٽ ڪريو ته S3 ڪمپريشن دستياب ناهي، پر ORC ڊفالٽ طور مقامي کمپريشن استعمال ڪري ٿو.

رواني

هاڻي ته اسان لاگز کي محفوظ ڪرڻ ۽ وصول ڪرڻ کي ترتيب ڏنو آهي، اسان کي موڪلڻ کي ترتيب ڏيڻ جي ضرورت آهي. اسان استعمال ڪنداسين رواني, ڇاڪاڻ ته مون کي روبي سان پيار آهي، پر توهان Logstash استعمال ڪري سگهو ٿا يا سڌو سنئون kinesis ڏانهن لاگ موڪلي سگهو ٿا. Fluentd سرور ڪيترن ئي طريقن سان لانچ ڪري سگھجي ٿو، مان توھان کي ٻڌايان ٿو ڊڪر بابت ڇو ته اھو سادو ۽ آسان آھي.

پهرين، اسان کي ضرورت آهي 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 ھلندو آھي، اسان اتي موڪلي سگھون ٿا نينڪس لاگز. اسان عام طور تي ڊاڪر ڪنٽينر ۾ نينڪس کي هلائيندا آهيون، انهي صورت ۾ ڊڪر کي فلينٽ لاء هڪ اصلي لاگنگ ڊرائيور آهي:

$ 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 آهي فائل tail پلگ ان.

اچو ته مٿي ڏنل ترتيب ڏنل لاگ پارسنگ کي Fluent configuration ۾ شامل ڪريون:

<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 ۾ رڪارڊ ٿيل آهي، انهي سان گڏ غلطيون. Kinesis ڪردار تائين S3 بالٽ تائين لکڻ جي رسائي ڏيڻ نه وساريو. جيڪڏهن Kinesis ڪجهه پارس نه ڪري سگهيو، اهو ساڳيو بالٽ ۾ غلطيون شامل ڪندو.

هاڻي توهان Athena ۾ ڊيٽا ڏسي سگهو ٿا. اچو ته تازيون درخواستون ڳوليون جن لاءِ اسان غلطيون واپس ڪيون:

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

هر درخواست لاء سڀ رڪارڊ اسڪيننگ

ھاڻي اسان جا لاگ پروسيس ڪيا ويا آھن ۽ ORC ۾ S3 ۾ ذخيرو ٿيل آھن، ٺھيل ۽ تجزيو لاءِ تيار آھن. Kinesis Firehose جيتوڻيڪ انهن کي هر ڪلاڪ لاء ڊائريڪٽرن ۾ منظم ڪيو. بهرحال، جيستائين ٽيبل کي ورهاڱو نه ڪيو ويو آهي، ايٿينا هر درخواست تي هر وقت ڊيٽا لوڊ ڪندي، نادر استثنا سان. اهو ٻه سببن لاء هڪ وڏو مسئلو آهي:

ڊيٽا جو مقدار مسلسل وڌي رهيو آهي، سوالن کي سست ڪري رهيو آهي؛
ايٿينا کي اسڪين ڪيل ڊيٽا جي مقدار جي بنياد تي بل ڪيو ويندو آهي، گهٽ ۾ گهٽ 10 MB في درخواست سان.

هن کي درست ڪرڻ لاءِ، اسان استعمال ڪريون ٿا AWS Glue Crawler، جيڪو S3 ۾ ڊيٽا کي ڪرال ڪندو ۽ Glue Metastore ڏانهن ورهاڱي جي معلومات لکندو. اهو اسان کي اجازت ڏيندو ته فلٽر جي طور تي ورهاڱي کي استعمال ڪرڻ لاء جڏهن ايٿينا سوال ڪيو وڃي، ۽ اهو صرف سوال ۾ بيان ڪيل ڊائريڪٽرن کي اسڪين ڪندو.

Amazon Glue Crawler ترتيب ڏيڻ

Amazon Glue Crawler S3 بالٽ ۾ سڀني ڊيٽا کي اسڪين ڪري ٿو ۽ جدولن سان گڏ ٺاهي ٿو. AWS Glue ڪنسول مان هڪ گلو ڪريلر ٺاهيو ۽ هڪ بالٽ شامل ڪريو جتي توهان ڊيٽا کي ذخيرو ڪريو. توھان استعمال ڪري سگھو ٿا ھڪڙو ڪريلر ڪيترن ئي بالٽ لاءِ، ان صورت ۾ اھو مخصوص ڊيٽابيس ۾ ٽيبل ٺاھيندو نالن سان جيڪي بالٽ جي نالن سان ملن ٿا. جيڪڏهن توهان هن ڊيٽا کي باقاعده استعمال ڪرڻ جو منصوبو ٺاهيو ٿا، پڪ ڪريو ته ڪريلر جي لانچ شيڊول کي ترتيب ڏيو توهان جي ضرورتن مطابق. اسان سڀني ٽيبلن لاءِ هڪ ڪريلر استعمال ڪندا آهيون، جيڪو هر ڪلاڪ هلندو آهي.

ورهاڱي واري ٽيبل

ڪريلر جي پهرين لانچ کان پوء، هر اسڪين ٿيل بالٽ لاء ٽيبل سيٽنگون ۾ بيان ڪيل ڊيٽابيس ۾ ظاهر ٿيڻ گهرجي. ايٿينا ڪنسول کوليو ۽ ٽيبل ڳوليو نينڪس لاگز سان. اچو ته ڪجهه پڙهڻ جي ڪوشش ڪريون:

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 تجزياتي فريم ورڪ. ان ۾ ڪافي ڪم آھن، پر اسان ٻنھي ۾ دلچسپي رکون ٿا: پاڻمرادو ورھاڱي جا فلٽر استعمال ڪرڻ جي صلاحيت ۽ ڊيٽا اڳي گڏ ڪرڻ. اهو ڊيٽا اسڪيما استعمال ڪري ٿو ڊيٽا اسڪيما، جاوا اسڪرپٽ ۾ لکيو ويو آهي SQL پيدا ڪرڻ ۽ ڊيٽابيس جي سوال تي عمل ڪرڻ لاءِ. اسان کي صرف اهو ظاهر ڪرڻو پوندو ته ڪيئن استعمال ڪجي ورهاڱي واري فلٽر کي ڊيٽا اسڪيما ۾.

اچو ته هڪ نئين Cube.js ايپليڪيشن ٺاهي. جيئن ته اسان اڳ ۾ ئي AWS اسٽيڪ استعمال ڪري رهيا آهيون، اهو منطقي آهي استعمال ڪرڻ لاء Lambda استعمال ڪرڻ لاء. توهان استعمال ڪري سگهو ٿا ايڪسپريس ٽيمپليٽ نسل لاءِ جيڪڏهن توهان هيروڪو يا ڊڪر ۾ Cube.js پس منظر کي ميزباني ڪرڻ جو ارادو ڪيو. دستاويز ٻين کي بيان ڪري ٿو ميزباني جا طريقا.

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

هتي اسان variable استعمال ڪري رهيا آهيون FILTER_PARAMSورهاڱي واري فلٽر سان SQL سوال پيدا ڪرڻ لاء.

اسان ميٽرڪس ۽ پيرا ميٽرس پڻ سيٽ ڪريون ٿا جيڪي اسان ڊيش بورڊ تي ڊسپلي ڪرڻ چاهيون ٿا ۽ اڳي گڏ ڪرڻ جي وضاحت ڪريو. Cube.js اڳ ۾ گڏ ڪيل ڊيٽا سان اضافي جدول ٺاهيندو ۽ خودڪار طور تي ڊيٽا کي اپڊيٽ ڪندو جيئن اهو ايندو. اهو نه صرف سوالن کي تيز ڪري ٿو، پر ايٿينا استعمال ڪرڻ جي قيمت پڻ گھٽائي ٿو.

اچو ته هن معلومات کي ڊيٽا اسڪيما فائل ۾ شامل ڪريون:

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 فارميٽ، جيڪو گهربل ميٽرڪس بيان ڪري ٿو. مثال طور، ڳڻڻ لاءِ ته نينگڪس ڏينهن ۾ ڪيتريون غلطيون ڏنيون، توهان کي هيٺين درخواست موڪلڻ جي ضرورت آهي:

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

Amazon Athena ۽ Cube.js استعمال ڪندي نينڪس لاگ اينالائيٽڪس