Grafana プラグインの開発: 失敗の歴史

こんにちは、みんな！数か月前、私たちは新しいオープンソースプロジェクトを本番環境でリリースしました。Kubernetesを監視するためのGrafanaプラグインです。 DevOpsProdigy KubeGraf。プラグインのソースコードは以下から入手できます。 GitHubの公開リポジトリ。この記事では、プラグインをどのように作成したか、どのようなツールを使用したか、開発プロセス中にどのような落とし穴に遭遇したかについてお話ししたいと思います。さあ行こう！

パート 0 - はじめに: どのようにしてここまで来たのでしょうか?

Grafana 用の独自のプラグインを作成するというアイデアは、まったくの偶然から生まれました。当社は 10 年以上にわたり、さまざまな複雑さのレベルの Web プロジェクトを監視してきました。この間、当社はさまざまな監視システムの使用に関して、膨大な専門知識、興味深い事例、経験を蓄積してきました。そしてある時点で、私たちは自問しました。「Kubernetes を監視するための魔法のツールはあるのでしょうか。いわゆる『設定して忘れる』ことができるツールはあるのだろうか？」。当然ながら、K8S を監視するための業界標準は長い間、Prometheus + Grafana バンドルでした。また、このスタックの既成ソリューションとして、prometheus-operator、ダッシュボードのセット kubernetes-mixin、grafana-kubernetes-app など、さまざまな種類のツールの大規模なセットがあります。

私たちにとって最も興味深いオプションは grafana-kubernetes-app プラグインであるように思われましたが、これは 1 年以上サポートされておらず、さらに、node-exporter および kube-state-metrics の新しいバージョンでは動作しません。そしてある時点で、私たちは「自分たちで解決策を作ろう」と決心しました。

プラグインに実装することにしたアイデアは何ですか?

• 「アプリケーション マップ」の視覚化: 名前空間、デプロイメントなどでグループ化された、クラスター内のアプリケーションの便利な表現。
• 「デプロイメント - サービス (+ ポート)」タイプの接続の視覚化。
• クラスター ノード全体にわたるクラスター アプリケーションの分散の視覚化。
• 複数のソース（Prometheus および k8s API サーバー）からメトリックと情報を収集します。
• インフラストラクチャ部分 (プロセッサ時間、メモリ、ディスク サブシステム、ネットワークの使用) とアプリケーション ロジック (ポッドのヘルス ステータス、使用可能なレプリカの数、生存/準備テストの通過に関する情報) の両方を監視します。

パート 1: 「Grafana プラグイン」とは何ですか?

技術的には、GrafanaプラグインはGrafanaのデータディレクトリ（/var/grafana/プラグイン/ /dist/module.js) であり、SystemJS モジュールとして読み込むことができます。また、このディレクトリには plugin.json ファイルがあり、このファイルには、プラグインに関するすべてのメタ情報 (名前、バージョン、プラグインの種類、リポジトリ/サイト/ライセンスへのリンク、依存関係など) が含まれています。

モジュール.ts

プラグイン.json

スクリーンショットからわかるように、plugin.type = app を指定しました。 Grafana には 3 種類のプラグインがあるためです。

パネル: 最も一般的なタイプのプラグイン - さまざまなダッシュボードを構築するために使用される、いくつかのメトリックを視覚化するためのパネルです。
情報源: データ ソースへのプラグイン コネクタ (たとえば、Prometheus データ ソース、ClickHouse データ ソース、ElasticSearch データ ソース)。
アプリ: Grafana 内で独自のフロントエンド アプリケーションを構築し、独自の HTML ページを作成し、データ ソースに手動でアクセスしてさまざまなデータを視覚化できるプラグイン。また、他のタイプのプラグイン (データソース、パネル) やさまざまなダッシュボードを依存関係として使用できます。

type = app のプラグイン依存関係の例.

プログラミング言語として JavaScript または TypeScript のいずれかを使用できます (ここでは TypeScript を選択しました)。あらゆるタイプのHello-Worldプラグイン用の空白 リンクを見つけてください: このリポジトリには、プリインストールされ構成されたビルダーを備えた多数のスターター パック (React 上のプラグインの実験的な例も含まれています) が含まれています。

パート2: ローカル環境の準備

プラグインを操作するには、当然のことながら、prometheus、node-exporter、kube-state-metrics、grafana などのすべてのツールがプリインストールされた Kubernetes クラスターが必要になります。環境は迅速かつ簡単にセットアップでき、ホットリロードを確実に実行できるように、Grafana データ ディレクトリを開発者のマシンから直接マウントする必要があります。

私たちの意見では、Kubernetesをローカルで操作する最も便利な方法は ミニキューブ。次のステップは、prometheus-operator を使用して Prometheus + Grafana バンドルをインストールすることです。で この記事 minikube に prometheus-operator をインストールするプロセスが詳細に説明されています。永続性を有効にするには、パラメータを設定する必要があります 永続性: true 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：直接開発

オブジェクトモデル

プラグインの実装に備えて、TypeScript クラスとして操作するすべての基本的な Kubernetes エンティティ (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 = [];
   }
}

ゲッターとセッターを使用すると、必要なエンティティ メトリックを便利で読みやすい形式で表示または設定できます。たとえば、割り当て可能な 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 つの重要な Angular サービスにアクセスできます。

• backendSrv は、Grafana API サーバーとの対話を提供するサービスです。
• datasourceSrv — Grafanaにインストールされているすべてのデータソースとのローカルなやりとりを提供するサービス（たとえば、.getAll()メソッドはインストールされているすべてのデータソースのリストを返します。.get( ) - 特定のデータソースのインスタンス オブジェクトを返します。

パート4: データソース

Grafana の観点から見ると、データソースは他のすべてのプラグインとまったく同じです。独自のエントリ ポイント module.js があり、メタ情報を含むファイル plugin.json があります。 type = app でプラグインを開発する場合、既存のデータソース (たとえば、prometheus-datasource) と独自のデータソースの両方と対話できます。これらのデータソースは、プラグイン ディレクトリ (dist/datasource/*) に直接保存することも、依存関係としてインストールすることもできます。私たちの場合、データ ソースはプラグイン コードとともに提供されます。また、データ ソース インスタンス構成ページに使用される config.html テンプレートと ConfigCtrl コントローラー、およびデータ ソースのロジックを実装する Datasource コントローラーも必要です。

KubeGrafプラグインでは、ユーザーインターフェースの観点から、データソースは次の機能を実装するKubernetesクラスタのインスタンスです（ソースコードは入手可能です）。 リンク):

• k8s api-server からデータを取得する (名前空間、デプロイメントのリストを取得するなど)
• リクエストを 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、plugin.json ファイルから自動的に取得されます。

第6部：結論の代わりに

リリース後もプラグインの開発は中止しませんでした。そして現在、私たちはクラスターノードのリソース使用状況を正しく監視し、UX を改善するための新機能を実装し、プラグインのインストール後にクライアントと GitHub のリクエストの両方から受け取った大量のフィードバックを整理することに取り組んでいます (問題やプルリクエストを残していただければ、とてもうれしく思います 🙂 )。

この記事が、Grafana のような素晴らしいツールを理解し、独自のプラグインを作成するのに役立つことを願っています。

ありがとうございます！）

出所： habr.com