FAQ

Öffnen Sie das Zielgerät in der Liste zu bearbeiten. In der Adressleiste des Browsers sehen Sie so etwas wie:

https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834 

Die deviceId=63698 ist die Geräte-ID.
Die taskId=132834 ist die Aufgaben-ID.

Der Überwachungsagent "Shanghai" (China) befindet sich hinter der Großen Firewall Chinas, die direkt von der chinesischen Regierung verwaltet wird. Die chinesische Regierung verfügt über eine Filterregel für den gesamten Internetverkehr, und sie ist nicht öffentlich. Diese Filterregeln werden häufig geändert, was wiederum die Überwachungsergebnisse des Shanghai, China-Agenten beeinflusst.

Standardmäßig erkennen Exchange-Server, ob eine E-Mail-Adresse lokal ist. Wenn dies der Fall ist, sendet der Server die E-Mail nicht über das öffentliche Internet. Dies ist eine Standardeinstellung der meisten E-Mail-Server.

Wenn Sie das Senden und Empfangen über das öffentliche Internet testen möchten, empfehlen wir Ihnen, unseren Roundtrip-E-Mail-Monitor + ein E-Mail-Konto von^{Drittanbietern} wie Gmail zu verwenden.

Unsere Roundtrip-E-Mail-Überwachung erfordert die Verwendung von POP3- oder IMAP-Protokollen entweder an Ihrem Standort oder bei der^3.

Es gibt drei Möglichkeiten, dies mit Roundtrip zu testen:

Testen von Outbound

1. Richten Sie SMTP so ein, dass die E-Mail von unseren externen Überwachungsstandorten über Ihren SMTP-Server gesendet wird, indem Sie die SMTP-Serveradresse eingeben. (Dies testet, ob Ihr SMTP-Server funktioniert.
2. Geben Sie eine E-Mail-Adresse ein, an die die E-Mail gesendet werden soll (z. B. gmail.com)
3. Geben Sie die gmail POP3/IMAP-Serveradresse ein, damit der Überwachungsspeicherort die E-Mail vom SMTP-Server abrufen kann.

Test Inbound

1. Richten Sie SMTP so ein, dass die E-Mail von unseren externen Überwachungsstandorten über den Gmail-SMTP-Server gesendet wird, indem Sie die Gmail-SMTP-Serveradresse eingeben.
2. Geben Sie eine E-Mail-Adresse ein, an die die E-Mail gesendet werden soll (ein Konto in Ihrem System)
3. Geben Sie Ihre POP3/IMAP-Serveradresse ein, damit der Überwachungsspeicherort die E-Mail vom SMTP-Server abrufen kann.

Testen von Ausgehend und Eingehend

1. Richten Sie SMTP so ein, dass die E-Mail von unseren externen Überwachungsstandorten über Ihren SMTP-Server gesendet wird, indem Sie die SMTP-Serveradresse eingeben.
2. Geben Sie eine E-Mail-Adresse ein, an die die E-Mail gesendet werden soll (z. B. gmail.com)
3. Richten Sie das Gmail-Konto so ein, dass es automatisch an Ihr POP3/IMAP-E-Mail-Konto auf Ihrem Server zurückgesendet wird.
4. Geben Sie Ihre POP3/IMAP-Serveradresse ein, damit der Überwachungsspeicherort die E-Mail von Ihrem Server abrufen kann.

Testen von ActiveSync

Das ActiveSync-Protokoll führt auch eine Hin- und Rückfahrt durch. Active sync DOES testen die Möglichkeit, eine E-Mail von einem Remotegerät (unseren Überwachungsstandorten) zu senden und eine E-Mail vom Server von diesem Remotegerät abzurufen. Die E-Mail wird jedoch nicht von einem aktiven Synchronisierungsserver an einen anderen gesendet, da das sendende und empfangende Konto dasselbe Konto auf demselben Server ist, sodass der kürzeste Weg zu einer lokalen Adresse nicht erforderlich ist, die Nachricht an das öffentliche Internet zu senden, bis die Nachricht von einem Remotegerät abgerufen wird (unsere Überwachungsstandorte).

Hier ist der Unterschied zwischen Round Trip und ActiveSync - Sie können sehen, dass E-Mails über mehrere Server mit einem Drittanbieter-E-Mail-Anbieter wie Gmail verschoben werden, während sich die E-Mail mit activesync auf einem Server befindet:

3rd Party Round Trip E-Mail-Pfad

1. Dotcom-Monitor "E-Mail-Client" sendet eine Nachricht über das öffentliche Internet
2. SMTP Server des Kunden leitet die Nachricht an das^{Drittanbieterkonto} im öffentlichen Internet weiter
3. ^3. Teil (Gmail) E-Mail-Server Empfängt die Nachricht
4. ^3. Teil (gmail) Auto leitet sich über das öffentliche Internet an Den E-Mail-Server für Kunden weiter
5. Dotcom Monitor "E-Mail-Client" fordert E-Mails von Kunden POP3 oder^rd IMAP-Server über das öffentliche Internet (oder direkt von der Drittanbieter-Gmail, wenn Sie nicht automatisch weiterleiten)

ActiveSync-E-Mail-Pfad

1. Dotcom-Monitor "E-Mail-Client" sendet eine Nachricht über das öffentliche Internet
2. Customers ActiveSync Server leitet die Nachricht weiter und stellt fest, dass das Konto lokal ist, sodass es direkt an das Konto gesendet wird, ohne es an das öffentliche Internet zu senden.
3. Dotcom Monitor "E-Mail-Client" fordert E-Mail von Kunden ActiveSync Server über das öffentliche Internet

Eine Konto-ID, die auf der Startseite "Konto auswählen" in der Liste der verfügbaren Konten angegeben wird.

Nachdem Sie sich angemeldet haben, suchen Sie Ihre Konto-ID im Menü Konto in der Dropdown-Liste.

Darüber hinaus wird Ihre Konto-ID unter > Kontokontoeinstellungenangezeigt.

Abteilungs-ID

Sobald Sie in einem Masterkonto eingeloggt sind, finden Sie Ihre Abteilungs-IDs unter Konto > Kontoeinstellungen > Abteilungen.

Each test in LoadView has a unique ID. Using the test ID you can call a specific scenario while configuring LoadView integration (e.g., for Jenkins or CircleCl builds).

The Test ID can be found on the test page.

The approach provides the ability to carefully define how Dotcom-Monitor interprets responses as either “Up” or “Down” responses. This is accomplished using filters.

Filtering defines the Up/Down states using the following adjustable criteria:

• Error is reported for a specified number of minutes
• Error is confirmed by a specified number of agents
• Error is detected in a specified number of tasks.

All filters and their settings are available at Configure > Filters. After a filter is applied to a device all of the device’s notifications are based on the filter’s criteria. “Default Filter” is assigned to all new devices. The default filter has a balanced configuration and is suitable for most monitoring devices.

Uptime/Downtime Calculations

The formula for the Downtime calculation is as follows:

1. Downtime Duration is tied directly to the configurations within the filter:

• The Downtime period starts when a filter’s conditions are met. For example, when the number of agents which report a failure equals the number of agents specified in the filter, and as also specified the conditions are met for the number of minutes and tasks, then a downtime alert is sent.
• The Uptime period starts when the filter’s conditions are no longer met. Specifically, Uptime starts when the number of agents, minutes, or tasks, which have reported “up” success, no longer meet the conditions needed for the filtered “down” conditions. For example, an “up” state is indicated when the number of error (“down”) responses received by agents becomes less than the number of error (“down”) responses that agents need, as set in the filter, in order to indicate a “down” condition.

2. Duration of “Undefined” state. An Undefined state can be set when the status of each agent involved in monitoring becomes Undefined. An agent status is considered as Undefined if the agent does NOT provide any response (error or success) in a certain amount of time:

Response Wait Time Duration = (the overall agents number+1) × monitoring frequency + 15 min

For example, we use three monitoring agents and a monitoring frequency of 5 minutes. Each agent will wait for a response for Response Wait Time Duration = (3+1)×5+15 min = 35 min. Once the time expired and no response received, an agent reports Undefined.

3. Duration of “Postponed” state.  Postponing a device at any moment will stop any monitoring activity until it is re-enabled.

4. Duration Excluded by Schedule. Another entity that can significantly affect Uptime/Downtime calculations is Schedules. This is an option for managing your monitoring during routine maintenance. Monitoring can be postponed for specific days of the week as well as specific hours and minutes during a day. To set up a schedule, follow the instruction.

LoadView verwendet Load Injector-Server von Amazon Web Services (AWS) und Azure Cloud Services. Dotcom-Monitor hat 17 geografische Regionen Load Injector Server können angegeben werden und die Last kann generiert werden. In jeder Region können etwa 500 Lastinjektoren instanziiert werden.

Kapazitätsgrenzen hängen aufgrund der Unterschiede in den Testausführungsalgorithmen vom Überwachungsplattformtyp ab:

• Für HTTP (S)-Tests kann jeder Load Injektor ungefähr bis zu 1000 gleichzeitige HTTP-Benutzer verarbeiten.
• Für Webseiten- oder Webanwendungstests kann jeder Load Injector ungefähr bis zu 25 gleichzeitige Benutzer verarbeiten.

Der Grenzwert für einen bestimmten Auslastungstesttyp wird mit der folgenden Formel berechnet:

500 x 16 x Anzahl gleichzeitiger Benutzer pro Lastinjektor = Maximale Benutzerauslastung

Finden Sie die resultierenden Kapazitätsgrenzen unten:

Sie können die Agentenspeicherorte für mehrere Geräte gleichzeitig auf dem
Bildschirm Geräte-Manager
bearbeiten.

1. Erweitern Sie im Geräte-Managerdie Überwachungsplattformen, und wählen Sie die Geräte aus, die Sie aktualisieren möchten, indem Sie die Kontrollkästchen neben jedem Gerät aktivieren oder alle Geräte unter einer Plattform auswählen, indem Sie das Kontrollkästchen im Plattformkopf aktivieren.
2. Klicken Sie auf die Aktionsschaltfläche für die Plattform, die Sie aktualisieren möchten.
3. Wählen Sie Agent aus, um die Agentenspeicherorte für die ausgewählten Geräte zu aktualisieren.
4. Wählen Sie auf dem nächsten Bildschirm alle Speicherorte aus, die Sie hinzufügen oder entfernen möchten.
5. Drücken Sie die entsprechende Schaltfläche Hinzufügen oder Entfernen am unteren Rand.

Kurz gesagt, die Aufgaben von UserView und BrowserView Platforms laden eine Webseite in einem echten Browser und führen alle Seitenkomponenten aus, während HTTP(S) Task den emulierten "synthetischen" Browser verwendet und nur Das Seitenelement herunterlädt, das ohne Rendering angefordert wurde.

Weitere Informationen finden Sie unter Unterschiede zwischen der Überwachung über HTTP(S) und über BrowserView/UserView und Unterschiede in der Zeitmessung zwischen HTTP(S) und BrowserView/UserView Tasks.

Die API ist durch die IP-Adresse gesperrt, um nur autorisierten Benutzern Zugriff zu gewähren. Bevor Sie die API verwenden, müssen Sie sich an den Support wenden und ihnen die IP-Adressen der Speicherorte geben, an denen Sie auf die API zugreifen.

Weitere Informationen zur Verwendung der API finden Sie auf der Seite API Getting started.

Dotcom-Monitor löscht daten aus dem System automatisch nach dem folgenden Zeitplan.

Für aktive Konten:

• Generierte Berichtsdateien wie CSV- oder PDF-Dokumente werden ab dem generierten Datum 3 Jahre lang aufbewahrt.
• Reaktionszeitdaten aus allen Aufgaben werden 6 Monate lang aufbewahrt. Alle Antwortzeitdaten, die in einem detaillierten Wasserfalldiagramm wie DNS, der ersten Paketantwortzeit und der Ladezeit einzelner Elemente enthalten sind, sind in den sechsmonatigen Aufbewahrungszeitraum einbezogen.
• Aggregierte Daten werden 3 Jahre lang aufbewahrt. Beispielsweise sind Details zur Elementebene eines HTTP-Seitenladetasks nach 1 Jahr nicht mehr verfügbar, aber die aggregierte Zeit zum Laden der Seite bleibt 3 Jahre lang erhalten. Dazu gehören alle berechneten Zusammenfassungsdaten, z. B. berechnete Betriebs- und Ausfallzeiten. Daher ist es möglich, dass ein Diagramm oder ein Bericht, der vor einem Jahr für Zeiträume über einem Jahr ausgeführt wurde, keine Daten zurückgibt, wenn der Zeitrahmen der angegebenen Abfrage kürzer ist als die gespeicherten aggregierten Daten.
• Videoaufnahmen werden nach 6 Tagen gelöscht. Weitere Informationen zur Funktionsweise von Videoaufzeichnungen finden Sie im Artikel "Videoaufzeichnung "Videoaufzeichnung "Videoaufzeichnung "Videoaufzeichnung".

Diese Aufbewahrungsrichtlinie gilt für alle Vorgangstypen.

Testkontodaten werden nicht gemäß diesem Zeitplan gespeichert und können jederzeit nach Ablauf der Testversion gelöscht werden.

Geschlossene Kontodaten können innerhalb von 60 Tagen nach der letzten Benutzeranmeldung für das Konto aus dem System gelöscht werden.

Nachdem Sie Aufgaben mit Benachrichtigungen eingerichtet haben und diese ausgeführt werden, erhalten Sie möglicherweise mehrere Benachrichtigungen, aber wenn Sie den Dienst oder die Website überprüfen, sieht alles gut aus. Es ist wichtig, auf den Inhalt der Warnungen zu achten, um herauszufinden, was den Fehler verursacht. Einige Fehler können benutzerdefinierte Dotcom-Monitor-Fehlercodesenthalten, während andere http-Statuscodes enthalten können, die Ihnen helfen können, die Ursache des Fehlers zu entschlüsseln.

Aufgrund der detaillierten Natur der Dotcom-Monitor-Überwachungsfunktionen sollten Sie Ihre Warnungen, Berichte oder aufgezeichneten Skripts optimieren, um bestimmte Elemente oder Fehler auszuschließen, um falsch positive Ergebnisse zu vermeiden. Einige dieser Gründe sind:

• Ein oder mehrere Überwachungsstandorte werden zeitveraltet, während die übrigen Standorte erfolgreich sind.
• Es wurden Änderungen an Ihrer Website vorgenommen, und bestimmte Elemente, die erwartet wurden, werden nicht mehr gefunden.
• Etwas auf Ihrer Website reagiert langsam, was dazu führt, dass das System denkt, dass es nicht mehr existiert,
• Der Netzwerkverkehr führt dazu, dass sich Ihre Website verlangsamt und die Timeout-Limits überschreitet.
• Ein "Hiccup" im Netzwerkverkehr über das Internet oder von einem Überwachungsstandort aus
• Elemente von Drittanbietern laden langsam und werden ausgeglast.
• URLs in Elemente von Drittanbietern wurden geändert.

Sie können diese falsch positiven Ergebnisse anpassen, indem Sie Filter erstellen und den Filter auf die Warnungen und Berichte des beanstandeten Gerätsanwenden.

Sie können auch den False Positive Check auf Ihren Geräten aktivieren. Dadurch wird eine Kaskade von Prüfungen von einem Speicherort ausgelöst, der einen Überwachungsfehler erkennt, um zu bestätigen, dass das Gerät mehr als einmal einen Fehler verursacht.

Der einfachste Weg, eine große Anzahl von Objekten (Geräte / Aufgaben / Filter / Zeitpläne / etc.) im Dotcom-Monitor System zu erstellen, besteht darin, ein Support-Ticket zu öffnen und das Support-Team um Unterstützung zu bitten. Sie können Sie anweisen, alle Objekte, die Sie erstellen möchten, in eine Kalkulationstabelle mit einer Spalte für jedes relevante Feld einzugeben.

Sobald Ihre Kalkulationstabelle abgeschlossen ist, können Sie sie an das Support-Ticket anhängen oder per E-Mail an den Support senden, und sie werden die Änderungen für Sie auffüllen.

Sie können einzelne Gerätewarnungen für bis zu 24 Stunden im Geräte-Manager stummstellen, indem Sie auf Aktionen neben dem Gerät klicken, Warnungsstilleauswählen und für den gewünschten Zeitraum stumm stumm halten.

Um mehrere Geräte gleichzeitig zum Schweigen zu bringen, klicken Sie auf das Kontrollkästchen neben jedem Gerät, das Sie stummstellen möchten, und klicken Sie dann auf die blaue Aktionsbeschriftung oben in der Tabelle, und wählen Sie Stille für den gewünschten Zeitraum aus.

Sie können die API auch verwenden, um Warnungen für mehr als 24 Stunden zum Schweigen zu bringen. Informationen dazu finden Sie in der API: Deaktivieren von Warnungen für ein Gerät. Bevor Sie die API verwenden können, müssen Sie die Unterstützung darüber benachrichtigen, welche IP-Adressen den API-Zugriff zulassen möchten.

Dotcom-Monitor-Systeme bieten einen robusten Satz von Überwachungstools, die sorgfältig angepasst werden sollten, um das für jedes überwachte Ziel erforderliche Leistungsniveau zu erkennen. Aufgrund der Anzahl und Vielzahl von Warnfaktoren müssen Sie möglicherweise einige der Einstellungen auf Ihren Monitoren optimieren, um Fehlalarme zu vermeiden.

Um festzustellen, ob die Warnungen, die Sie erhalten, gültig sind, lesen Sie diesen Artikel zum Identifizieren falsch positiver Ergebnisse.

Wenn Sie immer noch keine Benachrichtigungen erhalten möchten, wie sie derzeit konfiguriert sind, erhalten Sie durch das Ausführen eines Onlineberichts aus dem Geräte-Manager für die Zeit, in der Sie die Warnungen erhalten haben, mehr Einblick in das Auslösen der Warnungen.

Maximale Zeit abgelaufen

Wenn der Fehler im Onlinebericht "(300) Task Maximum timeout expired" angibt, bedeutet dies, dass der Vorgang länger als das für die Aufgabe angegebene maximale Timeout in Anspruch genommen hat. Dies kann auf ein legitimes Problem hinweisen, aber es liegt an Ihnen zu bestimmen, an welchem Punkt Sie Benachrichtigungen erhalten müssen. Wenn Sie der Meinung sind, dass Sie zu viele Benachrichtigungen erhalten, können Sie die Aufgabe bearbeiten und das maximale Timeoutlimit erhöhen.

Standortspezifische Fehler

Wenn Sie von mehreren Standorten aus überwachen, aber nur Probleme von einem einzigen Standort aus auftreten, können Sie mehrere Dinge überprüfen.

IP Eingeschränkter Zugriff

Wenn Ihr Serverzugriff über die IP-Adresse eingeschränkt ist, sollten Sie sicherstellen, dass Sie die IP-Adressen aller Überwachungsstandorte zu Ihrer IP-Adresszugriffsliste hinzugefügt haben.

Sicherheitszertifikate erforderlich

Wenn Ihr Server für den Zugriff auf Inhalte ein Zertifikat benötigt, müssen Sie ein Supportticket öffnen, um das Zertifikat an jeden Überwachungsspeicherort hochzuladen.

Große Firewall chinas

Wenn Sie Probleme von einem Standort in China haben, können Sie die Ergebnisse der "Großen Firewall von China" sehen. Da die chinesische Regierung eine strenge Kontrolle darüber hat, welche Inhalte innerhalb des Landes zugänglich sind, werden Inhalte manchmal als unzugänglich herausgefiltert oder die Bandbreite für bestimmte Websites wird gedrosselt, so dass Elemente von der Website eine Zeitüberschreitung aufweisen. In diesen Fällen gibt es oft wenig, was Sie tun können, da die chinesische Regierung die Kontrolle über das Netzwerk hat.

Kontakt Support

Wenn Sie Probleme von einem oder mehreren bestimmten Standorten haben, können Sie ein Support-Ticket öffnen und unser Support-Team wird mit Ihnen zusammenarbeiten, um andere mögliche Probleme zu identifizieren. Manchmal kann es zu Problemen mit einem fehlerhaften DNS-Serverrouting, einer umgekehrten DNS-Suche oder einem problemspezifischen Problem für den Überwachungsspeicherort treten.

UserView-Timeouts

Wenn Sie ein UserView-Skript ausführen, müssen Sie dem Skript möglicherweise eine Verzögerung hinzufügen, um der Site mehr Zeit zum ordnungsgemäßen Laden aller Elemente zu geben. Sie können den Schritt auch wiederholen, z. B. auf einen Hrefnachschlag klicken, nachdem Sie eine Verzögerung hinzugefügt haben, falls der Link nicht beim ersten Mal auf der Seite gerendert wurde, wird versucht, erneut darauf zu klicken.

Es gibt eine Reihe von Faktoren, die bestimmen, ob eine Warnmeldung gesendet wird und an wen sie gesendet wird.

Filter

Wenn Sie ein Gerät erstellen, wird ein Standardfilter automatisch auf alle Geräte angewendet. Der Standardfilter erfordert, dass mehr als ein Speicherort (es sei denn, Sie wählen nur einen Speicherort aus) den Fehler empfängt, bevor eine Warnung ausgelöst wird. Dies geschieht, um falsch positive Warnungen zu beseitigen, wenn ein Standort unter einem kleinen Netzwerk-Hickhack leidet. Sie können einen Filter erstellen, der nicht mehr als einen Standort erfordert, aber beachten Sie, dass Sie aufgrund der unkontrollierten Art des Datenverkehrs im Internet wahrscheinlich viele falsch positive Warnungen erhalten.

Zeitpläne

Wenn Sie einen Zeitplan auf ein Gerät angewendet haben, wird das Gerät nicht während ungeplanter Zeiträume überwacht, sodass keine Daten aufgezeichnet werden, um eine Warnung zu starten. Wir empfehlen Ihnen, keinen Zeitplan direkt auf Ihre Geräte anzuwenden, damit das System rund um die Uhr überwacht wird, auch wenn Sie keine Benachrichtigungen rund um die Uhr erhalten möchten. Sie können Zeitpläne auf verschiedene Warnungsgruppen anwenden, sodass verschiedene Gruppen z. B. nur während ihrer Arbeitsschichten Benachrichtigungen erhalten.

Eskalationsperioden

Beim Einrichten von Gruppenwarnungen können Sie angeben, ob die Gruppe sofort eine Benachrichtigung erhalten soll, wenn der Fehler erkannt wird, oder ob es eine Verzögerung zwischen dem Zeitpunkt, an dem der Fehler zum ersten Mal erkannt wird, und dem Senden eines Fehlers geben soll. Beispielsweise haben Sie z. B. eine Supportgruppe der zweiten Ebene, die erst benachrichtigt wird, wenn 30 Minuten nach Demenknach Erhalt einer Warnung der First-Tier-Support weiterhin ein Fehler auftritt.

Falsche Positivprüfungen

Standardmäßig ist der Falsche positiv-Scheck aktiviert. Dies bedeutet, dass, wenn ein Überwachungsspeicherort einen Fehler auftritt, versucht, den Fehler neu zu erstellen, bevor eine Fehlermeldung gesendet wird. Wir empfehlen nicht, dies zu deaktivieren, da dies das Risiko erhöht, falsch positive Warnungen zu erhalten, aber wenn Ihre Aufgabe besonders lange dauert, um eine Iteration abzuschließen, können Sie die falsch positive Prüfung deaktivieren, sodass Sie Sofortfehler erhalten, anstatt 10 Minuten nach dem ersten Fehler (5 Minuten, um die erste Aufgabe abzuschließen). , wenn der Fehler erkannt wird, weitere 5 Minuten, um den Fehler zu bestätigen)

Warnungsgruppen

Beachten Sie, dass Warnungsgruppen für mehrere Geräte eingerichtet und verwendet werden können. Wenn Sie feststellen, dass eine Person keine Warnung erhält, stellen Sie sicher, dass ihre Kontaktinformationen in allen erforderlichen Gruppen vorhanden sind. Seien Sie vorsichtig beim Bearbeiten oder Entfernen von Personen aus Gruppen, da diese Gruppe für zusätzliche Geräte verwendet werden kann.

Es gibt viele verschiedene Fehler, die auftreten können, während eine Website noch teilweise oder vollständig zugänglich ist. Einige der häufigsten Fehler, die auftreten können, während Ihre Website immer noch verfügbar zu sein scheint, sind:

• Ein Timeout wurde überschritten

Wenn der Fehler angibt, dass ein Timeout aufgetreten ist, bearbeiten Sie die Überwachungsaufgabendetails, und suchen Sie nach einem Wert für maximales Timeout. Wenn Sie viele Timeoutfehler erhalten, sollten Sie erwägen, den maximalen Timeoutwert zu erhöhen oder ihn ganz zu entfernen. Alternativ können Sie Aktualisierungen ihrer Website durchführen, um die Ladegeschwindigkeit zu verbessern, oder einzelne Elemente in einem Content Distribution Network (CDN) hosten. Wenn Sie keinen Wert für maximales Timeout angegeben haben, beträgt das Standardtimeout für eine Aufgabe 120 Sekunden.

