Changes

Centralized logging in swarm

15,641 bytes added, 07:57, 18 May 2019

→‎Swarm stack

:[[File:ClipCapIt-180928180930-200815152409.PNG]]

https://www.elastic.co/guide/en/kibana/current/docker.html<br>

===Volume plugin===

Három fontos mappáját kell kivezessük az NFS meghajtóra a Kibana konténernek:

* /usr/share/kibana/config: konfig mappa helye

* /usr/share/kibana/data : ez a munkaterület

* /usr/share/kibana/plugins : ide írnak a plugin-ek.

 

 

===Telepítés===

A Kibana-t is az '''elk''' overlay hálózatra fogjuk csatlakoztatni, így közvetlenül el fogja érni az elasticsearch szolgáltatást a 9200 porton. Az elasticsearch domain nevet fel fogja oldani a swarm DNS szerver a konténer IP címére az '''elk''' hálózaton. Az Elasticsearch szerver elérhetőségét most nem config fájlal adjuk meg, hanem a '''ELASTICSEARCH_URL''' környezeti változóval. A Kibana web-es felülete a '''5601'''-es porton érhető el, azt publikáljuk az ingress overlay hálózatra, így bármelyik node publikus IP címével el fogjuk érni a Kibana-t.

<pre>

-e ELASTICSEARCH_URL=http://elasticsearch:9200 \

-p 5601:5601 \

--mount "type=volume,src=192.168.42.1/home/adam/Projects/DockerCourse/persistentstore/kibana/config/\

,dst=/usr/share/kibana/config,volume-driver=nfs" \

--mount "type=volume,src=192.168.42.1/home/adam/Projects/DockerCourse/persistentstore/kibana/data/\

,dst=/usr/share/kibana/data,volume-driver=nfs" \

--mount "type=volume,src=192.168.42.1/home/adam/Projects/DockerCourse/persistentstore/kibana/plugins/\

,dst=/usr/share/kibana/plugins,volume-driver=nfs" \

docker.elastic.co/kibana/kibana:6.4.0

</pre>

<br>

{{note|A legjobb a *'''Discover* ''' képernyőben, hogy szabad szavasan is lehet benne keresni, írjunk be bármilyen szöveget, amelyik logban az szerepelt, azt meg fogja mutatni, pl egy IP cím, vagy bármilyen más id}}

 

Most keressünk a logstash-* patternekben. <br>

Listázzuk ki az összes olyan logstash-* indexbe tartozó log bejegyzést, amit nem az elastch termékek generáltak:

NOT program: kibana* and NOT program : logmanager_*

 

 

Vagy szimplán keressünk rá a "hello logspout" üzenetre, amit a tesztelés céljából indított ubuntu konténer küldött be. Mivel szabad szavasan is lehet keresni, csak írjuk be felülre hogy "hello logspout".

:[[File:ClipCapIt-180929-152229.PNG]]

{{note|Figyeljünk a jobb felső sarokban keresési intervallum beállításokra. Alapértelmezetten csak 15 perces adatokban keres}}

<br>

 

==Visualize==

A Vizualize felületen 18 féle diagram típusból választhatunk:

=Swarm stack=

'''dockerelastic-composestack.yml'''

<syntaxhighlight lang="C++">

version: '3'

services:

elasticsearch:

image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0

ports:

- "9200:9200"

networks:

- elk

volumes:

- "elasticsearch-conf:/usr/share/elasticsearch/config"

- "elasticsearch-data:/usr/share/elasticsearch/data"

environment:

- "discovery.type=single-node"

deploy:

restart_policy:

condition: on-failure

resources:

reservations:

memory: 500m

logstash:

image: docker.elastic.co/logstash/logstash:6.4.0

networks:

- elk

environment:

- "LOGSPOUT=ignore"

volumes:

- "logstash-conf:/usr/share/logstash/pipeline"

deploy:

restart_policy:

condition: on-failure

resources:

reservations:

memory: 100m

logspout:

image: gliderlabs/logspout:v3.2.5

networks:

- elk

volumes:

- "/var/run/docker.sock:/var/run/docker.sock"

environment:

- "SYSLOG_FORMAT=rfc3164"

command:

- "syslog://logstash:51415"

deploy:

mode: global

restart_policy:

condition: on-failure

kibana:

image: docker.elastic.co/kibana/kibana:6.4.0

networks:

- elk

volumes:

- "kibana-conf:/usr/share/kibana/config"

