Svetainių stebėjimas kūrėjams, įpintas į jūsų sistemą.

Uptimia vykdo tikrus jūsų API iškvietimus — prisijungia, paima žetoną, pateikia užsakymą, jį perskaito — ir patikrina kiekvieną atsaką. Kiekvienai cron užduočiai priskirkite veikimo signalo URL, stebėjimo objektus kurkite tiesiai iš diegimo scenarijaus, o įspėjimai jus pasieks per Slack, Discord ar PagerDuty.

Pradėkite nemokamą bandymą → Skaitykite API dokumentaciją
Daugiapakopės API grandinės ir cron veikimo signalai REST API, webhook ir įspėjimai ten, kur dirbate Be kreditinės kortelės
Stebimos svetainės
100,000+
Patikrų per dieną
50M+
Tikrinimo taškai
171+
Aprėptos šalys
70+

Keturi gedimai, kurie nesukelia klaidos

Diegimo dieną visos keturios prielaidos teisingos. Nė viena jų savaime tokia neišlieka — o kai kuri nors nustoja galioti, jokios klaidos neatsiranda.

Įsitikinimas 01

„Jei kas nors sugestų, pamatytume klaidos pranešimą.“

Klaidų sekimo įrankiai mato tik kodą, kuris vykdomas. Nepasileidusi cron eilutė, darbo viduryje užstrigęs procesas, tyliai nustojęs galioti sertifikatas — nė vienas jų nesukelia klaidos. Blogiausi gedimai palieka ne klaidos pėdsaką, o tylą.

Įsitikinimas 02

„CI patikros žalios, vadinasi, produkcinėje aplinkoje viskas gerai.“

CI įrodo, kad kodas buvo geras diegimo metu. Nebegaliojantys žetonai, prisipildę diskai, išnaudotos kvotos ir konfigūracijos nuokrypiai atsiranda tarp diegimų — veikiančioje sistemoje, kurios jūsų testai daugiau nebemato.

Įsitikinimas 03

„Sužinotume greitai — juk visą dieną sėdime prie kompiuterio.“

Prie klaviatūros sėdite 40 iš 168 savaitės valandų — likusių 128 nestebi niekas. O naudotojai apie sugedusį apmokėjimą praneša retai: bando dar kartą ir išeina.

Įsitikinimas 04

„Bandomojoje aplinkoje veikė, vadinasi, veikia.“

Bandomojoje aplinkoje niekada nebūna produkcinio srauto, tokio duomenų kiekio, trečiųjų šalių kvotų ar to paties DNS. Gedimai, kurie jus pažadina 03:00, kaip tik ir yra tie, kurių bandomoji aplinka nepakartoja.

1,440× „jis atsakė“
viena /health patikra · kasdien

„Turime /health galinį tašką — vadinasi, esame apsidraudę“ — didžiausias iš visų. Kas minutę vykdoma būklės patikra 1 440 kartų per parą praneša, kad procesas atsako (24 × 60). O kiek iš tų patikrų įrodo, kad apmokėjimas užbaigiamas, naktinė atsarginė kopija sukurta ar eilė tuštėja? Nė viena.

„Procesas atsako“ ir „sistema veikia“ — du skirtingi teiginiai. Naudotojams rūpi tik vienas iš jų.

Štai kaip atrodo tyliai sustojusi cron užduotis, kai ją stebi veikimo signalas.↓ minutė po minutės

Kas nutinka, kai cron užduotis tyliai nustoja veikti

Diegimas perrašė crontab ir vieną eilutę praleido. Tą naktį invoice-worker nepasileido, nieko nepranešė, o visi valdymo skydeliai liko žali — eilė taip ir nepajudėjo.

