NFS 마운트에 기록 된 시스템 로그


0

오늘 우리는 /postfix의 잘못된 구성으로 인해 전체 루트 ( ) 파티션으로 가득 찬 (100 %) Linux 서버에 문제가 발생하여 큰 /var/log/syslog파일 을 가져 왔으며 어제 다른 유스 케이스에 AWS EFS (NFS 서비스)를 사용하기 시작했습니다.

이 두 가지 이벤트를 기반으로 로그 파일이 미쳐서 서버 / 디스크 중단을 피할 수있는 가능한 해결 방법에 대해 내부적으로 논의했으며 모든 서버의 로그 파일에 단일 NFS 마운트를 사용하는 것이 좋습니다. AWS의 EFS 서비스는 거의 무제한 (에서보고 한 8 엑사 바이트 df)을 제공하며 단일 드라이브의 모든 로그를 통합하면 디버깅 오류를 쉽게 줄일 수 있습니다.

위의 사실과 아이디어를 감안할 때 문제는 분명합니다. 모든 Linux 로그에 NFS 마운트를 사용하는 것이 제안 된 접근법입니까? 찬반 양론?

나는 이것이 찬성 질문 일지 모른다는 것을 알고 있지만, 그것은 내가 필요한 피드백이 아니라 실제 사실 / 문제 / 측정에 따라 발생할 수있는 실제 가능한 단점입니다.

답변:


1

1) 물론 로깅의 양에 따라 다르지만 네트워크 로깅이 느리므로 로컬 디스크에 로깅하는 것과 비교하여 시스템의 일부가 크게 느려질 수 있습니다. NFS는 또한 상당한 CPU를 사용할 수 있습니다. 디스크 공간 부족으로 인해 로그가 네트워크 FS로 이동했다는 사실을 알 때까지 서버에서 몇 주 동안 성능 문제를 겪는 사람들을 보았습니다.

2) 1) 로그를 자체 파티션으로 이동하고 2) 다소 적극적인 롤링 정책을 가지고 3) 압축 된 로그를 AWS로 이동하는 것이 좋습니다. 로그는 손상된 경우 많은 정보를 표시 할 수 있으므로 로그를 내보내기 전에 암호화하는 것이 좋으며 AWS 스토리지에 대한 보안이 매우 엄격합니다.


여분의 파티션을 사용하는 것이 좋은 옵션이지만 사운드 사용에 대해서는 의문의 여지가 있습니다. 나는 그렇게 생각하지 않으며 일부 로그 파일 / 항목은 / var / log에 다른 파티션을 마운트하는 데 숨겨져있을 수 있습니다. 무슨 뜻인지 알겠 니?
Gonzalo Vasquez 2016 년

1
/ var / log 자체를 새로운 파티션으로 만들 필요는 없습니다. / var / log의 소프트 링크를 사용하여 / var / log / postfix 또는 다른 파티션으로 이동할 수 있습니다.
xenoid

좋아, 그것은 좋은 소리, 그러나 syslog 또는 메시지와 같은 파일을 새 파티션으로 이동하려면 어떻게해야합니까? 그것들은 리눅스 시작의 초기부터 쓰여졌습니다. 다른 파티션을 마운트하기 전에도 몇 줄을 생각합니다
Gonzalo Vasquez
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.