Obserwowalność Oracle Exadata
Twoja Exadata może być sprawna.Jej wydajność niekoniecznie.
Co może być trudne do zauważenia podczas monitorowania mocno skonsolidowanego środowiska Exadata.
Szacowany czas czytania: 5–6 minut
Dlaczego to ważne
Dobra kondycja nie pokazuje całej historii
Exadata dostarcza ogromną ilość informacji o tym, co dzieje się w środowisku. Dostępne są metryki CPU, I/O, aktywności baz danych, storage, sieci i wielu innych obszarów.
Dlaczego więc problemy z wydajnością nadal bywają trudne do zdiagnozowania? Jednym z powodów jest to, że posiadanie metryk nie oznacza jeszcze posiadania właściwego obrazu środowiska.
Jest to szczególnie widoczne w skonsolidowanych systemach Exadata. Gdy wiele baz współdzieli tę samą infrastrukturę, zachowanie jednej z nich może wpływać na wydajność innej. Problem może też trwać krótko i zniknąć z obrazu danych historycznych.
Właśnie w tym miejscu ograniczenia tradycyjnego monitoringu stają się widoczne.
Masz dane. Ale czy widzisz ich historię?
Pierwszym wyzwaniem podczas analizy problemu z wydajnością Exadata zwykle nie jest znalezienie metryki. Jest nim połączenie metryk w jeden spójny obraz.
Objaw w bazie
Załóżmy, że baza nagle zaczyna odpowiadać wolniej. W jej metrykach może być widoczne wyższe opóźnienie lub większe użycie CPU, ale nie musi z nich wynikać dlaczego tak się stało.
Kontekst platformy
W tym samym czasie inna baza może generować intensywne I/O, komórka storage może pracować pod zwiększonym obciążeniem, ruch sieciowy może się zmienić, a kilka workloadów może konkurować o te same zasoby. Wszystkie metryki są dostępne, lecz oglądane osobno wymagają od DBA ręcznego łączenia faktów.
Od gotowych widoków do monitoringu projektowanego dla Exadata
Oracle Enterprise Manager
Oracle Enterprise Manager oferuje szeroki zestaw funkcji monitorowania Oracle i Exadata, w tym gotowe dashboardy i widoki. Dla wielu zadań operacyjnych jest to wystarczające. Trudność pojawia się wtedy, gdy środowisko trzeba obejrzeć dokładnie z perspektywy badanego incydentu.
Grafana
Grafana daje w takiej analizie znacznie większą elastyczność: pozwala łączyć metryki, modyfikować dashboardy i prezentować dane z różnych źródeł. Samodzielne zbudowanie środowiska monitoringu Exadata wymaga jednak decyzji o tym, co i jak zbierać, jak długo przechowywać dane oraz jak utrzymywać użyteczne dashboardy.
GoMon4Exa
W tym obszarze GoMon4Exa może być alternatywą. Wykorzystuje Prometheus do zbierania i przechowywania metryk oraz Grafanę do wizualizacji, ale dashboardy i podejście do monitoringu są od początku projektowane wokół Exadata.
Zamiast zaczynać od uniwersalnej platformy i dopasowywać ją do Exadata, zacznij od pytań troubleshootingowych i zbuduj wokół nich właściwy widok.
A jeśli problem już zniknął?
Niektóre z najtrudniejszych problemów wydajnościowych przestają występować, zanim rozpocznie się ich analiza.
Problem z CPU lub storage może trwać kilka minut. Aplikacja zwalnia, użytkownicy zgłaszają incydent, a zanim DBA spojrzy na środowisko, wszystko ponownie wygląda normalnie. Dlatego dane historyczne są tak ważne.
OEM udostępnia historię metryk, lecz szczegółowe dane są z czasem agregowane, a interwał zbierania zależy od metryki i konfiguracji. To pomaga zrozumieć trendy długoterminowe, ale jest mniej użyteczne przy pytaniu: co dokładnie wydarzyło się w ciągu tych pięciu minut?
Krótkie nasycenie CPU, zakłócenie storage lub problem sieciowy może silnie wpłynąć na aplikację, nie zmieniając istotnie średniej dobowej. Właśnie wtedy przydają się metryki o wyższej rozdzielczości.
Prometheus może dłużej zachowywać metryki w ich pierwotnej rozdzielczości. Zamiast analizować tylko średnie, można odtworzyć rzeczywistą kolejność zdarzeń.
Pięć minut, które wyjaśniają incydent
CPU zaczyna rosnąć
rośnie obciążenie bazy
zmienia się opóźnienie I/O
wydłuża się czas odpowiedzi aplikacji
obciążenie wraca do normy
Taka sekwencja mówi znacznie więcej niż średnia dobowa. Prometheus i Grafana dają tę możliwość, ale samodzielne zbudowanie monitoringu specyficznego dla Exadata nadal wymaga pracy.
GoMon4Exa dostarcza tę warstwę od razu: wysokorozdzielcze metryki historyczne oparte na Prometheus oraz dashboardy Grafany zaprojektowane do analizy wydajności Exadata.
Najważniejsze nie jest samo przechowywanie większej ilości danych, lecz możliwość odtworzenia zdarzeń po ustąpieniu problemu.
Problem może nie leżeć w Twojej bazie
To jeden z najczęstszych scenariuszy w skonsolidowanym środowisku Exadata: baza jest wolna, więc naturalnie zaczynasz analizę właśnie od niej.
Baza może jednak być jedynie miejscem, w którym problem staje się widoczny. Gdy kilka baz współdzieli CPU, I/O, sieć i storage, jedno obciążenie może wpływać na inne. Wyższe opóźnienie w jednej bazie może być skutkiem intensywnego zużycia zasobów przez inną.
OEM pomaga identyfikować zużycie zasobów przez bazy i analizować wykorzystanie Exadata, szczególnie w obszarze CPU, I/O i metryk Oracle. W mocno skonsolidowanym środowisku pojawia się jednak dodatkowe pytanie: kto jeszcze korzystał z tych samych zasobów?
Zrozumienie wkładu poszczególnych workloadów wspiera planowanie pojemności, optymalizację oraz — gdy jest to właściwe — raportowanie wykorzystania lub chargeback.
GoMon4Exa został zaprojektowany właśnie z myślą o takich środowiskach. Zamiast ograniczać się do wydajności pojedynczej bazy, pokazuje platformę jako całość i pomaga wskazać konsumentów zasobów oraz potencjalne konflikty między workloadami.
Pytanie początkowe
“Dlaczego ta baza działa wolno?”
Lepszy punkt wyjścia
“Co dzieje się na platformie i może spowalniać tę bazę?”
Exadata nie działa w próżni
Exadata jest tylko jednym z elementów większości środowisk produkcyjnych.
Źródło problemu
Problem z wydajnością aplikacji może obejmować samą aplikację, Kubernetes, host, bazę danych, storage, infrastrukturę sieciową lub inne obciążenie. Źródło problemu nie zawsze jest więc widoczne w środowisku monitoringu Oracle.
Wspólna oś czasu
Prometheus i Grafana są użyteczne w takiej architekturze, ponieważ łączą metryki różnych systemów w jednej warstwie monitoringu. Na wspólnej osi czasu można umieścić czas odpowiedzi aplikacji, aktywność bazy, CPU hosta, I/O storage i metryki Exadata.
Konfiguracja platformy
Uniwersalna platforma obserwowalności nadal wymaga konfiguracji pod konkretne środowisko: właściwych exporterów, metryk, etykiet, retencji i dashboardów, a także wiedzy, które metryki Exadata pomagają w danym typie incydentu.
Warstwa Exadata
GoMon4Exa dostarcza część specyficzną dla Exadata. Ponieważ bazuje na Prometheus, metryki Exadata można analizować razem z danymi innych systemów, zamiast tworzyć kolejną odizolowaną wyspę monitoringu.
Czy te dwa zdarzenia naprawdę wystąpiły jednocześnie, czy tylko zakładamy, że są powiązane?
Celem nie jest zastąpienie każdego narzędzia monitorującego, lecz uczynienie Exadata użyteczną częścią wspólnego obrazu obserwowalności.
Znalezienie wolnej bazy to jeszcze nie root cause
W troubleshooting można zwykle wejść z dwóch stron — od platformy albo od workloadu.
Top-down
Zacznij od platformy
Widzisz, że w środowisku Exadata dzieje się coś nieprawidłowego. Szukasz nietypowego zużycia zasobów, wskazujesz głównych uczestników, a następnie schodzisz do bazy, workloadu i ostatecznie odpowiedzialnego SQL-a.
Bottom-up
Zacznij od workloadu
Wiesz już, która baza lub zapytanie ma problem. Sprawdzasz, jakie zasoby zużywa, kto jeszcze z nich korzysta, co dzieje się na storage lub hoście i które inne bazy mogą odczuwać ten sam wpływ.
Oba kierunki są potrzebne, ponieważ źródło problemu i widoczny objaw nie zawsze znajdują się w tym samym miejscu. Baza może raportować wysokie opóźnienie, podczas gdy presję na zasoby wywołuje inny workload.
Podejście skoncentrowane wyłącznie na wydajności pojedynczej bazy staje się wtedy ograniczeniem. GoMon4Exa wspiera oba kierunki analizy: od platformy Exadata do workloadów i SQL-a oraz od konkretnej bazy na zewnątrz, ku jej wpływowi na całą platformę.
Dla DBA oznacza to mniej czasu spędzonego na przełączaniu się między niepowiązanymi widokami i więcej czasu na zrozumieniu tego, co rzeczywiście się dzieje.
Od danych do wyjaśnienia
Monitoring powinien odpowiadać, nie tylko alarmować
Exadata już teraz udostępnia wiele danych monitoringowych. Wyzwaniem jest uczynienie ich użytecznymi wtedy, gdy coś przestaje działać prawidłowo.
Oracle Enterprise Manager jest mocny w monitorowaniu, diagnostyce i zarządzaniu technologiami Oracle. Prometheus i Grafana oferują elastyczność, wysoką rozdzielczość metryk oraz łączenie danych z różnych systemów. Żadne z tych podejść nie musi automatycznie zastępować drugiego.
Dla organizacji potrzebujących warstwy obserwowalności bardziej skoncentrowanej na Exadata, GoMon4Exa łączy metryki Prometheus z dashboardami Grafany zaprojektowanymi wokół analizy wydajności i środowisk skonsolidowanych.
“Coś jest nie tak.”