Utveckling av ett plugin för Grafana: en historia av stora skott

Hej allihopa! För några månader sedan lanserade vi vårt nya open source-projekt i produktion - ett Grafana-plugin för övervakning av Kubernetes, som vi kallade DevOpsProdigy KubeGrafKällkoden för plugin-programmet finns tillgänglig i offentligt arkiv på GitHubOch i den här artikeln vill vi dela med oss ​​av historien om hur vi skapade pluginet, vilka verktyg vi använde och vilka fallgropar vi stötte på under utvecklingsprocessen. Nu kör vi!

Del 0 - Introduktion: Hur hamnade vi här?

Idén att skriva vårt eget plugin för Grafana kom till oss helt av en slump. Vårt företag har övervakat webbprojekt av varierande komplexitet i över 10 år. Under denna tid har vi samlat på oss en mängd expertis, intressanta fall och erfarenhet av att använda olika övervakningssystem. Och vid någon tidpunkt frågade vi oss själva: "Finns det ett magiskt verktyg för att övervaka Kubernetes som man, som man säger, kan "ställa in och glömma"?" Naturligtvis har Prometheus + Grafana-paketet länge varit branschstandarden för att övervaka K8S. Och som färdiga lösningar för denna stack finns en stor uppsättning olika verktyg: prometheus-operator, en uppsättning dashboards kubernetes-mixin, grafana-kubernetes-app.

Det mest intressanta alternativet för oss verkade vara grafana-kubernetes-app-pluginet, men det har inte stödts på över ett år och dessutom kan det inte fungera med nya versioner av node-exporter och kube-state-metrics. Och vid någon tidpunkt bestämde vi oss: "Varför inte skapa vår egen lösning?"

Vilka idéer bestämde vi oss för att implementera i vårt plugin:

• visualisering av "applikationskartan": en bekväm representation av applikationer i ett kluster, grupperade efter namnrymder, distributioner etc.;
• visualisering av anslutningar av typen "distribution - tjänst (+portar)".
• visualisering av distributionen av klusterapplikationer över klusternoder.
• samlar in mätvärden och information från flera källor: Prometheus och K8s API-server.
• övervakning av både infrastrukturdelen (användning av processortid, minne, diskundersystem, nätverk) och applikationslogik - hälsostatus för poddar, antal tillgängliga repliker, information om genomförande av liveness-/beredskapstester.

Del 1: Vad är ett "Grafana-plugin"?

Tekniskt sett är ett Grafana-plugin en vinkelkontroller som lagras i Grafanas datakatalog (/var/grafana/plugins/ /dist/module.js) och kan laddas som en SystemJS-modul. I den här katalogen bör det också finnas en fil plugin.json, som innehåller all metainformation om ditt plugin: namn, version, plugin-typ, länkar till repository/site/licens, beroenden etc.

modul.ts

plugin.json

Som du kan se på skärmdumpen angav vi plugin.type = app. Eftersom plugins för Grafana kan vara av tre typer:

panel: den vanligaste typen av plugin - är en panel för att visualisera vissa mätvärden, som används för att bygga olika dashboards.
datakällaen plugin-koppling till någon datakälla (till exempel Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource).
app: ett plugin som låter dig bygga din egen frontend-applikation i Grafana, skapa dina egna html-sidor och manuellt komma åt datakällan för att visualisera olika data. Andra typer av plugins (datakälla, panel) och olika dashboards kan också användas som beroenden.

Exempel på plugin-beroenden med type = app.

Du kan använda antingen JavaScript eller TypeScript som programmeringsspråk (vi valde det). Du kan hitta mallar för hello-world-plugins av alla typer hitta via länkDetta repository innehåller ett stort antal startpaket (det finns till och med ett experimentellt exempel på ett plugin på React) med förinstallerade och konfigurerade bundlers.

Del 2: Förbereda den lokala miljön

För att arbeta med pluginet behöver vi naturligtvis ett Kubernetes-kluster med alla förinstallerade verktyg: prometheus, node-exporter, kube-state-metrics, grafana. Miljön bör konfigureras snabbt, enkelt och smidigt, och för att säkerställa snabb återladdning bör Grafana-datakatalogen monteras direkt från utvecklarens maskin.

Enligt vår mening är det enklaste sättet att arbeta lokalt med Kubernetes minikubeNästa steg är att installera Prometheus + Grafana-paketet med hjälp av prometheus-operator. Denna artikel Processen för att installera prometheus-operator på minikube beskrivs i detalj. För att aktivera persistens måste du ställa in parametern uthållighet: sant I filen charts/grafana/values.yaml, lägg till din egen PV och PVC och ange dem i parametern persistence.existingClaim.

Vårt slutgiltiga lanseringsskript 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 inför plugin-implementeringen bestämde vi oss för att beskriva alla grundläggande Kubernetes-entiteter som vi kommer att arbeta med som TypeScript-klasser: pod, deployment, daemonset, statefulset, job, cronjob, service, node, namespace. Var och en av dessa klasser ärvs från den gemensamma BaseModel-klassen, som beskriver konstruktorn, destruktorn, metoder för att uppdatera och byta synlighet. Var och en av klasserna beskriver kapslade relationer med andra entiteter, till exempel en lista över poddar för en entitet av deployment-typen.

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

