Grafana용 플러그인 개발: 빅샷의 역사

안녕하세요 여러분! 몇 달 전, 우리는 새로운 오픈 소스 프로젝트인 Kubernetes 모니터링용 Grafana 플러그인을 프로덕션에 출시했습니다. DevOpsProdigy KubeGraf. 플러그인 소스 코드는 다음에서 확인할 수 있습니다. GitHub의 공개 저장소. 그리고 이 글에서는 우리가 플러그인을 어떻게 만들었는지, 어떤 도구를 사용했는지, 개발 과정에서 어떤 함정에 빠졌는지에 대한 이야기를 여러분과 공유하고 싶습니다. 갑시다!

파트 0 - 입문: 어떻게 이 지점에 도달했나요?

Grafan용 플러그인을 자체적으로 작성하려는 아이디어는 우연히 떠오른 것입니다. 우리 회사는 10년 넘게 다양한 수준의 복잡성을 지닌 웹 프로젝트를 모니터링해 왔습니다. 그 동안 우리는 다양한 모니터링 시스템을 활용하면서 많은 전문지식과 흥미로운 사례, 경험을 축적해왔습니다. 그리고 어느 시점에서 우리는 스스로에게 이렇게 물었습니다. "Kubernetes를 모니터링하여 "설정하고 잊어버리도록" 하는 마법의 도구가 있습니까?". 물론 k8s 모니터링을 위한 업계 표준은 오랫동안 프로메테우스 + 그라파나 조합. 그리고 이 스택을 위한 기성 솔루션으로 prometheus-operator, kubernetes-mixin 대시보드 세트, grafana-kubernetes-app 등 다양한 종류의 도구 세트가 있습니다.

grafana-kubernetes-app 플러그인은 우리에게 가장 흥미로운 옵션인 것 같았지만 XNUMX년 넘게 지원되지 않았으며 게다가 새 버전의 node-exporter 및 kube-state-metrics와도 작동할 수 없습니다. 그리고 어느 순간 우리는 “우리 스스로 결정을 내려야 하지 않을까?”라고 결정했습니다.

플러그인에 구현하기로 결정한 아이디어는 무엇입니까?

• "애플리케이션 맵" 시각화: 클러스터 내 애플리케이션을 네임스페이스, 배포별로 그룹화하여 편리하게 표시합니다.
• "배포 - 서비스(+포트)"와 같은 연결 시각화.
• 클러스터 노드 전체에 클러스터 애플리케이션 배포를 시각화합니다.
• Prometheus 및 k8s API 서버와 같은 여러 소스에서 측정항목 및 정보를 수집합니다.
• 인프라 부분(CPU 시간, 메모리, 디스크 하위 시스템, 네트워크 사용)과 애플리케이션 로직(상태 포드, 사용 가능한 복제본 수, 활성/준비 테스트 통과에 대한 정보)을 모두 모니터링합니다.

파트 1: "Grafana 플러그인"이란 무엇입니까?

기술적인 관점에서 Grafana용 플러그인은 Grafana 데이터 디렉터리(/var/grafana/플러그인/ /dist/module.js) SystemJS 모듈로 로드될 수 있습니다. 또한 이 디렉터리에는 플러그인에 대한 모든 메타 정보(이름, 버전, 플러그인 유형, 저장소/사이트/라이센스 링크, 종속성 등)가 포함된plugin.json 파일이 있어야 합니다.

module.ts

플러그인.json

스크린샷에서 볼 수 있듯이 우리는plugin.type = app을 지정했습니다. Grafana용 플러그인은 세 가지 유형이 있을 수 있습니다.

패널: 가장 일반적인 유형의 플러그인 - 다양한 대시보드를 구축하는 데 사용되는 측정항목을 시각화하는 패널입니다.
데이터 소스: 일부 데이터 소스(예: Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource)에 대한 플러그인 커넥터입니다.
앱: Grafana 내에서 자신만의 프런트엔드 애플리케이션을 구축하고, 자신만의 HTML 페이지를 만들고, 데이터 소스에 수동으로 액세스하여 다양한 데이터를 시각화할 수 있는 플러그인입니다. 또한, 다른 유형(데이터소스, 패널)의 플러그인과 다양한 대시보드를 종속성으로 사용할 수 있습니다.

type=app인 플러그인 종속성의 예.

프로그래밍 언어로 JavaScript와 TypeScript를 모두 사용할 수 있습니다(저희는 이를 선택했습니다). 가능한 모든 유형의 hello-world 플러그인을 위한 준비 링크를 찾아보세요: 이 저장소에는 사전 설치 및 구성된 빌더가 포함된 수많은 스타터 팩(React에 실험적인 플러그인 예제도 있음)이 포함되어 있습니다.

2부: 로컬 환경 준비

플러그인 작업을 위해서는 당연히 prometheus, node-exporter, kube-state-metrics, grafana 등 모든 사전 설치된 도구가 포함된 kubernetes 클러스터가 필요합니다. 환경은 빠르고 쉽고 자연스럽게 설정되어야 하며, 핫 리로드를 보장하려면 Grafana 데이터 디렉터리를 개발자 컴퓨터에서 직접 마운트해야 합니다.

