Tag Archives: monitoring

AA meetup & SEConference invitation

global_337963982

It looks like I’ll have once again talk at AA meetup (Anonymous Admins group). I’ll show you guys presentation I prepared for 11th Linux Session in Wrocław about Ganglia and Nagios integration. It was quite sudden as organizers asked me just yesterday and announced today that I’ll have this talk tomorrow. It’ll be fun I think ;) RSVP at http://www.meetup.com/AnonimowiAdmini/events/173718072/

seconference_logo2

Moreover this Friday I’ll give a talk about node.js security. I’ll cover topics of securing server environment, creating backend services in a stable and reliable & secure way and also I’ll try to show some patterns of insecure ways of delivering solutions based on node.js. Register at http://2014.seconference.pl/

(Polish) Opowieść o chorym administratorze, czyli OpenSource w walce ze zbyt wysokim ciśnieniem wody

Sorry guys – this post is only in polish. If You feel like reading this in english – post me a comment and I’ll do my best :)

Wstępniak

Od ponad 3 miesięcy żyliśmy w remoncie. Większość tego czasu również towarzyszyły nam jakieś choroby (czego tam mały z przedszkola nie przyniósł). No i nadszedł ten weekend – koniec remontu!

Dodam, że ja od samego początku trzymałem się nieźle – w zasadzie w ogóle nie chorowałem. Owszem – byłem już cholernie zmęczony kurzem, syfem, pyłem, łomotem, przenoszeniem mebli itd – ale żyłem tym dniem, gdy to wszystko się skończy.

Ta sobota zaczęła się inaczej. W zasadzie nie mogłem wstać z łóżka. Czułem się jakby mnie walec rozjechał. Nie byłem tak chory od kilku albo i kilkunastu lat. Yeahhhh…. Samej soboty nie pamiętam wiele – podobnie noc z soboty na niedzielę nie wyglądała najlepiej. I nadeszła niedziela. Temperatura nadal, ale walec ze mnie zjechał. Nie chciało mi się cholernie wstawać z łóżka, ale nieszczęśliwie – coś nie teges z internetem. A, że “serwerownia” znajduje się w piwnicy – musiałem się tam wybrać. Nie, żebym był szczęśliwy, ale wiecie – są pewne priorytety, a internet jest na początku tej listy.

Coś się dzieje…

Podejrzewałem, że klasycznie powiesił się router Neostrady – mimo, że dopiero co wymieniany (bo stary wieszał się ciągle). Jako, że nie mogłem się dobić do jego interfejsu tak też musiałem tam iść i załatwić to osobiście (ale już niedługo – namierzyłem tanie listwy zasilające IP – zobaczymy co wtedy powie).

Gdy już moja szanowne cztery litery zeszły do Mordoru, pierwsze co usłyszałem to “kap,kap,kap”. Cóż – “*urwa, *urwa, *urwa” pomyślałem. W trakcie remontu wymieniliśmy (co nie było w planie) wszystkie kaloryfery i sporo hydrauliki. Raz już się to zdarzyło po tej wymianie – a teraz znowu:

Na zdjęciu powyżej tego nie widać, ale piec ma miernik ciśnienia wody – akurat wskazywał max pozycję (pow. 4 atmosfer) – pewnie było więcej, bo po prostu się skala skończyła. Woda zaczęła kapać, bo po prostu uszczelka puściła. Szczęście, że uszczelka, a nie jakaś złączka gdzieś w ścianie. Notabene gdy się to wcześniej stało to pod piecem nie było wiadra a sanki małego – plastikowe. Zebrały sporo wody wtedy ;)

Simple visual monitoring

Konstrukcja niestety nie pozwala tutaj spuścić wody z obiegu – trzeba to zrobić gdzieś indziej (na górze – w mieszkaniu – bezpośrednio z jednego z kaloryferów). A to jest problem, bo nie można spuścić jej zbyt wiele – bo wtedy się zapowietrzą kaloryfery, trzeba dolewać od nowa itd. Nie myśląc zbyt wiele pobiegłem po netbooka (Toshiba NB500)  i ustawiłem go na starym foteliku małego – na przeciw pieca:

Ten netbook ma kamerkę, więc w tej chwili mógłbym po prostu połączyć się z nim via Skype. Ale to mało koszerne, bo Skype ma swoje widzimisie i zdarzało mi się, że traciłem z nim połączenie. Stąd też pomysł, aby postawić serwer kamery internetowej – na netbooku mam Fedorę 17, więc: yum install motion

I sprawa załatwiona (no prawie – nie było internetu, więc reset routera, potem jeszcze Wireshark w ruch bo to pudło się kompletnie zresetowało i po kilku chwilach już było ok). Teraz jeszcze tylko go uruchomić (service motion start), wyszukać netstatem, na którym porcie nasłuchuje i przepuścić go przez iptables (8081) i obraz gotowy. Rozłożyłem więc zestaw do spuszczania wody na górze, odpaliłem laptopa, połączyłem się z kamerką i rozpocząłem procedurę awaryjną ;)

