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
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
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
-
- 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
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
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
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
-
- Reactions:
- Beiträge: 112
- Registriert: So Feb 17, 2019 5:10 pm
- Wohnort: Münsterland
- Hat sich bedankt: 379 Mal
- Danksagung erhalten: 57 Mal
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.
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.
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
da check_mk im Hintergrund analog zum Wiregate mit RRDs arbeitet und das WebGUI sehr altbacken aussieht, solltest Du Dir vielleicht etwas moderneres anschauen.
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.
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)
Andreas
----------
timberwolf272 | 950Q (VPN offen + reboot nach Rückfrage)
-
- Reactions:
- Beiträge: 394
- Registriert: Mi Sep 12, 2018 1:11 am
- Wohnort: NRW
- Hat sich bedankt: 212 Mal
- Danksagung erhalten: 251 Mal
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
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
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
-
- Reactions:
- Beiträge: 309
- Registriert: Do Sep 13, 2018 10:54 pm
- Hat sich bedankt: 99 Mal
- Danksagung erhalten: 120 Mal
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
-
- Reactions:
- Beiträge: 112
- Registriert: So Feb 17, 2019 5:10 pm
- Wohnort: Münsterland
- Hat sich bedankt: 379 Mal
- Danksagung erhalten: 57 Mal
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
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
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
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.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.
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)
Andreas
----------
timberwolf272 | 950Q (VPN offen + reboot nach Rückfrage)
-
- Reactions:
- Beiträge: 157
- Registriert: So Aug 12, 2018 10:42 am
- Hat sich bedankt: 8 Mal
- Danksagung erhalten: 78 Mal
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)
Thomas
timberwolf146 / Timberwolf Server 2500 Indian Gold + PBM / Version 1.6.0 IP3 (Wartungs-VPN offen / Reboot jederzeit möglich)
-
- 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:
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:
Nachteile der RRD:
Aber mit der Zeit kommen neue Herausforderungen und die werden mit der Influx sehr viel besser gemeistert.
lg
Stefan
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
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.
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.
-
- Reactions:
- Beiträge: 424
- Registriert: Mo Aug 13, 2018 6:31 pm
- Hat sich bedankt: 192 Mal
- Danksagung erhalten: 147 Mal
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.
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)
-
- 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:
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
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.
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.
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.