Oc Pasm Monitor. Andrzej Rydzanicz Opitz Consulting Kraków Sp.z o.o.

Transkrypt

1 XV Konferencja PLOUG Kościelisko Październik 2009 Oc Pasm Monitor Andrzej Rydzanicz Opitz Consulting Kraków Sp.z o.o. Abstrakt. Celem prezentacji jest przedstawienie platformy PASM Monitor (Pro-Active-System-Management) bazującej na produkcie Nagios (Open Source) oraz OC-AGENT aplikacji Java napisanej na potrzeby naszego projektu celem zwiększenia wydajności oraz niezawodności naszych usług. Zaprezentowany zostanie całościowy zakres moŝliwości systemu monitoringu szerokiej gamy produków firmy ORACLE oraz uŝyte technologie (Nagios, shell scripting, Java, OSGi, Oracle Database oraz Oracle APEX).Wykład oparty jest o praktyczne doświadczenia z projektów.

2 Oc Pasm Monitor Wprowadzenie Wczesne dostrzeganie problemów zagraŝających całej infrastrukturze informatycznej firmy, wymaga niezawodnego narzędzia monitorującego jakim z pewnością jest Nagios (oprogramowanie Open Source mające szeroki wachlarz zastosowań, jeŝeli chodzi o nadzór Infrastruktury IT). Zaprojektowany z myślą o uŝytkownikach końcowych (administratorzy), nagios swą skalowalnością oraz elastycznoscią daje pewność, iŝ krytyczne procesy biznesowe nie zostaną przerwane przez nieznane problemy natury technicznej. Nagios jest potęŝnym narzędziem dającym moŝliwość śledzenia procesów biznesowych w czasie rzeczywistym, co pozwala wykryć a następnie usunąć usterki w infrastrukturze IT, tak aby uŝytkownik końcowy nie był świadom zaistaniałych problemów. 2. Czym jest OC PASM? OC PASM Opitz Consulting Pro-Active-System-Managment. Naszym celem jest dostarczenie wysoko wyspecjalizowanego systemu charakteryzującego się 24 godzinną dostępnością przez 7 dni w tygodniu. W skład tego systemu wchodzą następujace komponenty: 2.1. Monitoring 2.2. Administracja 2.3. Stały kontakt telefoniczny (24h przez 7 dni w tygodniu) OC PASM (Opitz Consulting ProActiveSystemManagment) jest zunifikowanym, dostosowanym do potrzeb klienta, kompleksowym systemem zarządzania oraz nadzoru baz danych Oracle. Wszystkie działania wykonywane są zgodnie z tzw. SLA (Servive Level Agreements). Administracja odbywa się w oparciu o komponent monitorujący (Nagios). Precyzyjnie wytyczone drogi eskalacji mają na celu zapewnienie jesczcze większej niezawodności. Podstawowym komponentem tego systemu jest wyŝej wspomniany Nagios. Główną ideą monitoringu baz danych, jest szybkie wykrywanie sytuacji konfliktowych, które mogą przerodzić się w szeroko rozumiane przerwy w dostawie usług bazodanowych. Naszym celem było zbudowanie systemu monitoringu, który byłby uniwersalny do tego stopnia, aby mógł działać na róŝnych platformach oraz nadzorować róŝnego typu rozproszone środowiska klientów. Z załoŝenia system musiałbyć w stanie monitorować rozproszone systemy klienta zbierając istotne informacje statusowe oraz statystyczne a następnie wysyłać powiadomienia do odpowiednich grup odpowiedzialnych za dany komponent, sieć lub system. Przetestowaliśmy róŝnego rodzaju narzędzia, ale najbardziej odpowiednim i niezawodnym okazał sie właśnie Nagios. System ten oferuje równieŝ prosty w uŝyciu (wręcz intuicyjny) interfejs uŝytkownika. Szczególną cechą tego narzędzia okazała sie bardzo łatwa integracja z naszym systemem ticket-owym (aplikacja Pasm) co doprowadziło do powstania wyŝej wymienionej juz platformy OC PASM MONITOR. 3. Czym jest Nagios? Oryginalnie Nagios powstał pod roboczą nazwą NetSaint. Został napisany oraz jest wspierany przez Ethan Galstad oraz grupę programistów, którzy aktywnie uczestniczą w rozwoju tego narzędzia jak rownieŝ wielu dodatków/wtyczek (plugins). Istotnym atutem Nagiosa jest fakt, iŝ jest to narzędzie całkowicie opensourcowe (GNU GPL). Po co wydawać setki tysięcy złotych na oprogramowanie komercyjne (np. Enterprise Manager), gdy nie płacąc ani złotówki moŝemy uzyskać tą samą funkcjonalność. Nagios to system monitorowania hostów i usług w sieci komputerowej dający moŝliwość sprawdzania ich stanu w zaplanowanym czasie przy uŝyciu wtyczek. Nagios ma

