Grafana plugina arendamine: õppetunnid ja kogemused

Tere kõigile! Mõned kuud tagasi käivitasime tootmises meie uue avatud lähtekoodiga projekti — Grafana plugina Kubernetes'i jälgimiseks, mille nimeks saime DevOpsProdigy KubeGraf. Plugina lähtekood on saadaval avalikus GitHub'i hoidlas. Ja selles artiklis tahame jagada teiega lugu sellest, kuidas me plugina loomisega alustasime, milliseid tööriistu kasutasime ja milliste takistustega silmitsi seisisime arenduse käigus. Alustame!

Osa 0 — sissejuhatus: kuidas me siia jõudsime?

Mõte kirjutada omaenda plugin Grafanale tekkis meile täiesti juhuslikult. Meie ettevõte on enam kui 10 aastat tegelenud erineva keerukusega veebiprojektide jälgimisega. Selle aja jooksul oleme kogunud suure hulga teadmisi, huvitavaid juhtumeid ja kogemusi erinevate jälgimissüsteemide kasutamisest. Ja mingil hetkel küsisime endalt: „Kas on olemas maagiline tööriist Kubernetes'i jälgimiseks, et nagu öeldakse, „paned paika ja unustad”?..“ Kubernetes'i jälgimise valdkonna standardiks on juba ammu olnud kombinatsioon Prometheus + Grafana. Ja selle tehnoloogiapaki jaoks on olemas suur hulk erinevaid tööriistu: prometheus-operator, kubernetes-mixin paneelide kogum, grafana-kubernetes-app.

Meile näis kõige huvitavam valik olevat grafana-kubernetes-app plugin, kuid see ei ole enam üle aasta toetust saanud ning lisaks ei oska see töötada uusimate versioonide node-exporter'i ja kube-state-metrics'iga. Ja mingil hetkel otsustasime: „Äkki ei tee me oma lahendust?”

Milliseid ideid otsustasime oma plugina realiseerida:

• rakenduse kaardi visualiseerimine: mugav rakenduste esitus klastris, rühmitatuna namespace'ide, deployment'ite kaupa…;
• suhete visualiseerimine tüüpi „deployment — teenus (+portid)”.
• klastri rakenduste jaotumise visualiseerimine klastris olevate nod'i vahel.
• metriikide ja teabe kogumine mitmest allikast: Prometheus ja Kubernetes'i API server.
• infrastruktuuri jälgimine (protsessoriaja, mälu, kõvakettateenuse ja võrgu kasutamine), samuti rakenduste loogika jälgimine — pod'ide tervisestatus, saadaval olevate koopiate arv, teave liveness/readyness testide läbimise kohta.

Osa 1: Mis on „Grafana plugin“?

Tehnilisest vaatenurgast on Grafana plugin Angulari kontrollija, mis salvestatakse Grafana data katalooge./var/grafana/plugins/<your_plugin_name>/dist/module.js) ja võib laadida SystemJS-modulina. Samuti peab selle katalooge olema fail plugin.json, mis sisaldab kogu teavet teie plugina kohta: nimi, versioon, plugina tüüp, lingid hoidla/sait/ litsents, sõltuvused ja nii edasi.

module.ts

plugin.json

Nagu näha ekraanipildilt, oleme määranud plugin.type = app. Grafana pluginaid on kolm tüüpi:

paneel: kõige levinum plugina tüüp — esindab paneeli, mis visualiseerib teatud mõõdikuid, kasutatakse erinevate armatuurlaudade loomiseks.
andmeallika: andmeallika konnektor (näiteks Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource).
app: plugin, mis võimaldab teil luua oma frontendi rakenduse Grafanas, luua oma html-lehti ja manuaalselt pöörduda andmeallika poole, et visualiseerida erinevaid andmeid. Samuti võivad sõltuvustena kasutada muid plugina tüüpe (andmeallikas, paneel) ja erinevaid armatuurlaudu.

Näide plugina sõltuvustest tüübi = app kohta.

Programmeerimiskeelena saab kasutada nii JavaScripti kui ka TypeScripti (me oleme valinud viimase). Valmistooted hello-world pluginate jaoks igasugustes tüüpidest leiate ühenduse kaudu: see hoidla sisaldab suurt hulka starter-pack'e (sealhulgas eksperimenteerimiste näolu plugina React'i peal) koos eelinstallitud ja konfigureeritud kogumikega.

Osa 2: kohaliku keskkonna ettevalmistamine

Plugina arendamiseks on meil loomulikult vaja kubernetes klastri kõigi eelkohustuslike tööriistadega: prometheus, node-exporter, kube-state-metrics, grafana. Keskkond peab olema seadistatav kiiresti, kergelt ja vaevata, ja hot-reload andmete kausta jaoks peab Grafana kaust olema otseselt arendaja masinast mähitud.

Meie arvates on kubernetes'ega kohalikuks tööks kõige mugavam minikube. Järgmine samm on installida Prometheus + Grafana koos prometheus-operatoriga. Käesolevas selles artiklis on üksikasjalikult kirjeldatud prometheus-operatori installimise protsessi minikube'is. Püsivuse sisselülitamiseks on vajalik seadistada parameeter persistence: true charts/grafana/values.yaml failis, lisada oma PV ja PVC ning määrata need parameetrisse persistence.existingClaim

Meie lõplik minikube'i käivitamisskript näeb välja järgmine:

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

Osa 3: arendamine

Objektimudel

Plugin'i rakendamise ettevalmistamiseks otsustasime kirjeldada kõiki põhielemente Kubernetes'is, millega me töötame, TypeScript'i klassidena: pod, deployment, daemonset, statefulset, job, cronjob, service, node, namespace. Igaüks neist klassidest pärib üldklassist BaseModel, milles on kirjeldatud konstruktor, destruktor, meetodid uuendamiseks ja nähtavuse vahetamiseks. Igas klassis on kirjeldatud ka sisemised suhted teiste elementidega, näiteks deployment'i tüüpi elemendi pod'id.

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

export class Deployment extends BaseModel {
   pods: Array;
   services: Array;

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

Getter'ite ja setter'ite abil saame välja tuua või seada meile vajalikud metrikad elementide mõistetaval ja loetaval kujul. Näiteks vormindatud väljund allocatable cpu nod'ist:

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

Lehed

Meie plugin'i kõigi lehtede nimekiri on algselt kirjeldatud meie pluing.json failis sõltuvuste osas:

Iga lehe jaoks peame määrama LEHE NIME (mille abil see leht hiljem slug'iks konvertitakse); komponendi nime, mis vastutab selle lehe töö eest (komponentide nimekiri eksporditakse module.ts); kasutaja rolli, kellele on see leht ja sidumise seaded saadaval, ning navigatsiooni seadistused külgriba jaoks.

Komponendis, mis vastutab lehe töö eest, peame seadma templateUrl, edastades sinna html-faili tee, kus on mark-up. Kontrollija sees saame sõltuvuse sisestamise kaudu juurdepääsu kahele olulisele angular-teenusele:

• backendSrv — teenus, mis tagab suhtluse grafana api-serveriga;
• datasourceSrv — teenus, mis tagab kohapealse suhtluse kõigi sinu Grafanas installitud andmeallikatega (näiteks meetod .getAll() — tagastab nimekirja kõigist installitud andmeallikatest; .get() — tagastab konkreetse andmeallika objekti-instandi.

Osa 4: andmeallikas

Grafana vaatepunktist on datasource täpselt sama tüüpi plugin nagu kõik teised: sellel on oma sisenemispunkt module.js ja metaandmete fail plugin.json. Kui arendame pluginat tüübiga app, saame suhelda nii olemasolevate datasource'idega (näiteks prometheus-datasource) kui ka omaenda, mida saame hoida otse pluginakataloogis (dist/datasource/*) või paigaldada sõltuvusena. Meie puhul tarnitakse datasource koos pluginakoodiga. Samuti on vajalik config.html mall ja ConfigCtrl kontrollija, mida kasutatakse datasource'i eksemplari konfigureerimise lehel ja Datasource kontrollija jaoks, kus on teostatud teie datasource'i tööd loogika.

Pluginas KubeGraf, kasutajaliidese vaatenurgast, esindab datasource kubernetes-klastri eksemplari, kus on rakendatud järgmised võimalused (allikakood on saadaval linki pidi):

• andmete kogumine k8s api-server'ist (namespace'ide, deployment'ide jne. loendi saamine)
• päringute edastamine prometheus-datasource'ile (mis valitakse pluginaseadetes iga konkreetse klastrite jaoks) ja vastuste vormindamine andmete kasutamiseks nii staatilistes lehtedes kui ka armatuurlaudadel.
• andmete värskendamine pluginas staatilistes lehtedes (kehtiva värskendussagedusega).
• päringute töötlemine template-loendi koostamiseks grafana-dashboards (meetod .metriFindQuery())

• ühenduse testimine lõpliku k8s-klastriga.

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: "Andmeallikas on korras", title: "Edu"};
           }else{
               return {status: "error", message: "Andmeallikas ei ole korras", title: "Viga"};
           }
       }, error => {
           return {status: "error", message: "Andmeallikas ei ole korras", title: "Viga"};
       })
}

