FHS에서 권장하는 규칙에 따라 사용자 정의 패키지를 설치하고 /opt/package_name, 구성 파일을 저장하고, /etc/opt/package_name정적 파일을 저장하고 있습니다 . /var/opt/package_name/static/[1] [2] [삼]
또한 일부 로그 파일을 저장해야 합니다. 분석 도구를 통해 검색할 수 있기를 원하므로 일반 위치에도 있어야 합니다. 이것들이 들어가야 할까요:
/var/log/package_name(시스템 패키지와 동일하지만 사용자 정의 패키지임)/var/opt/package_name/log(다음/var/opt관례 - 그러나 이것이 발견될 수 있습니까?)- 다른 건 없나요?
답변1
나는 그것들을 에 넣었습니다 /var/log/package_name; 그것은 최소 놀라움의 원칙을 더 잘 만족합니다 /var/opt/package_name/log. 이에 대한 참조가 없습니다. 단지 내가 로그를 찾고 있는 위치와 일치할 뿐입니다.
또한 자체 로그 파일 작성을 포기하고 대신 syslog로깅을 위해 적절한 태그와 기능을 사용할 수도 있습니다. 기존 분석 도구와의 완벽한 통합을 찾고 있다면 통신 채널로 이보다 더 나은 결과를 얻을 수 없을 것입니다. :
- "로그 분석"을 기능으로 나열하는 모든 일반 도구는 이미 주목을 받고 있습니다
syslog. logrotate로그 파일 할당 해제 및 회전 의미는 내가 처리합니다. 파일을 삭제하고 새 파일을 열도록 지시하는 메커니즘을 구축할 필요가 없습니다 .logrotate새 파일에 회전하라고 지시할 필요도 없습니다 !- 사이트에서 필요한 경우 로그를 중앙 로깅 서버로 오프로드할 수 있습니다.
rsyslog필요한 경우 기존에 확립된 도구가 사용되므로 해당 기능을 직접 구현하는 것에 대해 생각할 필요가 없습니다. - 로그 파일에 대한 액세스 제어(POSIX 및 SELinux)가 이미 처리되었으므로 배포별 보안 의미에 대해 너무 많이 걱정할 필요가 없습니다.
내 로그에 대해 일부 사용자 정의 바이너리 형식을 사용하지 않는 한 JSON과 같이 syslog에 친숙한 컴퓨터에서 구문 분석 가능한 텍스트 형식을 선호합니다. 나는 내 별도의 로그 파일을 정당화하는 데 어려움을 겪고 있습니다. 분석 도구는 이미 syslog매처럼 지켜보고 있습니다.
답변2
패키지 구성 파일은 FHS 규칙을 따르므로 일관성을 유지하고 로그 파일을 /var/opt/package_name/log.
FHS 규정:
도 지적했다
아래 로그 파일을 배치한다고 해서 /var/opt패키지가 제대로 작동하는 데 방해가 되는 것은 아니므로 이를 사용하는 것은 /var/log명백한 표준 위반입니다.
"이것이 검색 가능합니까?"라는 말이 무슨 뜻인지 명확하지 않습니다. 어쨌든 사용자 정의 로그는 사용자 정의 도구에 의해 처리될 것이기 때문에 일반 도구가 로그를 처리하도록 설계되었다고 가정하면 사용자 정의 로그는 번들로 제공되지 않는 패키지의 표준 위치를 탐색해야 합니다.
이는 syslog로깅 구성을 중앙 집중화하고 조정하는 데 유용한 도구이지만 알려진 경로가 있는 일반 파일에서 로깅 작업을 수행해야 할 때 로그를 저장할 위치에 대한 문제를 완전히 해결하지는 못합니다. 때때로 응용 프로그램 로그 디렉터리에 저장된 특정 파일은 프로세스 ID를 저장하는 파일과 같이 예상 경로를 사용하여 응용 프로그램 자체 또는 관련 프로그램에서 액세스할 수 있도록 설계되어 syslog해당 파일에 적용되지 않습니다.