{"id":12841,"date":"2020-06-30T17:27:41","date_gmt":"2020-06-30T17:27:41","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2020\/06\/30\/interne-anwendungen-ueberwachung-von-hinter-ihre-firewall\/"},"modified":"2026-08-26T22:24:28","modified_gmt":"2026-08-26T22:24:28","slug":"interne-anwendungen-ueberwachung-von-hinter-ihre-firewall","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/interne-anwendungen-ueberwachung-von-hinter-ihre-firewall\/","title":{"rendered":"So \u00fcberwachen Sie interne Anwendungen hinter Ihrer Firewall"},"content":{"rendered":"
\"IT
Interne Anwendungen werden auf privaten Adressen betrieben, die das \u00f6ffentliche Internet nicht erreichen kann \u2013 daher muss das Monitoring von innen heraus erfolgen.<\/figcaption><\/figure>\n

Ihr Monitoring-Dashboard zeigt \u00fcberall Gr\u00fcn, und trotzdem k\u00f6nnen die H\u00e4lfte der Mitarbeiter das ERP-System nicht \u00f6ffnen. Das ist der blinde Fleck des externen Monitorings: Die Pr\u00fcfungen laufen vom \u00f6ffentlichen Internet aus, w\u00e4hrend Ihr CRM, HR-Portal, Intranet und Helpdesk auf privaten Adressen liegen, die das Internet nicht erreichen kann. Wenn eine dieser Anwendungen ausf\u00e4llt, zeigt das Dashboard nichts an. Die Helpdesk-Warteschlange sagt eine Menge.<\/p>\n

Die L\u00f6sung ist kein zweites Tool oder ein selbstgebautes Skript-Wimmelbild. Es ist die Ausf\u00fchrung desselben synthetischen Monitorings<\/a>, dem Sie f\u00fcr \u00f6ffentliche Seiten bereits vertrauen \u2013 von innen in Ihrem Netzwerk \u00fcber einen privaten Agent, der hinter der Firewall sitzt und Berichte sendet. Der Agent ist der einfache Teil; die schwierigere Entscheidung ist, welche Mitarbeitererfahrung er repr\u00e4sentieren soll \u2013 Hauptsitz, Niederlassung, VPN-Nutzer \u2013 weil internes Monitoring versagt, sobald Sie das Innere der Firewall als einen Ort behandeln. Dieser Leitfaden erkl\u00e4rt, wie diese Architektur funktioniert und f\u00fchrt dann durch sechs nummerierte Schritte f\u00fcr die End-to-End-\u00dcberwachung interner Anwendungen: Inventarisierung, Agentenbereitstellung, synthetische Pr\u00fcfungen, Netzwerkpr\u00fcfungen, Abh\u00e4ngigkeitspr\u00fcfungen und Alarmierung.<\/p>\n

Warum externes Monitoring keine internen Anwendungen erreichen kann<\/h2>\n

\u00d6ffentliche Monitoring-Knoten k\u00f6nnen alles mit einer \u00f6ffentlichen Adresse testen. Interne Anwendungen haben keine. Sie werden im internen DNS aufgel\u00f6st, befinden sich im privaten Adressraum und sind oft nur \u00fcber VPN erreichbar. Zeigen Sie eine externe Pr\u00fcfung auf Ihr Intranet, erhalten Sie bestenfalls eine Verbindungszeit\u00fcberschreitung; die Pr\u00fcfung schl\u00e4gt nicht fehl, weil die Anwendung down ist, sondern weil der Pr\u00fcfstandort falsch ist.<\/p>\n

Also greifen die meisten Teams auf die zwei schlechtesten Monitoring-Strategien zur\u00fcck: auf Beschwerden warten oder einen Sysadmin Dinge von einem Arbeitsplatz aus anpingen lassen, wenn sich etwas merkw\u00fcrdig anf\u00fchlt. Keines davon liefert Basiswerte, Alarmierung, Antwortzeit-Historie oder Belege. Und interne Systeme haben echte Verpflichtungen \u2013 IT-Teams schlie\u00dfen interne SLAs und Betriebsvereinbarungen genau f\u00fcr diese Anwendungen ab, und ein SLA, das Sie nicht messen k\u00f6nnen, ist ein SLA, das Sie nicht nachweisen k\u00f6nnen<\/a>.<\/p>\n

Die Stakes sind dieselben wie bei kundenorientierten Seiten, nur nach innen gerichtet. Ein ERP-Ausfall stoppt die Auftragsabwicklung. Ein ausgefallenes Helpdesk-Portal legt das Team lahm, das alles andere repariert. Ein ausgefallenes Gehaltsportal am Stichtag ist ein unternehmensweites Ereignis. Diese Systeme verdienen dieselben kontinuierlichen Pr\u00fcfungen, die eine Umsatzseite erh\u00e4lt.<\/p>\n

Wie ein privater Monitoring-Agent funktioniert<\/h2>\n

Ein privater Agent ist eine Monitoring-Software, die Sie auf einem Host in Ihrem eigenen Netzwerk installieren. Er f\u00fchrt dieselben Pr\u00fcfungen aus, die ein \u00f6ffentlicher Monitoring-Knoten macht \u2013 HTTP(S)-Anfragen, skriptgesteuerte Browserabl\u00e4ufe, API-Aufrufe, Netzwerksonden \u2013 aber von dort, wo Ihre Mitarbeiter tats\u00e4chlich sitzen, gegen Adressen, die nur Ihr Netzwerk sehen kann.<\/p>\n

\"Architecture
Der Agent pr\u00fcft interne Apps lokal und schickt die Ergebnisse nach au\u00dfen \u2013 keine eingehenden Firewall-\u00d6ffnungen n\u00f6tig.<\/figcaption><\/figure>\n

Die Architektur ist wichtig wegen dessen, was sie nicht ben\u00f6tigt. Private Agenten folgen einem ausschlie\u00dflich ausgehenden Verbindungsmodell: Der Agent initiiert verschl\u00fcsselte Verbindungen zur Monitoring-Plattform, um Aufgaben abzurufen und Ergebnisse zu liefern \u2013 dieselbe Verkehrsrichtung, die Ihre Firewall bereits f\u00fcr Webbrowser-Arbeitspl\u00e4tze erlaubt. Auf der Firewall-Seite bedeutet das meist, ausgehenden Verkehr zu den Endpunkten der Plattform auf die Whitelist zu setzen. Sie \u00f6ffnen keine eingehenden Ports, ver\u00f6ffentlichen keinen internen Host im Internet und machen keine L\u00f6cher in den Perimeter. In stark gesicherten Umgebungen sind drei langweilige Dinge viel h\u00e4ufiger Ursache f\u00fcr Ausf\u00e4lle als die Architektur: Proxy-Authentifizierung, TLS-Inspektion und Zertifikatvertrauen sowie ob der Agent das interne DNS genauso aufl\u00f6st wie die Mitarbeiter. Pr\u00fcfen Sie diese drei, bevor Sie etwas anderes beschuldigen. Ihre Anwendungen, Anmeldedaten und Testziele bleiben intern; was verl\u00e4sst, sind Monitoring-Ergebnisse.<\/p>\n

Dotcom-Monitor Private Agents<\/a> wenden dieses Modell auf die gesamte Plattform an: dieselben synthetischen Pr\u00fcfungen, skriptierten Benutzerabl\u00e4ufe und Alarmierungen, die Sie von deren globalem Netzwerk aus fahren w\u00fcrden, ausgef\u00fchrt innerhalb Ihrer Firewall, mit Ergebnissen im selben Dashboard wie Ihr \u00f6ffentliches Monitoring. Ein Fenster deckt beide Seiten des Perimeters ab.<\/p>\n

Wie man interne Anwendungen in sechs Schritten \u00fcberwacht<\/h2>\n

Mit der Architektur klar, hier der Prozess. Jeder Schritt baut auf dem vorherigen auf, und Sie k\u00f6nnen dort aufh\u00f6ren, wo Ihre Umgebung es rechtfertigt.<\/p>\n

Schritt 1: Inventarisieren und Priorisieren Sie Ihre internen Anwendungen<\/h3>\n

Listen Sie auf, was tats\u00e4chlich genutzt wird: ERP, CRM, Buchhaltungs- und Gehaltsportale, HR-Systeme, Helpdesk, Kollaborations- und Messaging-Tools, Dateifreigaben und die internen APIs, die sie verbinden. H\u00f6ren Sie nicht bei der CMDB auf: Pr\u00fcfen Sie Ticket-Historie, SSO-App-Startprotokolle und die wiederkehrenden \u201eist es ausgefallen\u201c-Chatthreads, denn diese zeigen, worauf die Leute tats\u00e4chlich angewiesen sind, nicht nur, was jemand dokumentiert hat. Ein Abk\u00fcrzungsweg funktioniert immer: Fragen Sie leitende Ingenieure, welcher Ausfall sie ihren Urlaub absagen lassen w\u00fcrde. Dann stufen Sie die Liste nach Ausbreitungsradius ein. Was bringt das ganze Unternehmen zum Stillstand, wenn es ausf\u00e4llt? Was stoppt eine Abteilung? Was kann bis morgens warten?<\/p>\n

Nicht jede Anwendung braucht kontinuierliche Pr\u00fcfungen. Der IT-Helpdesk, der durch jeden anderen Ausfall geleitet wird, verdient Rund-um-die-Uhr-Betreuung; ein Reporting-Portal, das nur am Quartalsende genutzt wird, nicht. Weisen Sie jeder Stufe eine Pr\u00fcfungsfrequenz und ein Verf\u00fcgbarkeitsziel zu und schreiben Sie diese Ziele auf \u2013 sie werden die internen SLAs, die Ihr Monitoring sp\u00e4ter beweisen oder widerlegen wird.<\/p>\n

Schritt 2: Stellen Sie einen privaten Agenten dort bereit, wo Ihre Nutzer sitzen<\/h3>\n

Installieren Sie den Agent auf einem dedizierten, abgesicherten Host in Ihrem Netzwerk \u2013 eine stabile VM oder einen langlebigen Container, nicht eine gemeinsam genutzte Utility-Box, die ohne Vorwarnung neu gestartet wird \u2013 pr\u00fcfen Sie seinen ausgehenden Pfad zur Monitoring-Plattform und zeigen Sie Ihre ersten Pr\u00fcfungen auf die Tier-Eins-Liste. Das deckt den Hauptsitz ab. Aber nicht alle.<\/p>\n

Platzieren Sie Agenten nach Ausfallbereich, nicht nach Organigramm: einer in der N\u00e4he der Nutzer misst die Mitarbeitererfahrung, einer nahe der Anwendungsschicht misst die Anwendungs-Gesundheit, einer hinter dem VPN misst den Fernzugriff und wenn die drei unterschiedliche Ergebnisse liefern, ist diese Differenz die Diagnose. Wenn Sie Niederlassungen oder regionale Standorte haben, setzen Sie in jedem einen Agent ein. Eine Anwendung, die am HQ sofort reagiert, kann f\u00fcr eine Niederlassung am entfernten Ende eines ausgelasteten WAN- oder VPN-Links schleichen, und kein einziger Blickwinkel wird das aufdecken. Ein Agent pro Standort macht aus \u201eIn der Niederlassung Denver ist es immer langsam\u201c eine standortbezogene Diagrammansicht, mit der Sie arbeiten k\u00f6nnen. Behandeln Sie die Agent-Hosts selbst als Produktionsinfrastruktur: Halten Sie sie gepatcht, mit Strom versorgt und aus aggressiven Desktop-Aufr\u00e4umrichtlinien herausgenommen.<\/p>\n

Schritt 3: F\u00fchren Sie synthetische Pr\u00fcfungen auf kritischen Benutzerabl\u00e4ufen durch<\/h3>\n

Ein Ping, der sagt, dass die Anmeldeseite l\u00e4dt, sagt kaum etwas dar\u00fcber aus, ob ein Mitarbeiter seine Arbeit tun kann. Synthetische Pr\u00fcfungen sollten die Abl\u00e4ufe abbilden, die die Leute tats\u00e4chlich durchlaufen: anmelden, einen Datensatz \u00f6ffnen, eine Suche ausf\u00fchren, eine Transaktion absenden, das Ergebnis best\u00e4tigen. Mit einem Tool wie EveryStep<\/a> skriptet, wiederholt dieser Ablauf geplant vom privaten Agent ausgef\u00fchrt, und jeder Schritt erh\u00e4lt seine eigene Zeitmessung. Entwerfen Sie diese Skripte so, dass sie sicher f\u00fcr immer laufen: eine dedizierte Test-Identit\u00e4t, MFA bewusst gehandhabt statt auf sp\u00e4teres Brechen der Pr\u00fcfung zu setzen, einges\u00e4te Test-Datens\u00e4tze und keine Transaktionen, die f\u00fcr andere Aufr\u00e4umarbeit schaffen.<\/p>\n

Die zeitliche Messung pro Schritt ist der Wert, der sich verbirgt. Wenn der Ablauf sich verschlechtert, erfahren Sie nicht nur, dass die Anwendung langsam ist \u2013 Sie erfahren, dass der Suchschritt von zwei Sekunden auf zw\u00f6lf angestiegen ist, w\u00e4hrend die Anmeldung konstant blieb, was vor dem \u00d6ffnen eines Tickets auf die Datenbank deutet. Legen Sie diese Zeiten als Basiswerte an, wenn alles gesund ist, und alarmieren Sie bei Abweichungen, nicht nur bei Ausf\u00e4llen. Dieselbe Methode deckt schwere interne Plattformen ab \u2013 SharePoint<\/a> und SAP ERP<\/a> Installationen sind klassische Kandidaten. Wie oft jeder Ablauf ausgef\u00fchrt wird, bleibt eine eigene Entscheidung; die Abw\u00e4gungen werden in diesem Leitfaden zu Pr\u00fcfungsfrequenz und Standorten<\/a> behandelt.<\/p>\n

Schritt 4: F\u00fcgen Sie Netzwerk- und Infrastrukturpr\u00fcfungen hinzu<\/h3>\n

Interne Anwendungen fallen selten allein aus \u2013 oft ist das Netzwerk darunter das Problem. Langsames internes DNS l\u00e4sst jede Anwendung auf einmal kaputt erscheinen. Ein ausgelasteter Link zwischen Segmenten f\u00fcgt Latenz hinzu, die wie ein Anwendungsproblem aussieht. Paketverlust auf einem VPN-Tunnel verwandelt den Tag einer Niederlassung in eine Diashow.<\/p>\n

Vom selben privaten Agent aus f\u00fchren Sie Infrastrukturpr\u00fcfungen<\/a> unter der Anwendungsschicht aus: ICMP- und TCP-Sonden gegen kritische Hosts, DNS-Pr\u00fcfungen gegen Ihre internen Resolver und Latenzmessungen zwischen Netzwerksegmenten und Standorten. Beobachten Sie die Bandbreitenauslastung um bekannte Spitzenwerte herum. Eine nicht offensichtliche Pr\u00fcfung ist die Abfrage-Antwort-Zeit Ihrer Dom\u00e4nencontroller, denn wenn Active Directory oder LDAP langsamer wird, f\u00fchlt sich jede integrierte Anwendung kaputt an, w\u00e4hrend die eigenen Metriken jeder Anwendung weiterhin gr\u00fcn bleiben. Wenn eine Anwendungspr\u00fcfung und eine Netzwerkpr\u00fcfung gleichzeitig fehlschlagen, ist die Kombination selbst die Diagnose \u2013 Sie wissen in einem Zyklus, ob Sie das App-Team oder das Netzwerk-Team alarmieren sollten.<\/p>\n

Schritt 5: \u00dcberpr\u00fcfen Sie Drittanbieter-Abh\u00e4ngigkeiten von innen hinter der Firewall<\/h3>\n

Interne Apps sind stillschweigend von externen Diensten abh\u00e4ngig: dem Identit\u00e4tsanbieter f\u00fcr Single Sign-On, Zahlungsprozessoren, Lizenzservern, Anbieter-APIs. Anbieter-Statusseiten verschweigen oft: Sie best\u00e4tigen nur, dass die Seite des Anbieters erreichbar ist. Sie sagen nichts dar\u00fcber aus, ob Ihr<\/em> Netzwerk sie erreicht \u2013 durch Ihren Proxy, Ihre Firewall-Regeln, Ihr DNS. Eine veraltete Ausgangsregel kann eine Integration lahmlegen, w\u00e4hrend jede Statusseite im Internet Gr\u00fcn zeigt. F\u00fcr die wichtigen Abh\u00e4ngigkeiten f\u00fchren Sie gepaarte Pr\u00fcfungen vom \u00f6ffentlichen Internet und von Ihrem normalen Ausgangspfad aus: \u00d6ffentlich erfolgreich, privat fehlgeschlagen deutet auf Ausgang oder DNS hin, und beides schl\u00e4gt fehl, ist der Anbieter schuld.<\/p>\n

Also f\u00fchren Sie API-Pr\u00fcfungen<\/a> gegen diese Abh\u00e4ngigkeiten von innen hinter der Firewall aus, zusammen mit Gesundheitschecks Ihrer eigenen Kernfunktionen. F\u00fcr ein internes Abrechnungssystem bedeutet das geplante Tests von Anmeldung, Datenabruf und Transaktionsverarbeitung \u2013 Funktionen, deren Ausfall jemand innerhalb einer Stunde meldet, jetzt aber innerhalb von Minuten erkannt werden.<\/p>\n

Schritt 6: Automatisieren Sie Alarmierung und Reaktion<\/h3>\n

Erkennung zahlt sich nur aus, wenn die richtige Person davon erf\u00e4hrt. Richten Sie jeden Alarm<\/a> einer Anwendung an das Team, das sie besitzt, nicht an ein gemeinsames Postfach. Alarmieren Sie bei Verschlechterungen sowie bei harten Ausf\u00e4llen, damit die zw\u00f6lfsek\u00fcndige Suche Aufmerksamkeit erh\u00e4lt, bevor sie zum Ausfall wird. Seien Sie auch realistisch bei der Schwere: Ein internes Reporting-Portal, das um 3 Uhr morgens ausf\u00e4llt, ist kein Weckruffall, denn das Ziel ist der Schutz der Produktivit\u00e4t w\u00e4hrend der Gesch\u00e4ftszeiten, nicht f\u00fcnf Neunen. Stimmen Sie Richtlinien f\u00fcr au\u00dferhalb der B\u00fcrozeiten ab, um den Schlaf Ihres Teams zu sch\u00fctzen. F\u00fcgen Sie Eskalationen f\u00fcr Vorf\u00e4lle hinzu, die niemand best\u00e4tigt, und schieben Sie Alarme in die Kan\u00e4le, die Ihre Teams bereits beobachten \u2013 Chat, Ticket-Systeme, Bereitschaftstools.<\/p>\n

Automatisieren Sie dann die Routine-Enden. Wenn sich ein bekannter instabiler Dienst sicher neu starten l\u00e4sst, wenn die Ressourcennutzung einen Schwellenwert \u00fcberschreitet, skripten Sie das und lassen den Alarm die L\u00f6sung ausl\u00f6sen; bewahren Sie die Menschen f\u00fcr Ausf\u00e4lle auf, die Urteilsverm\u00f6gen erfordern. Und sch\u00fctzen Sie sich vor Fehlalarmen \u2013 eine einmal vom Agenten fehlgeschlagene Pr\u00fcfung ist eine Tatsache, die Sie best\u00e4tigen sollten, bevor Sie jemanden wecken. Praktische Alarm-Tuning-Methoden finden Sie in unserem Leitfaden zu Website-Monitoring-Alarme<\/a>.<\/p>\n

Externes Monitoring vs. privates Agenten-Monitoring<\/h2>\n

Die beiden Ans\u00e4tze sind keine Rivalen; sie decken entgegengesetzte Seiten der Firewall ab, und die meisten Organisationen brauchen beides.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Faktor<\/th>\nExternes Monitoring<\/th>\nPrivates Agenten-Monitoring<\/th>\n<\/tr>\n<\/thead>\n
Blickwinkel<\/td>\n\u00d6ffentliches Internet, globale Standorte<\/td>\nInnerhalb Ihres Netzwerks, dort, wo Mitarbeiter sitzen<\/td>\n<\/tr>\n
Kann private Adressen erreichen<\/td>\nNein<\/td>\nJa<\/td>\n<\/tr>\n
Firewall-\u00c4nderungen<\/td>\nKeine (Ziele sind \u00f6ffentlich)<\/td>\nNur Ausgeh-Whitelist; keine eingehenden Ports<\/td>\n<\/tr>\n
Was gepr\u00fcft wird<\/td>\nVerf\u00fcgbarkeit und Performance f\u00fcr Kunden<\/td>\nMitarbeitererfahrung bei internen Systemen<\/td>\n<\/tr>\n
Wo sensible Ziele liegen<\/td>\nVon \u00f6ffentlichen Pr\u00fcfungen per Design exponiert<\/td>\nBleiben drinnen; nur Ergebnisse verlassen das Netzwerk<\/td>\n<\/tr>\n
Am besten geeignet f\u00fcr<\/td>\nWebseiten, \u00f6ffentliche APIs, SaaS-Frontends<\/td>\nERP, CRM, Intranets, interne APIs, Niederlassungs-Konnektivit\u00e4t<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Die entscheidende Frage ist der Blickwinkel: Messen Sie kundenorientierte Systeme dort, wo die Kunden sind, und interne Systeme dort, wo die Mitarbeiter sind. Eine Plattform, die beides kann, h\u00e4lt die beiden Perspektiven in einem Dashboard statt in zwei Tools.<\/p><\/blockquote>\n

Das Fazit<\/h2>\n

Interne Anwendungen fallen genauso aus wie \u00f6ffentliche, aber sie fallen im Dunkeln aus: Externe Pr\u00fcfungen k\u00f6nnen sie nicht erreichen, so dass die erste Alarmierung meist von einem Menschen kommt. Ein privater Agent schlie\u00dft diese L\u00fccke mit einer ausschlie\u00dflich ausgehenden Architektur, die keine eingehenden Firewall-\u00c4nderungen ben\u00f6tigt, und die oben genannten sechs Schritte machen daraus eine funktionierende Praxis \u2013 inventarisieren und stufen Sie Ihre Apps ein, stellen Sie Agenten dort bereit, wo Nutzer sitzen, skripten Sie die wichtigen Abl\u00e4ufe, \u00fcberwachen Sie das darunterliegende Netzwerk, pr\u00fcfen Sie Drittanbieter-Abh\u00e4ngigkeiten von innen und leiten Sie Alarme an die Eigent\u00fcmer mit automatisierter Routinebehandlung weiter.<\/p>\n

Beginnen Sie mit einem Agenten und Ihren f\u00fcnf wichtigsten internen Systemen. Innerhalb einer Woche haben Sie Basiswerte, die noch nie jemand in Ihrer Organisation gesehen hat, und die n\u00e4chste ERP-St\u00f6rung wird ein Ticket sein, das Ihr Team er\u00f6ffnet \u2013 nicht Ihre Nutzer.<\/p>\n

\n

\u00dcberwachen Sie, was das Internet nicht sehen kann<\/h2>\n

F\u00fchren Sie echtes Browser-synthetisches Monitoring<\/a> gegen Ihre internen Anwendungen mit Dotcom-Monitor Private Agents<\/a> durch \u2013 dieselbe Plattform, dasselbe Dashboard, innerhalb Ihrer Firewall. Starten Sie eine kostenlose Testversion<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"

\u00dcberwachen Sie interne Apps hinter Ihrer Firewall: private Agent-Architektur, synthetische und Netzwerkpr\u00fcfungen, Gesundheitschecks und Benachrichtigungseinrichtung.<\/p>\n","protected":false},"author":21,"featured_media":34447,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[883],"tags":[],"class_list":["post-12841","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/12841","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=12841"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/12841\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/34447"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=12841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=12841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=12841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}