| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- AI활용
- poetry
- loguru
- 프롬프트
- requirements.txt
- ai검증
- PaddleOCR
- default-argument
- deploy-hook
- pool_pre_ping
- fastapi
- ChatGPT
- poetry2.0
- 코드입력사이트
- pdfplumber
- systemd
- poetry-plugin-export
- journald
- pool_recycle
- 디스크용량
- 픽스처
- Linux
- sys_platform
- 온라인컴파일러
- 티스토리챌린지
- MySQL
- SQLAlchemy
- 로그관리
- autogenerate
- GCP
- Today
- Total
목록Linux (2)
모도리는 공부중
2024년 말, 작은 운영 서버에서 정리한 기록이다. 본문의 디스크 수치는 그 시점 값이다. 다만 그때 내가 근거로 삼았던 설명이 틀렸다는 걸 나중에 알게 됐고, 그 부분은 이 글에 그대로 적었다.운영 중인 서버를 살펴보다가 문득 궁금해졌다. journalctl로 보는 이 로그들, 일정 기간 지나면 오래된 것부터 알아서 없어지는 걸까? 아니면 무한정 쌓이고 있는 걸까?백엔드 애플리케이션 로그는 애플리케이션 단에서 라이브러리로 따로 쌓고 있어서, journal에 쌓이는 로그는 "지금 잘 돌아가고 있나" 확인하는 용도면 충분했다. 그런데 이게 디스크를 야금야금 먹고 있다면 얘기가 달라진다.현재 상태부터 확인일단 서버의 journald 설정 파일을 열어봤다.sudo cat /etc/systemd/journal..
로그 시리즈 3편. 1편에서 systemd로 옮기며 상한을 걸었고, 2편에서 syslog 이중 적재를 잡았다. 이 글은 그 뒤 일주일이다. 포워딩을 끊고 사용률이 100%에서 77%로 내려왔다. 이번엔 진짜 끝난 줄 알았다.매일 오후 5시 기록을 그대로 옮기면 이렇다.날짜엔진 서버1/16 (조치 직후)77%1/1783%1/20 오전89%1/20 오후90%1/2193%1/2497%하루에 2~3%씩 꾸준히. 이번엔 폭발이 아니라 등속이었다.이번엔 시스템 로그가 아니었다/var/log를 봤더니 journal이 500M 근처에서 얌전했다. syslog는 상위 목록에서 아예 사라졌고. 2편에서 한 조치는 잘 먹고 있었다.그럼 뭐가 차는 건가.찾기 전에 급한 불부터 껐다. journal은 이 명령 하나로 그 자리에..