No dobra. W ten sposób spuściłem trochę wody do wiadra i ciśnienie wróciło z powrotem do normy. Poprawiłem siłę dokręcenia kurka wody w piecu i trzymałem kciuki. Niestety po godzinie sprawa znów się pogorszyła – zarówno ciśnienie wody skoczyło do góry jak i moja temperatura.

Co tam – nie takie sytuacje się załatwiało – padały replikacje baz danych, równocześnie poole memcache’a, odpieraliśmy ataki DDos, dyski przestawały działać, ginęły backupy, wybuchały (!!!) serwerownie – i niby ciśnienie wody w piecu ma mnie pokonać? :D

DEFCON 1 – Black Ops response

Problem – rozpoznanie:

  • ciśnienie wody w obiegu szwankuje, gdy osiąga granicę 3-4 atmosfer uszczelka zaczyna puszczać wodę. Cholera wie przy jakim ciśnienie woda rozsadzi coś innego niż uszczelkę w piecu
  • jest niedziela – zapomnij o hydrauliku czy serwisie pieca
  • zapomnij o jakichkolwiek zakupach – jesteś chory, więc radź sobie z tym co masz w domu

Możliwości:

  • zakręcić dopływ wody do pieca – jednak to odetnie nas w domu od ciepłej wody w kranie. niekoszerne…
  • mając już zorganizowane stanowisko spuszczania wody można tą akcję powtórzyć kilka razy i sprawdzić czy może lekkie dokręcenie głównego zaworu w dopływie wody nie rozwiąże go – może mniejsze ciśnienie wejściowe da nam trochę czasu?
Decyzja prosta i krótka – potrzebny nam real-time monitoring, który sam nas będzie ostrzegał w sytuacji przekroczenia określonego ciśnienia (2 atmosfery) – wtedy spuszczamy wodę, delikatnie dokręcamy główny zawór wody i ponawiamy akcję.
Piec niestety jest stary – nie ma żadnej możliwości podłączenia via jakikolwiek interfejs do serwera tak aby pobierać z niego dane na temat parametrów środowiskowych. Dlatego też pozostaje nam monitoring z zewnątrz. Mamy obraz – wystarczy więc zrealizować rozpoznawanie pozycji strzałki pokazującej ciśnienie i tyle.

Automatyzujemy proces monitoringu

Niestety nie znalazłem nigdzie na CPANie czy php.necie biblioteki “jpg2pressure”, więc z palca nie udało mi się rozwiązać problemu. Rozpocząłem więc research. Po kilku minutach doszedłem do wniosku, że rozpoznawanie pozycji strzałki nie jest dobrą drogą, bo można by z tego napisać doktorat. Dużo łatwiej jest porównywać obrazy. Do tego można spokojnie skorzystać z biblioteki ImageMagick. Znalazłem tam funkcję porównywania – pozostaje się w niej zdoktoryzować: http://www.imagemagick.org/Usage/compare/

Checklista:

  1. Kamera internetowa musi być ustawiona stabilnie. Fotelik małego nie działa dobrze, znaleźć inne rozwiązanie
  2. Kamera internetowa generuje 2 obrazy na sekundę a do tego obciąża netbooka bardzo mocno (LAVG w okolicach 1, czyli max). Wystarczy nam jedno zdjęcie co minutę.
  3. Potrzebuję trzech zdjęć – dla poziomu “alert” (2 atmosfery, dla poziomu “warning” (1,5 atmosfery) oraz dla poziomu “OK” (lekko poniżej 1 atmosfery).
  4. Potrzebny jest automat, który będzie przycinał zdjęcia tak aby było widać tylko aktywne pole, po którym wędruje strzałka. Dzięki temu porównanie będzie dużo łatwiejsze.
  5. Potrzebny jest patent do porównywania tych obrazów (to już raczej załatwione – ImageMagick oraz compare)
  6. Na koniec wpinamy to w domowego Nagiosa i SMSy :)
No to do roboty:

ad1. Kamera internetowa musi być ustawiona stabilnie. Fotelik małego nie działa dobrze, znaleźć inne rozwiązanie.

To była krótka piłka. Postawiłem netbooka na szafce na buty i przybliżyłem jeszcze do pieca. Stał już bardzo stabilnie.

ad2. Kamera internetowa generuje 2 obrazy na sekundę a do tego obciąża netbooka bardzo mocno (LAVG w okolicach 1, czyli max). Wystarczy nam jedno zdjęcie co minutę.

Musiałem ogólnie zmienić kilka parametrów kamery (/etc/motion/motion.conf):
width 640
height 480
framerate 2
minimum_frame_time 60
quality 100
picture_type jpeg
Po powyższych zmianach i przeładowaniu serwera motion obciążenie netbooka spadło znacznie :)

