Ha van egy dolog, amelyet a vállalkozások nem engedhetik meg maguknak a mai versenykörnyezetben, akkor a rendszer nem optimális.


Még rosszabb, ha egy vagy több alrendszer meghibásodik, és a műszaki csapat nem ismeri azt. A kritikus iparágakban, mint például a bankok, a tőzsdei kereskedelem stb., A leállások millió dollárt (vagy annál többet) fizethetnek percenként, míg másokban végzetes ügyfelek válhatnak vissza. Már majdnem eljutott arra a pontra, hogy egy hiba megismerése, még mielőtt az ügyfél megteszi, nem csak okos; ez kötelező.

API-k, API-k, mindenhol

Ez egy olyan API, amelyben az API-k uralják, és valószínűleg napi többször is hallja és használja a kifejezést. Ha bármilyen szolgáltató vagy, akkor rendelkezik olyan API-kkal, amelyekre mások támaszkodnak, és vannak olyan API-k, amelyeket fogyasztanak a vállalkozás működésének fenntartása érdekében (Google Maps API, fizetési API-k stb.). De ez csak a jéghegy csúcsa. A számítógépes programozás világában az Application Programming Interface (API) egy széles kifejezés, amely nem csupán a térképeken és a vásárlásokon terjed ki..

Anélkül, hogy felismernéd, a szoftverrendszerben minden (igen, szó szerint mindent) egy API vagy egy API-t tesz ki.

Mielőtt továbblépnénk az API-k figyelésére, szánjunk egy percet arra, hogy megértsük, mi az API és milyen szoftverrendszer-kiterjesztést fed le. Ez segít csökkenteni a választásokat, és jobban eldönti, mely API-kat kívánja lefedni, és ezért mely eszközök lesznek jobbak az egyedi felhasználási esethez.

Mi az API??

Kezdjük a szokásos tankönyv-meghatározással, mielőtt mélyebben kidolgozzuk a mindennapi üzleti szókincset. Ha a Wikipedia-t kérdezzük az API-król, akkor az a következő:

A számítógépes programozásban az alkalmazásprogramozási felület (API) egy szubrutin definíciók, kommunikációs protokollok és eszközök az eszközkészlethez. Általános értelemben ez egyértelműen meghatározott módszerek összessége a különböző elemek közötti kommunikációhoz. A jó API megkönnyíti a számítógépes program fejlesztését, mivel biztosítja az összes építőelemet, amelyeket a programozó összerak.

Az API lehet web alapú rendszer, operációs rendszer, adatbázis rendszer, számítógépes hardver vagy szoftver könyvtár számára.

A második sor elengedhetetlen (a hangsúly az enyém). Az API-knak nem csak a webszolgáltatások számítanak. Operációs rendszerhívások, adatbázis-rendszer-interakciók, hardverjelek, szoftverkönyvtárak (kód, amelyet egy másik kód újra felhasználhat) – mindegyike egy API hatálya alá tartozik, mivel mindegyik jól definiált, jól megérthető felületet és protokollokat tartalmaz..

Most, bármely adott napon, ezen API-k bármelyike ​​leállhat. Lehet, hogy a merevlemez másodpercenként elérte a bemeneti / kimeneti műveletek korlátját, vagy lejárt az SSL tanúsítvány, vagy van egy nem észlelt hiba a használt kód legújabb verziójában – ezek a helyzetek folyamatos figyelést és azonnali cselekedetet tesznek szükségessé, amikor (lehetőleg korábban) probléma merül fel.

Megfelelően ez a cikk olyan eszközöket javasol, amelyek figyelemmel kísérhetik az alkalmazást minden területen, nem csupán a két rendszer közötti adatcserét.

Az API leállások költsége

Nehéz számszerűsíteni, hogy mekkora a leállás ideje, de Gartner kiadott egy tanulmány 2014-ben, amely rögzítette a számot 300 000 dollár óránként. Ez természetesen szerény átlag. Fontolja meg az üzleti veszteséget, amelyet egy órányi állásidő okozott, mondjuk a fekete péntek kedvezményes időszakában. További horror történeteket arról, hogy a hibás / nem működő API-k megölték az üzleti vagy a munkavállalói szellemet, lásd: itt és itt.

