Разработка на добавки за Grafana: историята на пълнените конуси

Здравейте всички! Преди няколко месеца стартирахме нашия нов проект с отворен код в производство - Grafana-plugin за наблюдение на kubernetes, който нарекохме DevOpsProdigy KubeGraf. Изходният код на приставката е достъпен на публично хранилище в GitHub. И в тази статия искаме да споделим с вас историята за това как създадохме плъгина, какви инструменти използвахме и какви капани срещнахме в процеса на разработка. Да тръгваме!

Част 0 - въведение: как стигнахме дотук?

Идеята да напишем собствен плъгин за Grafan се роди съвсем случайно. Нашата компания наблюдава уеб проекти с различни нива на сложност повече от 10 години. През това време натрупахме много експертиза, интересни казуси и опит в използването на различни системи за мониторинг. И в един момент се запитахме: „Има ли магически инструмент за наблюдение на Kubernetes, така че, както се казва, „настройте го и го забравете“?“ И като готови решения за този стек има голям набор от различни видове инструменти: prometheus-operator, набор от табла за управление kubernetes-mixin, grafana-kubernetes-app.

Приставката за grafana-kubernetes-app изглеждаше най-интересната опция за нас, но тя не се поддържа повече от година и освен това не знае как да работи с новите версии на node-exporter и kube-state- метрика. И в един момент решихме: „Не трябва ли сами да вземем решение?“

Какви идеи решихме да приложим в нашия плъгин:

• визуализация на „карта на приложенията“: удобно представяне на приложения в клъстер, групирани по пространства от имена, внедрявания…;
• визуализация на връзки като "разгръщане - услуга (+портове)".
• визуализация на разпределението на клъстерните приложения по клъстерни възли.
• колекция от показатели и информация от няколко източника: Prometheus и k8s api сървър.
• следене както на инфраструктурната част (използване на процесорно време, памет, дискова подсистема, мрежа), така и на логиката на приложението - здравния статус на pods, броя на наличните реплики, информация за преминаването на сонди за живост/готовност.

Част 1: Какво е "плъгин за Grafana"?

От техническа гледна точка плъгинът за Grafana е ъглов контролер, който се съхранява в директорията с данни на Grafana (/var/grafana/plugins/ /dist/module.js) и може да се зареди като SystemJS модул. Също така в тази директория трябва да има файл plugin.json, съдържащ цялата мета информация за вашия плъгин: име, версия, тип на плъгина, връзки към хранилището/сайта/лиценза, зависимости и т.н.

module.ts

plugin.json

Както можете да видите на екранната снимка, сме посочили plugin.type = app. Приставките за Grafana могат да бъдат три вида:

панел: най-често срещаният тип добавки - представлява панел за визуализиране на всякакви метрики, използван за изграждане на различни табла за управление.
източник на данни: съединител за добавки към всеки източник на данни (например Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource).
ап: Плъгин, който ви позволява да изградите свое собствено приложение за преден край в Grafana, да създадете свои собствени html страници и да получите ръчен достъп до източника на данни, за да изобразите различни данни. Приставки от друг тип (източник на данни, панел) и различни табла за управление също могат да се използват като зависимости.

Примерни зависимости на плъгини с type = app.

Като език за програмиране можете да използвате както JavaScript, така и TypeScript (ние го избрахме). Можете да създавате шаблони за плъгини hello-world от всякакъв тип намери чрез връзка: това хранилище съдържа голям брой стартови пакети (има дори експериментален пример за React плъгин) с предварително инсталирани и конфигурирани създатели.

Част 2: подготовка на местната среда

За да работим върху плъгина, разбира се, имаме нужда от kubernetes клъстер с всички предварително инсталирани инструменти: prometheus, node-exporter, kube-state-metrics, grafana. Средата трябва да се настройва бързо, лесно и естествено и за да се осигури горещо презареждане, директорията с данни на Grafana трябва да се монтира директно от машината на разработчика.

Най-удобният според нас начин за локална работа с kubernetes е minikube. Следващата стъпка е да инсталирате пакета Prometheus + Grafana с помощта на prometheus-operator. IN тази статия процесът на инсталиране на prometheus-operator на minikube е описан подробно. За да активирате постоянството, трябва да зададете параметъра постоянство: вярно във файла charts/grafana/values.yaml добавете свои собствени PV и PVC и ги посочете в параметъра persistence.existingClaim

Крайният скрипт за стартиране на 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: директно развитие

Обектен модел

Като подготовка за внедряването на плъгина решихме да опишем всички основни обекти на 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 = [];
   }
}

С помощта на гетери и сетери можем да покажем или зададем нужните ни показатели на обекта в удобна и четима форма. Например форматираният изход на разпределяемите процесори кимва:

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

Pages

Списъкът с всички страници на нашия плъгин първоначално е описан в нашия pluing.json в раздела за зависимости:

В блока за всяка страница трябва да посочим ИМЕТО НА СТРАНИЦАТА (тогава ще бъде преобразувано в slug, чрез който тази страница ще бъде достъпна); името на компонента, отговорен за работата на тази страница (списъкът с компоненти се експортира в module.ts); указване на потребителската роля, за която е налична работа с тази страница и настройки за навигация за страничната лента.

В компонента, отговарящ за страницата, трябва да зададем templateUrl, като подадем пътя до html файла с маркирането там. Вътре в контролера, чрез инжектиране на зависимости, можем да получим достъп до 2 важни ъглови услуги:

• backendSrv - услуга, която осигурява взаимодействие с grafana api-сървъра;
• datasourceSrv – услуга, която осигурява локално взаимодействие с всички източници на данни, инсталирани във вашата Grafana (например методът .getAll() – връща списък с всички инсталирани източници на данни; .get( ) - връща обект на екземпляр на конкретен източник на данни.

Част 4: източник на данни

От гледна точка на Grafana, източникът на данни е абсолютно същият плъгин като всички останали: има своя собствена входна точка module.js, има файл plugin.json с мета информация. Когато разработваме плъгин с тип = приложение, можем да взаимодействаме както със съществуващи източници на данни (например prometheus-datasource), така и с нашите собствени, които можем да съхраняваме директно в директорията на плъгина (dist/datasource/*) или да инсталираме като зависимост . В нашия случай източникът на данни идва с кода на приставката. Също така е необходимо да имате шаблон config.html и контролер ConfigCtrl, който ще се използва за конфигурационната страница на екземпляра на източника на данни и контролер на източник на данни, който прилага логиката на вашия източник на данни.

В приставката KubeGraf, от гледна точка на потребителския интерфейс, източникът на данни е екземпляр на клъстер kubernetes, който прилага следните функции (изходният код е наличен по ссылке):

• извличане на данни от k8s api-сървър (получаване на списък с пространства от имена, внедрявания...)
• прокси заявки към prometheus-datasource (който е избран в настройките на плъгина за всеки конкретен клъстер) и форматиране на отговорите за използване на данни както в статични страници, така и в табла за управление.
• актуализиране на данни на статични страници на плъгина (със зададено време за честота на опресняване).
• обработване на заявки за формиране на шаблонен лист в grafana-dashboards (метод .metriFindQuery())

• тест за свързване с последния 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 - datasourceHttpSettings. Използвайки този компонент, можем да конфигурираме достъпа до http източника на данни, като посочим url и основни настройки за удостоверяване/упълномощаване: парола за влизане или клиентски сертификат/клиентски ключ. За да внедря възможността за конфигуриране на достъп с помощта на токен на носител (де факто стандартът за k8s), трябваше да направя малко „измама“.

За да разрешите този проблем, можете да използвате вградения в Grafana механизъм "Plugin Routes" (повече за страница с официална документация). В настройките на нашия източник на данни можем да декларираме набор от правила за маршрутизиране, които ще бъдат обработени от прокси сървъра на grafana. Например, за всяка отделна крайна точка има възможност за задаване на заглавки или url с възможност за шаблониране, данните за които могат да бъдат взети от полетата jsonData и secureJsonData (за съхраняване на пароли или токени в криптирана форма). В нашия пример заявки като /__proxy/api/v1/именни пространства ще бъде проксииран към URL адреса на формуляра
/api/v8/именни пространства със заглавка Упълномощаване: Носител .

Естествено, за да работим с k8s api сървъра, се нуждаем от потребител с достъп само за четене, манифестите за създаване на които също можете да намерите в изходен код на приставката.

Част 5: освобождаване

След като напишете свой собствен плъгин Grafana, естествено ще искате да го направите публично достъпен. В Grafana това е библиотека с плъгини, достъпна на връзката grafana.com/grafana/plugins

За да бъде вашият плъгин достъпен в официалния магазин, трябва да направите PR в това хранилище, добавяйки следното съдържание към файла repo.json:

където версията е версията на вашия плъгин, url е връзка към хранилището, а commit е хешът на ангажимента, който ще направи конкретната версия на плъгина достъпна.

И на изхода ще видите прекрасна картина на формата:

Данните за него ще бъдат автоматично ограбени от вашите Readme.md, Changelog.md и файла plugin.json с описанието на приставката.

Част 6: вместо заключения

Не спряхме да разработваме нашия плъгин след пускането. И сега работим върху правилното наблюдение на използването на ресурсите на клъстерните възли, въвеждането на нови функции за подобряване на UX, а също така събираме голямо количество обратна връзка, получена след инсталирането на плъгина както от нашите клиенти, така и от ishshui в github (ако оставите своя проблем или заявка за изтегляне, ще се радвам много 🙂).

Надяваме се, че тази статия ще ви помогне да разберете такъв страхотен инструмент като Grafana и може би да напишете свой собствен плъгин.

Благодаря ви!)

Източник: www.habr.com