🥇Nginx लग एनालिटिक्स Amazon Athena र Cube.js प्रयोग गर्दै

सामान्यतया, व्यावसायिक उत्पादनहरू वा तयार-निर्मित खुला स्रोत विकल्पहरू, जस्तै Prometheus + Grafana, Nginx को सञ्चालन निगरानी र विश्लेषण गर्न प्रयोग गरिन्छ। यो अनुगमन वा वास्तविक समय विश्लेषण को लागी एक राम्रो विकल्प हो, तर ऐतिहासिक विश्लेषण को लागी धेरै सुविधाजनक छैन। कुनै पनि लोकप्रिय स्रोतमा, nginx लगहरूबाट डाटाको मात्रा द्रुत रूपमा बढ्दै गएको छ, र ठूलो मात्रामा डाटा विश्लेषण गर्न, यो अधिक विशेष प्रयोग गर्न तार्किक छ।

यस लेखमा म तपाईंलाई बताउनेछु कि तपाईं कसरी प्रयोग गर्न सक्नुहुन्छ एथेना लगहरू विश्लेषण गर्न, Nginx लाई उदाहरणको रूपमा लिएर, र म खुला स्रोत cube.js फ्रेमवर्क प्रयोग गरेर यस डेटाबाट विश्लेषणात्मक ड्यासबोर्ड कसरी जम्मा गर्ने भनेर देखाउनेछु। यहाँ पूर्ण समाधान वास्तुकला छ:

TL:DR;
समाप्त ड्यासबोर्डमा लिङ्क गर्नुहोस्.

हामीले प्रयोग गर्ने जानकारी सङ्कलन गर्न प्रवाहित, प्रशोधन को लागी - AWS Kinesis डाटा फायरहोस и AWS गोंदभण्डारणको लागि - AWS S3। यो बन्डल प्रयोग गरेर, तपाईं nginx लगहरू मात्र भण्डारण गर्न सक्नुहुन्छ, तर अन्य घटनाहरू, साथै अन्य सेवाहरूको लगहरू पनि। तपाइँ तपाइँको स्ट्याक को लागी समान भागहरु संग केहि भागहरु लाई प्रतिस्थापन गर्न सक्नुहुन्छ, उदाहरण को लागी, तपाइँ सिधै nginx बाट kinesis मा लग लेख्न सक्नुहुन्छ, 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 प्रयोग गर्नेछौं। यसले तपाईंलाई लगहरू एकै ठाउँमा भण्डारण र विश्लेषण गर्न अनुमति दिन्छ, किनकि एथेनाले S3 मा डाटासँग प्रत्यक्ष रूपमा काम गर्न सक्छ। लेखमा पछि म तपाईंलाई बताउनेछु कि कसरी लगहरू थप्न र प्रशोधन गर्ने, तर पहिले हामीलाई S3 मा सफा बाल्टी चाहिन्छ, जसमा अरू केहि पनि भण्डारण गरिने छैन। तपाइँ कुन क्षेत्रमा तपाइँको बाल्टी सिर्जना गर्नुहुनेछ पहिले नै विचार गर्न लायक छ, किनकि एथेना सबै क्षेत्रहरूमा उपलब्ध छैन।

एथेना कन्सोलमा सर्किट सिर्जना गर्दै

लगहरूको लागि एथेनामा एउटा तालिका बनाउनुहोस्। यदि तपाइँ Kinesis Firehose प्रयोग गर्ने योजना बनाउनुहुन्छ भने यो लेखन र पढ्न दुवैको लागि आवश्यक छ। एथेना कन्सोल खोल्नुहोस् र तालिका सिर्जना गर्नुहोस्:

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 ढाँचामा डाइरेक्टरीहरूमा विभाजन गरी चयन गरिएको ढाँचामा लेख्नेछ। डाटा पढ्दा यो काममा आउनेछ। तपाईले निस्सन्देह, fluentd बाट S3 मा सिधै लेख्न सक्नुहुन्छ, तर यस अवस्थामा तपाईले JSON लेख्नुपर्नेछ, र फाइलहरूको ठूलो आकारको कारणले यो असक्षम छ। थप रूपमा, PrestoDB वा एथेना प्रयोग गर्दा, JSON सबैभन्दा ढिलो डेटा ढाँचा हो। त्यसैले Kinesis Firehose कन्सोल खोल्नुहोस्, "डिलिभरी स्ट्रिम सिर्जना गर्नुहोस्" मा क्लिक गर्नुहोस्, "डिलिभरी" फिल्डमा "प्रत्यक्ष PUT" चयन गर्नुहोस्:

अर्को ट्याबमा, "रेकर्ड ढाँचा रूपान्तरण" - "सक्षम" चयन गर्नुहोस् र रेकर्डिङ ढाँचाको रूपमा "Apache ORC" चयन गर्नुहोस्। केहि अनुसन्धान अनुसार ओवेन ओ'माली, यो PrestoDB र Athena को लागि इष्टतम ढाँचा हो। हामीले माथि बनाएको तालिकालाई स्किमाको रूपमा प्रयोग गर्छौं। कृपया ध्यान दिनुहोस् कि तपाईंले किनेसिसमा कुनै पनि S3 स्थान निर्दिष्ट गर्न सक्नुहुन्छ; तालिकाबाट मात्र स्कीमा प्रयोग गरिन्छ। तर यदि तपाइँ फरक S3 स्थान निर्दिष्ट गर्नुहुन्छ भने, तपाइँ यो तालिकाबाट यी रेकर्डहरू पढ्न सक्षम हुनुहुने छैन।

हामीले भण्डारणको लागि S3 चयन गर्छौं र हामीले पहिले सिर्जना गरेको बाल्टी। Aws ग्लु क्रलर, जसको बारेमा म केहि पछि कुरा गर्नेछु, 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 पोर्ट हो।

अब हामीसँग Fluentd चलिरहेको छ, हामी त्यहाँ Nginx लगहरू पठाउन सक्छौं। हामी सामान्यतया डकर कन्टेनरमा Nginx चलाउँछौं, जसमा 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>

एथेना

यदि तपाईंले सबै कुरा सही रूपमा कन्फिगर गर्नुभयो भने, त्यसपछि केही समय पछि (पूर्वनिर्धारित रूपमा, Kinesis रेकर्डहरूले प्रत्येक 10 मिनेटमा एक पटक डाटा प्राप्त गर्दछ) तपाईंले S3 मा लग फाइलहरू देख्नुपर्छ। Kinesis Firehose को "निगरानी" मेनुमा तपाईले S3 मा कति डाटा रेकर्ड गरिएको छ, साथै त्रुटिहरू देख्न सक्नुहुन्छ। Kinesis भूमिकामा S3 बाल्टीमा लेख्ने पहुँच दिन नबिर्सनुहोस्। यदि Kinesis ले केहि पार्स गर्न सकेन भने, यसले एउटै बाल्टीमा त्रुटिहरू थप्नेछ।

अब तपाईं एथेना मा डाटा हेर्न सक्नुहुन्छ। हामीले त्रुटिहरू फिर्ता गरेका नवीनतम अनुरोधहरू फेला पारौं:

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

प्रत्येक अनुरोधको लागि सबै रेकर्डहरू स्क्यान गर्दै

अब हाम्रा लगहरू प्रशोधन गरिएको छ र ORC मा S3 मा भण्डारण गरिएको छ, संकुचित र विश्लेषणको लागि तयार छ। किनेसिस फायरहोसले तिनीहरूलाई प्रत्येक घण्टाको लागि डाइरेक्टरीहरूमा व्यवस्थित गर्यो। यद्यपि, जबसम्म तालिका विभाजन गरिएको छैन, एथेनाले दुर्लभ अपवादहरू सहित, हरेक अनुरोधमा सबै-समय डाटा लोड गर्नेछ। यो दुई कारणका लागि ठूलो समस्या हो:

डाटाको मात्रा निरन्तर बढ्दै छ, प्रश्नहरू ढिलो गर्दै;
एथेनालाई प्रति अनुरोध न्यूनतम १० MB को साथ स्क्यान गरिएको डाटाको भोल्युमको आधारमा बिल गरिन्छ।

यसलाई ठीक गर्न, हामी AWS ग्लु क्रलर प्रयोग गर्छौं, जसले S3 मा डेटा क्रल गर्नेछ र ग्लु मेटास्टोरमा विभाजन जानकारी लेख्नेछ। यसले हामीलाई एथेना क्वेरी गर्दा फिल्टरको रूपमा विभाजनहरू प्रयोग गर्न अनुमति दिनेछ, र यसले क्वेरीमा निर्दिष्ट डाइरेक्टरीहरू मात्र स्क्यान गर्नेछ।