Noha az API leállások üzleti oldalát nem lehet alábecsülni, van egy rejtett veszteség, amely hosszú távon még nagyobb lehet – a csapat morálja. A fejlesztők szeretik az automatizálást és a rendszerek megbízhatóságát (valójában mindannyian; képzeljük el, hogy a levelezőszervere napi többször lemegy!), És a leállások megtörik a kódot, és megrontják őket. Ha ezek továbbra is fennállnak, a problémák hamarosan más üzleti funkciókat (értékesítés és marketing) érintnek, amelyek megunnak, hogy folyamatosan elveszítik az arcát az ügyfél előtt.

Szorosan láttam, hogy két vállalkozás halálhoz közeli halálban van a gyenge házon belüli felügyeleti rendszerek miatt, és nincs szívem, hogy újra látom. ��

A leállásokat nem lehet kiküszöbölni; a való világban bármi bármikor rosszul fordulhat. Megfelelő megfigyelő rendszerek bevezetésével megismerhetjük a hibákat, amikor azok előfordulnak, néha még az ügyfél előtt!

Tekintettel erre, nézzük meg a piac legjobb API-figyelő eszközeit.

Uptrends

Komplett megoldás mindenféle API-figyelésre (emlékszel az API-nak a korábbi átfogó meghatározására?), Uptrends figyelést biztosít webhelyek, API-k, szerverek és egyebek számára. Meghaladja a 25 000 boldog ügyfélt, ügyfelei körében például a Vimeo, a Microsoft, a Volkswagen, a Vimeo és még sok más névvel..

Az Uptrends egyedülálló tulajdonsága a böngésző alapú tesztelés. A szolgáltatás az aktuális különféle böngészőket hozza létre az alkalmazás / webhely futtatásához, és részletes mutatót ad a teljesítményéről.

De a válaszidők és a mutatók csak a fele a történetnek. Az Uptrends részletes, eszköz-alapú teljesítményjelentést nyújt Önnek, így pontosan tudja, mi okozza a szűk keresztmetszetet. Hiba észlelésekor a szolgáltatás készít egy képernyőképet, és elküldi azt neked, így pontosan láthatja, hogy milyen az érzése az egyenlet másik végén. ��

Összességében az Uptrends egy megbízható és kellemes szolgáltatás, amelyet sok nagy név bíz meg.

Dotcom-Monitor

A Dotcom-Monitor platform lehetővé teszi a multi-task monitor eszköz konfigurálását egy HTTP / S feladat segítségével. Ezzel figyelemmel kísérheti az OAuth 2.0 alapú webes API-kat a rendelkezésre állás, a teljesítmény és a megfelelő válaszok szempontjából. Egy vagy több végfelhasználói kérés replikálásával és egy SOAP webszolgáltatás megfigyelésével a Dotcom-Monitor ügynökök ellenőrzik, hogy az adatok megfelelően cserélhetők-e az API és a webalkalmazás között..

Amikor egy ügynök hibát észlel, ellenőrzi az eszköz szűrőjével. Ha a hibát nem szűrik ki, akkor az eszköz riasztást indít. Konfigurálhat több riasztási csoportot, és beállíthat testreszabott riasztási ütemezéseket és eszkalációs lehetőségeket. A jelentések CSV, PDF és TXT formátumban érhetők el. Több és hasznos mutatót mutatnak, például a válaszidőket, az állásidőt és az átlagos teljesítményt hely szerint.

A Dotcom-Monitor árazási tervei havi 1,99 USD-tól kezdődnek, és webszolgáltatás-megfigyelést kínálnak a HTTP / S, a Web API SOAP / REST, az SSL tanúsítási ellenőrzés, a válaszok érvényesítése, az azonnali riasztások és a 30 megfigyelési hely támogatásával, többek között.

Checkly

Checkly azt állítja, hogy egy korszerű megfigyelési és tesztelési megoldás, amelyre nagy figyelmet fordítottak, különösen a JavaScript közösségben olyan ügyfelekkel, mint a Vercel és a Humio. Ellenőrizheti a webes API-kat, valamint a webhely tranzakcióit egy igazi böngészőben. Az egyetlen műszerfal mindent megmutat, amit bármikor tudnia kell az alkalmazás helyességéről és teljesítményéről.

Nagyon szeretem, hogy a Checkly egyesíti a könnyű beállítást és a könnyű használatot az erőteljes eszközökkel a csekkek testreszabásához. Egy egyszerű ping helyett teljes értékű, konfigurálható HTTP ellenőrzéseket használ az API-k figyelésére. Ez magában foglalja a telepítési / lebontási szkripteket is, amelyek nagyon hasznosak, ha például kéréseket aláírni vagy a teszt adatait tisztítani szeretné.

Kiemelkedik még egy nagyteljesítményű REST API, amely lehetővé teszi az ellenőrzések összehangolását és automatizálását, például a Terraform segítségével. Ezenkívül lehetővé teszi a felhasználók számára a finomfigyelésű riasztás beállítását az Opsgenie, Pagerduty vagy Slack funkcióval kombinálva. Mindent egybevetve nagyszerű megoldás, amelyet a legfontosabbnak látok a modern DevOps csapatok számára.

Az árak havonta 7 USD-tól kezdődnek, és tartalmaznak egy perces ellenőrzési intervallumot és a globális adatközpontok helyét.

Amazon CloudWatch (AWS-hez)

Ha az AWS-en van infrastruktúra, a CloudWatch nem javasolható eléggé. Az alkalmazásfigyelés mellett a CloudWatch infrastruktúra-megfigyeléssel is rendelkezik, amely segíti a DevOps-csapatot békésen aludni éjjel.

Képforrás: aws.amazon.com

A hivatalos leírás szerint a CloudWatch a következőket kínálja:

  • Alkalmazásfigyelés
  • A rendszer egészének láthatósága
  • Erőforrás-optimalizálás
  • Egységes működési állapot

Tehát mindaddig, amíg csak AWS-telepítésre van szüksége, a CloudWatch képes lesz figyelemmel kísérni az alkalmazás üzemidejét, teljesítményét, erőforrás-felhasználását, hálózati sávszélességet, lemez / CPU-felhasználást és így tovább, robusztus megoldást nyújtva mindenféle megfigyeléshez.

A CloudWatch talán a legjelentősebb előnye, hogy gyakorlatilag nem kell beállítania semmit. Az AWS-szolgáltatások releváns naplókat generálnak, és közvetlenül megosztják azokat a CloudWatch-szel, amely egy ügyes és egyszerűen érthető irányítópultra vezet.

Képforrás: aws.amazon.com

Az irányítópulton keresztül nem csak a mutatókat olvashatja (míg az ingyenes tervek akár egyperces pontosságot nyújtanak, a fizetett tervek akár egy másodperces pontossággal is elérhetik, hatékonyan lehetővé téve a valós időben történő figyelést), de létrehozhat egyedi szabályokat, beállíthat riasztásokat, és mikor indulnak el, szkennelje be a rendszer naplóba annyi részletet, amennyit csak akar, és így tovább.

Persze, hogy nem mindenki működik az AWS-en, de a legkritikusabb és leghíresebb digitális vállalkozások vannak, ezért gondoltam, hogy a CloudWatch-et be kellene vezetni ebbe a listába. Lehet, hogy ezen a ponton egy törött kürt hangzik, de őszintén szólva, ha AWS-en van, akkor egyszerűen nincs egyszerűbb módja a megfigyelés beállításának, mint a CloudWatch-nek..

Szeretne többet megtudni az AWS CloudWatchről, tanuljon az szakértő itt.

Ami az árakat illeti, az Amazon ott is egyszerűnek tartotta. Nincs havi vagy éves bejelentkezés. Ön dönti el, hogy mekkora a szükséglete, és csak az alapján fizet, amit használ.

De mindenekelőtt nézzen meg a szabad szintű ajánlatot, és mondja el, hogy nem lehet ezt a szolgáltatást igénybe venni. ��

Képforrás: aws.amazon.com

Szigor

Ha a teljesítménymutatók alapján él, és az ügyfelek élményét minden más fölé helyezi, Szigor érdemes megnézni. A név jól megválasztott, mivel a szerszámmal annyira szigorúak lehetnek, amennyit csak akar. ��

A Rigor egyik leghasznosabb tulajdonsága a funkcionális tesztelés. Ha nem vesz részt a tesztelési lingóban, ne aggódjon; A funkcionális tesztelés a tranzakció teljes folyamatának tesztelésére utal, és nem csupán egy végpontra összpontosít.

Bizonyos értelemben a funkcionális tesztelés sokkal fontosabb, mint az egység tesztelése, mivel implicit módon lefedi az egység tesztelését, és közvetlenül biztosítja az ügyfelek tapasztalatainak előrejelzését.

Amint a fenti képen látható, ez a funkcionális teszt hét szabálysorozattal rendelkezik, amelyek tranzakciót képeznek.

Az 1. szabály egy adott előadónak az API-n való keresésére irányuló kérés. akkor a 2. szabály egy állítás, vagyis azt akarjuk érvényesíteni, hogy a keresett művész elérhető legyen; ha ezt a két tesztet sikeresen elvégzik, a rendszer tovább lép a 3. szabályra és így tovább.

A fenti példában a funkcionális teszt megszakad a 7. szabálynál, és az érdekelteket azonnal értesítik, hogy nincs elég másolat a „Funky Kingston” albumról. Beszéljen arról, hogy az üzletre összpontosít, mint a technológiai darabokat!

A Rigor egy komoly szolgáltatás egy komoly vállalkozás számára, amely nem bánja a díj fizetését valami csodálatosért, tehát ha ön ilyen, akkor feltétlenül nézd meg.

Assertible

Assertible maga a legegyszerűbb API-figyelő eszköz, és elsősorban a Testing és a QA csapatokra irányul. Tehát ha úgy gondolja, hogy nincs házon belüli műszaki kompetenciája a JSON, XML és a kódírás birkózásához, akkor az Assertible érdemes megnézni.

Az Assertible USP vonzó és egyértelmű: A minőségbiztosítási és tesztelési csapatok teszteket hozhatnak létre, és ellenőrizhetik / ellenőrizhetik azokat az Assertible felületen. Tökéletesen integrálódik a GitHub-hoz, így a tudásbázis veled is marad, a Slackkal való tökéletes munka mellett.

A teljes körű integráció és áttekintési funkció lehetővé teszi, hogy gyakorlatilag bárki a csapatban (akár projektmenedzser) tesztkészítést készítsen és felülvizsgálja a teljesítménymutatót.

Oké, a fenti képernyőképen megjelenő helyzet kissé irreálisnak tűnik (egyperces problémamegoldás), de ez lehetséges, ha a visszajelzés világos és azonnali. A szükséges kódolás hiánya azt jelenti, hogy a tesztek olyan gyorsan elkészíthetők, ahogy a minőségbiztosítási csapatok beírhatják, és ha egyszer megtették, újra és újra alkalmazhatók. Ez éles ellentétben áll a legtöbb társaságnál alkalmazott „kézi tesztelés” gyakorlattal, ahol egyetlen tesztelőnek több napot is igénybe vehet az alkalmazás lefedése, és mégis hiányozni kell a kiváló részletekről egyszerűen felügyelet vagy erőfeszítés miatt..

Havonta 100 dollárért (ami a tetejük terv, egyébként), az Assertible lehetővé teszi akár 50 webszolgáltatás, összesen 50 000 teszt és 20 csapattag figyelését. Fontolja meg, hogy a minőségbiztosítás teljes munkaidőben dolgozzon-e a tesztek létrehozása és kézi futtatása során, és nyilvánvaló, hogy az Assertible exponenciális hatékonyságot kínál.

BlazeMeter

Amikor az alkalmazások teljes körű tesztelésére és felügyeletére kerül sor, BlazeMeter a behemoth, ami minden másat eszik ebédre. Ugyanakkor nem a gyenge szívből vagy azok számára, akik egyszerű API-figyelő megoldást keresnek, amely nem igényel sok.

A BlazeMeter valami olyan, amivel feleségül vesszük, és ez az alkalmazás teljes élettartama alatt kifizetődik.

A BlazeMeter legnagyobb pluszpontja az integráció a Apache JMeter, vitathatatlanul az alapértelmezett teljesítménymérő eszköz nagy webes alkalmazásokhoz. Igen, a BlazeMeter használatával szabadon választhat nyílt forrású tesztelési kereteket, és egyszerűen elemezheti azokat egyszerű műszerfalak segítségével.

A tervek költségesek, és ha az alkalmazás akár 5000 egyidejű felhasználót is képes megnézni, akkor a BlazeMeter használata havi 649 dollárba kerül. A rögzített költségekkel kapcsolatos tervek még nagyobb munkaterhelés esetén is elérhetők, amely normát figyelembe véve a BlazeMeter ügyfelek fajtája: Pfizer, Adobe, GAP, NFL, Atlassian, hogy csak néhányat említsünk.

Nem úgy, mintha a BlazeMeter nem lenne egyszerűbb módon használható. A legtöbb más API-figyelő eszközhöz hasonlóan, funkcionális tesztelést is nyújt („forgatókönyveknek” hívják őket), amelyet intuitív grafikus felhasználói felület felhasználásával lehet elvégezni..

A BlazeMeter a fejlesztők számára készült. A dedikált tesztelő eszközön keresztül Bika, A BlazeMeter DSL-t (tartomány-specifikus nyelvet) tesz közzé, amely felhasználható általános tesztek írására, amelyeket a JMeter, a Selén és más népszerű nyílt forráskódú eszközök ellen lehet futtatni. És ne hagyja, hogy a DSL említése aggasztja Önt; ez nem más, mint egy dicsőített YAML (.yml kiterjesztés) fájl:

végrehajtás:
– párhuzamosság: 100
felhajtás: 1m
tartás: 1m30s
forgatókönyv: egyszerű

forgatókönyv:
egyszerű:
gondolkodási idő: 0,75
kérések:
– http://blazedemo.com/

Töltsön el egy kis időt a Taurus-szal, és a fejlesztők hálásak lesznek azért, hogy bonyolult, újrafelhasználható teszteket tudnak írni!

Összességében a BlazeMeter nehézsúlyú.

AppDynamics

Az AppDynamics, amely a Cisco része, már régóta a webes alkalmazások figyelő játékában van, és nagyon jól ismert. Jelenleg az AppDynamics egy eszközkészlet, amely megoldja a modern SaaS-csoport teljesítmény- és figyelési követelményeinek széles skáláját.

Ami a tiszta API / mikroszolgáltatás-megfigyelést illeti, a csomag kínál Microservice IQ. Ezzel a szolgáltatással figyelemmel kísérheti és elemezheti egy gyakorlatilag bármilyen méretű mikroszolgáltatási fürtöt, megőrizve az előzményeket, és lehetővé téve annak összekapcsolását a fürtben bekövetkező változásokkal. Mindenesetre ez legalább lehetővé teszi a csomópontok fürtből történő hozzáadásának / eltávolításának a szimulációját.

Ugyanez vonatkozik a valós idejű mutatók figyelésére, amelyeket meg lehet tenni fürtszintű vagy csomópont szintű szinten is, szükség szerint bemutatva mind a nagy kép nézetet, mind a szélsőséges részleteket..

Amint az a képernyőképen látható, a Docker megfigyelés közvetlenül be van építve, amelyet azok a csapatok értékelnek, akiknek infrastruktúrája fut a Docker-en (szinte mindenki, azaz ��).

Ezen felül felhőmegfigyelés és DevOps megfigyelés is rendelkezésre áll, amelyek számos IaaS szolgáltatónál működnek, mint például az Amazon AWS, Azure, Pivotal stb. csapat.

A torta jegesedése a Machine Learning integrálása a rendszer szívébe. Például, néha nem ismeri az alkalmazásának ideális alapvonalait, de mivel a vállalkozás zökkenőmentesen működik, akkor elfogadhatja a jelenlegi mutatókat alapvonalakként.

Szóval, hogyan fogja kiszámítani az alapvonalat? Nehéz, ha óránként több ezer adatpont adatfolyamot közvetít, de nem, ha van egy képes gépi tanulási rendszer, amely fut.

Hogyan segít ez a vállalkozásoknak? Íme egy példa. Ha tudja, hogy az üzemidő kiindulási pontja 98,5%, és jelenleg 98,6% -ot fut, akkor valódi nyugalma van. Ezenkívül a valódi, kemény alapvonalakhoz való hozzáférés megtakarít a túlságosan nagy technikai igénybevételektől és a drága migrációktól, amelyeket egyes tanácsadók javasolhatnak a „hat kilenc” elérésére (üzemidő 99,9999%)..

Az ML rendszer szintén elég intelligens ahhoz, hogy a kódon belül (ez a leglátványosabb rész!) Kiszámítsa és jelentse a hibát okozó mikroszolgáltatások csoportjában az egyetlen hiba okot, így a csapatok pontosan tudják, mit kell kijavítani. Az alábbi képernyőkép bemutatja, hogyan lehet a rendszert beépíteni egy Java Spring alapú REST szolgáltatásba, és rámutatni a meghibásodott babra.

Itt nem lehet lefedni az összes állkapocs-ejtő funkciót, ezért nyugodtan nézze meg a hivatalos dokumentumok.

Új műemlék

Sokan szerint, Új műemlék a piacvezető az alkalmazások teljesítményének figyelésére szolgáló eszközökben, és jó okból. A nagy és a kis társaságok egyaránt használják – a Fortune 500 behemoth-októl kezdve a kicsi, fürge indulásokig -, és nagyszerű kombinációt kínál a pontosság és a részletek között.

Az Új Relic csapat büszke arra, hogy mélyen megérti a DevOps-ot, és ennek megfelelően ennek az ajánlatnak az a célja, hogy teljes, valós idejű képet biztosítson az Ön infrastruktúrájáról..

A New Relic legnagyobb USP-je a teljes rendszer intuitív elrendezése, amely lehetővé teszi, hogy azonnal megnézze, hogyan folyik minden, és pontosan hol található a szűk keresztmetszet, ha van ilyen. Nehéz szavakkal leírni az UI-t, tehát itt van egy képernyőkép:

Mint láthatja, nagyon könnyű vizuálisan követni, hogy az adatok hogyan áramlanak a rendszerből a rendszerbe, és az ott kapott teljesítménymutatókra. A lassúság és a leállások azonnali riasztásokat váltanak ki, lehetővé téve a problémák megoldását, még mielőtt az üzleti vállalkozás szenvedne.

Nem csak a DevOps oldala felel meg az Új emlékműben. Lehetőség van arra is, hogy célokat és szabályokat állítson fel az ügyfelek tapasztalataira, és részletes jelentéseket kapjon annak eldöntésére, hogy hol kell további munkát végezni. Mint minden, a sót érdemelő digitális marketingszakember tudja, ez az információ szilárd arany.

Nincs vége a New Relic zseniális műszerfalának. Vessen egy pillantást erre, például, amely csomópontok szerint ábrázolja a teljes alkalmazás-fürtöt, és élő visszajelzést nyújt az egyes csomópontokban zajló eseményekről.

Tehát függetlenül attól, hogy az alkalmazás egyszerű vagy összetett – az Új Relic sok érdekes betekintést kínál.

API erőd

A következő sorban van API erőd, amelynek célja svájci hadsereg kést adni az API-figyelésnek a szervezet különböző csapata számára, és ezt nagyon jól csinálja.

A tesztelők és a fejlesztők egyaránt célja, hogy az API Fortress vizuális, együttműködési teszteket készítsen, mint bármely más modern API-figyelő eszköz, odakinn, majd kissé távolabb a sétára a kényelem és a szolgáltatások szempontjából. A kettő, amit legjobban szeretek, a terhelés tesztelése és a gúnyolódás.

A fejlesztők számára az API Fortress létrehozhat egy tesztkészletet egy adott API-specifikációból. Tehát, ha a Swaggert, az OpenAPI-t vagy a RAML-t követi, a munka fele már elkészült. Az API-megfigyelés lehetővé teszi a fejlesztői csapatoknak, hogy az új API felületét mint állati szolgáltatást határozzák meg, amelyen a minőségbiztosítási csapatok azonnal elkezdhetik a tesztkészletek felépítését. Nincs több fárasztó, hosszú várakozás az aktuális API befejezéséhez, mielőtt a minőségbiztosítás megkezdődhet!