03:00:00 invoice-worker ping taip ir neatėjoNevykęs diegimas sugadino cron eilutę — jokios klaidos, jokio lūžio, tik tyla sąskaitos: sustojusios
03:06 Pati tyla jus ir pažadinaAtidaromas incidentas: pirmiausia Slack, tada PagerDuty, jei niekas nepatvirtina sąskaitos: sustojusios
03:15 Cron eilutė pataisyta, užduotis paleista iš naujoViena klaidinga eilutė šio vakaro diegime — rasta tą pačią naktį, kai buvo išleista sąskaitos: sustojusios
03:19 Ateina kitas ping — išspręsta automatiškaiAtsistatymą patvirtina pats ping, o įrašas išsaugomas incidento istorijoje sąskaitos: juda
19 mintyla → sutvarkyta
Sutvarkyta tą pačią naktį.03:19
Sustojusi veikti užduotis pati savęs neįspės — todėl neatėjęs ping ir yra įspėjimas. Niekam nereikia tris dienas nieko nežinoti.
įrašoma viena curl eilutesutvarkyta per 19 min.išspręsta automatiškaikopijos · eilės · sinchronizacijos — tas pats jungiklis
O be veikimo signalo? Nustojusi veikti užduotis atrodo lygiai taip pat kaip veikianti — abiem atvejais tyla. Gedimas išlenda trečią dieną, kai kas nors paklausia, kur dingo sąskaitos. trečia diena

Tiek apie nutrūkusią užduotį. Bet cron — tik vienas paviršius, gendantis be garso; kiekvienas aukščiau minėtas įsitikinimas turi savo paviršių.↓ kiekvienam po stebėjimo objektą

Grandinės, ping signalai ir agentai

API grandinės paslaugoms, gaunami veikimo signalai užduotims, tikros naršyklės srautai atsiskaitymams, vienos eilutės agentas serveriui. Skirtingi paviršiai, vienas incidentų srautas, viena API.

API stebėjimasIškvietimai grandinėje, tikrinami žingsnis po žingsnio
Veikimo signalas (cron)Neatėjęs ping ir yra įspėjimas
WebhooksĮspėjimai — POST į jūsų galinį tašką
Serverio rodikliaiCPU, RAM ir diskas iš vidaus
1 įspėjimų ašis svetainės · užduotys · serveriai · srautai
Veikimo patikrosKas 30 s nuo Professional plano
OperacijosTikros naršyklės srautai, žingsnis po žingsnio
12 įspėjimų kanalųSlack, PagerDuty, SMS ir dar 9
Patikros iš išorės vykdomos iš 171+ tikrinimo taškų 70+ šalyse, o kiek regionų turi sutarti — iki 3 — nusprendžiate jūs, ir tik tada kas nors iškviečiamas. Vienas nestabilus maršrutas niekada netaps iškvietimu 03:00, o kiekvieną čia esantį stebėjimo objektą galima valdyti per REST API. jokių netikrų pavojaus signalų
Daugiau apie API stebėjimą →

Grandinės, veikimo signalai ir eskalavimo pakopos

API stebėjimas kūrėjams

Iškvietimai grandinėje, tikrinami kiekvienas atskirai

/health galinis taškas įrodo, kad procesas atsako. Apie už jo esantį srautą jis neįrodo nieko. Grandinė iš eilės įvykdo tikrus iškvietimus ir patikrina kiekvieną atsaką — būsenos kodą, užtrukusį laiką, reikšmę JSON viduje — net kas minutę visuose mokamuose planuose, iš visų vietų arba tik iš tų, kurias pasirenkate.

  • Iki 15 žingsnių — GET, POST, PUT, PATCH, DELETE ar HEAD, vykdomi iš eilės
  • Paimkite ir panaudokite — reikšmę iš vieno atsako įstatykite į kitą per {{token}}
  • Tikrinkite tai, kas svarbu — būsenos kodą, atsako laiką, JSONPath reikšmę, antraštę ar atsako turinį, kiekviename žingsnyje
