UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

Network Monitoring

Informationen über Docker, Verwaltung mit portainer und VMs
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
alexbeer
Reactions:
Beiträge: 394
Registriert: Mi Sep 12, 2018 1:11 am
Wohnort: NRW
Hat sich bedankt: 212 Mal
Danksagung erhalten: 251 Mal

Network Monitoring

#1

Beitrag von alexbeer »

Hallo,
Hat hier schon jemand eine Network Monitoring Lösung auf dem TWS im Einsatz?
Ich wollte das schon immer Mal ausprobieren, habe es aber immer wieder verdrängt, weil ich keine passende Hardware im Einsatz hatte.
Einige Admin-Kollegen sind sehr von Check_MK angetan. Es gibt davon auch einen fertigen Docker - Container: https://mathias-kettner.de/cms_introduction_docker.html
Auf dem TWS bietet es sich ja geradezu an.
Sobald mein TWS eingezogen ist, steht dies für mich auf der TODO Liste.

VG Alex
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit

exkanzler
Reactions:
Beiträge: 112
Registriert: So Feb 17, 2019 5:10 pm
Wohnort: Münsterland
Hat sich bedankt: 379 Mal
Danksagung erhalten: 57 Mal

#2

Beitrag von exkanzler »

Hi,
da check_mk im Hintergrund analog zum Wiregate mit RRDs arbeitet und das WebGUI sehr altbacken aussieht, solltest Du Dir vielleicht etwas moderneres anschauen. 8-)
Da wir ja schon die Kombination Grafana + InfluxDB auf dem Wolf laufen haben, habe ich selber Prometheus im Auge. Da kann man nämlich die Metriken in InfluxDB schreiben und Grafana für die Anzeige nutzen.
Wann ich mich damit aber beschäftigen kann, kann ich leider nicht sagen.

Stefan & Co haben gute Vorarbeit geleistet mit der Wahl der Softwarekomponenten. :bow-yellow:

Gibt auch nen Docker Image. Unklar ob dies auch auf den Hutschienenmodellen läuft, sonst gibt es auch Downloadpakete für ARM.
https://prometheus.io/download/

Gruß
Andreas
Gruß
Andreas
----------
timberwolf272 | 950Q (VPN offen + reboot nach Rückfrage)

Ersteller
alexbeer
Reactions:
Beiträge: 394
Registriert: Mi Sep 12, 2018 1:11 am
Wohnort: NRW
Hat sich bedankt: 212 Mal
Danksagung erhalten: 251 Mal

#3

Beitrag von alexbeer »

Hi,
danke für den Tip Prometeus - klingt definitiv interessant.
MIt den technischen Details habe ich mich ehrlicherweise noch nicht beschäftigt. Per Mund-zu-Mund-Propaganda wurde nur die hohe Flexibilität beim Monitoring von diversen Hosts gelobt.

In der Doku habe ich i.Ü. auch die Möglichkeit gefunden, nach Graphite / InfluxDB zu exportieren: https://mathias-kettner.de/cms_graphing ... aphing_api
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit

James_T_Kirk
Reactions:
Beiträge: 309
Registriert: Do Sep 13, 2018 10:54 pm
Hat sich bedankt: 99 Mal
Danksagung erhalten: 120 Mal

#4

Beitrag von James_T_Kirk »

exkanzler hat geschrieben: Sa Mär 02, 2019 10:56 pm da check_mk im Hintergrund analog zum Wiregate mit RRDs arbeitet und das WebGUI sehr altbacken aussieht, solltest Du Dir vielleicht etwas moderneres anschauen.
Hier muss ich mich kurz einklingen, weil ich das nicht so stehen lassen möchte. Ich administriere bei mir an der Arbeit das check_mk System mit über 300 Hosts / 13.000 Services und mir ist in 19 Jahren IT Erfahrung noch kein System untergekommen was sich so einfach und zeitgleich sehr sehr flexibel und mächtig einsetzen lässt. Es mag jetzt nicht das ideale System fürs Homelab (wobei es auch fertige special Agents für z.B. Fritzbox und Synology) mitbringt, im KMU und Enterprise Umfeld kenne ich aber nichts besseres. Es werden viele moderne Techniken (Azure, AWS, Docker, Kubernetes) unterstützt und was nicht fertig dabei ist kann man selbst erweitern (Shell/Python Kenntnisse benötigt). Eine solche Offenheit bringt kaum ein Hersteller mit. Die Daten lassen sich auch in eine Influx DB schicken.
Die GUI gibt es auch in schick (gelb/schwarz statt grün/grau um es schnell erkennbar zu machen), lässt sich seit 05/2018 umschalten. Richtig Spaß macht die Kostenpflichtige EE Version, die freie CE hat ein paar technische und optische Einschränkungen. Für kleine Netze mit weniger als 10-20 Hosts reicht die aber auch.
TWS 950Q 435 verkauft, umgestiegen auf Home Assistant

