Grafana: [機能リクエスト]組織モデルを拡張して、ユーザーグループとダッシュボード(サブ)グループを含める

作成日 2016年05月03日  ·  3コメント  ·  ソース: grafana/grafana

バックグラウンド

データソース:InfluxDB、データの変更頻度が低い場合はPostgreSQLの可能性があります。

この機能リクエストは、次の場所で行われているディスカッションの一般的な拡張です。

2132、#2777、#1611

これは、 2016raintank.slack.comgrafanaチャネルで作成したGrafana Cloud Hosting BestPracticesのスラック投稿に基づいています。

好奇心旺盛な方へ:
オフグリッドまたはハイブリッドシステムとは何かを知るには、この非常にアクセスしやすいドキュメントをチェックしてください。

再生可能エネルギーに基づくハイブリッド電力システム(出典: Alliance for Rural Electrification

挑戦

以下は、私の最も複雑なGrafanaユースケースの1つの例です。

├── Off-Grid manufacturer 1
│   └── Technical staff
│   └── Finance staff
│   └── Investors
│   └── Public (i.e. demo dashboards)
│   │
│   └── Plant hire company 1.1
│   │   ├── Finance staff
│   │   ├── Technical staff
│   │   └── Investors
│   │   └── Public (i.e. demo dashboards)
│   │   │
│   │   └── Building company 1.1.1
│   │   │   ├── Technical staff
│   │   │   ├── Finance staff
│   │   │   └── Investors
│   │   │   └── Public (i.e. demo dashboards)
│   │   .
│   │   .
│   │   └── Building company 1.1.n
│   .
│   .
│   └── Plant hire company 1.n
.
.
└── Off-Grid manufacturer n

複数の組織だけでなく、数層の深さの複数の組織を扱う必要があることに注意してください。

Off-Grid manufacturer 1には、次の5つの異なるユーザーグループがあります。

•技術スタッフ
•財務スタッフ
•投資家
• 公衆
•顧客(すなわち、プラントレンタル会社、本質的には下位組織)

これらの各グループには、データの視覚化に関して大きく異なるニーズがあり、各グループに適用可能なデフォルトのダッシュボードを設定できるのは素晴らしいことです。 技術者のような一部のグループは、独自のダッシュボードを作成し、何でもグラフ化できるようにするためのフルアクセスを許可したいと考えています。 他のすべてのグループがこれらの2つの極端な中間にある間、私が完全にロックダウンしたいパブリックグループ。 グループが干渉したり、お互いのダッシュボードやデータソースにアクセスしたりしたくありません。

Off-Grid manufacturer 1は、その下にあるすべての企業のすべてのデータにアクセスできる必要があります。一方、 Plant hire company 1.1は、その下にあるすべての企業にアクセスできる必要がありますが、他の工場雇用者のデータにはアクセスできない必要があります。それ自体またはそれより上の組織と同じレベルの企業。

私が知っているやや極端な例ですが、これが私の現実です!

機能リクエスト

ダッシュボードへのアクセスを簡素化するには、組織内にユーザーグループとダッシュボードグループを用意し、各ユーザーまたはユーザーグループのダッシュボードに表示/編集権限を付与できると便利です。 特定のグループ(またはサブ組織)に制限された管理者権限を持つ、特定のグループ内の特定のユーザーに管理者の役割を割り当てる機能を備えたサブグループ(またはサブ組織)も便利です😈

単一の組織を描画する必要がある場合は、次のようになります。

users     :  u1   u2    u3   u4   u5 |
              \ /    \ /     /   /   |
               |      |     /   /    |
user      :   ug1    ug2   /   /     |
groups    :    |   /  |   /   /      |
               |  /   |  /   /       |>- organisation
               | /    | /   /        |
dashboard :   dg1    dg2   /         |
groups    :    |      |   /          |
              / \    / \ /           |
dashboards:  d1 d2  d3 d4            |
                                   --

ノート:

  • ユーザー1( u1 )は、ユーザーグループ1( ug1 )を介して、ダッシュボード1と2( d1d2 )にのみアクセスできます。
  • ユーザー2( u2 )は両方のユーザーグループに属しているため、4つのダッシュボードすべてにアクセスできます。
  • ユーザーグループ2( ug2 )に属するすべてのユーザーは、両方のダッシュボードグループにアクセスできるため、4つのダッシュボードすべてにもアクセスできます。
  • ユーザー4( u4 )は、ユーザーグループを経由せずに、ダッシュボードグループ2( dg2 )に直接属します。
  • ユーザー5( u5 )には、ダッシュボード4( d4 )を表示する権限しかありません。 私が理解している限り、これは組織内で実施されている現在の許可モデルですか?

複数の下位組織を持つ組織は、次のようになります。

                                  | sub-users     :  su1 su2  su3 su4
                                  |                    \ /     \ /  
                                  |                     |       |   
             sub-organisation 1 -<| sub-user      :    sug1    sug2 
            /                     | groups        :     |  \    |   
organisation                      |                     |   \   |   
            \                     |                     |    \  |  
     sub-organisation 2           | sub-dashboard :    sdg1    sdg2  
                                  | groups        :     |       |   
                                  |                    / \     /  \  
                                  | sub-dashboards:  sd1   sd2    sd3
                                   --

ノート:

  • サブダッシュボード2( sd2 )は両方のサブダッシュボードグループに属しているため、4人のユーザー全員がアクセスできます。
  • sub-organisation 1は、それ自体を除いて、 sub-organisation 2属するデータまたはorganisationに属するデータにアクセスできません。

実際のシナリオ

これは、これが実際にどのように機能するかを私がどのように想定しているかを描くための使用シナリオです。

私には顧客Off-Grid manufacturer 1 、オフグリッドシステムを構築してプラントレンタル会社に販売し、プラントレンタル会社はそれらを建設現場で電力を必要とする建設会社に雇用しています(注:4つの組織レベル)。

Off-Grid manufacturer 1は、 Off-Grid manufacturer 1から購入するすべてのオフグリッドシステムを監視したい新しい顧客Plant hire company 1.2 Off-Grid manufacturer 1獲得します。 Plant hire company 1.2は、自分のユーザーアクセス権を管理したい2人の顧客Building companies 1.2.1 & 1.2.2がいます。

Off-Grid manufacturer 1は、すべての顧客にアクセスを許可したいオフグリッドシステムごとにダッシュボードの標準セットを作成しました。

管理組織の例:

  • Off-Grid manufacturer 1という新しい組織を作成します
  • この組織内に1人のユーザーを作成し、それらに管理者権限を付与します。

    グループの管理の例:

  • Off-Grid manufacturer 1組織の管理者ユーザーは、2つのダッシュボードを作成します。

    • ダッシュボード1:会計士の機密財務数値を表示します
    • ダッシュボード2:技術者のバッテリー電圧を表示します
  • 管理者ユーザーは、「Finances」という新しいグループを作成し、ダッシュボード1へのアクセスを許可します。
  • 管理者ユーザーは、「技術者」と呼ばれる新しいグループを作成し、ダッシュボード2へのアクセスを許可します。

    ユーザーの管理の例:

  • Off-Grid manufacturer 1組織の管理者ユーザーが新しいユーザーを作成します(例: finance_user_1 )。

  • finance_user_1が「Finances」グループに追加されます(ダッシュボード1にすぐにアクセスできます)

    サブグループ/サブ組織の管理者

  • Off-Grid manufacturer 1組織の管理者ユーザーは、新しいグループまたはサブ組織を作成します(例: hire_company_1.2 )。

  • adminユーザーは、 hire_company_1.2_adminという名前の新しいユーザーを作成します。
  • hire_company_1.2_adminできます:

    • 新しいユーザーを作成します(ユーザーは自動的にhire_company_1.2グループに制限されます。

    • サブユーザーグループを作成する

    • サブユーザーをサブユーザーグループに割り当てる

    • ダッシュボードを作成する

    • サブダッシュボードグループを作成する

    • ダッシュボードをサブダッシュボードグループに割り当てる

typfeature-request

最も参考になるコメント

データソースも分離し、グループの管理者が自分のデータソースを安全に管理できるようにすることをお勧めします。

全てのコメント3件

データソースも分離し、グループの管理者が自分のデータソースを安全に管理できるようにすることをお勧めします。

ダッシュボードグループと権限モデルの提案: https

Teams&Dashboardフォルダーを介してv5で実行

このページは役に立ちましたか?
0 / 5 - 0 評価