Pinned Feature List + Planning + Wishlist

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • In Planning + Wishlist (unsorted list):

    • Rewrite of Bloonix to Python 3
    • Trend Monitoring
    • Capacity Monitoring
    • Evaluation / prediction of bottlenecks
    • Network weather map
    • Heuristic checks
    • Mobile App
    • Centralized Logging (like logstash)
    • Metric processing daemon (like carbon)
    • Translation of the documention into English (bloonix.org)
    • Host View Dashboard
    • LDAP Auth

    • Agent Installer for other Operating Systems
      • Solaris
      • FreeBSD
      • HP-UX
      • AIX
      • Windows

    • Packaging for
      • Arch Linux
      • armhf (Raspbian/arm)

    Notice: SNMP or Nagios Plugins can be used, but my wish is to develope Bloonix Plugins for all operating systems and applications!

    • Plugins for operating systems (CPU, Memory, Network, ...)
      • Solaris
      • FreeBSD
      • HP-UX
      • AIX
      • Windows

    • Plugins for applications, system checks
      • Oracle
      • DB2
      • MSSQL
      • VMware
      • OpenStack
      • Microsoft IIS
      • MongoDB
      • RabbitMQ
      • Samba
      • Network Security Scans
      • Tomcat
      • Browser Page Speed
      • Hardware RAID Checks for different Controllers
      • Elasticsearch
      • Cassandra
      • Java Applications
      • iptables
      • Quotas
      • Filesum checks (Filechange/Rootkit detection)

  • Weil ich hier gerade Raspbian sehe - ich habe auf einem Raspi mit minibian letztens den Bloonix Satellite erfolgreich installiert bekommen (normale Debian sources verwendet) - sogar in Docker (auf ARM). Evtl funktionieren da Dinge bereits einfach, worth a try.

    Fragen zu IPtables: Was soll da überwacht werden? Ich hab grad ein Plugin für Shorewall auf der TODO List, da wollen wir accounting foo überwachen. Ich dachte noch ein ein Plugin welches prüft, ob die Firewall überhaupt geladen ist (via shorewall status). Nun ist das halt shorewall und nicht nur iptables. An was hattet Ihr da gedacht?

    Fragen zu filesum checks: Ala ein simples md5deep, welches als Argument ein path-to-file mit hashes bekommt (wenn ja sowas läuft länger als 60 sec), oder sowas wie chkrootkit (das läuft auch länger).
    Beides müsste man ggf in einem Cronjob ausführen und den Output in ein File speichern + im Plugin parsen, denke ich. Was meint Ihr?

    Network Security Scans find ich spannend. Ich dachte ein simpler nmap check wäre geil. Derzeit hab ich auf dem Schrim, ein Plugin für die cli vom ssllabs check zu bauen - und dann einfach die Result-Note, z.B. "A" oder "A+" zu parsen. Das sollte tun für den "advancteren SSL Check". Vllt noch nen Link zur SSLlabs ergebnis page im Plugin Output. Auch neat fande ich es, das mit in den HTTP Check zu werfen, so wie das Traceroute, welches man dort dazu klicken kann.
    Nmap kann halt viel wenn der Tag lang ist. Ich dachte z.B. an einen portscan von außen, wobei nur port 80 und 22 offen sein dürfen o.ä.

    Und noch eine Frage zu Bloonix Py: Wenn der Rewrite durch ist, funktionieren die pl Plugins weiter + es ist geplant, Plugins weiterhin in pl zu bauen - und wenn ich mich recht erinnere, ist es auch gar nicht geplant, Plugins dann in py zu bauen? So ähnlich hatte ich das in Erinnerung, wie war das nochmal genau?
    A service is only a service if its monitored.

    The post was edited 3 times, last by pthurner ().

  • pthurner wrote:

    Und noch eine Frage zu Bloonix Py: Wenn der Rewrite durch ist, funktionieren die pl Plugins weiter + es ist geplant, Plugins weiterhin in pl zu bauen - und wenn ich mich recht erinnere, ist es auch gar nicht geplant, Plugins dann in py zu bauen? So ähnlich hatte ich das in Erinnerung, wie war das nochmal genau?


    bloonix-plugin.py war das erste Modul, welches ich entwickelt hatte und ist schon seit Anfang 2016 fertig, aber ich weiß noch nicht ob ich es veröffentlichen werde.

    Der Grund meiner Bedenken ist, dass ich keine Insellösung schaffen möchte. Das Modul ist in Python 3.4 entwickelt und nur bedingt rückwärts kompatibel. Das ist auch leider der große Nachteil des ganzen Versionskrieges diverser Sprachen.

    Hier muss man auch stark unterscheiden zwischen Server und Client.

    Bei der Bloonix-WebGUI und dem Bloonix-Server, welche beide auf dem "Server" laufen, ist das alles kein Problem, denn da hat man gezielt Einfluss auf die Distribution und Softwareversionen (Perl/Python/Ruby/PHP/etc.). Aber sobald es in Richtung Client/Kunde (Bloonix-Agent + Plugins) geht, hat man da keinen Einfluss mehr drauf. Es gibt da draussen soviele legacy Systeme und unterschiedliche Distro-Versionen im Einsatz, dass man alles doppelt entwickeln/bauen müsste.

    AFAIK sieht es derzeit so aus:

    CentOS 5: Python2
    CentOS 6: Python2
    CentOS 7: Python3
    Debian Squeeze: Python2
    Debian Wheezy: Python2
    Debian Jessie: Python3

    Squeeze ist zwar seit Feb 2016 EOL, aber es gibt da draussen noch so viele Systeme, die man aus 1000 Gründen nicht so einfach auf Jessie upgraden kann. Will man solche Systeme aufgrund von inkompatiblen Plugins vom Monitoring ausschließen?

    In welcher Python Version soll man nun also den Agenten + Plugins entwickeln?

    Python 2? Vermutlich EOL in 2020
    Python 3? Was ist mit legacy Systemen?
    Python 4? Kommt ja bald, aber was ist mit legacy Systemen?

    Der Agent + Plugins sind in Perl 5 entwickelt und rückwärts kompatible bis Perl 5.8 (Linux 2.6). Und auch in den nächsten 10-20 Jahren wird Perl 5 noch auf allen Linux Distros verfügbar sein. Wenn ich also ein Plugin in Perl 5 entwickel, dann haben die Plugins ne lange Lebenszeit. Entwickel ich aber ein Plugin in Python 3 und es kommt der erste Kunde mit 1000 Systemen, die nur ein Python 2 haben, dann ist das total doof. Und der nächste kommt mit Python 4.... und letzten Endes hat man da Plugins für 3 verschiedene Versionen liegen.

    Ob viele nun Perl mögen oder nicht, die Sprache ist robust und rückwärtskompatibel bis ins Jenseits, das macht die Sprache für Client-Anwendungen so attraktiv. Ich liebe Python, aber die Sprache hat halt die Nachteile mit unsupporteten Versionen auf verschiedenen Distros.

    Zurück zur Insellösung: was ich total uncool fände wäre, wenn die einen Plugins in Python 2 entwickeln, die anderen in Python 3, dann kommt jemand mit Ruby Version X, der andere mit Ruby Version Y und so. Am Ende gibts einen Garten aus Plugins, die nur auf bestimmten Distros laufen. Ich bin von dieser Vorstellung nicht begeistert, denn am Ende gibts so nen Müllhaufen wie Nagios Exchange *SCNR* ;)