Nie tak dawno temu opisałem mój proces dochodzenia do oprogramowania Zabbix, który to zdeployowałem w chmurze Hetzner. Ma to być narzędzie, które posłuży wiele lat. Dlatego też wiedziałem, że można tam zacząć monitorować rzeczy w szerszej perspektywie czasowej. I tak jakoś szybkim krokiem możemy przejść do… apteczek samochodowych. Pewnie wielu z Was takowe posiada, ale czy regularnie sprawdza ważność ich wyposażenia? Okazuje się, że nawet w nowej apteczce niektóre elementy potrafią przeterminować się za 1,5 czy 2 lata. Zakup nowych apteczek skłonił mnie więc do poszukiwania rozwiązania, aby w jakiś sposób monitorować i zostać poinformowanym o tym, że któryś z elementów będzie expired.
Zaraz na samym początku korzystania z Zabbixa w chmurze Hetzner przygotowaliśmy skrypt, którym można było łatwo definiować strony internetowe, które następnie były monitorowane poprzez Web Scenarios. Skrypt szybko dodawał monitoring i zakładał odpowiednie triggery i inne elementy bez potrzeby ręcznego klikania. Troszkę taki wyszedł z tego pseudo Terraform, ale w Pythonie. Skrypt nie jest kompletny, nie jest idealny, ale zrobił to co trzeba, czyli po prostu dodał ten monitoring, który skutecznie zastąpił Uptime Kuma.
Sposób tworzenia tego monitoringu i alarmu bardzo mi się spodobał. Finalnym elementem dla użytkownika było w zasadzie wpisanie adresu strony i ważności monitorowania w JSON-ie, a następnie odpalenie skryptu. Pomyślałem, że coś takiego można byłoby dodać do innych rzeczy, a dobrym testem byłoby przerobienie skryptu na monitoring ważności apteczek samochodowych.
Dodawanie pozycji do apteczki
Utworzenie nowego skryptu jednak nie było tak proste. Fakt, można utworzyć pozycje i ustawić daty ważności w Zabbix, ale nie ustawimy odmierzania czasu. Tak, Zabbix sam z siebie czasu nie odmierza, a więc nie możemy ustawić, że np. odliczamy do 31 grudnia 2025, a Zabbix sam z siebie będzie odejmował z puli kolejne godziny. Niestety, tutaj potrzebny jest jakiś zewnętrzny bodziec, który ten czas odliczy i prześle wartości do serwera.
Ale od początku. Pierwszy skrypt dodaje nowe rzeczy do apteczki i ustawia dla nich datę ważności. Każda pozycja w apteczce to osobny item w Zabbix. Skrypt automatycznie tworzy też triggery – w moim przypadku są trzy alarmy dla każdego przedmiotu: pierwszy 30 dni przed końcem ważności, drugi na 14 dni, a trzeci na 7 dni przed przeterminowaniem.
Dzięki temu mam czas na spokojne zakupienie nowych produktów i wymianę tych, które wkrótce stracą ważność.
Odświeżanie danych
Tutaj pojawia się wcześniej wspomniana kwestia techniczna. Zabbix sam w sobie nie odmierza czasu dla pozycji. Jeśli mam item z datą ważności na “2025-12-31”, to Zabbix nie będzie sam sprawdzał, ile dni zostało. Potrzebny jest “zewnętrzny bodziec”, który zaktualizuje wartość i zmusi Zabbix do ponownego sprawdzenia triggerów.
Dlatego powstał drugi skrypt, który uruchamiam jako cronjob co 12 godzin w Forgejo Actions. Skrypt odpytuje Zabbix API, pobiera wszystkie pozycje związane z apteczkami i aktualizuje ich wartości.
Praca w praktyce
Kiedy zbliża się termin ważności jakiegoś produktu, dostaję powiadomienie na Telegram, tak samo jak w przypadku alertów z infrastruktury IT. Wszystko scentralizowane w jednym miejscu, więc nie muszę pamiętać, która apteczka była ostatnio sprawdzana ani co w niej się znajduje.
Ograniczenia
Największy problem to brak automatycznego usuwania pozycji. Jeśli jakiś przedmiot znika z apteczki, to muszę ręcznie usunąć go z Zabbixa. Przydałoby się, żeby skrypt porównywał aktualny stan inventory w kodzie z tym, co jest w Zabbix i sam usuwał nieaktualne pozycje. Te wszelkie problemy rozwiązałby Terraform, ale niestety, provider do Zabbixa jest przestarzały i już nie działa. Innym sposobem byłoby skorzystanie z Ansible, ale niestety, nie badałem czy jeszcze Ansible działa.
Co dalej
Myślę, aby ponownie wykorzystać ten zestaw narzędzi do podobnych rzeczy. Monitoring terminu ważności to przecież uniwersalny problem - leki w domowej apteczce, produkty spożywcze w spiżarni, przeglądy techniczne samochodu, ważność dokumentów czy subskrypcje oprogramowania. Wszystko to mogłoby być monitorowane tym samym mechanizmem.
Przydałoby się jednak usuwanie danych pozycji, kiedy te znikną z inventory w kodzie. Wymaga to refaktoringu i lepszego zaprojektowania struktury danych, ale z czasem do tego wrócę.