Weryfikacja interakcji sensor-monitor

[paweljozwik]

@dawidkomorowski Zerknij na diagram interakcji między sensorem a monitorem https://github.com/0maczel/pz/blob/master/dokumentacja/Sensor%20Monitor%20interakacja.png i daj mi znać czy moje zrozumienie jak ma się ta komunikacja odbywać jest poprawne.

Link: #19

[dawidkomorowski]

@paweljozwik Właśnie rzuciłem okiem i dokładnie takie było moje wyobrażenie co do tej komunikacji - jedyna rzecz, której tam brakuje to sprawdzenie czy dana metryka/zasób istnieje, jako że metryka/zasób może zostać już wcześniej zdefiniowany przez inny sensor, tudzież przez ten sam sensor we wcześniejszej sesji.

Jak to może być sprawdzone, przy obecnym API to trzeba by pobrać wszystkie i sukcesywnie odpytać je w poszukiwaniu tej o oczekiwanej nazwie - gdy się znajdzie użyć jej ID, a gdy nie, utworzyć nową. Można by tu zaproponować oczywistą optymalizację po stronie API, czyli dać endpoint do wykonywania takiego zapytania o metrykę/zasób o zadanej nazwie, które zwróci ID/Link lub null.

Nie wiem jak też obecne API ma się do wniosków ze spotkania z "klientem", czy wymaga ono poważniejszych zmian?

Ping @dariuszduda @invader92 @0maczel

[dawidkomorowski]

@paweljozwik Trzeba w końcu podjąć decyzję czy używamy ExternalSystemId czy nie.

Jeżeli nie to domniemam, że identyfikacja sensora odbywa się per zasób? Wtedy kilka różnych sensorów na różnych maszynach reprezentujących jeden logiczny zasób zwyczajnie nie są rozróżnialne przez Monitor i on nie dba o to jakie sensory będą dodawać nowe pomiary tego zasobu (gdyż będą współdzielić jedną konfiguracje po stronie monitora)? Takie coś wydaje się być dość rozsądne w kontekście nadania abstrakcji kolejnym warstwom systemu. Dopóki konfiguracje nie będą ulegać zmianom to jest to chyba dobre podejście.

Wtedy w sumie można też z reprezentacji pomiaru pozbyć się informacji z jakiej konfiguracji sensora została ona utworzona gdyż taka konfiguracja już nie będzie tożsama z konkretnym sensorem.

[paweljozwik]

Jestem za pozbyciem sie ExternalSystemId wydaje mi sie że informacja gdzie (zasób) i co (metryka) jest wystarczająca do zidentyfikowania sensora.

Co do reprezentacji wkleje to co pisałem w innym wątku

"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."

Tak ja to widzę i tak mam zamiar to zaimplementować.

Jeżeli nie to domniemam, że identyfikacja sensora odbywa się per zasób?

Zasób + metryka

"Wtedy w sumie można też z reprezentacji pomiaru pozbyć się informacji z jakiej konfiguracji >sensora została ona utworzona gdyż taka konfiguracja już nie będzie tożsama z konkretnym >sensorem."

Jakiej konkretnie informacji z konfiguracji chcesz sie pozbyć, mierzona metryka/zasób/pomiar?

Swoją drogą umówmy się na TS i ustalmy to za jednym zamachem. @dawidkomorowski @invader92 @0maczel @misiek2709

Jeśli o mnie chodzi jestem dostępny codziennie od ok. 19-20.

[0maczel]

Jutro (poniedziałek 16.05) o 20?

[dawidkomorowski]

@paweljozwik Miałem na myśli usunięcie z modelu danych informacji o konfiguracji sensora na encji pomiaru. Nie będzie w obecnej formie ona do niczego przydatna więc warto się jej pozbyć.

Obecna implementacja dla endpointu /sensors pozwala pobrać listę sensorów filtrując po nazwie zasobu jak i metryki, więc to jest chyba to o co nam chodziło.

[dawidkomorowski]

@paweljozwik Wszystkie endpointy potrzebne do procesu przeprowadzenia rejestracji są już zaimplementowane więc ten aspekt może być zrealizowany i przetestowany już od strony faktycznego sensora.

Warte uwagi są pewnie zmiany w REST API. W wielu miejscach obecnie zwracane nie są URI, a reprezentacje konkretnych encji.

Jeżeli chodzi o dostarczony pierwotnie schemat interakcji sensor-monitor, wszystko tam jest wciąż aktualne, jedynie z uwagą, że nie zawsze potrzeba tworzyć nowe zasoby/metryki/konfiguracje sensora, a można je wykorzystać, co wymaga dodatkowych zapytań podczas tego procesu.

Jeżeli chodzi o endpoint odpowiedzialny za publikowanie pomiarów, jest on jeszcze w trakcie implementacji - będzie niedługo dostępny. Z punktu widzenia API jego dokumentacja jest raczej finalna i można się już na nim oprzeć podczas implementacji.

PS. Czy próbowaliście (wy, w sensie zespół od sensorów) uruchomić Monitor? Pytam głównie czy jesteście to w stanie zrobić (macie narzędzia, które pozwalają go zbudować ze źródeł i uruchomić), czy potrzebny jest deployment gotowej aplikacji wykonywalnej?