Amazon Glue Crawler सेटअप गर्दै

Amazon Glue Crawler ले S3 बाल्टीमा भएका सबै डाटा स्क्यान गर्छ र विभाजनहरू सहित तालिकाहरू सिर्जना गर्दछ। AWS ग्लु कन्सोलबाट ग्लु क्रलर सिर्जना गर्नुहोस् र तपाईंले डाटा भण्डारण गर्ने बाल्टी थप्नुहोस्। तपाईंले धेरै बाल्टिनहरूको लागि एउटा क्रलर प्रयोग गर्न सक्नुहुन्छ, जसमा यसले बाल्टीहरूको नामसँग मेल खाने नामहरूका साथ निर्दिष्ट डाटाबेसमा तालिकाहरू सिर्जना गर्नेछ। यदि तपाइँ यो डेटा नियमित रूपमा प्रयोग गर्ने योजना बनाउनुहुन्छ भने, तपाइँका आवश्यकताहरू अनुरूप क्रलरको सुरुवात तालिका कन्फिगर गर्न निश्चित हुनुहोस्। हामी सबै टेबलहरूको लागि एउटा क्रलर प्रयोग गर्छौं, जुन हरेक घण्टा चल्छ।

विभाजित तालिकाहरू

क्रलरको पहिलो सुरुवात पछि, प्रत्येक स्क्यान गरिएको बाल्टिनको लागि तालिकाहरू सेटिङहरूमा निर्दिष्ट गरिएको डेटाबेसमा देखा पर्दछ। एथेना कन्सोल खोल्नुहोस् र 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 मेगाबाइट प्रति अनुरोध को लागी छैन। तर यो अझै धेरै राम्रो छ, र ठूलो डेटासेटहरूमा भिन्नता धेरै प्रभावशाली हुनेछ।

Cube.js प्रयोग गरेर ड्यासबोर्ड निर्माण गर्दै

ड्यासबोर्ड जम्मा गर्न, हामी Cube.js विश्लेषणात्मक फ्रेमवर्क प्रयोग गर्छौं। यसमा धेरै प्रकार्यहरू छन्, तर हामी दुईमा रुचि राख्छौं: स्वचालित रूपमा विभाजन फिल्टरहरू र डेटा पूर्व-एकत्रीकरण प्रयोग गर्ने क्षमता। यसले डाटा स्किमा प्रयोग गर्दछ डाटा स्कीमा, SQL उत्पन्न गर्न र डाटाबेस क्वेरी कार्यान्वयन गर्न Javascript मा लेखिएको। हामीले डाटा स्किमामा विभाजन फिल्टर कसरी प्रयोग गर्ने भनेर संकेत गर्न आवश्यक छ।

एउटा नयाँ Cube.js अनुप्रयोग सिर्जना गरौं। हामीले पहिले नै AWS स्ट्याक प्रयोग गरिसकेकाले, Lambda प्रयोग गर्नु तार्किक छ। यदि तपाइँ Heroku वा Docker मा 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`
    }
  }
});

यहाँ हामी चर प्रयोग गर्दैछौं 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 र लोकप्रिय फ्रन्ट-एन्ड फ्रेमवर्कका लागि ग्राहक पुस्तकालयहरूको सेट। हामी ड्यासबोर्ड निर्माण गर्न ग्राहकको प्रतिक्रिया संस्करण प्रयोग गर्नेछौं। Cube.js ले डाटा मात्र उपलब्ध गराउँछ, त्यसैले हामीलाई भिजुअलाइजेशन लाइब्रेरी चाहिन्छ - मलाई यो मनपर्छ रिचार्टहरू, तर तपाईं कुनै पनि प्रयोग गर्न सक्नुहुन्छ।

Cube.js सर्भरले अनुरोध स्वीकार गर्दछ JSON ढाँचा, जसले आवश्यक मेट्रिक्स निर्दिष्ट गर्दछ। उदाहरणका लागि, Nginx ले दिनमा कति त्रुटिहरू दियो भनेर गणना गर्न, तपाईंले निम्न अनुरोध पठाउनु पर्छ:

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

NPM मार्फत Cube.js क्लाइन्ट र प्रतिक्रिया कम्पोनेन्ट लाइब्रेरी स्थापना गरौं:

$ 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 प्रयोग गरेर Nginx लग एनालिटिक्स