- "kibana-data:/usr/share/kibana/data"

- "kibana-plugins:/usr/share/kibana/plugins"

environment:

- "LASTICSEARCH_URL=http://elasticsearch:9200"

ports:

- 5601:5601

deploy:

restart_policy:

condition: on-failure

 

networks:

elk:

driver: overlay

 

volumes:

elasticsearch-conf:

driver: nfs

driver_opts:

share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/elasticsearch/config

elasticsearch-data:

driver: nfs

driver_opts:

share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/elasticsearch/data

logstash-conf:

driver: nfs

driver_opts:

share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/logstash/config

kibana-conf:

driver: nfs

driver_opts:

share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/kibana/config

kibana-data:

driver: nfs

driver_opts:

share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/kibana/data

kibana-plugins:

driver: nfs

driver_opts:

share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/kibana/plugins

</syntaxhighlight>

 

 

# docker stack deploy --compose-file docker-compose.yml logmanager

 

 

Ugyan a service-ek nevébe a swarm bele fogja tenni a logmanager előtagot (ami a stack neve), ettől függetlenül a compose fájlban szereplő névvel a stack service-ek még mindig tudják használni a DNS névfeloldást egymás IP címeinek a kitalálásár az '''elk''' overlay hálózaton. (A hálózat nevébe is megváltozik: logmanager_elk)

<pre># docker stack lsNAME SERVICESlogmanager 4</pre> <pre># docker stack ps logmanager ...</syntaxhighlightpre> =Elasticsarch cluster= ==Áttekintés==Alap esetben az ES cluster építése egy automatizált folyamat, a user elől el van fedve. Kicsit leegyszerűsítve nincs más dolgunk, mint hogy elindítani a kívánt számú ES példányt ugyan azzal a cluster névvel egy közös hálózaton, a cluster felépítése teljesen automatikusan végbe fog menni.  Négyféle alap node típus van: * '''Master-eligible node''': A master node-ok vezérli a cluster infrastruktúrát. Nyilván tartja a cluster tagokat, vezérli az index-ek létrehozását, törlését, valamint dönt róla hogy shard melyik node-ra kerüljön (node.master = true)* '''Data node''': Ezek a node-ok tárolják az adatbázis adatokat és hajtrák végre az adatmanipulációs és kereső műveleteket, lényegében ők a munkások. (node.data = true)* '''Ingest node''': Ingest nodes are able to apply an ingest pipeline to a document in order to transform and enrich the document before indexing. With a heavy ingest load, it makes sense to use dedicated ingest nodes and to mark the master and data nodes as node.ingest: false.* '''Tribe node''': több cluster között képes kapcsolatot teremteni, az egyetlen node típus ami több cluster-nek is a tagja lehet. * '''Coordinating node''': A kliens kéréseket a Coordinating node-ok kapják meg és továbbítják a data node-oknak, akik a keresés eredményét visszaküldik a keresést indító Coordinating node-nak, összegzi az eredményeket és visszaküldi a kliensnek. Lényegében minden node egyben Coordinating node is, tehát bárhova beérkezhet a kliens kérés. Azonban nagyon nagy terhelés mellett készíthetünk dedikált Coordinating node-okat, amiken az előző négy típust kikapcsoljuk, és a klienseknek csak ezen node-okon keresztül kommunikálhatnak a cluster-el.   Elviekben egy node egyben több szerepben is lehet, sőt, alap beállítások mellett minden egyes létrehozott node egyben master, data és ingest node is egyben. Ez kis cluster méret mellett ideális, nincs más dolgunk mint hogy ugyan azokkal a beállításokkal elindítunk pl 5 node-ot, ezek automatikusan cluster-t fognak formálni és meg fogják választani a vezetőt. Nagyobb terhelés mellett viszont már érdemes specializált node-okat létrehozni, külön master és külön data node-okat. Ezen felül érdemes lehet szintén dedikált coordinating node-okat is bevezetni.

=Multiple node ES cluster=

Nem is olyan triviális több A node-os ES ok létrehozásakor a minimum beállítás:* Az interfész, ahol eléri a többi node-ot a cluster-ben* A cluster node-ok listája* Cluster név, ami azonosítja a cluster-t csinálni docker swarmahova csatlakoznia kell. {{warning|Saját adat mappa minden data és master node-nak: Fontos hogy a data és master node-oknak saját data mappája legyen, amin nem osztozik más node-on mint azt az ember gondolnáokkal, mert akkor összekeveredhetnek. }}

