이상하게 들리는 상황에 직면했습니다. 다양한 로그 파일이 포함된 디렉터리가 있는 마운트 지점이 있습니다. 디렉터리를 마운트 해제하고 다른 위치에 다시 설치해야 하는 경우도 있습니다. ( logrotate주된 의도는 아니지만 이것을 다른 방법으로 생각할 수 있습니다 .)
문제는 이것이 실시간 시스템이라는 점이다.언제나로그 파일이 열립니다. 제거하고 다시 설치하기 전에 먼저 모든 쓰기 프로세스를 중지하고 다시 설치한 후에 다시 시작할 수 있지만 제 경우에는 항상 이를 보장할 수는 없습니다. 기록되는 프로세스가 모두 내 통제하에 있지 않을 수도 있고 내 설치 전환 루틴이 들어보지 못한 새로운 프로세스가 항상 있을 수도 있습니다. 또는 누군가가 대화형으로 로그인하여 로깅 디렉터리로 변경했을 수도 있습니다. (또한 일부 프로세스는 잠재적인 불안정 없이 중지할 수 없습니다.) 그러나 로깅 디렉터리의 파일에 쓰고 있거나 로깅 디렉터리를 현재 디렉터리로 사용하는 모든 프로세스는 제거를 차단하므로 스위치가 전혀 작동하지 않습니다.
그래서 제가 하고 싶은 것은 가상의 "동적 마운트 전환 파일 시스템"을 사용해 보는 것입니다. 이는 기본적으로 모든 파일 시스템 작업을 기본 실제 파일 시스템에 매핑하는 간단한 통과 가상 파일 시스템입니다.하지만매핑을 다양한 기본 실제 파일 시스템으로 동적으로 리디렉션하는 기능언제든지, 파일이 열려 있어도 마찬가지입니다.
전환하는 동안 당연히 몇 가지 의미론적 의미가 있습니다.
쓰기 위해 열린 파일은 이전에 작성된 부분이 이전 가상 마운트 지점에 남아 있고 새로 작성된 모든 부분이 새 가상 마운트 지점으로 이동되도록 분할되어야 합니다. 이는 O_APPEND 모드에서 열린 파일에서 가장 잘 작동하며, 실제로 해당 파일에 기록된 파일 검색을 억제해야 할 수도 있습니다. 그러나 이러한 모든 결과는 순차적으로 작성된 로그 파일의 경우 완벽하게 괜찮습니다(물론 내 응용 프로그램과 관련된 것임).
읽기 위해 열린 파일은 EOF 또는 EIO를 반환해야 합니다.
로그 디렉터리를 현재 디렉터리로 사용하는 프로세스는 영향을 받아서는 안 됩니다(
ls전환 전후의 결과가 매우 다를 수 있음에도 불구하고).로그 디렉터리의 하위 디렉터리에는 더 많은 고려가 필요할 수 있지만 기본적으로 동일한 규칙을 따릅니다.
지금까지는 이 모든 것이 이해가 되기를 바랍니다(비록 제가 그렇게 생각하는 것이 미쳤다고 생각할 수도 있지만).
그래서 내 질문은 다음과 같습니다
이를 수행할 수 있는 가상 파일 시스템 모듈이 이미 있습니까? (나는 "union" 파일 시스템에 대해 알고 있으며
autofs어떤 면에서는 다소 유사합니다.)그러한 모듈이 존재하지 않는 경우, 작성하려고 하면 극복할 수 없는 어려움을 간과하고 있습니까?
내가 하고 싶은 일을 하는 더 좋은 방법이 있나요? 내 요구 사항은 파일 시스템을 마운트 해제하고 다시 마운트하는 것과 동일한 작업을 수행하는 것이지만 내 한계는 파일이 열려 있을 가능성이 높다는 것입니다.
(아직도 "미친 짓이다. 제거할 때 열려 있는 파일이 없는지 확인하면 된다"고 말하는 분들도 계십니다. 제가 말씀드리는 것은 전혀 보장할 수 없다는 것입니다. 가능한 모든 프로세스 식별 로그 작성 files는 열려 있는 질문입니다. 모든 로그 파일을 미리 식별해야 하는 솔루션은 완전히 미래에 대비할 수 없습니다. 이것이 제가 VFS의 미친 동적 마운트를 진지하게 고려하는 이유입니다. 실제로 작업 부하가 줄어들고 작업 부하가 증가할 것이라고 믿습니다. )
부록: 누군가 중앙에서 쉽게 관리할 수 있도록 모든 로깅을 syslog(또는 다른 고유한 중앙 서비스)로 전환하라고 제안했습니다. 하지만 앞서 말했듯이 나는 로깅을 수행 중이거나 수행할 수 있는 모든 프로세스를 제어할 수 없습니다. 예를 들어, chrony추적 정보와 같은 항목을 기록하기 위해 syslog 대신 fwrite를 사용한다는 것입니다. (타이밍을 엉망으로 만들고 싶지 않기 때문에 chrony를 중지했다가 다시 시작할 수 없으므로 이제 대부분의 chrony 로깅을 포기해야 합니다.)
답변1
가능한 해결책 중 하나는 로그를 비관계형 데이터베이스로 보내는 것입니다.
또한 몇 가지 트릭을 시도하고 여러 소스에서 동시에 쓰기를 지원하는 파일 시스템을 선택할 수도 있습니다.
두 솔루션 모두 고유한 문제가 있으며 나에게는 매력적이지 않습니다.
질문할 때 또 다른 가능한 해결책은 NFS를 통해 공용 /var/log/machine 디렉토리를 공유하는 것입니다. 이것은 또한 몇몇 서버에서 작동할 수 있지만 확장성이 좋지 않은 불쾌한 해킹입니다.
가능하다면 중앙 syslog 서버를 만들고 모든 로그를 이 서버로 지정하겠습니다. 이런 방식으로 적어도 해당 로그에서는 동시 문제가 해결됩니다.
직접적인 시스템 로깅에 적합하지 않은 다른 애플리케이션의 경우 시스템 로그의 경우에도 filebeat 또는 greylog를 고려합니다.
궁극적으로 syslog가 불가능한 로그를 중앙 syslog로 처리하려고 합니다(후자의 경우 Apache 및 Tomcat 로그를 사용합니다).
Loggly, Scalyr 등 다른 상용 제품도 확인해 보실 수 있습니다. 뉴렐릭(New Relic) 또는 스플렁크 엔터프라이즈(Splunk Enterprise). 추가 보너스로 경영진에게 매우 유용한 통계를 제시하고 용량 계획을 수립할 수 있습니다.
비용을 지출하고 명확하게 정의된 프로세스가 있으면 새 솔루션을 설치해야 하는 사람은 누구나 "공식" 방법을 사용하여 공식 대상으로 로그를 보내야 한다는 내부 규칙을 설정할 수 있습니다.
추신: 당신은 기술적인 해결책으로 조직의 문제를 해결하려고 합니다. 일반적으로 일이 잘 진행되지 않습니다. 상사를 참여시켜야합니다.