Hallo.
Ich habe dieses Problem auch schon im OPNSense-Forum gepostet (wo es vermutlich eher hingehört) aber vielleicht hat ja hier zufällig jemand eine Idee??!
Was nun?
Hallo @white_rabbit,
Die Meldungen die im oberen Screenshot sind, beziehen sich auf die Fehlerrate der eingehenden
Pakete fuer die Interfaces 02, 15 und 16. Die Standardeinstellung fuer die Fehlerrate bei Netzwerkschnittstellen ist relativ niedrig. Hier der entsprechende Regelsatz dazu:
Ich hatte in der Vergangenheit solcherlei Alarme bei manchen meiner AIX Maschinen: Es
stellte sich heraus dass Checkmk zwar “recht hatte”, das aber fuer mich - nachdem das mit unseren
Netzwerkjungs und -maedels ueberprueft wurde - kein Problem war. Nach Anpassung des Regelsatzes, war alles OK.
Gruesse,
Thomas
P.S.: Wenn mal Zeit da ist, ist evtl. dieser exzellente Blog-Beitrag bzgl. Netzwerkueberwachung von Interesse:
1 Like
Ich möchte nur betonen: Erst sollte man die Fehlerraten verstehen, dann ggf. erst die Schwellwerte anpassen, sofern sich diese Fehlerraten nicht abstellen lassen. Schwellwerte sollten nie als erstes angepasst werden. @openmindz hat das hier sehr schön richtig gemacht.
@openmindz: Kleine Randnotiz: Schreibst du bei deinen Links noch dabei, dass die 4 Rules für die 1.6 und die 3 Rules für die 2.0 sind? Nicht, dass da Verwirrung aufkommt, das habe ich nämlich schon gesehen.
Das hatte ich zwar schon gemacht (da ich mich selbst schon damit verwirrt habe…:)), ich hab aber
die Links nochmal anders formattiert damit man genauer erkennt, welcher Link wofuer ist.
Thomas
1 Like
Hi.
Danke für die Hinweise. Mittlerweile lichtet sich das Problem und es sieht danach aus, als sei tatsächlich ein neuer Treiber unter FreeBSD dafür verantwortlich, dass der jetzt haufenweise Fehler auswirft, die vorher nicht als solche eingestuft wurden. An der Hardware hat sich wie gesagt nichts verändert. Genaueres dazu steht im Nachbarforum.
In diesem Fall würde ich den Schwellwert unter checkMK tatsächlich etwas hochdrehen wollen, da die ständigen Warnungen schon nerven.
Ich versuche heute mal mein Glück … mal sehen.
@white_rabbit falls deine Daten nicht per Agent sondern per SNMP eingesammelt werden kannst ja auch mal das erweiterte Interface Error Plugin hier
von @thl-cmk ausprobieren. Das bringt dann ausführlich was wirklich an Fehlern so auftritt. Bitte die Hinweise beachten - denn Check nur aktivieren wo wirklich gebraucht da sonst jedes Interface einen zweiten Check erhält 
Sehe grad die Metrics Definition könnte einen Fehler bringen unter 2.0 ist noch 1.6.
Der Check selbst sollte tun, hat keinen Include oder so drin.
Die Daten kommen von der OPNSense per Agent … leider ist es aber ziemlich nervig, dass man nach jedem Update erneut die Schritte 5 bis 8 dieser Anleitung durchgehen muss. Das Problem ist hier allerdings nun OT…
In Sachen checkMK-Feintuning gibt’s für mich sicher noch viel zu lernen. Fast alles sind hier default-Einstellungen. Der erste Schritt dürfte für mich aber ein Ugrade von 1.6 auf 2.0 sein. Beim letzten Versuch bin ich da an irgendeiner Stelle gestolpert und habe es danach nicht nochmal versucht.
Vielleicht sollten wir erneut versuchen ob opnsense den Agenten nativ integriert. Hätte ich auch gerne.
1 Like
Hallo (@andreas-doehler)
Ich habe mittlerweile (endlich) das Update von 1.6 auf 2.0 gemacht … es war am Ende ja doch viel einfacher als befürchtet und alles läuft noch.
Was das Pakte iferrordetails.mkp angeht, das Du vorgeschlagen hast: Das würde ich für die betroffenen Interfaces schon ganz gerne ausprobieren (mkp install iferrordetails.mkp).
Allerdings weiß ich bisher nicht, wie/wo ich diesen Check global deaktivieren und dann nur für ein paar Interfaces aktivieren kann? Hast Du da noch einen Tipp für mich…
Danke und viele Grüße.
Das Plugin arbeitet nur mit SNMP Datenquellen. Wenn die OPNSense per Agent Daten liefern wird das leider nix.
Ansonsten für SNMP Daten kann der Check mittels “Disabled or enabled sections (SNMP)” erstmal Global deaktiviert werden. Die SNMP Sektion lautet hier auch “iferrordetails”.
Nach der globalen Regel kann man dann diese Sektion wieder für die Geräte aktivieren wo man den Check haben will.
Grundsätzlich ja. Aber ich habe jetzt keinen direkten Ansprechpartner bei OPNsense. Ich kann es aber ja mal versuchen.
2 Likes
@robin.gierse Wollt Ihr nicht mal da Hilfe anbieten? Die Umsetzung sollte für Euch super einfach sein.
@Doc das Thema ist mir untern Tisch gefallen. Ich rufe aber mal nochmal in die richtigen Kanäle, mal schauen, ob wir was tun können. Versprechen kann ich allerdings wie gehabt nichts.
Falls @os-s schon was erreicht hat, schreibt mich gerne mal direkt an, vielleicht lässt sich ja noch was koordinieren.
2 Likes
Hallo zusammen,
Ist das “Problem” mit den Error-Raten noch immer aktuell?
Falls ja:
- welche OPNsense Version?
- welche CMK-Version?
- welches Checkplugin?
Ich nutze auf meiner OPN (23.1.11) sowohl den CMK-FreeBSD-Agent als auch SNMP. Interfaces kommen via SNMP. Keine Probleme bei mir.
Schöne Grüße,
Marsellus W.
Hi Marcellus,
Welches Error Raten Problem?
Viele Grüße
Christian
@Doc
Ja, aber “was genau” wird/wurde denn da gewünscht?
Ich persönlich sehe für mich eine “Notwendigkeit”, etwas gegen die API zu machen, weil ich gerne die Interface-Namen als Items in den ServiceDescriptions nutzen wollen würde, und diese nicht via SNMP als ifAlias kommen.
Die API kann aber viiiiel mehr, nur was genau wird davon benötigt?
Jetzt antworte bitte nicht “alles!”, denn das Problem mit solchen Anforderungen kennen wir ja wohl alle selbst zu Genüge…
MfG,
Marsellus W.
Keine Ahnung.
Ich hätte gerne nativ den Agenten in OPNsense.
So wie den Metric Exporter für Prometheus als Plugin.
Und zwar so, dass der nicht nach einem Upgrade wieder weg ist.
Da müsste man wahrscheinlich nur nochmal mit OPNsense sprechen. Die Diskussion gabs da schonmal.
Dann noch sinnvolle Checkplugins rein und Checkmk ist das Mittel der Wahl für OPNsense User.