exkanzler
Reactions:
Beiträge: 112
Registriert: So Feb 17, 2019 5:10 pm
Wohnort: Münsterland
Hat sich bedankt: 379 Mal
Danksagung erhalten: 57 Mal

#5

Beitrag von exkanzler »

Danke für die Ergänzungen/ Klarstellungen. Wir nutzen Check_MK auch auf Arbeit für etwas mehr als 3.000 Server/VM/Netzgeräte. Im Enterprise Umfeld gebe ich Dir Recht.
Mir wurde von unseren Spezis aber gesagt, dass der Export nach InfluxDB (Graphite Protokoll) nur zusätzlich zu den RRDs möglich ist und zur Zeit auch keine Abkehr von den RRDs vom Hersteller geplant ist. Was ich persönlich schade finde, aber wohl eine Grundeinstellung von MK ist.

Zitat von https://mathias-kettner.de/cms_graphing ... aphing_api
Der Check_MK Micro Core kann alle Messdaten zusätzlich an eine (ab Version 1.2.8 sogar mehrere) Datenbank weiterleiten, die das Protokoll von Graphite unterstützt. Neben Graphite selbst hat z. B. die InfluxDB eine derartige Schnittstelle.
Aber gerade beim Timberwolf mit SSDs reduziere ich damit die Lebensdauer dieser je nach Nutzung / Umfang der Metriken dramatisch, da ich die Daten leider zweimal schreiben muss.

Deshalb würde ich persönlich eher eine andere Lösung präferieren, wenn alles auf dem Wolf laufen soll.

Gruß
Andreas

PS:
RRDs lassen sich wohl auch in Grafana einbinden.
https://qiita.com/atfujiwara/items/58cda0dbe44b1e03ac7f
Gruß
Andreas
----------
timberwolf272 | 950Q (VPN offen + reboot nach Rückfrage)

Dante
Reactions:
Beiträge: 157
Registriert: So Aug 12, 2018 10:42 am
Hat sich bedankt: 8 Mal
Danksagung erhalten: 78 Mal

#6

Beitrag von Dante »

Man könnte aber auch testen, ob man das Schreiben in die RRDs einfach ins Nivana jagt. Symlink auf /dev/null, Datei schreibschützen o.ä. Damit entfällt die Last auf die SSD. Ist nur fraglich, ob Check_MK sauber weiterläuft, wenn solche Maßnahmen getroffen werden.
Viele Grüße,
Thomas

timberwolf146 / Timberwolf Server 2500 Indian Gold + PBM / Version 1.6.0 IP3 (Wartungs-VPN offen / Reboot jederzeit möglich)

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#7

Beitrag von StefanW »

Hallo zusammen,

wir verwenden für das Monitoring der Systeme unserer Enterpreise-Kunden (anderer Geschäftsbereich) ebenfalls Check_MK und machen damit gute Erfahrungen. Ich bin aber nicht direkt damit beschäftigt, daher kann ich darüberhinaus nichts wissenswertes beitragen.

RRDs sind - in meinen Augen - zwar eine sehr bewährte und robuste aber auch eine veraltete Form der Zeitreihenaufzeichnung.

Vorteile der RRD:
  • IMHO immer noch der Standard, daher auch in vielen Produkten eingesetzt
  • Absolut ausgereift und sehr robust
  • Durch laufende Verdichtung kein Zuwachs der Datenmenge, damit ist Speicherplatz gut planbar
  • Es gibt etliche Tools dazu

Nachteile der RRD:
  • Starre Zeittakte. Mehrere Werte pro Intervall werden gemittelt. Damit ist keine Aufzeichnung boolscher Werte möglich (zumindest nicht mit einer Auflösung von wenigen Sekunden)
  • RRDs skalieren schlecht, ab ein paar hundert RRDs steigt die Prozessorlast immer stärker an, da (im Allgemeinen) bei jedem dritten bis zehnten Wert (das hängt von der Einstellung der RRAs und der Verdichtungsstufen ab) kommt es zu einem kompletten Umrechnen auch der dahinter liegenden RRAs. Damit werden eigentlich schon abgelegte Werte nochmals gelesen, ein Mittelweert gebildet und der Mitelwert in die nächste RRA geschoben, wo das gleiche nochmal passieren kann. Das bedeutet, viele Schreib- und Lesevorgänge wegen einem hinzugekommenen Wert (wenn auch nicht bei jedem)
  • Durch diesen Effekt auch hohe Schreib (eigentlich Löschbelastung) von SSD, Eine Influx schreibt einfach kontinuierlich weiter, die alten Werte werden nicht mehr angefasst, außer man stellt dort auch eine Verdichtung ein, aber dort passiert nicht dieser "umrollieren".
  • Keine SQl-Abfrage möglich, damit insgesamt weniger flexibel