Az API Fortress az összes fő CI / CD rendszerrel is működik, enyhítve az integráció további fájdalompontját. Végül a sziklaszilárd terhelés tesztelése és megfigyelése szintén beépítve van, így az API Fortress komplett csomag a fejlesztési és tesztelési csapatok számára az API gyors tesztelésére és megfigyelésére..

Traceview

Ha az interfész szintű megfigyelés a csapat számára nem eredményes, és ha egy erős, kódszintű megfigyelő eszközt keresel, akkor Traceview. Az írástól kezdve az összes fő programozási nyelv és környezet támogatott: Java, Scala, Net, Node, PHP, Python, Ruby és Go.

Amint az a fenti képernyőképekből látható, rendelkezésre állnak komponens- és funkciószintű mutatók, amelyek lézer-éles, azonnali betekintést nyújtanak az alkalmazás miért viselkedik úgy, ahogy van.

Hogyan állítsuk be? Nem lehetett egyszerűbb! A Traceview a korábban felsorolt ​​nyelvek többségén olyan szoftveres ügynököket tartalmaz, amelyeket egyszerűen be lehet vonni a projektbe anélkül, hogy bármi zavarná őket. Kezdje el a valós idejű betekintés gyors összegyűjtését. ��

RapidSpike

RapidSpike egy karcsú megoldás, amely az üzemidő és a felügyelet alapvető elemeire összpontosít, anélkül, hogy sok extra csengő és sípszó lenne, amelyek egyesek szerint a legtöbb API-figyelő eszközhöz tartoznak. Az előre definiált útvonalak (felhasználói utazások) nyomon követése támogatott, mint az API-val több lépésben történő beszélgetés esetén.

Mindez szabványok, és nagyjából az, amit elvárhat bármilyen modern API-figyelő rendszertől, de véleményem szerint a RapidSpike különbözteti meg a riasztási rendszereket.

A rendszerben beépített eszkaláció van, tehát ha az első kapcsolatfelvételi szint nem oldja meg a „válságot” vagy nem reagál rá, az értesítés a láncot feljavítja. Jaj! �� Nos, talán jobb, ha nincs szükségünk tényleges főnökre, aki állandóan lábujjjal tart minket.

API Science

Val vel API Science, tesztelni kell az API-kat egy API-val. Noha ez úgy tűnik, mint egy divatos módszer ugyanaznak a mondatra, az API Science néhány új funkcióval rendelkezik, amelyek valószínűleg sokk számára vonzódnak. Az első az API-verem teljes kötegének figyelése, ami azt jelenti, hogy lefedjük a külső API-kat is.

Sokszor előfordul, hogy az API-k teljesítőképesek és érzékenyek, de az Ön vállalkozásától függőek nem működnek. Ezenkívül bizonyos esetekben nincs objektív állítás, melyik API volt akkoriban lezárva. Ez a küzdelem egyfajta hidegháborúvá válhat két API-szolgáltató között.

Ilyen esetekben az API Science vitathatatlan középútként működik, amely megmutathatja az API-k korábbi rendelkezésre állását.

A második kiváló szolgáltatás az API-k elosztott tesztelése. Az API Science figyeli az API-kat a világ minden tájáról, és megtudja, hogyan viselkedik az API a különböző helyszíneken. Kombinálja az összes egyéni JavaScriptet a megfigyelő rendszerben, és rendelkezik egy ideális API-figyelő eszközzel. ��

Ezzel véget ér az API-figyelésre vonatkozó legfontosabb ajánlásaim. Minden tőlem telhetőt megtették, hogy az API-kat nem azokra a szűk meghatározásokra korlátozzam, amelyek legtöbbször meg vannak jelölve. Az üzleti tulajdonosoktól kezdve a fejlesztőkig, a tesztelőkig, a minőségbiztosítási és a projektmenedzserekig minden olyan eszköz megtalálható ebben a listában.

CÍMKÉK:

  • API

  • Monitoring

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me