Cum să limitați dimensiunea jurnalului pe Elastic beanstalk cu platforma Corretto 8/Amazon Linux 2?

Am migrat recent una dintre aplicațiile noastre pe platforma „Corretto 8 care rulează pe 64 de biți Amazon Linux 2/3.2.12”. Acum vedem problema că fișierele jurnal ne umplu volumul discului într-un interval de puțin peste o săptămână. Nu am avut problema înainte.

Ceea ce este enervant este că transmitem acele jurnale către cloudwatch, așa că nu avem nevoie de ele în instanță în sine. Ceea ce este și mai enervant este că toată documentația, postările de blog etc. pe care le pot găsi pe această temă aparent nu sunt scrise pentru această platformă. Când mă uit la structura fișierului, se pare că adoptă o abordare diferită pe care încă nu mi-am dat seama complet.

În primul rând, nu există /var/log/httpd ... folder sau alte foldere pentru anumite jurnale. Până acum mi-am dat seama că ceea ce este trimis în fluxul de jurnal web.stdout.log (care pe vechea platformă era denumit diferit, dar nu-mi amintesc cât de precis. În orice caz, acolo se înregistrează aplicația spring-boot). to) este stocat în fișierul /var/log/messages.

Știu asta pentru că în timp ce analizăm de ce rămâneam fără spațiu pe disc, acest fișier ar fi întotdeauna cel mai mare de pe întregul disc. Cu excepția, imediat după ce a început o instanță, atunci avea o dimensiune rezonabilă. După 3 zile, poate ajunge la o dimensiune de 2 GB și continuă să crească până când nu mai rămâne nimic. Este, fără îndoială, sursa necazului nostru.

Întrebarea este, ce pot do despre? Rotația jurnalelor este în configurația implicită și pot vedea unele fișiere în /var/log/rotated (de asemenea, un folder diferit de unde erau jurnalele rotite), dar acestea sunt mici (cel mai mare dintre ele este un adorabil 1,3 MB în size...), iar dimensiunea /var/log/messages nu scade niciodată, ci doar crește.

Am citit numeroase articole despre cum să rezolv probleme similare prin configurarea logrotate folosind ebextensions, de la AWS înșiși și bloggeri, dar în toate pot vedea foarte repede că sunt construite pe o structură foarte diferită, așa că nu par aplicabile. De asemenea, am experimentat deja în timpul migrării că unele lucruri care au fost făcute cu ebextensions acum nu se mai făceau cu ebextensions, dar documentația este destul de lipsită.

Cunoaște cineva platforma suficient pentru a-mi da un indiciu despre cum aș putea proceda pentru a configura aceasta? Nici nu am nevoie roti buștenii, strict vorbind, vreau doar să dispară de îndată ce sunt mai vechi de o oră și ceva. La urma urmei le avem pe cloudwatch...

Informatii suplimentare Cu cât mă uit mai adânc în asta, cu atât devin mai confuz. Există un fișier /var/log/web.stdout.log, care primește aceleași mesaje ca și /var/log/messages. Privind conținutul logrotate.elasticbeanstalk.hourly, acesta este fișierul care se află de fapt în rotație de jurnal și care pare să funcționeze bine.

Făcând un lsof, procesul care utilizează acel fișier este rsyslogd. Conform comentariului Shearn89s de mai jos, se pare că acesta este noul syslog și tot ceea ce se conectează la stdout este înregistrat acolo.

Dându-mi seama că acel fișier nu este sub nici un fel de rotație, încerc să-l configurez. Doar pe instanță direct deocamdată, voi afla mai târziu cum să o fac în configurația reală a mediului.

Am creat un nou fișier de configurare în /etc/logrotate/elasticbeanstalk.hourly cu următorul conținut:

/var/log/messages {
 su root root
 dimensiune 10M
 rotiți 5
 lipsingok
 comprima
 notificare gol
 copytruncate
 dateext
 formatul datei %s
 olddir /var/log/rotated
}

Alergare sudo /usr/sbin/logrotate /etc/logrotate.elasticbeanstalk.hourly/logrotate.elasticbeanstalk.messages.conf --debug, am urmatoarea iesire:

model de rotație: /var/log/messages 10485760 octeți (5 rotații)
olddir este /var/log/rotated, fișierele jurnal goale nu sunt rotite, istoricele vechi sunt eliminate
luând în considerare log /var/log/messages
  bustenul trebuie rotit
jurnal rotativ /var/log/messages, log->rotateCount este 5
„%s” convertit -> „%s”
sufixul dateext „1646905905”
model glob „[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0 -9]'
glob a eșuat găsirea vechilor bușteni rotați
copierea /var/log/messages în /var/log/rotated/messages1646905905
trunchierea /var/log/messages
comprimarea jurnalului cu: /bin/gzip

Pare promițător, dar adevărul rece este că nimic nu pare să se fi schimbat. Fișierul are în continuare aceeași dimensiune și nu a fost creat niciun fișier în folderul de rotație. Se pare că nu are niciun efect. Am schimbat configurația, astfel încât se mișcă și creează în loc de trunchiere, am încercat -f, toate cu același rezultat. Nu există nicio eroare de la logrotate, dar nici un efect. Dosarul ăla pare al naibii de impermeabil.

Am salvat asta în .ebextensions/liblogrotate.config:

fisiere:
   /etc/remove_old_logs.sh:
     proprietar: rădăcină
     grup: rădăcină
     modul: "000644"
     continut: |
       #!/bin/sh
       găsiți /var/log -type f -mtime +7 -exec rm {} +

container_commands:
  01_crontab:
    comandă: "( crontab -l | grep -v -F \". /etc/remove_old_logs.sh\" ; echo \"0 0 * * * . /etc/remove_old_logs.sh\" ) | crontab -"

Acesta creează un crontab care elimină fișierele mai vechi de 7 zile din folderul /var/log. Știu că nu este optim, dar nu-mi pasă atât de mult de acele bușteni.