Skip to content
cronitorex.com
Cronitorex Cronitorex

Migracja do Cronitorex

Z Cronitor

API ping Cronitorex jest celowo kompatybilne z formatem Cronitor: te same wartości status (run, complete, fail, skip), te same opcjonalne pola (duration, exit_code, host, msg) i te same parametry ?api_key= / ?series= w wersji GET. W większości przypadków migracja sprowadza się do:

  1. Utworzenia odpowiadającego monitora w panelu Cronitorex i wygenerowania klucza API.
  2. Wskazania istniejących pingów na endpoint Cronitorex zamiast Cronitor, z nowym kluczem API.
  3. Pozostawienia reszty wywołania bez zmian: wartości statusów, parametry.
curl "https://cronitor.link/p/<CRONITOR_KEY>/my-job?state=complete"
curl "https://cronitorex.com/ping/my-job?api_key=<API_KEY>&status=complete"

Z PostPing, Healthchecks.io lub innego narzędzia opartego na pingach

Wzorzec jest ten sam niezależnie od punktu startu: te narzędzia działają przez wywołanie przez job jakiegoś URL-a przy starcie/sukcesie/błędzie. Żeby się przenieść:

  1. Utwórz monitor w Cronitorex i pobierz jego URL do pingowania oraz klucz API.
  2. W wrapperze cron lub jobie CI podmień stary URL pingu na URL Cronitorex, używając klienta cronitorex.sh lub zwykłego curl na GET /ping.
  3. Zmapuj wartości statusów starego narzędzia na cztery stany Cronitorex: run, complete, fail, skip (zobacz Typy zdarzeń i statusy).

Checklist migracji

  • Zinwentaryzuj każdy job, który obecnie pinguje stary serwis (cron, CI, timery systemd, k8s CronJobs).
  • Uruchom oba serwisy równolegle przez kilka cykli na job - nie przełączaj joba, dopóki nie zobaczysz pinga complete lub fail w Cronitorex.
  • Odtwórz routing alertów (email/Slack/webhook) dla każdego monitora przed wyłączeniem starego narzędzia, żeby nie było luki w pokryciu.
  • Gdy każdy monitor będzie potwierdzony jako działający, usuń pingi starego serwisu i anuluj subskrypcję.