added grafana charts

This commit is contained in:
2019-12-06 20:40:59 +01:00
parent 649b5ec6ab
commit 1b4abb583d
7 changed files with 58 additions and 37 deletions

View File

@ -69,29 +69,50 @@ Korábbi mérések során a prímszámoló függvény egy Python folyamatot hasz
Kíváncsi voltam, egyes mérések során milyen belső állapotai vannak a Knative egyes alegységeinek. Azért, hogy ezeket megfigyelhessem, telepítettem a Knative Monitoring egységét. Ez után újra elvégeztem bizonyos méréseket. Először a prímszámoló függvény viselkedését vizsgáltam meg. Érdekes, hogy a Workeren elérhető húsz magból összesen hetet sem használnak.
%TODO
<grafana-isprime-controllvsdata>
Az \ref{fig:grafana-isprime-controllvsdata} ábrán látható, hogy a függvényt kiszolgáló Podok és a Knative rendszer processzorhasználata hogyan alakul egymáshoz képest. Érdekes, hogy együtt is csupán körülbelül tíz processzormagot használnak. A Control Plane az ábrán a Knative Serving egyes komponenseit, az Istio-t, a monitoring eszközöket és a Kubernetes beépített részeit jelenti. A lenti ábrán látható ezen komponensek között miként oszlik el a processzorhasználat.
A fenti ábrán látható, hogy a függvényt kiszolgáló Podok és a Knative rendszer processzorhasználata hogyan alakul egymáshoz képest. Érdekes, hogy együtt is csupán körülbelül tíz processzormagot használnak. A Control Plane az ábrán a Knative Serving egyes komponenseit, az Istio-t, a monitoring eszközöket és a Kubernetes beépített részeit jelenti. A lenti ábrán látható ezen komponensek között miként oszlik el a processzorhasználat.
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-controllvsdata.png}
\caption{Processzorhaszn\'alat ar\'any\'anak alakul\'asa pr\'imsz\'amol\'o f\"uggv\'eny terhel\'ese sor\'an}
\label{fig:grafana-isprime-controllvsdata}
\end{figure}
%TODO
<grafana-isprime-controlplane-namespaces>
Látszik, hogy a Knative Serving komponense használja leginkább a processzort. A kubectl top parancsot használva azt is sikerült kideríteni, hogy pontosan az Activator nevű komponens miatt emelkedik ki a Knative processzorhasználata. A Knative Activator felel a metrik\'ak autoscaler fel\'e tov\'abb\'it\'as\'a\'ert, valamint inaktiv Revision-\"okh\"oz \'erkező k\'er\'esek bufferel\'es\'e\'ert. A Grafana által generált grafikonok egyikén megfigyelhető, hogy a pánik mód mikor kapcsolt be és meddig tartott. Ez a lenti grafikonon látszik. A pánik mód a specifikáltak szerint viselkedik, \aref{fig:grafana-isprime-controlplane-namespaces} ábrán az is látszik, miként alakult a Podok száma a mérés során.
Látszik, hogy a Knative Serving komponense használja leginkább a processzort. A kubectl top parancsot használva azt is sikerült kideríteni, hogy pontosan az Activator nevű komponens miatt emelkedik ki a Knative processzorhasználata. A Knative Activator felel a metrik\'ak autoscaler fel\'e tov\'abb\'it\'as\'a\'ert, valamint inaktiv Revision-\"okh\"oz \'erkező k\'er\'esek bufferel\'es\'e\'ert. A Grafana által generált grafikonok egyikén megfigyelhető, hogy a pánik mód mikor kapcsolt be és meddig tartott. Ez a lenti grafikonon látszik. A pánik mód a specifikáltak szerint viselkedik, az xy ábrán az is látszik, miként alakult a Podok száma a mérés során.
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-controlplane-namespaces.png}
\caption{Ir\'any\'it\'asi rendszerek processzorhaszn\'alat\'anak alakul\'asa pr\'imsz\'am\'aol\'o f\"uggv\'eny terhel\'ese sor\'an}
\label{fig:grafana-isprime-controlplane-namespaces}
\end{figure}
%TODO
<grafana-isprime-panik>
Az \ref{fig:grafana-isprime-panik} \'es \aref{grafana-isprime-jmeter} \'abr\'akon l\'atszik, hogy a p\'anik m\'od sor\'an l\'etrej\"ottek r\"ovid idő alatt a Podok, majd ut\'ana v\'egig k\"ozel annyi sz\'am\'u Pod volt. Az is megfigyelhető, hogy b\'ar a hosztg\'ep nincs kihaszn\'alva, a f\"uggv\'eny teljes\'itm\'enye degrad\'al\'odott.
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-panik.png}
\caption{Knative p\'anik \'allapot\'anak alakul\'asa pr\'imsz\'amol\'o f\"uggv\'eny terhel\'ese sor\'an}
\label{fig:grafana-isprime-panik}
\end{figure}
%TODO
<grafana-isprime-jmeter>
A fenti k\'et \'abr\'an l\'atszik, hogy a p\'anik m\'od sor\'an l\'etrej\"ottek r\"ovid idő alatt a Podok, majd ut\'ana v\'egig k\"ozel annyi sz\'am\'u Pod volt. Az is megfigyelhető, hogy b\'ar a hosztg\'ep nincs kihaszn\'alva, a f\"uggv\'eny teljes\'itm\'enye degrad\'al\'odott.
A Knative rendszer sz\'amos m\'odon sz\'amontartja a f\"uggv\'enybe \'erkező konkurens k\'er\'esek sz\'am\'at. P\'eld\'aul, mint ahogy az \aref{fig:grafana-isprime-observedconcurrency} \'abr\'an l\'athat\'o, az Average Panic Concurrency egy r\"ovidebb idő alatt sz\'amolt \'atlag, mint ahogy a p\'anik sk\'al\'az\'ashoz sz\"uks\'eges. Az Average Concurrency egy sokkal lassabban v\'altoz\'o \'ert\'ek, ez az, ami az eddigi m\'er\'esek sor\'an ki lett nyerve az autoscaler napl\'of\'ajljaib\'ol. A Target Concurrency \'ert\'ek a YAML \'allom\'anyban be\'all\'itott \'ert\'ek. Az Excess Burst Capacity \'ert\'ek reprezent\'alja a k\"ul\"onbs\'eget a f\"uggv\'eny tartal\'ek kapacit\'asa - mennyi t\"obblet terhel\'est k\'epes a f\"uggv\'eny feldolgozni, mielőtt t\'ulterhelődik - \'es a be\'all\'itott c\'elkonkurencia k\"oz\"ott. Amennyiben ez a sz\'am negat\'iv, az Activator komponensen is \'atmennek a be\'erkező k\'er\'esek.
<grafana-isprime-observedconcurrency>
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-isprime-observedconcurrency.png}
\caption{Knative \'altal sz\'amolt konkurencia \'ert\'ekek}
\label{fig:grafana-isprime-observedconcurrency}
\end{figure}
A Knative rendszer sz\'amos m\'odon sz\'amontartja a f\"uggv\'enybe \'erkező konkurens k\'er\'esek sz\'am\'at. P\'eld\'aul, mint ahogy az a fenti \'abr\'an l\'athat\'o, az Average Panic Concurrency egy r\"ovidebb idő alatt sz\'amolt \'atlag, mint ahogy a p\'anik sk\'al\'az\'ashoz sz\"uks\'eges. Az Average Concurrency egy sokkal lassabban v\'altoz\'o \'ert\'ek, ez az, ami az eddigi m\'er\'esek sor\'an ki lett nyerve az autoscaler napl\'of\'ajljaib\'ol. A Target Concurrency \'ert\'ek a YAML \'allom\'anyban be\'all\'itott \'ert\'ek. Az Excess Burst Capacity \'ert\'ek reprezent\'alja a k\"ul\"onbs\'eget a f\"uggv\'eny tartal\'ek kapacit\'asa - mennyi t\"obblet terhel\'est k\'epes a f\"uggv\'eny feldolgozni, mielőtt t\'ulterhelődik - \'es a be\'all\'itott c\'elkonkurencia k\"oz\"ott. Amennyiben ez a sz\'am negat\'iv, az Activator komponensen is \'atmennek a be\'erkező k\'er\'esek.
Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését. Az \ref{fig:grafana-hello-controllvsdata} \'abr\'an megfigyelhető, hogy ez esetben a Control Plane processzorhaszn\'alata t\"obb volt, mint a Data Plane-\'e. A m\'er\'es sor\'an ez esetben is romlott a monitoring rendszer telep\'it\'ese ut\'an.
Másodikként az echo típusú függvény terhelése alatt vizsgáltam meg a Knative belső működését. A lenti \'abr\'an megfigyelhető, hogy ez esetben a Control Plane processzorhaszn\'alata t\"obb volt, mint a Data Plane-\'e. A m\'er\'es sor\'an ez esetben is romlott a monitoring rendszer telep\'it\'ese ut\'an.
%TODO
<grafana-hello-controllvsdata>
\begin{figure}[!ht]
\centering
\includegraphics[width=120mm, keepaspectratio]{figures/grafana-hello-controllvsdata.png}
\caption{Processzorhaszn\'alat ar\'any\'anak alakul\'asa echo t\'ipus\'u f\"uggv\'eny terhel\'ese sor\'an}
\label{fig:grafana-hello-controllvsdata}
\end{figure}