nginx 의 errorlog 와 access로그 분석

12083 단어 nginx
nginx 설정 에서 로그 와 관련 된 설정 은 주로 다음 두 명령 을 중심 으로 합 니 다.
1、error_log
2、access_로그: 로그 기록 
우선 강조해 야 할 것 은 access 로그 와 error 로그 가 상수 파일 이름 (access 지원 변수 파일 이름 때문에 나중에 설명 할 것 입 니 다) 이 라면 nginx 프로 세 스 는 프로 세 스 가 끝 날 때 까지 파일 설명 자 를 캐 시 합 니 다.
로그 의 fd 가 언제 바 뀔 까요?
1) 프로 세 스 다시 시작
2) NGX 를 받 았 습 니 다REOPEN_SIGNAL 신호, 새로운 로그 파일 생 성
다른 경우 로그 의 fd 가 변 하지 않 기 때문에 프로 세 스 가 실 행 될 때 로그 파일 을 삭제 하면 새로운 로그 파일 이 생 성 되 지 않 고 로 그 를 잃 어 버 립 니 다.
다음은 이 두 지령 의 경 위 를 상세 하 게 설명 한다.
1: 먼저 errorlog:
nginx 는 error 를 지원 하 는 두 모듈 이 있 습 니 다.로그 명령 어:
하 나 는 ngxerrlog_module, 이 모듈 은 하나의 명령 만 있 습 니 다. 바로 error 입 니 다.log, 설정 유형: NGXMAIN_CONF, 반전 함 수 는: ngxerror_log;
또 하 나 는 ngxhttp_core_module, 이 모듈 에 도 명령 이 있 습 니 다: errorlog, 설정 유형: NGXHTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF, 반전 함 수 는: ngxhttp_core_error_log。
static ngx_command_t  ngx_errlog_commands[] = {

    {ngx_string("error_log"),
     NGX_MAIN_CONF|NGX_CONF_1MORE,
     ngx_error_log,
     0,
     0,
     NULL},

    ngx_null_command
};
static ngx_command_t  ngx_http_core_commands[] = {
{ ngx_string("error_log"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_1MORE,
      ngx_http_core_error_log,
      NGX_HTTP_LOC_CONF_OFFSET,
      0,
      NULL },
}

이렇게 하면 몇 가지 의문 이 생 길 수 있다.
1: 왜 두 개의 같은 명령 이 같은 기능 을 실현 해 야 합 니까?
2: 두 명령 의 유형 은 모두 NGX 를 지원 합 니 다.HTTP_MAIN_CONF, 그러면 main 에 설 정 된 errorlog 는 도대체 어떤 것 을 사 용 했 습 니까?
3. 이들 의 역할 관계.
다음은 설명 하 겠 습 니 다.
nginx 모듈 등록 시 ngx 발견errlog_module 모듈 은 ngx 보다 먼저http_core_module 모듈 에 등 록 된.
nginx 에서 프로필 을 분석 할 때 errorlog, 등록 모듈 순서대로 명령 을 찾 습 니 다. 그러면 먼저 ngx 를 찾 을 수 있 습 니 다.errlog_module 모듈, 만약 이때, errorlog 는 main 에서 설정 되 어 있 습 니 다. 그러면 ngxerrlog_모듈 모듈 errorlog 의 NGXHTTP_MAIN_CONF match, ngx 실행error_log。
하면, 만약, 만약...log 는 http {} 에 설정 되 어 있 으 며, 등록 모듈 순서대로 명령 을 찾 아 ngx 를 찾 습 니 다.errlog_module 모듈 의 errorlog, type 이 NGX 인 것 을 발견 했다.HTTP_MAIN_CONF, 일치 하지 않 습 니 다. 계속 찾 아 보 세 요. ngxhttp_core_module 의 errorlog, type 은 NGXHTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF, match 후 ngx 실행http_core_error_log。
위 에 ngx 라 고 언급 되 어 있 습 니 다.error_log 와 ngxhttp_core_error_log 두 함수, 이 두 함수 의 기능 은 기본적으로 일치 하지만, 두 설정 역할 영역 이 다 르 기 때문에 설정 저장 위치 가 다 릅 니 다: ngxerrlog_module 는 cycle - > new 에 저 장 됩 니 다.log,ngx_http_core_module http core 모듈 데이터 구조 ngxhttp_core_loc_conf_s 의 errorlog (이 요약: clcf - > error log).
clcf->error_log 는 http 모듈 에 있 는 것 으로 http 요청 과 관련 된 로 그 를 기록 합 니 다.
cycle->new_log 는 프로 세 스 시작, 이벤트 등 을 기록 합 니 다.
그러나 주 프로 세 스 가 시 작 될 때 설정 파일 을 읽 지 않 았 습 니 다. 로그 인쇄 가 어디 에 있 는 지 지정 하지 않 았 습 니 다.nginx 는 이 때 오류 내용 이나 결 과 를 표준 출력 에 전송 할 수 있 지만 시스템 초기 화 상황 을 기록 하려 면 socket 감청 상황 을 로그 파일 에 기록 해 야 합 니 다.nginx 의 main 함수 에서 먼저 ngx 를 호출 합 니 다.log_init 함수, 기본 로그 파일 은 설치 경로 / logs / error. log 입 니 다. 이 파일 에 접근 할 수 있 는 권한 이 없 으 면 오류 가 발생 하여 종료 합 니 다.mian 함수 끝 에 ngxmaster_process_cycle 함수 가 호출 되 기 전에 이 로그 파일 을 닫 습 니 다.
main 에 만 error 를 설정 했다 면log, http {} 에 설정 되 어 있 지 않 으 면 clcf - > errorlog 할당 은 clcf - > errorlog, 다음 코드:
static char *
ngx_http_core_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child)
{
    ngx_http_core_loc_conf_t *prev = parent;
    ngx_http_core_loc_conf_t *conf = child;

    。。。。。。


    if (conf->error_log == NULL) {
        if (prev->error_log) {
            conf->error_log = prev->error_log;
        } else {
            conf->error_log = &cf->cycle->new_log;
        }
    }

    。。。。。。
}