3 134 Andrzej Rydzanicz moŝliwość sprawdzania rownocześnie wielu usług, oferując przy tym zcentralizowany interfejs uŝytkownika, dający moŝliwość skupienia się na komponentach, które nas interesują. Generalna zasada monitoringu przy pomocy Nagiosa brzmi: mogę monitorować wszystko, co da sie monitorować przy pomocy wtyczki (dostarczonej standardowo, bądź napisanej własnoręcznie). KaŜdy wykryty błąd lub usterka jest natychmiast komunikowana naleŝnym grupom administratorów, które rownieŝ moŝemy zdefiniować w zaleŝności od monitorowanego komponentu. Komunikacja moŝe odbywać sie na wiele sposobow ( , pager, sms lub inny zdefiniowany przez uŝytkownika sposób). Narzędzie oferuje takŝe moŝliwość określenia stopnia ostrzeŝeń dla poszczególnych grup uŝytkowników (stany: Uknown, Warning, Critical) jak rowniez tzw. tłumienia wysyłania komunikatów na określony czas. Ogólna architektura narzędzia prezentuje się następująco: Rys. 1. Ogólna architektura Nagiosa Nagios regularnie czyta plik z komendami oraz pozwala modyfikować proces monitorowania i wysyłania komunikatów podczas działania narzędzia. Nagios daje rownieŝ moŝliwość interakcji z aplikacją z zewnątrz poprzez tzw. plik External Comand File. PoniŜej przedstawiona jest architektura owego rozwiązania.

4 Oc Pasm Monitor 135 Rys. 2. Architektura pracy Nagiosa Takowa interakcja daje moŝliwość wprowadzania komend (np. przez apikacje zewnętrzną) do pliku, które następnie zostaną przez proces Nagios wykonane w zadanym czasie. Nagios oferuje dwa rodzaje metod sprawdzania usług sieciowych: aktywne oraz pasywne. Monitoring aktywny to synchroniczne oraz planowane przez proces Nagiosa wykonania komend, mających na celu uzyskanie statusu danej usługi w zadanym czasie. Monitorowanie pasywne polega zaś na analizowaniu wyników dostarczonych przez zewnętrzne aplikacje (w sposób asynchroniczny). Przetwarzanie danych odbywa sie w ten sam sposób jak w monitoringu aktywnym. 4. Czym jest platforma PASM MONITOR? Poprzez lata doświadczeń oraz testów udało nam się zaimplementować nowatorską platformę OC PASM Monitor. Jej ogólna architektura przedstawia sie nastepujaco:

5 136 Andrzej Rydzanicz Rys. 3. Architektura Platformy OC PASM MONITOR Jak widać na powyŝszej grafice, cała infrastruktura monitorująca podzielona jest na dwie części. Pierwsza to maszyna PMS (pasywny monitoring Pasm Monitoring Systen) oraz PAS (aktywny monitoring). KaŜda z maszyn PAS podłączana jest do infrastruktury sieciowej klienta gdzie wykonywane są aktywne odpytania statusów poszczególnych usług sieciowych. Maszyna PMS jest tylko jedna tutaj przekazywane są zbiorcze statusy usług sieciowych zebranych przez aktywny monitoring realizowany przez serwery PAS, rezydujące u poszczególnych klientów. To właśnie PMS udostępnia interfejs uŝytkownika dający moŝliwość generowania grafik dla poszczególnych usług sieciowych (obrazujących ich dostępność w przeciągu określonego czasu itd.) tzw. grafik modułu PNP. PoniŜsza grafika prezentuje przykładowe średnie czasy odpowiedzi oraz ilość utraconych pakietów ICMP oraz aktualne zuŝycie procesora.