Trotzdem sind wir Tobias Oetiker dankbar für RRDtool, MRTG, Smokeping usw. weil das damals das beste und einfachste war, das es gab und Millionen von Admins über zwei Jahrzehnte (im Juli) begleitet hat.


Aber mit der Zeit kommen neue Herausforderungen und die werden mit der Influx sehr viel besser gemeistert.

lg

Stefan
Zuletzt geändert von StefanW am So Mär 03, 2019 11:37 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

jockel
Reactions:
Beiträge: 424
Registriert: Mo Aug 13, 2018 6:31 pm
Hat sich bedankt: 192 Mal
Danksagung erhalten: 147 Mal

#8

Beitrag von jockel »

Ich betreibe hier zu Hause eine check_mk Installation in einer VM und finde es auch für das Heimnetz nicht schlecht, auch wenn es da sicher mehr Spielerei als wirkliche Notwendigkeit ist.

Wegen der Lebensdauer der SSD würde ich mir wegen ein paar RRDs keine Sorgen machen, die verbaute von Samsung dürfte eine Endurance von 70-150TB haben, je nach Größe. Selbst wenn da am Tag 100 MB zusätzlich geschrieben wird (was zu viel sein dürfte), bewegt man sich nach 15 Jahre in der Größenordnung von 1% der Endurance.

Wichtiger dürften da die Mountoptionen noatime/nodiratime sein, da gehe ich aber unbesehen davon aus, dass Elabnet das sinnvoll gesetzt hat.
TWS 2500 ID: 145 + 1x TP-UART + 2x DS9490R, VPN geschlossen, Reboot nach Absprache / wiregate198 (im Ruhestand)

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#9

Beitrag von StefanW »

jockel hat geschrieben: So Mär 03, 2019 12:13 pm...die verbaute von Samsung dürfte eine Endurance von 70-150TB haben, je nach Größe.
Sogar deutlich mehr, weil wir verbauten die nerere Generation 860 Evo und dort wurden die Endurance gegenüber davor verdoppelt.

Endurance der von uns verbauten SSD (Desktop-Server):
  • 32 GB Transcend: 45 TBW / 1,5 Mio Std MTBF
  • 64 GB Transcend: 80 TBW / 1,5 Mio Std MTBF
  • 250 GB Samsung: 150 TBW / 1,5 Mio Std MTBF
  • 500 GB Samsung: 300 TBW / 1,5 Mio Std MTBF
  • 1 TB Samsung: 600 TBW / 1,5 Mio Std MTBF
Der Hutschienenserver dürfte sogar auf eine Endurance (da pSLC) von gut 480 TBW kommen.

jockel hat geschrieben: So Mär 03, 2019 12:13 pmSelbst wenn da am Tag 100 MB zusätzlich geschrieben wird (was zu viel sein dürfte), bewegt man sich nach 15 Jahre in der Größenordnung von 1% der Endurance.
Richtig, eher weniger.

Trotzdem muss man es in größeren Szenarien drauf achten. Im Enterprise Umfeld mit womöglich minütlichen Intervallen bei 1000 RRDs käme man geschätzt* auf 11.5 GB am Tag, mithin auf 4 TB im Jahr und 63 TBW in 15 Jahren. Da muss die Platte dann groß genug sein und auch den anderen Betrieb stemmen. Allerdings gibt es für das Enterprise Umfeld auch noch bessere SSD.

*Ich schätze, dass im Durchschnitt pro hinzugefügtem Datum etwa zwei 4k Blöcke neu geschrieben werden müssen.

jockel hat geschrieben: So Mär 03, 2019 12:13 pmWichtiger dürften da die Mountoptionen noatime/nodiratime sein, da gehe ich aber unbesehen davon aus, dass Elabnet das sinnvoll gesetzt hat.
Jep, selbstredend.

lg

Stefan
Zuletzt geändert von StefanW am So Mär 03, 2019 5:56 pm, insgesamt 2-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Antworten

Zurück zu „Docker, portainer, VM“