Med hjälp av getters och setters kan vi mata ut eller ställa in de entitetsmått vi behöver i en bekväm och läsbar form. Till exempel, den formaterade utdata från allokerbara CPU-noder:

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årt plugin beskrivs initialt i vår pluing.json i avsnittet om beroenden:

I blocket för varje sida måste vi ange SIDENAMNET (det kommer då att konverteras till en slug genom vilken sidan blir tillgänglig); namnet på komponenten som ansvarar för driften av denna sida (listan över komponenter exporteras till module.ts); indikation av användarrollen för vilken arbete med denna sida är tillgängligt och navigeringsinställningar för sidofältet.

I komponenten som ansvarar för sidan måste vi ställa in templateUrl och skicka dit sökvägen till html-filen med markupen. Inuti kontrollenheten kan vi, genom dependency injection, få tillgång till två viktiga Angular-tjänster:

• backendSrv är en tjänst som tillhandahåller interaktion med grafanas API-server;
• datasourceSrv — en tjänst som tillhandahåller lokal interaktion med alla datakällor som är installerade i din Grafana (till exempel returnerar metoden .getAll() en lista över alla installerade datakällor; .get() ) - returnerar ett instansobjekt för en specifik datakälla.

Del 4: datakälla

Ur Grafanas synvinkel är datasource exakt samma plugin som alla andra: det har sin egen entry point module.js, det finns en fil med metainformation plugin.json. När vi utvecklar ett plugin med typen = app kan vi interagera med både befintliga datakällor (till exempel prometheus-datasource) och våra egna, som vi kan lagra direkt i plugin-katalogen (dist/datasource/*) eller installera som ett beroende. I vårt fall levereras datasourcen med plugin-koden. Dessutom krävs config.html-mallen och ConfigCtrl-kontrollanten, som kommer att användas för konfigurationssidan för datasource-instansen och Datasource-kontrollanten, som implementerar logiken för din datasource.

I KubeGraf-pluginet är en datakälla, ur användargränssnittsperspektiv, en instans av ett Kubernetes-kluster som implementerar följande funktioner (källkod tillgänglig по ссылке):

• hämtar data från k8s api-server (hämtar en lista över namnrymder, distributioner...)
• proxyförfrågningar till prometheus-datasource (som väljs i plugin-inställningarna för varje specifikt kluster) och formatering av svar för att använda data både på statiska sidor och i dashboards.
• uppdaterar data på statiska sidor i plugin-programmet (med den inställda uppdateringsfrekvenstiden).
• bearbetar frågor för att generera ett mallark i grafana-dashboards (metod .metriFindQuery())

• testanslutning med det slutliga 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"};
       })
}

En separat intressant punkt, enligt vår mening, är implementeringen av autentiserings- och auktoriseringsmekanismen för datakällan. Som regel kan vi, direkt ur lådan, använda den inbyggda Grafana-komponenten — datasourceHttpSettings. Med den här komponenten kan vi konfigurera åtkomst till http-datakällan genom att ange url:en och grundläggande autentiserings-/auktoriseringsinställningar: login-password eller client-cert/client-key. För att implementera möjligheten att konfigurera åtkomst med en bearer-token (de facto-standarden för k8s) var vi tvungna att "fuska" lite.

För att lösa detta problem kan du använda den inbyggda Grafana-mekanismen "Plugin Routes" (mer information finns på officiell dokumentationssidaI inställningarna för vår datakälla kan vi deklarera en uppsättning routingregler som kommer att bearbetas av grafana-proxyservern. Till exempel, för varje enskild slutpunkt finns det möjlighet att ange rubriker eller URL med möjlighet att skapa mallar, 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 är förfrågningar av typen /__proxy/api/v1/namnrymder kommer att skickas via proxy till webbadresser av formen
/api/v8/namnrymder med headern Authorization: Bearer uppsatt.

Naturligtvis behöver vi en användare med skrivskyddad åtkomst för att arbeta med k8s API-server, manifesten för att skapa dessa finns också i plugin-källkod.

Del 5: Släpp

När du väl har skrivit ditt eget Grafana-plugin vill du naturligtvis göra det med öppen källkod. I Grafana är detta ett plugin-bibliotek, tillgängligt på grafana.com/grafana/plugins

För att ditt plugin ska vara tillgängligt i den officiella butiken måste du göra en PR i detta förråd, lägger till innehåll som detta i repo.json-filen:

där version är versionen av ditt plugin, url är länken till arkivet och commit är hashen för den commit som gör den specifika versionen av pluginet tillgänglig.

Och vid utgången ser du en underbar bild som denna:

Data för den hämtas automatiskt från dina Readme.md-, Changelog.md- och plugin.json-filer med plugin-beskrivningen.

Del 6: Istället för slutsatser

Vi har inte slutat utveckla vårt plugin efter lanseringen. Och nu arbetar vi med korrekt övervakning av resursanvändningen för klusternoder, implementerar nya funktioner för att förbättra användarupplevelsen och bearbetar även en stor mängd feedback som vi fått efter plugininstallationer, både från våra kunder och från förfrågningar på GitHub (om ni lämnar ert ärende eller pull request blir jag väldigt glad 🙂).

Vi hoppas att den här artikeln hjälper dig att förstå ett så fantastiskt verktyg som Grafana och kanske skriva ditt eget plugin.

Tack!)

Källa: will.com