6 Oc Pasm Monitor 137 Rys. 4. Grafiki PNP (PING oraz zuŝycie CPU) Następna grafika odnosi sie bezpośrednio do bazy danych i prezentuje aktualną liczbę sesji oraz procesów uŝytkowników.

7 138 Andrzej Rydzanicz Rys. 5. Grafiki PNP (Aktualna liczba sesji oraz liczba procesów oraclowych) W zaleŝności od interesujących nas statystyk, mamy do dyspozycji następujące ramy czasowe: 4 godziny, 24 godziny, 1 tydzień, 1 miesiąc 1 rok. 5. OC-AGENT i jego zadania Kolejnym nieodzownym elementem platformy jest komponent pośredniczący między maszynami PAS oraz PMS noszący nazwę OC-AGENT. Jest to aplikacja Java napisana specjalnie na potrzeby platformy. Stanowi swoisty pomost w przekazywaniu informacji do centralnego komponentu platformy (serwera PMS). Wszystkie informacje zebrane przez aktywny monitoring na temat odpytywanych usług gromadzone są w dwóch plikach: service-perfdata.$time$ oraz hostperfdata.$time$ (makro $TIMES$ oznacza czas w formacie uniksowym ilość sekund od roku 1970). Oto przykładowa zawartość jednego z plików: ServerB PING 0 PING OK - Packet loss = 0%, RTA = 0.31 ms rta= ms; ; ; pl=0%;20;60; ServerA PING 0 PING OK - Packet loss = 0%, RTA = 0.25 ms rta= ms; ; ; pl=0%;20;60; ServerB ICIP: tablespace IMAGE 0 ICIP : IMAGE OK - 0% used [ 1 / 500 MB used ] used=1mb;85;92;0;500

