Który klient StatsD powinienem użyć dla projektu java/grails?

Question

Czekam na dodanie kolekcji danych StatsD do mojej aplikacji grails i rozejrzenie się po istniejących bibliotekach i kodu pozostawiło mnie trochę zdezorientowany, co byłoby dobrym rozwiązaniem skalowalnym. Aby trochę umieścić pytanie w kontekście, pracuję nad projektem typu gry online, w którym naturalnie będę monitorował interakcje użytkownika z silnikiem gry, naturalnie skupią się one wokół konkretnych momentów w czasie, w których użytkownicy X będą wykonywać interakcje w oknie sekundy lub dwóch, a następnie powtarzanie po 10-20 sekundowej przerwie.

Oto moja analiza opcji dostępnych dzisiaj.

przykład klient Etsy StatsD

https://github.com/etsy/statsd/blob/master/examples/StatsdClient.java

W „Najprostszą rzeczą, która mogłaby działać” rozwiązanie, mogę ciągnąć tej klasy w moim projekcie i instanciate singleton instancji jako fasoli wiosny i używać go bezpośrednio. Jednak po zauważeniu, że wtyczka grails-statsd tworzy pulę instancji klienta, zacząłem zastanawiać się nad skalowalnością tego podejścia.

Wydaje się, że metoda doSendmógłby stać się wąskim gardłem, gdy wiele wątków próbuje wysłać zdarzenia w tym samym czasie, jednak jak rozumiem, z powodu pożaru i zapomnieć naturę wysyłania pakietów UDP, to powinno się zdarzyć szybko, unikając ogromnego obciążenia, które zwykle kojarzymy z połączeniami sieciowymi.

Grails-statsd plugin

https://github.com/charliek/grails-statsd/

Ktoś stworzył już wtyczki StatsD dla Grails, który zawiera kilka ciekawych funkcji, takich jak adnotacje i withTimer metody. Jednak widzę, że w implementacji brakuje niektórych poprawek z przykładowej implementacji, takich jak określanie ustawień regionalnych dla połączeń z String.format. Nie jestem też wielkim fanem wciągania do wspólnej puli Apache, gdy standardowy Executor może osiągnąć podobny efekt.

java-statsd-client

https://github.com/tim-group/java-statsd-client/

Jest to alternatywa czysty biblioteki Java, która działa asynchronicznie przez utrzymywanie swojego ExecutorService. Obsługuje cały interfejs API StatsD, w tym zestawy i próbkowanie, ale nie zapewnia żadnych haczyków do konfigurowania puli wątków i wielkości kolejki. W przypadku problemów, dla rzeczy niekrytycznych, takich jak monitorowanie, myślę, że wolałbym skończoną kolejkę i przegrywanie zdarzeń niż posiadanie nieskończonej kolejki, która wypełnia moją stertę.

plugin play statsd

https://github.com/vznet/play-statsd/

Teraz nie mogę użyć tego kodu bezpośrednio w moim projekcie grails, ale myślałem, że to warto zobaczyć, aby zobaczyć, jak zostały wdrożone. Ogólnie uwielbiam sposób, w jaki budowany jest kod w StatsdClient.scala, bardzo czysty i czytelny. Wygląda na to, że zawiera błąd lokalizacji, ale poza tym funkcja jest kompletna z próbką etsy. Co ciekawe, chyba że jest jakaś magia scala, której nie zrozumiałem, wydaje się, że tworzy ona nowe gniazdo dla każdego punktu danych, który jest wysyłany do StatsD. Chociaż to podejście dobrze unika konieczności tworzenia puli obiektów lub wątków executorów, nie mogę sobie wyobrazić, że jest to bardzo wydajne, potencjalnie wykonując wyszukiwania DNS w wątku żądania, które powinno być jak najszybciej zwrócone do użytkownika.

pytania