ad3. Potrzebuję trzech zdjęć – dla poziomu “alert” (2 atmosfery, dla poziomu “warning” (1,5 atmosfery) oraz dla poziomu “OK” (lekko poniżej 1 atmosfery).

Miałem kilka zdjęć jeszcze z operacji spuszczania wody z obiegu, więc wziąłem kilka przydatnych.

ad4. Potrzebny jest automat, który będzie przycinał zdjęcia tak aby było widać tylko aktywne pole, po którym wędruje strzałka. Dzięki temu porównanie będzie dużo łatwiejsze.

Oczywiście można by się bawić w pisanie kodu, który wczytuje obraz i go tnie, ale to takie… programistyczne. A ja jestem chory i nie chce mi się dziś programować, a poza tym po co nam aż taka armata. Tutaj wystarczy convert – który jest składnikiem biblioteki ImageMagick, więc yum install ImageMagick i następnie:
/usr/bin/convert -crop 110×50+60+250 alert.jpg alert.jpg
No i mamy ślicznie przycięty obrazek. Oczywiście rozmiar oraz pozycję przycięcia wyznaczyłem organoleptycznie ;)

ad5. Potrzebny jest patent do porównywania tych obrazów

I tu się zrobiło ciekawie. Lektura do poczytania: http://www.imagemagick.org/Usage/compare/ – czytając na szybko doszedłem do wniosku, że albo próbuję metodą porównywania statystyk obrazu (Comparison Statistics) albo armatą, czyli Matching Sub-Images and Shapes (HitAndMiss Morphology, Peak Finding and extracting, Using a Laplacian Convolution Kernel – itd…).
Co mogłem powiedzieć – z Laplasjanami bawiłem się jakieś 10 lat temu gdy studiowałem fizykę, więc stwierdziłem, że najpierw dam szansę metodom statystycznym – to w końcu najprostsze rozwiązanie :)
Streszczając metodę statystyczną – podajemy 2 obrazy na wejściu, wybieramy jeden z algorytmów porównania i na wyjściu otrzymujemy pewną liczbę – a jej znaczenie zależy od algorytmu. Po lekturze dokumentacji wybrałem na początek metrykę  Average Error (over all pixels) – MAE (Mean absolute error, average channel error distance). Żeby sprawdzić jej wyniki wziąłem jeden przycięty obraz (probe.jpg), który to pokazywał przypadkową pozycję strzałĸi. Następnie w pętli zrobiłem porównanie tego obrazu za pomocą metryki MAE do kilku dziesięciu obrazów, które zebrałem w trakcie spuszczania wody z obiegu (czyli wędrówki strzałki od 4 atmosfer aż do pozycji poniżej 1 atmosfery, czyli określonej przeze mnie jako OK):
for i in ls imgs/*jpg; do /usr/bin/compare -metric mae probe.jpg $i null: 2>>data_out.csv; done
Na koniec jeszcze musiałem przyciąć plik CSV tak aby zawierał tylko liczby całkowite i żadnych stringów:
cut -d . -f 1 data_out.csv > data_out2.csv
No i mogłem zobaczyć na wykresie czy cokolwiek tutaj ma sens:
Bingo! Wyraźnie widać miejsce, w którym wartość spada do minimum, a nawet do zera. To jest miejsce, w którym osiągamy maksimum podobieństwa obrazów, czyli minimalna wartość porównania wg. metryki MAE. Sweet :) Dodam, że to co po lewej to były jakieś odrzuty danych, więc nie brałem ich pod uwagę (to były obrazy, które były zrobione jeszcze w innej pozycji kamery, przed zastąpieniem fotelika szafką na buty).
W tej chwili musiałem jeszcze określić granicę alertów dla konkretnych liczb. Wyszło mi na to, że skala podobieństwa poniżej 1800 oznacza, że obrazy są podobne na tyle, iż mogę stwierdzić, że strzałka ciśnienia jest w podanym miejscu. Dokonałem jeszcze kilku sprawdzeń i zwykresowałem wyniki na kilkunastu wykresach generowanych automatycznie gnuplotem:
Teraz pozostało to tylko ubrać w jakiś skrypt i całość gotowa:
W dużym skrócie – skrypt działa w ten sposób, że pobiera obrazy z kamery, wybiera ostatni z nich i na nim dokonuje porównania. A potem na podstawie wyniku decyduje czy wysyłać alert czy nie.

ad5. Na koniec wpinamy to w domowego Nagiosa i SMSy :)

Tutaj nie ma już co opisywać :) Tak – mam domowego Nagiosa – to chyba normalne, nie? :)

Kończ waść…

Tak jak teraz na to patrzę z perspektywy czasu… chyba na prawdę byłem chory :) Ale co by tu nie mówić – to zadziałało :) Dostałem 3 SMSy z alertami, za każdym razem spuszczałem delikatnie wodę i dokręcałem główny zawór delikatnie aż sytuacja się unormowała. Nikogo nie wzywałem już – w wakacje i tak piec wymieniam, więc zabawa się zacznie od początku.

Teraz już patent zlikwidowałem, jednak do serwera, który siedzi w piwnicy mam zamiar podpiąć kamerkę USB – tak na wszelki wypadek :) A nowy piec mam nadzieję, że będzie miał już jakiś ludzki interfejs tak, aby to monitorować po ludzku a nie metodą chałupniczą.

Co mogę powiedzieć na koniec – OpenSource rządzi :)

Aaaa.. macie na koniec zdjęcie głównego zaworu wody: