Övervakning av extern statussida

En monitor för externa statussidor håller koll på den offentliga statussidan för en tjänst som du är beroende av — AWS, GCP, Azure, GitHub, OpenAI, Anthropic och många fler — och larmar dig när leverantören rapporterar ett avbrott eller försämrad prestanda. Använd den för att få veta om problem hos dina leverantörer så snart de rapporterar dem, och för att skilja dem från dina egna.

Den läser också statussidor som är gjorda med Status200, resurs för resurs, och skiljer planerat underhåll från ett avbrott: håll koll på ett annat teams projekt, eller en leverantör vars statussida körs på Status200.

Så fungerar det#

Vid varje kontroll hämtar en sond statussidan, tar reda på vilket format den använder och läser den övergripande statusen, komponenterna och de aktiva incidenterna. Om du har avgränsat monitorn till en komponentgrupp eller en komponent räknas bara de. Sedan avgör kriterierna om monitorn är online eller offline.

Du kan använda den för att:

• Övervaka tillgängligheten för tjänster från tredje part som din applikation är beroende av
• Få larm när dina leverantörer har avbrott
• Följa statusen för enskilda komponenter
• Avgränsa övervakningen till en enda komponentgrupp (t.ex. bara OpenAI:s "APIs"), så att incidenter på andra ställen på sidan som inte rör dig inte utlöser din monitor
• Upptäcka försämrad prestanda innan den påverkar dina användare
• Koppla ihop dina egna incidenter med problem hos dina leverantörer

Leverantörer som stöds#

Automatisk identifiering#

När leverantören är inställd på Auto identifierar Status200 statussidans format automatiskt, i den här ordningen:

1. Först provar den statussidans API från incident.io (/proxy/<host>).
2. Sedan provar den JSON-API:et från Atlassian Statuspage (/api/v2/status.json, /api/v2/components.json och /api/v2/incidents/unresolved.json).
3. Sedan ber den om sammanfattningen för en Status200-statussida (/status-page-api/summary/<page>).
4. Om de misslyckas försöker den läsa sidan som ett RSS- eller Atom-flöde.
5. Som sista utväg gör den en enkel kontroll av om sidan kan nås över HTTP.

Kontrollen av om sidan kan nås är också utvägen när en leverantör som du uttryckligen har valt misslyckas. Den talar bara om ifall sidan svarar — online vid ett svar 2xx eller 3xx — och rapporterar inga komponenter eller incidenter.

Skapa en monitor för externa statussidor#

1. Starta en ny monitor#

   Gå till Monitorer och klicka på Skapa monitor. Under Monitortyp klickar du på Fler monitortyper och väljer External Status Page under Basic Monitoring, eller skriver statuspage i sökrutan. Ange ett Namn och klicka sedan på Nästa.

2. Ange statussidans URL#

   Ange Statussidans URL. Låt Leverantör stå kvar på Auto om du inte känner till formatet.

3. Avgränsa den, om du behöver#

   Öppna Fler fält för att ange ett Component Group Filter, som APIs, och ett Filter för komponentnamn för att bevaka en enda komponent (inom gruppen, om en grupp är angiven).

4. Testa den#

   Klicka på Testa monitor för att hämta sidan en gång, och kontrollera leverantören, komponenterna och incidenterna som den hittade.

5. Gå igenom kriterierna#

   Kriteriesteget börjar med standardkriterierna, som markerar monitorn som offline när leverantören rapporterar en aktiv incident eller ett avbrott inom avgränsningen. Ändra dem om du behöver och klicka sedan på Nästa.

6. Välj sonder och skapa#

   Välj Sonder och ett Övervakningsintervall — det börjar på Var 5:e minut — och klicka sedan på Skapa monitor.

Konfigurationsalternativ#

Component Group Filter#

Om statussidan delar in sina komponenter i grupper kan du avgränsa monitorn till en enda grupp. På https://status.openai.com avgränsar du till exempel monitorn till OpenAI:s API-tjänster genom att ange APIs.

När en komponentgrupp är angiven beräknas antalet aktiva incidenter och den övergripande statusen bara utifrån komponenterna i den gruppen — en incident som påverkar en grupp som inte rör dig (till exempel ChatGPT) utlöser inte en monitor som är avgränsad till gruppen "APIs".

Filtrering på komponentgrupp stöds för leverantörerna Atlassian Statuspage, incident.io och Status200 Status Page. RSS- och Atom-flöden har inga komponentgrupper.

Filter för komponentnamn#

Om statussidan rapporterar om flera komponenter kan du ange ett komponentnamn för att bara övervaka den komponenten. Filtret matchar varje komponent vars namn innehåller det du anger, utan hänsyn till versaler och gemener — actions matchar en komponent som heter "Actions".

När en komponentgrupp också är angiven tillämpas filtret för komponentnamn inom den gruppen, så att du kan rikta in dig på en enda komponent i en större grupp. När inget av filtren är angivet övervakas alla komponenter inom avgränsningen. I ett RSS- eller Atom-flöde jämförs namnfiltret med titlarna på flödets poster.

Övervakningskriterier#

Du kan konfigurera kriterier som avgör när den externa tjänsten anses vara online eller offline, utifrån:

Den övergripande statusen är det som sidan säger, så värdena varierar mellan leverantörer: en Atlassian Statuspage rapporterar sin egen beskrivning, som All Systems Operational; en Status200-statussida den sämsta statusen bland sina komponenter i omfånget, som under_maintenance; ett flöde rapporterar operational eller degraded_performance; kontrollen av om sidan kan nås rapporterar reachable eller unreachable. De här jämförelserna skiljer på versaler och gemener. För att larma om avbrott är External Status Page Active Incidents och External Status Page Component Status oftast mer tillförlitliga.

I ett RSS- eller Atom-flöde räknas posterna från de senaste 24 timmarna som aktiva incidenter: en RSS-post utifrån sitt publiceringsdatum, en Atom-post utifrån sitt uppdateringsdatum. En post som är daterad framåt i tiden räknas först från sitt datum.

Standardkriterier#

Som standard skapar Status200 kriterier utifrån det som verkligen spelar roll för en statussida — dess aktiva incidenter och komponenternas hälsa, snarare än bara om den kan nås:

Eftersom antalet aktiva incidenter och komponenternas status tar hänsyn till filtren för komponentgrupp / komponentnamn riktar sig de här standardkriterierna automatiskt bara mot de komponenter du bryr dig om.

Status200-statussidor#

Välj Status200 Status Page som leverantör, eller låt Auto stå kvar, för att hålla koll på en statussida som är gjord med Status200: ett annat teams projekt, eller en leverantörs sida på Status200 Cloud eller på en egen driftad Status200. Ange sidans egen adress i Statussidans URL: dess domän, som https://status.example.com, eller https://status200.ru/status-page/<status-page-id> för en sida utan egen domän.

Monitorn läser sidans sammanfattning, /status-page-api/summary/<page> (se Läs sammanfattningen): bara det som sidan visar sina besökare, och inget annat från det andra projektet. Varje resurs på sidan, en monitor eller en monitorgrupp, är en komponent, med det namn som sidan ger den, i sidans grupp; en grupp inuti en annan heter Core / Databases. Håll koll på en resurs med Filter för komponentnamn, eller en grupp med Component Group Filter.

En komponents status är det värde som dess status på sidan står för, så kriterierna för komponentstatus fungerar som på vilken statussida som helst:

Medan en pågående planerad underhållshändelse berör en resurs, eftersom den nämner en av resursens monitorer eller en monitor i dess monitorgrupp, är komponenten under_maintenance, oavsett vilken status dess monitorer har: en monitor kontrolleras inte medan en händelse håller den. En händelse som ännu inte har börjat, eller som är över, ändrar ingenting. Sidans aktiva incidenter räknas för de resurser de berör.

Standardkriterierna tar aldrig underhåll för ett avbrott: monitorn förblir online under det andra projektets planerade arbete.

Visa det andra projektets underhåll på din monitor#

1. Lägg till kriteriet#

   Klicka på Lägg till kriterier i monitorns kriterier. Ge det filtret External Status Page Component Status, Lika med, Under Maintenance, och välj din underhållsstatus i Ändra övervakningsstatus till.

2. Flytta det högst upp#

   Dra det nya kriteriet ovanför de andra: det första kriteriet som matchar vinner.

3. Kontrollera det med Testa monitor#

   Klicka på Testa monitor medan det andra projektet har underhåll på gång: komponenten som berörs visar Under Maintenance.

Vad en Status200-statussida låter monitorn läsa#

En sida som alla kan öppna läses som dess besökare ser den. En privat sida, som kräver inloggning, SSO eller ett lösenord, kan inte läsas: med Status200 Status Page vald misslyckas kontrollen och säger varför. En sida med en lista över tillåtna IP-adresser måste släppa in sondens adress: håll koll på den från en sond inne i det nätverket.

Mallvariabler#

När du skapar incidenter eller larm från monitorer för externa statussidor kan du använda de här variablerna i titlar, beskrivningar och åtgärdsanteckningar (se Incident- och varningsmallar):

Populära statussidors URL:er#

Här är en lista över statussidor för populära tjänster. Många av dem använder Atlassian Statuspage eller incident.io, så leverantören Auto identifierar dem automatiskt. En sida som inte bygger på någon av dem, och som inte är ett flöde, får bara kontrollen av om den kan nås — för sådana övervakar du i stället leverantörens RSS- eller Atom-flöde, om den publicerar ett.

Bästa praxis#

• Använd leverantören Auto om du inte känner till det exakta formatet — automatisk identifiering fungerar bra för de flesta statussidor.
• Avgränsa till en komponentgrupp om du bara är beroende av en del av en leverantör (t.ex. bara OpenAI:s "APIs"), så att incidenter som inte rör dig inte skapar brus.
• Övervaka specifika komponenter om du bara är beroende av vissa tjänster.
• Kombinera med dina egna monitorer — para ihop monitorer för externa statussidor med dina egna API- och webbplatsmonitorer. När båda går ned samtidigt pekar leverantörens statussida snabbare ut grundorsaken.

Felsökning#

Nästa steg#