ပုံမှန်အားဖြင့်၊ Prometheus + Grafana ကဲ့သို့သော စီးပွားဖြစ်ထုတ်ကုန်များ သို့မဟုတ် အဆင်သင့်လုပ်ထားသော open-source အခြားရွေးချယ်စရာများကို Nginx ၏လုပ်ဆောင်ချက်ကို စောင့်ကြည့်ပြီး ခွဲခြမ်းစိတ်ဖြာရန် အသုံးပြုပါသည်။ ဤသည်မှာ စောင့်ကြည့်ခြင်း သို့မဟုတ် အချိန်နှင့်တပြေးညီ ခွဲခြမ်းစိတ်ဖြာခြင်းအတွက် ကောင်းမွန်သော ရွေးချယ်မှုတစ်ခုဖြစ်သော်လည်း သမိုင်းဆိုင်ရာ ခွဲခြမ်းစိတ်ဖြာမှုအတွက် အလွန်အဆင်ပြေမည်မဟုတ်ပေ။ ရေပန်းစားသော အရင်းအမြစ်တစ်ခုခုတွင်၊ nginx မှတ်တမ်းများမှ ဒေတာပမာဏသည် လျင်မြန်စွာ ကြီးထွားနေပြီး ဒေတာပမာဏအများအပြားကို ခွဲခြမ်းစိတ်ဖြာရန်၊ ပိုမိုထူးခြားသော အရာတစ်ခုကို အသုံးပြုခြင်းသည် ယုတ္တိတန်ပါသည်။
ဤဆောင်းပါးတွင်သင်မည်သို့အသုံးပြုရမည်ကိုပြောပြပါမည်။
TL:DR;
အချက်အလက်စုဆောင်းရန် ကျွန်ုပ်တို့အသုံးပြုသည်။
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" "-"
၎င်းတို့ကို ခွဲခြမ်းစိတ်ဖြာနိုင်သော်လည်း JSON တွင် မှတ်တမ်းများထုတ်ပေးနိုင်ရန် Nginx ဖွဲ့စည်းမှုပုံစံကို ပြင်ရန် ပိုမိုလွယ်ကူပါသည်။
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 Stream ဖန်တီးခြင်း။
Kinesis Firehose သည် ရွေးချယ်ထားသောဖော်မတ်တွင် Nginx မှ S3 သို့ရရှိသောဒေတာကို YYYY/MM/DD/HH ဖော်မတ်တွင် လမ်းညွှန်များအဖြစ် ပိုင်းခြားပေးမည်ဖြစ်သည်။ ဒေတာဖတ်တဲ့အခါ ဒါက အဆင်ပြေပါလိမ့်မယ်။ သင်သည် S3 ကို ကျွမ်းကျင်စွာ တိုက်ရိုက် ရေးနိုင်သော်လည်း ဤကိစ္စတွင် သင်သည် JSON ကို ရေးသားရမည်ဖြစ်ပြီး ဖိုင်များ၏ အရွယ်အစား ကြီးမားခြင်းကြောင့် ၎င်းသည် ထိရောက်မှု မရှိပေ။ ထို့အပြင်၊ PrestoDB သို့မဟုတ် Athena ကိုအသုံးပြုသည့်အခါ JSON သည် အနှေးဆုံးဒေတာဖော်မတ်ဖြစ်သည်။ ထို့ကြောင့် Kinesis Firehose ကွန်ဆိုးလ်ကိုဖွင့်ပါ၊ “ပေးပို့မှုလမ်းကြောင်းကိုဖန်တီးပါ” ကိုနှိပ်ပါ၊ “ပေးပို့ခြင်း” အကွက်တွင် “တိုက်ရိုက် PUT” ကိုရွေးချယ်ပါ။
နောက်တဘ်တွင်၊ "Record format conversion" - "Enabled" ကိုရွေးချယ်ပြီး "Apache ORC" ကို အသံသွင်းဖော်မတ်အဖြစ် ရွေးချယ်ပါ။ သုတေသနအချို့အရ သိရသည်။
ကျွန်ုပ်တို့သည် သိုလှောင်မှုအတွက် S3 နှင့် အစောပိုင်းက ကျွန်ုပ်တို့ဖန်တီးခဲ့သော ပုံးကို ရွေးချယ်သည်။ နောက်အနည်းငယ်ပြောပြမည့် Aws Glue Crawler သည် S3 ပုံးတွင် ရှေ့ဆက်များနှင့် အလုပ်မဖြစ်နိုင်သောကြောင့် ၎င်းကို ဗလာအဖြစ်ထားရန် အရေးကြီးပါသည်။
သင်၏ဝန်ပေါ်မူတည်၍ ကျန်ရွေးချယ်စရာများကို ပြောင်းလဲနိုင်သည်၊ ကျွန်ုပ်သည် ပုံမှန်အားဖြင့် ၎င်းတို့ကို အသုံးပြုပါသည်။ S3 ချုံ့မှုကို မရရှိနိုင်ကြောင်း သတိပြုပါ၊ သို့သော် ORC သည် မူရင်းချုံ့မှုကို မူရင်းအတိုင်း အသုံးပြုသည်။
ကျွမ်းကျင်စွာ
ယခု ကျွန်ုပ်တို့သည် သိမ်းဆည်းခြင်းနှင့် လက်ခံခြင်းမှတ်တမ်းများကို စီစဉ်သတ်မှတ်ထားသောကြောင့် ပေးပို့ခြင်းကို ပြင်ဆင်သတ်မှတ်ရန် လိုအပ်ပါသည်။ သုံးမယ်။
အရင်ဆုံး fluent.conf configuration file ကိုလိုအပ်ပါတယ်။ ၎င်းကိုဖန်တီးပြီးရင်းမြစ်ကိုထည့်ပါ-
ဆိပ်ကမ်းကို 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
မပို့မီ ကက်ရှ်မှတ်တမ်းများ ပြုလုပ်ရန်။ ၎င်းမပါဘဲ သင်လုပ်နိုင်သည်၊ သို့သော် ပြန်လည်စတင်သည့်အခါ၊ back-breaking လုပ်အားဖြင့် သိမ်းဆည်းထားသော အရာအားလုံးကို သင်ဆုံးရှုံးနိုင်သည်။ မည်သည့်ဆိပ်ကမ်းကိုမဆို သင်အသုံးပြုနိုင်သည်၊ 24224 သည် မူရင်း Fluentd ဆိပ်ကမ်းဖြစ်သည်။
ယခု ကျွန်ုပ်တို့တွင် Fluentd လည်ပတ်နေပြီဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့သည် ထိုနေရာတွင် Nginx မှတ်တမ်းများကို ပေးပို့နိုင်ပါသည်။ ကျွန်ုပ်တို့သည် များသောအားဖြင့် Docker ကွန်တိန်နာတွင် Nginx ကို run လေ့ရှိသည်၊ ယင်းအခြေအနေတွင် Docker တွင် Fluentd အတွက် မူရင်း logging driver ရှိသည်။
$ 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 configuration တွင် အထက်တွင်သတ်မှတ်ထားသော ခွဲခြမ်းစိတ်ဖြာမှုမှတ်တမ်းကို ထည့်ကြပါစို့။
<filter YOUR-NGINX-TAG.*>
@type parser
key_name log
emit_invalid_record_to_error false
<parse>
@type json
</parse>
</filter>
အသုံးပြု၍ Kinesis သို့ မှတ်တမ်းများ ပေးပို့ခြင်း။
<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 သည် ၎င်းတို့အား နာရီတိုင်းအတွက် လမ်းညွှန်ချက်များအဖြစ်ပင် စီစဉ်ပေးခဲ့သည်။ သို့သော်၊ ဇယားကိုအပိုင်းပိုင်းမခွဲထားသရွေ့ Athena သည် ရှားပါးခြွင်းချက်များဖြင့် တောင်းဆိုမှုတိုင်းအတွက် အချိန်တိုင်းဒေတာကို တင်ပါမည်။ ဤသည်မှာ အကြောင်းအရင်း နှစ်ခုကြောင့် ကြီးမားသော ပြဿနာဖြစ်သည် ။
- ဒေတာပမာဏသည် အဆက်မပြတ်ကြီးထွားနေပြီး၊ မေးမြန်းမှုများကို နှေးကွေးစေသည်။
- Athena သည် တောင်းဆိုမှုတစ်ခုလျှင် အနည်းဆုံး 10 MB ဖြင့် စကင်ဖတ်ထားသော ဒေတာပမာဏအပေါ် အခြေခံ၍ ကောက်ခံပါသည်။
၎င်းကိုဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် S3 တွင်ဒေတာကိုရှာဖွေပြီး Glue Metastore သို့ partition အချက်အလက်ကိုရေးပေးမည့် AWS Glue Crawler ကိုအသုံးပြုသည်။ ၎င်းသည် Athena ကိုမေးမြန်းသည့်အခါ partitions များကို filter တစ်ခုအဖြစ်အသုံးပြုရန်ခွင့်ပြုမည်ဖြစ်ပြီး၊ ၎င်းသည် query တွင်ဖော်ပြထားသောလမ်းကြောင်းများကိုသာစကင်န်ဖတ်မည်ဖြစ်သည်။
Amazon Glue Crawler ကို စနစ်ထည့်သွင်းခြင်း။
Amazon Glue Crawler သည် S3 ပုံးရှိ ဒေတာအားလုံးကို စကန်ဖတ်ပြီး အပိုင်းများပါသော ဇယားများကို ဖန်တီးသည်။ AWS Glue ကွန်ဆိုးလ်မှ Glue 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 megabytes ရှိသော dataset တစ်ခုတွင် မှတ်တမ်းများ တစ်ပတ်သာရှိသည်။ partition အလိုက် filter တစ်ခုကို စမ်းကြည့်ရအောင်။
အနည်းငယ်မြန်သော်လည်း အရေးအကြီးဆုံးမှာ - ဒေတာ 1.23 megabytes သာရှိသည်။ စျေးနှုန်းတောင်းဆိုမှုတစ်ခုလျှင် အနည်းဆုံး 10 megabytes အတွက်မဟုတ်ပါက များစွာစျေးသက်သာမည်ဖြစ်ပါသည်။ သို့သော် ၎င်းသည် များစွာပိုကောင်းနေသေးပြီး ကြီးမားသောဒေတာအတွဲများတွင် ခြားနားချက်သည် ပို၍အထင်ကြီးစရာဖြစ်လိမ့်မည်။
Cube.js ကိုအသုံးပြု၍ ဒက်ရှ်ဘုတ်တစ်ခုတည်ဆောက်ခြင်း။
ဒက်ရှ်ဘုတ်ကို စုစည်းရန်အတွက် Cube.js ခွဲခြမ်းစိတ်ဖြာမှုဆိုင်ရာ မူဘောင်ကို အသုံးပြုသည်။ ၎င်းတွင် လုပ်ဆောင်ချက်များစွာ ပါဝင်သော်လည်း ကျွန်ုပ်တို့ စိတ်ဝင်စားသည်မှာ- အခန်းကန့်စစ်ထုတ်ခြင်းများနှင့် ဒေတာကြိုတင်စုစည်းမှု အလိုအလျောက် အသုံးပြုနိုင်သည့် စွမ်းရည်နှစ်ခုဖြစ်သည်။ ၎င်းသည် data schema ကိုအသုံးပြုသည်။
Cube.js အပလီကေးရှင်းအသစ်တစ်ခု ဖန်တီးကြပါစို့။ ကျွန်ုပ်တို့သည် AWS stack ကိုအသုံးပြုပြီးဖြစ်သောကြောင့်၊ အသုံးပြုရန် Lambda ကိုအသုံးပြုခြင်းသည် ယုတ္တိတန်ပါသည်။ အကယ်၍ သင်သည် Heroku သို့မဟုတ် Docker တွင် Cube.js နောက်ခံကို လက်ခံကျင်းပရန် စီစဉ်ပါက မျိုးဆက်အတွက် အမြန်ပုံစံကို အသုံးပြုနိုင်သည်။ စာတမ်းတွင် အခြားသူများကို ဖော်ပြသည်။
$ npm install -g cubejs-cli
$ cubejs create nginx-log-analytics -t serverless -d athena
cube.js တွင် ဒေတာဘေ့စ်ဝင်ရောက်ခွင့်ကို ပြင်ဆင်သတ်မှတ်ရန် Environment variable များကို အသုံးပြုသည်။ ဂျင်နရေတာသည် သင့်သော့များအတွက် သင်သတ်မှတ်နိုင်သည့် .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 ကိုအသုံးပြုနေသည်။
ဒက်ရှ်ဘုတ်ပေါ်တွင် ကျွန်ုပ်တို့ပြသလိုသည့် မက်ထရစ်များနှင့် ကန့်သတ်ချက်များကိုလည်း သတ်မှတ်ပြီး ကြိုတင်စုစည်းမှုများကို သတ်မှတ်ပေးပါသည်။ Cube.js သည် ကြိုတင်စုစည်းထားသောဒေတာဖြင့် နောက်ထပ်ဇယားများကို ဖန်တီးမည်ဖြစ်ပြီး ၎င်းရောက်ရှိလာသည်နှင့်အမျှ ဒေတာကို အလိုအလျောက် အပ်ဒိတ်လုပ်မည်ဖြစ်သည်။ ၎င်းသည် မေးမြန်းမှုများကို မြန်ဆန်စေရုံသာမက Athena အသုံးပြုမှုကုန်ကျစရိတ်ကိုလည်း လျှော့ချပေးပါသည်။
ဤအချက်အလက်ကို data 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`
)
}
}
}
အသုံးပြုထားသော မက်ထရစ်များအားလုံးအတွက် ဒေတာကို ကြိုတင်စုစည်းရန်နှင့် လအလိုက် ပိုင်းခြားခြင်းကို အသုံးပြုရန် လိုအပ်ကြောင်း ဤပုံစံတွင် ကျွန်ုပ်တို့ သတ်မှတ်ပါသည်။
ယခု ကျွန်ုပ်တို့သည် ဒက်ရှ်ဘုတ်ကို စုစည်းနိုင်ပါပြီ။
Cube.js backend က ပံ့ပိုးပေးတယ်။
Cube.js ဆာဗာသည် တောင်းဆိုချက်ကို လက်ခံပါသည်။
{
"measures": ["Logs.errorCount"],
"timeDimensions": [
{
"dimension": "Logs.createdAt",
"dateRange": ["2019-01-01", "2019-01-07"],
"granularity": "day"
}
]
}
Cube.js client နှင့် NPM မှတစ်ဆင့် React အစိတ်အပိုင်းစာကြည့်တိုက်ကို ထည့်သွင်းကြပါစို့။
$ 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>
);
}}
/>
)
}
ဒက်ရှ်ဘုတ်ရင်းမြစ်များကို တွင် ရရှိနိုင်ပါသည်။
source: www.habr.com