이벤트 로그 메트릭을위한 데이터 아키텍처?

서비스에 많은 수의 사용자 이벤트가 있으며 " D 날짜 이후 의 이벤트 유형 T 발생 횟수"와 같은 작업을 수행하려고 합니다.

우리는 두 가지 기본 결정을 내리려고합니다.

1. 무엇을 보관해야합니까? 모든 이벤트 저장 및 집계 저장

   • (이벤트 로그 스타일) 모든 이벤트를 기록하고 나중에 계산합니다.
   • (시계열 스타일) 매일 집계 된 단일 날짜 " D 의 이벤트 E 수"를 저장합니다.

2. 데이터를 저장할 위치

   • 관계형 데이터베이스 (특히 MySQL)
   • 비 관계형 (NoSQL) 데이터베이스에서
   • 플랫 로그 파일 (을 통해 네트워크를 통해 중앙에서 수집 syslog-ng)

표준 시스템이란 무엇입니까? 다른 유형의 시스템 비교에 대한 자세한 내용은 어디에서 읽을 수 있습니까?

추가 세부 사항:

• 총 이벤트 스트림은 하루 수십만 개에 달합니다.
• 그러나 현재 우리의 요구는 그 안에있는 특정 유형의 이벤트 만 계산하는 것입니다.
• 원시 데이터 또는 집계 결과에 실시간으로 액세스 할 필요는 없습니다.

IMHO는 "모든 이벤트를 파일에 기록하고, 나중에 스트림을 필터링하고 집계하기 위해 크롤링"하는 것은 매우 표준적인 UNIX 방법이지만, Rails-y 동포는 MySQL에 있지 않는 한 아무 것도 없다고 생각하는 것 같습니다.

그것은 항상 달려 있습니다. 나는 당신에게 새로운 관점을 제공하기 위해 조언을 드릴 것입니다

무엇을 보관해야합니까? 모든 이벤트 저장 및 집계 저장

(이벤트 로그 스타일) 모든 이벤트를 기록하고 나중에 계산합니다.

세부 사항을 놓치지 않을 계획이라면, 지금은 관련이 없지만 내 눈에 가장 좋은 접근 방식입니다. 때로는 결과가 나오면 X 또는 Y에 대해서는 관련이없는 다른 이벤트를 찾습니다. 또는 추가 정보를 가져 오지 않았지만 일부 분석 후에는 간단하게 수행 할 수 있습니다. 기록 된 정보는 기록하지 않았으므로 사진에 추가하려면 시간이 다소 걸립니다. .

(시계열 스타일)는 매일 집계 된 "날짜 D에 대한 이벤트 E 수"를 매일 저장합니다.

내일 구현하고 사용하려면 작동 할 수 있지만 새로운 요구 사항이 있거나 어떤 이유로 든 생략 한 다른 이벤트와의 상관 관계를 발견하면이 새로운 이벤트를 추가 한 다음 일부를 기다려야합니다 좋은 집계 수준을 갖는 데 오랜 시간

데이터를 저장할 위치

관계형 데이터베이스 (특히 MySQL)

첫 번째 옵션은 모든 이벤트를 기록하려고하면 DB에 무거울 수 있으므로 두려워하는 MySQL이 너무 작아 질 수 있으며 RDBMS 솔루션을 원할 경우 PostgreSQL과 같이 더 크게 생각할 수도 있고 Oracle 또는 DB2와 같은 독점적이라고 생각할 수도 있습니다 .

그러나 집계를 위해서는 좋은 선택이 될 것입니다. 생성 된로드에 따라 코드에서 집계하고 이러한 집계를 DB에 삽입 할 수 있습니다.

비 관계형 (NoSQL) 데이터베이스에서

이 솔루션을 사용하려면 Wikipedia에서 잘 읽는 방법을 따라야 할 접근 방법 이 도움이 될 수 있습니다. 경험이 충분하지 않기 때문에 해당 주제에 대해 많은 도움을 줄 수 없으며 대부분 rdbms를 사용합니다.

플랫 로그 파일 (syslog-ng를 통해 네트워크를 통해 중앙에서 수집)

나는 개인적으로 그 옵션을 선택하지 말 것을 권장합니다. 파일이 너무 커지면 파싱하기가 더 어려울 수 있지만 여전히 주요 목적을 알지 못합니다. 시스템을 추적하거나 단순히 로그를 확인하는 것입니다 파일 ...

그것이 도움이되기를 바랍니다!

로그를 구문 분석하고 결과를 계산하여 DB에 저장하는 아이디어가 유효하다고 생각합니다. 어쨌든 DB의 모든 원시 로그를 원한다는 것을 확신하지 못합니다 (동료가 제안한 것이라고 생각합니다). 이미 파일에 로그가 있습니다. 맞습니까? 그것들을 보관할 수 있습니다. 비트가 실제로 사용 사례에 달려 있다고 가정합니다.

또한 "댓글 답변"을 질문으로 옮기는 것에 대해서는 @ Thorbjørn Ravn Andersen에 동의하십시오.

사용 목적에 따라 다릅니다. 집계 값을 표시하는 표준 그래프 또는 보고서가있는 경우 이벤트가 들어올 때이를 필터링하고 해당 버킷으로 집계하는 것이 좋습니다. 특정 이벤트로 드릴 다운해야하거나 나중에 이벤트를 다시 분석 / 재 분류하려는 경우 개별 이벤트를 저장해야합니다.

시간과 공간이 있다면 일반적으로 데이터를 집계하지만 세부 사항을 (압축) 파일에 저장하는 것이 좋습니다. 거의 필요하지 않기 때문에 세부 정보에 쉽게 액세스 할 필요는 없지만 분류 기준이 변경되면 대량 재 처리에 사용할 수 있습니다.

모든 아키텍처 결정은 비즈니스 요구에 따라 이루어져야합니다. 귀하의 경우, 로그 시스템에서 어떤 정보를 얻고 자하는지, 그리고 저장 방법,이 정보를 요구하는 빈도 및 결과를 얻기 위해 기다리는 시간을 결정하기 위해 더 명확한 아이디어를 가져야합니다. . 이것이 로그 수집기, 이벤트 상관기 및 이와 유사한 응용 프로그램의 디자인을 주도합니다.

내 의견을 제시하기보다는 개발하려는 응용 프로그램과 유사한 응용 프로그램을 살펴 보는 것이 좋습니다. 그들 중 일부는 개발하려는 척하는 것보다 훨씬 강력 할 수 있지만 아키텍처 및 스토리지 정책을 살펴보면 상처를 입지 않습니다. 전문가 측면에는 RSA 및 Arcsight와 같은 SIEM 응용 프로그램이 있으며 오픈 소스 측면에는 Kiwi 또는 OSSIM (전문 기기 기반 버전도 있음)과 같은 이니셔티브가 있습니다.

고려해야 할 또 다른 사항은 도구로 얻은 결과를 사용하기 시작하면 경영진으로부터 더 많은 정보와 더 자세한 정보를 얻기 위해 많은 요청을 받기 시작한다는 것입니다. 그러니 ... 조심해서 사용하고 시야를 넓히십시오. 더 많은 작업을 제공 할 수 있지만 많은 지원과 가시성을 얻을 수 있습니다 (패키지에 압력이 가해 짐) ....