Begin nu met monitoren en ontvang 20% korting op uw eerste factuur. Beschikbaar voor alle Uptrends-abonnementen.

Stel dat u uw Uptrends-account koppelt aan het operationsmanagementsysteem dat uw organisatie gebruikt. Door alertdata van Uptrends in te voeren in uw bestaande incidentmanagementprocessen, creëert u een naadloze integratie van Uptrends' externe monitoring in de dagelijkse procedures die uw teams al gebruiken.

Als onze voorgedefinieerde integratietypen uw DevOps-software niet bevatten, kunt u de aangepaste-integratieoptie gebruiken om de integratie zelf te bouwen. Het belangrijkste bij het bouwen van een succesvolle integratie is, dat u weet wat voor soort bericht het andere systeem verwacht. In de API-documentatie van de third party vindt u welke URL u moet gebruiken en welke inhoud u op die URL moet posten. Deze zogenoemde webhook-gebaseerde integraties laten Uptrends "hook" (koppelen) met het andere systeem door directe calls toe te staan. Uptrends kan een call naar de integratie initiëren zodra er een relevante alert verschijnt.

De inhoud is doorgaans JSON-geformatteerd (maar XML en andere formaten zijn ook prima) en bevat de verschillende velden die een specifieke betekenis en belangrijkheid hebben in dat systeem.

De juiste berichtinhoud bouwen

Om relevante inhoud voor die velden in elk uitgaand alertbericht in te vullen, moet de berichtinhoud die u definieert zogenaamde systeemvariabelen bevatten. Wanneer u in uw berichtinhoud naar een systeemvariabele verwijst, wordt deze vervangen door de juiste inhoud wanneer Uptrends een alert genereert. Met systeemvariabelen kunt u berichtdefinities schrijven die voldoen aan de verwachtingen van het andere systeem.

Laten we een voorbeeld bekijken. Een voor de hand liggend stuk informatie dat waarschijnlijk deel moet uitmaken van elk alertbericht, is een eenvoudige beschrijving van de error die door Uptrends is gedetecteerd. Stel dat het systeem waarmee u wilt koppelen een veld genaamd "errordescription " heeft. U zou Uptrends' foutbeschrijving in dat veld kunnen invoeren door deze definitie op te nemen in uw JSON-geformatteerde bericht:

{ "errordescription": "{{@alert.description}}" }

In de systeemvariabelen van Uptrends is de tekstuele beschrijving van de error die een waarschuwing triggert beschikbaar in de variabele {{@alert.description}}, dus u plaatst die variabele gewoon waar u hem nodig hebt in uw bericht. Op dezelfde manier kunt u {{@ alert.timestamp}} gebruiken om naar het tijdstip van de alert te verwijzen, {{@ monitor.name}} om de naam van de controleregel op te nemen enzovoort. Alle beschikbare systeemvariabelen worden hieronder vermeld. Merk op dat alle systeemvariabelen het formaat {{@ ...}} hebben:

Variabele Beschrijving Voorbeeldwaarde
@alert.alertGuid Unieke ID van deze alert cbfc7769-edb2-46a7-89d0-1e1b1fb0815b
@alert.type

Het type van dit alertbericht:

Alert: er is een nieuwe fout gedetecteerd.

Ok: de oorspronkelijke fout is opgelost.

Herinnering: de oorspronkelijke fout duurt nog steeds voort.

Alert | Ok | Herinnering
@alert.timestampUtc De datum en tijd van de alert, uitgedrukt in UTC-tijd en geformatteerd als ISO 8601. 2018-11-08T16:26:58
@alert.timestamp Dezelfde datum en tijd als @alert.timestampUtc, maar in de tijdzone van uw account. Ook geformatteerd als ISO 8601. 2018-11-08T10:26:58
@alert.firstErrorUtc De datum en tijd van de oorspronkelijke fout die deze waarschuwing heeft getriggerd, uitgedrukt in UTC-tijd en geformatteerd als ISO 8601. 2018-11-08T16:21:58
@alert.firstError Dezelfde datum en tijd als @alert.firstErrorUtc, maar in de tijdzone van uw account. Ook geformatteerd als ISO 8601. 2018-11-08T10:21:58
@alert.errorTypeId De fouttype-ID van de fout die deze alert heeft getriggerd 5407
@alert.description Tekstbeschrijving van de fout die deze alert heeft getriggerd. Verwacht DNS-resultaat niet gevonden
@alert.firstErrorCheckUrl De URL van een deep link die u naar de details van de error leidt die deze alert heeft getriggerd.

https://app.uptrends.com/Report/ProbeLog/Check/30833627687

@alert.firstErrorCheckId De ID van de error die deze alert heeft getriggerd. 30833627687
@alertDefinition.guid De unieke ID van de alertdefinitie die is gebruikt om deze alert te genereren. 2C97E464-6112-435B-8C8D-6DEF1E18273A
@alertDefinition.name De naam van de alertdefinitie die is gebruikt om deze alert te genereren. Standaardalert
@escalationLevel.id De ID van het escalatieniveau dat is gebruikt om deze alert te genereren. 1
@escalationLevel.message Het aangepaste bericht dat is opgegeven in het escalatieniveau. Gebruik checklist THX-1138 om dit probleem te onderzoeken.
@incident.key Unieke ID van het incident waartoe deze alert behoort. Een foutalert en een OK-alert delen dezelfde incident-key. ba8ffcb7-5de0-489e-b649-f00f0b447e80-0-30099055746
@monitor.monitorGuid De unieke ID van de controleregel in uw account die deze alert heeft getriggerd. 849b2046-213d-43ad-9efc-5af1faaeb222
@monitor.name De naam van de controleregel in uw account die deze alert heeft getriggerd. GalacticResorts.com - DNS
@monitor.notes Alle aangepaste opmerkingen die in de controleregelinstellingen zijn ingevuld. Controleer Amazon Route53 DNS entries
@monitor.url De URL of het netwerkadres dat deze controleregel aan het controleren is. https://galacticresorts.com
@monitor.dashboardUrl De URL van een deep link die u naar het dashboard van deze controleregel brengt. https://app.uptrends.com/Probe/Dashboard?probeGuids=fe1ad4a2-57c1-49db-af16-ff3a6beaa8d4
@monitor.editUrl De URL van een deep link die u naar de instellingen van deze controleregel brengt. https://app.uptrends.com/Report/Probe?probeGuid=fe1ad4a2-57c1-49db-af16-ff3a6beaa8d4
@account.accountId Uw Uptrends-account-ID 299840

Foutberichten, OK-berichten en Herinneringen

Wanneer u op de tab Aanpassingen een berichtdefinitie maakt, gebruikt Uptrends die berichtdefinitie voor alle fouttypen: een Foutalert wanneer de controle de waarschuwing voor het eerst genereerde, een OK-alert wanneer de controle de waarschuwing oplost en Herinneringalerts (afhankelijk van uw escalatieniveau-instellingen) daartussen.

De berichtinhoud is vrijwel hetzelfde voor alle alerttypen, behalve voor timestamp-waarden en de variabele {{@ alert.type}}, die het alerttype zelf uitvoert.

Hoewel prima voor veel situaties, is het gebruik van dezelfde berichtinhoud niet voldoende als u verschillende inhoud nodig hebt voor verschillende alerttypen, of als u een nieuw incident in uw systeem moet maken (op basis van een Foutalert) waarvoor een andere URL nodig is om datzelfde incident op te lossen (op basis van een OK-alert).

Afzonderlijke berichten voor verschillende alerttypen

Om afzonderlijke berichtdefinities voor alerttypen te maken klikt u op de knop "Stappen toevoegen" onder aan de tab Aanpassingen. De knop "Stappen toevoegen" creëert een extra berichtdefinitie die u bijvoorbeeld zo kunt configureren dat die alleen van toepassing is op OK-alerts. Voor elk alerttype kunt u nu de juiste HTTP-methode (GET/POST/PUT/PATCH/DELETE), URL, headers en request body opgeven.

Selecteer de selectievakjes Foutalert, OK-alert en Herinneringalert boven elke stapdefinitie om de gewenste instelling te maken. U kunt elk alerttype slechts één keer selecteren, maar OK-alerts en Herinneringalerts zijn optioneel. Wilt u helemaal geen OK-alerts of Herinneringalerts versturen, selecteer dan deze selectievakjes niet.

Foutalerts en OK-alerts horen bij elkaar

Of u nu afzonderlijke berichten gebruikt voor Fout- en OK-alerts of niet, het is waarschijnlijk handig voor het externe systeem om te weten welke alerts bij elkaar horen. Elk incident begint immers met een Foutalert en eindigt met een OK-alert. Om het externe systeem te helpen dit te begrijpen, kunt u de variabele {{@ incident.key}} in uw berichten gebruiken. Fout- en OK-alerts delen dezelfde incident-key, maar elk nieuw incident heeft een unieke key. In sommige systemen wordt de incident-key een deduplicatiesleutel of incident-ID genoemd.

Variabelen gebruiken

Wanneer in een integratie de optie Aanpassen actief is, kunt u een of meer variabelen voor die integratie op de tab Algemeen behouden. De standaardinstelling voor voorgedefinieerde integratievariabelen (zoals aangegeven door Waarde hier opgeven) is dat de waarde voor die variabelen wordt gedefinieerd als een vaste waarde in de integratie. U kunt vervolgens naar die variabelen verwijzen in de berichtdefinitie op de tab Aanpassingen. Meer informatie over het definiëren en gebruiken van variabelen vindt u in dit Knowledge Base-artikel over het gebruik van variabelen in een multi-step API-configuratie. Voor integraties geldt precies dezelfde aanpak.

Voor integraties hebt u echter een extra optie die nog meer kracht toevoegt. Stel dat u een integratie hebt gecreëerd die verbinding maakt met uw IT-managementsysteem. De integratie stuurt informatie op basis van de controleregel en alert die de alert heeft getriggerd. Maar is dat voldoende informatie voor het IT-managementsysteem om passende maatregelen te nemen? U kunt wat aanvullende informatie sturen over hoe met het nieuwe incident moet worden omgegaan. U kunt deze informatie meestal uitdrukken als: hoe moet het incident door het externe systeem worden behandeld? Verschillende alertdefinities (in feite elk escalatieniveau daarbinnen) kunnen unieke routinginformatie specificeren, die u in het uitgaande alertbericht kunt opnemen.

Om dit te doen definieert u een variabele op de tab Algemeen van de integratie en kiest u Waarde opgeven in het escalatieniveau. U ziet dat u hem geen waarde meer kunt geven in de integratie zelf. In plaats daarvan kunt u, wanneer u deze integratie in de escalatieniveaus van uw alertdefinities gebruikt, daar waarden voor deze variabele opgeven. Hierdoor hoeft u slechts één integratiedefinitie voor uw IT-managementsysteem te maken, terwijl u flexibiliteit behoudt in de manier waarop alle alerts daar worden afgehandeld.

Een integratie controleren met testberichten

Nadat u een aangepaste integratie hebt gemaakt of gewijzigd, is het handig om deze eerst te testen voordat u deze in production gebruikt. De tab Aanpassingen in de integratie-editor heeft een knop genaamd Testalert versturen waarmee u een testbericht naar het third-partysysteem kunt sturen met de HTTPS-stap(pen) die u hebt gemaakt. Wanneer u deze testfunctie gebruikt, kunt u selecteren welk alerttype (een Foutalert, een OK-alert of een Herinneringalert) Uptrends moet gebruiken voor dit specifieke testbericht. U kunt zo nodig andere geschikte waarden invullen en de resterende data (die normaal gesproken relevante controleregel- en alertdata zijn) zullen worden gevuld met fictieve waarden.

Zodra Uptrends het bericht genereert en het naar het third-partysysteem of de API verstuurt, worden de volledige berichtinhoud, de response code van de server en de inhoud weergegeven. U kunt de request headers en inhoud en de response headers en inhoud uitbreiden om het uitgaande en inkomende verkeer dat betrokken was bij het versturen van dit testbericht te inspecteren.

Een integratie controleren met live-data

Hoewel de hiervoor beschreven testfunctie nuttig is voor het statisch testen van uw bericht en variabelen, en om vast te stellen dat het communicatiekanaal naar het externe systeem correct werkt, is het goed om de mogelijkheid te hebben om te verifiëren dat de integratie ook in een live-situatie correct werkt.

Zorg er eerst voor dat één van uw alertdefinities daadwerkelijk uw integratie gebruikt. Anders triggert Uptrends de integratie nooit om berichten te versturen. Meer informatie over het activeren van integraties in uw alertinstellingen kunt u lezen in deze Academy-les over escalatieniveaus.

Vervolgens moet er een errorsituatie optreden, zodat uw monitoring een echte alert genereert. Zodra u een alert in uw Alertstatus of Alertlog-dashboard ziet, klikt u erop om de details van die alert weer te geven. De tab Details toont alle belangrijkste eigenschappen van de alert; de tab Berichten bevat de informatie die u nodig hebt om het berichtverkeer tussen Uptrends en het externe systeem te inspecteren.

Zoek op de tab Berichten de integratie die u wilt inspecteren; mogelijk worden er andere integraties weergegeven die ook door deze alert zijn getriggerd. Vouw het integratiepaneel en de requests en responses uit. U ziet de volledige inhoud van het uitgaande bericht(en), de responses die door het externe systeem zijn teruggestuurd en eventuele errorberichten die zijn opgetreden als er een probleem was bij het versturen van het alertbericht.

Externe ID's of aangepaste data opnemen

Wanneer u Uptrends integreert met een third-partysysteem, is het goed om na te gaan of er een verband is tussen uw Uptrends-controleregels en de bronnen (soms componenten of services genoemd) die u in het third-partysysteem hebt gedefinieerd. De controleregels in uw Uptrends-account hebben een naam en een unieke identifier (een monitorGuid), maar deze zijn meestal niet bekend in het third-partysysteem. De bronnen die in het third-partysysteem zijn gedefinieerd, hebben waarschijnlijk ook hun eigen identifier, die Uptrends ook niet kent.

Als u wilt dat een controleregel in Uptrends een incident voor een specifieke bron aan de andere kant triggert, moet u een soort relatie tussen de twee definiëren. In Uptrends kunt u die relatie definiëren door de identifier (of andere belangrijke informatie) van de externe bron/component te nemen en deze als een aangepaste waarde toe te voegen aan de instellingen van een controleregel.

Hierdoor kunnen de alertingdata die door Uptrends naar het externe systeem zijn verstuurd die identifier bevatten, zodat het ontvangende systeem weet welke bron of component door de binnenkomende alert is beïnvloed.

U kunt aangepaste velden toevoegen in het gedeelte Metadata op de tab Algemeen van een controleregel. Naast de externe waarde die u wilt opslaan, moet elk aangepast veld ook een unieke naam hebben, zodat we ernaar kunnen verwijzen in een alertbericht. Stel bijvoorbeeld dat uw third-partysysteem het concept van Components heeft en dat elke component een ComponentId als unieke identifier heeft. U wilt dan dat ComponentId specificeren in de controleregelinstellingen in Uptrends, zodat de twee aan elkaar kunnen worden gekoppeld.

Om dit te doen gaat u naar het gedeelte Vrije velden in de instellingen van uw controleregel. Voeg een vrij veld toe door "ComponentId" als de veldnaam in te vullen en de juiste externe ID-waarde (bijvoorbeeld 7149488f-0b33-460d-85eb-210c0e80d7ba) als de veldwaarde. Klik op Opslaan om de nieuwe instellingen op te slaan.

We kunnen er nu voor zorgen dat de externe waarde als onderdeel van het alertbericht wordt verstuurd door deze op te nemen in de Request body van het uitgaande bericht. U kunt de functie {{@CustomField ()}} gebruiken om te verwijzen naar het vrije veld dat u zojuist hebt toegevoegd. Als voorbeeld kunt u dit fragment toevoegen aan de request body:

{ "Component": "{{@CustomField(ComponentId)}}" }

U ziet dat de veldnaam "ComponentId" die we in de controleregelinstellingen hebben gebruikt, letterlijk is opgenomen in de function call @CustomField (). Wanneer een echte alert wordt getriggerd, genereert dit de volgende inhoud:

{ "Component": "7149488f-0b33-460d-85eb-210c0e80d7ba" }

Het externe systeem kan deze waarde gebruiken om een incident voor de juiste component te maken. In dit voorbeeld wordt slechts één vrij veld gebruikt, maar u kunt ervoor kiezen meerdere aangepaste waarden te gebruiken.