Skip to main content

IPlogger mit DB-Unterstützung (iplogger-db.sh)

IPlogger, Debian (+Derivate)
Wiki-Stand: 12.05.2026
Script-Stand: 12.05.2026

Download

IPLogger DB – IP- und Verfügbarkeitsüberwachung

Überblick

Der iplogger-db.sh ist ein datenbankgestützter IP-Logger zur dauerhaften Überwachung der eigenen Internetverbindung und der öffentlichen WAN-IP-Adresse.
Das Script wurde dafür entwickelt, langfristig und nachvollziehbar festzuhalten:

  • welche öffentliche IP-Adresse zu welchem Zeitpunkt aktiv war
  • ob eine Internetverbindung vorhanden war
  • ob lediglich die IP-Ermittlung fehlgeschlagen ist
  • welche Prüfdienste funktioniert oder versagt haben
  • wie lange einzelne IPs aktiv waren
  • wann Provider oder Verbindungen ausgefallen sind

Der Fokus liegt nicht auf einer simplen „Wie ist meine IP“-Abfrage, sondern auf einer historisch nachvollziehbaren Langzeitaufzeichnung mit Auswertung und Zeiträumen.

Das System arbeitet vollständig datenbankbasiert und speichert jede einzelne Messung dauerhaft ab.

Ziel des Systems

Der Logger beantwortet unter anderem folgende Fragen:

  • Welche öffentliche IP war am 12.03.2024 um 14:00 Uhr aktiv?
  • Wie lange blieb eine bestimmte IP bestehen?
  • Wann erfolgte ein DSL-/WAN-Reconnect?
  • War die Leitung tatsächlich offline oder nur ein Prüfdienst gestört?
  • Welche Provider lieferten fehlerhafte Antworten?
  • Welche DNS-/Connectivity-Ziele waren erreichbar?
  • Wie oft kam es zu Unterbrechungen?
  • Wie stabil arbeitet die Internetanbindung?

Gerade bei:

  • DSL-Zwangstrennungen
  • CGNAT-/Providerwechseln
  • VPN-/Tunnelproblemen
  • Routingfehlern
  • sporadischen Ausfällen
  • Providerstörungen

liefert die Historie eine klare technische Nachvollziehbarkeit.

Architektur

Das System besteht aus mehreren Komponenten:

KomponenteAufgabe
providersÖffentliche IP-Abfragedienste
connectivity_checksPrüft, ob Internet grundsätzlich erreichbar ist
stateSpeichert Rotationszustände
iplogHistorische Hauptdatenbank
summary_*Auswertung und Zusammenfassung
PDF-/CSV-ExportArchivierung und Dokumentation

Grundlogik

Der Ablauf einer Messung sieht vereinfacht so aus:

1. Connectivity prüfen
2. Wenn Internet vorhanden:
3. Öffentliche IP ermitteln
4. Ergebnis speichern
5. Statistiken aktualisieren

Wichtig dabei:

Das Script unterscheidet sauber zwischen:

ZustandBedeutung
OFFLINEKeine Internetverbindung
CHECK_FAILEDInternet vorhanden, aber IP nicht ermittelbar
OKIP erfolgreich ermittelt
INVALID_RESPONSEProvider lieferte ungültige Antwort
NO_RUNReservierter Status

Dadurch wird verhindert, dass ein einfacher Fehler eines einzelnen IP-Dienstes fälschlich als Internetausfall interpretiert wird.

Initialisierung

Einstiegspunkt: init

./iplogger-db.sh init

Dieser Befehl erstellt die komplette Datenbankstruktur.

Dabei werden automatisch angelegt:

  • Tabellen
  • Standardprovider
  • Connectivity-Ziele
  • Rotationsstatus

Datenbanktabellen

providers

Enthält alle IP-Ermittlungsdienste.

Standardmäßig:

  • icanhazip.com
  • ifconfig.me
  • api.ipify.org
  • checkip.amazonaws.com

Gespeichert werden zusätzlich:

  • Erfolgszähler
  • Fehlerzähler
  • letzter Erfolg
  • letzter Fehler
  • Timeoutwerte

