로그 파일 항목을 MySQL 데이터베이스로 가져오는 올바른/효율적/신뢰할 수 있는 방법은 무엇입니까?

로그 파일 항목을 MySQL 데이터베이스로 가져오는 올바른/효율적/신뢰할 수 있는 방법은 무엇입니까?

남용 패턴을 식별하기 위해 서버 액세스 로그 파일을 쿼리할 수 있기를 원합니다. 로그 파일은 실제로 쿼리하기가 쉽지 않으며 각 히트가 MySQL 데이터베이스의 행인 경우 원하는 작업을 수행하는 것이 상당히 쉬울 것입니다.

웹 서버를 변경하거나 요청 응답 시간을 늦추는 모듈을 사용하고 싶지 않습니다. 웹 서버는 텍스트 로그에 항목을 기록하도록 최적화되어 있으며 그렇게 되기를 원합니다. 즉. 웹 서버가 파일에 쓰고 나중에 일괄 처리를 통해 파일 항목을 데이터베이스 항목으로 이동하도록 합니다.

PHP는 나에게 가장 친숙한 서버 측 언어입니다. 파일을 열고 한 줄씩 구문 분석하고 해당 줄을 데이터베이스에 삽입하는 것은 간단합니다. 문제는 액세스 로그가 기관총처럼 기록된다는 것입니다. 웹 서버가 로그에 기록을 시도하는 동안 PHP는 로그를 구문 분석할 수 없습니다. 웹 서버는 PHP가 구문 분석하는 동안 참을성 있게 기다릴 수 없습니다.

중복된 항목을 가져오거나 항목이 누락되지 않고 동시에 작업을 수행할 수 있는 방법이 필요합니다.

그래서 저는 두 가지 아이디어를 가지고 있습니다. 첫째, 회전된 로그만 처리합니다 access.log.1. 이렇게 하면 실시간 성능이 떨어지지만 동일한 리소스를 놓고 경쟁하는 두 프로그램 간의 충돌을 피할 수 있습니다. PHP가 로그를 읽을 때 로그를 회전시키려는 로그 회전 문제가 여전히 남아 있습니다. 특히 반복하는 동안 파일 이름을 재사용하기 때문입니다. 동일한 로그를 다시 읽거나 이름 충돌로 인해 손실되지 않도록 하는 방법이 필요합니다.

둘째, 큐를 파이프처럼 사용할 수 있습니다. 나는 이전에 파이프를 사용해 본 적이 없어서 그것이 어떻게 작동하는지 모릅니다. 만약에:

  1. 웹 서버는 이를 일반 파일로 취급하여 마치
  2. 웹 서버는 다시 시작할 때 이를 일반 파일로 바꾸려고 시도하지 않았으며
  3. 파이프는 PHP가 호출되고 항목이 끝에서 제거될 때까지 순서가 지정된 대기열의 텍스트 항목만 보유합니다.
  4. 입구 부분을 당겨서 제거하세요...

그렇다면 내가 찾고 있는 것이 바로 그것이었을 수도 있다. 문제는 PHP를 호출하고 파이프에서 콘텐츠를 가져온 다음 종료하여 나중에 cron에서 다시 호출할 수 있느냐는 것입니다. 아니면 파이프를 사용하려면 PHP가 데몬처럼 지속적으로 실행되어야 합니까? 즉, 파이프의 반대쪽 끝에 아무것도 없으면 파이프가 파일처럼 여전히 물건을 담을 수 있습니까?

아니면 페이지 서비스 시간을 늦추지 않고 데이터베이스에 대한 로그를 안전하고 안정적으로 읽을 수 있는 다른 방법이 있습니까?

관련 정보