Posts by dnsmichi

This forum was archived to /woltlab and is now in read-only mode.

    hmmm sieht alles ganz normal aus.


    aber ich wundere mich, warum du configure mit den mysql-libs mit /var/lib/mysql aufrufst. in /var/lib/mysql liegen die datenbanken an sich, nicht aber die libraries fuer mysql. die liegen in /usr/lib/mysql


    per default brauchst du das auch nicht angeben, debian/ubuntu findet das automatisch im normalfall.


    koennte sein, dass dort der hund begraben liegt.



    FALSCH

    Code
    1. ./configure --with-mysql-lib=/var/lib/mysql --with-mysql-inc=/usr/include/mysql


    RICHTIG

    Code
    1. ./configure --with-mysql-lib=/usr/lib/mysql --with-mysql-inc=/usr/include/mysql

    Naja gut, dann haben wirs aber in anderer Form auch als Argument, dass eine gewisse RDBM-Vielfalt laengst ueberfaellig ist ;-)


    Von unserer Seite aus ist Oracle als RRDBM gefordert, und meine Aufgabe ist es, genau das fuer die NDO/IDO zu betreuen bzw das Projekt weiter zu forcieren. Dementsprechend ist Icinga gerade richtig gekommen, denn die immer mehr Wegentwicklung der NDOUtils Oracle von NDO ist nicht unser Ziel, auch was Communityfeedback & Support anbelangt.


    Dies gilt natuerlich auch fuer andere RDBMs von anderen Leuten, die nicht nur MySQL verwenden koennen/wollen. Wo auch jeder herzlich eingeladen ist, die aktuelle Icinga-Version gegen die DB zu testen und Feedback zu geben im Bugtracker [1] oder auf den Mailinglisten [2] (oder auch hier im Forum auf Deutsch!).
    Allround-DB-Genies findet man selten, aber gemeinsam laesst es sich sicher leichter bewerkstelligen - und das sage ich jetzt unabhaengig von NDO/Nagios oder IDO/Icinga. Profitieren werden wir alle davon, egal welche bevorzugte Version dann letztendlich eingesetzt wird.


    lg
    Michi


    [1] https://dev.icinga.org/projects/icinga-core/issues
    [2] http://www.icinga.org/community/

    per default schreibts in debian nach /var/log/messages - nicht ins syslog.


    die error-msg deutet darauf hin, dass entweder die rechte auf der db nicht korrekt gesetzt wurden bzw das db-schema mit der table-structure broken ist.


    connecte mal in der shell auf mysql:



    und poste den output. alternativ kannst du das natuerlich auch mit phpmyadmin machen.


    lg
    Michi


    PS:
    hendrik  
    Das wird ein nettes Feature fuer Icinga IDOUtils, wenn die Fehlermeldung endlich sprechender wird :)

    Ist schön das die IDO jetzt auch (z.B.) Oracle unterstützt, aber seien wir doch mal realistisch wer bitte schön haengt denn an Nagios
    eine Power DB wie Oracle oder DB2 ( sofern letztere auch schon unterstützt wird) ???
    Da stehen doch die Anschaffungs und Wartungskosten doch in keiner Relation zum Produkt selbst.
    Also wir haben rund 500 Hosts mit rund 4000 Services und unsere MySQL langweilt sich immer noch.


    wie schon richtig erwaehnt wurde, ist es in Firmen gang und gebe, nur eine DB zu verwenden, wo sich KnowHow und Lizenzen bereits zusammengefunden haben. Fuer uns gibt es die Option "MySQL" nicht, sondern wir verwenden Oracle. Und benoetigen dahingehend eine stabile Version, die auch im produktiven Betrieb eingesetzt werden kann. Die Bemuehungen, die NDOUtils auch fuer Oracle fit zu machen, sind in einem eigenen "Fork" der NDOUtils gelandet, wenn du so willst.
    Ein Commit ins Master Repository waere natuerlich wuenschenswert, aber solange die Performance-Probleme der NDO nicht grundlegend geloest werden sowie diverse Bugs gefixed sind, macht auch dieser Merge keinen Sinn.
    Mit Bugs meine ich bspweise jenen, wo sich die NDO via segfault verabschiedet und Nagios mitreisst - passiert bisweilen, und die Errorlogs sprechen nicht fuer sich. Bei Icinga sehe ich dagegen das Potenzial, durch Ressourcen-"Joins" diese Bugs schnellstmoeglichst zu bereinigen und durch einen abstrahierten DB-Layer auch die Unterstuetzung fuer eine breitere Auswahl an RDBMs anzubieten.
    Es wird ein wenig tricky werden, vor allem, was die nicht-normalisierten SQL-Queries und den Housekeeper betrifft, aber solange diese erste Loesung kompatibel zu Nagios bleibt, sollte es fuer niemanden das grosse Problem sein, bei einer Stable Version operativ auf Icinga mit zB IDOUtils Oracle/Postgre umzusteigen (auch mit Migrierung bestehender Datensaetze).


    Ich frage mich warum muss es gleich ein ganzer Fork sein ? Haette es nicht gereicht wenn man alternative Pakete angeboten/entwickelt haette die die Missstaende
    (ich weiss NDO ist ein Missstand)


    Der groesste Missstand an der NDO ist die stehende Entwicklung seit mehr als einem Jahr - Minor bugfixes im Repository sollten doch darauf hindeuten, dass es schoen langsam aus der Betaphase herauskommt. Entweder plant Ethan eine geheimnisvolle Neuprogrammierung der NDO oder es gibt andere Plaene. Aber darueber zu schweigen halte ich nicht fuer gut, und wenn man eine DB-Anbindung benoetigt, moechte man auch nicht unbedingt eine "Beta" operativ auf der Running Stage einsetzen (was man zur Zeit leider muss und die Probleme die auftreten, kosten dann wieder viele Mannstunden...).


    Dementsprechend halte ich es fuer ein absolutes NO-GO der Community gegenueber (und auch dem Produkt Nagios as is, das auch mit DBs arbeiten kann), dass man hier auf der Stelle tritt. Es gibt auf der Mailingliste bereits sehr viel Input (users + devel abonnieren!), Vorschlaege, Diskussionen und das hilft bereits sehr viel, wenn ichs mal so formulieren darf. Dass es auf englisch ist, bedient sich eben der Tatsache, dass jeder mit jedem kommunizieren koennen sollte.


    Nichtsdestotrotz denke ich, dass wir mit Version 0.8.2 auch die groebsten Probleme der IDOUtils beseitigen werden sowie die "most-favorite RDBMs" auch angebunden werden koennen.


    lg
    Michi

    dann solltest du doch die "beta" installieren, in produktivem betrieb funktionierts, auch wenn du dir diverse performance-tweaks hier im forum ansehen solltest (broker options, table-indizes, db trimming der history - die eh fast keiner braucht, etc).


    oder du wartest noch ein wenig und guckst dir icinga mit den idoutils an, wo das direkt beim hauptinstall integriert sein wird (optional).

    grundsaetzlich - ndoutils installieren und zb mysql db verwenden. wo diese db dann liegt, ist egal, kann auch als backend fuer den webserver dienen (und ndo schreibt remote hin), wo dann das iphone die webseite davon aufruft.
    bei den event_broker optionen nicht -1 verwenden sondern nur die wirklich benoetigten informationen zusammenaddieren (gibts im forum genug tipps zur ndo).


    zwecks auswertung kannst du dir imho selbst eine kleine query basteln, die dir die benoetigten informationen aus der db holt. vorsicht vor dem db-schema, du brauchst schon einige joins, bis du wirklich alle informationen rausholen kannst.


    in die where clause nimmst du dann nagios_servicestatus.current_state != 0 auf, womit du alle services bekommst die nicht in ordnung sind. bei den joins kommts halt drauf an, welche informationen du dann effektiv brauchst.


    orientieren kannst dich dabei wie eh schon geschrieben an diversen tools, mir gefaellt adhoc das nagincidents vom code her sehr gut ;-)

    also wenn man sich wirklich durch die wichtigsten passagen durchkaempft (das blabla zu den trademarks usw kann man sich eh sparen) und den ersten artikel ganz unten liest, dann ist die entwicklung als aeusserst interessant zu bewerten.


    dass nagios.org nicht mehr bei klick auf nagios-addons auf nagiosexchange etc verlinkt, ist ja schon laenger so. aber jetzt erst draufzukommen, dass man damit die community schmaelert und auch kunden veraergert, die erst recht wieder alles zusammenklauben muessen (nagios an sich, plugins, google, blabla), ist schon etwas komisch. so gesehen ist der fork auch der einzig richtige ansatz. zum einen, um die nagios-entwickler wachzuruetteln und zum anderen, um neue wege zu beschreiten. mir persoenlich ist es egal, ob jetzt netways die boesen trademarkverletzer sind oder sonst etwas, denn schliesslich muss ja jeder irgendwie seinen vorteil daraus ziehen koennen. und mannstunden kosten nunmal geld, das auch bezahlt werden muss.


    bezueglich der community-"idee" von ethan ist es ein wenig sonderbar, neue subdomains zu delegieren.


    http://community.nagios.org/20…where-do-we-go-from-here/

    Vor allem der aktuelle Text spricht doch Baende, wie wenig die Community bis dato beachtet wurde und jetzt soll sie ploetzlich die Gestaltung eines Bugtrackers oder einer Ideensammlung maintainen.

    Quote

    This site is waiting to be built by the Nagios community.

    Ich bin gespannt, ob da noch mehr kommt, auch in der Hinsicht, dass jetzt Andreas Ericsson mit von der Partie ist.


    GitWEB: http://git.icinga.org/
    Tracker: http://dev.icinga.org/ ==> icinga-core Projekt
    Pure GIT: git clone git://git.icinga.org/icinga-core.git


    sehr fein, danke.


    der branch ist natuerlich sehr interessant:
    https://git.icinga.org/index?p…e61d205f8ce34be853f35bd3b


    und wenn ich mir https://git.icinga.org/index?p…e61d205f8ce34be853f35bd3b so ansehe, dann haben wir mit char *ndo2db_db_rawtablenames[NDO2DB_MAX_DBTABLES] eine auch fuer oracle-taugliche loesung, denn ohne table_prefix ist die laengste table genau 30 zeichen lang, was auch oracle max erlaubt.


    betrachtet man den table_prefix weiter, gibts in der config den neu definierten. dh wenn man alt und kompatibel bleiben moechte, muss man den wieder auf nagios aendern.
    https://git.icinga.org/index?p…ba07ed4d83acad5072a83f964
    oder man passt sich die DB um den prefix selbst an. bei oracle wird der eh leerbleiben muessen, ausser man aendert das db-layout komplett.


    testen werde ich morgen dann.

    die geschichte mit dem ndo-db-schema stimmt schon, denn wenn man das schema fuer groessere netzwerke verwendet, kommt man irgendwann zu dem punkt, wo die queries nicht mehr skalieren, wenn die db voller und voller wird (der scheduled garbage collector funktioniert da dann auch nicht mehr).


    davon abgesehen wurden damals bei den ndoutils oracle auch schon tablenamen verkuerzt, da oracle nicht mit zu langen tablenames umgehen kann. dementsprechend waere ein ansatzweise redesign der datenbank im entwicklungsstadium der ido doch sehr angenehm. man kann immer noch patches bauen, die die datenbank dann entsprechend anpassen per script. aber ich denke, das werde ich mich mit hendrik noch genauer besprechen, denn oracle hat schon viele eigenheiten, ueber die man noch stolpern kann.


    lg
    Michi

    Die Ausgelieferten IDOUtils werden bereits eine DB Abstraktionschicht (libdbi.sourceforge.net) beinhalten.
    Da wird sich zeigen müssen, ob es die richtige Entscheidung war, da diese library nicht bei allen Distributionen als Paket aus den offiziellen Repos verfügbar ist.
    Es könnte sich als Sinnvoller erweisen, es den Anwendern zu zumuten für sich selbst, die libdbi inkl. der spezifischen DB Treiber zu kompileren, dafür aber die IDO auf den entsprechenden DB Systemen wirklich laufen lassen zu können, ohne vom Codedevelopment abhängig zu sein.


    vielleicht aendert sich die verteilung in die repositories, wenn die libdbi in einem grossen projekt ihren platz findet. bezugnehmend auf die ndoutils und den ndoutils oracle ist dieser schritt sicherlich in die richtige richtung gesetzt worden, da man fuer die db-vielfalt doch einen abstrahierten layer benoetigt, um den code der idoutils nicht unnoetig kompliziert zu machen.
    wenn man sich deinen commit in den ndoutils vom 19.4. (iirc) ansieht, wo die libdbi umgesetzt wird und dann ein diff zur vorigen revision macht, sieht man doch sehr deutlich, dass durch die libdbi alles viel klarer und anschaulicher wird.


    http://git.nagiosprojects.org/…f7622a275eb928e55963d73b2


    Ob die Anwender aber generell gewillt sind, diesen Schritt zu gehen wird sich zeigen müssen - da will Icinga ja aber den offenen Diskussionen nicht im Wege stehen, also: Time will tell.


    sofern man genuegend faqs und manuals bereitstellt im vorfeld, sollte es kein problem darstellen, libdbi mit mysql auf einem standardsystem umzusetzen. die idee von libdbi kommt ja urspruenglich von der perl-dbd/dbi wo es ein derartiges interface ja schon laenger gibt und das auch sehr intuitiv verwendbar ist.


    Auch wenn die Homepage von libdbi nativ kein Oracle anbietet, so habe ich schon Unkenrufe gehört, dass es dort eine Lösung geben soll. Wenn der besagte Kontributor hier mitliest - ich werde noch auf deine Mail antworten, versprochen! Ein Tracking Item habe ich dazu auch schon gesehen, bist also nicht verloren gegangen.


    sollte er nicht mitlesen? hier ist doch die beste anlaufstelle fuer offizielle fragen und news ;-) was die libdbi und oracle betrifft, werde ich mich darin vertiefen und es auf unserem testsystem mit oracle-db umsetzen/ausprobieren, sofern sich eine praktikable loesung ergibt. entsprechende updates oder spezifischere diskussionen verlagern wir aber ins mailtechnische :-)


    lg
    Michi

    na endlich tut sich wieder was, klasse idee ... :thumbup:


    bez. der ndoutils und neuem ndo aka ido ... wer wird denn das in zukunft maintainen bzw ansprechpartner sein? ich nehme mal stark an der hendrik so wie jetzt schon passiert mit dem umbiegen auf die libdbi. waere interessant, das endlich auch fuer mehr datenbanken aufzubauen, vornehmlich in meinem fall oracle :-)


    insofern "cat ndoutils oracle >> icinga_ido2db" =)

    hi,


    gibts eigentlich neben dem im git vorhandenen commit der ndoutils [1] mit dem umbau auf libdbi konkrete plaene, fuer welche datenbanken das dann einsetzbar sein soll? soweit ich recherchiert habe, sind die libdbi bzw die libdbi-drivers so weit fortgeschritten, dass mysql, postgre, etc vollstaendig unterstuetzt werden, fuer oracle gibt es noch keine ordentliche loesung.


    dies waere vor allem dahingehend interessant, um vielleicht die ndoutils oracle [2] endlich vollstaendig ins hauptprojekt committen zu koennen. ich habe dieses projekt vor 2 wochen erhalten und mich wuerde es sehr stark interessieren, inwieweit die zukunftsplaenebei ndoutils fortgeschritten sind bzw ob andurin in die richtung "neuer maintainer" geht ;-)


    lg
    Michi


    [1] http://git.nagiosprojects.org/…efs/heads/ndoutils-libdbi
    [2] https://www.nagiosforge.org/gf/project/ndoutils_oracle/