Фон

Источник данных: InfluxDB, возможно, PostgreSQL для редко меняющихся данных.

Этот запрос функции является общим продолжением дискуссий, происходящих в:

2132, № 2777, № 1611

Он основан на посте Slack : grafana на raintank.slack.com .

Для любопытных:
Чтобы узнать, что такое автономная или гибридная система, ознакомьтесь с этим очень доступным документом:

Гибридные энергосистемы на основе возобновляемых источников энергии (источник: Альянс за электрификацию сельских районов )

Соревнование

Ниже приведен пример одного из моих самых сложных вариантов использования Grafana.

├── 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 различных групп пользователей, а именно:

• Технический персонал
• Финансовый персонал
• Инвесторы
• Общедоступные
• Заказчики (т. Е. Компании по аренде растений; по сути, суборганизация)

У каждой из этих групп совершенно разные потребности в визуализации данных, и было бы здорово иметь возможность настраивать информационные панели по умолчанию, применимые к каждой группе. Некоторым группам, например техническим специалистам, я хочу предоставить полный доступ для создания собственных информационных панелей и возможности рисовать что угодно. Я хочу полностью заблокировать публичную группу, в то время как все остальные группы находятся где-то посередине между этими двумя крайностями. Я не хочу, чтобы группы вмешивались или имели доступ друг к другу как к информационным панелям, так и к источникам данных.

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 ( d1 & d2 ).
• Пользователь 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 привлекает нового клиента, Plant hire company 1.2 , который хочет контролировать все автономные системы, которые они покупают у Off-Grid manufacturer 1 . Plant hire company 1.2 есть два клиента, Building companies 1.2.1 & 1.2.2 , которые хотят управлять своими собственными правами доступа пользователей.

Off-Grid manufacturer 1 создал стандартный набор информационных панелей для каждой автономной системы, к которой они хотят предоставить доступ всем своим клиентам.

Пример управляющей организации:

• Я создаю новую организацию под названием Off-Grid manufacturer 1

• Я создаю одного пользователя в этой организации и даю ему права администратора.

  Пример администрирования групп:

• Пользователь-администратор организации Off-Grid manufacturer 1 создает 2 панели мониторинга.

  • Панель 1: показывает конфиденциальные финансовые показатели для бухгалтеров
  • Приборная панель 2: показывает напряжение аккумуляторной батареи для технических специалистов
• Пользователь-администратор создает новую группу под названием «Финансы» и предоставляет ей доступ к информационной панели 1.

• Пользователь с правами администратора создает новую группу под названием «Технические специалисты» и предоставляет ей доступ к панели 2.

  Пример администрирования пользователей:

• Пользователь-администратор организации Off-Grid manufacturer 1 создает нового пользователя (например, finance_user_1 ).

• finance_user_1 добавляется в группу "Финансы" (у них есть немедленный доступ к дашборду 1)

  Администраторы подгрупп / суборганизаций

• Пользователь-администратор организации Off-Grid manufacturer 1 создает новую группу или суборганизацию (например, hire_company_1.2 ).

• Пользователь с правами администратора создает нового пользователя с именем hire_company_1.2_admin .
• hire_company_1.2_admin может:
  
  
  
  • создавать новых пользователей (которые автоматически ограничиваются группой hire_company_1.2 .
  
  
  • создавать подгруппы пользователей
  
  
  • назначать субпользователей в субпользовательские группы
  
  
  • создавать информационные панели
  
  
  • создать группы под-панели
  
  
  • назначать информационные панели в подгруппы информационных панелей