Daugiau apie API stebėjimą →
POST/auth/login200 · paimama
{{token}}
POST/orders201 · <800 ms
{{orderId}}
GET/orders/{{orderId}}$.status = paid
DEL/orders/{{orderId}}204 · išvaloma
Įrodyta: apmokėjimas veikia218 ms
Visi keturi iškvietimai pavyko — prisijungta, užsakyta, apmokėjimas patvirtintas, išvalyta. Patvirtinta iš 3 vietų.
4 žingsniaikas 60 s2 kintamieji
Visą tą laiką /health patikra atsakinėja puikiai — ir neįrodo nė vieno iš šių keturių iškvietimų. įrodyta 0 iš 4
Cron užduočių stebėjimas

Užduotis, kuri taip ir nepasileido

Nustojusi veikti užduotis netampa raudona — ji tiesiog nutyla: klaidos niekas nesukelia, tad niekas ir neįspėja. Priskirkite jai veikimo signalo URL, į kurį ji siųstų ping kaskart pasileidusi, ir įspėjimu taps neatėjęs ping: praleidus terminą kartu su leistinu vėlavimu, Uptimia atidaro incidentą. Praneškite ir apie pradžią, ir apie pabaigą — tada pagaunamos ir tos užduotys, kurios ne sustoja, o pakimba.

  • Intervalas arba cron grafikas — paprastas intervalas arba 5 laukų cron išraiška jūsų paskyros laiko juostoje
  • Įrašoma viena eilute — paruošti fragmentai Crontab, Bash, PowerShell, GitHub Actions ir PHP
  • Pagauna ne tik praleidimus, bet ir pakibimus — atsiųskite pradžios ping, o vykdymo trukmės riba pažymės užduotį, kuri taip ir nesibaigia
Daugiau apie veikimo signalų stebėjimą →
nightly-backup · siunčia ping į /p/hb_9f3c… · cron 0 3 * * *
Tue03:00✓ 1.2 s
+ 24 h
Wed03:00✓ 1.1 s
+ 24 h
Thu03:00✓ 1.3 s
tyla
Fri03:00nėra ping
Incidentas atidarytas03:15
nightly-backup praleido savo 03:00 langą ir tylėjo visą jai skirtą 15 minučių leistino vėlavimo laiką. Ji nutilo, o ne pasidarė raudona.
SlackPagerDutyEl. paštas
Nustojusi veikti užduotis klaidos nesukelia — ji tiesiog nutyla. Įspėjimu tampa neatėjęs ping. vėlavimas 15 min.
REST API ir webhook įspėjimai

Stebėjimo objektai, sukurti diegimo žingsnyje

Niekas nieko nespaudžia — stebėjimo objektą sukūrė tas pats scenarijus, kuris išleido paslaugą. Stebėjimo objektus kurkite ir tvarkykite per REST API tiesiai iš CI žingsnio, o atsidarius incidentui pasirinktinis webhook POST užklausa nusiųs jį ten, kur jau dirbate: į būsenų lentą, į botą, į ChatOps srautą.

  • REST API — kurkite, skaitykite, atnaujinkite ir trinkite stebėjimo objektus visuose planuose (API stebėjimo objektai ir veikimo signalai — v2 versijoje), o paskyros API raktus tvarkote nustatymuose
  • Pasirinktiniai webhook — kai stebėjimo objektas suveikia, į bet kurį galinį tašką POST užklausa siunčiamas fiksuotas JSON turinys su jūsų pačių antraštėmis
  • Saugu iš karto — siunčiant webhook tikrinamas TLS, fiksuojamas DNS ir atmetami vidinio tinklo adresai
Skaitykite API ir webhook dokumentaciją →
Jūsų diegimo procesasCI žingsnis
# uses your account API key
curl -X POST …/api/v2/api-monitor
  -d '{"name":"Checkout API","interval":60}'
→ 201 Created · tas pats scenarijus, kuris išleido paslaugą, sukūrė ir jos stebėjimo objektą.
Stebėjimo objektas #4821 · veikia
tikrinama kas 60 s iš visų vietų
atsidaro incidentas → POST
Pasirinktinis webhook
POST hooks.caldmont.com/uptimia
jūsų antraštėsTLS patikrintabe peradresavimų
Naują paslaugą prijunkite tiesiai iš diegimo proceso — nereikia spaudinėti mygtukų kiekvienai naujai aplinkai. 0 paspaudimų
Įspėjimai ten, kur jau esate

