Performanceüberwachung ?

[Aiun]

hi,

ich suche einen "einfachen" weg eine Performanceüberwachung zu machen. Im wesentlichen CPU, Cache, Ram ... bla blub

soll nicht zu aufwendig sein, das kommt dann vielleicht im nächsten Schritt.

Ich habe auf einem Webserver mehrere Cronjobs laufen und müsste mal sehen wie stark die am System fressen und ob gleichzeitig andere Dinge möglich sind (Normaler Websitebesuch)

Am besten auch eine überprüfung, wieviele Anfragen in der Zeit an den Datenbankserver gesendet werden, damit ich auch prüfen kann ob die schwachstelle dort liegt.

diese Infos dann als Datei o.ä., damit ich sie per hand / php-script auswerten kann. - haupt Programmiersprache dabei ist php. Perl o.ä. nur ungern, zu wenige augen hier, die es warten / weiterentwickeln könnten falls nötig.

Rootrechte auf den Servern (Debian) sind nicht vorhanden !

[Schlaubi]

Hallo,

wie wärs mit einer regelmäßigen (cronjob) Ausgabe von top in ein Logfile, welches

Du dann auswerten könntest? Ansonsten fällt mir was "einfacheres" leider

nicht ein, sorry.

[RodNoc]

hmm.. CPU, RAM, etc überwachen kann man mit Hobbit. inwieweit root-rechte gebraucht werden weiß ich nicht, aber ich kann mich nicht erinnern irgendwas als root ausgeführt zu haben zu installation. Hobbit schreibt die Daten alle mit und stellt sie in einem webinterface grafisch dar.

SourceForge.net: Hobbit monitor

Gruß

Dom

[dr.disk]

Wenn's einfach sein soll habe ich bisher immer phpsysinfo bevorzugt: http://phpsysinfo.sourceforge.net/

Für Festplatten fand ich das hier immer ganz nett: http://martybugs.net/linux/hddtemp.cgi

Sobald's etwas größer werden darf/soll: http://www.nagios.org/

[Crush]

Ich hab in der letzten Zeit so etwas in der Art auch gebastelt, um Useraktivitäten aller Art, Logins, Umgebungsvariablen, Speicher, Prozesse, Serververfügbarkeiten, etc. mit zu loggen. Ich will damit allerdings in der Lage sein, zeitlich zu verfolgen, was der User oder der Rechner im Detail zu einem bestimmten Zeitpunkt hintereinander angestellt hat und nicht nur vordefinierte Alarmaktionen (wenn Prozeß x = "Name", dann Alarm = rot) abfragen.

Können der Hobbit, Big Brother oder irgeneins der anderen o.g. Programme das auch? Meines Wissens kann der kommerzielle Big Brother dies jedenfalls nicht.

[DocInfra]

Mit ein wenig Aufwand kann man MRTG verwenden, zumal sich MRTG auch mit Werten aus Skirpten usw. füttern lässt. Hier mal ein Beispiel wie man sowas machen kann. Die dort dargestellten Werte kommen per teilweise per SNMP, teilweise per Skript. Cacti wäre auch noch eine Möglichkeit.

[dr.disk]

Ich hab in der letzten Zeit *snip*

Das klingt ja fast schon nach der totalen Überwachung Wäre da auditd vielleicht das passende für Dich?

[Crush]

MRTG und Cacti geben wieder nicht ausreichend Informationen her, wie ich sie benötige - aber danke trotzdem!

dr.disk:

Das klingt ja fast schon nach der totalen Überwachung

-> Genau!

Der Audit Daemon ist schon nah an dem dran, allerdings handelt es sich um mehrere Workstations (AIX kein Linux) stark unterschiedlicher Konfigurationen und CPUs, weshalb sich das Prog so wohl nicht einsetzen lassen würde. Außerdem scheint der mir die Filterung immer noch zu sehr von der Vorkonfiguration abzuhängen. Da kämen dann evtl. trotzdem immer noch zuviel unnötige Daten raus, die nur die Analyse stören oder einfach zu wenig, weil unvorhergesehene Prozesse nicht zur Kontrolle definiert wurden, aber ich werd´s mir auf jeden Fall mal anschauen.