Beispiel:

NameURL
icanhazip.comhttps://icanhazip.com
api.ipify.orghttps://api.ipify.org

connectivity_checks

Prüft die generelle Internetverfügbarkeit.

Standardmäßig:

  • Google DNS (8.8.8.8)
  • Quad9 (9.9.9.9)
  • Cloudflare (1.1.1.1)

Die Prüfung erfolgt per Ping.

state

Speichert interne Rotationsinformationen.

Dadurch wird nicht immer derselbe Provider zuerst verwendet.

Beispiele:

NameWert
next_provider_index2
next_connectivity_index1

iplog

Die zentrale Historientabelle.

Hier wird jede Messung dauerhaft gespeichert.

Gespeichert werden unter anderem:

  • Messzeitpunkt
  • öffentliche IP
  • Status
  • verwendeter Provider
  • Anzahl Versuche
  • Fehlermeldungen
  • Rohantworten
  • Connectivity-Status

Rotationssystem

Warum Rotation?

Würde immer derselbe Provider zuerst verwendet werden:

  • wäre dieser stärker belastet
  • Fehler würden schwerer auffallen
  • andere Provider würden kaum genutzt

Deshalb arbeitet das System rotierend.

Beispiel

Durchlauf 1

1. icanhazip.com
2. ifconfig.me
3. ipify

Durchlauf 2

1. ifconfig.me
2. ipify
3. icanhazip.com

Durchlauf 3

1. ipify
2. icanhazip.com
3. ifconfig.me

Dadurch verteilt sich die Last gleichmäßig.

Connectivity-Prüfung

Einstiegspunkt: check oder run

./iplogger-db.sh check

oder:

./iplogger-db.sh run

Beides startet dieselbe Messlogik.

Ablauf der Connectivity-Prüfung

Vor der eigentlichen IP-Ermittlung wird geprüft:

  • besteht überhaupt Internet?
  • ist Routing vorhanden?
  • funktionieren externe Ziele?

Dazu werden mehrere bekannte Ziele angepingt.

Erst wenn mindestens eines erreichbar ist, wird die IP-Abfrage gestartet.

Provider-Prüfung

Nach erfolgreicher Connectivity-Prüfung:

curl -> Provider -> Antwort validieren

Dabei wird geprüft:

  • ist die Antwort leer?
  • ist die Antwort eine gültige IPv4?
  • ist die Antwort eine gültige IPv6?

Nur dann gilt der Durchlauf als erfolgreich.

Beispielabläufe

Erfolgreicher Lauf

Connectivity OK
Provider erreichbar
IP gültig
→ Status OK

Gespeichert wird beispielsweise:

2026-05-12 22:00:00
IP: 93.192.117.44
Status: OK

Internet vorhanden, aber Provider kaputt

Connectivity OK
Provider liefert Müll
→ CHECK_FAILED

Beispiel:

Provider https://api.example liefert:
ERROR 500

Das Internet funktioniert trotzdem.

Komplett offline

Google DNS nicht erreichbar
Cloudflare nicht erreichbar
Quad9 nicht erreichbar
→ OFFLINE

Summary-System

Das eigentliche Kernstück ist die Verlaufsanalyse.

Einzelne Messungen werden zu Zeiträumen zusammengefasst.

Einstiegspunkt: summary

Tabellenansicht

./iplogger-db.sh summary tabelle

Beispiel:

BEGIN_AT           END_AT             IP               SAMPLES OFFLINE FAILS
2026-05-01 10:00  2026-05-03 02:00   93.192.117.44         91       0     0

Textansicht

./iplogger-db.sh summary text

Beispiel:

01.05.2026 10:00 Uhr - 03.05.2026 02:00 Uhr:
IP 93.192.117.44 (91x online)

Wie die Periodenerkennung funktioniert

Die Funktion summary_rows() analysiert die komplette Historie.

Sobald sich die IP ändert:

alte Periode schließen
neue Periode beginnen

Zusätzlich werden innerhalb der Periode gezählt:

  • Offline-Ereignisse
  • Fehler
  • erfolgreiche Samples

