search

0maczel / pz

Projekt realizowany w ramach zajęć "Programowanie Zespołowe" na WFiIS w semestrze letnim 2015/2016.
0 stars 0 forks source link

Obsługa konfiguracji sensorów. #19

Closed dawidkomorowski closed 8 years ago

dawidkomorowski commented 8 years ago

Podstawowy przypadek użycia REST API monitora to proces rejestracji nowego sensora (lub określenie istniejącej konfiguracji sensora).

Należy zaimplementować klasy serwisowe i ich metody pozwalające na:

Dodatkowo należy odpowiednio zaktualizować dokumentację REST API.

Link: #16

paweljozwik commented 8 years ago

Pozwole sobie się wtrącić ;)

"znalezienie sensora w oparciu o ExternalSystemId" mamy to w aktualnym REST API? możliwe że przeoczyłem

wstępnie zastanawiając się nad implementacją tej procedury, z perspektywy sensora, widziałem to tak że sensor odpytuje o metryki i zasoby (używając metod GET które pobierają całe listy) w monitorze i w razie potrzeby dodaje nowe i sam się rejestruje ale nie będę miał nic przeciwko jeśli zaimplementujecie dwie ostatnie kropki z tej listy.

Co do tych dwóch ostatnich kropek to unikalność metryki z perspektywy sensora będzie zachowana, ewentualnym problemem może być unikalność zasobu.

dawidkomorowski commented 8 years ago

@paweljozwik, trzech ostatnich kropek nie ma w dokumentacji aktualnego REST API, ale nie traktowałbym go nazbyt wiążąco.

Warto tu rozpatrzyć możliwe przypadki użycia tego procesu rejestracji sensora. Poniżej trzy warianty brzegowe:

  1. Sensor dodaje nową metrykę, zasób i swoją konfigurację.
  2. Sensor wykorzystuje istniejącą metrykę i zasób i na ich podstawie dodaje swoją konfigurację.
  3. Sensor wykorzystuje swoją istniejącą konfigurację.

Na podstawie tych trzech scenariuszy widać potrzebę możliwości odnalezienia odpowiednich danych. Oczywiście można ten obowiązek zostawić po stronie sensora, z tym że, jeśli zwrócone kolekcje metryk, zasobów, sensorów będą zawierać linki do faktycznych zasobów, to mamy klasyczne N+1 jeśli chodzi o ilość zapytań do monitora, aby obsłużyć przypadek 1 (gdzie nic nie zostanie odnalezione i wszystko należy utworzyć).

Jeżeli znowu kolekcje zwracałyby faktyczne zasoby, to zapytań będzie niewiele, ale i tak będą niosły one sporo danych. Optymalnym zatem wydaje się utworzyć takie serwisy, które będą potrafić zrealizować podstawowe filtrowanie. Można zatem do tych endpointów reprezentujących odpowiednie kolekcje (/sensors, /metrics, /resources) dodać parametry query, zawężające zwracaną listę (/metrics?name=CPU) i dalej już sensor obsłuży otrzymane wyniki.

Jeżeli przyjąć nazwy zasobów i metryk jako unikalne (co wydaje się dość logiczne) to zwrócone zostaną jednoelementowe listy. Pytanie jak z sensorami, czy sensor o danym ExternalSystemId może mieć więcej niż jedną konfigurację? Jeśli nie, to można to też zrobić unikalne i wszystko jest proste. Jeżeli pozwalamy na kilka konfiguracji to sprawa się lekko komplikuje, zależnie od dalszych wymagań.

paweljozwik commented 8 years ago

Aktualny projekt tej komunikacji opierałem na tym co w tym momencie jest w REST API stąd pomysł robienia filtrowania w sensorze.

Wydaje mi się że lepsze byłoby jednak filtrowanie tego po stronie monitora, choćby z tego względu że będzie mógł z tego skorzystać zarówno web-client jak i klient automatyczny.

Ja bym się skłaniał za architekturą: jedna metryka + jeden zasób -> jeden sensor tzn. aplikacja sensora która ma monitorować użycie pamięci ("RAM") i cpu ("CPU") na danym komputerze ("pawel-pc") faktycznie w monitorze stworzy (albo użyje jeśli już będą) dwa sensory: "RAM" + "pawel-pc" -> sensor/1 "CPU" + "pawel-pc" -> sensor/2

I potem do tych endpointów aplikacja będzie pchała odpowiednie pomiary. Co prawda nie jest to najprostsze możliwe podejście ale daje pewną skalowalność przy dodawaniu nowych metryk.

ExternalSystemId w zasadzie nie wiem po co to jest, możliwe że jakaś zaszłość z dyskusji na spotkaniach. Wydaje mi się że jest to pewna redundancja z zasobem. Nazwa hosta jako nazwa zasobu powinna wystarczyć jako identyfikator tego skąd pochodzi pomiar.

dawidkomorowski commented 8 years ago

Co do ExternalSystemId, to ono miało być tym unikalnym identyfikatorem sensora, po którym ten mógłby się odnaleźć. Oczywiście można do tego wykorzystać nazwę zasobu jak sugerujesz, chociaż w takim wypadku tracimy możliwość używania kilku sensorów dla jednego zasobu (zasób nie może już przykładowo reprezentować sali laboratoryjnej, w której jest 15 komputerów i na każdym sensor monitorujący zasoby).

Co do filtrowania, to tak jak wspomniałeś lepszym wydaje się zrobić to po stronie monitora, zatem API zostanie rozszerzone o filtrowanie kolekcji.

Update: Temat wart jeszcze poruszenia, to kwestia reprezentacji referencji zasobów w JSON. Może jakiś spec od REST mógłby się wypowiedzieć jak powinno być to zrobione poprawnie. Obecna wersja REST API, którą tworzyłem w owym czasie, referencje do innych obiektów zawsze podaje jako URL (tam dany jako względny, ale chyba powinien być bezwzględny). Pytanie czy reprezentacja używana do POST-owania nowych zasobów powinna wyglądać tak samo, czy może używać np. Id wprost?

Pewne sugestie na temat REST, na których się oparłem wtedy mówią, że reprezentacja zasobu przy GET i POST powinna być taka sama, chociaż w sposób oczywisty komplikuje się obsługa POST-ów zawierających URL jako referencję.

dawidkomorowski commented 8 years ago

@invader92 Czy udało się zrobić już jakieś postępy?