ການພັດທະນາ plugin ສໍາລັບ Grafana: ປະຫວັດສາດຂອງການສັກຢາໃຫຍ່

ສະບາຍດີທຸກຄົນ! ສອງສາມເດືອນກ່ອນຫນ້ານີ້, ພວກເຮົາໄດ້ເປີດຕົວໂຄງການ open-source ໃຫມ່ຂອງພວກເຮົາເຂົ້າໃນການຜະລິດ - plugin Grafana ສໍາລັບການຕິດຕາມ kubernetes, ທີ່ພວກເຮົາເອີ້ນວ່າ. DevOpsProdigy KubeGraf. ລະຫັດແຫຼ່ງ plugin ແມ່ນມີຢູ່ ຄັງເກັບສາທາລະນະໃນ GitHub. ແລະໃນບົດຄວາມນີ້ພວກເຮົາຕ້ອງການແບ່ງປັນກັບທ່ານກ່ຽວກັບວິທີທີ່ພວກເຮົາສ້າງ plugin, ເຄື່ອງມືທີ່ພວກເຮົາໃຊ້ແລະສິ່ງທີ່ພວກເຮົາພົບໃນຂະບວນການພັດທະນາ. ໄປ​ກັນ​ເລີຍ!

ພາກທີ 0 - ແນະນໍາ: ພວກເຮົາມາຮອດຈຸດນີ້ໄດ້ແນວໃດ?

ຄວາມຄິດທີ່ຈະຂຽນ plugin ຂອງພວກເຮົາເອງສໍາລັບ Grafan ໄດ້ມາຫາພວກເຮົາໂດຍບັງເອີນ. ບໍລິສັດຂອງພວກເຮົາໄດ້ຕິດຕາມໂຄງການເວັບໄຊຕ໌ຂອງລະດັບຕ່າງໆຂອງຄວາມສັບສົນຫຼາຍກວ່າ 10 ປີ. ໃນລະຫວ່າງເວລານີ້, ພວກເຮົາໄດ້ສະສົມຄວາມຊໍານານຈໍານວນຫລາຍ, ກໍລະນີທີ່ຫນ້າສົນໃຈ, ແລະປະສົບການໃນການນໍາໃຊ້ລະບົບການຕິດຕາມຕ່າງໆ. ແລະໃນບາງຈຸດພວກເຮົາໄດ້ຖາມຕົວເອງວ່າ: "ມີເຄື່ອງມື magic ສໍາລັບການຕິດຕາມ Kubernetes, ດັ່ງນັ້ນ, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, "ຕັ້ງມັນແລະລືມມັນ"? .. ມາດຕະຖານອຸດສາຫະກໍາສໍາລັບການຕິດຕາມ k8s, ແນ່ນອນ, ມີມາດົນນານແລ້ວ ການປະສົມປະສານຂອງ Prometheus + Grafana. ແລະເປັນການແກ້ໄຂທີ່ພ້ອມທີ່ຈະເຮັດສໍາລັບ stack ນີ້, ມີຊຸດຂະຫນາດໃຫຍ່ຂອງປະເພດຕ່າງໆຂອງເຄື່ອງມື: prometheus-operator, ຊຸດຂອງ dashboards kubernetes-mixin, grafana-kubernetes-app.

plugin grafana-kubernetes-app ເບິ່ງຄືວ່າເປັນທາງເລືອກທີ່ຫນ້າສົນໃຈທີ່ສຸດສໍາລັບພວກເຮົາ, ແຕ່ມັນບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນຫຼາຍກວ່າຫນຶ່ງປີແລະ, ນອກຈາກນັ້ນ, ບໍ່ສາມາດເຮັດວຽກກັບສະບັບໃຫມ່ຂອງ node-exporter ແລະ kube-state-metrics. ແລະໃນບາງຈຸດພວກເຮົາໄດ້ຕັດສິນໃຈ: "ພວກເຮົາບໍ່ຄວນຕັດສິນໃຈຂອງຕົນເອງບໍ?"

ແນວຄວາມຄິດອັນໃດທີ່ພວກເຮົາຕັດສິນໃຈປະຕິບັດໃນ plugin ຂອງພວກເຮົາ:

• ການສະແດງພາບຂອງ "ແຜນທີ່ແອັບພລິເຄຊັນ": ການນໍາສະເຫນີທີ່ສະດວກຂອງຄໍາຮ້ອງສະຫມັກໃນກຸ່ມ, ຈັດກຸ່ມໂດຍ namespaces, deployments ... ;
• ການສະແດງພາບຂອງການເຊື່ອມຕໍ່ເຊັ່ນ "ການປັບໃຊ້ - ບໍລິການ (+ ພອດ)".
• ການເບິ່ງເຫັນພາບຂອງການແຈກຢາຍຂອງແອັບພລິເຄຊັນກຸ່ມໃນທົ່ວກຸ່ມຂອງກຸ່ມ.
• ການເກັບກໍາຂໍ້ມູນ metrics ແລະຂໍ້ມູນຈາກຫຼາຍແຫຼ່ງ: Prometheus ແລະ k8s api server.
• ການຕິດຕາມທັງສອງສ່ວນຂອງໂຄງສ້າງພື້ນຖານ (ການນໍາໃຊ້ເວລາ CPU, ຫນ່ວຍຄວາມຈໍາ, ລະບົບຍ່ອຍຂອງແຜ່ນ, ເຄືອຂ່າຍ) ແລະເຫດຜົນຂອງແອັບພລິເຄຊັນ - ໂພຊະນາການສະຖານະພາບສຸຂະພາບ, ຈໍານວນການຈໍາລອງທີ່ມີຢູ່, ຂໍ້ມູນກ່ຽວກັບການທົດສອບຄວາມພ້ອມ / ຊີວິດ.

ສ່ວນທີ 1: "Plugin Grafana" ແມ່ນຫຍັງ?

ຈາກມຸມເບິ່ງດ້ານວິຊາການ, plugin ສໍາລັບ Grafana ແມ່ນຕົວຄວບຄຸມມຸມ, ເຊິ່ງຖືກເກັບໄວ້ໃນໄດເລກະທໍລີຂໍ້ມູນ Grafana (/var/grafana/plugins/ /dist/module.js) ແລະສາມາດໂຫລດເປັນໂມດູນ SystemJS. ນອກຈາກນັ້ນໃນໄດເລກະທໍລີນີ້ຄວນຈະມີໄຟລ໌ plugin.json ທີ່ມີຂໍ້ມູນ meta ທັງຫມົດກ່ຽວກັບ plugin ຂອງທ່ານ: ຊື່, ຮຸ່ນ, ປະເພດ plugin, ການເຊື່ອມຕໍ່ກັບ repository / site / ໃບອະນຸຍາດ, ການຂຶ້ນກັບ, ແລະອື່ນໆ.

module.ts

plugin.json

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໃນພາບຫນ້າຈໍ, ພວກເຮົາກໍານົດ plugin.type = app. ເນື່ອງຈາກວ່າ plugins ສໍາລັບ Grafana ສາມາດມີສາມປະເພດ:

ຄະນະກໍາມະ: ປະເພດປັ໊ກອິນທົ່ວໄປທີ່ສຸດ - ມັນເປັນກະດານສໍາລັບການເບິ່ງເຫັນ metrics ໃດ, ໃຊ້ເພື່ອສ້າງ dashboards ຕ່າງໆ.
ແຫຼ່ງຂໍ້ມູນ: ຕົວເຊື່ອມຕໍ່ plugin ກັບບາງແຫຼ່ງຂໍ້ມູນ (ຕົວຢ່າງ: Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource).
app: ປັ໊ກອິນທີ່ຊ່ວຍໃຫ້ທ່ານສ້າງຄໍາຮ້ອງສະຫມັກດ້ານຫນ້າຂອງທ່ານເອງພາຍໃນ Grafana, ສ້າງຫນ້າ html ຂອງທ່ານເອງແລະເຂົ້າເຖິງແຫຼ່ງຂໍ້ມູນດ້ວຍຕົນເອງເພື່ອສະແດງຂໍ້ມູນຕ່າງໆ. ນອກຈາກນີ້, plugins ຂອງປະເພດອື່ນໆ (ແຫຼ່ງຂໍ້ມູນ, ກະດານ) ແລະ dashboards ຕ່າງໆສາມາດນໍາໃຊ້ເປັນ dependencies.

ຕົວຢ່າງການຂຶ້ນກັບ plugin ກັບ type=app.

ທ່ານສາມາດນໍາໃຊ້ທັງ JavaScript ແລະ TypeScript ເປັນພາສາການຂຽນໂປຼແກຼມ (ພວກເຮົາເລືອກມັນ). ການກະກຽມສໍາລັບ plugins hello-world ຂອງທຸກປະເພດທີ່ທ່ານສາມາດເຮັດໄດ້ ຊອກຫາການເຊື່ອມຕໍ່: repository ນີ້ປະກອບມີ starter-packs ຈໍານວນຫລາຍ (ມີເຖິງແມ່ນຕົວຢ່າງທົດລອງຂອງ plugin ໃນ React) ກັບ builders ທີ່ຕິດຕັ້ງໄວ້ກ່ອນແລະ configured.

ພາກທີ 2: ການກະກຽມສະພາບແວດລ້ອມທ້ອງຖິ່ນ

ເພື່ອເຮັດວຽກກ່ຽວກັບ plugin, ຕາມທໍາມະຊາດພວກເຮົາຕ້ອງການກຸ່ມ kubernetes ທີ່ມີເຄື່ອງມືທີ່ຕິດຕັ້ງໄວ້ກ່ອນທັງຫມົດ: prometheus, node-exporter, kube-state-metrics, grafana. ສະພາບແວດລ້ອມຄວນໄດ້ຮັບການສ້າງຕັ້ງຂຶ້ນຢ່າງໄວວາ, ງ່າຍດາຍແລະທໍາມະຊາດ, ແລະເພື່ອຮັບປະກັນການໂຫຼດຄືນໃຫມ່, ໄດເລກະທໍລີຂໍ້ມູນ Grafana ຄວນຖືກຕິດຕັ້ງໂດຍກົງຈາກເຄື່ອງຂອງຜູ້ພັດທະນາ.

ວິທີທີ່ສະດວກທີ່ສຸດ, ໃນຄວາມຄິດເຫັນຂອງພວກເຮົາ, ເຮັດວຽກໃນທ້ອງຖິ່ນກັບ kubernetes ແມ່ນ ມິນິຄິບ. ຂັ້ນຕອນຕໍ່ໄປແມ່ນການຕິດຕັ້ງການປະສົມປະສານ Prometheus + Grafana ໂດຍໃຊ້ prometheus-operator. IN ຫົວ​ຂໍ້​ນີ້ ຂັ້ນຕອນການຕິດຕັ້ງ prometheus-operator ໃນ minikube ແມ່ນໄດ້ອະທິບາຍຢ່າງລະອຽດ. ເພື່ອເປີດໃຊ້ຄວາມຄົງທົນ, ທ່ານຕ້ອງກໍານົດພາລາມິເຕີ ຄວາມຄົງທົນ: ຄວາມຈິງ ໃນໄຟລ໌ charts/grafana/values.yaml, ເພີ່ມ PV ແລະ PVC ຂອງທ່ານເອງ ແລະລະບຸພວກມັນຢູ່ໃນພາລາມິເຕີ persistence.existingClaim

script ການເປີດຕົວ minikube ສຸດທ້າຍຂອງພວກເຮົາເບິ່ງຄືວ່ານີ້:

minikube start --kubernetes-version=v1.13.4 --memory=4096 --bootstrapper=kubeadm --extra-config=scheduler.address=0.0.0.0 --extra-config=controller-manager.address=0.0.0.0
minikube mount 
/home/sergeisporyshev/Projects/Grafana:/var/grafana --gid=472 --uid=472 --9p-version=9p2000.L

ພາກທີ 3: ການພັດທະນາຕົວຈິງ

ຮູບແບບວັດຖຸ

ໃນການກະກຽມສໍາລັບການປະຕິບັດ plugin, ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະອະທິບາຍທຸກຫນ່ວຍງານ Kubernetes ພື້ນຖານທີ່ພວກເຮົາຈະເຮັດວຽກກັບໃນຮູບແບບຂອງຫ້ອງຮຽນ TypeScript: pod, deployment, daemonset, statefulset, job, cronjob, service, node, namespace. ແຕ່ລະຊັ້ນຮຽນເຫຼົ່ານີ້ສືບທອດມາຈາກຫ້ອງຮຽນ BaseModel ທົ່ວໄປ, ເຊິ່ງອະທິບາຍເຖິງຕົວສ້າງ, ຕົວທໍາລາຍ, ວິທີການປັບປຸງ ແລະປ່ຽນການເບິ່ງເຫັນ. ແຕ່ລະຊັ້ນຮຽນອະທິບາຍຄວາມສຳພັນທີ່ຕິດພັນກັບໜ່ວຍງານອື່ນ, ຕົວຢ່າງ, ລາຍຊື່ຂອງຝັກສຳລັບໜ່ວຍງານຂອງການຈັດປະເພດ.

import {Pod} from "./pod";
import {Service} from "./service";
import {BaseModel} from './traits/baseModel';

export class Deployment extends BaseModel{
   pods: Array<Pod>;
   services: Array<Service>;

   constructor(data: any){
       super(data);
       this.pods = [];
       this.services = [];
   }
}

ດ້ວຍຄວາມຊ່ອຍເຫລືອຂອງ getters ແລະ setters, ພວກເຮົາສາມາດສະແດງຫຼືກໍານົດ metrics entity ທີ່ພວກເຮົາຕ້ອງການໃນຮູບແບບທີ່ສະດວກແລະສາມາດອ່ານໄດ້. ຕົວຢ່າງ, ຮູບແບບຜົນຜະລິດຂອງ nodes cpu ທີ່ສາມາດຈັດສັນໄດ້:

get cpuAllocatableFormatted(){
   let cpu = this.data.status.allocatable.cpu;
   if(cpu.indexOf('m') > -1){
       cpu = parseInt(cpu)/1000;
   }
   return cpu;
}

ຫນ້າ

ບັນຊີລາຍຊື່ຂອງຫນ້າ plugin ຂອງພວກເຮົາທັງຫມົດແມ່ນໄດ້ອະທິບາຍໃນເບື້ອງຕົ້ນໃນ pluing.json ຂອງພວກເຮົາໃນພາກ dependencies:

ໃນບລັອກສໍາລັບແຕ່ລະຫນ້າພວກເຮົາຕ້ອງລະບຸ PAGE NAME (ຫຼັງຈາກນັ້ນມັນຈະຖືກປ່ຽນເປັນ slug ໂດຍຫນ້ານີ້ຈະສາມາດເຂົ້າເຖິງໄດ້); ຊື່ຂອງອົງປະກອບທີ່ຮັບຜິດຊອບສໍາລັບການປະຕິບັດງານຂອງຫນ້ານີ້ (ບັນຊີລາຍຊື່ຂອງອົງປະກອບຖືກສົ່ງອອກໄປຍັງ module.ts); ການຊີ້ບອກເຖິງບົດບາດຂອງຜູ້ໃຊ້ທີ່ເຮັດວຽກກັບໜ້ານີ້ມີຢູ່ ແລະການຕັ້ງຄ່າການນຳທາງສຳລັບແຖບດ້ານຂ້າງ.

ໃນອົງປະກອບທີ່ຮັບຜິດຊອບສໍາລັບການປະຕິບັດງານຂອງຫນ້າ, ພວກເຮົາຕ້ອງກໍານົດ templateUrl, ຜ່ານເສັ້ນທາງໄປຫາໄຟລ໌ html ດ້ວຍ markup. ພາຍໃນຕົວຄວບຄຸມ, ໂດຍຜ່ານການສັກຢາທີ່ຂຶ້ນກັບ, ພວກເຮົາສາມາດເຂົ້າເຖິງໄດ້ເຖິງ 2 ການບໍລິການດ້ານມຸມທີ່ສໍາຄັນ:

• backendSrv - ການບໍລິການທີ່ສະຫນອງການໂຕ້ຕອບກັບເຄື່ອງແມ່ຂ່າຍ Grafana API;
• datasourceSrv - ການບໍລິການທີ່ສະຫນອງການໂຕ້ຕອບທ້ອງຖິ່ນກັບແຫຼ່ງຂໍ້ມູນທັງຫມົດທີ່ຕິດຕັ້ງຢູ່ໃນ Grafana ຂອງທ່ານ (ຕົວຢ່າງເຊັ່ນວິທີການ .getAll() - ສົ່ງຄືນບັນຊີລາຍຊື່ຂອງແຫຼ່ງຂໍ້ມູນທີ່ຕິດຕັ້ງທັງຫມົດ; .get( ) - ສົ່ງຄືນວັດຖຸຕົວຢ່າງຂອງແຫຼ່ງຂໍ້ມູນສະເພາະ.

ສ່ວນທີ 4: ແຫຼ່ງຂໍ້ມູນ

ຈາກທັດສະນະຂອງ Grafana, ແຫຼ່ງຂໍ້ມູນແມ່ນ plugin ດຽວກັນກັບສິ່ງອື່ນໆ: ມັນມີຈຸດເຂົ້າຂອງຕົນເອງ module.js, ມີໄຟລ໌ທີ່ມີຂໍ້ມູນ meta plugin.json. ເມື່ອພັດທະນາ plugin ດ້ວຍ type = app, ພວກເຮົາສາມາດພົວພັນກັບທັງແຫຼ່ງຂໍ້ມູນທີ່ມີຢູ່ (ຕົວຢ່າງ, prometheus-datasource) ແລະຂອງພວກເຮົາເອງ, ເຊິ່ງພວກເຮົາສາມາດເກັບຮັກສາໂດຍກົງໃນ plugin directory (dist/datasource/*) ຫຼືຕິດຕັ້ງເປັນ dependency. ໃນກໍລະນີຂອງພວກເຮົາ, ແຫຼ່ງຂໍ້ມູນມາພ້ອມກັບລະຫັດ plugin. ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະມີແມ່ແບບ config.html ແລະຕົວຄວບຄຸມ ConfigCtrl, ເຊິ່ງຈະຖືກນໍາໃຊ້ສໍາລັບຫນ້າການຕັ້ງຄ່າ instance datasource ແລະຕົວຄວບຄຸມ Datasource, ເຊິ່ງປະຕິບັດເຫດຜົນຂອງແຫຼ່ງຂໍ້ມູນຂອງທ່ານ.

ໃນ plugin KubeGraf, ຈາກຈຸດໂຕ້ຕອບຂອງຜູ້ໃຊ້, ແຫຼ່ງຂໍ້ມູນແມ່ນຕົວຢ່າງຂອງກຸ່ມ kubernetes ທີ່ປະຕິບັດຄວາມສາມາດຕໍ່ໄປນີ້ (ລະຫັດແຫຼ່ງແມ່ນມີຢູ່. ການເຊື່ອມຕໍ່):

• ການ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ຈາກ k8s api-server (ການ​ໄດ້​ຮັບ​ລາຍ​ຊື່​ຂອງ namespaces​, ການ​ນໍາ​ໃຊ້ ... )
• ການຮ້ອງຂໍ proxying ກັບ prometheus-datasource (ເຊິ່ງຖືກເລືອກໃນການຕັ້ງຄ່າ plugin ສໍາລັບແຕ່ລະກຸ່ມສະເພາະ) ແລະຮູບແບບການຕອບສະຫນອງເພື່ອນໍາໃຊ້ຂໍ້ມູນທັງໃນຫນ້າຄົງທີ່ແລະໃນ dashboards.
• ການອັບເດດຂໍ້ມູນໃນໜ້າປລັກອິນຄົງທີ່ (ດ້ວຍອັດຕາໂຫຼດຂໍ້ມູນໃໝ່ທີ່ກຳນົດໄວ້).
• ດໍາເນີນການສອບຖາມເພື່ອສ້າງແຜ່ນແມ່ແບບໃນ grafana-dashboards (metriFindQuery() method)

• ການທົດສອບການເຊື່ອມຕໍ່ກັບກຸ່ມ k8s ສຸດທ້າຍ.

testDatasource(){
   let url = '/api/v1/namespaces';
   let _url = this.url;
   if(this.accessViaToken)
       _url += '/__proxy';
   _url += url;
   return this.backendSrv.datasourceRequest({
       url: _url,
       method: "GET",
       headers: {"Content-Type": 'application/json'}
   })
       .then(response => {
           if (response.status === 200) {
               return {status: "success", message: "Data source is OK", title: "Success"};
           }else{
               return {status: "error", message: "Data source is not OK", title: "Error"};
           }
       }, error => {
           return {status: "error", message: "Data source is not OK", title: "Error"};
       })
}

ຈຸດທີ່ຫນ້າສົນໃຈແຍກຕ່າງຫາກ, ໃນຄວາມຄິດເຫັນຂອງພວກເຮົາ, ແມ່ນການຈັດຕັ້ງປະຕິບັດກົນໄກການກວດສອບແລະການອະນຸຍາດສໍາລັບແຫຼ່ງຂໍ້ມູນ. ໂດຍປົກກະຕິ, ອອກຈາກກ່ອງ, ພວກເຮົາສາມາດໃຊ້ອົງປະກອບຂໍ້ມູນ Grafana ທີ່ມີໂຄງສ້າງHttpSettings ເພື່ອກໍານົດການເຂົ້າເຖິງແຫຼ່ງຂໍ້ມູນສຸດທ້າຍ. ການນໍາໃຊ້ອົງປະກອບນີ້, ພວກເຮົາສາມາດຕັ້ງຄ່າການເຂົ້າເຖິງແຫຼ່ງຂໍ້ມູນ http ໂດຍການລະບຸ url ແລະການຕັ້ງຄ່າພື້ນຖານຂອງການກວດສອບຄວາມຖືກຕ້ອງ / ການອະນຸຍາດ: login-password, ຫຼື client-cert/client-key. ເພື່ອປະຕິບັດຄວາມສາມາດໃນການກໍາຫນົດຄ່າການເຂົ້າເຖິງໂດຍໃຊ້ token bearer (ມາດຕະຖານ de facto ສໍາລັບ k8s), ພວກເຮົາຕ້ອງເຮັດການປັບເລັກນ້ອຍ.

ເພື່ອ​ແກ້​ໄຂ​ບັນ​ຫາ​ນີ້​, ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ກົນ​ໄກ Grafana "Plugin Routes​" ທີ່​ມີ​ຢູ່​ໃນ (ລາຍ​ລະ​ອຽດ​ເພີ່ມ​ເຕີມ​ໄດ້​ທີ່​. ໜ້າເອກະສານທາງການ). ໃນການຕັ້ງຄ່າຂອງແຫຼ່ງຂໍ້ມູນຂອງພວກເຮົາ, ພວກເຮົາສາມາດປະກາດຊຸດຂອງກົດລະບຽບການກໍານົດເສັ້ນທາງທີ່ຈະດໍາເນີນການໂດຍເຄື່ອງແມ່ຂ່າຍຕົວແທນ grafana. ຕົວຢ່າງ, ສໍາລັບແຕ່ລະ endpoint ແຕ່ລະຄົນສາມາດກໍານົດ headers ຫຼື urls ທີ່ມີຄວາມເປັນໄປໄດ້ຂອງ template, ຂໍ້ມູນທີ່ສາມາດເອົາມາຈາກຊ່ອງ jsonData ແລະ secureJsonData (ສໍາລັບການເກັບຮັກສາລະຫັດຜ່ານຫຼື tokens ໃນຮູບແບບການເຂົ້າລະຫັດ). ໃນຕົວຢ່າງຂອງພວກເຮົາ, ຄໍາຖາມເຊັ່ນ: /__proxy/api/v1/namespaces ຈະຖືກສົ່ງຕໍ່ກັບ url ຂອງແບບຟອມ
/api/v8/namespaces ດ້ວຍການອະນຸຍາດ: Bearer header.

ຕາມທໍາມະຊາດ, ເພື່ອເຮັດວຽກກັບເຄື່ອງແມ່ຂ່າຍ k8s api ພວກເຮົາຕ້ອງການຜູ້ໃຊ້ທີ່ມີການເຂົ້າເຖິງ readonly, manifests ສໍາລັບການສ້າງທີ່ທ່ານຍັງສາມາດຊອກຫາຢູ່ໃນ ລະຫັດແຫຼ່ງ plugin.

ສ່ວນທີ 5: ປ່ອຍ

ເມື່ອທ່ານໄດ້ຂຽນ plugin Grafana ຂອງທ່ານເອງ, ຕາມທໍາມະຊາດແລ້ວ, ທ່ານຕ້ອງການເຮັດໃຫ້ມັນເປີດເຜີຍຕໍ່ສາທາລະນະ. ໃນ Grafana ນີ້ແມ່ນຫ້ອງສະຫມຸດຂອງ plugins ມີຢູ່ທີ່ນີ້ grafana.com/grafana/plugins

ເພື່ອໃຫ້ປັ໊ກອິນຂອງທ່ານມີຢູ່ໃນຮ້ານທີ່ເປັນທາງການ, ທ່ານຈໍາເປັນຕ້ອງເຮັດ PR ໃນ repository ນີ້ໂດຍການເພີ່ມເນື້ອຫາແບບນີ້ໃສ່ໄຟລ໌ repo.json:

ບ່ອນທີ່ສະບັບແມ່ນສະບັບຂອງ plugin ຂອງທ່ານ, url ແມ່ນການເຊື່ອມຕໍ່ກັບ repository, ແລະ commit ແມ່ນ hash ຂອງຄໍາຫມັ້ນສັນຍາທີ່ສະບັບສະເພາະຂອງ plugin ຈະມີໃຫ້.

ແລະຢູ່ທີ່ຜົນຜະລິດທ່ານຈະເຫັນຮູບພາບທີ່ປະເສີດເຊັ່ນ:

ຂໍ້ມູນສໍາລັບມັນຈະຖືກຈັບໂດຍອັດຕະໂນມັດຈາກ Readme.md, Changelog.md ແລະໄຟລ໌ plugin.json ຂອງທ່ານດ້ວຍຄໍາອະທິບາຍ plugin.

ພາກທີ 6: ແທນທີ່ຈະເປັນການສະຫລຸບ

ພວກເຮົາບໍ່ໄດ້ຢຸດການພັດທະນາ plugin ຂອງພວກເຮົາຫຼັງຈາກປ່ອຍ. ແລະໃນປັດຈຸບັນພວກເຮົາກໍາລັງເຮັດວຽກກ່ຽວກັບການກວດສອບການນໍາໃຊ້ຊັບພະຍາກອນຂອງ cluster nodes ຢ່າງຖືກຕ້ອງ, ແນະນໍາຄຸນສົມບັດໃຫມ່ເພື່ອປັບປຸງ UX, ແລະຍັງໄດ້ຮັບຄໍາຕິຊົມຈໍານວນຫລາຍທີ່ໄດ້ຮັບຫຼັງຈາກການຕິດຕັ້ງ plugin ທັງໂດຍລູກຄ້າຂອງພວກເຮົາແລະຈາກຄົນໃນ GitHub (ຖ້າທ່ານອອກໄປ. ບັນຫາຫຼືການຮ້ອງຂໍຂອງທ່ານ, ຂ້ອຍຈະດີໃຈຫຼາຍ :)

ພວກເຮົາຫວັງວ່າບົດຄວາມນີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈເຄື່ອງມືທີ່ປະເສີດເຊັ່ນ Grafana ແລະ, ບາງທີ, ຂຽນ plugin ຂອງທ່ານເອງ.

ຂອບ​ໃຈ!)

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