우리 생각에 쿠버네티스를 로컬에서 작업하는 가장 편리한 방법은 다음과 같습니다. 미니큐브. 다음 단계는 prometheus-operator를 사용하여 Prometheus + Grafana 조합을 설치하는 것입니다. 안에 이 기사 minikube에 prometheus-operator를 설치하는 과정을 자세히 설명합니다. 지속성을 활성화하려면 매개변수를 설정해야 합니다. 지속성 : 사실 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, 배포, daemonset, statefulset, job, cronjob, 서비스, 노드, 네임스페이스)으로 설명하기로 결정했습니다. 이러한 각 클래스는 생성자, 소멸자, 가시성을 업데이트하고 전환하기 위한 메서드를 설명하는 공통 BaseModel 클래스에서 상속됩니다. 각 클래스는 다른 엔터티와의 중첩 관계(예: 배포 유형 엔터티에 대한 Pod 목록)를 설명합니다.

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

getter 및 setter의 도움으로 필요한 엔터티 메트릭을 편리하고 읽기 쉬운 형식으로 표시하거나 설정할 수 있습니다. 예를 들어 할당 가능한 CPU 노드의 형식화된 출력은 다음과 같습니다.

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

페이지

모든 플러그인 페이지 목록은 처음에 종속성 섹션의 pluing.json에 설명되어 있습니다.

각 페이지의 블록에는 페이지 이름을 표시해야 합니다(이 페이지에 액세스할 수 있는 슬러그로 변환됩니다). 이 페이지의 작업을 담당하는 구성 요소의 이름(구성 요소 목록은 module.ts로 내보내집니다) 이 페이지 작업이 가능한 사용자 역할과 사이드바에 대한 탐색 설정을 나타냅니다.

페이지 작업을 담당하는 구성 요소에서 templateUrl을 설정하고 여기에 마크업이 포함된 html 파일 경로를 전달해야 합니다. 컨트롤러 내부에서는 종속성 주입을 통해 최대 2개의 중요한 각도 서비스에 액세스할 수 있습니다.

• backendSrv - Grafana API 서버와의 상호 작용을 제공하는 서비스입니다.
• datasourceSrv - Grafana에 설치된 모든 데이터 소스와의 로컬 상호 작용을 제공하는 서비스(예: .getAll() 메서드) - 설치된 모든 데이터 소스 목록을 반환합니다. ) - 특정 데이터 소스의 인스턴스 객체를 반환합니다.

파트 4: 데이터 소스

Grafana의 관점에서 보면 datasource는 다른 모든 플러그인과 완전히 동일한 플러그인입니다. 자체 진입점 module.js가 있고 메타 정보가 있는 파일인plugin.json이 있습니다. type = app인 플러그인을 개발할 때 기존 데이터 소스(예: 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를 사용하여 최종 데이터 소스에 대한 액세스를 구성할 수 있습니다. 이 구성 요소를 사용하면 URL 및 기본 인증/권한 설정(login-password 또는 client-cert/client-key)을 지정하여 http 데이터 소스에 대한 액세스를 구성할 수 있습니다. 베어러 토큰(k8s의 사실상 표준)을 사용하여 액세스를 구성하는 기능을 구현하기 위해 약간의 조정이 필요했습니다.

이 문제를 해결하려면 내장된 Grafana "플러그인 경로" 메커니즘을 사용할 수 있습니다(자세한 내용은 다음을 참조하세요). 공식 문서 페이지). 데이터 소스 설정에서 grafana 프록시 서버가 처리할 라우팅 규칙 세트를 선언할 수 있습니다. 예를 들어, 각 개별 엔드포인트에 대해 템플릿이 가능한 헤더 또는 URL을 설정할 수 있으며, 이에 대한 데이터는 jsonData 및 secureJsonData 필드에서 가져올 수 있습니다(비밀번호 또는 토큰을 암호화된 형식으로 저장하기 위해). 이 예에서 다음과 같은 쿼리는 /__proxy/api/v1/네임스페이스 양식의 URL로 프록시됩니다.
Authorization: Bearer 헤더가 있는 /api/v8/namespaces.

당연히 k8s API 서버를 사용하려면 읽기 전용 액세스 권한이 있는 사용자가 필요하며 생성을 위한 매니페스트도 다음에서 찾을 수 있습니다. 플러그인 소스 코드.

파트 5: 출시

자신만의 Grafana 플러그인을 작성하고 나면 자연스럽게 이를 공개적으로 사용할 수 있게 만들고 싶을 것입니다. Grafana에서는 여기에서 사용할 수 있는 플러그인 라이브러리입니다. grafana.com/grafana/plugins

공식 스토어에서 플러그인을 사용하려면 다음에서 PR을 작성해야 합니다. 이 저장소repo.json 파일에 다음과 같은 콘텐츠를 추가하면 됩니다.

여기서 version은 플러그인 버전이고, url은 저장소에 대한 링크이며, commit은 플러그인의 특정 버전을 사용할 수 있는 커밋의 해시입니다.

출력에서 다음과 같은 멋진 그림을 볼 수 있습니다.

이에 대한 데이터는 Readme.md, Changelog.md 및 플러그인 설명과 함께 플러그인.json 파일에서 자동으로 가져옵니다.

6부: 결론 대신

우리는 출시 후에도 플러그인 개발을 중단하지 않았습니다. 이제 우리는 클러스터 노드의 리소스 사용을 올바르게 모니터링하고, UX를 개선하기 위한 새로운 기능을 도입하고, 클라이언트와 GitHub 사용자 모두로부터 플러그인을 설치한 후 받은 많은 양의 피드백을 수집하기 위해 노력하고 있습니다. 귀하의 문제나 끌어오기 요청을 보내주시면 매우 기쁠 것입니다 :)

이 기사가 Grafana와 같은 훌륭한 도구를 이해하고 아마도 자신만의 플러그인을 작성하는 데 도움이 되기를 바랍니다.

감사합니다!)

출처 : habr.com