1. Sądząc po tym, że wszystkie inne implementacje wydają się mieć inną strategię wdrożone do obsługi współbieżności, mogę założyć, że przykład Etsy jest trochę zbyt naiwny do użytku produkcyjnego?
2. Czy moja analiza wygląda na poprawną?
3. Jakie inne osoby używają statsd w java/groovy?

Do tej pory wygląda na to, że najlepszym istniejącym rozwiązaniem jest wtyczka Grails tak długo, jak długo mogę zaakceptować zależność między wspólnymi zasobami, ale teraz poważnie zastanawiam się nad wydaniem niedzieli, pisząc własną wersję, która łączy najlepsze części. każdej realizacji.

Answer 1

Po spaniu przez tydzień, myślę, że zamierzam użyć istniejącej wtyczki StatsD grails. Uzasadnieniem tego było to, że chociaż udało mi się uzyskać efekt podobny do przy użyciu Executora do obsługi współbieżności, bez korzystania z puli obiektów, byłby on nadal związany z pojedynczą instancją klienta/gniazda, teoretycznie stanowiącą raczej oczywiste wąskie gardło w aplikacji. Dlatego, jeśli i tak będę potrzebować puli, równie dobrze mogę użyć jednego, gdy ktoś inny wykonał całą ciężką pracę :)

Answer 2

Podczas podobnego wyszukiwania dla klienta Java StatsD natrafiłem na StatsD over SLF4J i porównałem go z Java StatsD Client, który wspomniałeś miał kilka problemów. Opierając się na lekturze źródła, wymyśliłem ten podział dotyczący problemów.

EDYCJA: poniższa tabela została zaktualizowana dla wersji 3.0.1 klienta java-statsd, w której rozwiązano wiele pierwotnych problemów.

 
          | java-statsd-client | statsd-over-slf4j 
——————————————————————————+————————————————————————+———————————————————— 
messages support sampling |   yes   |  yes 
——————————————————————————+————————————————————————+———————————————————— 
actual sampling performed | no, left to caller | yes, using java.util.Random 
——————————————————————————+————————————————————————+———————————————————— 
nonblocking impl worker | single daemon thread | single daemon thread 
——————————————————————————+————————————————————————+———————————————————— 
nonblocking impl queue |  unbounded  | caller-specified bound 
——————————————————————————+————————————————————————+———————————————————— 
String.format locale  |   none*   |  Locale.US 
——————————————————————————+————————————————————————+———————————————————— 
charset for message bytes |  UTF-8**   | default, can be overridden 

* no localisation is applied 
** this is the charset that StatsD reads with 

Answer 3

Mówiąc jako podstawowy committer z java-statsd-client, a także kogoś, kto używa tej biblioteki w produkcji, chciałbym spróbować rozwiać swoje obawy dotyczące „mający nieskończoną kolejkę, która wypełnia moje sterty.”

Wydaje mi się, że przygwoździłeś go, analizując przykład klienta Etsy StatsD, gdy powiedziałeś "ze względu na ogień i zapomnij o naturze wysyłania pakietów UDP, powinno to nastąpić szybko, unikając dużego obciążenia, które zwykle kojarzymy z połączenia sieciowe."

Rozumiem, że sposób, w jaki klient java-statsd-client jest obecnie zaimplementowany, ograniczenie tworzenia się dużej kolejki komunikatów wychodzących to szybkość wysyłania pakietów typu "załóż i zapomnij". Nie jestem ekspertem w tej dziedzinie, ale nie jestem świadomy, w jaki sposób może to zablokować tak, że może powstać nieskończona kolejka.

Podczas początkowej oceny wystąpiły pewne nierozstrzygnięte problemy z klientem java-statsd (np. Nieścisłości kodowania znaków/znaków i brak obsługi próbkowania), ale zostały one ostatnio rozwiązane. Pozostaje pytanie, czy istnieje ryzyko zapełnienia sterty. Chciałbym usłyszeć w tej sprawie przemyślenia ze strony społeczności, a jeśli dojdziemy do konsensusu, że istnieje problem, z przyjemnością zbadam wprowadzenie kolejki ograniczającej do biblioteki.