Linux Palvelimena: Harjoitus 2

Tehtävä 2:

http://terokarvinen.com/2016/aikataulu-linux-palvelimena-ict4tn003-22-ja-23-alkusyksy-2016

h2:

– Kerää kuormitustietoja munin -ohjelmalla
– Kuormita konetta stress:llä
– Käytä tunnilla käytyjä työkaluja arvioidaksesi kuormitusta: cpu, mem, io…
– Lopuksi analysoi munin keräämiä käyriä
– Aiheuta valitsemaasi lokiin muutamia rivejä ja analysoi niistä 2-3 riviä perusteellisesti

Vapaaehtoisia lisätehtävä:

– Valvo Nagioksella ja aiheuta hälytys
– Kokeile jotain yli ajan tilatietoja tallentavaa ohjelmaa (muuta kuin munin)
– Kirjoita oma ohjelma, joka näyttää tilatietoja Linuxissa (esim vapaa muisti, prosessorien lukumäärä…). Tehtävää helpottavat /proc/ ja /sys/, joten riittänee, kun osaat lukea tekstitiedostoja.

Munin-asennus

Ensimmäiseksi piti koneelle asentaa munin http://munin-monitoring.org/. Asennus onnistui normaalilla Sudo apt-get install komennolla. Tämä vaati, kuten aina, sekä salasanan, että pakettien asennushyväksynnän Y-valinnalla. Ohjelma ei kuitenkaan ollut terminaalissa suoritettava, vaan se asentui html-sivuiksi apache web-palvelimen kylkeen. Pikainen ohjeiden luku munin-kotisivuilta kertoi tarkemmin kuinka tuo ympäristö toimii. Kaikki logien kerääminen tapahtuu ns. pluginien avulla. Peruspaketissa oli mukana tarvittavat pluginit itse järjestelmän seurantaa silmällä pitäen. Pikainen testaus graafien toimivuudesta onnistui menemällä osoitteeseen localhost/munin. Eteen tuli kuitenkin ongelma: graafien zoomaaminen ei onnistunut, zoomattu kuva puuttui jostain syystä palvelimelta. Stackoverflow:sta (http://stackoverflow.com/questions/23352233/munin-dynazoom-not-working-on-ubuntu) löytyi kuitenkin apu ongelmaan. Komento sudo a2enmod cgi; sudo service apache2 restart korjasi ongelman.

Koneen kuormitus ja seurantaa

Koneen kuormittaminen onnistui annettujen ohjeiden perusteella stress-ohjelmalla. Pikainen testaus näytti, ettei tuotakaan ohjelmaa ollut valmiiksi asennettuna, joten aloitin stress-harjoituksen asentamalla stress-sovelluksen komennolla: sudo apt-get install stress. Tämän jälkeen antamalla komennon stress, sain näkyviin erilaisia komentoja, joilla stressausta voi testata.

CPU

Avasin toiseen terminaaliin top-ohjelman prosessien seuraamiseksi. Toisessa terminaalissa annoin komennon stress --cpu 8 --timeout 10s
TOP näytti resurssien käytön kasvaneen hieman, muttei kuitenkaan merkittävästi. Päätinkin kokeilla rankempaa testiä ajamalla stress cpu 2400 --timeout 20s
Nyt resurssien käyttö muuttui jo huomattavasti. Running processes määrä kasvoi yhdestä 2401, %Cpu(s) nousi 99,7 ja load averagekin kasvoi huomattavasti.
Screenshot_2016-09-04_11-23-31

IO

Ensimmäinen havainto oli, kun iotop sovellusta yritti käynnistää, ettei sitä ollut asennettuna. Ensin siis asensin sovelluksen komennolla sudo apt-get install iotop. Tämä vaati, kuten aina, sekä salasanan, että pakettien asennushyväksynnän Y-valinnalla.

Sovelluksen käynnistäminen ei onnistunutkaan komennolla iotop, kuten alunperin ajattelin:

matto@thumbcrown:~/Desktop$ iotop -ao
Netlink error: Operation not permitted (1)

The Linux kernel interfaces that iotop relies on now require root priviliges
or the NET_ADMIN capability. This change occured because a security issue
(CVE-2011-2494) was found that allows leakage of sensitive data across user
boundaries. If you require the ability to run iotop as a non-root user, please
configure sudo to allow you to run iotop as root.

