저는 Linux 서버의 로그를 저장하는 보다 현대적인 방법을 찾고 있습니다. Rsyslog는 로그를 유지 관리 가능하게 유지하고 로그가 차지하는 공간을 최소화하기 위해 여전히 logrotate에 크게 의존하고 있으며 이는 더 이상 권장되는 접근 방식이 아닙니다. 대신, 아래에 설명된 대로 데이터 손실 및 기타 문제를 방지하려면 로그 기록기가 로그 회전자와 동일해야 합니다.FGA: 이번 세기에는 logrotate나 newsyslog를 사용하지 마세요
내 목표는 다음과 같습니다
- 로그 유지 관리를 단순하게 유지하고 로그 출력을 검사하고 조작할 수 있는 다양한 도구를 제공합니다.
- 공간 부족 문제를 피하고 구성 오버헤드를 방지하여 이러한 일이 발생하지 않도록 하세요. 또한 로그 중복을 피하십시오
- 이 옵션은 로그가 영원히 열려 있어
copytruncate잘림 중에 로깅 데이터가 손실되는 문제를 방지하는 데 사용해야 합니다. 또는 서비스를 강제로 다시 시작해야 하는 대체 방법을 사용하세요. - 여전히 중앙 로그 서버/데이터베이스(Elasticsearch 등)로의 전달 구현을 단순하게 유지하세요.
내 경험상 rsyslog + logrotate를 사용하면 큰 노력 없이는 이 작업을 수행할 수 없지만 Journald는 최소한 이러한 기준을 모두 충족하는 것 같으므로 이를 단독으로 사용하고 이미 설명한 목적을 위해 rsyslog도 제거하고 싶습니다. 기존 저널 중복을 제거합니다(저널링할 때 storage=persistent).
저널드가 이 목표에 완벽하게 부합한다고 생각하는 이유에 대한 자세한 내용은 다음과 같습니다.
- 로그 및 공간 사용량을 자동으로 유지 관리할 만큼 스마트합니다(형식은 일관되고 공간 사용량은 파티션의 사용 가능한 공간을 기준으로 함).
- 많은 소프트웨어가 이미 호환됩니다(docker에는 저널링된 로깅 백엔드가 있고, 로그 처리 및 Logstash로 전송을 위한 저널비트가 있습니다).
- 순환 예약을 처리하기 위해 "덤프" cron 작업에 의존하지 않습니다.
- 로그를 확인하는 많은 도구가 있습니다
- 로그 파일은 문제 없이 열려 있습니다.
- 널리 사용되는 모든 서버 배포판에 이미 내장되어 있으며 최소한의 구성이 필요합니다.
- 권한을 올바르게 처리하고 해당 권한에 액세스하려면 특정
adm또는 그룹systemd-journal의 멤버십이 필요합니다.
일기에서 본 질문은 다음과 같습니다.
- 로그는 바이너리 형식이며 외부 도구를 사용한 텍스트 기반 구문 분석을 허용하지 않습니다(예: Zabbix 에이전트는 이러한 로그를 구문 분석하고 특정 트리거에 따라 경고를 발생시킬 수 없습니다). 하지만 중앙 로그 데이터베이스의 로그를 통해 이 작업을 계속 수행할 수 있습니다.
제가 궁금한 것은 이 접근 방식을 위험하게 만드는 일부 주요 정보를 간과하거나 누락하고 있는 것은 아닌지입니다.Red Hat Linux 및 SUSE Enterprise Linux와 같은 상업용 배포판에는 여전히 rsyslog가 포함되어 있는 것으로 나타났습니다. 이는 단지 호환성상의 이유일 수 있으며 사용이 필요하지 않을 수도 있습니다. 이 솔루션은 모든 배포판과 호환되는 일반적인 솔루션으로 간주되어야 합니다.