Das längste Thema

  • Naja ein Agent ist jetzt nix verwerfliches. Wenn dir WMI / SNMP abschmiert stehst du auch am Ende da. Beim Verbiegen der Strukturen gebe ich dir allerdings recht.

  • Ich möchte mich hier nochmal kurz bezüglich des Monitor-Threads zu Wort melden. Gegen Kritik haben wir überhaupt nichts. Viele Punkte hatten wir bereits auf unserer ToDo-Liste - woran auch schon gearbeitet wird. Allerdings hört bei uns konstruktive Kritik auf, wenn man bewusst ein Produkt schlecht redet ohne es überhaupt getestet zu haben. Wenn es dann noch unter die Gürtellinie geht und beleidigend wird "klinken" wir uns aus.


    Wir stehen noch am Anfang und einige wichtige Features wie z.B. custom Checks fehlen noch. Aber daran wird bereits gearbeitet. Vielleicht hätte ich den Thread erst in 2-3 Wochen erstellen sollen, wenn die letzten wichtigen Features implementiert sind und wir ggf. auch schon eine hosted Version zum testen hätten anbieten können. Naja, man lernt nie aus...

  • wenn ma am zum monitorenden System was installieren muss,

    um es dann in ein Monitoring "einzuhängen" hat man bereits was falsch gemacht;

    Worin besteht da das Problem? Ein Agent kommt lokal an alle Infos, die über das Netzwerk nicht zugänglich wären. Bei Icinga gibt es einen Check der prüft ob alle Agents verbunden sind. Plus man kann getrenntes Monitoring aufsetzen, dass prüft ob das Monitoring ansich läuft.

  • Worin besteht da das Problem? Ein Agent kommt lokal an alle Infos, die über das Netzwerk nicht zugänglich wären.

    genau da ist der Knackpunkt, wie würdest denn am Monitoring System mitbekommen, dass z.B.

    - eine Festplatte sich verabschiedet

    - die CPU überhitzt

    - ein Prozess amok läuft und CPU/RAM blockiert

    wenn auf Grund eines Netzwerkproblems die Verbindung zwischen Agent und Monitoring unterbrochen ist?
    in dem Fall würd einem das Monitoring System mitteilen,

    dass der Server xy nicht erreichbar ist, aber das würd man ohne Agent auch wissen ;)


    Failure by Design?:/

  • wenn auf Grund eines Netzwerkproblems die Verbindung zwischen Agent und Monitoring unterbrochen ist?

    in dem Fall würd einem das Monitoring System mitteilen,

    dass der Server xy nicht erreichbar ist, aber das würd man ohne Agent auch wissen ;)


    Failure by Design?:/

    Ohne Netzwerkverbindung wird aber kein Alarm die Maschine verlassen… Ich habe keinen Zugriff auf das Hostsystem um extern ne Box mit SMS Versand etc. anzuschließen. Sind ja auch Rootserver.


    Immerhin weiß man, dass etwas auf der Maschine nicht stimmt. Aus der Summe der Meldungen kann man dann schon anfangen den Fehler zu suchen. Sollte der Agent abrauchen kriege ich das gemeldet, sollte das Netz abrauchen dito. Und alle anderen Fehler meldet das Monitoring.

  • genau da ist der Knackpunkt, wie würdest denn am Monitoring System mitbekommen, dass z.B.

    - eine Festplatte sich verabschiedet

    - die CPU überhitzt

    - ein Prozess amok läuft und CPU/RAM blockiert

    wenn auf Grund eines Netzwerkproblems die Verbindung zwischen Agent und Monitoring unterbrochen ist?:/

    Und wie bekommst du diese Dinge mit, wenn du auf einen client verzichtest?

  • Und wie bekommst du diese Dinge mit, wenn du auf einen client verzichtest?

    ich weiß worauf Du hinauswillst, wobei:

    beim 3ten Beispiel würde der Agend Dir auch was husten, wenn der Amokprozess den Agent selbst ausbremst, oder?

    bei virtuellen Servern jucken eigentlich diverse Dinge überhaupt nicht, weil sie nur f. den Hostbetreiber relevant sind;


    ich halte es einfach so, ist er erreichbar, passt alles,

    ist er es nicht, gibts ein Problem, welches ich möglicherweise gar nicht beheben kann;


    es gibt Dinge, die kann man wissen, sprich welche der Agent liefert, jucken aber nicht, wenn man sie nicht weiß;

    Paul 'ne Glaskugel gehört zum alltäglichen Geschäft; sagte bereits der Albert damals: "je mehr Du weißt, desto mehr weißt Du nicht"

    (od. war der Ausspruch von jemand anders)


    ist wie mit der Haustür, mich juckt es nicht wer davor steht, wenn er sich nicht vorher angemeldet hat, lass ich ihn einfach stehen;:D

  • ich halte es einfach so, ist er erreichbar, passt alles,

    ist er es nicht, gibts ein Problem, welches ich möglicherweise gar nicht beheben kann;

    Das ist aber auch Professionalitätslevel Kinderzimmerhoster.


    Ein Agent reported nicht erst dann, wenn es zu spät ist, sondern wenn ein Ausfall droht. Zumindest wenn du die Schwellwerte richtig konfigurierst. Das beste Beispiel ist da das Thema Dateisysteme. Nehmen wir mal an, da läuft etwas Amok und schreibt dir das Dateisystem voll - wenn du da bei sagen wir 80% Auslastung Bescheid bekommst, kannst du ggf. noch durch Anpassung von Configs o.Ä. die Reißleine ziehen und einen Ausfall verhindern. Wenn dir dann bei 100% Füllstand die Datenbank einfriert und du auf einmal keinen Connect mehr hinbekommst, und es dann erst merkst... na da ist das Kind doch schon in den Brunnen gefallen.


    Ferner kannst du, je nach eingerichteten Checks, mit Agents auch Logs überwachen, Fehlerraten in der Datenverarbeitung berechnen und auswerten usw.


    Dieses Mindset "Och wir lassen es im Fall des Falles erstmal vor die Wand fahren und dann schauen wir mal, wenn es gar nicht mehr geht." ....

    Wie wenig Anspruch an sich selbst kann man denn als Admin haben? Davon bekomme ich Ausschlag und Anfälle. Und Bluthochdruck. Und andere schlimme Dinge...

  • Ein Agent reported nicht erst dann, wenn es zu spät ist, sondern wenn ein Ausfall droht.

    unter der Voraussetzung es läuft alles, gebe ich Dir Recht; ;)

    aber einen Ausfall des Netzwerks od. gar ein Blackout hat noch kein Agent vorher gemeldet ...^^

    Und das ist ja eigentlich auch der hauptsächliche Sinn des Monitoring. :)

    bei echtem physischem Blech hat es schon was, vorher Bescheid zu bekommen,

    dass z.B. eine Platte kurz vor dem Ausfall ist;:)


    whoami0501 es hat hier weniger mit Kindergarten und so zu tun, sondern eher mit: was will man und was braucht man;

    mir genügt das tägl. 'logwatch'-Mail;


    ich unterstelle halt, dass die Monitoring Agents nicht weniger oder mehr fehlerfrei/-anfällig sind wie alles andere auch;

    und im worst case es nicht ausgeschlossen ist, dass derartiges selbst ein Einfallstor darstellt; hat ja auch schon Antiviren gegeben,

    welche bestimmte Schadsoftware erst ermöglichten 8o

  • ich unterstelle halt, dass die Monitoring Agents nicht weniger oder mehr fehlerfrei/-anfällig sind wie alles andere auch;

    exakt - je nach Reife der Anwendung und der installierten Prozesse ist das Risiko für Angriffe über irgendwelche Monitoring Agents größer als der Nutzen. Klar ist's schön, gemeldet zu bekommen, daß die Platte bald voll ist oder CPU dauerhaft auf >90% - aber, Hand aufs Herz: Wie häufig kommt diese Meldung BEVOR der Admin das eh schon gemerkt hat?

    Hatte auch schon den Fall, daß das Monitoring mir einen SUN Server lahmgelegt hat - das ist aber schon Jahrzehnte her, da war irgendwas mit ping Paketen, die das Betriebssystem lahmlegen konnten.

    Keep it simple kann auch heißen, das Monitoring auf das Notwendigste einzuschränken und einfach zu halten.

    Und jetzt wegducken und Popcorn holen, das Geschnattere wird lustig.

  • Also bei einem kleinen Bash-Skript, welches lediglich mit Userrechten läuft und auf große Abhängigkeiten verzichtet, passiert sowas nicht. Und das ein Bösewicht sich über meinen ausgehenden POST via cURL auf das System schalten kann würde ich dann doch live sehen wollen bevor ich es glaube ;)