Please do not file bugs on iotop about this.

Oikea komento olikin sudo iotop -ao ja tietenkin oman salasanan joutui tässä vaiheessa syöttämään.

stress komento stress --io 8 --timeout 20s näkyi hetkittäisenä Total DISK WRITE ja Actual DISK Write -arvojen kasvuna. Paremman otoksen sai kuitenkin antamalla komennon stress --io 20 --timeout 20s. Suuremmilla testiarvoilla iotop ei enää saanut dataa muutoksista, eikä stress testaus näkynyt sovellukselle lainkaan (kaikki arvot olivat 0.00B/s).

VM eli Muisti

Muistin seuraaminen onnistui free -h komennolla. Muistin seuraaminen testauksen aikana onnistui helpoiten komennolla watch -n 2 free -h joka seurasi muistin käyttöä ja päivitti tilanteen ruudulle 2 sekunnin välein.

stress-testaus muistilla onnistui ajamalla komento stress --vm 20 --timeout 20s
Toisella ruudulla oleva watch -n 2 free -h näytti used muistin käytön “Mem” alueella kasvavan 3,4G saakka, normaalin 170M sijasta.
Screenshot_2016-09-04_11-23-21

MUNIN-analysointi

CPU

http://localhost/munin/localdomain/localhost.localdomain/cpu.html

CPU:n käyttö graafissa selkein muutos oli “user”-käytön kasvaminen testaushetkillä. Toinen testauksen aikana kasvanut osuus oli selkeästi system-käyttö. Näiden käyttämä määrä saatavilla olevasta kapasiteetistä ei kuitenkaan graafin mukaan ollut lähelläkään 100% kokonaiskapasiteetista.

IO

http://localhost/munin/localdomain/localhost.localdomain/diskstats_iops/sda.html

Levyn stress-testaus näkyi käyrällä selkeänä piikkinä sekä luku, että kirjoitus osuuden osalta. Sekä IO/sec, että Req Size (KB) arvot olivat nousseet huomattavasti tehtyjen testien aikana. Normaalikäytössä arvot olivat hyvin lähellä nollaa.

Muisti

http://localhost/munin/localdomain/localhost.localdomain/memory.html

Muistin käytössä munin-graafi kertoi cache-osuuden kasvamisesta stress testin aikana. Myös committed osuus oli stress-testauksen aikana kasvanut merkittävästi. Muita poikkeamia muistin käyttökäyrässä ei näkynyt.

Lokirivit

Lokirivin muodostaminen oli helppoa antamalla terminaalissa komento sudo apt-get update ja jättämällä salasana syöttämättä (painoin vain enter-näppäintä). Kolmen virheellisen yrityksen jälkeen annoin komennon uudelleen ja syötin tällä kertaa myös salasanan oikein. Syntyneet logi-rivit olivat:

Sep  4 12:27:51 thumbcrown sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/8 ruser=matto rhost=  user=matto
Sep  4 12:27:58 thumbcrown sudo:    matto : 3 incorrect password attempts ; TTY=pts/8 ; PWD=/var/log ; USER=root ; COMMAND=/usr/bin/apt-get update
Sep  4 12:28:04 thumbcrown sudo:    matto : TTY=pts/8 ; PWD=/var/log ; USER=root ; COMMAND=/usr/bin/apt-get update
Sep  4 12:28:04 thumbcrown sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep  4 12:28:07 thumbcrown sudo: pam_unix(sudo:session): session closed for user root

Jokainen logi-rivi alkoi samalla tavalla Sep 4 oli kuluva päivämäärä, 12:27:51 => 12:28:07 oli kellonaika, jolloin tapahtuma kirjautui logiin, tässä tapauksessa Suomen paikallista aikaa GMT + DST = UTC +3h, thumbcrown oli palvelimen/työaseman nimi jonka logiin merkintä tuli ja sudo– oli komento joka ilmoituksen aiheutti.

Rivien jatko-osuudet puolestaan poikkesivat toisistaan, riippuen tapahtumasta.

