Nginx ჟურნალის ანალიტიკა Amazon Athena-სა და Cube.js-ის გამოყენებით

როგორც წესი, კომერციული პროდუქტები ან მზა ღია წყაროს ალტერნატივები, როგორიცაა Prometheus + Grafana, გამოიყენება Nginx-ის მუშაობის მონიტორინგისა და ანალიზისთვის. ეს კარგი ვარიანტია მონიტორინგისთვის ან რეალურ დროში ანალიტიკისთვის, მაგრამ არც ისე მოსახერხებელი ისტორიული ანალიზისთვის. ნებისმიერ პოპულარულ რესურსზე, nginx logs-ის მონაცემების მოცულობა სწრაფად იზრდება და დიდი რაოდენობით მონაცემების გასაანალიზებლად, ლოგიკურია გამოიყენოთ რაიმე უფრო სპეციალიზებული.

ამ სტატიაში მე გეტყვით, თუ როგორ შეგიძლიათ გამოიყენოთ Athena ჟურნალების გასაანალიზებლად, მაგალითად Nginx-ის მაგალითზე, და მე გაჩვენებთ, თუ როგორ უნდა ავაწყოთ ანალიტიკური დაფა ამ მონაცემებიდან ღია კოდის cube.js ჩარჩოს გამოყენებით. აქ არის გადაწყვეტის სრული არქიტექტურა:

TL:DR;
ბმული მზა დაფაზე.

ინფორმაციის შესაგროვებლად ჩვენ ვიყენებთ გამართული, დასამუშავებლად - AWS Kinesis Data Firehose и AWS წებოშესანახად - AWS S3. ამ ნაკრების გამოყენებით შეგიძლიათ შეინახოთ არა მხოლოდ nginx ჟურნალები, არამედ სხვა მოვლენები, ისევე როგორც სხვა სერვისების ჟურნალები. თქვენ შეგიძლიათ შეცვალოთ ზოგიერთი ნაწილი მსგავსი ნაწილებით თქვენი სტეკისთვის, მაგალითად, შეგიძლიათ დაწეროთ logs to kinesis-ზე პირდაპირ nginx-დან, 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-ს კონსოლში

მოდით შევქმნათ ცხრილი ათენაში ჟურნალებისთვის. ის საჭიროა როგორც წერისთვის, ასევე კითხვისთვის, თუ გეგმავთ 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-ზე fluentd-დან, მაგრამ ამ შემთხვევაში მოგიწევთ დაწეროთ JSON და ეს არაეფექტურია ფაილების დიდი ზომის გამო. გარდა ამისა, PrestoDB ან Athena-ს გამოყენებისას, JSON არის ყველაზე ნელი მონაცემთა ფორმატი. ასე რომ, გახსენით Kinesis Firehose კონსოლი, დააწკაპუნეთ "მიწოდების ნაკადის შექმნა", "მიწოდების" ველში აირჩიეთ "პირდაპირი PUT":

შემდეგ ჩანართში აირჩიეთ „ჩაწერის ფორმატის კონვერტაცია“ - „ჩართულია“ და ჩაწერის ფორმატად აირჩიეთ „Apache ORC“. ზოგიერთი კვლევის მიხედვით ოუენ ომელი, ეს არის ოპტიმალური ფორმატი PrestoDB და Athena-სთვის. ჩვენ ვიყენებთ ზემოთ შექმნილ ცხრილს, როგორც სქემას. გთხოვთ გაითვალისწინოთ, რომ თქვენ შეგიძლიათ მიუთითოთ ნებისმიერი S3 მდებარეობა კინეზიში; მხოლოდ სქემა გამოიყენება ცხრილიდან. მაგრამ თუ თქვენ მიუთითებთ სხვა S3 მდებარეობას, მაშინ ვერ შეძლებთ ამ ჩანაწერების წაკითხვას ამ ცხრილიდან.

ჩვენ ვირჩევთ S3 შესანახად და თაიგულს, რომელიც ადრე შევქმენით. Aws Glue Crawler, რომელზეც ცოტა მოგვიანებით ვისაუბრებ, ვერ მუშაობს პრეფიქსებით S3 თაიგულში, ამიტომ მნიშვნელოვანია მისი ცარიელი დატოვება.

დარჩენილი ვარიანტები შეიძლება შეიცვალოს თქვენი დატვირთვის მიხედვით; მე ჩვეულებრივ ვიყენებ ნაგულისხმევს. გაითვალისწინეთ, რომ S3 შეკუმშვა არ არის ხელმისაწვდომი, მაგრამ ORC ნაგულისხმევად იყენებს მშობლიურ შეკუმშვას.

გამართული

ახლა, როდესაც ჩვენ დავაკონფიგურირეთ ჟურნალების შენახვა და მიღება, ჩვენ გვჭირდება გაგზავნის კონფიგურაცია. ჩვენ გამოვიყენებთ გამართული, იმიტომ, რომ მე მიყვარს Ruby, მაგრამ შეგიძლიათ გამოიყენოთ 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-ის კონტეინერში, ამ შემთხვევაში Docker-ს აქვს ფლუენტდ-ის ლოგინგის დრაივერი:

$ 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-ის კონფიგურაციას:

<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 მბ თითო მოთხოვნაზე.

ამის გამოსწორების მიზნით, ჩვენ ვიყენებთ AWS Glue Crawler-ს, რომელიც დაათვალიერებს მონაცემებს S3-ში და ჩაწერს დანაყოფის ინფორმაციას Glue Metastore-ში. ეს საშუალებას მოგვცემს გამოვიყენოთ ტიხრები, როგორც ფილტრი Athena-ს შეკითხვისას და ის მხოლოდ დაასკანირებს მოთხოვნაში მითითებულ დირექტორიაებს.

Amazon Glue Crawler-ის დაყენება

Amazon Glue Crawler სკანირებს ყველა მონაცემს S3 თაიგულში და ქმნის ცხრილებს დანაყოფებით. შექმენით Glue Crawler AWS Glue კონსოლიდან და დაამატეთ თაიგული, სადაც ინახავთ მონაცემებს. თქვენ შეგიძლიათ გამოიყენოთ ერთი მცოცავი რამდენიმე თაიგულისთვის, ამ შემთხვევაში ის შექმნის ცხრილებს მითითებულ მონაცემთა ბაზაში სახელებით, რომლებიც ემთხვევა თაიგულების სახელებს. თუ ამ მონაცემების რეგულარულად გამოყენებას გეგმავთ, დარწმუნდით, რომ დააკონფიგურირეთ 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_PARAMSSQL მოთხოვნის გენერირება დანაყოფის ფილტრით.

ჩვენ ასევე ვაყენებთ მეტრიკასა და პარამეტრებს, რომლებიც გვინდა გამოვაჩინოთ დაფაზე და მივუთითოთ წინასწარი აგრეგაციები. 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 backend უზრუნველყოფს 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>
        );
      }}
    />
  )
}

დაფის წყაროები ხელმისაწვდომია აქ კოდის ქვიშის ყუთი.

წყარო: www.habr.com