Seite wählen

1500 Cisco Switches mit Trafficgraphen für 10000 Ports

von | Jun 4, 2009 | Kunden, Nagios

check_interface_table_v2Wir haben für einen Kunden, der hier leider nicht namentlich genannt werden kann, eine hochverfügbare Monitoringlösung implementiert, die sich sehen lassen kann.
Im Rahmen des Projektes ist eine integrierte Nagios- / NetwaysGrapher- / Nagviz- Umgebung entstanden die das Handling der Netzinfrastruktur erheblich vereinfacht und das Administratorenteam so bei der Arbeit unterstützt.
Mittels nmap, SNMP und der Möglichkeiten des Cisco Discovery Protocol (cdp neighbors) werden die configs incl. der Parentbeziehungen sowie der Hostgroups (vtp-domain) automatisch generiert. Gute Arbeit Christian! 😉
Für die Überwachung der Switches wurde das check_interface_table.pl Plugin erweitert und individualisiert.
Die auf Statusänderungen zu Überwachenden Ports können via regular expression ausgewählt und warning sowie critical Schwellen für Auslastung angegeben werden. Darüber hinaus liefert das Plugin nun Performancedaten für den Grapher und linkt direkt auf den Trafficgraphen (in der Tabelle hellgrün hinterlegt).
Die Zusammenarbeit hat beiden Seiten viel Spass gemacht und wir freuen uns auf ein baldiges Wiedersehen. Vielleicht für die Integration des NetwaysGrapherV2.

7 Kommentare

  1. Christian Richter

    Hallo Birger,
    jetzt werd ich aber rot 😉 Danke nochmal für deine super Arbeit und
    Unterstützung auch nach dem Projekt…
    Gruss Chris

    Antworten
  2. Birger Schmidt

    Wie gesagt, war mir ein Vergnügen! Nicht nur die Arbeit, sondern auch die kulinarischen Genüsse und kulturellen Aktivitäten (ich hätte nie gedacht dass Spock was mit Uhura hatte).

    Antworten
  3. Christian

    Bezieht sich eure individuelle Erweiterung des Plugins auf die Auswertung des Traffic? Oder ist das mit der Standardversion des check_interface_table.pl realisiert worden?

    Antworten
  4. Birger Schmidt

    So ist es. Die Traffic Auswertung ist mit der alten GPL Version nicht möglich. Nun aber mit der neuen check_interface_table_v2.pl Version.

    Antworten
  5. David Knecht

    Hallo Birger
    In der Überschrift zu Deinem Beitrag schreibst Du, dass Du mit check_interface_table.pl (bzw. inzwischen ev. mit check_interface_table_v2.pl) 1500 Switches überwachst und dabei Trafficgraphen für 10000 Ports erstellst.
    Gehe ich recht in der Annahme, dass Du hierfür mit einer verteilten Nagios-Umgebung mit mehreren Nagios-Kollektoren arbeitest? Mich interessiert natürlich auch, wieviele Switches und Ports Du mit einer einzigen Nagios-Instanz überwachst und welche Hardware-Specs ein solches Nagios-System aufweist.
    Besten Dank schon mal für Deine Infos.
    David

    Antworten
  6. Birger Schmidt

    Nein, das ist tatsächlich nur eine (allerdings geclusterte) Nagios Installation. Soweit ich mich erinnere eine 8 Kern Maschine mit 16 Gig RAM. Die steht dabei auch ganz gut unter Dampf.
    Aber wir haben inzwischen bei anderen Kunden ein sehr viel schnelleres in C geschriebenes Plugin im Einsatz, dass sich bisher nur auf Cisco Hardware versteht.
    Das findet sich bisher nur in unserem git. Der Blog Artikel dazu kommt später.
    https://www.netways.org/repositories/browse/plugins/plugins/snmp_interface_check
    Gruß,
    Birger

    Antworten
  7. David Knecht

    Hallo Birger
    Erstmal herzlichen Dank für Deine Auskunft! Ich habe da allerdings noch eine Anschlussfrage, die auch wieder die Skalierung in einer grossen Umgebung betrifft. Ich hoffe, ich missbrauche Deinen Blog damit nicht!
    a) Gesetzt der Fall, ich konfiguriere die „check_interface_table.pl“ und „snmp_interface_check“ Nagios Service-Checks so, dass *ein einziger* Nagios Service-Check *mehrere* Interfaces eines einzigen Routers/Switches überwacht. Wenn nun ein solches Interface down geht, wechselt der Service-Check vom Status „normal“ in den Status „critical“ und ich erhalte eine Notification zugemailt. So weit, so gut. Wenn nun aber ein zweites Interface down geht, ändert sich der Service-Status insgesamt nicht, er bleibt „critical“. Als Folge dessen erhalte ich keine Notification zu diesem zweiten Down-Event. Wenn eines dieser beiden Interfaces nun wieder hochkommt, wird ebenfalls keine Notification versandt, weil der Service-Status wegen des anderen Down-Interfaces nach wie vor „critical“ ist.
    b) Falls ich dennoch über den Status jedes Interfaces mittels Notifikation korrekt informiert werden möchte, müsste ich meines Erachtens für jedes einzelne zu überwachende Interface einen eigenen Service Check konfigurieren. Aber: Performt das denn auf dem Nagios-System???
    Ich stelle diese Anschlussfrage wieder vor der Perspektive von ca. 1500 zu überwachenden Switches bzw. 10000 zu überwachenden Ports und frage mich, ob die beiden Umgebungen, die Du hier angesprochen hast (ich meine die „check_interface_table.pl“- sowie die „snmp_interface_check“-Umgebung), gemäss a) oder b) (oder ganz anders?) aufgesetzt sind.
    Danke nochmals! David

    Antworten

Trackbacks/Pingbacks

  1. Inhaltsverzeichnis Juni 2009 - Nagios, Live, Nordic, Kassel, Meet, Workshop, Weekly, Twitter - NETWAYS Blog - [...] Live vom Nordic Meet on Nagios: syslog-ng Live vom Nordic Meet on Nagios: Nagios on Red Hat 1500 Cisco…

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Kunden | Nagios

Happy New Year 2023

"Alles, was anders ist, ist gut." So sagt es zumindest Phil Conners im 90er-Jahre Klassiker "Und täglich grüßt das Murmeltier". Wenn ich ehrlich bin, hätte ich das Anfang dieses Jahres auch gedacht, denn es schien als würden wir COVID-19 langsam in den Griff kriegen...

Der NETWAYS Support Collector

Dem ein oder anderen unserer Support Kunden ist unser neuer Support Collector vielleicht schon über den Weg gelaufen. Aber was ist das überhaupt? Und was bringt er? Der NETWAYS Support Collector ist eines unserer neuesten Kreationen. Inspiriert von, dem mehr...