제가 가진 주요 요구 사항은 여러 컴퓨터에서 결합된 로그를 보고 간단한 검색을 수행할 수 있어야 한다는 것입니다. 그러나 솔루션이 (핵심) 시스템의 나머지 부분에 최소한의 영향을 미치기를 바랍니다. 실시간 요구 사항이 없으며 프로세스가 비동기식일 수 있습니다.
처음에는 syslog가 좋은 옵션처럼 보였지만, syslog 서버가 죽으면 어떻게 될까요? 최악의 경우에는 핵심 시스템의 사용자에게 오류가 표시되고, 가장 좋은 경우에는 일부 로그가 손실됩니다.
그래서 여기저기 둘러보다가 Logstash를 발견했습니다(http://logstash.net/). 현재 내 생각은 다음과 같습니다.
- 각 서버(시스템의 핵심 구성 요소를 실행 중)에는 Logstash 에이전트가 실행 중입니다.
- 에이전트는 로그 파일을 모니터링하고 이를 ElasticSearch 클러스터로 보냅니다.
- Logstash UI를 사용하는 또 다른 서버가 있습니다
그런 식으로:
- 단일 실패 지점이 없습니다.
- ES 클러스터가 종료되더라도 에이전트만 영향을 받습니다. 애플리케이션은 여전히 파일에 로그를 기록합니다.
- ES가 돌아온 후 에이전트는 (희망적으로) 보류 중인 모든 로그를 파악하여 보낼 것입니다. (Logstash는 그렇게 할 만큼 똑똑합니까?)
이것이 효과가 있을 것 같나요? 아니면 다른 솔루션을 추천해 주실 수 있나요?
답변1
Rsyslog당신이 설명하는 기능 중 일부가 있고 프로젝트에도안정적인 메시지 전달에 관한 많은 문서.
즉, rsyslog를 사용하면 다음을 사용할 수 있습니다.RELP안정적인 syslog 메시지 전달을 위한 프로토콜을 사용하면 메시지 손실에 대해 걱정할 필요가 없습니다. 또한 원격 서버가 다운된 경우 rsyslog가 메시지를 버퍼링하는 로컬 스풀 파일을 구성하는 옵션도 있습니다. 리모컨이 다시 활성화되면 상담원이 따라잡을 것입니다.
또한 관계형 데이터베이스에 기록하도록 rsyslog를 구성한 다음 원하는 대로 데이터베이스를 중복되게 만들 수 있습니다(개인적으로는 syslog 서버가 클러스터링하기 더 쉽다고 생각합니다).
답변2
이 질문은 주제에서 벗어나 종료될 가능성이 높습니다. FAQ를 참조하세요.
그럼에도 불구하고 syslog(또는 모든 syslog 기반 시스템)는 정상적으로 작동해야 합니다. 결국 로그 손실이 우려된다면 일반 DR 시나리오의 일부로 syslog 서버를 백업해야 합니다. 매우 간단한 작업/요청입니다.