일부 소프트웨어의 출력이 파일이 아닌 콘솔에 기록될 때 어떤 단점(성능 측면)이 있는지 궁금합니다.
구체적인 사례는 일부 프로세스가 의도적으로 stdout에 로그인하도록 구성되었기 때문에 Docker 컨테이너를 실행하는 것입니다.
파일의 경우 내가 생각할 수 있는 유일한 문제는 로그에서 사용하는 공간과 로깅의 강도에 따른 일부 IO입니다.
예를 들어, 액세스 로그를 stdout(콘솔)에 기록하는 Docker 컨테이너에 웹 서버 애플리케이션이 있고 컨테이너가 1년 동안 계속 실행된다고 가정해 보겠습니다. 이 큰 버퍼는 메모리(커널 1?)에 남아 있을 것입니다. 아니면 커널이 특정 제한 이후에 결국 시간을 지울까요?
이 경우 메모리 고갈과 커널 패닉을 걱정해야 합니까, 아니면 개념을 오해하고 있습니까?
(app|container|node가 닫히면 콘솔이 dmesg지워질 때와 동일하게 새로 고쳐지는 것으로 알고 있습니다.)
답변1
이것은 나쁜 생각입니다.
시스템 콘솔에 로깅하는 것은 로그 출력을 다음으로 보내는 특별한 경우입니다.어느실제 터미널 또는 커널 가상 터미널 장치. 거기아니요커널 버퍼 증가. 터미널 디스플레이 상단에서 스크롤하는 내용은 손실됩니다.
그러나 이것은 WWW 서버를 기록하는 데에는 좋지 않은 생각입니다.
교훈"Bash는 특정 수신 요청 후 잘못된 문자를 표시합니다." 그리고공격자에게 터미널에 임의의 콘텐츠를 쓸 수 있는 방법을 제공하지 마세요.특히 시스템 콘솔의 경우.
그리고 LAN에 보안이 필요하지 않다고 가정하지 마십시오. 언제나물건을 받아들이는 보안 서버어느회로망.
프로세스의 표준 오류와 표준 출력을 파이프에 연결하고, 파이프의 다른 쪽 끝은 아래에 언급된 도구 중 하나입니다.https://unix.stackexchange.com/a/505854/5132:
./기록할 내용 2>&1 |자전거 로그/
이러한 도구는 파일이 logs/지정된 디스크 공간 이상을 차지하지 않도록 하고 올바른 지점에서 로그를 자동으로 회전시킵니다. 이렇게 간단한 방법으로도 로그를 살펴보면 less공격자가 제공한 데이터가 최종 장치에 그대로 전송되는 대신 어느 정도 삭제되었음을 확인할 수 있습니다. (물론 options 을 사용하지 마십시오 -R.)less