Resolve #4 (wörk)
Clemens Klug
parent
d34c9fc4bc
commit
dc89b1e5fc
|
|
@ -27,3 +27,20 @@ New components
|
|||
\item Interface (Configuration)
|
||||
\item Cross-game comparisons
|
||||
\end{itemize}
|
||||
|
||||
\section{Requirements}\label{sec:require} %TODO
|
||||
Wait, what did I want to do again?
|
||||
\begin{itemize}
|
||||
\item Per-game importer (Web client, File loader, …)
|
||||
\item Analyzer modules (number crunching)
|
||||
\item Output \& Visualization (CSV, [Geo]JSON, KML, Graphs, …)
|
||||
\item Interface (Configuration)
|
||||
\begin{itemize}
|
||||
\item Expert users/researchers
|
||||
\item Staging/designing staff
|
||||
\end{itemize}
|
||||
\item Cross-game comparisons
|
||||
\item Integration of external data (questionnaire results)
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,21 +1,9 @@
|
|||
|
||||
\section{Requirements}
|
||||
Wait, what did I want to do again?
|
||||
\begin{itemize}
|
||||
\item Per-game importer (Web client, File loader, …)
|
||||
\item Analyzer modules (number crunching)
|
||||
\item Output \& Visualization (CSV, [Geo]JSON, KML, Graphs, …)
|
||||
\item Interface (Configuration)
|
||||
\begin{itemize}
|
||||
\item Expert users/researchers
|
||||
\item Staging/designing staff
|
||||
\end{itemize}
|
||||
\item Cross-game comparisons
|
||||
\item Integration of external data (questionnaire results)
|
||||
\end{itemize}
|
||||
With an administrative background, the first approach to log processing which comes to mind are the various log processing frameworks.
|
||||
The following chapter \autoref{sec:logproc} takes a dive into this world and evaluates the feasability of two such system for the scope of this thesis.
|
||||
Based on the findings, an alternative approach is then outlined in \autoref{sec:alternative-design}.
|
||||
|
||||
|
||||
\section{Evaluating log processing solutions}
|
||||
\section{Evaluating log processing solutions}\label{sec:logproc}
|
||||
This chapter looks into the possibilities of existing log processing solutions.
|
||||
By example, Kibana with an Elastic Search backend and Grafana with an InfluxDB will be evaluated.
|
||||
|
||||
|
|
@ -41,10 +29,9 @@ Grafana is a solution to analyze, explore, and visualize various source of time
|
|||
There exist plugins for nearly any storage and collection backend for metrics\furl{https://grafana.com/plugins?type=datasource}.
|
||||
The different backends are available through a unified user interface shown in \autoref{img:grafana}.
|
||||
|
||||
Spatial resolution suffers under similar conditions compared to Kibana, with even lower spatial resolution as shown in \uatoref{img:grafana-spatial}.
|
||||
Spatial resolution suffers under similar conditions compared to Kibana.
|
||||
\autoref{img:kibana} shows by example the restrictions by the query language/query editing interfaces in the domain of weather stations.
|
||||
|
||||
\image{\textwidth}{grafana-spatial}{Spatial resolution in Grafana}{img:grafana-spatial}
|
||||
\image{\textwidth}{grafana-metrics}{Configuring a graph in Grafana}{img:grafana}
|
||||
|
||||
|
||||
|
|
@ -55,10 +42,11 @@ The privacy concerns vital in web monitoring prohibit detailed spatial analyzes,
|
|||
|
||||
Regarding the specified use cases, expecially the non-expert users benefit from a simple to use interface.
|
||||
The default Kibana worchbench does not qualify for this, a custom interface could improve the situation.
|
||||
Grafana does have support for shared dashboards with a fixed set of data, %TODO
|
||||
Grafana does have support for shared dashboards with a fixed set of data, however precise spatial support is still lacking.
|
||||
A third party plugin recently does provide such support\furl{https://github.com/CitiLogics/citilogics-geoloop-panel}, unfortunately it missed the timeframe during the evaluation of grafana for this thesis.
|
||||
Such a plugin would still be a possibly fragile component given the fast pace of web development shown by these kind of projects.
|
||||
|
||||
|
||||
\section{Architectural Design}
|
||||
\section{Architectural Design}\label{sec:alternative-design}
|
||||
\subsection{Overview}
|
||||
While the development of a custom stack requires a lot of infrastructural work to get the project running, the learnings above give points to build a custom solution as a feasible alternative:
|
||||
\begin{itemize}
|
||||
|
|
@ -152,35 +140,3 @@ By acting like any normal client, the framework can avoid obstacles like CORS/XS
|
|||
|
||||
The independence to user interfaces, mainly the web interface, allows scalability through load-balancing with mulitple API workers.
|
||||
Expert users with special requirements can embed the framework in projects without pulling in large amounts of dependencies for user interfaces or games/game servers.
|
||||
\begin{comment}
|
||||
|
||||
|
||||
\subsection{old}
|
||||
Game independance:
|
||||
\begin{itemize}
|
||||
\item log importer/transformer necessary
|
||||
\end{itemize}
|
||||
\begin{itemize}
|
||||
\item Based on map-reduce
|
||||
\item Map: Analysis
|
||||
\begin{itemize}
|
||||
\item Iterate Log entries
|
||||
\item Feed log entry through analyzer queue
|
||||
\begin{itemize}
|
||||
\item Augment entries
|
||||
\item Filter entries
|
||||
\item Sequential order
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item Reduce: Collect summaries from analyzers
|
||||
\begin{itemize}
|
||||
\item Rendering
|
||||
\item Post-processing, Comparison, …
|
||||
\end{itemize}
|
||||
|
||||
\item standalone (indep. of any game)
|
||||
\item own client for game server (due to CORS/XSS prevention prohibiting shared use of game server assets in other host)
|
||||
\item API for integration
|
||||
\item allow load distribution
|
||||
\end{itemize}
|
||||
\end{comment}
|
||||
|
|
@ -228,19 +228,3 @@ When a scenario with high load occurs, this definition allows for simple scaling
|
|||
To create more celery worker nodes, issuing the command \textit{docker-compose scale worker=8} suffices to create 8 worker containers running in parallel.
|
||||
|
||||
\image{\textwidth}{architecture.pdf}{Service composition overview}{img:arch}
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Examples} %TODO ?!?!
|
||||
Configuration \& results
|
||||
%\twofigures{0.5}{../../PresTeX/images/oeb-kml}{Analyzer configuration}{img:oebkml}{../../PresTeX/images/oeb-ge}{Result visualized}{img:oebge}{Example: Generate KML tracks (BioDiv2Go; Oberelsbach2016)}{fig:oeb2016}
|
||||
|
||||
|
||||
ActivityMapper
|
||||
\image{.7\textwidth}{../../PresTeX/images/track-fi}{Combined screen activity and spatial progress}{img:trackfi}
|
||||
|
||||
|
||||
Graphs
|
||||
\image{\textwidth}{../../PresTeX/images/speed}{Speed distribution}{img:speed}
|
||||
\image{.9\textwidth}{../../PresTeX/images/time-rel}{Time distribution}{img:time}
|
||||
|
|
|
|||
|
|
@ -15,8 +15,22 @@
|
|||
\lstinputlisting[language=yaml,caption={Dockerfile for Biogames server},label=code:bd2d]{code/biogames/Dockerfile}
|
||||
\lstinputlisting[language=bash,caption={Entrypoint for Biogames docker container},label=code:bd2e]{code/biogames/start.sh}
|
||||
\subsection{Traefik reverse proxy}\label{app:traefik}
|
||||
\lstinputlisting[language=yaml,caption={Dockerfile for Traefik reverse proxy},label=code:bd2t]{code/traefik.yml}
|
||||
\lstinputlisting[language=toml,caption={Traefik reverse proxy configuration},label=code:bd2toml]{code/traefik.toml}
|
||||
\lstinputlisting[language=yaml,caption={Docker-compose file for Traefik reverse proxy},label=code:bd2t]{code/traefik.yml}
|
||||
\lstinputlisting[language=yaml,caption={Traefik reverse proxy configuration (traefik.toml)},label=code:bd2toml]{code/traefik.toml}
|
||||
|
||||
\subsection{Geogame Log Analysis project setup}\label{app:dcs}
|
||||
\lstinputlisting[language=yaml,caption={Docker-compose file for Geogame Log Analysis project},label=code:gglap]{code/project.yml}
|
||||
|
||||
\section{TODO}
|
||||
\subsection{Examples} %TODO ?!?!
|
||||
Configuration \& results
|
||||
%\twofigures{0.5}{../../PresTeX/images/oeb-kml}{Analyzer configuration}{img:oebkml}{../../PresTeX/images/oeb-ge}{Result visualized}{img:oebge}{Example: Generate KML tracks (BioDiv2Go; Oberelsbach2016)}{fig:oeb2016}
|
||||
|
||||
|
||||
ActivityMapper
|
||||
\image{.7\textwidth}{../../PresTeX/images/track-fi}{Combined screen activity and spatial progress}{img:trackfi}
|
||||
|
||||
|
||||
Graphs
|
||||
\image{\textwidth}{../../PresTeX/images/speed}{Speed distribution}{img:speed}
|
||||
\image{.9\textwidth}{../../PresTeX/images/time-rel}{Time distribution}{img:time}
|
||||
|
|
@ -7,10 +7,10 @@
|
|||
\chapter{forschungsstand}
|
||||
\input{content/2-state-of-the-art}
|
||||
|
||||
\chapter{lösungsansatz}
|
||||
\chapter{Solution approach}\label{sec:solution}
|
||||
\input{content/3-solution}
|
||||
|
||||
\chapter{umsetzung}
|
||||
\chapter{Implementation}
|
||||
\input{content/4-implementation}
|
||||
|
||||
\chapter{evaluierung}\label{sec:eval}
|
||||
|
|
|
|||
|
|
@ -9,4 +9,5 @@ t [label="HTTP frontend\nTraefik"];
|
|||
s -- db [];
|
||||
c -- db [label="Internal network"];
|
||||
t -- s [label=" External network,\nlabel"];
|
||||
s -- c [label="Shared volume"];
|
||||
}
|
||||
|
|
@ -50,6 +50,7 @@
|
|||
\selectlanguage{english}
|
||||
\setstretch{1.1}
|
||||
%% Titelseite
|
||||
\hypersetup{pageanchor=false}
|
||||
\maketitle
|
||||
|
||||
%% Seitenlayout
|
||||
|
|
@ -75,6 +76,7 @@
|
|||
%\printnomenclature %TODO
|
||||
|
||||
\cleardoubleemptypage
|
||||
\hypersetup{pageanchor=true}
|
||||
\pagestyle{scrheadings}
|
||||
\pagenumbering{arabic}
|
||||
\setcounter{page}{1}
|
||||
|
|
|
|||
Loading…
Reference in New Issue