Vielleicht wird mein Prog nie benötigt, aber eventuell halt doch. An sich habe ich das Ding ja schon zu 99% fertig. Es wird erstmal einfach alles in Logfiles geschrieben, die aber locker am Tag 50-100MB ausmachen können (im Sekundentakt wird geloggt). Der Witz war ein Analysetool, welches die auffälligen relevanten Aktionen dieser Daten einigermaßen schnell rausfiltert und in mehreren Screens die Zeitausschnitte korrekt zueinander einblendet, damit man dann "Schuldige" für Systemprobleme ausfindig machen kann.

Die Kontrolle würde übrigens erst noch von einer Sicherheitsabteilung abgesegnet werden müssen und alle User, die Zugang zu dem System haben, würden wir eventuell auch noch darüber informieren - ansonsten wäre es illegal. Ich will nicht explizit Personen damit kontrollieren, sondern Systemschwierigkeiten bestimmten Useraktionen zuordnen können, um diese zukünftig zu beseitigen, Fehlverhalten der Anwender irgendwie auszuschließen und alle notwendigen Komponenten für den Betrieb einer Spezialsoftware abzusichern.

Es besteht halt die Vermutung, daß Mitarbeiter des Kunden mehr oder weniger absichtlich versuchen den Betrieb zu stören und da langsam große Kosten und Konsequenzen angedroht werden mit dem Argument, die Software taugt nichts, halte ich eine solche Absicherung - auch als Beweismittel - nur für fair und recht. Wir sind uns halt in seeehr vielen Fällen sicher, daß der Kunde selbst die Störungen unnötig verursacht hat. Andererseits will man sich den Kunden auch nicht vergraulen - dem ich mal grundsätzlich nicht unterstellen will, daß er mit Absicht Störungen verursacht - und versuchen dessen unvorhergesehene "Störquellen" irgendwie währenddessen abzufragen, daß die Programme entsprechend darauf reagieren können. Ein wenig Fingerspitzengefühl ist da schon angesagt.

Erschwerend ist es vor allem, daß mehrere Programme in einer Prozesskette ineinander greifen und ein Problem meistens nicht eindeutig erkennbar ist wie ein fehlender Rechner im Netz, sondern dann das ein oder andere Programm einfach verstummt und nicht mehr reagiert und z.B. auf Nachrichten oder Lizenzen anderer Programme einfach wartet und diese - wieso auch immer - nicht erhält. Außerdem sind die kommunizierenden Rechner/Netze zum Teil quer in Deutschland verteilt und können evtl. in späteren Projekten weltweit verstreut sein - dann wird die Fehlersuche noch schwieriger.

An sich ist so ein Logger-Programm nichts Dummes um in komplexen Systemen herauszufinden, ob Programmfehler tatsächlich nur von einer Software abzuleiten sind oder durch externes Wirken hervorgerufen werden. Das muß ja nicht erst zum produktiven Einsatz herausgefunden werden, auch als "Debugtool" ist es gar nicht so schlecht, sowas in der Tasche zu haben. Ich bin aber schon überrascht, daß es dafür bis jetzt doch relativ wenig zu diesem Thema gibt... ist das evtl. sowas wie eine Marktlücke?

[dr.disk]

@crush:

Kommt mir irgendwie bekannt vor.

Ich selbst hab auditd noch nie benutzt, bin jetzt das erste mal bei OpenSuSE 10.2 bewußt darüber gestolpert. Ob der überhaupt unter AIX läuft - weiß es nicht.

Das letzte mal wo ich an einer Softwareentwicklung mitgearbeitet habe wo wir solche Probleme hatten, hat die Software ein ausführliches Protokoll geschrieben und eine Historie in der Datenbank geführt. In der Historie werden sämtliche Felder der Datenbank gespeichert welche sich geändert haben. Folgende Werte also: Tabellennamen, Feldnamen, alter Wert, neuer Wert, Benuzter welcher ändert und das aktuelle Datum. Das Protokoll war zum eben mal schnell sichten ganz ok, meistens war die Historie unser "Freund und Helfer". Also der Nachweis, wer was wann getan hat.

