データソース:InfluxDB、データの変更頻度が低い場合はPostgreSQLの可能性があります。
この機能リクエストは、次の場所で行われているディスカッションの一般的な拡張です。
これは、 2016年raintank.slack.com
にgrafana
チャネルで作成した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 |
--
ノート:
u1
)は、ユーザーグループ1( ug1
)を介して、ダッシュボード1と2( d1
とd2
)にのみアクセスできます。u2
)は両方のユーザーグループに属しているため、4つのダッシュボードすべてにアクセスできます。ug2
)に属するすべてのユーザーは、両方のダッシュボードグループにアクセスできるため、4つのダッシュボードすべてにもアクセスできます。u4
)は、ユーザーグループを経由せずに、ダッシュボードグループ2( dg2
)に直接属します。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
--
ノート:
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つのダッシュボードを作成します。
管理者ユーザーは、「技術者」と呼ばれる新しいグループを作成し、ダッシュボード2へのアクセスを許可します。
Off-Grid manufacturer 1
組織の管理者ユーザーが新しいユーザーを作成します(例: finance_user_1
)。
finance_user_1
が「Finances」グループに追加されます(ダッシュボード1にすぐにアクセスできます)
Off-Grid manufacturer 1
組織の管理者ユーザーは、新しいグループまたはサブ組織を作成します(例: hire_company_1.2
)。
hire_company_1.2_admin
という名前の新しいユーザーを作成します。hire_company_1.2_admin
できます:hire_company_1.2
グループに制限されます。データソースも分離し、グループの管理者が自分のデータソースを安全に管理できるようにすることをお勧めします。
ダッシュボードグループと権限モデルの提案: https :
Teams&Dashboardフォルダーを介してv5で実行
最も参考になるコメント
データソースも分離し、グループの管理者が自分のデータソースを安全に管理できるようにすることをお勧めします。