근 데 왜 두 지령 을 합치 지 않 았 어 요?
우선 모듈 등록 순 서 를 살 펴 보 자.
ngx_module_t *ngx_modules[] = {
    &ngx_core_module,
    &ngx_errlog_module,
    &ngx_conf_module,
    &ngx_events_module,
    &ngx_event_core_module,
    &ngx_rtsig_module,
    &ngx_epoll_module,
    &ngx_regex_module,
    &ngx_http_module,
    &ngx_http_core_module,
    &ngx_http_log_module,
   ......
}

가시 ngxerrlog_module 와 ngxhttp_core_module 중간 에 n 다 중 모듈 이 있 습 니 다.이 모듈 들 은 http 에 독립 되 어 있 으 며 로그 의 인쇄 가 필요 합 니 다. 이 로 그 는 기록 이 필요 할 것 입 니 다.
이 모듈 을 절약 할 수 없습니다. 그러면 ngx 를 고려 하 십시오.http_core_module 의 errorlog 를 합 쳐 도 생각 만 해도 안 돼 요. 왜 요?
생각 ngxerrlog_module 은 errorlog 정보 가 어디 에 있 는 지 생각해 보 세 요. ngxhttp_core_module 의 error로그 정보 가 어디 에 있 습 니까?
ngx 호출 중error_log 에서 서로 다른 server 나 location 에 대한 error로그 정 보 는 어디 에 저장 합 니까?(모듈 간 깊이 결합 불가)
두 모듈 이 서로 영향 을 주지 않 기 위해 서 는 좋 은 방법 이 야!
2: accesslog
다음은 accesslog,access_log 명령 은 ngx 에 속 합 니 다.http_log_모듈 모듈.
ngx_http_log_module 은 세 가지 명령 이 있 습 니 다.
static ngx_command_t  ngx_http_log_commands[] = {

    { ngx_string("log_format"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_2MORE,
      ngx_http_log_set_format,
      NGX_HTTP_MAIN_CONF_OFFSET,
      0,
      NULL },

    { ngx_string("access_log"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF
                        |NGX_HTTP_LMT_CONF|NGX_CONF_TAKE123,
      ngx_http_log_set_log,
      NGX_HTTP_LOC_CONF_OFFSET,
      0,
      NULL },

    { ngx_string("open_log_file_cache"),
      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1234,
      ngx_http_log_open_file_cache,
      NGX_HTTP_LOC_CONF_OFFSET,
      0,
      NULL },

      ngx_null_command
};

모든 block 은 위의 명령 을 설정 할 수 있 습 니 다. 이 명령 들 은 각 block 설정 의 loc [ngx http log module. index] 에 대응 합 니 다. (이것 을 이해 하려 면 설정 파일 의 전체 해석 과정 과 block 대응 관 계 를 알 아야 합 니 다) 즉, 아래 의 데이터 구 조 를 알 아야 합 니 다.
typedef struct {
    ngx_array_t                *logs;       /* array of ngx_http_log_t */

    ngx_open_file_cache_t      *open_file_cache;
    time_t                      open_file_cache_valid;
    ngx_uint_t                  open_file_cache_min_uses;

    ngx_uint_t                  off;        /* unsigned  off:1 */
} ngx_http_log_loc_conf_t;

access 에 대하 여log 는 주로 다음 과 같은 몇 가지 가 있 습 니 다.
1、ngx_http_log_module 은 nginx 상태 기 마지막 단계 NGX 에 속 합 니 다.HTTP_LOG_PHASE 의 처리 모듈, 즉 http 요청 이 끝 났 을 때 실 행 된 것 입 니 다. 이 작업 은 이번 request 의 접근 상황 을 인쇄 하 는 것 입 니 다.
2、access_log 지원 변수 명령 경로:
     access_log  logs/'$remote_addr'access.log  main;
3. 변수 경로 든 상수 경로 든 모두 정 보 를 ngx 에 넣 었 습 니 다.http_log_loc_conf_t 의 logs 이 배열 에서 관리 합 니 다. logs 배열 의 요 소 는 ngx 입 니 다.http_log_t。
typedef struct {
    ngx_open_file_t            *file;
    ngx_http_log_script_t      *script;
    time_t                      disk_full_time;
    time_t                      error_log_time;
    ngx_http_log_fmt_t         *format;
} ngx_http_log_t;

상수 일 때 file 기록 을 사용 하면 이 파일 기록 은 cycle - > open 에 넣 습 니 다.files
struct ngx_open_file_s {
    ngx_fd_t              fd;
    ngx_str_t             name;

    u_char               *buffer;
    u_char               *pos;
    u_char               *last;

};

변수 일 때 script 기록 사용 하기
typedef struct {
    ngx_array_t                *lengths;
    ngx_array_t                *values;
} ngx_http_log_script_t;

4 、 errorlog 아니면 accesslog, nginx 는 파일 핸들 을 저장 하여 로그 파일 을 빠르게 작성 합 니 다.하지만 access 때문에log 지원 은 변수 명령 경로 에 따라 request 나 ip 에 따라 서로 다른 access 로 그 를 구분 하면 파일 핸들 을 저장 하 는 방식 으로 로그 파일 을 작성 하면 시스템 fd 의 대량 점용 을 초래 할 수 있 습 니 다.nginx 는 여기 서 최적화 되 었 습 니 다.
1) acess 로그 경 로 를 상수 로 지정 하면:
    access_log  logs/access.log  main;
    그럼 errorlog 와 마찬가지 로 파일 경로 이름 을 cycle - > openfiles 에서 갑 니 다. 이것 은 list 입 니 다. 경로 가 이 list 에 가입 할 때 재 작업 을 합 니 다.모든 모듈 이 초기 화 되 었 을 때 이 파일 경 로 를 순서대로 열 고 fd 를 가 져 와 인쇄 로 그 를 사용 할 수 있 습 니 다.
   로 그 를 인쇄 할 때 호출 함수: ngxwrite_fd
2) acess 로그 경 로 를 변수 로 지정 하면:
   script 태그 로그 파일 을 변수 파일 이름 으로 사용 합 니 다.
   로 그 를 인쇄 할 때 호출 함수: ngxhttp_log_script_write
  이 함수 에 서 는 캐 시 fd 에 대한 관리 가 구현 되 었 습 니 다.이것들 과 지령 openfile_log_cache 의 설정 은 밀접 한 관 계 를 가진다.