Pirmiausia Slack, tada PagerDuty, jei niekas nepatvirtina

Į kanalą, kurį jūsų komanda ir taip stebi, o ne į pašto dėžutę, kurios naktį niekas neatidaro. Neatsakytą Slack žinutę eskalavimo pakopos jūsų nustatytu laiku pakelia iki PagerDuty iškvietimo, o vienas patvirtinimas — paspaustas pačiame įspėjime, be prisijungimo — sustabdo visus laukiančius žingsnius visiems.

  • Įspėjimai ten, kur dirbate — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, el. paštas, SMS, webhook ir kiti
  • Eskalavimo pakopos — iki 10 žingsnių su nustatytais laiko tarpais vienose taisyklėse; patvirtinus tiesiai iš įspėjimo eskalavimas sustoja
  • Pirmiausia patvirtinama — sutrikimą patvirtina keli regionai, o vėluojančių užduočių palaukiama iki leistino vėlavimo pabaigos, ir tik tada kas nors iškviečiamas
Daugiau apie neveikimo įspėjimus →
Incidentas — invoice-worker03:06
Neatėjęs ping, patvirtinta iš kelių regionų. Eskalavimo taisyklės: Budėjimo pakopos.
SlackDiscordPagerDuty+ dar 9
1
#incidents (Slack)
iškviesta 03:06 · visas budėjimo kanalas
nepatvirtinta
+ 5 min. · nepatvirtinta
2
PagerDuty budėjimas
patvirtino Sam 03:13 · iš įspėjimo, be prisijungimo
eskalavimas pristabdytas
+ 10 min
3
Visi · visi kanalai
būtų iškviesti 03:21 — miega toliau
Vienas patvirtinimas sustabdo visus žemiau esančius žingsnius — kas nebuvo iškviestas, tas ir liks neiškviestas, o niekieno telefonas neskambina du kartus. patvirtinus — sustoja

Įspėjimas randa jus ten, kur jau dirbate, o ne dar viename valdymo skydelyje

Sustojęs procesas, nutrūkusi grandinė, be vietos diske likęs serveris — viskas pasiekia tuos pačius kanalus ir viskas valdoma per REST API.

Budėjimas ir eskalavimas
PagerDuty Webhooks Twilio
Tiesioginiai kanalai
El. paštas SMS

Vienas kontaktų sąrašas — nustatote kartą, per API arba UI.

Peržiūrėkite visą integracijų katalogą →
04:10 · atidarytas incidentas — invoice-worker · nėra veikimo signalo nuo 03:00
#ops-alertsSlack
⚠ Nėra veikimo signalo — invoice-worker · kas valandą
laukta 04:00vėlavimas 10 min.Patvirtinti ↩
+371 ··· 4082SMS
Uptimia: NĖRA VEIKIMO SIGNALO invoice-worker. Laukta 04:00, leistinas vėlavimas 10 min.; paskutinis ping 03:00:12.
InboxEl. paštas
⚠ Nėra veikimo signalo — invoice-worker · kas valandą
Paskutinis ping 03:00:12, kito laukta iki 04:00 su 10 minučių leistinu vėlavimu. Vykdymo žurnalas ir webhook turinys — incidento kortelėje…
ProductionPagerDuty
TRIGGEREDNėra veikimo signalo — invoice-worker
priskirta budinčiajam · per Uptimia integraciją

Nepavykęs diegimas turi jus įspėti.Ne naudotojai.

30 dienų bandymas atrakina visus stebėjimo tipus ir visus įspėjimų kanalus.

Išbandykite nemokamai 30 dienų →
30 dienų nemokamai be kreditinės kortelės atšaukite bet kada

Pirmąjį stebėjimo objektą sukurkite per 3 žingsnius

Nukreipkite į objektą, nustatykite įspėjimų kanalą ir palikite veikti.

1 žingsnis2 minutės

Pasirinkite paviršių

