Influxdb datengrösse

[A Former User]

@cainam sagte in Influxdb datengrösse:

da kommen 100e einträge... auch solche mit 500M, die meisten aber mit 4.0k

Moin,

So dann fangen wir mal von vorne an

Auf welcher Hardware läuft das ganze?
Wenn das kleine Tool noch nicht installiert ist, dann installier dir mal ncdu.

Da du als root hantierst, gehe ich davon aus, dass es irgendetwas mit Docker ist, da ist das dann etwas schwerer mit dem Installieren des Tools, wenn es eine normale Linux Installation ist, dann ist das easy und Du kannst es so aufrufen

root# ncdu /

oder

# sudo ncdu /

Du bekommst dann eine Übersicht der Füllmenge, der Verzeichnisse ab dem root Verzeichnis, dann kann man mit den Cursortasten ein Verzeichnis anwählen und mit Enter eine Ebene tiefer gehen.

VG
Bernd

[cainam]

nein, habe über proxmox debian cts am laufen

[cainam]

@marc-berg said in Influxdb datengrösse:

Okay, das bedeutet wohl, dass die DB vorher 1,4 GB groß war und jetzt 600 MB. Das passt.

wie kommst du auf das? ich habe 16GB für die maschine und das ist fast voll... ausser influxdb läuft da nix drauf

backup ist bei ca 1.9 gb ... vorher vielleicht 2.1gb

[A Former User]

@cainam sagte in Influxdb datengrösse:

nein, habe über proxmox debian cts am laufen

Moin,

was ist cts?
Es gibt LinuX Container = LXC oder Virtual Mashine = VM

Gut, dann installier mal und richte Dir auch gleich ein User ein, damit Du nicht als root im System herum schlawienerst.
Ein User und sudo reichen aus, um ein Linuxsystem zu benutzen und zu warten/pflegen.

VG
Bernd

P.S.: So installiert man Programme, da Du ja schon als root hantierst, aber im LXC oder VM nicht in Proxmox

# apt install ncdu

[cainam]

@dp20eic said in Influxdb datengrösse:

.

genau LXC

wieso ist das so wichtig nicht als root? ich bin ja alleine der zugriff hat und ob ich was mit sudo xxxx zerstöre oder als root... gibts da ein unterschied?

apt install ncdu
habe ich installiert... resp so eingegeben... da ist nicht viel passiert... und nun?

[A Former User]

@cainam sagte in Influxdb datengrösse:

wie kommst du auf das? ich habe 16GB für die maschine und das ist fast voll... ausser influxdb läuft da nix drauf

Moin,

Dein Speicher wird von was anderem gefressen, ich gehe von riesigen Log Files, Journal Files aus, oder der apt Cache ist aufgebläht.

Also ncdu installieren und schauen, wo die Kracher liegen, dann gezielt aufräumen

VG
Bernd

[cainam]

du hast glaube ich recht... logs