Két megközelítés közül választhatunk:

* '''Automatikus cluster formálás:''' egy darab swarm service-t definiálunk, és egyszerűen meghatározzuk a replikák számát, elindul több konténerben az Elasticsearch egy swarm service-ként: http://derpturkey.com/elasticsearch-cluster-with-docker-engine-swarm-mode/

* '''Kézi cluster létrehozás:''' Minden egyes cluster tagot külön swarm service-ként definiálunk a compose fájlban 1-es replika számmal, tehát előre pontosan megmondjuk, hogy hány darab fog futni, és hogy melyik node-nak milyen szerepe van: http://blog.ruanbekker.com/blog/2018/04/29/running-a-3-node-elasticsearch-cluster-with-docker-compose-on-your-laptop-for-testing/

http {{note|A swarm-ra azért van szükség, hogy könnyedén ki tudjuk telepíteni a távoli VM-re az ES konténereket. Swarm nélkül minden egyes VM-re nekünk kéne kézzel kitenni. }} ==Discovery==Az Elasticsearch a "Zen Discovery" szolgáltatást használja a cluster node-ok felkutatására és a master node kiválasztására.   '''discovery.zen.ping.unicast.hosts'''<br>Ebben a paraméterben kell felsorolni a node-ok listáját. Szerencsére itt meg lehet adni olyan host nevet is, ami több IP címére oldódik fel. A swarm cluster-ben minden service névvel indított DNS lekérdezésre a swarm visszaadja az összes konténer IP címét akik a szolgáltatáshoz tartoznak.   '''discovery.zen.minimum_master_nodesedit'''<br>Ebben a paraméterben kell megadni, hogy hány master node-nak kell jelen lennie egyszerre, ahhoz hogy fenntartónak ítéljék meg az egyes nódok a cluster-t. Ezzel el lehet kerülni, hogy hálózati hiba estén, mikor a cluster két fele izolálódik egymástól önálló életre keljen a két oldal, mert mind a kettő azt hiszi, hogy ők teljes cluster-t alkotnak, és beindul egy párhuzamos működés, ami visszafordíthatatlan károkat okozna a cluser-ben. (split brain) (master_eligible_nodes / 2) + 1To explain, imagine that you have a cluster consisting of two master-eligible nodes. A network failure breaks communication between these two nodes. Each node sees one master-eligible node… itself. With minimum_master_nodes set to the default of 1, this is sufficient to form a cluster. Each node elects itself as the new master (thinking that the other master-eligible node has died) and the result is two clusters, or a split brain. These two nodes will never rejoin until one node is restarted. Any data that has been written to the restarted node will be lost.  Now imagine that you have a cluster with three master-eligible nodes, and minimum_master_nodes set to 2. If a network split separates one node from the other two nodes, the side with one node cannot see enough master-eligible nodes and will realise that it cannot elect itself as master. The side with two nodes will elect a new master (if needed) and continue functioning correctly. As soon as the network split is resolved, the single node will rejoin the cluster and start serving requests again.  ==Perzisztencia==Ez itt a legnagyobb kérdés. Még akkor is ha nem dinamikusan létrehozott VM-eken futtatjuk az ES cluster-t, a swarm minden egyes újraindításkor más és más node-ra fogja rakni ugyan azt a node-ot.  ...  ===Produkciós beállítások===Ha kivesszük a '''discovery.type=single-node''' paramétert, és ezen felül még a '''network.host''' paramétert is beállítjuk, az ES produkciós üzemmódban fog elindulni. Produkciós indulás közben sokkal szigorúbban ellenőrzi a kötelező beállításokat. Ebből a legfontosabb host operációs rendszernek (jelen esetben a boot2docker) a '''vm.max_map_count''' beállítása, amit fel kell emelni minimum '''262144'''-ra. Ha ez kevesebb, az adott node nem fog elindulni. <pre>docker-machine ssh mg0...sudo sysctl -w vm.max_map_count=262144</pre>  ==Egy lehetséges megoldás==Mivel minden master és data node-nak saját perzisztencia store-ra van szüksége nem tehetjük meg simán egy darab swarm service-ként elindítjuk a cluster-t és aztán felskálázzuk (docker swarm scale). Tehát az világos, hogy minden data és manager node-ot külön service-ként kell definiálni. Viszont az ingress overlay hálózatra csak egy service-hez tudjuk a 9200-as portot definiálni. (feltéve, ha el akarjuk érni kívülről). Szerencsére a koordinációs node-oknak (amik nem végeznek se master, de data se Ingest tevékenységet, kizárólag a kliensek kéréseit rout-olják a megfelelő node-okhoz) nem kell hogy legyen mentett data mappája, így ezeket létre tudjuk hozzon több elemű swarm service-ként, mint Elasticsearch belépési pont, és akkor a swarm ingress hálózat még meg is oldja a load-balancing-ot.  ===Közös konfigurációs fájl===A közös konfigurációs fájlba felvesszük az összes cluster tag végpontját '''discovery.zen.ping.unicast.hosts''' paraméterben. A listában minden egyes sor egy swarm service neve, amit a swarm DNS felold konténer IP címére. Egyedül a '''elasticsearch_coord''' lesz több konténerből álló szolgáltatás, amik rá lesznek kötve az ingress hálózatra is, ezek lesznek az ES cluster belépési pontjai. Szerencsére a zen discovery képes olyan DNS válaszokat is kezelni, amik több végpontot adnak vissza. <br>Az alábbi fájlt fel fogjuk csatolni az összes service-be NFS megosztással. <br>/usr/share/elasticsearch/config/'''elasticsearc.yml'''<syntaxhighlight lang="C++">cluster.name: "my-cluster"network.host: 0.0.0.0 discovery.zen.minimum_master_nodes: 2 discovery.zen.ping.unicast.hosts: - elasticsearch_coord - elasticsearch1 - elasticsearch2 - elasticsearch3</syntaxhighlight>  Az összes ES node a közös elk nevű overlay hálózaton tud majd közvetlen kommunikálni egymással.    ===Coordinating node-ok===A Coordinating node-okat több elemű swarm service-ként fogjuk létrehozni. Ezek a node-ok lesznek a ES cluster belépési pontjai. Egyedül ebben a swarm service-ben lesz több mint egy konténer. Data mappát nem is csatolunk fel hozzá. Ahhoz hogy coordinating node-ként viselkedjen egy node be kell állítani, hogy se nem data, se nem master és se nem ingest tevékenységet nem végezhet. Ehhez létrehozhattunk volna egy külön konfigurációs fájlt a coordinating node-oknak, mi most itt beírtuk környezeti változóba. 3 példányt kértünk belőle. Az ingress hálózaton a 9200 -as porton érhetjük majd el a coordinating node-okat bármelyik swarm node IP címén.<syntaxhighlight lang="C++"> elasticsearch_coord: image: docker.elastic.co/elasticsearch/derpturkeyelasticsearch:6.com4.0 ports: - "9200:9200" networks: - elk volumes: - "es-conf:/usr/share/elasticsearch/config" environment: - node.data=false - node.master=false -node.ingest=false deploy: replicas: 2 restart_policy: condition: on-failure</syntaxhighlight> ===További node-ok definiálása===Mivel most nem akarunk hatalmas cluster-t építeni, három további node-ot fogunk a cluster-withhez adni, amik már mind a három szerepkörben benne lesznek (master, data és ingest). Mivel a master és az adat node-oknak már saját data mappára van szüksége, minden node-ot egy külön swarm service-ként fogunk definiálni saját volume plugin megosztással a perzisztens store-ban. Így bárhol is hozza létre őket a swarm, mindig ugyan azt a data mappát fogják megkapni. <syntaxhighlight lang="C++"> elasticsearch1,2,3: image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0 ports: - "9200:9200" networks: - elk volumes: - "es-conf:/usr/share/elasticsearch/config" -engine"es-swarmdata1,2,3:/usr/share/elasticsearch/data" environment: - node.name=node1,2,3 deploy: replicas: 1 restart_policy: condition: on-failure</syntaxhighlight>A fenti compose blokkot háromszor kell a compose fájlba rakni a megfelelő sorszámmal a service, node és volume megosztás nevében (1,2,3)  ==Docker stack fájl== {{warning|Nincs még frissítve...}} <syntaxhighlight lang="C++">version: '3'services: .... networks: elk: driver: overlay volumes: elasticsearch-conf: driver: nfs driver_opts: share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/elasticsearch/config es-data1: driver: nfs driver_opts: share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/elasticsearch/data1 es-modedata2: driver: nfs driver_opts: share: 192.168.42.1:/home/adam/Projects/DockerCourse/persistentstore/elasticsearch/data2</syntaxhighlight>

• ← Older edit

Adam

Bureaucrat, administrator

7,540

edits