Telemetrie - jak jí implementovat, vzor rubrika: Folklór

4 pilif
položil/-a 20.3.2018

Zdravím ve spolek,
zvažujeme u nás implementaci sběru telemetrických dat v naší aplikaci.
Jde nám momentálně primárně o toto:

  • nejčastěji prováděné úkony uživatelů
  • mapa pohybu uživatelů
  • čas, který uživatel strávil na dané operaci (aktivní formulář)
  • čas zpracování vybraných operací

Zatím jen zkoumám možná řešení a nějak nevím čeho se chytit. Nechci vymýšlet kolo...
Hrubá představa je, že by to bylo něco na principu logování, ale s pevně danou strukturou pro lepší katalogizaci či výstupy. Současně by to mělo aplikaci minimálně vytěžovat, takže snad nějaká servisa v jiném procesu/vlákně čekající na příchozí data a vždy v nějaký intervalech odesílající do centrálního uložiště.

Pro upřesnění jde o .NET aplikaci typu klient server. Tenký klient je WPF a aplikační server WebAPI na IIS.

Mohu poprosit o nějaké nakopnutí správným směrem? Nic takového jsem ještě nedělal a současně mi google zatím moc nepomohl (asi používám špatná klíčová slova :))

Díky.

Komentáře

  • plelovsky : Telemetrie se to nejspíš nenazývá. Telemetrie je technologie umožňující měření na dálku a dálkový přenos dat (https://cs.wikipedia.org/wiki/Telemetrie). Spíš bych hledal monitoring, performance monitor apod. 21.3.2018
odkaz
7 harrison314
odpověděl/-a 21.3.2018
 
upravil/-a 21.3.2018

Ak na serveri alebo v klientskej aplikacii pouzivate IoC kontainer, tak klucove slovo je interceptor, proxy triedy, dekorator. Do nich zapuzdris logovanie a logiky sa nechytas. Je to v podstate forma AOP, ale funguje aj s cudzim kodom.

Tu je ukazka s Windsor Castle https://www.codeproject.com/Articles/1080517/Aspect-Oriented-Programming-using-Interceptors-wit.

A tu je ukazka pre Simple Injector s mojou vlastnou kniznicou https://github.com/harrison314/MassiveDynamicProxyGenerator#massivedynamicproxygeneratorsimpleinjector.

Ak nepouzivas ziaden IoC kontainer, tak potom to musis napisat rucne, co je otrava.
Este sa odporucam pozriet na Application Insights, ktre riesi to co potrebujes (ide to pouzit aj pri lokalnom vyvoji).
Este dalsie klucove slovo je "performance counters".

Komentáře

  • pilif : IoC používám (Windsor). Ty odkazy jsou výborné, určitě je využiji, ale asi jsem špatně položil otázku. Spíše se mi jednalo o nějaký koncept co všechno a v jakém tvaru sbírat, kde si co udržovat v aplikaci a kam to ukládat. Což asi v odpovědích také najdu :) Upřímně řečeno trochu jsem "tápal". 24.3.2018
  • harrison314 : Tieto logy, by som urcite oddelil od aplikacnych logov, a ake zvolit a kam, to je realne problem, no to si musite zvazit sami. Mozem pridat len par svojich skusnoti. vazne treba zvazit co a ako logovat, obcas robim zoserverovou aplikaciu ktora loguje GB dat za hodinu, ale ie je z nich mozne zistit takmer nic. Takisto logovanie suvych nestrukturovanych logov do SQL databazy je problem. Tu by som odporucal skor NoSql databazu(napr. MongoDB) a s nej pumpovat data pre statitky do SQL databazy. Dalej na nete som cital chvali o Kibane a Elastic Stacku, tak som to vo firme pretlacil, no vyvsledku sa po pol roku ten server vypol, bolo to neskutocne pomale, nenazrdane na ramku a disky, Kibane vtedy chbali potrebne funkcie na nejake zgrupovanie vysledkov a okrem pomaleho UI to neprinieslo nic. V samotnych logoch je ale velmi dolezite pripajat ich kontext (pouzivatel, jeho operacia, request, session,...) aby sa dal zopakovat jeho pohyb po aplikacii. To co bude v samotnych logoch velmi zalezi, co a ako chces vo vysledku sledovat. 24.3.2018
  • harrison314 : Pokial nie je daco jasne este sa pytaj. 27.3.2018

Pro zobrazení všech 2 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.