Dlaczego zdecydowałem się na własne narzędzia CLI do monitorowania serwerów API?

Na początku mojej drogi z monitorowaniem wydajności serwerów API korzystałem z popularnych narzędzi typu Grafana, Prometheus czy DataDog. Wszystkie te rozwiązania są świetne, ale często wiązały się z koniecznością konfiguracji, pełnym stackiem i wysokimi kosztami. Z czasem zdałem sobie sprawę, że do mojich potrzeb wystarczy coś prostszego, co pozwoli mi szybko i bez zbędnych ceregieli sprawdzić podstawowe metryki — czas odpowiedzi, błędy, dostępność. Właśnie wtedy postawiłem na własne narzędzia CLI, które napisałem na macOS, korzystając głównie z Node.js i Bash. Takie podejście pozwoliło mi zyskać pełną kontrolę, a jednocześnie nie obciążało systemu ani nie wymagało skomplikowanej konfiguracji.

Jak zacząłem? Wybór technologii i podstawowe założenia

Decyzja o użyciu Node.js i Bash była podyktowana głównie dostępnością i moją znajomością tych narzędzi. Node.js świetnie radzi sobie z wysyłaniem żądań HTTP, obsługą JSON i tworzeniem lekkich skryptów, które można uruchamiać z terminala. Bash natomiast to mój niezawodny partner do automatyzacji i zarządzania procesami w systemie macOS. Chciałem, aby moje narzędzia były szybkie, nie obciążały systemu i można było je łatwo modyfikować. Podstawowe założenia były proste: monitorować wybrany endpoint API co określony czas, zapisywać wyniki do pliku logu, a w razie wykrycia błędów lub przekroczenia czasu odpowiedzi wysyłać powiadomienia do Slacka.

Tworzenie pierwszego skryptu monitorującego w Node.js

Pierwszym krokiem było napisanie prostego skryptu w Node.js, który wyśle żądanie GET do wybranego API i zmierzy czas odpowiedzi. Użyłem do tego biblioteki axios, bo jest lekka i prosta w użyciu. Oto przykładowy kod:

const axios = require('axios');

const url = 'https://api.przyklad.com/endpoint';

async function checkApi() {
  const start = Date.now();
  try {
    const response = await axios.get(url);
    const duration = Date.now() - start;
    console.log(`Czas odpowiedzi: ${duration} ms, status: ${response.status}`);
    if (response.status !== 200 || duration > 500) {
      // wyzwól powiadomienie
    }
  } catch (error) {
    console.error('Błąd podczas zapytania:', error.message);
    // wyzwól powiadomienie o błędzie
  }
}

checkApi();

Ten prosty skrypt można uruchomić z poziomu terminala, a jego wynik zapisywać do pliku lub wyświetlać na bieżąco. Właśnie w tym miejscu zacząłem myśleć o automatyzacji i rozbudowie funkcjonalności.

Automatyzacja z cronem i logowanie wyników

Po opanowaniu podstawowego skryptu przyszła pora na automatyzację. Na macOS nie ma nic prostszego niż crontab — narzędzie, które pozwala uruchamiać skrypty cyklicznie. Dodałem wpis do crontaba, który wywołuje mój skrypt co minutę:

* * * * * /usr/local/bin/node /ścieżka/do/skryptu/check_api.js >> /ścieżka/do/logów/api_monitor.log 2>&1

Takie rozwiązanie pozwoliło mi mieć stały podgląd na działanie API bez konieczności ręcznego uruchamiania skryptów. Logi były zapisywane do pliku, co ułatwiło późniejszą analizę ewentualnych problemów. Co ważne, można było też stworzyć prosty skrypt Bash, który analizuje logi i wyświetla podsumowania lub wysyła alert, gdy coś jest nie tak.

Powiadomienia i integracja z Slackiem

O ile logi są przydatne, to szybka reakcja na awarie to klucz. Dlatego do mojego systemu dodałem powiadomienia przez Slacka. Wystarczyło, że w skrypcie Node.js dodałem funkcję wysyłającą żądanie POST do webhooka Slacka:

const axios = require('axios');

const webhookUrl = 'https://hooks.slack.com/services/XXXX/XXXX/XXXX';

function sendSlackNotification(message) {
  axios.post(webhookUrl, { text: message })
    .then(() => console.log('Powiadomienie wysłane'))
    .catch(err => console.error('Błąd wysyłki powiadomienia:', err.message));
}

async function checkApi() {
  // ... wcześniejszy kod
  if (response.status !== 200 || duration > 500) {
    sendSlackNotification(`🔴 API ${url} nie działa poprawnie. Status: ${response.status}, czas: ${duration} ms`);
  }
  // ...
}

W ten sposób dostawałem natychmiastowe powiadomienia, gdy coś szło nie tak. Nie potrzebowałem żadnych skomplikowanych narzędzi, wystarczyła mi szybka integracja i prostota rozwiązania.

Praktyczne wyzwania i rozwiązania

Podczas tworzenia własnego narzędzia napotkałem kilka problemów. Na przykład, czasami serwer odpowiedział z dużym opóźnieniem lub zwracał błędy, które trzeba było rozróżnić. Zdecydowałem się więc na dodanie do skryptu możliwości wysyłania statystyk do pliku CSV, co ułatwiło późniejszą analizę trendów. Innym wyzwaniem było zarządzanie powiadomieniami — nie chciałem spamować Slacka, więc wprowadziłem mechanizm, który wysyła powiadomienie dopiero po trzech kolejnych błędach, a potem czekał na poprawę. Takie rozwiązania pozwoliły mi lepiej kontrolować alerty i nie tracić czasu na fałszywe alarmy.

Korzyści i wnioski z własnej automatyzacji

Po kilku tygodniach korzystania z własnych narzędzi CLI zacząłem dostrzegać, że monitorowanie stało się znacznie prostsze i bardziej elastyczne. Mogłem szybko dodać nowe endpointy, zmienić parametry monitorowania czy dostosować alerty. Nie musiałem już polegać na zewnętrznych platformach, które czasami były zbyt rozbudowane lub kosztowne. Co najważniejsze, zyskałem pełną kontrolę nad tym, co się dzieje w mojej infrastrukturze API, a wszystko to w środowisku, które znam i lubię — macOS.

Podsumowanie: własny workflow na miarę potrzeb

Stworzenie własnych narzędzi CLI do monitorowania API okazało się strzałem w dziesiątkę. To rozwiązanie jest lekkie, szybkie, elastyczne i co najważniejsze — dostosowane do moich indywidualnych potrzeb. Dzięki temu mogę z łatwością sprawdzać wydajność własnych serwerów, szybko reagować na awarie i oszczędzić czas na konfiguracji skomplikowanych systemów. Jeśli masz choć odrobinę doświadczenia z Node.js i Bash, zachęcam do eksperymentowania — własnoręcznie napisane narzędzia często okazują się bardziej satysfakcjonujące i lepiej dopasowane do konkretnego workflow niż gotowe rozwiązania. W końcu to Twoje środowisko i Twoje potrzeby, więc warto je kształtować według własnych zasad.