Detailmodus

Einstiegspunkt

./iplogger-db.sh summary export pdf details

Der Detailmodus erzeugt eine vollständige Zeitauflistung aller erfolgreichen Messungen innerhalb einer Periode.

Beispiel

16.02.2020 05:00 Uhr - 16.02.2020 11:00 Uhr:
IP 93.192.117.44 (24x online)

- 16.02.2020 05:00 06:00 07:00 08:00
- 16.02.2020 09:00 10:00 11:00

Oder bei Tageswechsel:

07.02.2021 04:00 05:00 06:00
08.02.2021 00:00 01:00 02:00

Dadurch werden lange Zeiträume kompakt lesbar dargestellt.

PDF-Export

Einstiegspunkt

./iplogger-db.sh summary export pdf

oder:

./iplogger-db.sh summary export pdf details

Der Export erzeugt automatisch:

  • TXT-Zwischendatei
  • PDF-Datei
  • Überschrift
  • Datum
  • Seitenzahlen

Verwendet werden bevorzugt:

  • enscript
  • ps2pdf

Alternativ:

  • pandoc

 

CSV-Export

Einstiegspunkt

./iplogger-db.sh summary export csv

Exportiert die zusammengefassten Perioden in maschinenlesbarer Form.

Beispiel:

begin_at;end_at;ip;samples;offline;fails
2026-05-01 10:00;2026-05-03 02:00;93.192.117.44;91;0;0

Historischer CSV-Import

Einstiegspunkt

./iplogger-db.sh import ipdb.csv ";"

Der CSV-Import dient primär zur Übernahme historischer Daten aus der ersten Generation des IPLoggers.

Dabei werden ältere Aufzeichnungen in die neue Datenbankstruktur übernommen.

Unterstützt werden:

  • erfolgreiche IPs
  • Offline-Einträge
  • Fehlerzustände

Typische Einsatzszenarien

WAN-Reconnects nachvollziehen

IP 1:
01:00 - 12:00

IP 2:
12:05 - aktuell

→ DSL-Zwangstrennung klar sichtbar.

Providerprobleme erkennen

15x CHECK_FAILED
aber keine OFFLINE-Zustände

→ Internet vorhanden, aber IP-Dienst gestört.

VPN-/Tunnelprobleme analysieren

Wenn:

  • Connectivity vorhanden
  • aber bestimmte Ziele nicht erreichbar

kann nachvollzogen werden:

  • wann Routingprobleme begannen
  • wie lange sie bestanden
  • ob WAN-Wechsel beteiligt waren

Besonderheiten

IPv4 und IPv6

Das System akzeptiert beide Varianten automatisch.

Zeitbasierte Rotation

Provider und Connectivity-Checks werden nicht statisch verwendet.

Das verhindert:

  • Single-Point-Abhängigkeiten
  • einseitige Last
  • verfälschte Statistiken

Dauerhafte Historie

Die Datenbank arbeitet append-only.

Neue Einträge werden ausschließlich ergänzt.

Dadurch bleibt die komplette Historie nachvollziehbar erhalten.

Beispiel für Cronjob

0 * * * * /srv/scripte/iplogger-db.sh check >/dev/null 2>&1

Dadurch erfolgt stündlich eine neue Messung.

Fazit

iplogger-db.sh ist kein einfacher „Wie ist meine IP“-Checker, sondern ein vollständiges Langzeit-Überwachungs- und Auswertungssystem für:

  • öffentliche WAN-IPs
  • Internetverfügbarkeit
  • Providerstabilität
  • Fehleranalysen
  • historische Zeiträume
  • dokumentierbare Verbindungsverläufe

Besonders wertvoll wird das System durch:

  • die periodische Zusammenfassung
  • die saubere Statusunterscheidung
  • die rotierenden Prüfmechanismen
  • die nachvollziehbare Langzeithistorie
  • die Exportfunktionen für Archivierung und Dokumentation

 

💾 Download

Das Programm kann hier in immer der neuesten Version heruntergeladen werden:

IPlogger Script (via mariobeh.de)

 

Back to top