Grafana 用プラグインの開発: 大物の歴史

こんにちは、みんな！ 数か月前、私たちは新しいオープンソース プロジェクトを運用開始しました。これは、kubernetes を監視するための Grafana プラグインです。 DevOpsProdigy KubeGraf。 プラグインのソース コードは次の場所から入手できます。 GitHub 上のパブリック リポジトリ。 この記事では、プラグインをどのように作成したか、使用したツール、開発プロセス中に遭遇した落とし穴についてのストーリーを共有したいと思います。 さあ行こう！

パート 0 - 入門: どのようにしてこの点に到達したのでしょうか?

Grafan 用に独自のプラグインを作成するというアイデアは、まったくの偶然から思いつきました。 当社は 10 年以上にわたり、さまざまなレベルの複雑さの Web プロジェクトを監視してきました。 この間、私たちはさまざまな監視システムの使用に関する専門知識、興味深い事例、経験を大量に蓄積してきました。 そしてある時点で、私たちは自問しました。「よく言われるように、Kubernetes を監視するための魔法のツールはあるだろうか?プロメテウスとグラファナの組み合わせ。 そして、このスタック用の既製のソリューションとして、prometheus-operator、kubernetes-mixin ダッシュボードのセット、grafana-kubernetes-app など、さまざまな種類のツールの大規模なセットがあります。

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

プラグインに実装することにしたアイデア:

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

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

技術的な観点から見ると、Grafana のプラグインは Angular コントローラーであり、Grafana データ ディレクトリ (/var/grafana/プラグイン/ /dist/module.js)、SystemJS モジュールとしてロードできます。 また、このディレクトリには、プラグインに関するすべてのメタ情報 (名前、バージョン、プラグイン タイプ、リポジトリ/サイト/ライセンスへのリンク、依存関係など) を含む plugin.json ファイルがあるはずです。

モジュール.ts

プラグイン.json

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

パネル: 最も一般的なタイプのプラグイン - あらゆるメトリクスを視覚化するためのパネルであり、さまざまなダッシュボードの構築に使用されます。
情報源: 一部のデータ ソースへのプラグイン コネクタ (例: 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 データ ディレクトリは開発者のマシンから直接マウントされる必要があります。

私たちの意見では、ローカルで 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 エンティティ (ポッド、デプロイメント、デーモンセット、ステートフルセット、ジョブ、cronjob、サービス、ノード、名前空間) を記述することにしました。 これらの各クラスは、コンストラクター、デストラクター、可視性を更新および切り替えるためのメソッドを記述する共通の 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() メソッド - インストールされているすべてのデータソースのリストを返します。 ) - 特定のデータソースのインスタンス オブジェクトを返します。

パート 4: データソース

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

KubeGraf プラグインでは、ユーザー インターフェイスの観点から見ると、データソースは次の機能を実装する kubernetes クラスターのインスタンスです (ソース コードは利用可能です) リンク):

• k8s API サーバーからデータを収集する (名前空間、デプロイメントのリストを取得するなど)
• prometheus-datasource (特定のクラスターごとにプラグイン設定で選択) へのリクエストをプロキシし、静的ページとダッシュボードの両方でデータを使用するように応答をフォーマットします。
• 静的プラグイン ページのデータを更新します (リフレッシュ レートが設定されています)。
• grafana ダッシュボードでテンプレート シートを生成するためのクエリの処理 (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 と基本的な認証/認可設定 (ログイン パスワード、またはクライアント証明書/クライアント キー) を指定して、http データ ソースへのアクセスを構成できます。 ベアラー トークン (k8s の事実上の標準) を使用してアクセスを構成する機能を実装するには、少し調整する必要がありました。

この問題を解決するには、組み込みの Grafana の「プラグイン ルート」メカニズムを使用できます (詳細については、 公式ドキュメントページ）。 データソースの設定では、grafana プロキシ サーバーによって処理される一連のルーティング ルールを宣言できます。 たとえば、個々のエンドポイントごとに、ヘッダーまたは URL をテンプレート化して設定することができ、そのデータは jsonData および secureJsonData フィールドから取得できます (パスワードまたはトークンを暗号化された形式で保存するため)。 この例では、次のようなクエリが実行されます。 /__proxy/api/v1/namespaces フォームの URL にプロキシされます
/api/v8/namespaces と Authorization: Bearer ヘッダー。

当然のことながら、k8s API サーバーを操作するには、読み取り専用アクセス権を持つユーザーが必要です。作成用のマニフェストも次の場所にあります。 プラグインのソースコード.

パート 5: リリース

独自の Grafana プラグインを作成したら、当然、それを公開したくなるでしょう。 Grafana では、これはここで利用できるプラグインのライブラリです grafana.com/grafana/plugins

プラグインを公式ストアで入手できるようにするには、次の URL で PR を行う必要があります。 このリポジトリ次のようなコンテンツを repo.json ファイルに追加します。

ここで、version はプラグインのバージョン、url はリポジトリへのリンク、commit はプラグインの特定のバージョンが利用可能になるコミットのハッシュです。

出力では、次のような素晴らしい画像が表示されます。

そのデータは、Readme.md、Changelog.md、およびプラグインの説明を含む plugin.json ファイルから自動的に取得されます。

パート 6: 結論ではなく

私たちはリリース後もプラグインの開発を停止しませんでした。 そして現在、私たちはクラスター ノードのリソースの使用状況を正しく監視し、UX を向上させる新機能を導入し、プラグインのインストール後にクライアントと GitHub 上の人々の両方から受け取った大量のフィードバックを収集することに取り組んでいます (終了した場合)あなたの問題またはプルリクエスト、私はとても幸せです:)

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

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

出所： habr.com