API grandinė, veikimo signalo URL, naršyklės srautas ar vienos eilutės agentas — sukurkite jį naudotojo sąsajoje arba per REST API.

Stebėjimo tipas
API grandinėVeikimo signalasServerisVeikimo laikas
arba POST /api/v2/api-monitor tiesiai iš diegimo proceso
2 žingsnis1 minutė

Nukreipkite įspėjimą

Siųskite jį į Slack, Discord ar PagerDuty, pridėkite webhook ir nuspręskite, kam pranešti toliau, jei niekas nepatvirtina.

Įspėjimų kanalai
SlackPagerDutyWebhook+ dar 9
eskalavimas: Slack → +5 min. PagerDuty → +15 min. visi
3 žingsnisautomatiškai

Palikite veikti

Patikros vykdomos iš 171+ stebėjimo vietų ir, prieš jus iškviesdamos, patvirtina gedimą — įspėjime įvardijamas sugedęs žingsnis ar užduotis.

Veikia
Checkout API · kas minutę · patvirtina 3 regionai
nightly-backup · ping 03:00 · laiku

Taip pat įskaičiuota

Vienos eilutės serverio agentas

CPU, atmintis, diskas ir apkrova iš paties serverio vidaus — bash diegimas su kontroline suma, jokio savo rinkiklio rašyti nereikia. Linux, per systemd laikmatį arba cron.

curl -s uptimia.com/server-agent/install.sh | bash -s -- $KEY

Operacijų stebėjimas

Prisijungimą ar apmokėjimą atkartokite tikroje naršyklėje — srautą sudėliojate žingsnis po žingsnio rengyklėje, o kiekvieno žingsnio ekrano nuotrauka parodo, ką jis matė.

✓ prisijungimo srautas · tikra naršyklė

Techninės priežiūros laikotarpiai

Diegiate šįvakar? Suplanuokite laikotarpį — patikros pristabdomos, įspėjimai tyli, ir per planuotą diegimą niekas nebus iškviestas be reikalo.

Sk 02:00–03:00 · įspėjimai išjungti

Atsistatymo pranešimai

Kai paslauga atsistato, apie tai sužino visi, kas gavo įspėjimą — kanale nebelieka kabančio klausimo „ar vis dar neveikia?“.

✓ atsistatė · 03:19 · 13 min.

Incidentų istorija

Kiekvienas incidentas užrašomas: kas suveikė, kada, kiek truko atsistatymas ir — jei veikė eskalavimo pakopos — kas jį patvirtino.

MTTA ir laiko juosta · kiekvienam incidentui

Vienas sąrašas grandinėms ir užduotims

API grandinės, veikimo signalai, serveriai ir veikimo patikros dalijasi vienu valdymo skydeliu, viena įspėjimų ašimi ir viena API — o ne keturios atskiros priemonės.

Checkout APIAPI GRANDINĖ nightly-backupVEIKIMO SIGNALAS web-01SERVERIO AGENTAS

Kas yra svetainių stebėjimas kūrėjams?

Svetainių stebėjimas kūrėjams — tai praktika stebėti tai, ką patys išleidžiate: HTTP API, foninius procesus, serverius ir naudotojų srautus, o kuriam nors sugedus gauti įspėjimą per įrankius, kuriuos jau naudojate. Stebėjimą įpinate į savo sistemą: daugiapakopė API patikra iš išorės, veikimo signalo ping, kurį atsiunčia pati cron užduotis, agentas serverio viduje ir REST API su webhook ten, kur mieliau parašysite scenarijų.

Vien būklės patikra

Atsako, bet vis tiek neveikia

GET /health
atsako puikiai
tuo tarpu
Apmokėjimas neveikia
nepavyksta užsakymo žingsnis

Paviršutiniškas ping lieka žalias, o srautas, nuo kurio priklauso naudotojai, tuo metu genda.

Stebėjimo objektas, tikrinantis srautą

Grandinė tai pagauna

4 žingsnių API grandinė
prisijungimas → užsakymas → patikra
nepavyksta 2 žingsnis
Iškvietimas į Slack
„2 žingsnis — /orders nepavyko“