• Text oder Bilder, die überprüft werden, werden nicht gefunden

Wenn die Aufgabe die Überprüfung eines bestimmten Schlüsselworts oder Bildes auf der Seite enthält, wird der Rest des Inhalts möglicherweise immer noch ordnungsgemäß geladen, während das erwartete Element fehlt.

• Elemente auf der Seite werden langsam geladen, wodurch das Skript fehlschlägt

Eine Überprüfung schlägt möglicherweise fehl, wenn die Aufgabe nach einem Element sucht, bevor das Element vollständig geladen wurde. Wenn es sich bei der Aufgabe um ein UserView-Skript handelt, müssen Sie möglicherweise eine Zeitverzögerung hinzufügen, bevor Sie dieses bestimmte Element validieren.

• Die DNS-Auflösung schlägt möglicherweise bei einer Teilmenge von DNS-Servern fehl

Manchmal kann einer der angegebenen DNS-Server oder DNS-Server der obersten Ebene aufgrund verschiedener Netzwerkprobleme im Internet oder lokalen Dienstanbietern die DNS-Auflösung möglicherweise nicht vollständig für Ihre Site qualifizieren. In diesem Fall fragen die meisten Browser weiterhin den nächsten verfügbaren DNS-Server ab und schließen die Auflösung ab, aber je nachdem, wie Die Überwachung eingerichtet ist, erhalten Sie möglicherweise immer noch Benachrichtigungen. Weitere Informationen zur Fehlerbehebung von DNS-Fehlern finden Sie in unserem Knowledge Base-Artikel hier.