9.2 GiB [##########] /log
2.1 GiB [## ] /lib
508.8 MiB [ ] /cache
1.4 MiB [ ] /spool
1.1 MiB [ ] /backups
24.0 KiB [ ] /mail
e 4.0 KiB [ ] /tmp
e 4.0 KiB [ ] /opt
e 4.0 KiB [ ] /local
@ 0.0 B [ ] lock
@ 0.0 B [ ] run

wie lösche ich alle die ich nicht brauch?

kann ich hier die obersten drei logs einfach löschen?
/..
3.4 GiB [##########] daemon.log
3.4 GiB [######### ] syslog
1.4 GiB [#### ] /journal
654.1 MiB [# ] auth.log
186.5 MiB [ ] daemon.log.1
27.9 MiB [ ] syslog.1
22.8 MiB [ ] messages
22.8 MiB [ ] user.log
11.3 MiB [ ] daemon.log.3.gz
11.0 MiB [ ] daemon.log.2.gz
10.1 MiB [ ] daemon.log.4.gz
1.7 MiB [ ] syslog.4.gz
1.7 MiB [ ] syslog.5.gz
1.6 MiB [ ] syslog.6.gz
1.5 MiB [ ] syslog.7.gz
1.5 MiB [ ] syslog.3.gz
1.3 MiB [ ] syslog.2.gz

[A Former User]

@cainam sagte in Influxdb datengrösse:

wieso ist das so wichtig nicht als root? ich bin ja alleine der zugriff hat und ob ich was mit sudo xxxx zerstöre oder als root... gibts da ein unterschied?

Moin,

das ist eine Diskussion, die wir gern mal beim Bier austragen können
Root ist einfach nicht nötig und ein falscher Befehl und alles ist hin, als User kanst Du ersteinmal nichts kaputt machen und wenn man mal ein Befehl als root braucht, dann nimmt man sudo, punk aus.

@cainam sagte in Influxdb datengrösse:

apt install ncdu

Nicht sagen, zeigen, Text in Code Tags </> hier zeigen, so sieht das bei mir aus, ist aber schon installiert, bei mir.

dp20eic@iobroker:~$ sudo apt install ncdu
[sudo] password for dp20eic: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ncdu is already the newest version (1.15.1-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

VG
Bernd

[A Former User]

@cainam sagte in Influxdb datengrösse:

du hast glaube ich recht... logs

Moin,

auch ein blindes Huhn findet mal ein Korn

@cainam sagte in Influxdb datengrösse:

kann ich hier die obersten drei logs einfach löschen?

Nein, mal gerad nachschauen, wie man das am sinnvollsten macht.

VG
Bernd

P.S.: eins noch vorweg, es ist bei Deiner Installation etwas nicht korrekt, denn es sollte eigentlich ein Log Rotation stattfinden, entweder bei einer gewissen Größe oder einem gewissen alter eines Log Files und dann sollten es auch nur x Gepackte Log Files geben, siehe syslog,x.gz aber das Packen scheint nicht mehr zu funktionieren, könnte man an den Zeiten der Files sehen, seit wann.
P.P.S.: dann scheint da etwas gehörig in die Logs hineinzuschreiben, leider kann man so große Dateien nur schlecht debuggen um zu sehen was da die letzten Tage so vor sich ging.
P.P.P.S.: jetzt erst mal zu einem schnell Schuß, damit das erst mal wieder funktioniert und Du Dir anschließend die Log Files anschauen kannst
Das jetzt wirklich als root da hier die vollen Rechte gebraucht werden

# truncate -s 1M /var/log/daemon.log
# truncate -s 1M /var/log/syslog

P.P.P.P.S.: die Gezipten Log Files kannst Du ganz löschen

# rm -f /var/log/*.gz

P.P.P.P.P.S.: anschließend den LXC einmal rebooten

[Marc Berg]

@cainam sagte in Influxdb datengrösse:

wie kommst du auf das?

Weil die Zahlen genau das sagen. Aber das hat sich ja in den letzten Posts schon aufgeklärt.

[A Former User]

@dp20eic sagte in Influxdb datengrösse:

P.P.P.P.P.S.: anschließend den LXC einmal rebooten

Moin,

zitiere mich mal selbst

Das journal kann man dann auch gleich noch schrumpfen.

# journalctl --flush --rotate --vacuum-time=1h

Und noch eine kleine Linux gratis Stunde, was machen die Kommandos eigentlich?

# truncate   -> schrumpft das angegeben File auf eine angegebene Größe, welche mit dem Parameter `-s` angegeben wird
# journalctl -> ist das Controll Programm, mit welchem man sich das `systemd` `Journal` anschauen kann und verwalten kann,
  da die Files vom `systemd journal` Binär Datein sind, braucht man ein Tool zum Anschauen, Auswerten

Wenn man wissen möchte, was ein Kommandozeilentool so macht und welche Parameter es gibt, dann einfach

# man progname           -> z. B. # man truncate
oder
# programname -h (--help) -> z. B.: # truncate -h

VG
Bernd

[cainam]

@dp20eic
DANKE, du bist genial...

wegen dem bier - gerne wo bist du denn zuhause

jetzt sieht es so aus

root@Daten:~# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/loop0      15375304 4712560   9859928  33% /
none                 492       4       488   1% /dev
udev             3952404       0   3952404   0% /dev/tty
tmpfs            3987136       0   3987136   0% /dev/shm
tmpfs            1594856      60   1594796   1% /run
tmpfs               5120       0      5120   0% /run/lock

einiges besser

kann ich das truncate mit dem auth.log auch machen?

[A Former User]

@cainam sagte in Influxdb datengrösse:

wieso ist das so wichtig nicht als root? ich bin ja alleine der zugriff hat und ob ich was mit sudo xxxx zerstöre oder als root... gibts da ein unterschied?

Moin,

bin zu faul, hier alles zu schreiben, aber hier -> https://wiki.ubuntuusers.de/mit_Root-Rechten_arbeiten/ ist das wichtigst gesagt.

Auch ich hatte auf den Servern nie wirklich root Zugriff, obwohl ich das Passwort wusste, ich bin immer über meinen persönlichen User auf den ~ 200 - 300 Servern unterwegs gewesen, nur wenn wir neue Software auf die Systeme gebracht haben, dann habe ich mal als root gearbeitet, würde ich aber heute nicht mehr so machen

VG
Bernd

[A Former User]

@cainam sagte in Influxdb datengrösse:

kann ich das truncate mit dem auth.log auch machen?

Moin,

nein, glaube da gibt es einen anderen Trick, denn auch das File ist Binär, daher geht das nicht mit truncate ich schaue mal in meinem verstaubten Kämmerchen (Brain) nach.

VG
Bernd

[cainam]

@dp20eic said in Influxdb datengrösse:

P.S.: eins noch vorweg, es ist bei Deiner Installation etwas nicht korrekt, denn es sollte eigentlich ein Log Rotation stattfinden, entweder bei einer gewissen Größe oder einem gewissen alter eines Log Files und dann sollten es auch nur x Gepackte Log Files geben, siehe syslog,x.gz aber das Packen scheint nicht mehr zu funktionieren, könnte man an den Zeiten der Files sehen, seit wann.

soll ich influxdb neu installieren oder gibt das ein chaos?

[Thomas Braun]

@cainam sagte in Influxdb datengrösse:

ob ich was mit sudo xxxx zerstöre oder als root... gibts da ein unterschied?

Als root wird JEDER Befehl, ob sinnvoll oder nicht, ob gefährlich oder nicht ohne Rückmeldung gnadenlos durchgerasselt.
Der Prefix 'sudo' gibt dir also die Chance, darüber nachzudenken, ob der Befehl vielleicht nicht doch besser ohne root-Rechte zu verwenden ist. Und du fällst nach dem sudo auch wieder in die user-Rolle zurück.
Das ist also das was für den Metzger der Kettenhandschuh ist oder für den Schweißer seine Schweißbrille. Amateure oder Lebensmüde (oder lebensmüde Amateure) kommen vermeintlich ohne diese Dinge viel besser zurecht. Ist aber ein Trugschluss, die Profis wissen warum sie ihre Schutzausrüstung anlegen.

ich bin ja alleine der zugriff hat

Auch das ist ein Trugschluss. Kannst dir per

cat /etc/passwd

ja mal die Liste der User auf der Kiste ansehen. Die haben alle spezifische Rechte und Einschränkungen.

[A Former User]

@cainam sagte in Influxdb datengrösse:

soll ich influxdb neu installieren oder gibt das ein chaos?

Moin,

das ist nicht nötig, wenn jetzt erst einmal etwas aufgeräumt ist, kann man sich die verschiedenen Files mal anschauen und findet ja, vielleicht heraus, warum die Logs nicht mehr rotierten und dann angewachsen sind, bis sie auch nicht mehr gepackt werden konnten.

VG
Bernd

[A Former User]

@dp20eic sagte in Influxdb datengrösse:

glaube da gibt es einen anderen Trick, denn auch das File ist Binär

Moin,

noch mal ein selbst Zitat.
Habe dummes Zeug geschrieben, ist keine Binär Datei, kann mal mit truncate machen oder

# > /vat/log/auth.log

Da diese Datei auch besondere Rechte hat entweder auch als root oder Dein User muss in die adm Gruppe, damit das mit sudo klappt.
Aber man sollte sich wirklich mal /etc/logrotate.conf und /etc/logrotate.d/* anschauen, ob alles korrekt eingerichtet ist, denn dann muss man da nicht viel aufwand mit dem House Keeping machen.

VG
Bernd

[cainam]

@dp20eic said in Influxdb datengrösse:

/etc/logrotate.conf

 cat /etc/logrotate.conf
# see "man logrotate" for details

# global options do not affect preceding include directives

# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
#dateext

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# system-specific logs may also be configured here.

/etc/logrotate.d/*

cat /etc/logrotate.conf
# see "man logrotate" for details

# global options do not affect preceding include directives

# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
#dateext

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# system-specific logs may also be configured here.
root@Daten:~# cat /etc/logrotate.d/*
/var/log/alternatives.log {
        monthly
        rotate 12
        compress
        delaycompress
        missingok
        notifempty
        create 644 root root
}
/var/log/apt/term.log {
  rotate 12
  monthly
  compress
  missingok
  notifempty
}

/var/log/apt/history.log {
  rotate 12
  monthly
  compress
  missingok
  notifempty
}

# no packages own btmp -- we'll rotate it here
/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}
/var/log/dpkg.log {
        monthly
        rotate 12
        compress
        delaycompress
        missingok
        notifempty
        create 644 root root
}
/var/log/influxdb/influxd.log {
    daily
    rotate 7
    missingok
    dateext
    copytruncate
    compress
}
/var/log/syslog
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}
/var/log/unattended-upgrades/unattended-upgrades.log
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
/var/log/unattended-upgrades/unattended-upgrades-shutdown.log
{
  rotate 6
  monthly
  compress
  missingok
  notifempty
}
# no packages own wtmp -- we'll rotate it here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    minsize 1M
    rotate 1
}
root@Daten:~#

siehst du was da falsch ist?

[A Former User]

@cainam sagte in Influxdb datengrösse:

/etc/logrotate.conf

Moin,

ist untergegengen, aber nein in der Datei /etc/logrotate.conf ist alles ok uns auch bei den Dateien in /etc/logrotate.d/* sehe ich auf Anhieb auch keinen Fehler.

Jetzt mal schauen, ob der Dienst auch läuft

dp20eic@iobroker:~$ systemctl status logrotate.timer 
* logrotate.timer - Daily rotation of log files
     Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Wed 2023-09-20 14:48:42 CEST; 1 day 17h ago
    Trigger: Sat 2023-09-23 00:00:00 CEST; 15h left
   Triggers: * logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Warning: some journal files were not opened due to insufficient permissions.

dp20eic@iobroker:~$ systemctl status logrotate.service 
* logrotate.service - Rotate log files
     Loaded: loaded (/lib/systemd/system/logrotate.service; static)
     Active: inactive (dead) since Fri 2023-09-22 00:00:35 CEST; 8h ago
TriggeredBy: * logrotate.timer
       Docs: man:logrotate(8)
             man:logrotate.conf(5)
    Process: 24906 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS)
   Main PID: 24906 (code=exited, status=0/SUCCESS)
        CPU: 52ms

VG
Bernd