로그 작성 함수: 
static void
ngx_http_log_write(ngx_http_request_t *r, ngx_http_log_t *log, u_char *buf,
    size_t len)
{
    u_char     *name;
    time_t      now;
    ssize_t     n;
    ngx_err_t   err;

    if (log->script == NULL) {
        name = log->file->name.data;
        n = ngx_write_fd(log->file->fd, buf, len);

    } else {
        name = NULL;
        n = ngx_http_log_script_write(r, log->script, &name, buf, len);
    }
......
}

5. 캐 시 파일 설명자 에 대해 nginx 는 캐 시 파일 설명 자 를 관리 하 는 두 가지 명령 이 있 습 니 다.
하 나 는 본문 에서 말 한 ngxhttp_log_module 모듈 의 openfile_log_cache;
하 나 는 ngxhttp_core_module 모듈 의 openfile_cache;
전 자 는 access 변수 로그 파일 만 관리 합 니 다.
후 자 는 static, index, tryfiles, gzip, mp4, flv 를 포함 하여 관리 하 는 것 이 많 습 니 다. 보 셨 습 니까? 모두 정적 파일 입 니 다!
이 두 명령 의 handler 는 모두 함수 ngx 를 호출 하 였 다.open_file_cache_init, 이것 이 캐 시 파일 설명 자 를 관리 하 는 첫 번 째 단계 입 니 다: 초기 화
ngx_open_file_cache_t *
ngx_open_file_cache_init(ngx_pool_t *pool, ngx_uint_t max, time_t inactive)
{
    ngx_pool_cleanup_t     *cln;
    ngx_open_file_cache_t  *cache;

    cache = ngx_palloc(pool, sizeof(ngx_open_file_cache_t));
    if (cache == NULL) {
        return NULL;
    }

    ngx_rbtree_init(&cache->rbtree, &cache->sentinel,
                    ngx_open_file_cache_rbtree_insert_value);

    ngx_queue_init(&cache->expire_queue);

    cache->current = 0;
    cache->max = max;
    cache->inactive = inactive;

    cln = ngx_pool_cleanup_add(pool, 0);
    if (cln == NULL) {
        return NULL;
    }

    cln->handler = ngx_open_file_cache_cleanup;
    cln->data = cache;

    return cache;
}