Wenn ich im Online-Berichtsdetail eine einzelne Überwachungssitzung ausdehne, um detaillierte Details der Schritte anzuzeigen, warum werden dann Fehler angezeigt, aber die gesamtüberwachte Aufgabe ist erfolgreich?

Es gibt eine Reihe von Fällen, in denen ein einzelnes Element oder ein Aufruf an einen überwachten Server zu einer gekennzeichneten oder fehlerbehafteten Antwort führt. Solche Antworten werden in der Regel durch ein rotes Ausrufezeichen notiert, und der Text kann leicht ausgegraut sein.

1. Eine Ursache für diese Art von gekennzeichnetem Ereignis könnte sein, dass die überwachte Website eine Standardauthentifizierungerfordert. In diesem Fall wird die erste Anforderung für eine URL als Fehler gekennzeichnet, da der Server eine 401-Antwort zurückgibt, die den Browser darüber informiert, dass eine Standardauthentifizierung erforderlich ist. Die nächste Anforderung wird dann vom Monitor gesendet, einschließlich der grundlegenden Authentifizierungsanmeldeinformationen, die eine erfolgreiche Antwort zurückgibt, so dass die Aufgabe technisch erfolgreich abgeschlossen wurde.
2. Eine weitere mögliche Ursache könnte sein, dass das angeforderte Element bereits von einer vorherigen Anforderung im Überwachungsskript geladen wurde, und sobald dies realisiert wurde, wird die Anforderung abgebrochen, aber wieder wurde die Aufgabe als Ganzes erfolgreich abgeschlossen.
3. Für weitere Einblicke in solche Anomalien, zögern Sie nicht, den Support zu kontaktieren, indem Sie ein Support-Ticket öffnen.