Open main menu

Changes

Openshift - HAproxy metrics EN

2,001 bytes removed, 10:42, 25 January 2020
no edit summary
[[Openshift - HAproxy metrics|Openshift - HAproxy metrics HU]]
:[[File:ClipCapIt-190807-102633.PNG]]
<br>
=== Http test application ===
To generate the For generating http traffic, I made a test application that can generate arbitrary different response time and http response code requestscodes. Source available at here: https://github.com/berkiadam/haproxy-metrics/tree/master/test-app
The Kubernetes install files can be found at the root of the git repository.
Once installed, After installation use the app is available atapplication based on the following:
* http://test-app-service-mynamespace.192.168.42.185.nip.io/test/slowresponse/ <delay in millisecundum>
* http://test-app-service-mynamespace.192.168.42.185.nip.io/test/slowresponse/ <delay in milliseconds> / <http response code>
<br>
=Using HAproxy metrika végpont használataMetric Endpoint=A HAproxyhas a built-nak van beépített metrika végpontjain metric endpoint, ahol alapértelmezetten which by default provides Prometheus szabványú metrikákat szolgáltat (tud még CSV-tis)metrics, but most of its metrics are not really usable. Az így nyert metrikák nagy része nem igazán értelmes metrikákThere are two metric types that are worth mentioning. Két olyan metrikát tudunk innen kinyerniOne of them counts the responses with 200 http code, ami mindenképpen figyelendő prometheus-ban, ezek a hibás és 200-as válaszok számlálói backend-ekre lebontvaand the other counts the responses with 500 (bad request).
A metrikákat lekérdező végpont The metric endpoint (/metrics) alapból is turned on by default. This can be van kapcsolva. Ezt ki lehet kapcsolniturned off, de attól még gyűjteni fogja a metrikákat a but HAProxywill still collect metrics in the background. A The HAproxy pod két komponensből épül felis made up of two components. Az egyik maga a One is HAproxy a másik a itself and the other is the router-controller ami a that manages the HAproxy konfigurációját kezeliconfiguration. A metrikákat mind a két komponensről Metrics are collected from both components every 5 másodpercenként gyűjti be a metrika kezelőseconds by the metric manager. A metrikák között vannak frontend és Frontend and backend metrikák is külön szolgáltatásonként összegyűjtvemetrics are both collected, grouped by services.
:[[File:ClipCapIt-190808-094455.PNG|600px]]
<br>
==Metrikák lekérdezéseQuery Metrics ==A metrikák lekérdezésére két lehetőség vanThere are two ways to query metrics. # felhasználó név Basic authentication with username + jelszó használatapassword: Basic authentikácóval a /metrics végpontot meghívva le lehet kérdezni a metrikákat. http endpoint# Authentication with Kubernetes RBAC szabályok definiálása a megfelelő serviceAccount -hozRules: Gépi feldolgozásra For machine processing (e.g. in Prometheus) lehetőség van rá, hogy it is possible to enable RBAC szabályokkal engedélyezzük egy adott rule based authentication for a given service-account-nak hogy lekérdezze a metrikákat.
<br>
===User + jelszó alapú lekérdezés password based authentication ===
Felhasználó név alapú lekérdezés esetén az alapértelmezett metrika The default metrics URL az alábbiis:
<pre>
http://<user>:<password>@<router_IP>:<STATS_PORT>/metrics
A metrika The user, jelszó és password, and port a can be found in the in the service definition for the HAproxy router-hez tartozó service definíciójában van. Ehhez elsőként meg kell keresni a router-hez tartozó service-t:
<pre>
# kubectl get svc -n default
router ClusterIP 172.30.130.191 <none> 80/TCP,443/TCP,1936/TCP 4d
</pre>
LáthatjukYou can see that there is an extra port listed upon the default 80 and 433, hogy az which is the '''1936'''-os porton ,that is hallgatózik, ez a metrika végpontjának a portjathe port of the metrics endpoint.
Most nézzünk bele a Now, let's examine the definition of the service definíciójába, hogy megkapjuk a user és pass-t isto extract the username and password:
<source lang="C++">
# kubectl get svc router -n default -o yaml
Ennek függvényébenAccording to this, a the URL of the metrics endpoint using the node 's IP címét felhasználva, address (minishfit IPin the example) a metrika URL az alábbiis the following: http://admin:4v9a7ucfMi@192.168.42.64:1936/metrics (ezt böngészőben nem lehet meghívniYou can't invoke this URL in web-browsers as they aren't familiar with this format, mert nem ismerik ezt a formátumotuse curl for testing it in the command line)
<pre>
# curl admin:4v9a7ucfMi@192.168.42.64:1936/metrics
 
# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.
===ServiceAccount alapú lekérdezésbased authentication ===Lehetőség van rá, hogy ne csak It is possible to query the HAproxy metrics not only with basic authentication-el kérdezzük le a HAproxy metrikákat, hanem but also with RBAC szabályokkalrules.
 Készíteni kell egy olyan We need to create a '''ClusterRole'''that allows the Prometheus service-t ami megengedi hogy lekérdezést kezdeményezzünk a account to query the '''routers/metrics''' végponton. Ezt később össze fogjuk rendelni a prometheus-t futtató serviceAccount-alendpoint.
<br>
'''cr-prometheus-server-route.yaml'''
Második lépésben készíteni kell egy The second step is to create a '''ClusterRoleBinding'''-ot, ami összerendeli a prometheus-hoz tartozó that binds the Prometheus serviceAccount-ot a fenit with the new role-al.
<br>
'''crb-prometheus-server-route.yaml'''
namespace: mynamespace
</source>
Hozzuk létre a két feni objektumotLet's create the two new objects:
<pre>
# kubectl apply -f cr-prometheus-server-route.yaml
<br>
==Prometheus integrációintegration==
 Keressük meg router-ekhez tartozó Lets examine the '''Endpoint''' definíciótdefinition of the HAproxy router. Ezt fogjuk hozzáadni a prometheus konfigurációhozBased on that, amivel az összes router pod-ot meg tudja majd keresniwe can create the Prometheus configuration that will be responsible for finding runtime all the pods running HAproxy instances. Olyan We have to find the OpenShift endpoint-t fogunk keresni, aminek a neve object with the name '''router''' és van that have a port definition called '''1936-tcp''' nevű portja, amin keresztül le fogjuk kérdezni az alapértelmezett metrika végponton . Prometheus will extract the port number for the metrics query form this port-definition (/metrics) keresztül a HAproxy metrikákat.
<pre>
# kubectl get Endpoints router -n default -o yaml
<br>
<br>
A In the Promethues konfigurációba hozzá kell adni egy új configuration, you need to add a new '''target'''-et, amiben with '''kubernetes_sd_configs'''-al keressük meg azt az Endpoint-ot, aminek a neve that will look for endpoints with the name '''router''' és van and with the port '''1936-tcp''' nevű portja. <presource lang="c++">
- job_name: 'openshift-router'
scheme: https
action: keep
regex: router;1936-tcp
</presource> 
Frissítsük a Prometheus konfigurációját tartozó Update the '''''ConfigMap'''-etof your Prometheus configuration.
<pre>
# kubectl apply -f cm-prometheus-server-haproxy.yaml
</pre>
 
Nézzük meg a promethues pod-ban, hogy a konfiguráció újra lett e már töltve:
<pre>
# kubectl describe pod prometheus-server-75c9d576c9-gjlcr -n mynamespace
Containers:
prometheus-server-configmap-reload:
...
prometheus-server:
</pre>
A Let's look into the logs of the side card container running in the Promethues pod-ban futó side card konténerbe nézzük meg a logokat (ez felelős a konfiguráció újra töltéséértresponsible for reloading the configuration). Látnunk kell, hogy újra töltötte a konfigurációt.
<pre>
# kubectl logs -c prometheus-server-configmap-reload prometheus-server-75c9d576c9-gjlcr -n mynamespace
</pre>
 Ugyan ezt látni kell, ha a promethues server konténerének a logját nézzükLets check the Prometheus logs as well:
<pre>
# kubectl logs -c prometheus-server prometheus-server-75c9d576c9-gjlcr -n mynamespace
...
level=info ts=2019-07-22T20:25:36.016Z caller=main.go:730 msg="Loading configuration file" filename=/etc/config/prometheus.yml
</pre>
Ezek utánNext, ha megnyitjuk a open the Promethues console and navigate to the 'target oldalt a konzolon' page: http://mon.192.168.42.185.nip.io/targets:[[File:ClipCapIt-190722-233253.PNG]]<br>Ha több router lenne a klaszterbenIf there were more routers in the cluster, akkor azok mind feltűnnének itt mint külön végpontokthey would be all listed as separate endpoints. <br>
<br>
 
<br>
<br>==Metrika fajtákMetric types==http://people.redhat.com/jrivera/openshift-docs_preview/openshift-origin/glusterfs-review/architecture/networking/haproxy-router.html<br>
Első ránézésre két értelmes metrikát találhatunk a At first glance, there are two meaningful metrics provided by the HAproxy repertoárjában. Ezek az alábbiakThese are the following:
<br>
===haproxy_server_http_responses_total===Megmutatja backend-enként hogy hángy It is a Prometheus counter, shows how many 200-as és hány and 500-as http státuszú választ adott egy adott replies a given servicegave per backend. Itt nincs pod alapú bontásIt is on service level only. Sajnos a Unfortunately, we do not receive information on http 300 és and 400-as hibákról nem kapunk információterrors. Ezeket is majd az We will also get these from the access log-ból tudjuk kinyerni
<br>
<br>
Generáljuk Let's generate a teszt alkalmazással egy 200-as választanswer using the test application. Látunk kell, hogy a We need to see the counter egyel megnőof the 200 responses grows by one: http://test-app-service-mynamespace.192.168.42.185.nip.io/test/slowresponse/1/200
<pre>
haproxy_server_http_responses_total{code="2xx",jobJob ="openshift-router",namespace="mynamespace",pod="testbody-app",route="testbody-app-service",service="testbody-app-service"} 1
</pre>
<br>
Generáljuk Let's generate a teszt alkalmazással egy 500-as választresponse using the test application again. Látunk kellThis time, hogy a the counter egyel megnőof the 500 responses grows by one: http://test-app-service-mynamespace.192.168.42.185.nip.io/test/slowresponse/1/500
<pre>
haproxy_server_http_responses_total{code="5xx",job="openshift-router",namespace="mynamespace",pod="testbody-app",route="testbody-app-service",service="testbody-app-service"} 1
</pre>
<br>
===haproxy_server_response_errors_total===Counter type
<pre>
haproxy_server_response_errors_total{instance="192.168.122.223:1936",job="openshift-router",namespace="mynamespace",pod="test-app-57574c8466-pvcsg",route="test-app-service",server="172.17.0.17:8080",service="test-app-service"}
<br>
=Metrikák gyűjtése logokbólCollecting metrics from the access logs=
==Overview==
The task is to process the access log of HAproxy with a log interpreter parser and generate Prometheus metrics that must be made are available to for Prometheus at through an HTTP endpoint. We will use the grok-exporter tool, which can do this in one personboth. It can read logs from a file or stdin and generate metrics from itbased on the logs. The grok-exporter will receive the logs from HAproxy via a packaged an rsyslog server. Rsyslog puts will put logs into a file from which grok-exporter will be able to read them. Grok-exporter converts logs into promethues metrics.
Necessary steps: * You need We have to create a docker image from grok-exporter that has rsyslogin the image. (The container must be able to run the rsyslog server as root, which requires extra openShfit configuration.)* The grok-exporter image must configuration will be run on in OpenShfit with both the grok-exporter configuration configured in ConfigMap and the rsyslog workspace with must be an OpenSfhit OpenShift volume.(writing a containers file system in runtime is really inefficient) * For grok-exporter deployment, you need We have to create a ClasterIP-type service that can perform load-balancing between grok-exporter pods.* Routers (The HAproxy) routers should be configured to log write access logs in debug mode and send them to the resulting access log remote rsyslog server running next to port 514 of the grok-exporter service.* The rsyslog server running on in the grok-exporter pod puts will both write the received HAproxy access logs into the file ('' '/ var / log / messages' '(' - emptyDir type volume) and sends it them to' '' stdout ''' as well for central log processing.* Logs written to stdout will be collected picked up by the docdocker-log-driver and forwarded to the centralized log architecture.(log retention) * The grok-exporter program reads '' '/ var / log / messages' '', and generates prometheus Prometheus metrics from its the HAproxy access-logs.* The configuration of promethues should Prometheus scrape config has to be configured to use extended with a '' 'kubernetes_sd_configs' '' to section. Prometheus must collect the metrics directly invoke from the grok proxy -exporter pods to collect the metric, not to go through the Kubernetes service to bypass load-balancing, since everything pod needs to be queried.
<br>
==HAproxy log struktúrastructure==
https://www.haproxy.com/blog/introduction-to-haproxy-logging/
<br>
A HAproxy az alábbi provides the following log struktúrát produkálja minden egyes structure for each request-response párhozpair:
<pre>
Aug 6 20:53:30 192.168.122.223 haproxy[39]: 192.168.42.1:50708 [06/Aug/2019:20:53:30.267] public be_edge_http:mynamespace:test-app-service/pod:test-app-57574c8466-qbtg8:test-app-service:172.17.0.12:8080 1/0/0/321/321 200 135 - - --NI 2/2/0/1/0 0/0 "GET /test/slowresponse/1 HTTP/1.1"
<br>
Teljes specifikációFull specification: https://github.com/berkiadam/haproxy-metrics/blob/master/ha-proxy-log-structure.pdf
<br>
<br>
==introduction of grok-exporter bemutatása==A grokGrok-exporter egy olyan eszköz, ami logokat képes reguláris kifejezések alapján feldolgozni, amiből elő tudja állítani is a tool that can process logs based on regular expressions and convert them to one of the 4 alapvető prometheus metrika típustbasic Prometheus metrics:
* gauge
* counter
* kvantilis
A metrikához tetszőleges számú címkét tudunk beállítani a parszolt logsor elemeit felhasználva. A grokGrok-exporter a is based on '''logstash-grok''' implementációján alapul, a and grok-exporter is using patterns and functions defined for logstash-ben definiált patterneket és függvényeket használja.
Részletes dokumentáció ittDetailed documentation: <br>
https://github.com/fstab/grok_exporter/blob/master/CONFIG.md<br>
<br>
A The grok-exporter háromféle inputot tud kezelnican read form three types of input sources:* '''file''': mi ezt fogjuk használni, az rsyslog által írt log-ot fogja feldolgozni. we will stick to this* '''webhook''': Ez a megoldás is használható lenne, ha This solution could also be used with logstash used as rsyslog szervernek a logstashserver. Logstash can send the logs to the grok-t használnánk fel, majd a exporter webhook with the logstash '''plugin "http-output''' plugin-el webhook-on tovább küldenénk a grok-exporter-nek. "* '''stdin''': Az With rsyslog-al az , stdin is használható lennecan also be used. Ehhez az This requires the use of the ''' omprog''' programot kell használni. Az omprog képes program, that can read data from sockets and pass on data through stdin-en átadni egy programnak azt amit rsyslog socket-ről olvas. A programot az omprog újra fogja indítani ha már nem fut. : https://www.rsyslog.com/doc/v8-stable/configuration/modules/omprog.html
<br>
===Alternatív megoldásokAlternative Solutions ==='''Fluentd''':<br>A '''To achieve the same goal with fluentd'''-vel is megoldható a feladat. Ehhez három , we would need three fluentd plugin-t kell használni (ezt nem probáltam ki)plugins:
* fluent-plugin-rewrite-tag-filter
* fluent-plugin-prometheus
'''mtail''':<br>
A másik alternatíva a The other alternative solution would be google 's '''mtail''' projektje lenne, ami állítólag erőforrás hatékonyabban lenne képes feldolgozni a logsorokat mint a which is said to be more efficient in processing logs than the grok motorengine. <br>
https://github.com/google/mtail
<br>
===Config fájlConfiguration file===A The configuration of grok-exporter konfigurációja a can be found in '''/etc/grok_exporter/config.yml''' fájlban van. There are 5 részre osztható sections.
* global:
* input: Megmondja, hogy honnan és hogyan olvassa Tells you where and how to retrieve logs. Can be a logokat. Lehet stdin, file és and webhook. Mi a We will use file inputot fogjuk használniinput. * grok: A Location of the grok patternek helyepatterns. A Docker image-ben ez a Pattern definition are stored in /grok/patterns mappa leszfolder by default. * metrics: Ez a legfontosabb részThis is the most important part. Itt kell egyenként definiálni a metrikákat és a hozzá tartozó reguláris kifejezést (grok patternek formájában)Here you need to define the metrics and the associated regular expression* server: Milyen porton hallgatózzon a szerverContains the port of the http metrics server.
<br>
====Metrics====
A metrikákat metrika típusonként kell definiálniMetrics must be defined by metric types. A négy alapvető prometheus metrika típus támogatottThe four basic types of Prometheus metrics are supported: '''Gauge, Counter, Histogram, Summary''' (kvantilisquantile) A típus alatt meg kell adni<br>Each definition contains 4 parts: * name: ezen a néven fog szerepelni a metrikaThis will be the name of the metric* help: Ez lesz a metrika This is the help szövegetext for the metric. * match: Itt kell leírni reguláris kifejezés szerűen Describes the structure of the log string in a logsor szerkezetét amire illeszkedni kell a metrikáknakregular expression style format. Itt Here you can use pre-defined grok patterneket lehet használni, amik előre definiáltakpatterns: ** '''ALAP BASIC grok patternekpatterns''': https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns
** '''HAROXY patterns''': https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/haproxy
 * label: A találati csoportoknak lehet nevet adni. A névre lehet hivatkozni a label szekcióban, amiből létre fog hozni egy olyan címkét, aminek az értéke a parsolt adat leszHere we can add Prometheus labels to the metrics.
<br>
====matchdefinition====A Grok assumes that each element is separated by a single space in the source log files. In the match-ben fel kell írni egy reguláris kifejezést grok építő kockákból. Azt feltételezzüksection, hogy az egyes elemeket you have to write a log-ban egy szünet választja elregular expression using grok building blocks. Minden egyes építő kocka Each building block has the format: '''%{PATTERN-NÉVPATTERN_NAME}''' alakú, ahol a PATTERN-NÉV-nek léteznie kell valamelyik where PATTERN_NAME must be an existing predefined grok pattern gyűjteményben. A legáltalánosabb típus a The most common type is '''%{DATA}''', ami egy tetszőleges adatstruktúrára vonatkozik, ami nem tartalmaz szünetetwhich refers to an arbitrary data structure that contains no withe-space. There are several compound patterns that are build up from basic grok patterns. Több olyan pattern is van, ami több elemi pattern-ből van kombinálvaWe can assign the regular expression result groups to named variables that can be used as the value of the Prometheus metric or as label values. Ha azt akarjuk hogy a The variable name must be placed inside the curly bracket of the pattern-el leírt reguláris kifejezésből találati csoport is képződjön, nevet kell adni separated by a patternek, plsemicolon from the patter name:
<pre>
%{DATA:this_is_the_name}
</prePre>Ekkor pattern-el megtalált mező értéke bele fog kerülni a The result of the regular expression will be assigned to the variable '''this_is_the_name''' változóba, amire lehet hivatkozni a metrika értékének a meghatározásánál illetve a címke legyártásnálwhich can be referenced when defining the value of the Prometheus metric or the metrics label.
<br>
 ====labelsdefinition ====A In the label section we can define labels szekcióban nevesített for the generated Prometheus metric. The labels are defined with a name:value list, where the value can be a string constant or a variable defined for a patternin the match section. The variable must be referenced in go-ekre lehet hivatkozni. Ekkor az adott logsorból parszolt mező értékét fogja adni template style between double curly brackets starting with a definiált címkénekdot. Pl. a For example, if we used the '''%{DATA:this_is_the_name}''' pattern használata esetén felírhatjuk a következő címkétin the match section, we can define the 'mylabel' Prometheus label with the value of the 'this_is_the_name' variable in the following way: <br>
<pre>
mylabel: '{{.this_is_the_name}}'
</prePre>Ekkor, ha a %{DATA} pattern által leírt mező értéke Lets assume that the 'this_is_the_name' variables value is 'myvalue' volt, akkor a metrikára rá fog kerülni egy ilyen címke. Then the metric would receive the following label: '''{mylabel="myvalue"}'''<br>Nézzünk egy példát: We are going to demonstrate a full, metric definition example in the following section <br>Adott a következő The following log sorline is given:
<pre>
7/30.07./2016 142:37:03 PM adam 1.5</prePre>És a következő metrika szabály a And there is given the following metric definition in the grok config-ban:
<source lang="C++">
metrics:
user: '{{.user}}'
</source>
A metrika neve '''grok_example_lines_total''' lesz. A metrikára az alábbi leszHere is the finale metric provided by the grok-exporter metrics endpoint:
<pre>
# HELP Example counter metric with labels.
<br>
====Metrika értékének meghatározásaValue of the metric ====A For a counter típusú metrikánál nincs szükség a metrika értékét meghatározni-type metric, mert ott azt fogja számolniwe don't need to determine the value of the metric, hogy hány illeszkedő logsort találtas it will just simply count the number of matches of the regular expression. Ezzel ellentétben az összes többi típusnál meg kell adniIn contrast, hogy mit tekintünk az értéknekfor all other types, we have to specify the value. Ezt a It has be defined in the '''value''' szekcióban kell megadnisection of the metric definition. Variables can be referenced in the same way as we saw it in in the label definition chapter, ahol be kell hivatkozni egy nevesített grok patternin go-t a match szekcióból ugyan úgy Go templét formában, ahogy a címkéket template style. Here is definiáltukan example. Pl adott a következő két logsorThe following two log lines are given:
<pre>
7/30.07./2016 142:37:03 PM adam 17/30.07./2016 142:37:03 adam PM Adam 5</prePre>És erre az alábbi And we define the following histogram-ot definiáljuk, ami két vödörből állwhich consists of two buckets, az bucket 1-es és and 2-es vödörből:
<source lang="C++">
metrics:
user: '{{.user}}'
</source>
Ekkor az alábbi metrika fog ebből keletkezniThis will result in the following metrics:
<pre>
# HELP Example counter metric with labels.
<br>
====FüggvényekFunctions ====A metrika értékekre (value) és a címkékre is lehet függvényeket alkalmazni. A függvények a '''Functions were introduced in grok-exporter version 0.2.7'''-es grok-exporter verzió kell vagy újabb. Lehet használni string manipulációs függvényeket és aritmetikai függvényeket isWe can apply functions to metric value and to the value of its labels. String manipulation functions and arithmetic functions are also available. A következő két argumentumú aritmetikai függvények támogatottakThe following two arguments arithmetic functions are supported:
* add
* subtract
* multiply
* divide
A függvény szintaxisa az alábbiFunctions have the following syntax: <pre>{{FÜGGVÉNY_NEVE FUNCTION_NAME ATTR1 ATTR2}}</pre> ahol az where ATTR1 és az and ATTR2 is lehet egy patternből nyert érték vagy egy természetes számcan be either a natural number or a variable name. A patternből nyert értékeket ugyan úgy The variable name must start with a dot.-al kell kiírni. Pl ha a Here is an example using the multiply függvényt használjuk a fenti példábanfunction on the the 'grok_example_lines' metric definition form the example above: <source lang="C++"> value          value: "{{multiply .val 1000}}"
</source>
Akkor a metrika az alábbira módosulThe outcome would be:
<pre>
# HELP Example counter metric with labels.
# TYPE grok_example_lines histogram
grok_example_lines_bucket{user="adam", le="1"} 0grok_example_lines_bucket{user="adam", le="2"} 0grok_example_lines_bucket{user="adam", le="+Inf"} 2
...
</prePre> Mivel a két érték Since the two values ​​would change to 1000 ill and 5000-re fog módosulni, ezért mindkettő az both will fall into the infinite kategóriába fog esnibucket.
<br>
<br>
==Creating the grok config fájl elkészítésefile ==Össze kell állítani egy olyan We have to compile a grok patternthat can extract all the attributes that are required for creating the response-t ami illeszkedik a latency-histogram based on the HAproxy access-log sorokra, és képes kigyűjteni az összes számunkra fontos attribútumotlogs. The required attributes are the following:
* válasz kiszolgálásának szumma idejeresponse time
* haproxy instance id
* openshfit service névtérnamespace* pod névname
<br>
Példa Example haproxy access-log:
<pre>
Aug 6 20:53:30 192.168.122.223 haproxy[39]: 192.168.42.1:50708 [06/Aug/2019:20:53:30.267] public be_edge_http:mynamespace:test-app-service/pod:test-app-57574c8466-qbtg8:test-app-service:172.17.0.12:8080 1/0/0/321/321 200 135 - - --NI 2/2/0/1/0 0/0 "GET /test/slowresponse/1 HTTP/1.1"</prePre>
A In the config.yml fájlban egy olyan hisztogramot fogunk definiálnifile, ami we will define a requestek teljes kiszolgálásának a válaszidejét tartalmazza. Ez egy klasszikus classic response-time-latency histogram, általában a következő vödröket szokta tartalmazni that usually contains the following buckets (másodpercbenin seconds):
<pre>
[0.1, 0.2, 0.4, 1, 3, 8, 20, 60, 120]
</prePre>A válaszidőket tartalmazó metrikáknak konvenció szerint a következő a neveResponse time histogram metrics by convention are called: '''<name prefix>_http_request_duration_seconds''' 
'''config.yml'''
</source>
Explanation:* '''type: file''' -> fájlból olvassuk a logokatread logs from file* '''path: /var/log/messages''' -> Az The rsyslog szerver a server writes logs to /var/log/messages mappába írja a logokat alapértelmezetten by default* '''readall: true''' -> mindig az egész always reads the entire log fájlt beolvassafile. Ezt csak tesztelésre szabad így használniThis should only be used for testing, éles környezetbenin a live environment, ezt mindig this always has to be set to false-ra kell állítani. * '''patterns_dir: ./patterns''' -> A Base directory of the pattern definitions in the docker image-ben itt találhatók a pattern definíciók* <pre>value: "{{divide .Tt 1000}}"</pre> A kiszolgálási idő a The response time in the HAproxy log-ban miliszekundumban van, ezt konvertálni kell szekundumrais in milliseconds so we convert it to seconds. * '''port: 9144''' -> Ezen a porton lesz elérhető a The http port of the /metrics végpont. endpoint
<br>
{{warning|nem szabad éles környezetben elfelejteni a Do not forget to set the value of '''readall''' értékét ''to 'false'''-ra állítani, mert nagyon lerontja in a hatásfokotlive environment as it can significantly degrade performance}}
<br>
<br>
==='''Online grok teszter===testers'''<br>Több There are several online grok tesztelő eszköz is léteziktesting tools. Ezekkel nagyon hatékonyan össze lehet állatni a szükséges These can be help to compile the required grok pattern-texpression very effectively. Try this: https://grokdebug.herokuapp.com/ 
:[[File:ClipCapIt-190808-170333.PNG]]
<br>
==building the docker image elkészítése==A The grok-exporter docker image elérhető a is available on the docker hub-on több változatban in several variants. The only problem with them is. A gond velük csak az, hogy nem tartalmazzák az that they do not include the rsyslog szervert, amire szükségünk vanserver, hogy a what we need for the HAproxy közvetlen el tudja küldeni a logokat a to send logs directly to the grok-exporter podokankpod. <br>
docker-hub link: https://hub.docker.com/r/palobo/grok_exporter <br>
<br>
A második gond az, hogy The second problem is that they are all based on ubuntu base image-en alapulnak, ahol nagyon nehéz megoldani, hogy az that makes it very difficult to get rsyslog az to log to stdout-ra is logoljon, ami ahhoz kell(ubunto doesn't support loggin to stdout), hogy a Kubernetets centralizált which required by the centralized log gyűjtője is megkapja a HAproxy logokat, így mind a monitoring mind centralizált logging-ot ki tudjuk szolgálnisystem. Ezrét az eredeti We are going to port the original grok Dockerfile-t portolni fogjuk to '''centos 7'''-re, valamint ki fogjuk egészíteni az base image and will add rsyslog szerver telepítésével isinstallation to the new image.
<br>
Az összes szükséges fájl elérhető a All necessary files are available under my git-hub-on: https://github.com/berkiadam/haproxy-metrics/tree/master/grok-exporter-centos<br>Készítettem egy I also created an ubuntu alapú megoldást based solution, which is, ami az eredeti an extension of the original docker-hub-os megoldás kiegészítéseversion, ez szintén megtalálható a which can also be found on git-hub-on a in the '''grok-exporter-ubuntu mappábanfolder'''. A howot további részében mi mindig a centos verziót fogjuk használniIn the rest of this chapter, we are going to use the centOS version.
<br>
<br>
===Dockerfile===A We will modify the official '''palobo/grok_exporter''' Dockerfile-ból fogunk kiindulni, de ki fogjuk azt egészíteni az we will extend it with the rsyslog installációval és portoljuk installation and port it to centos-re: https://github.com/berkiadam/haproxy-metrics/tree/master/grok- CentOS-exporter-centos
<br>
 ➲[[File:Grok-exporter-docker-build.zip|Dokcer Download all files required for the build of the Docker image buld-hez szükséges összes fájl letöltése]]
<br>
CMD sh -c "nohup /usr/sbin/rsyslogd -i ${PID_DIR}/pid -n &" && ./grok_exporter -config /grok/config.yml
</source>
{{note|Fontos, hogy a It is important to use grok-exporter-ből legalább a version 0.2.7-es verziót használjukor higher, abban jelent meg először a függvények kezeléseas functions were introduced in this version}}
<br>
<br>
Az The '''rsyslog.conf''' fájlt az alábbiakkal kell kiegészítenifile include at least the following, ami lehetővé teszi, hogy az that enables receiving logs on port 514-es porton over both UDP-n és and TCP-n is fogadni tudjon logot (részletesen lásd a fenti ZIP-bensee zip above for details), valamint, hogy minden log-t írjon ki az . The logs are written to stdout-ra és a and to /var/log/messages fájlba is.
<pre>
$ModLoad omstdout.so
<br>
===Lokális Local build és lokális tesztand local test ===Első körben a lokális docker démonnal fogjuk First, we will build-elni a the docker image-t, hogy tudjuk lokálisan futtatni tesztelés céljábólwith the local docker daemon so that we can run it locally for testing. Később majd ezt a Later we will build it directly on the minishfit VM-en fogjuk build-elni, mert csak onnan fogjuk tudni feltölteni a since we will only be able to upload it to the minishfit docker registry-befrom the VM. Mivel majd egy távoli (nem Since, at the and, as we will upload the image to a lokális) remote docker repository-ba akarjuk majd az image-t felölteni, fontos, hogy betartsuk az elnevezési konvenciókatit is important to follow the naming conventions:
<pre>
<repo URL>:<repo port>/<névtérnamespace>/<image-névname>:<tag>
</pre>
Mi a minishift-en futó We will upload the image to the docker-registry-be fogjuk feltölteni majd az image-t, ezért fontosrunning on the minishift, hogy a so it is important to specify the address and port of the minishfit-docker-registry címét és portját adjuk meg és azt az and the OpenShift névteret, ahova az namespace where the image kerül majdwill be deployed.
<pre>
# docker build -t 172.30.1.1:5000/default/grok_exporter:1.1.0 .</prePre>
Az elkészült The image-t natív, lokális docker futtatással tesztelhetjükcan be easily tested locally. Készítsünk egy Create a haproxy teszt test log fájlt file ('''haproxy.log''') amibe helyezzük el az alábbi tartalmatwith the following content in it. Ezt fogjuk feldogoztatni a This will be processed by the grok-exporter-elduring the test, mintha a as if it had been provided by haproxy-tól kapta volna.
<pre>
Aug 6 20:53:30 192.168.122.223 haproxy[39]: 192.168.42.1:50708 [06/Aug/2019:20:53:30.267] public be_edge_http:mynamespace:test-app-service/pod:test-app-57574c8466-qbtg8:test-app-service:172.17.0.12:8080 1/0/0/321/321 200 135 - - --NI 2/2/0/1/0 0/0 "GET /test/slowresponse/1 HTTP/1.1"
<br>
Helyezzük el ugyan ebbe a mappába a fent elkészített Put the grok config file '''config.yml''' fájlt isspecified above in the same folder. A In the config.yml fájlban állítsuk át az file, change the input.path értékét to '''/grok/haproxy.log-ra''', hogy a grok-exporter a teszt logfájlunkat dolgozza felwhere the test log content is. Majd egy Then start the container with following '''docker run''' paranccsal indítsuk el az alábbi módoncommand:
<pre>
# docker run -d -p 9144:9144 -p 514:514 -v $(pwd)/config.yml:/etc/grok_exporter/config.yml -v $(pwd)/haproxy.log:/grok/haproxy.log --name grok 172.30.1.1:5000/default/grok_exporter:1.1.0</prePre>
<br>
Az indulás után ellenőrizzük a log-ban hogy a Check the logs and confirm that the grok és az and rsyslog valóban elindultak eboth have started:
<pre>
# docker logs grok
  * Starting enhanced syslogd rsyslogd     ...done.Starting server on is http://7854f3a9fe76:9144/metrics</prePre>
<br>
Ekkor a böngészőben a Metrics are available in the browser at http://localhost:9144/metrics címen elérhetőek a metrikák:
<pre>
...
<br>
<br>
Második lépésként ellenőrizzük leAs a second step, hogy a docker konténerben futó verify that the '''rsyslog''' képes e távoli running in the docker container can receive remote log üzeneteket fogadnimessages. Ehhez elsőként lépjünk be a konténerbe és figyeljük a To do this, first enter the container with the exec command and check the content of the /var/log/messages fájlt: file in f (follow) mode.
<pre>
# docker exec -it grok /bin/bash
<br>
Most az anya gépről a Now, on the host machine, use the '''logger''' paranccsal küldjünk egy command to send a log üzenetet a konténerben futó message to the container running rsyslog szervernek az server on port 514-es porton:
<pre>
# logger -n localhost -P 514 -T "this is the message"
</prePre>(T=TCP)
Ekkor a The log meg kell jelenjen a should then appear in the '''syslog''' fájlbanfile:
<pre>
Aug 8 16:54:25 dell adam this is the message</prePre>
Törölhetjük a lokális You can delete the local docker konténertcontainer.
<br>
<br>
===Távoli Remote build===Fel szeretnénk tölteni az elkészült docker We have to to upload our custom grok Docker image-t a to the minishfit saját registry-ébe. Ehhez az To do so, you need to build the image-t a with the minishfit VM lokális 's local docker démonjával kell build-elnidaemon, mert csak onnan ehet hozzáférni a since you can only access the minishfit registry-hezfrom the VM so uploading images is only possible from the VMs local registry. <br>Részletek ittDetails can be found here: [[Openshift_basics#Minishfit_docker_registry|➲Image push a to minishift docker registriy-be]]
 Ahhoz hogy az '''We need special rights for accessing the minishift registry even from the VM running the minishfit cluster. In the example we always log in to minishfit as admin''' user-nek legyen joga feltölteni az image-t a minisfhit registry-be a '''default''' névtérbe, ahol a router is fut, szüksége hogy megkapja a '''so we are going to extend the admin user with the cluster-admin''' jogotrole, that has sufficient rights for uploading images to the minishift registry. FontosFor extending our user roles we have to log into the system namespace, hogy '''-u system:admin''' -al lépjünk be ne csupán 'so always include the namespace name in the 'oc login'''-al, mert akkor nem lesz jogunk az '''oc adm''' parancsot kiadni. Ugyan így fogunk hivatkozni a user-re is az '''--as''' paraméterbencommand.
<pre>
# oc login -u system:admin
# oc adm policy add-cluster-role-to-user cluster-admin admin --as=system:admin
cluster role "cluster-admin" added: "admin"
</prePre>{{note|Ha ezt a hibát kapjuk If we get this error '''Error from server (NotFound): the server could not find the requested resource''', ez azt jelenti, hogy az '''it probably means that our oc''' kliens programunk régebbi mint a client is older than OpenShift verzióversion}}
Irányítsuk át a lokális Redirect our local docker kliensünket a client to the docker daemon running on the minisfhit VM-en futó docker démonra, majd jelentkezzünk be a and log into the minishift docker registry-be:
<pre>
# minishift docker-env
# eval $(minishift docker-env)
# oc login
Username: admin
Password: <admin>
# docker login -u admin -p $(oc whoami -t) $(minishift openshift registry)
Login Succeeded
</prePre>
Build-eljük le a the image on the minishfit VM-en isas well:
<pre>
# docker build -t 172.30.1.1:5000/default/grok_exporter:1.1.0 .</prePre>
Lépjünk be a Push the image to the minisfhit docker registry-be majd adjuk ki a '''push''' parancsot. :
<pre>
# docker push 172.30.1.1:5000/default/grok_exporter:1.1.0
</prePre>
<br>
==Required Kubernetes objektumokobjects ==
A grokFor the HAproxy-exporter-hez létre fogunk hozni egy we will create a serviceAccount-ot, egy a deployment-et, egy a service-t és egy and a comifMap-et ahol a where we will store the grok-exporter konfigurációját fogjuk tárolniconfiguration. Ezen felül módosítani fogjuk az anyuid nevű In addition, we will extend the '''SecurityContextConstraintsanyuid''' objektumotSecurityContextConstraints object, mivel az because the rsyslog szerver miatt a server requires the grok-exporter konténernek privilegizált módban kell futniacontainer to run in privileged mode.
* haproxy-exporter service account
* scc-anyuid.yaml
A teljes konfigurációt itt tölthetjük leThe full configuration can be downloaded here: [[File:Haproxy-kubernetes-objects.zip]], vagy megtalálható az alábbi or can be found in the git repository-banbelow: https://github.com/berkiadam/haproxy-metrics
<br>
<br>
===Create the ServiceAccount létrehozása===A haproxy-exporter-nek szüksége van egy saját serviceAccount-ra, amire engedélyezni fogjuk a privilegizált (root) konténer futtatást. Erre az rsyslog szervernek van szüksége.
<pre>
# kubectl create serviceaccount haproxy-exporter -n default
serviceaccount/haproxy-exporter created</prePre>
Ennek As a hatáséra a következő result, the following serviceAccount definíció jött létredefinition was created:
<source lang="C++">
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: "2019-08-10T12:27:52Z"
name: haproxy-exporter
namespace: default
resourceVersion: "837500"
selfLink: /api/v1/namespaces/default/serviceaccounts/haproxy-exporter
uid: 45a82935-bb6a-11e9-9175-525400efb4ec
secrets:
- name: haproxy-exporter-token-8svkx
===Objektumok definiálásaAddition Kubernetes objects===
<br>
<br>
A grokBecause of Haproxy-exporter-ben lévő runs an rsyslog szerver miatt fontosserver, hogy a konténer privilegizált üzemmódban fussonits container must be run in privileged mode. Ehhez az To do this, you need to add the HAproxy-exporter serviceAcccount to the SCC named '''anyuid''' nevű . So we don't need the '''privileged'' SCC-be fel kell venni a haproxy-exporter-hez tartozó serviceAcccount-because the container wants to start as root, we don'tneed to force it by OpenShift configuration, hogy engedélyezzük a we just have to allow it. Without running as root nevében futtatást. Tehát nincs szükség a privileged SCC-re, mert a konténer elve root-ként szeretne indulni. Más különben az rsyslog nem lesz képes létrehozni a socket-eketwill not be able to create sockets. {{warning|Az SCC-k kezeléshez nem elég a developer user mynamespace-re kapott admin rolebindg-ja. Ehhez admin-ként kell bejelentkezni: oc login -u system:admin}} 
<br><br>
Listázzuk ki a SCC-ketLets list the SCCs:
<pre>
# kubectl get SecurityContextConstraints
<br>
 Az The haproxy-exporter service-account must be added to the '''anyuid''' SCC-hez a users szekcióban kell hozzáadni a '''serviceAccountsection of the 'anyuid''-ot az alábbi formábanSCC in the following format:  - system:serviceaccount:<névtérnamespace>:<serviceAccount>
<br>
'''sccScc-anyuid.yaml'''<source lang="C++">
kind: SecurityContextConstraints
metadata:
name  name: anyuid
...
users: - system:serviceaccount:default:haproxy-exporter
...
</source>
Mivel ez már egy létező Since this is an existing '''scc''' és csak egy apró módosítást akarunk rajta eszközölniand we just want to apply some minor changes, ezért helyben is szerkeszthetjükwe can edit it 'on the fly' with the 'oc edit' command:
<pre>
# oc edit scc anyuid
<br>
===objektumok létrehozásacreate the objects ===
<pre>
# kubectl apply -f cm-haproxy-exporter.yaml
configmap/haproxy-exporter created
</pre>
<pre>
# kubectl apply -f deployment-haproxy-exporter.yaml
deployment.apps/haproxy-exporter created
# kubectl rollout status deployment haproxy-exporter -n default
deployment "haproxy-exporter" successfully rolled out
</pre>
<br>
===TesztelésTesting ===
Keressük meg a Find the haproxy-exporter pod-ot majd nézzük meg a and check logs of the pod logját:
<pre>
# kubectl logs haproxy-exporter-744d84f5df-9fj9m -n default
 * Starting enhanced syslogd rsyslogd    ...done.Starting server on http://haproxy-exporter-744d84f5df-9fj9m:9144/metrics
</pre>
Majd lépjünk be a konténerbe és teszteljük re az Then enter the container and test the rsyslog működésétserver:
<pre>
# kubectl exec -it haproxy-exporter-647d7dfcdf-gbgrg /bin/bash -n default
</pre>
Majd a Then use the '''logger''' paranccsal küldjünk egy command to send a log üzenetet az message to rsyslog-nak.
<pre>
logger -n localhost -P 514 -T "this is the message"
</pre>
Most listázzuk ki a Now, let's list the contents of the /var/log/messages mappa tartalmátfolder:
<pre>
# cat messages
Aug 28 19:16:09 localhost root: this is the message
</pre>
Lépjünk ki a konténerből, és kérjük le megint a Exit the container and retrieve the pod logjait, hogy megnézzük, hogy az logs again to see if the log has been sent to stdout-ra is kirakta e a logotas well:
<pre>
# kubectl logs haproxy-exporter-647d7dfcdf-gbgrg -n default
Starting server on http://haproxy-exporter-647d7dfcdf-gbgrg:9144/metrics2019-08-28T19:16:09+00:00 localhost root: this is the message
</pre>
<br>
==HAproxy konfigurációConfiguration ==
===Környezeti változók beállításaSetting the environment variables ===A In the HAproxy-nak be fogjuk állítani környezeti változónk keresztül a routers, we will set the address of the rsyslog server running in the haporxy-exporter pod-ban futó rsyslog szerver címétvia environment variables. Ehhez első lépésben listázzuk a Let's check first the haproxy-exporter service-t.
<pre>
# kubectl get svc -n default
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEhaproxy-exporter-service ClusterIP 172.30.213.183 <none> 9144/TCP,514/TCP,514/UDP 15s
..
</pre>
A HAproxy az stores the rsyslog szerver címét a server address in the '''ROUTER_SYSLOG_ADDRESS''' nevű környezeti változóban tárolja (Deployment része)environment variable. Ezt futásidőben át tudjuk írni az We can overwrite this at runtime with the '''oc set env''' paranccsalcommand. A változó átírása után a After rewriting the variable, the pod magától újra fog indulniwill restart automatically.
<pre>
# oc set env dc/myrouter ROUTER_SYSLOG_ADDRESS=172.30.213.183 -n default
deploymentconfig.apps.openshift.io/myrouter updated
</pre>
{{note|Minishift-en a In minishift, in the router konténerben nem működik a containers the name resolution does not work for Kubernetes service-ek nevére a névfeloldásnames, mivel nem a because it doesn't use the Kubernetes klaszter cluster DNS szerver címe van beállítva, hanem a server but the minishfit VM. Ezért nem tehetünk mástTherefore, mint hogy a all you have to do is enter the service 's IP címét adjuk meg a neve helyettaddress instead of its name. In OpenShift környezetben a , we have to use the name of the service nevét adjuk meg}}
Majd második lépésben állítsuk át debug-ra a logszintet As a second step, change the HAproxy-banlog level to debug, mert csak debug szinten van because it only produces access-login debug level.
<pre>
# oc set env dc/myrouter ROUTER_LOG_LEVEL=debug -n default
deploymentconfig.apps.openshift.io/myrouter updated
</pre>
{{warning|Teljesítmény tesztel meg kell vizsgálni hogy mekkora plusz terhelést jelent a Performance test must be carried out to see how much is the extra load when running the haproxy-nak ha in debug módban futmode}}
<br>
A fenti két környezeti változó módosításának a hatására a router konténerben As a result of the modification of the two environment variables, the configuration of HAproxy in '''/var/lib/haproxy/conf/haproxy.config''' fájlban a HAproxy konfigurációja az alábbira változotthas changed to:
<pre>
# kubectl exec -it myrouter-5-hf5cs /bin/bash -n default
$ cat /var/lib/haproxy/conf/haproxy.config
global
..
log   log 172.30.82.232 local1 debug
</pre>
A lényeg, hogy megjelent a log paraméternél a This is the IP address of the haproxy-exporter service címe és a ''', and the log level is debug''' log szint.
<br>
<br>
<br>
===Testing the rsyslog szerver teszteléseserver ===Generáljunk egy kis forgalmat a Generate some traffic through haproxy-n keresztül, majd lépjünk vissza a then go back to the haproxy-exporter konténerbe, és listázzuk a container and list the content of the messages fájl tartalmátfile.
<pre>
# kubectl exec -it haproxy-exporter-744d84f5df-9fj9m /bin/bash -n default
#
# tail -f /var/log/messages
Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy fe_sni stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy be_no_sni stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy fe_no_sni stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy openshift_default stopped (FE: 0 conns, BE: 1 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy be_edge_http:dsp:nginx-route stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy be_http:mynamespace:prometheus-alertmanager-jv69s stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy be_http:mynamespace:prometheus-server-2z6zc stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy be_edge_http:mynamespace:test-app-service stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[24]: Proxy be_edge_http:myproject:nginx-route stopped (FE: 0 conns, BE: 0 conns).Aug 9 12:52:17 192.168.122.223 haproxy[32]: 127.0.0.1:43720 [09/Aug/2019:12:52:17.361] public openshift_default/<NOSRV> 1/-1/-1/-1/0 503 3278 - - SC-- 1/1/0/0/0 0/0 "HEAD / HTTP/1.1"
</pre>
Ha a logjait megnézzük a haproxy-exporter pod-nak, ugyan ezt kell ássuk.
<pre>
...
Aug 9 12:57:21 192.168.122.223 haproxy[32]: 192.168.42.1:48266 [09/Aug/2019:12:57:20.636] public be_edge_http:mynamespace:test-app-service/pod:test-app-57574c8466-qbtg8:test-app-service:172.17.0.17:8080 1/0/12/428/440 200 135 - - --II 2/2/0/1/0 0/0 "GET /test/slowresponse/1 HTTP/1.1"Aug 9 12:57:28 192.168.122.223 haproxy[32]: 192.168.42.1:48266 [09/Aug/2019:12:57:21.075] public be_edge_http:mynamespace:test-app-service/pod:test-app-57574c8466-qbtg8:test-app-service:172.17.0.17:8080 4334/0/0/3021/7354 200 135 - - --VN 2/2/0/1/0 0/0 "GET /test/slowresponse/3000 HTTP/1.1"Aug 9 12:57:28 192.168.122.223 haproxy[32]: 192.168.42.1:48266 [09/Aug/2019:12:57:28.430] public be_edge_http:mynamespace:test-app-service/pod:test-app-57574c8466-qbtg8:test-app-service:172.17.0.17:8080 90/0/0/100/189 404 539 - - --VN 2/2/0/1/0 0/0 "GET /favicon.ico HTTP/1.1"Aug 9 12:57:35 192.168.122.223 haproxy[32]: 192.168.42.1:48268 [09/Aug/2019:12:57:20.648] public public/<NOSRV> -1/-1/-1/-1/15002 408 212 - - cR-- 2/2/0/0/0 0/0 "<BADREQ>"
</pre>
===Testing the grok-exporter tesztelésecomponent ===Kérjük le a grokPlease open the gork-exporter metrikákat a metrics at http://<pod IP>:9144/metrics címen. Vagy a You can open this URL either in the haproxy-exporter pod-ban itself with on localhost hívással, vagy bármelyik másik or in any other pod-ban a using the haporxy-exporter pod 's IP címét felhasználvaaddress. Az alábbi példában a test-app-ba lépek be. Látnunk kell a metrikák között a We have to see the '''haproxy_http_request_duration_seconds_bucket''' histogramothistogram among the metrics.
<pre>
# kubectl exec -it test-app-57574c8466-qbtg8 /bin/bash -n mynamespace$
$ curl http://172.30.213.183:9144/metrics
...
# HELP haproxy_http_request_duration_seconds The request durations of for the applications running in openshift openhift that have route defined.
# TYPE haproxy_http_request_duration_seconds histogram
haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="0.1"} 0haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="0.2"} 1haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="0.4"} 1haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="1"} 2haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="3"} 2haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="8"} 3haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="20"} 3haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="60"} 3haproxy_http_request_duration_seconds_bucket{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="120"} 3haproxy_http_request_duration_seconds_bucket{haproxy={ "haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service",le="+Inf"} 3haproxy_http_request_duration_seconds_sum{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service"} 7.9830000000000005haproxy_http_request_duration_seconds_count{haproxy="haproxy[32]",namespace="mynamespace",pod_name="test-app-57574c8466-qbtg8",service="test-app-service"} 3
</pre>
<br>
==Prometheus beállításokSettings ==
===Statikus konfigurációStatic configuration ===<source lang="C++">     - job_name: grok-exporter scrape_interval      scrape_interval: 5s metrics_path      metrics_path: /metrics static_configs      static_configs:       - targets: ['grok-exporter-service.default:9144']
</source>
=== Pod Level Data Collection ===
===Pod szintű adatgyűjtés=== Azt szeretnénk, hogy a We want the haproxy-exporter podok skálázhatóak legyenekpods to be scalable. Ehhez az kell, hogy a prometheus ne a This requires that the Prometheus does not scrape the metrics through the service-en keresztül kérje le a metrikát (mert akkor a service because it does loadbalancing-ot csinál) hanem közvetlenül a pod, but from the pods directly. So Prometheus must query the Endpoint definition assigned to the haproxy-okat szólítsa meg. Ehhez az kell, hogy a prometheus a exporter service from the Kubernetes API-n keresztül kérje le a haproxy-epxporter-hez tartozó '''Endpoint'''-ot, ami tartalmazza a service-hez tartozó podok ip címének a listájátwhich contains the list of IP addresses the pods. Ehhez a prometheus We will use the '''kubernetes_sd_configs''' elemét fogjuk használnielement to achieve his. (Ennek előfeltétele, hogy a This requires Prometheus képes legyen kommunikálni a to be able to communicate with the Kubernetes API-val. Részleteket lásd itt: For details, see [[Prometheus_on_Kubernetes]])
A When using '''kubernetes_sd_configs''' használatakor mindig egy adott Prometheus always gets a list of a specific Kubernetes objektum listát kérünk le a szerverről objects from the API (node, service, endpoints, pod), majd a kapott listából megkeressük azt az erőforrást, amiből be akarjuk gyűjteni a metrikákatand then it identifies those resources according to its configuration from which it wants to collect the metrics. Ezt úgy tesszük meg hogy a In the ''''relabel_configs''' szekcióban majd szűrőfeltételeket írunk föl az adott Kubernetes resource címkéiresection of Prometheus configuration we will define filter conditions for identifying the needed resources. Jelen esetben a In this case, we want to find the endpoint belonging to the haproxy-exporter-hez tartozó Endpoint-ot akarjuk megtalálniservice, mert az alapján a because it allows Prometheus meg tudja találni az összes a to find all the pods for the service-hez tartozó pod-ot. Tehát a címék alapján meg akarjuk majd találni egyrészt azt az So, based on Kubernetes labels, we want to find the endpoint-ot, amit that is called '''''haproxy-exporter-service'''-nak hívnak, ezen felül van egy and has a port called '''metrics''' portja, amin keresztül a through which Prometheus képes lekérni a metrikákatcan scrape the metrics. Az alapértelmezett In Prometheus, the default scrape URL a is '''/metrics''', tehát ezt külön nem kell definiálni, a grok-exporter is ezt használjaso we don't have to define it implicitly.
<pre>
# kubectl get Endpoints haproxy-exporter-service -n default -o yaml
kind: Endpoints
metadata:
name  name: haproxy-exporter-service
...
ports  ports:   - name: log-udp port    port: 514 protocol    protocol: UDP   - name: metrics port    port: 9144 protocol    protocol: TCP   - name: log-tcp port    port: 514 protocol    protocol: TCP
</pre>
Két címkét keresünk az We are looking for two labels in the Endpoints listábanlist:
* __meta_kubernetes_endpoint_port_name: metrics -> 9144
* __meta_kubernetes_service_name: haproxy-exporter-service
<br>
A The config-map that describes proetheus.yaml-t, vagyis a prometheus.yaml-t leíró config-map-et az alábbiakkal kell kiegészítenishould be extended with the following: <source lang="C++">     - job_name: haproxy-exporter scheme      scheme: http tls_config      tls_config: ca_file        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server_name        server_name: router.default.svc bearer_token_file      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token kubernetes_sd_configs      kubernetes_sd_configs:       - role: endpoints namespaces        namespaces: names          names:           - default relabel_configs      relabel_configs:       - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action        action: keep regex        regex: haproxy-exporter-service;metrics</sourceSource>
Töltsük újra a Reload configMap-et:
<pre>
# kubectl apply -f cm-prometheus-server-haproxy-full.yaml
</pre>
Majd várjuk meg, hogy a Wait for Prometheus újra olvassa a konfigurációs fájltto read the configuration file again:
<pre>
# kubectl logs -f -c prometheus-server prometheus-server-75c9d576c9-gjlcr -n mynamespace
...
level=info ts=2019-07-22T20:25:36.016Z caller=main.go:730 msg="Loading configuration file" filename=/etc/config/prometheus.yml
</pre>
<br>
Majd a Then, on the http://mon.192.168.42.185.nip.io/targets képernyőn ellenőrizzükscreen, hogy eléri e a verify that Prometheus a can scrape the haproxy-exporter target-et: :[[File:ClipCapIt-190809-164445.PNG]]
<br>
===scaling haproxy-exporter skálázása===
<pre>
# kubectl scale deployment haproxy-exporter --replicas=2 -n defaultdeployment.extensions/haproxy-exporter scaled
</pre>
<pre>
# kubectl get deployment haproxy-exporter -n default
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEhaproxy-exporter 2 2 2 2 3h
</pre>
<br>
:[[File:ClipCapIt-190809-174825.PNG]]
<br>
==Metrika fajtákMetric types ==
===haproxy_http_request_duration_seconds_bucket===
type: histogram
<br>
===haproxy_http_request_duration_seconds_bucket_count===type: counter<br>Az összes darabszáma az adott histogramba eső request-ek számánakThe total number of requests in that histogram
<pre>
haproxy_http_request_duration_seconds_count{haproxy={ "haproxy[39]",jobJob ="haproxy-exporter",namespace="mynamespace",pod_name="testapp-appbody",service="testbody-app-service"} 5
</pre>
<br>
<br>
===haproxy_http_request_duration_seconds_sum===type: counter<br>A válaszidők idejének összege az adott hisztogrambanThe sum of the response times in a given histogram. Az előző példa alapján összesen 5 kérés jöttBased on the previous example, és there were a kiszolgálási idő összeadva total of 5 requests and the summ serving time was 13 s volt.
<pre>
haproxy_http_request_duration_seconds_sum{haproxy={ "haproxy[39]",jobJob ="haproxy-exporter",namespace="mynamespace",pod_name="testapp-appbody",service="testbody-app-service"13663} 13.663
</pre>
<br>
=OpenShift router + rsyslog=
Starting with OpenShift 3.11-től kezdődően lehet olyan , it is possible to fire up a router-t definiálni, hogy az OpenShfit automatikusan elindít egy that will contain a side car rsyslog konténert a container in the router pod-ban és be is állítja, hogy a and configure HAproxy egy socket-en keresztül (to send logs to the rsyslog server via an emptyDir volume) elküldje a logokat az rsyslog szervernek, ami az which writes them to stdout-ra írja azokat alapértelmezettenby default. Az The configuration of rsyslog konfigurációja egy is in a configMap-ban van.
:[[File:ClipCapIt-190810-164907.PNG]]
<br>
A You can create a router-t syslogserverrel a with syslogserver using the '''--extended-logging''' kapcsolóval hozhatjuk létre az switch in the '''''oc adm router''' paranccsalcommand.
<pre>
# oc adm router myrouter --extended-logging -n default
info: password for stats user admin has been set to O6S6Ao3wTX
--> Creating router myrouter ... configmap     configmap "rsyslog-config" created warning    warning: serviceaccounts "router" already exists clusterrolebinding    clusterrolebinding.authorization.openshift.io "router-myrouter-role" created deploymentconfig    deploymentconfig.apps.openshift.io "myrouter" created service     service "myrouter" created--> Success
</pre>
<br>
Kapcsoljuk be a Turn on debug szintet a level loging in HAproxy-ban:
<pre>
# oc set env dc/myrouter ROUTER_LOG_LEVEL=debug -n default
deploymentconfig.apps.openshift.io/myrouter updated
</pre>
<br>
Két konténer van az új There are two containers in the new router pod-ban:
<pre>
# kubectl describe pod/myrouter-2-bps5v -n default
..
Containers:
router  router: Image    Image: openshift/origin-haproxy-router:v3.11.0 Mounts    Mounts:       /var/lib/rsyslog from rsyslog-socket (rw)
...
syslog  syslog: Image    Image: openshift/origin-haproxy-router:v3.11.0 Mounts    Mounts:       /etc/rsyslog from rsyslog-config (rw)       /var/lib/rsyslog from rsyslog-socket (rw)
...
rsyslog  rsyslog-config: Type    Type: ConfigMap (a volume populated by a ConfigMap) Name    Name: rsyslog-config Optional    Optional: false rsyslog  rsyslog-socket: Type    Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium    Medium: SizeLimit    SizeLimit: <unset>
</pre>
Láthatjuk, hogy mind két konténerbe mount-olva van You can see that the '''/var/lib/rsyslog/''' mappafolder is mounted in both containers. A HAproxy konfigurációs fájljában ide fogja létrehozni az The rsyslog.sock fájltfile will be created here.
<br>
<br>
===router konténercontainer ===Ha belépünk a When we enter the router konténerbecontainer, láthatjuk, hogy már fel is nyalta a konfigurációwe can see that the configuration has already been modified:
<pre>
# kubectl exec -it myrouter-2-bps5v /bin/bash -n default -c routerbash-4.2$ cat /var/lib/haproxy/conf/haproxy.config
global
...
log   log /var/lib/rsyslog/rsyslog.sock local1 debug
...
defaults
...
option   option httplog --> Enable logging of HTTP request, session state and timers
...
backend be_edge_http:mynamespace:test-app-service
</pre>
<br>
<br>
===rsyslog konténercontainer ===
<pre>
# kubectl exec -it myrouter-2-bps5v /bin/bash -n default -c syslog
$ cat /etc/rsyslog/rsyslog.conf $ModLoad imuxsock$SystemLogSocketName /var/lib/rsyslog/rsyslog.sock$ModLoad omstdout.so*.* :omstdout:
</pre>
<br>
Ha át akarjuk konfigurálni az If you want to reconfigure rsyslog-ot hogy küldje el a logokat pl a to send logs to e.g, logstash-nek, akkor csak a then you only need to rewrite the configMap-et kell átírni. Alapértelmezetten csak az By default, rsyslog only writes to stdout-ra írja amit kap.
<pre>
# kubectl get cm rsyslog-config -n default -o yaml
apiVersion: v1
data:
rsyslog  rsyslog.conf: |     $ModLoad imuxsock     $SystemLogSocketName /var/lib/rsyslog/rsyslog.sock     $ModLoad omstdout.so     *.* :omstdout:
kind: ConfigMap
metadata:
name  name: rsyslog-config namespace  namespace: default
</pre>
<br>
<br>
===Viewing HAproxy logok nézegetéseLogs ===
<pre>
# kubectl logs -f myrouter-2-bps5v -c syslog
</pre>
Retrieved from "http://wiki.berki.org/index.php/Special:MobileDiff/4335...5014"