ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Apach Log 파일 분석 방법
    IT Information/최신 기술 동향 2013. 11. 8. 16:05
    반응형

    아파치로그파일


    인터넷의 사용이 대중화되어 가며 늘어나는 것 중의 하나가 사용자에게 실질적인 서비스를 제공하고 있는 입구의 역할을 담당하고 있는 웹 서버 입니다. 

     앞선 이야기에서 웹(Web) 서버를 운영하는 목적 중의 하나가 클라이언트에게 정보를 제공하는 제공자 역할을 하는 것이라고 언급한바 있습니다. 

    관리자의 입장에서는 어떤 형태의 자료가 가장 많이 이용되고 있느냐 하는 여러 가지 사실에 대해서 궁금해 할 것이고 , 그에 대한 결과를 더 나은 정보의 제공과 환경의 제공이라는 것에 이용함으로써 더욱 더 향상된 서비스를 제공할 수가 있게 되는 것입니다.


     - 로그파일이란 ?

    웹 서버를 운영하는 관리자들은 아파치의 확장된 로깅기능을 이용하여 웹 서버의 활동을 살펴볼 수가 있습니다. 

    n        에러로그

    n        접속 로그

    n        에이전트 로그

    n        참조로그

    에러로그에는 웹 서버 운영시에 발생되는 로그 및 CGI 와 같은 스크립트의 에러가 기록되게 되며, 우리가 생각하는 대부분의 접속 정보중의 하나인 ‘access.log’ 에는 서버로부터 전송되어 지는 정보가 기록되어 집니다. 사용자가 사용한 브라우저 정보는 에이전트 로그에 쌓이며 , 참조로그는 외부의 어떤 URL 을 참조하여 들어올 경우 설정이 되어 지게 됩니다.

    그러나, 지금 아파치 1.3.X 에 와서는 이렇게 나누어져 있는 것이 크게 의미는 없습니다. 왜냐하면, mod_log_config 모듈이 기본 access 로그를 대체하여 설정을 하게 되어져 있기 때문입니다.


    * 퍼미션 에러시

    1) Change "create 640 root adm" to "create 644 root adm" in /etc/logrotate.d/apache2 using your favorite text editor or, if you must script everything:


    sudo sed -i 's/create 640 root adm/create 644 root adm/g' /etc/logrotate.d/apache2


    2) Change the permissions on /var/log/apache2/access.log and /var/log/apache2/error.log to 644.


    sudo chmod 644 /var/log/apache2/access.log /var/log/apache2/error.log


    sudo vim /var/log/apache2/

    근데 루트리는 왜 

    apach 13 - 왜 9월 까지 바께 없지??


     ---------- 로그 보는 법

    1) 아파치 로그파일 기록되는 위치


    /var/log/httpd/access_log

    (레드햇의 경우임. 아파치를 컴파일해 설치했다면 /usr/local/apache/logs/access_log 임)


     


    2) 로그 기록 내용


     


    211.36.215.78 -  manager [22/Jun/2000:23:09:09 +0900] "GET / HTTP/1.1" 200 5

    ------------- ---  ----   ---------------------------  --- -- ---- -

          1        2    3               4                  5   6   7        8  9


     


    1 : 접속한 클라이언트의 IP 주소, 혹은 도메인 (httpd.conf 에서 HostnameLookups off 로

         설정하면 리버스 도메인 찾기를 않음)


    2 : REMOTE_IDENT (RFC 931 identification (아이덴티피케이션:동일함 확인)

         - 서버가 RFC 931 을 지원하는 경우 이 환경 변수에 클라이언트 시스템에서

         CGI프로그램을 실행시킨 사용자 이름이 저장된다고 합니다. 몰겠습니다.

         아직 한번도 여기 뭔가가 찍힐 것 확인 못해서..


    3 : 사용자이름( .htaccess .htpasswd 에 정의된 사용자 id )


    4 : 클라이언트(사용자 브라우저)의 접속시간정보 ( httpd 접속시간 )

        (구성 : [day/month/year:hour:minute:second zone])


    5 : 클라이언트(사용자 브라우저) 요청종류 ( GET , POST )


    6 : 클라이언트가 요청한 홈페이지 URL 주소 ( 요청한 자료 & 자료위치 )


    7 : 프로토콜 버전


    8 : 상태코드 ( 예. 200 정상처리 )


    9 : 전송데이터 크기 

        상태코드 일부 304 은 - (하이픈) 로 표시

            hits  - 모든 상태 코드 포함 

            files - 상태코드 200번만


    통계 프로그램 Webalizer (웹알리저) 2.00 기준입니다.


    응답 코드별 히트 수


    아래 코드는 상태 코드입니다. 클라이언트가 서버에게 요청했을 때 결과에 대한 상태 코드죠. 여기서 설명한 상태 코드 외에도 더 있지만 차후 추가하겠습니다.


    이 용어는 알아두셔야 될 듯.


    * entity body 

      엔터티 본체는 요청/응답 메시지를 통해서 전달될 수 있는 데이타 자체를 나타내는

      바이트 스트림(byte stream:흐름)이다.


    말은 거창 한데.. 그냥 데이타 보내고 받는 부분입니다. 이 스트림은 엔터티 헤더에서 지정되는 데이타 타입과 인코딩 형식을 갖게 된다.

     


    Code 200 - OK


     


    사용자가 요청한(get , post) 가 성공적으로 수행되었을 때 요청한 처리 결과를 클라이언트에게 전달되는 정보는 사용된 메소드(method:방법)에 따라서 달라진다.. 위에 get 이나 post 가 있습니다. 

     


    Code 206 - Partial(퍄셜) Content(컨텐트)  ( 일부 내용 )


     


    서버가 요청을 처리했지만 클라이언트에게 일부만 전달되었을 때..

     


    Code 301 - Moved Permanently (퍼머렌트리) ( 영구히, 불변하게 이동했다. )


     


    요청된 자원의 URL 값이 완전히 변경되었으므로 앞으로는 새로운 URL 값을 사용하여야 한다. 새로운 URL 값은 location(로케이션,위치) 헤더를 통해서 클라이언트에 전달된다. 또한, HEAD method 를 제외한 모든 경우에 요청  메시지의 entity body를 통해서 새로운 URL의 하이퍼 링크를 포함하는 짧은 메세지를 전달해 주어야 한다.


    웹 브라우저는 post method 를 사용한 요청의 결과로 301 상태코드를 전달받는 경우에는 자동으로 새로운 URL에 접속을 해서는 안된다. 반드시, 사용자의 확인을 거쳐야 한다.

     


    Code 304 - Not Modified ( 수정 모했따 )


     


    conditional(컨디셔널) 잠정적인(조건부의,가정적인) get method가 사용된 경우에 전달된다. Request(리퀘스트 : 요구)를 처리한 결과 If-Modified-since 헤더에  지정된 날짜/시간 이래로 지정된 문서가 변경된 사실이 없는 경우 서버는 이 상태코드로 응답해야 한다. 이때, entity body(실제 본문) 는 전송되지 않는다. (?) 웹브라우저 캐쉬사용 출력 속도 향상

     


    Code 400 - Bad Request  ( 잘못 요청 )


     


    Request(리퀘스트:요청) 메세지의 syntax(신택스:구문)가 잘못되어서 서버가 request 를 처리할 수 없다. 재 접속을 하는 경우에 클라이언트는 반드시 올바른 request메시지를 사용해야 한다.

     


    Code 401 - Unauthorized  (언어더라이즈드 :  권한없는, 허가받지 않은 )


     


    Request가 user authentication을 필요로 한다는 것을 클라이언트에게 알려주기 위해서 사용된다. WWW-Authenticate 헤더를 통해서 요청된 자원에 적용되는 challenge를 전달한다. 401 response(리스판(폰)스:감응,응답) 를 받은 클라이언트는 적절한  Authorization(어더리제이션:위임,권한부여) credentials(크리덴셜:신용 증명 물)를 포함하는 Authorization 헤더와 함께 다시 Request 메시지를 전송한다. Request 메시지에 그와 같은 Authorization credentials이 포함된 경우에  401 상태코드가 전달되면 user authentication(어던트케잇:인증)이 실패한 것을 나타낸다. - 인증 실패

     


    Code 404 - Not Found ( 못 찾았다 )



    반응형
Designed by Tistory.