Utveckling av plugin för Grafana: en historia av samlade erfarenheter

Hej alla! För några månader sedan lanserade vi vårt nya open-source projekt i produktion — en Grafana-plugin för övervakning av Kubernetes, som vi har döpt till DevOpsProdigy KubeGraf. Källkoden för pluginet finns tillgänglig i ett offentligt arkiv på GitHub. I den här artikeln vill vi dela med er historien om hur vi skapade pluginet, vilka verktyg vi använde och vilka hinder vi stötte på under utvecklingen. Låt oss börja!

Del 0 — introduktion: hur kom vi dit?

Idén att skriva vår egen plugin för Grafana föddes av en slump. Vårt företag har arbetat med övervakning av webbprojekt i olika komplexitetsnivåer i över 10 år. Under denna tid har vi samlat på oss mycket expertis, intressanta fallstudier och erfarenheter av att använda olika övervakningssystem. Vid något tillfälle ställde vi oss frågan: "Finns det ett magiskt verktyg för att övervaka Kubernetes, så att man kan 'installera och glömma'"?.. Standardlösningen för att övervaka k8s är naturligtvis sedan länge en kombination av Prometheus + Grafana. Och det finns en mängd olika verktyg som erbjuder färdiga lösningar för denna teknikstack: prometheus-operator, en uppsättning dashboards från kubernetes-mixin, grafana-kubernetes-app.

Det mest intressanta alternativet för oss verkade vara pluginet grafana-kubernetes-app, men det har inte underhållits på över ett år och dessutom fungerar det inte med de nya versionerna av node-exporter och kube-state-metrics. Vid något tillfälle beslutade vi: "Varför inte göra vår egen lösning?"

Vilka idéer beslutade vi oss för att genomföra i vårt plugin:

• visualisering av "applikationskartan": en användarvänlig representation av applikationer i klustret, grupperade efter namespaces, deployments…;
• visualisering av relationer som "deployment — service (+ports)".
• visualisering av distributionen av klustrets applikationer över noderna i klustret.
• insamling av metrik och information från flera källor: Prometheus och k8s API-server.
• övervakning av både infrastrukturdelarna (användning av processor, minne, lagringssystem, nätverk) och applikationernas logik — hälsostatus för pods, antal tillgängliga repliker, information om genomförande av liveness/readiness-checkar.

Del 1: Vad är en "plugin för Grafana"?

Ur ett tekniskt perspektiv är en plugin för Grafana en Angular-kontroller som lagras i data-katalogen för Grafana (/var/grafana/plugins/<your_plugin_name>/dist/module.js) och kan laddas som ett SystemJS-modul. I denna katalog bör det också finnas en fil plugin.json som innehåller all metadata om din plugin: namn, version, typ av plugin, länkar till repository/sajt/licens, beroenden och så vidare.

module.ts

plugin.json

Som visas i skärmdumpen har vi angett plugin.type = app. Plugins för Grafana kan vara av tre typer:

panel: den vanligaste typen av plugin — representerar en panel för visualisering av olika metrik, används för att bygga olika dashboards.
datasource: plugin-anslutning till en datakälla (till exempel Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource).
app: ett plugin som låter dig bygga din egen frontend-applikation inom Grafana, skapa dina egna html-sidor och manuellt göra anslutningar till datakällor för att visualisera olika data. Andra typer av plugins (datasource, panel) och olika dashboards kan också användas som beroenden.

Exempel på beroenden för plugin med type = app.

Som programmeringsspråk kan både JavaScript och TypeScript användas (vi valde det senare). Mallar för hello-world plugins av alla typer kan hittas via länken: i detta repository finns ett stort antal starter-paket (det finns till och med ett experimentellt exempel på en plugin i React) med förinstallerade och konfigurerade byggverktyg.

Del 2: förberedelse av den lokala miljön

För att arbeta med pluginet behöver vi naturligtvis en Kubernetes-kluster med alla förinstallerade verktyg: prometheus, node-exporter, kube-state-metrics, grafana. Miljön bör sättas upp snabbt, enkelt och utan problem, och för att säkerställa hot-reload bör datakatalogen för Grafana monteras direkt från utvecklarens maskin.

Det mest bekväma sättet att arbeta lokalt med Kubernetes, enligt vår mening, är minikube. Nästa steg är att installera Prometheus + Grafana med hjälp av prometheus-operator. I denna artikel beskrivs installationsprocessen för prometheus-operator på minikube i detalj. För att aktivera persistens måste parametern persistence: true i filen charts/grafana/values.yaml, lösa din egen PV och PVC och ange dem i parameter persistence.existingClaim

Det slutgiltiga startskriptet för minikube ser ut så här:

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

Del 3: direkt utveckling

Objektmodell

Som förberedelse för att implementera pluginen har vi beslutat att beskriva alla grundläggande entiteter i Kubernetes som vi kommer att arbeta med i form av TypeScript-klasser: pod, deployment, daemonset, statefulset, job, cronjob, service, node, namespace. Varje klass ärver från en gemensam klass BaseModel, där konstruktör, destruktör, metoder för uppdatering och visningsväxling beskrivs. I varje klass beskrivs inbäddade relationer med andra entiteter, till exempel listan över poddar i en deployment-entitet.

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 = [];
   }
}

Med hjälp av getters och setters kan vi visa eller ställa in de mätvärden för entiteter vi behöver på ett bekvämt och läsbart sätt. Till exempel, formaterad utmatning av allocatable cpu för noden:

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