nginx 관리 캐 시 파일 설명 자 를 볼 수 있 습 니 다. 빨간색 과 검은색 트 리 와 대기 열 을 사 용 했 습 니 다. 이 후속 은 한 편의 글 로 서술 하 는 것 이 좋 습 니 다. 관련 된 내용 이 좀 많 습 니 다. 본 고 는 로그 모듈 을 분석 하 는 것 을 위주 로 합 니 다.
6. 지령 openfile_log_cache
1) nginx 에서 이 명령 의 기본 설정 은: open 입 니 다.file_log_cache off;
access 변수 로그 파일 의 fd 에 캐 시 를 하지 않 고 파일 을 쓸 때마다 열 고 로 그 를 쓰 는 것 이다.그럼 이 파일 fd 는 언제 닫 습 니까?
이것 은 nginx 메모리 관리의 cleanup 와 관련 이 있 습 니 다. cleanup 는 등록 할 수 있 습 니 다. 메모리 풀 이 소각 되 었 을 때 cleanup 링크 의 각 cleanup handler 를 호출 합 니 다. (상세 한 것 은 nginx 메모리 풀 관 리 를 뒤 져 볼 수 있 습 니 다)
이 파일 fd 는 request 가 끝 난 후에 메모리 풀 을 없 앨 때 fd 를 닫 습 니 다.
오픈 설정log_file_cache off; 실행 코드 는 다음 과 같 습 니 다.
access 변수 파일 fd 를 가 져 오 는 함수 입 니 다. 반환 값 은 access 로그 의 fd 여야 합 니 다.
ngx_int_t
ngx_open_cached_file(ngx_open_file_cache_t *cache, ngx_str_t *name,
    ngx_open_file_info_t *of, ngx_pool_t *pool)
{
    time_t                          now;
    uint32_t                        hash;
    ngx_int_t                       rc;
    ngx_file_info_t                 fi;
    ngx_pool_cleanup_t             *cln;
    ngx_cached_open_file_t         *file;
    ngx_pool_cleanup_file_t        *clnf;
    ngx_open_file_cache_cleanup_t  *ofcln;

    of->fd = NGX_INVALID_FILE;
    of->err = 0;

    //  open_log_file_cache off  ,cache  
    if (cache == NULL) {

        ......

	//    cleanup
        cln = ngx_pool_cleanup_add(pool, sizeof(ngx_pool_cleanup_file_t));
        if (cln == NULL) {
            return NGX_ERROR;
        }

        //      ,  fd rc = ngx_open_and_stat_file(name, of, pool->log);
        rc = ngx_open_and_stat_file(name, of, pool->log);

        //        
        if (rc == NGX_OK && !of->is_dir) {
	    //  cleanup  ,           ngx_pool_cleanup_file,      close  fd
            cln->handler = ngx_pool_cleanup_file;
            clnf = cln->data;

            clnf->fd = of->fd;
            clnf->name = name->data;
            clnf->log = pool->log;
        }

        return rc;
    }
......

}

2) 오픈 을 설정 하면file_log_cache 는 4 가지 인 자 를 지원 합 니 다: max = N [inactive = time] [min uses = N] [valid = time] max  최대 캐 시 파일 설명자 수 inactive 가 몇 시간 동안 활동 하지 않 으 면 min 삭 제 됩 니 다.uses 는 inactive 시간 내 에 N 번 활동 해 야 캐 시 에 유효 하 게 inactive 를 검사 할 수 있 습 니 다.구체 적 인 캐 시 파일 fd 의 경 위 는 한 편의 글 로 상세 하 게 설명 할 필요 가 있 습 니 다. 여기 서 는 잠시 말 하지 않 고 최근 에 정리 할 시간 이 있 기 를 바 랍 니 다.The End

좋은 웹페이지 즐겨찾기