8 Oc Pasm Monitor ServerB Swap Usage 0 SWAP OK: 87% free (26504 MB out of MB) swap=26503mb;0;0;0;3046 Na pierwszym miejscu widzimy liczbę, która reprezentuje uniksowy format czasu oznaczający ilość sekund od roku Przykładowo: Liczba oznacza date Di 8. Sep 17:49:31 CEST 2009 (date Następnie widzimy nazwę hosta do którego odnosi sie check oraz zwróconą wartość. Charakterystyczną cechą tego wyniku jest pionowa kreska (pipe), która dzieli wynik na dwie czesci: ServerA DB: tablespace IMAGE 0 DB : IMAGE OK - 0% used [ 1 / 500 MB used ] used=1mb;85;92;0;500 Pierwsza część (powyŝej) reprezentuje faktyczny string, który ujrzymy później w interfejsie uŝytkownika jako wynik wykonanego checku, druga zaś (poniŝej), stanowi dane dla modułu PNP odpowiedzialnego za kreślenie wykresów: used=1mb;85;92;0;500 1MB aktualna zajetosc 85 wartosc w procentach okreslajaca poziom warning 92 wartosc w procentach okreslajaca poziom critical 0 wartosc min. 500 wartosc max. Jak juŝ wspomniano wyniki poszczególnych check-ów zapisywane są do dwóch plików, które są systematycznie przetwarzane przez OC-AGENT-a tzn. wyniki są zbierane i przekazywane dalej do modułu centralnego. Takie rozwiązanie ma jedną zasadniczą zaletę, w razie wystąpienia problemów natury sieciowej w komunikacji między modułem centralnym (PMS) i lokalnym (PAS) OC-AGENT jest w stanie odłoŝyć dane i przekazać je w późniejszym terminie, gdy problemy zostaną usunięte. Naszym celem jest szczególna dbałość o dane klienta, tak więc cała komunikacja między centralnym komponentem a maszyną PAS odbywa sie przy uŝyciu protokołu https. PoniŜsza grafika przedstawia proces przetwarzania plików wynikowych przez proces OC-AGENT. Jak widać w początkowej fazie ilość plików wynikowych wzrasta, ale po chwili znowu spada do zera co wskazuje na to, iŝ pliki zostały zebrane przez proces OC-AGENT i przekazane dalej do modułu centralnego. Proces ten odbywa sie cyklicznie.

9 140 Andrzej Rydzanicz Rys. 6. Proces przesyłu plików wynikowych do modułu centralnego OC-AGENT to bardzo elastyczny, modułowy komponent, sterowany centralnie. Mamy moŝliwość ustalania czasu próbkowania (z jaką czestotliwością OC-AGENT ma przekazywać pliki). Istnieje rownieŝ moŝliwość, aby OC-AGENT uaktualnił swoją konfigurację. PoniŜej przedstawiono przykład startu agenta: 2009/02/09 13:54:13 /opt/oc_agent/./load/wsclient-0.10.jar 2009/02/09 13:54:13 /opt/oc_agent/./load/servicelayer-0.10.jar 2009/02/09 13:54:13 /opt/oc_agent/./load/checkuploader-0.20.jar 2009/02/09 13:54:13 /opt/oc_agent/./load/configupdater-0.20.jar 2009/02/09 13:54:14 Installed /opt/oc_agent/load/checkuploader-0.20.jar: null 2009/02/09 13:54:14 Installed /opt/oc_agent/load/wsclient-0.10.jar: null 2009/02/09 13:54:14 Installed /opt/oc_agent/load/servicelayer-0.10.jar: null 2009/02/09 13:54:14 Installed /opt/oc_agent/load/configupdater-0.20.jar: null 2009/02/09 13:55:15 Service-Layer started 2009/02/09 13:55:25 Service-Layer: Initially started ConfigUpdater 2009/02/09 13:55:25 ServiceLayer: Config still null

10 Oc Pasm Monitor /02/09 13:55:25 Config-Updater: Bearbeite Host pas403 und Plugin OCAgentServiceLayer 2009/02/09 13:55:26 Bearbeite Config /02/09 13:55:26 Service-Layer: Config injected! 2009/02/09 13:55:26 Config-Updater: Bearbeite Host pas403 und Plugin OCAgentConfigUpdater 2009/02/09 13:55:26 Bearbeite Config /02/09 13:55:26 Config-Updater: Bearbeite Host pas403 und Plugin OCAgentCheckUploader 2009/02/09 13:55:26 Bearbeite Config /02/09 13:55:27 Schleifenlauf 2009/02/09 13:55:27 OC Agent - Service Layer /02/09 13:55:27 OC-Agent Config-Updater Version /02/09 13:55:27 ist gestartet 2009/02/09 13:55:27 OC-Agent Check-Uploader Version /02/09 13:55:27 wurde gestartet 2009/02/09 13:55:27 CheckUploader RUN 2009/02/09 13:55:27 Check-Uploader: Process file service-perfdata /02/09 13:55:27 Check-Uploader: Process file service-perfdata /02/09 13:55:27 Check-Uploader: Process file service-perfdata /02/09 13:55:27 Check-Uploader: Process file host-perfdata /02/09 13:55:27 Check-Uploader: Process file service-perfdata Tekst pogrubiony prezentuje 4 zasadnicze komponenty: WSCLIENT, SERVICELAYER, CHECKUPLOADER, CONFIGUPDATER NajwaŜniejszym z nich jest WSCLIENT, który odpowiada za właściwą komunikację z modułem centralnym. CONFIGUPDATER zajmuje się aktualizacją konfiguracji, zaś CHECKUPLOA- DER przesyłem plików wynikowych (sprawdza czy istnieją, jeŝeli tak, to inicjonowana jest transmisja przez komponent wsclient). Następnie moŝna zauwaŝyć jak OC-AGENT zainstalował poszczególne moduły (tekst oznaczony kolorem zielonym). Tekst oznaczony kolorem niebieskim pokazuje, jak poszczególne pliki są uploadowane przez moduł CHECKUPLOADER. 6. Monitorowanie baz danych ORACLE Nagios nie narzuca ograniczeń na elementy, jakie chcemy monitorować. Zasada monitoringu przy pomocy wtyczek daje adminstratorom szeroki wachlarz zastosowań. Wystarczy prosty skrypt schell-owy (bash, ksh..) aby móc monitorować stan bazy danych i jej nierozłącznych komponentów. Check_oracle.sh skypt składający sie z wielu procedur odnoszących sie do konkretnego elementu, bedącego przedmiotem monitoringu. Przykładowe wykonanie skryptu moŝe wygladąć następująco: (naleŝy przy tym pamiętać, iŝ skrypt wykonywany jest aktywnie a rezultaty jego odpytań będą przekazane dalej do centralnego systemu PMS poprzez OC AGENT-a). Wykonanie z poziomu systemu operacyjnego (maszyna aktywnie monitorujacą serwer PAS): Usage: check_oracle.sh --tablespace <USER> <PASS> <INST> <TABLESPACE> <CRITICAL> <WARN- ING> pas350:/usr/local/nagios/libexec #./check_oracle.sh --tablespace nagios xxx sid SYSTEM fors : SYSTEM OK - 1% used [ 439 / MB used ] 'used'=439mb;70;90;0;32767

11 142 Andrzej Rydzanicz Podgląd graficznego interfejsu wykonania tego checku serwer PMS: Oczywiście cała komunikacja z bazą danych odbywa sie przy pomocy protokołu SQL.NET. Zaprezentowany wyŝej rodzaj checku jest tylko jednym z wielu, który opracowaliśmy aby w sposób rzeczowy i ciągły (zgodnie z SLA), monitorować systemy bazodanowe naszych klientów. Oto przykład interfejsu graficzengo, który ukazuje moŝliwości Nagiosa, jako nieodzownego komponentu OC PASM MONITOR. PoniŜsza grafika przedstawia aktualne statusy komponentów danego hosta. Widać tu podstawowe usługi jakie moŝna monitorować aby dostatecznie szybko wykrywać i zapobiegać błędom systemu operacyjnego. Dodatkowo monitorowana jest tu baza standby, która w tym przypadku znajduje sie na serwerze. Rys. 7. Interfejs uŝytkownika (statusy hosta) Jak widać powyŝej, do dyspozyji mamy metryki takie jak: bierzące obciaŝenie systemu, ilość zalogowanych uŝytkowników, dostępność hosta (PING), dostepność demona SSH, zajętość poszczególnych filesystemów, dostępność bazy standby oraz jej opóźnienie względem bazy produkcyjnej. Kolejna grafika przedstawia nie tylko statusy hosta ale równieŝ rezydującą na nim produkcyjną bazę danych Oracle. Sprawdzane są róŝnorodne komponenty, waŝne z punktu widzenia niezawodności systemu jako całości. MoŜemy wyszczególnić w obrębie monitoringu bazy następujące metryki: sprawdzanie zajętości przestrzeni tabel, aktualną liczbę sesji oraz liczbę procesów, czas od ostatniego backup-u bazy, sprawdzanie nowych wpisów (ORA-) w pliku alert.log jak równieŝ dostepność listenera i samej bazy danych (tnsping, dblogin). Rys. 8. Statusy bazy

12 Oc Pasm Monitor 143 Grafika poniŝej przedstawia z kolei monitoring samego hosta, na którym zainstalowany jest Nagios. Aby uniknąć systuacji, w której to monitoring z przyczyn bliŝej nieznanych uległ uszkodzeniu, zaimplementowaliśmy sprawdzanie maszyny nagiosowej oraz krytycznych dla jej prawidłowego działania komponentów. Rys. 9. Statusy hosta maszyny nagiosowej (PAS) Ciekawym rodzajem checku jest sprawdzanie samego procesu Nagiosa a dokładniej sprawdzanie statusowego logu deamona Nagiosa pod kątem wieku. Jeśli okaŝe sie, Ŝe log nie był uaktualniony dostatecznie długo, pojawi się alarm świadczący o tym, Ŝe proces Nagiosa nie działa lub działa nieprawidłowo. Jak juŝ wspomniałem wcześniej, Nagios oferuje szeroki wachlarz moŝliowści, jeŝeli chodzi o monitoring środowisk róŝnego typu. Jesteśmy w stanie nadzorować nie tylko pojedyńcze bazy danych (single instance) ale równieŝ róŝnego rodzaju konstelacje bazodanowe typu RAC czy Fail- Over Cluster. PoniŜsza grafika przedstawia nadzór RAC-a. Rys. 10. Monitoring środowiska typu RAC Jak moŝna łatwo zauwaŝyć nadzorowanie takiego środowiska nie róŝni się zbytnio od poprzedniego sposobu ale co moŝna zauwaŝyć na pierwszy rzut oka, to nowe pluginy kontrolujące zajętość grup dyskowych jak równieŝ samych dysków ASM. TakŜe pluginy typu dblogin i alert.log check zostaly rozdzielone na dwie osobne instancje RAC-a. Znaczącym aspektem z punktu widzenia bezpieczeństwa i niezawodności są bazy standby oraz ich monitoring. PoniŜszy przykład prezentuje plugin monitorujący opóznienie bazy standby względem produkcji jak równieŝ reprezentację graficzna tego zestawienia (moduł PNP): Rys. 11. Opóźnienie bazy standby względem produkcji Wzkres poniŝej prezentuje graficzną reprezentację powyŝszego check-u z wykorzystaniem modułu PNP. Jesteśmy w stanie dokładnie powiedzieć jak kształtowały sie wyniki opóźnienia bazy standby w zaleŝności od godziny. Poziom ostrzegawczy to w tym przypadku 45 minut, zaś 60 minut to poziom krytyczny.

13 144 Andrzej Rydzanicz Rys. 12. Graficzna reprezentacja powyŝszego checku Często zdaŝa się, Ŝe potrzebujemy wyciągnać interesujący nas raport z bazy wprowadzając ją w tryb read only. Jak widać na poniŝszym przykładzie sprawdzany jest czas, jak długo baza znajduje się w tym trybie. W razie przekroczenia krytycznej granicy generowany jest ticket: Rys. 13. Sprawdzanie czasu Read Only State - aktualny status ok Rys. 14. Sprawdzanie czasu Read Only State - aktualny status critical Nagios to bardzo praktyczne i elastyczne narzędzie. Jesteśmy w stanie monitorować nie tylko aktualny stan naszej bazy, ale równieŝ zmiany jakie zaszły w jej konfiguracji mam tu na myśli np. dodanie lub usunięcie tablespace-ów. Narzędzie to daje szeroki zakres zastosowań równieŝ w monitoring serwera aplikacji. Rys. 15. Nadzór serwera aplikacji Wielu klientów dysponuje równieŝ konstelacją typu fail-over-cluster co skłoniło nas do podjęcia wyzwania i opracowania monitoringu dla tego typu rozwiązania:

14 Oc Pasm Monitor 145 Rys. 16. Nadzór klastra typu fail-over Monitorujemy tu przede wszystkim zasoby CRS. 7. Aplikacja PASM Dzięki integracji narzędzia Nagios z naszym systemem zgłoszeniowym, powstała platforma OC PASM MONITOR. KaŜdy problem w środowisku IT klienta jest natychmiast rejestrowany przez modul monitorujący (Nagios) i przekazywany dalej do aplikacji Pasm. To właśnie na poziomie naszego systemu ticketowego odbywa sie kategoryzacja klienta jego systemów, komponentów oraz piorytetów z jakim ma być otwarty ticket. Wszystkie te informacje zawarte są w nowo powstałym tickecie tak aby dostarczyć precyzyjnych informacji na temat zaistniałego problemu. Na poziomie aplikacji mamy teŝ moŝliwość ignorowania błedów. Nie znaczy to, Ŝe zdarzenia te nie bedą raportowane, wręcz przeciwnie, bedą widoczne w systemie w postaci eventu ale nigdy nie powstanie z nich ticket. Mamy równieŝ moŝliwość zdefiniowania czasu w którym klient przeprowadzać będzie zabiegi techniczne bazy, bądz serwera, następstwem czego jest ignorowanie wszelkich błędów odnoszących się do odpowiedniego komponentu. 8. Podsumowanie Nagios to program działający jako daemon w systemie Linux do monitorowania sieci, urządzeń sieciowych, aplikacji, baz danych oraz serwerów rozpowszechnianym na podstawie licencji open source. MoŜe monitorować hosty oraz usługi według określonych ustawień, dzięki czemu jest moŝliwe dostosowanie go do swoich potrzeb. W razie wykrycia problemu Nagios moŝe wysłać E- Mail, wiadomość na pager lub SMS do administratora systemu z informacją o problemie. Jest niezwykle stabilnym oraz wszechstronnym narzędziem. Dzięki integracji z aplikacją PASM udało się nam stworzyć platformę OC PASM MONITOR, która specjalizuje się w nadzorowaniu wszelkiego rodzaju konfiguracji bazodanowych Oracle. Jej modułowość i prostota zapewnia wręcz nieograniczone moŝliwości zastosowań. Bezpieczeństwo i niezawodność to kolejny aspekt przemawiający na korzyść naszego rozwiązania, dający nam pozycję lidera wśród konkurencyjnych firm i rozwiązań na rynku niemieckim. Bibliografia