Meie arvates on eriliselt huvitav aspekt andmeallika autentimise ja autoriseerimise mehhanismi rakendamine. Tavaliselt saame me hõlpsasti kasutada Grafana sisseehitatud komponenti — datasourceHttpSettings, et konfigureerida juurdepääsu lõpp-andmeallikale. Selle komponendi abil saame seada http-andmeallika päringu, märkides url ja põhiseaded autentimise/autoriseerimise jaoks: kasutajanimi-parool või client-cert/client-key. Selleks, et rakendada juurdepääsu seadistamise võimalust bearer-tokeniga (de facto standard k8s jaoks), pidime natuke „kemplema”.

Selle probleemi lahendamiseks saab kasutada Grafana sisseehitatud mehhanismi „Plugin Routes” (lisainfo ametlikult dokumentatsioonilehel). Meie andmeallika seadetes saame määratleda reeglite kogumi, mida grafana proxy-server töötleb. Näiteks iga eraldi endpoint'i jaoks on võimalik määrata pealkirju või url-e, kasutades mallide loomise võimalust, mille andmed võivad tulla jsonData ja secureJsonData (salajaste andmete või tokenite krüptitud kujul hoidmiseks) väliidest. Meie näites on päringud, mis näevad välja /__proxy/api/v1/namespaces proksitud url-ile, mis näeb välja
/api/v1/namespaces, kus on määratud pealkiri Authorization: Bearer.

Muidugi, et töötada k8s api-serveriga, vajame me kasutajat koos readonly juurdepääsuga, mille loomiseks mõeldud manifestid on samuti saadaval plugin-koodi all.

Osa 5: väljaanne

Pärast oma Grafana plugina kirjutamist saate loomulikult soovida seda avatud kasutada. Grafanas on pluginate teek, mis on saadaval aadressil grafana.com/grafana/plugins

Kuna teie plugin oleks ametlikus poes nähtav, peate tegema PR seda repot, lisades failisse repo.json järgmise sisu:

kus version — teie plugina versioon, url — link repole ja commit — commit'i hash, mille alusel konkreetne plugina versioon on saadaval.

Ja lõpptulemuseks on imeline pilt:

Andmed selle jaoks saavad automaatselt läbi vaadatavaks teie Readme.md, Changelog.md ja plugin.json failist, mis kirjeldab plugina.

Osa 6: järeldused

Me ei ole pärast litsentsi väljaandmist oma pistikprogrammi arendust peatatud. Praegu töötame mõistliku klastrinoodide ressursside jälgimise, uusi funktsioonide rakendamise UX parandamiseks ja suurte tagasisidehulga töötlemise kallal, mida oleme saanud pistikprogrammi installimise käigus nii oma klientidelt kui ka GitHubi probleemide kaudu (kui jätate oma probleemide või pull request'i, olen väga õnnelik 🙂).

Loodame, et see artikkel aitab teil mõista suurepärast tööriista nagu Grafana ning võib-olla kirjutada omaenda pistikprogrammi.

Aitäh! )

Allikas: habr.com