Ensimmäinen rivi: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/8 ruser=matto rhost= user=matto, kertoi kirjautumisen epäonnistuneen. Tämä on loogista, koska ilmoitus tuli ensimmäisen kerran, kun jätin salasanan syöttämättä. uid=1000 kertoi, että virheilmoitus muodostui ensimmäiseltä ei root käyttäjältä. Samaan aikaan euid=0 kertoi, että komentoa yritettiin ajaa root käyttäjänä. tty=/dev/pts/8 kertoi logirivissä, että kirjautumista yritettiin terminaalista, jonka tunnisteena oli /pts/8. ruser ja user arvot kertoivat kirjautuneen käyttäjän käyttäjätunnuksen, joka tässä tapauksessa oli matto.

Toinen rivi: matto : 3 incorrect password attempts ; TTY=pts/8 ; PWD=/var/log ; USER=root ; COMMAND=/usr/bin/apt-get update

Kertoi meille, että käyttäjä matto on yrittänyt 3 kertaa kirjautua väärällä salasanalla. TTY kertoi terminaalin josta kirjautumista yritettiin. PWD kertoi missä kansiossa käyttäjä oli, kun kirjautumista yritettiin. USER kertoi minä käyttäjänä yritettiin kirjautua sisään ja COMMAND kertoi komentoa, jota yritettiin ajaa, mutta joka epäonnistui väärän salasanan antamisen vuoksi.

Viimeiset rivit pam_unix(sudo:session): session opened for user root by (uid=0) ja pam_unix(sudo:session): session closed for user root puolestaan kertoivat, että kirjautuminen onnistui ja sudo (pääkäyttäjä) yhteys muodostettiin onnistuneesti. Viimeinen logimerkintä kertoi lopuksi komentojen menneen läpi ja yhteyden sulkeutuneen.

Lisätehtävät

Nagios

Nagioksen asentaminen vaati normaalin sudo apt-get install nagios3 komennon lisäksi piti asennusikkunassa valita toimenpide postgresin osalta (Ilmoituksen sai pois painamalla TAB-näppäintä ja Enteriä, valitsin vaihtoehdoista No Configuration. Asennuksen valmistuttua ohjelmisto ei kuitenkaan toiminut, joten ajoin tuon sudo apt-get install nagios3-komennon uudelleen. Nyt minulta kysyttiin nagiosadmin salasanaa kahteen kertaan, jonka jälkeen ohjelmiston toiminnan pystyi varmistamaan avaamalla internet selaimen osoitteesta localhost/nagios3. Kirjautumalla nagiosadmin ja aiemmin annetulla salasanalla päästiin perusnäkymään. Perusnäkymässä eteen tuli kaksi virheilmoitusta. Ensimmäinen liittyi käynnissä olevien prosessien määrään. Määrä oli aivan odotettava, joten minun täytyi muuttaa hälytysrajaa tiedostosta /etc/nagios3/conf.d/localhost_nagios2.conf. sudo nano /etc/nagios3/conf.d/localhost_nagios2.conf ja sieltä riviä:

# Define a service to check the number of currently running procs
# on the local machine.  Warning if > 250 processes, critical if
# > 400 processes.

define service{
        use                             generic-service         ; Name of servi$
        host_name                       localhost
        service_description             Total Processes
                check_command                   check_procs!300!400
        }

Lisäksi levytilaan liittyvän hälytyksen sai korjattu muuttamalla tiedoston /etc/nagios-plugins/config/disk.cfg komennolla sudo nano /etc/nagios-plugins/config/disk.cfg riviä:

# 'check_all_disks' command definition
define command{
        command_name    check_all_disks
        command_line    /usr/lib/nagios/plugins/check_disk -w '$ARG1$' -c '$ARG2$' -e -A --ignore-eregi-path=/sys/kernel -i '.gvfs'
        }

ilman tuota viimeistä -i ‘.gvfs’-kohtaa, saamme aikaiseksi uuden virheilmoituksen (johtuu bugista). Tiedon löysin sivulta https://help.ubuntu.com/community/Nagios3.

Hälytys
Hälytyksen sai testattua esimerkiksi sammuttamalla ssh palvelimen komennolla sudo service sshd stop hälytys tulee näkymään hetken viiveellä:
Screenshot_2016-09-04_15-24-02

Hälytys hävisi vastaavasti pienellä viiveellä kun palvelun uudelleenkäynnisti komennolla sudo service sshd start.

Lähteet

13 total views, 2 views today