Neišlaikyta tikrinimo sąlyga įvardija konkretų iškvietimą — todėl iš karto imatės klaidos paieškos, o ne spėlionių.

Pagal paviršių

Kuris stebėjimo objektas ką stebi

Kiekviena šeima stebi vis kitą paviršių, o valdymo skydelis, įspėjimų ašis ir REST API — bendri. Kiekviena skaičiuojama atskirai, o brangiausiai kainuoja grandinė — tikslūs skaičiai kiekvienam planui pateikti kainų puslapyje.

Visi stebėjimo tipai →
PaviršiusKą aptinkameKaip tai veikia
API grandinėSugedę daugiapakopiai srautaiIki 15 žingsnių iš eilės su tikrinimo sąlygomis kiekvienam žingsniui, tikrinama net kas minutę
Veikimo signalasTyliai sustojusios cron užduotys ir procesaiGaunamo ping URL; praleidus terminą ir leistiną vėlavimą atidaromas incidentas
Veikimo laikasSutrikimai, serverio klaidosPatikros iš išorės net kas 30 s nuo Professional plano; gedimą patvirtina iki 3 regionų
Serverio agentasCPU, atminties, disko apkrovaVienos eilutės Linux agentas, kas 30 s siunčiantis /proc ir df duomenis
OperacijaSugedę prisijungimai ir apmokėjimaiDaugiapakopiai srautai atkartojami tikroje naršyklėje

Stebėjimas kūrėjams ir DevOps: dažnai užduodami klausimai

