End2End und Atlas-Probes
Kennen Sie das Projekt „RIPE Atlas“ (https://atlas.ripe.net/) Es ist ein verteiltes Monitoring des Internet mit kleinen Probes (Hardware oder Software). Eine Erklärung und Gegenüberstellung hilft auch beim Verständnis der Thematik eines End2End-Monitorings.
Herausforderung
Das Internet ist ein riesiger Verbund vieler Rechner, Router und Provider bei dem es keine zentrale Firma gibt, die den Betrieb sicherstellt. Es gibt die Root-DNS-Server, welche für die Namensauflösung zuständig sind und die fünf Vergabestellen (RIPE NCC, ARIN, APNIC; LACNIC, AfriNIX) für IP-Adressen über lokale Provider. Darüber steht das ICANN als „Non-Profit-Organization“. Im Prinzip arbeiten alle Institutionen und Provider gemeinsam an dem Ziel, das Internet als dezentrales Netzwerk funktionstüchtig zu halten. Provider überwachen ihr eigenes Netzwerk, die Verbindung zu den zahlenden Kunden und ihre Peerings aber stellen diese Informationen in der Regel nicht öffentlich bereit.
Es weiß also niemand, wie gut es dem Internet gerade geht und ob bestimmt Teilnetzwerk nicht oder nur schlecht erreichbar sein oder DNS-Blockaden z.B. auf Zensur schließen lassen.
Wie funktioniert Atlas?
Das RIPE NCC in Amsterdam hat daher ATLAS gestartet, welches eine Plattform zum Austausch von Konfigurationsdaten und Messergebnissen ist, die durch Probes ausgelesen und geliefert werden. Das RIPE NCC stellt dabei nur das Portal und das Backend bereit, während jeder eine Probes einrichten und betreiben kann. Anfang 2024 waren über 12.000 Probes aktiv, die ca. 15.000 Messungen/Sek durchgeführt und an die Atlas-Server des RIPE gesendet haben.
Der Betreiber einer Probe muss sich erst ein kostenfreies Konto beim RIPE NCC anlegen und kann dann die Software für eine selbst betriebene Probe kostenfrei herunterladen und installieren. Alternativ gibt es auch eine fertige Hardware mit Ethernet und Stromversorgung. Das RIPE NCC benötigt aber Sponsoren für den Betrieb und die Hardware. Daher habe ich eine Probe als Software einfach auf einer VM gestartet. Die überwacht damit durch regelmäßige Aufrufe gegen vom RIPE definierten Gegenstellen die Verfügbarkeit von meinem Netzwerk. Je mehr Probe-Systeme ihre Daten an das RIPE melde, desto weniger weiße Flecken gibt es auf der Landkarte. Eine Probe führt nur selbst Tests aus aber lauscht nicht auf lokalen Verkehr und ist auch nicht selbst erreichbar. Im Bereich Paderborn sind am 5. Feb 2024 folgende Probes gelistet
Quelle: https://atlas.ripe.net/coverage/
Darunter fallen natürlich "Freifunk"-Probes und VegaSystems als lokaler ISP aber auch einige scheinbar "privat" betriebene Probes
VegaSystems https://atlas.ripe.net/probes/21416 (Seit 2014) "tl-mr3020" VegaSystems Elsen: https://atlas.ripe.net/probes/23970 (Seit 2016) "tl-mr3020" FF-U-Probe https://atlas.ripe.net/probes/12583 (seit 2015) "tl-mr3020" FF-V-Probe nchFF-V-Probe https://atlas.ripe.net/probes/12712 (Seit 2021) "tl-mr3020"
Die vier Probes basieren anscheinend alle auf dem TPLink TL-MR-3020", einem kleinen Taschenrouter für unter 25€, der vermutlich mit OpenWRT (https://openwrt.org/toh/tp-link/tl-mr3020) und darauf installierter Atlas-Probe läuft. Diese Gerte wurden vom RIPE damals als "Hardware Version 3" verteilt.
- What is RIPE Atlas?
https://atlas.ripe.net/docs/getting-started/what-is-ripe-atlas.html - RIPE Atlas Probes
https://atlas.ripe.net/landing/probes-and-anchors/
https://atlas.ripe.net/about/probes/
https://atlas.ripe.net/about/anchors/ - RIPE Atlas
https://en.wikipedia.org/wiki/RIPE_Atlas
Atlas Credits
Durch die selbst gehostete Probe "verdiene" ich als Betreiber als Provider entsprechende "Credits", mit denen ich selbst Erreichbarkeits- und Latenzzeit-Messungen von beliebigen Probes zu anderen Gegenstellen über PING, TRACEROUTE, DNS, TLS, NTP und mit Einschränkungen auch HTTP konfigurieren kann.
Für eine Firma kann es daher sehr interessant sein eine Atlas-Probe zu betreiben und damit nicht nur die Erreichbarkeit der Gegenstellen vom eigenen Netzwerk zu prüfen, sondern mit den verdienten Credits auch andere Probes zu verwenden, um z.B. die eigenen Server von von extern zu überwachen.
Vielleicht ist das auch der Grund, warum die ein oder andere Firma selbst schon eine Atlas-Probe betreibt. Unter https://atlas.ripe.net/probes/public können Sie nach Namen aber auch insbesondere nach ASN suchen, z.B. ob ihr Provider schon eine Probe betreibt. Wenn ich nach dem Netzwerk von Microsoft (AS8075) suche, dann finde ich 36 Atlas-Probes mit 532 Userdefinierte Messungen (UDM). Im AS60294 (Deutsche Glasfaser) gibt es 72 Probes, von denen aber nur 48 verbunden sind.
Mit den passenden Credits können Sie als Firma damit ohne weitere Aktivitäten z.B. die Erreichbarkeit von Azure Amsterdam zu ihren Servern oder Services messen. Das ist insbesondere für die Firmen interessant, die VMs in Azure betreiben, die auf Dienste bei anderen Cloud-Providern zugreifen.
- Atlas: Credits
https://atlas.ripe.net/docs/getting-started/credits.html - Liste der Atlas Probes
https://atlas.ripe.net/probes/public - Atlas Probe von Microsoft (?)
https://atlas.ripe.net/probes/1001322/
Grenzen von Ripe Atlas
Viele Probes, viele Zahlen liefern noch keine Antworten, wenn diese nicht in Relation und eine übersichtliche Darstellung gebracht werden. Zudem hören sich 12000 Probes schon viel an aber die meisten werden von Internet Service Providern oder Firmen in ihrem Rechenzentrum betrieben. Ein Atlas-Probe gibt es aber leider nicht als Windows Dienst und schon gar nicht auf einem Client. Der Nutzen für Provider und Hoster ist groß aber für die Firma und deren Anwender nicht, denn einige Dinge kann Atlas nicht, die aus meiner Sicht für eine Endpunkt-Monitoring erforderlich wären.
- Keine Dauertests mit Zusammenfassung
Ich schreibe und erkläre immer wieder, dass "einmal Messen pro Minute" nur Mittelwerte über Auslastungen bringe aber keine qualifizierte Aussagen zu VoIP oder Stabilität, wenn Ausfälle weniger Sekunden dauern. Eine Atlas-Probe kann zwar auf wenige Sekunden Wiederholung konfiguriert werden aber die Menge an Daten macht eine Auswertung schwer, da keine Zusammenfassungen (Percenzil, Min, Max, Median) über eine Zeitspanne möglich sind. - Keine Konfigurationschecks
Es wird davon ausgegangen, dass die Atlas-Probe funktioniert aber nicht selbst prüft, ob sie optimal konfiguriert ist. Sie wird ja von einem Profi eingerichtet und läuft nicht auf einem Client. - Kein UDP
Es gibt keine UDP-Test, der ICE/STUN/TURN nachbilden und damit die Erreichbarkeit verschiedener Audio/Video-Dienste prüfen kannn - Nicht Windows
Leider ist eine Atlas-Probe nicht als PowerShell, Windows Applikation oder Windows Dienst verfügbar und kann damit nicht auf einem Anwender-Client mitlaufen. - Skalierung
Anfang 2024 gibt es ca. 12.00 Probes weltweit. Ich denke da würde es schon stören, wenn einige Firmen nun auf all ihren Clients eine Atlas-Probe betreiben würden. - Standort
Eine Atlas-Probe steht in der Regel in einem Rechenzentrum mit 24h Strom, Klima, Ethernet-Netzanbindung. Sie misst damit die Qualität ihrer eigenen Dienste direkt "neben" dem Server oder sogar auf dem Server. Das sagt natürlich nichts über die die Leistung aus, die beim Client ankommt.
Ich hoffe, dass Sie damit den Einsatzbereich und den Nutzen von Atlas besser verstehen. Atlas ist ein leistungsfähiges Werkzeug und jede Firma sollte sich durchaus überlegen, eine entsprechende Probe aufzubauen, um ihr Monitoring zu erweitern und über die verdienten Credits auch andere Probes zum Monitoring der eigenen Dienste einsetzen zu können. Atlas und Rimscout überlappen sich aber nicht, sondern können sich ergänzen.
Atlas Probe betreiben
Wenn Sie nun auf den Geschmack gekommen sind und eine Atlas-Probe selbst betreiben wollen, dann brauchen Sie aktuell ein Linux-System (Debiam oder CentOS). Das kann eine VM sein aber auch ein Raspberry Nano oder die OpenWRT-Basis kann eine Atlas-Probe betreiben. Es ist aktuell kein "Windows EXE/MSI" mit Maus und auch kein vorgefertigtes Paket als VM, ISO oder RPM-Paket. Nur für Docker haben andere Autoren ein Pakete geschnürt. Die Installation ist klassisch ein "GET/Compile/Build/Deploy"-Prozess, der aber gut beschrieben ist.
- Installation Instructions
https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/master/INSTALL.rst
Ich habe die Atlas-Probe einfach auf meinem Squid (Debian) mitlaufen lassen, auf dem ca. 400 MB addiert wurden. Ich nutze auf meinem Debian 12 Buster das Programm "SU", um mich zum Root zu machen. Andere Derivate nutzen vielleicht SUDO vor dem Aufruf.:
# Mache mich erst mal rum Chef. Das "-" hinter SU ist wichtig su - # Installation der erforderlichen Module und Werkzeuge zum kompilieren apt update && apt install git tar fakeroot libssl-dev libcap2-bin autoconf automake libtool build-essential # RIPE Atlas Repository kopieren git clone --recursive https://github.com/RIPE-NCC/ripe-atlas-software-probe.git # deb-Datei im aktuellen Arbeitsverzeichnis zusammenbauen lassen ./ripe-atlas-software-probe/build-config/debian/bin/make-deb # Installation des DEB-Pakets. Eventuell muessen Sie die Versionsnummer anpassen dpkg -i atlasswprobe-5080-1.deb
Bei der Installation der Probe wird ein Schlüsselpaar im Verzeichnis /var/atlas-probe/etc/probe_key.pub generiert.
# Auslesen des PublicKey. Der komplette Inhalt ist erforderliche cat /var/atlas-probe/etc/probe_key.pub
Diesen öffentlichen Schlüssel muss ich auf https://atlas.ripe.net/apply/swprobe/ eintragen. Damit kann sich die Probe gegenüber dem Atlas-Netzwerk eindeutig authentifizieren und die Verbindung ist zudem verschlüsselt. Nach der Anmeldung sollte ich meine Probe auf https://atlas.ripe.net/probes/mine finden und auch im Posteingang eine Willkommensmail erhalten haben.
https://atlas.ripe.net/probes/mine
Über die ID kann ich weitere Einstellungen vornehmen, z.B. Benachrichtigungen an meine beim RIPE hinterlegte Mailadresse, die genauer Angabe des Orts und später auch ein Wechsel des Public Key, die Übergabe an ein andere RIPE-Konto oder die Löschung steuern. Sie können auch dein Limit für die maximal durch die Probe verwendbare Bandbreite setzen. Auf "https://atlas.ripe.net/messages/" finden Sie die Nachrichten zu den Probes und Veränderungen.
Weitere Hinweise finden Sie auf:
- Troubleshooting Probe Status Issues
https://atlas.ripe.net/docs/howtos/troubleshooting-probe-status.html
Damit kann die Probe erst mal ein paar Tage "laufen".
Wenn Sie nicht startet, dann kontrolliere Sie die lokalen Logfiles auf "/var/atlas-probe/status". In meinem Fall hat sich die Probe dran gestört, dass ich die der SSH-Konfiguration die Anmeldung als ROOT erlaubt hatte.
Install the RIPE Atlas Software Probe
in Debian/Raspbian/Ubuntu in 15 minutes (English)
https://www.youtube.com/watch?v=8uvzE6bhks4
Install the RIPE Atlas Software Probe
in CentOS 7/8 Binary (RPM) in 5 minutes (English)
https://www.youtube.com/watch?v=SNecvbNYi20
RIPE NCC : RIPE Atlas
https://www.youtube.com/playlist?list=PLDWsJmznqM9FxRW14Edq14Sl4Zm896_B6
- RIPE Atlas Software Probes
https://atlas.ripe.net/docs/howtos/software-probes.html - RIPE Atlas Software Probes
https://labs.ripe.net/author/alun_davies/ripe-atlas-software-probes/ - Raspbian - Installation via Quellcode
https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Raspbian-source.de.md - Setting up a RIPE Atlas Probe (Docker)
https://github.com/Jamesits/docker-ripe-atlas
https://mrkaran.dev/posts/ripe-atlas-probe-setup/
Kommunikation
Natürlich habe ich der Probe mit Wireshark auf die Finger geschaut und ohne weitere Konfiguration macht er nur ein paar HTTPS-Requests und DNS-Anfragen
Bei den DNS-Anfragen ist etwas komisch, dass er nicht die konfigurierten DNS-Server sondern eigene DNS-Server fragt. Damit dies funktioniert, muss die Firewall natürlich 53/TCP ins Internet erlauben.
Name | Typ | Server | Antwort | Bemerkung |
---|---|---|---|---|
U1726009.He3b0c44298fc1c14.sos.atlas.ripe.net |
AAAA |
Default |
ame: nl-ams-as3333-3.anchors.atlas.ripe.net Address: 2001:67c:2e8:3::c100:a4 Aliases: U1726009.He3b0c44298fc1c14.sos.atlas.ripe.net ping.ripe.net |
Interessant, dass mein IPv4-DNS-Server bei einer Antwort eine IPv6-Adresse liefert, obwohl es im LAN kein IPvv6-Deployment gibt. Die Anfrage wird ca. alle 180 Sekunden wiederholte |
ctr-hel09.atlas.ripe.net |
A |
Default |
95.216.246.243 |
|
host.bind und id.server |
TXT |
193.0.14.129 192.36.148.17 192.5.5.241 199.7.83.42 192.168.102.204 202.12.27.33 170.247.170.2 192.33.4.12 199.7.91.13 192.112.36.4 192.203.230.10 198.97.190.53 192.58.128.30 |
Unterschiedliche Namen der DNS-Server |
Anscheinend misst und prüft die Atlas-Probe damit die Erreichbarkeit von Root-Servern über den Hostnamen "host.bind", der als TXT-Record den echten Namen des DNS-Servers liefert. |
<ihreProbeID>.atlas.ripe.net.62fda848ccd104d1 |
A |
Default |
Der Namen ist nicht auflösbar |
|
tOPoLogy4.DYndnS.aTlaS.riPE.nET |
A |
Default |
31.31.217.1 |
|
Es kann durchaus noch weitere DNS-Abfragen geben, die nicht während meiner Analyse passiert sind. Das ist aber nicht alles, denn neben TCP gibt es auch noch ein paar ICMP-Pakete, mit denen ein Traceroute gemacht wird.
Wenn Sie ihre Probe "öffentlich" machen, dann können natürlich auch andere Nutzer Tests zu anderen Gegenstellen konfigurieren.
Das Atlas-Backend stellt auch einige interessant Testgegenstellen bereit. So können Sie z.B. einfach eine variable Datenmenge per HTTP herunterladen
# HTTP-Antwort mit 5 Zeichen Invoke-Restmethod http://nl-ams-as3333-3.anchors.atlas.ripe.net/5 | fl # HTTP-Antwort mit 100 Zeichen Invoke-Restmethod http://nl-ams-as3333-3.anchors.atlas.ripe.net/100 | fl
- RIPE Altas: Built-in Measurements
https://atlas.ripe.net/docs/built-in-measurements/
Sicherheit und HTTP
Das könnte aber auch der Grund sein, warum die Probe by Default keine HTTP-Tests macht. Viele Atlas-Probes in Firmen werden vermutlich nicht in einem komplett separierten Subnetz stehen und haben daher "Nachbarn". Nun stellen Sie sich vor, dass ein Angreifer über geschickt definiert HTTP-URls quasi "von Innen" auf ihre Server oder Router zugreifen und einen Exploit ausnutzen kann. Dennoch sollten Sie auch die öffentlichen Informationen im Blick haben. Über die URL https://atlas.ripe.net/probes/<probeID>/#tab-network verrät die Probe natürlich nicht nur ihre externe IP-Adresse sondern auch ggfls. interne DNS-Server. Gateways etc.
Ich habe auf dieser Seite nicht genau darauf geachtet, die ProbeID unkenntlich zu machen. Sie können über das Atlas-Portal jederzeit nach Probes bei Providern oder an Orten suchen. "Security by Obscurity" ist nie ein guter Ratgeber. Die Probe sollte nicht von extern erreichbar sein und die Webservices beim RIPE dürften entweder genug Bandbreite und Rechenleistung haben oder DoS/DDoS-Filter nutzen.
API Abfragen
Nun sammeln ja die verschiedenen Probes überall Werte ein aber als Administrator möglich ich natürlich nicht täglich per Browser auf der Atlas-Webseite nach Diensten schauen. Dazu gibt es aber eine Atlas-API, über die ich die Abfragen automatisieren kann.
Einen API-Token brauchen Sie nur, wenn Sie Änderungen schreiben möchten. Zum Lesen von öffentlichen Werten reicht der anonyme Zugriff.
- Anonymous User
https://atlas.ripe.net/docs/apis/rest-api-manual/anonymous_user.html - API Keys
https://atlas.ripe.net/docs/apis/rest-api-manual/api_keys.html
InformatInformationen über eine Probe bekommen Sie einfach über eine REST-API. Die Daten genau einer bekannten Probe bekommen wir über die ProbeID.
Invoke-RestMethod https://atlas.ripe.net/api/v2/probes/<ihreProbeID>/
Interessanter sind natürlich Messwerte der eigenen Probe oder auch anderer Probes im Internet. Vielleicht betreibt ja ihr ISP eine Atlas-Probe oder sie finden eine Probe eines anderen Kunden beim gleichen ISP. Am einfachsten suchen Sie die Probe und den Messwert über das Portal, z.B. https://atlas.ripe.net/probes/<ihreProbeID>/#tab-builtins und übernehmen die unten rechts angezeigte URL. Zuerst hole ich mir die Checks:
Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/<ihreProbeID>" | ft Description, target,type,result description target type result ----------- ------ ---- ------ dns 150.100.6.8 150.100.6.8 dns https://atlas.ripe.net/api/v2/measurements/<ihreProbeID>/results/
Die "Result"-URL liefert dann die Details zu dem Test. Ich nutze dazu aber die folgende URL, welches mir die Ergebnisse liefert. Hier sind 452 Datensätze vorhanden. Sollten es über 500 sein, dann muss ich die folgenden Daten mit der unter "Next" mitgelieferten URL abrufen.
Das Property "quot; enthält die Ergebnisse und kann recht einfach als Tabelle ausgegeben werden:
(Invoke-(Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/?current_probes=<ihre ProbeID>&format=json").results ` | status,description,query_argument
Hier nur ein Anfang:
Je nach Probe-Type bekommen Sie weitere Werte und über die Parameter sind weitere Filter möglich, z.B. hier auf DNS-Checks
(Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/?current_probes=1007491&type=dns&format=json").results ` | ft type, status,description,query_argument type target timeout status description ---- ------ ------- ------ ----------- dns f.in-addr-servers.arpa 5000 @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for hostname.bind over I… dns f.in-addr-servers.arpa 5000 @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for in-addr.arpa over UD… dns f.in-addr-servers.arpa 5000 @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for in-addr.arpa over TC… dns f.in-addr-servers.arpa 5000 @{name=Ongoing; id=2; when=} Query f.in-addr-servers.arpa for version.bind over IP…
Leider habe ich noch keinen Weg gefunden, den Zeitpunkt der letzten Prüfung zu ermitteln oder über Filter nur die aktuellen Werte zu erhalten. Ich hatte gedacht, dass ich schnell mal die Werte in PRTG o.ä. überführen kann. Damit bleibt einzig der Status als Indikator übrig.
Quelle: REST API Reference : Measurements
https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements
Die Werte könnten wir aber schon z.B. durch PRTG abfrage abfragen und ins eigene Monitoring übernehmen lassen.
Bei meiner Probe sind aktuell keine Fehler zu sehen aber ich habe andere Probes gesucht. Aber selbst eine Probe, die schon über 1h Down ist, liefert immer noch den gleichen Status.
Der Status der Tests erscheint mir daher nicht sonderlich hilfreich.
Wenn Sie aber zu einer Probe die URL "https://atlas.ripe.net/probes/<IhreProbeID>#tab-builtins" aufrufen, dann sehen Sie nicht nur die Bilder sondern unten Rechts auch eine URL
Diese URL erlaubt ihnen den Download der Zahlenreihen zu einem Messpunkt einer Probe samt Filterung nach Zeit. Dazu muss ich mir natürlich erst einmal die "Measurements" holen. In meinem Fall:
$measurements=invoke-restMethod "https://atlas.ripe.net/api/v2/probes/1007491/measurements" count : 453 next : https://atlas.ripe.net/api/v2/probes/1007491/measurements?page=2 previous : results : {@{id=1014622; type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1014622/}, @{id=1040113; type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1040113/}, @{id=1040120; type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1040120/}, @{id=1040122; type=Measurement; measurement=https://atlas.ripe.net/api/v2/measurements/1040122/}…}
Als Ergebnis bekomme ich aber nur die ID des Measurements und eine URL aber keine weiteren Details. Über die URL kann ich mit dann Die Details dazu holen
Invoke-RestMethod "https://atlas.ripe.net/api/v2/measurements/1014622/" ` | fl description,type,protocol,query_argument,Status,result description : weekly resolve www.google.com type : dns protocol : UDP query_argument : www.google.com. status : @{id=2; name=Ongoing; when=} result : https://atlas.ripe.net/api/v2/measurements/1014622/results/
Mit der URL aus dem Feld "result" kann ich mir dann die Daten holen. Allerdings sollte ich dabei auf jeden Fall mit Filtern arbeiten, denn der "{pk}"-Wert (MeasurementID) beschreibt einen Check, der von bis zu 1024 Probes genutzt werden kann.
Create a RIPE Atlas ping measurement
using either the website or the API.
You may use up to 1,024 probes.
Quelle:
https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/status-checks.html#quick-start
Insbesondere die "Default Checks" sind entsprechend umfangreich. Ich sollte daher immer noch meine ProbeID mit als Filter vorgeben. Für einen einfache Test tut es die MeasurementID = 1, die ein Ping zum Default Gateway ist.
PS C:\> Invoke-RestMethod https://atlas.ripe.net/api/v2/measurements/1/latest/?probe_ids=1007491 dst_name : 192.168.100.5 dst_addr : 192.168.100.5 ttl : 64 sent : 3 rcvd : 3 dup : 0 min : 0,323 avg : 0,4143333333 max : 0,501 result : {@{rtt=0,501}, @{rtt=0,419}, @{rtt=0,323}} msm_id : 1 timestamp : 1707142867 size : 40 from : 217.91.247.140 msm_name : Ping type : ping fw : 5080 src_addr : 192.168.102.204 proto : UDP af : 4 prb_id : 1007491 stored_timestamp : 1707143030
- Latest Measurement Results
https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/latest.html#latest-measurement-results
Eine dritte Variante sind Statuschecks, die sich auf ein Measurement beziehen. Denken Sie daran, dass ein Measurement eine Messung auf eine konfigurierte Gegenstelle ist, die aber von mehreren Probes ausgeführt werden kann. Es ist daher keine einzelne Messung sondern eine Gruppe von mehreren Messungen, bei denen jede Messung einen eigenen Status haben kann.
# Status abfragen (Incinga/Nagio) Invoke-RestMethod https://atlas.ripe.net/api/v2/measurements/<pk>/status-check?permitted_total_alerts=1
All diese Daten sind natürlich auch für die Integration in ein eigenes Monitoring interessant.
Ich bin noch am experimentieren, wie ich welche Werte von RIPE ATLAS ich z.B. in PRTG übernehmen kann. Eine lokale PRTG-Probe kann viel mehr als eine Atlas-Probe und die von Paessler im Internet verteilten Cloud-Probes können auch von extern messen. Aber es gibt natürlich viel mehr Atlas-Probes und wenn der eigene ISP eine entsprechende Probe hat, dann können diese Daten schon eine Anreicherung darstellen.
- REST API Reference : Measurements
https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements - Atlas: Statuschecks: A Complex Example
https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/status-checks/complex_example.html - scripts_for_nagios_icinga_alerts
https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/scripts_for_nagios_icinga_alerts - Monitoring Integration Example: Icinga
https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/status-checks/monitoring_integration_example.html
Weitere Links
- What is RIPE Atlas?
https://atlas.ripe.net/docs/getting-started/what-is-ripe-atlas.html - Atlas: Create a new Measurement
https://atlas.ripe.net/docs/getting-started/user-defined-measurements.html#creating-a-new-measurement - SoftwareProbe
https://atlas.ripe.net/docs/howtos/software-probes.html
https://github.com/RIPE-NCC/ripe-atlas-software-probe - RIPE Atlas
https://www.youtube.com/watch?v=Z3SW2vO8qW0 - Sponsoring RIPE Atlas
https://www.youtube.com/watch?v=_vud5tR_JnE - How to use Ripe Atlas Probes to monitor networks
https://www.youtube.com/watch?v=eEe76GNbR3A - RaumZeitLabor: RIPE Atlas Measurement Network & Probe
https://www.youtube.com/watch?v=xzg_Jq4aPpg - PRTG Takes Part in Big RIPE Atlas Project
https://blog.paessler.com/prtg-takes-part-in-big-ripe-atlas-project