Ist die Software von Euch? Dann baut doch eine Historie oder Logs ein. Ansonsten bieten aber auch viele Programme bereits die Möglichkeit ausführliche Logs zu schreiben. Um was für Programme würde es sich denn handeln? Nur für das Verständnis und um das Problem besser greifen zu können.

[Crush]

Das Programm verwendet:

1.) Datenbank (Oracle)

2.) Ein PDM-System

3.) Ein Web-Interface, um Aufträge in die Pipeline zu schieben und 4/5 zu steuern

4.) Ein Tool, welches die Daten PDM-gerecht aus dem PDM-System liest und bereit stellt

5.) Ein anderes Datenimporttool, welches PDM-gerecht die Daten zurückführt ins System

5.) Ein Datenqualitätsprüfungstool

6.) Ein Datenkonvertierungstool

7.) Ein Lizenzserver

9.) Ein Programm, welches die Steuerung der Datenflüsse/Aufträge aller Tools übernimmt -> das ist das "scheinbare" Problemtool, weil es halt zentral alles handhabt, immer wieder auf den ein oder anderen Vorgang warten muß und dadurch zwangsläufig bei Problemen hier irgendwo "hängen" bleibt.

10.) Das System ist nicht zentral, sondern die Rechner des gesamten Systems sind über mehrere Städte verteilt. Es gibt mehrere komplette Umgebungen, die ein solches System darstellen. Dabei kann es übrigens Rechnerüberschneidungen geben, die also mehrere Systeme parallel bedienen.

Die Aufträge kann man übrigens auch von Hand einsteuern, wobei Überschneidungen mit dem automatisierten System riskante Aktionen sind. Von Hand dürfen viele unterschiedliche Leute gleichzeitig ins System eingreifen und zwischengelagerte Aktionen anstoßen -> hier hat es schon sehr oft geknallt.

Interne Programm-Logs sind schon drin und werden auch soweit möglich genutzt, man hat aber leider nur auf wenig Elemente innerhalb dieses Systems direkten Einfluß um diese Logs alle parallel auszuwerten, außerdem fallen soviel Daten an, daß diese schwer zu analysieren sind - indirekte Aktionen von Usern , die sich auf die Programme auswirken oder Systemstörungen sind hier nicht erkennbar.

Ich bin eigentlich nur dazugerufen worden, um mich ins gesamte System an sich und das Programm 10.) als Notfall-Backup (3rd level Support) einzuarbeiten und dem Krisenstab bei der Systemabsicherung und Fehler-/Problemstellensuche zu helfen.

Das hilft Dir hoffentlich, die Komplexität des Problems etwas näher vorstellen zu können. Hilfe erwarte ich im Forum ja nicht, da selbst die größten Köpfe aus den teilhabenden Konzernen und Firmen offensichtlich nicht genug Überblick über deren eigene Kreationen und Fehler haben.

[dr.disk]

@crush

Das klingt ja schon fast nach "touching a never running system"... PDM, hat das was mit Grafik zu tun? Das einzigste was mir gerade dazu einfällt ist das "Point Distribution Model".

Naja, wünsche Dir auf jeden Fall viel Erfolg bei Deiner Suche!

[Crush]

Wikipedia erklärt das besser als ich: PDM, PLM & EDM.

[Aiun]

danke erstmal für die guten Antworten

Ich werde wohl ein phpscript tipseln das mir die wesentlichen Daten aus Top rausholt. Im moment ziehe ich testweise Top komplett in ein Logfile. Aber ich will die Datenmenge begrenzen, top insgesamt ist ja mehr als nötig.

phpsysinfo sieht auch nicht schlecht aus, vielleicht probiere ich auch das mal.

[dr.disk]

Bei top kann man aber auch angeben was er überhaupt ausgeben soll - das sollte die Datenmenge beschränken.

phpsysinfo ist jedoch sehr leicht installiert. Falls das also reicht, warum das Rad ein zweites mal erfinden?