nginx 의 errorlog 와 access로그 분석
12083 단어 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
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
간단! Certbot을 사용하여 웹 사이트를 SSL(HTTPS)화하는 방법초보자가 인프라 주위를 정돈하는 것은 매우 어렵습니다. 이번은 사이트를 간단하게 SSL화(HTTP에서 HTTPS통신)로 변경하는 방법을 소개합니다! 이번에는 소프트웨어 시스템 Nginx CentOS7 의 환경에서 S...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.