Sidor

Listan över alla sidor i vår plugin beskrivs ursprungligen i vår pluing.json i avsnittet för beroenden:

I blocket för varje sida måste vi ange SIDNAMN (det kommer sedan att konverteras till slug, vilket är hur denna sida kommer att vara tillgänglig); namnet på komponenten som ansvarar för funktionen på denna sida (listan över komponenter exporteras i module.ts); ange vilken användarroll som har tillgång till att arbeta med denna sida och inställningarna för navigation i sidopanelen.

I komponenten som ansvarar för sidan måste vi ställa in templateUrl och ange sökvägen till html-filen med markup. Inom controllern, genom dependency injection, kan vi få tillgång till 2 viktiga Angular-tjänster:

• backendSrv — tjänsten som möjliggör interaktion med api-servern för Grafana;
• datasourceSrv — tjänsten som möjliggör lokal interaktion med alla datakällor som är installerade i din Grafana (till exempel, metoden .getAll() — returnerar en lista över alla installerade datakällor; .get() — returnerar objektinstansen av en specifik datakälla.

Del 4: datakälla

Från Grafanas perspektiv representerar en datasourc exakt samma typ av plugin som alla andra: den har en ingångspunkt module.js och en fil med metadata plugin.json. När vi utvecklar ett plugin med typ = app kan vi interagera både med befintliga datasourcer (till exempel prometheus-datasource) och med egna som vi kan lagra direkt i pluginets katalog (dist/datasource/*) eller installera som beroende. I vårt fall levereras datasourcen tillsammans med pluginets kod. Det är också nödvändigt att ha en mall config.html och kontrollern ConfigCtrl, som kommer att användas för konfigureringssidan av datasourc-exemplaret och kontrollern Datasource, där logiken för din datasources funktionalitet implementeras.

I KubeGraf-pluginet, från användargränssnittets perspektiv, representerar en datasourc ett exempel på en Kubernetes-kluster, där följande funktioner är implementerade (källkoden är tillgänglig via länken):

• hämtning av data från k8s api-server (hämtning av listor över namespaces, deployments…)
• proxying av förfrågningar till prometheus-datasource (som väljs i plugininställningarna för varje specifikt kluster) och formatering av svar för att använda data både på statiska sidor och i dashboards.
• uppdatering av data på statiska sidor i pluginet (med inställd uppdateringsfrekvens).
• bearbetning av förfrågningar för att skapa template-listor i grafana-dashboards (metod .metriFindQuery())

• test av anslutning till den slutgiltiga k8s-klustret.

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"};
       })
}

Enligt vår åsikt är en intressant aspekt implementeringen av autentisering och auktorisering för datasource. Vanligtvis kan vi använda den inbyggda komponenten datasourceHttpSettings i Grafana för att konfigurera åtkomst till den slutliga datakällan. Med denna komponent kan vi ställa in åtkomst till http-datakällan genom att ange URL och grundläggande autentisering/Auktorisering: användarnamn-lösenord, eller client-cert/client-key. För att möjliggöra åtkomstkonfiguration med ett bearer-token (de facto-standarden för k8s) var vi tvungna att göra lite "magik".

För att lösa detta problem kan den inbyggda mekanismen "Plugin Routes" i Grafana användas (mer information finns på den officiella dokumentationssidan). I inställningarna för vår datasource kan vi deklarera en uppsättning routingregler som kommer att hanteras av grafana proxy-servern. Till exempel finns det för varje separat endpoint möjlighet att ange rubriker eller URL med templatering, vars data kan hämtas från fälten jsonData och secureJsonData (för att lagra lösenord eller tokens i krypterad form). I vårt exempel kommer förfrågningar av typen /__proxy/api/v1/namespaces att proxas till URL av typen
/api/v1/namespaces med att rubriken Authorization: Bearer anger.

Självklart behöver vi en användare med readonly åtkomst för att arbeta med k8s api-servern, och manifest för att skapa den kan du också hitta i pluginens källkod.

Del 5: release

Efter att du har skrivit din egen plugin för Grafana kommer du självklart vilja publicera den offentligt. I Grafana finns det ett pluginbibliotek som är tillgängligt via länken grafana.com/grafana/plugins

För att din plugin ska vara tillgänglig i den officiella butiken måste du göra en PR i detta repository, genom att lägga till innehållet av typen i filen repo.json:

där version - versionen av din plugin, url - länk till ditt repository, och commit - hash för den commit som den specifika versionen av pluginen kommer att vara tillgänglig.

Och till slut kommer du att se en underbar bild av typen:

Data för den kommer automatiskt att samlas in från din Readme.md, Changelog.md och plugin.json-filens beskrivning av pluginen.

Del 6: sammanfattning

Vi har inte slutat utveckla vår plugin efter lanseringen. Just nu arbetar vi med korrekt övervakning av resursanvändningen av noderna i klustret, införandet av nya funktioner för att förbättra användarupplevelsen samt att bearbeta mängder av feedback som vi har fått efter installationer av pluginet, både från våra kunder och genom issues på GitHub (om du lämnar en issue eller pull request blir jag mycket glad 🙂 ).

Vi hoppas att denna artikel hjälper dig att förstå det fantastiska verktyget Grafana och kanske skriva din egen plugin.

Tack!)

Källa: habr.com