01Kas yra svetainių stebėjimas kūrėjams?+
Tai stebėjimas, kurį įpinate į savo sistemą, o ne dar vienas valdymo skydelis, kurį reikia nepamiršti atsiversti. Nukreipkite jį į tai, ką patys išleidžiate — API grandinę, cron užduoties veikimo signalą, serverį, prisijungimo srautą — ir jis įspės per įrankius, kuriuos jau naudojate. Viskas pasiekiama ir per REST API, tad naują paslaugą galima prijungti tiesiai diegimo procese.
02Ar galima stebėti visą daugiapakopį API srautą, o ne vieną galinį tašką?+
Taip — sudėliokite grandinę iš iki 15 užklausų iš eilės (GET, POST, PUT, PATCH, DELETE, HEAD), reikšmę iš vieno atsako įstatykite į kitą per {{token}} ir kiekviename žingsnyje tikrinkite būsenos kodą, atsako laiką, JSONPath reikšmę, antraštę ar atsako turinį. Jei žingsnis nepavyksta, įspėjimas jį įvardija — iš karto žinote, kuris iškvietimas sugedo.
03Kaip stebėti cron užduotį ar foninį procesą?+
Veikimo signalo stebėjimo objektu — budrumo jungikliu. Užduotis gauna savo unikalų ping URL; pridėkite vieną curl eilutę, ir ji atsiųs ping kaskart pasileidusi. Nustatykite intervalą arba cron grafiką su leistinu vėlavimu, ir jei ping neatkeliauja, atidaromas incidentas. Pradžios ping kartu su vykdymo trukmės riba pagauna ir pakibusias užduotis. Paruošti fragmentai apima Crontab, Bash, PowerShell, GitHub Actions ir PHP.
04Ar yra API, per kurią galima kurti ir tvarkyti stebėjimo objektus?+
Taip — REST API leidžia kurti, skaityti, atnaujinti ir trinti stebėjimo objektus iš savo įrankių, ir tai veikia visuose planuose. API stebėjimo objektai ir veikimo signalai yra v2 versijoje (kiti tipai pasiekiami ir v1), o autentifikuojamasi paskyros API raktais, kuriuos tvarkote nustatymuose; API raktų puslapyje rasite paruoštą nukopijuoti curl pavyzdį. Nėra nei Terraform provider, nei Zapier programėlės.
05Ar galima kiekvienam komandos nariui išduoti atskirą API raktą?+
Kol kas ne. API raktai priklauso paskyrai — atskiro rakto konkrečiam nariui išduoti ar atšaukti negalima. Susikurkite tiek pavadintų raktų, kiek reikia skirtingiems scenarijams ar aplinkoms, ir keiskite juos nustatymuose.
06Kur ateina įspėjimai ir ar galima juos nukreipti į savo įrankius?+
Į Slack, Discord, Telegram, Microsoft Teams, Mattermost, PagerDuty, el. paštą, SMS, WhatsApp, Twilio, Atlassian Statuspage ir pasirinktinius webhook. Webhook į bet kurį galinį tašką POST užklausa siunčia fiksuotą JSON turinį su jūsų antraštėmis — incidentus galite nukreipti į būsenų lentą, botą ar ChatOps srautą. Siunčiant tikrinamas TLS, fiksuojamas DNS ir atmetami vidinio tinklo adresai. Skambučių ir mobiliųjų pranešimų kanalų nėra.
07Ar tvarkote budėjimo grafikus?+
Grafikų — ne. Eskalavimo pakopos veikia nuo Professional plano: iš eilės einantys žingsniai su nustatytais laiko tarpais (iki 10, nuo 1 minutės iki 24 valandų), kurie kviečia vis kitą kanalą, kol kas nors patvirtina — tada eskalavimas sustoja visiems, o jei incidentas po jūsų nurodyto minučių skaičiaus vis dar atviras, gali automatiškai atsinaujinti. Savaitinio budėjimo grafiko Uptimia netvarko — jei rotacijoms naudojate PagerDuty, nukreipkite pakopas į jį.
08Ar serverio agentas veikia Windows sistemoje?+
Valdymo skydelyje pateikiama nukopijuojama diegimo komanda skirta Linux: bash agentas su kontroline suma, kuris įsidiegia kaip systemd laikmatis (atsarginis variantas — cron) ir skaito /proc bei df, kad praneštų CPU, atmintį, diską ir apkrovą. Kartu pateikiami PowerShell rinkiklis Windows sistemai ir macOS variantas — jie siunčia tą patį turinį, tik be atskirų branduolių ir I/O laukimo rodiklių, kuriuos atskleidžia vien Linux, — bet vienos eilutės komandos jiems nėra. Windows serverius taip pat galima stebėti iš išorės: veikimo, API arba operacijų stebėjimo objektais.
09Ar galima į API rengyklę importuoti cURL komandą ar OpenAPI aprašą?+
Kol kas ne — grandinės dėliojamos žingsnis po žingsnio rengyklėje, cURL ar OpenAPI importo nėra. Jei nenorite spaudyti mygtukų, API stebėjimo objektus kurkite ir atnaujinkite programiškai per REST API.
10Kiek grandinių, veikimo signalų ir agentų telpa į planą?+
Kiekviena šeima skaičiuojama atskirai, o brangiausiai kainuoja grandinė — vienas stebėjimo objektas yra visa užklausų seka, tad kainuoja maždaug tiek, kiek turi žingsnių. API grandinės, serverių agentai ir naršyklės srautai skaičiuojami griežtai; veikimo signalai — tai gaunami ping signalai, už kurių nėra jokio tikrinimo darbo, tad jų skaičiuojama taip pat dosniai kaip veikimo patikrų. Tikslūs skaičiai kiekvienam planui pateikti kainų puslapyje — planą rinkitės pagal grandines, kurias ketinate laikyti nuolat, o ne pagal tas, kurias tik išbandysite.

Išleiskite. Prižiūrėsime mes.

Bandymo metu prijunkite API grandinę, veikimo signalą ir serverio agentą — įspėjimai jus pasieks ten, kur jau esate.

Pradėkite nemokamą bandymą →
API grandinės ir veikimo signalai įskaičiuoti REST API ir webhook Įspėjimai į Slack, Discord ir PagerDuty Be kreditinės kortelės
30 dienų nemokamas bandymas · visi stebėjimo tipai įskaičiuoti · įspėjimai į įrankius, kuriuos jau naudojate