RAM Nutzung loggen

  • Moin,

    wie logge ich am Besten die RAM Nutzung über einen längeren (Wochen) Zeitraum?

    Wäre sar auf der Konsole verfügbar, würde ich mir einen simplen Cron-Job anlegen. Bevor ich anfange, Eigenlösungen zu stricken, wollte ich mal in die Runde fragen, welchen Ansatz ihr fahren würdet.


    Modell: HS-453DX

    Firmwareversion: 4.4.1.1216


    Danke im voraus,

    Rainer.

  • Danke für den Hinweis. Ist mir aber zuviel Overhead. Habe nun einen kleinen Cron-Job eingetragen, der mir stündlich die Ausgabe von free in eine Textdatei schreibt:

    Code
    45 * * * * /usr/bin/free >> /root/memfree.log

    Beizeiten lese ich den verkürzt aus mit:

    Code
    cat memfree.log | grep Mem
  • Ja, wenn man mit der Konsole zurecht kommt ist dies natürlich die einfachere Lösung. Allerdings bietet das Q'Center noch sehr viel mehr Möglichkeiten als den Arbeitsspeicherverbrauch auszulesen. Für mehrere NAS meiner Meinung nach ein Musthave, zumindest wenn diese 24x7 laufen.

  • Habe nun einen kleinen Cron-Job eingetragen, der mir stündlich die Ausgabe von free in eine Textdatei schreibt

    Und hast Du auch an einer Überwachung gedacht, ab wann Du Teile der Datei wieder löschst, die Du nicht mehr benötigst?

    Für mehrere NAS meiner Meinung nach ein Musthave, zumindest wenn diese 24x7 laufen.

    Von der Funktionalität her überzeugend. Aber bei schwächeren NAS führt dies zu Nebenwirkungen (Leistungseinbußen). Habe mich aber noch nicht umgesehen, in wie weit es ähnliche Funktionalität mit geringeren Nebenwirkungen gibt. (Hat derzeit keine Priorität bei mir und habe auch nicht alle NAS dauerhaft am Laufen.)

  • Hatte Q'Center lange auf 3 TS-231+ am Laufen. Sind kleine ARM-Modelle. Ein paar Prozent Leistung hat sich der Q'Agent schon genehmigt, hat aber zu keinen Problemen geführt. Wichtiger ist zu wissen, dass ab Installation des Q'Agent das NAS nicht mehr schlafen geht, auch die Platten nicht.

  • Ein paar Prozent Leistung hat sich der Q'Agent schon genehmigt, hat aber zu keinen Problemen geführt.

    Ein paar Prozent halte ich für jene Plattform für etwas verniedlicht. Meinem Eindruck nach dürften es schon zwischen 10 und 20% gewesen sein, als ich diesen Dienst für einige Wochen testweise in Betrieb hatte. Mein TS-431P hat ja ähnliche Leistungsgrenzen wie Deine TS-231+. Zu Problemen hat dies nicht geführt. Da stimme ich Dir zu. Meinen Beobachtungen zu QTS-Heartbeats zufolge führt dies deutlich näher zu Risiken von unsauberen und ungeplanten Restarts. Auf den leistungsfähigeren NAS war die Auswirkung weniger deutlich.

  • Und hast Du auch an einer Überwachung gedacht, ab wann Du Teile der Datei wieder löschst, die Du nicht mehr benötigst?

    Du meinst, ob ich die Größe der anwachsenden Log-Datei überwache? Ehrlich gesagt tue ich das nicht. Ich hoffe, ich denke daran, den Cron-Job zu stoppen, bevor die Festplatte voll ist. Dauert ja ein wenig - nach 2 Tagen ist die Datei auf sagenhafte 11K angewachsen.

    Grundsätzlich hast Du natürlich recht. Wie würdest Du das machen?

  • Grundsätzlich hast Du natürlich recht. Wie würdest Du das machen?

    Grundsätzlich haben sich zwei verschiedene Verfahren bewährt, soweit das Thema von den Verantwortlichen überhaupt erkannt wird. Die eine Variante kommt aus dem Datengovernance, also der kontrollierten Verwaltung der Daten und Datenströme. Diese fragt nicht nur, welche Daten benötigt werden, sondern auch, wer welche Daten nutzt und ab wann welche Daten nicht mehr benötigt werden. Das zweite Verfahren nutzt bestehende Mechanismen zum Umgang mit Protokolldateien, wie sie in Betriebssystemen oftmals eingebaut sind. Dieses Verfahren kann die Bewertung aus dem zuvor genannten Verfahren berücksichtigen. Auch dabei gibt es noch Untervarianten. Die primitive Variante überwacht die Größe von Protokolldateien. Bei erreichen einer bestimmten Größe oder Alters wird diese geschlossen, umbenannt und komprimiert, während die Protokollierung in einer neuen Datei mit ursprünglichem Namen fortgesetzt wird. Die komprimierte, umbenannte Protokolldatei hat eine laufende Nummer als neuen Dateinamenssuffix, ergänzt um die Standardnamenskonvention des gewählten Komprimierverfahrens oder Werkzeuges. Eine andere Variante verzichtet auf diese Umbenennung und Komprimierung und überschreibt statt dessen einfach die ältesten Einträge nach einem Ringpufferprinzip. Bei Datengovernance würde ein Wartungsjob nach nicht mehr benötigten Datensätzen suchen und diese löschen. Die Feststellung des Bedarfs kann komplex sein, um auch Ausnahmen zu berücksichtigen, die z.B. manuelle Markierungen verwendet. Typisches Beispiel sind gesetzliche Aufbewahrungsfristen für bestimmte Datensätze. Bei laufenden Gerichtsverhandlungen oder bestimmten Verwaltungsvorgängen der Öffentlichen Verwaltung können aber bestimmte Datensätze länger benötigt werden als im Gesetz geregelt, so dass diese Datensätze gekennzeichnet werden müssen, dass sie trotz erreichen der altersmäßigen Löschberechtigung davon ausgenommen werden. Ähnliches gilt z.B. für Verbindungsdaten, für die es oft ein vereinbartes Löschintervall gibt, aber im Fall von eintreffenden Beschwerden möglicherweise eine längere Aufbewahrung bis zum Abschluß der Klärung benötigen. Für beide Varianten sollte in QTS Mechanismen eingebaut sein, die Du vermutlich nutzen könntest, um die Konfiguration auf Deine Protokolldatei zu erweitern. Data Governance wird dagegen mit einer eigenen Verwaltungssoftware realisiert. Da habe ich bislang nur von kommerziellen Produkten gehört und keine Praxiserfahrung. Oftmals scheint mir dies in Firmen ohne solche Werkzeuge implementiert zu sein, und statt dessen automatische Wiedervorlage eingerichtet zu sein, zur manuellen Bearbeitung. Ist immer noch besser als die Daten zu vergessen.


    Beruflich habe ich teilweise mit Archiven zu tun gehabt, als eine Person, die mitverantwortlich war für die Einbringung von Datensätzen in Archive, unter Berücksichtigung gesetzlicher und behördlicher Auflagen als auch den Interessen des Arbeitgebers, um seinen Pflichten aus Produkthaftung nachkommen zu können über den gesamten Zeitraum, der in regulierten Branchen deutlich länger sein kann als was die normale IT oder Verbraucher kennen. Dies ging bis zu 70 Jahre nach Ende der Vermarktung eines Produktes, NICHT bis zu 3 Jahren nach Markteinführung. Ich habe keine Probleme, daran Mitverantwortlichen Fragen so zu stellen, dass sie erkennen können, ob ihre bisherigen Vorkehrungen ausreichen bzw. die Person zu identifizieren, die überhaupt in der Lage ist, meine Fragen zu beantworten. Ein Teil kann nur von Mitverantwortlichen beantwortet werden, ein Teil ist diesen nicht unbedingt bekannt, sondern vom Durchführenden zu beantworten. Den Archivbetreiber brauche ich i.d.R. dazu nicht zu befragen, soweit aus den anderen Antworten sich kein entsprechender Bedarf ergibt. Und ich habe keine Ausbildung für dieses Thema. Meine Erfahrungen mit Antworten sind nicht repräsentativ. Sollten diese Erfahrungen repräsentativ sein, so wäre der Zustand solcher Archive als katastrophal zu bewerten, weil die Erstellung zu naiv erfolgte.


    Das von Mavalok2 angesprochene Werkzeug Q'Center ist dazu nicht in der Lage. Aber es liefert zumindest die Information, wenn Speicherplatz knapp wird. Wenn die Ursache einer solchen Speicherplatzknappheit in Protokollen und Archiven läge, dann wäre das ein Hinweis und Handlungsaufforderung, die bisherige Praxis zu überprüfen, da sie sich allem Anschein nach als unzureichend heraus stelle. Ob es sich um eine Fehleinschätzung des Speicherbedarfes oder der Aufbewahrungskapazitäten handelt, oder die automatischen Löschmechanismen zu lange nicht ausreichend funktioniert haben, lässt sich nicht abstrakt sondern nur im Einzelfall beantworten. Beruflich habe ich dabei wiederholt erlebt, dass meine Vorgänger keine Angaben hatten, wie lange welche Protokolle benötigt würden und daher auch keine automatische Löschung eingerichtet.

  • Wow, voll viel Text und die Frage wird gar nicht beantwortet :/

    ich denke daran, den Cron-Job zu stoppen, bevor die Festplatte voll ist.

    Wie würdest Du das machen?


    Solche "endlosen" Logfiles versehe ich gerne mit z.B. dem aktuellem Monat im Dateinamen. Bei dir würde das z.B. memfree_03.log heißen können.

    Das setzt natürlich voraus, dass dein "simpler" Aufruf über die cron ein Script aufruft, du darin das Monat abfragst und den Dateinamen bastelst.


    Dadurch hättest du jedes Monat ein neues File, kannst dann noch im Script entscheiden, ob du das Vormonat einfach löschen willst, oder nach xy Monaten ...

  • nach 2 Tagen ist die Datei auf sagenhafte 11K angewachsen.

    Sind wir großzügig, dann sind es nach einem Jahr 2 MB, nach 10 Jahren 20 MB und nach 100 Jahren 200 MB. Ich schätzte das killt die Festplatte noch länger nicht. Vielleicht alle paar Jahre eine neue Datei anlegen. Die Frage ist allerdings, wieso langfristig Protokollieren. Dient dies nicht zur aktuellen Analyse des Arbeitsspeicherverbrauchs? Dann wird dies nach ein paar Tagen und Wochen ohnehin nicht mehr gebraucht. Für ein langfristiges Überwachen stellt sich dann die Frage der Art der Analyse der Daten. Mit einen reinen Textfile kannst Du schnell nichts mehr anfangen.

  • Wahrscheinlich bin ich ein wenig zu einfach gestrickt, aber ich kann beim besten Willen keinen Zusammenhang zur Fragestellung des TE in den Ausführungen von chef1 erkennen.

  • Wow, voll viel Text und die Frage wird gar nicht beantwortet

    Wie soll ich das verstehen? Ich habe drei Antworten geliefert: Logfilerotation, Ringpuffer und Data Governance, für Leser, die nicht so fit in Deutsch sind und es lieber komprimiert in Neudeutsch mögen.

    Solche "endlosen" Logfiles versehe ich gerne mit z.B. dem aktuellem Monat im Dateinamen. Bei dir würde das z.B. memfree_03.log heißen können.

    Das ist ja auch nur eine Variante von Logfilerotation, wie ich sie vorgeschlagen habe, mit dem Unterschied, dass dafür ein weiteres Skript benötigt wird, während meine Variante mit Betriebssystemmitteln auskommen sollte. Habe jetzt aber nicht überprüft, ob diese Variante von Logfilemanagement im Lieferumfang von QTS bereits enthalten ist, oder eine zusätzliche Installation eines Linuxpaketes benötigt.


    Nachtrag: Habe überprüft, dass bei meiner QTS-Version sowohl Syslog-Server als auch logrotate bereits dabei sind und zumindest ein Teil bis zur GUI durchgereicht wird.

    Einmal editiert, zuletzt von chef1 ()