Gunicorn: Gunicorn 기본 오류 로깅 날짜 형식이 표준 ISO8601이 아닙니다.

날짜 형식은 공통 로그 형식을 따릅니다. https://en.wikipedia.org/wiki/Common_Log_Format

아, 죄송합니다. 내 응답은 액세스 로그 형식에 관한 것입니다. 이 보고서는 오류 로그 형식에 관한 것입니다.

%{DATESTAMP} %{ISO8601_TIMEZONE} 를 사용할 수 있을 것 같습니다.

19.x의 경우 변경하기에는 너무 늦었습니다. 그것은 많은 로깅 사용량을 깨뜨릴 것입니다. 이것이 우리가 다음 메이저 버전에서 변경하고 싶은 것입니까?

@tilgovi 그래서 이게 원하던 건가요?

배포된 많은 시스템은 현재 형식에 의존합니다. 시스템과 같은 로그 숨김에 규칙이 항상 작성될 수 있기 때문에 많은 가치를 가져오지 않는 너무 큰 변경이 아닐까 걱정됩니다. 생각?

가능한 절충안은 전환 및 사용 중단일 수 있습니다. 표준을 따르지 않는 홀수(그러나 약간) 날짜 형식을 단계적으로 없애고 사용자에게 고정 로그 라인 형식으로 전환할 수 있습니다. 나는 파이썬을 통해 로거를 무시할 수 있다는 것을 알고 있지만 gunicorn이 경쟁 설정과 함께 제공되기 때문에 내가 가장 좋아하는 선택이 아닐 것입니다. DI는 OCD 사람이 아니지만 grok 쿼리를 요리하는 것은 현대적인 유형의 고문입니다. 당신이 설명하고 있는 것은 하나의 공간입니다 :D 그리고 어떤 것이 변경될 경우 필요한 것보다 더 길게 유지하는 것은 개발자의 몫입니다. 해야 한다면 세상의 끝은 아니지만 사람들이 버그가 있는 소프트웨어에 의존하더라도 우리는 계속 버그를 수정하고 있습니다... 그건 제 생각입니다... 질문이 저를 향한 것인지 확실하지 않습니다...

R20의 기본값을 변경할 수 있습니다.

이 형식은 실제로 매우 일반적입니다. RFC 3339 에는 이에 대한 메모가 있습니다.

참고: ISO 8601은 "T"로 구분된 날짜와 시간을 정의합니다. 이 구문을 사용하는 응용 프로그램은 가독성을 위해 공백 문자로 구분하여 전체 날짜 및 전체 시간을 지정하도록 선택할 수 있습니다.

오류 로그는 명령줄에도 인쇄되며 사람이 읽어야 하며 그대로 유지하고 싶습니다. 시간대 형식에 문제가 있습니까?

좋습니다. 즉, logstash의 grok에는 관대한 패턴이 아닌 엄격한 패턴이 미리 로드되어 있습니다. 나는 BBC/EBU에서 표준 사람들과 함께 일한 적이 있으며 이런 종류의 끔찍한 말을 기억합니다. 가독성을 위해 "(말) 공백 문자" 이것은 구현할 수 없습니다.... 그 문자는 무엇입니까? 물론 이 시점에서 모든 문자를 허용할 수 있으며 이는 좋지 않습니다. 그래서 Logstash의 사람들은 이것을 다음과 같은 방식으로 T 또는 space로 구현했습니다.

TIMESTAMP_ISO8601 %{YEAR}-%{MONTHNUM}-%{MONTHDAY}[T ]%{HOUR}:?%{MINUTE}(?::?%{SECOND})?%{ISO8601_TIMEZONE}?

또한 이것은 문제의 내용이 아닙니다. 문제는 표준에서 허용하지 않는 공백이 있는 시간대 접미사입니다.

불행히도 이 형식은 일반적이지 않습니다. 이 형식은 gunicorn에만 해당하는 비정통적 형식입니다. 나는 이것이 우리가 공백에 대해 논쟁하는 것이 얼마나 어리석은 소리인지 알고 있지만 언어와 automotons 구문에 관해서는 모든 것입니다.

도움이 됩니다, @kozmaz87. 사양을 파헤쳐 주셔서 감사합니다.

그러나 우리가 여기 있기 때문에 액세스 로그 형식도 지적하고 싶습니다. 이 형식은 훨씬 더 나쁩니다. 코드에서 코드의 출처를 찾지도 못했습니다... 꽤 애매한 구성 메커니즘으로 구성되어 있습니다. 다른 곳에서 할당됨. 조사하기 위해 코드를 체크아웃하지 않았지만 다음과 같은 출력이 생성됩니다.

127.0.0.1 - - [13/Aug/2018:15:03:26 +0000] "GET /debug/sms HTTP/1.1" 400 74 "-" "python-requests/2.18.4"

gunicorn 문서를 보면 이 로그의 두 번째 부분이 이유가 무엇이든 '-'라는 것을 알 수 있습니다... 세 번째는 사용자여야 하며, 이 역시 '-'로 평가되는 이유를 잘 모르겠고 다음이 사랑스럽습니다. 시간이 ':'로 연도와 결합되는 날짜 형식과 물론 좋아하는 공백으로 구분된 시간대 접미사. 그러나 주변을 파헤친 후 이것이 nginx가 기록하는 방식이라는 것을 알았으므로 nginx 액세스 로그를 모방하려고 시도하여 이 공간으로 구분된 시간대가 시작되는 곳이라고 가정합니다. HAProxy는 시간대 접미사를 설정하지 않는다는 점을 제외하고는 이것을 사용합니다...

벌목이 미쳤어요... 누가 얼음물 한 양동이 좀 가져다주세요 :)

액세스 로그 형식은 확실히 "공통"입니다: https://en.wikipedia.org/wiki/Common_Log_Format

하지만 마지막에 리퍼러와 사용자 에이전트를 추가합니다. --access-logformat 플래그 참조: http://docs.gunicorn.org/en/latest/settings.html#access -log-format

나는 그것을 깨닫는다. 두 번째 항목이 '-'인 것이 재미있습니다. :D 구현한 사람이 이것을 가지고 '-'

현재 로그 형식을 유지합니다. imo 공통 형식이 좋으며 업스트림 서버의 변경 사항에 대해 알지 못합니다. 생각? cc @tilgovi

범프 @tilgovi 도 @berkerpeksag

문제를 종료하면 해결되지 않습니다. @tilgovi 가 말했듯이 우리는 [공통 로그 형식](
https://en.wikipedia.org/wiki/Common_Log_Format.

나는 우리가 이것을 열어둘 수 있다고 생각한다. 오류 로그에 공통 로그 형식을 사용하지 않습니다. 공통 로그 형식은 액세스 로그 형식이며 거기에서 사용합니다.

사실, 신경 쓰지 마세요. 나는 지금 다시 확인했고 우리는 둘 다에 대해 동일한 시간 형식 문자열을 사용합니다. 그것이 어떤 대안보다 나에게 더 나은 것 같습니다. 액세스 로그와 오류 로그의 날짜 형식이 다른 것을 원하지 않습니다.

이제 문제를 더 잘 이해하고 다시 열어야 한다고 생각합니다.

다음은 기본 설정이 있는 Gunicorn의 출력 예입니다.

[2019-01-25 11:44:34 -0800] [22794] [INFO] 기니콘 시작 19.9.0
[2019-01-25 11:44:34 -0800] [22794] [INFO] 듣기 : http://127.0.0.1 :8000 (22794)
[2019-01-25 11:44:34 -0800] [22794] [INFO] 작업자 사용: 동기화
[2019-01-25 11:44:34 -0800] [22797] [INFO] pid가 있는 부팅 작업자: 22797
[2019-01-25 11:44:36 -0800] [22797] [정보] 127.0.0.1 - - [25/Jan/2019:11:44:36 -0800] "GET / HTTP/1.1" 200 14 " -" "컬/7.54.0"

문제는 액세스 로그의 공통 로그 형식을 구문 분석하는 것이 아니라 _전체 로그 줄_을 구문 분석하는 것입니다.

Gunicorn은 로그 라인의 시작 부분에서 타임스탬프, pid 및 레벨을 출력합니다. 액세스 로그 라인 _또한_에는 고유한 타임스탬프가 있는 공통 로그 형식의 메시지가 있습니다.

타임스탬프가 어떻게 같은 형식이 아닌지 주목하십시오. 이 문제에 대한 원래 요청은 _일반 로그 형식과 마찬가지로_ 로그 행 시작 부분의 타임스탬프에 공백이 없도록 하는 것이었습니다.

다음과 같이 보일 것입니다.

[25/1/2019:11:44:34 -0800] [22794] [INFO] gunicorn 시작 19.9.0
[25/1/2019:11:44:34 -0800] [22794] [INFO] 듣기: http://127.0.0.1:8000 (22794)
[25/Jan/2019:11:44:34 -0800] [22794] [INFO] 작업자 사용: 동기화
[25/1/2019:11:44:34 -0800] [22797] [INFO] pid가 있는 부팅 작업자: 22797
[25/Jan/2019:11:44:36 -0800] [22797] [INFO] 127.0.0.1 - - [25/Jan/2019:11:44:36 -0800] "GET / HTTP/1.1" 200 14 "-" "컬/7.54.0"

공통 로그 형식이 국제적이지 않기 때문에(짧은 월 이름을 가짐) 대답은 아마도 아닐 것입니다.

그러나 각 로그 줄의 시작 부분에 있는 타임스탬프를 ISO8601 타임스탬프로 변경할 수 있습니다.

https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

날짜와 시간 사이의 공백은 실제로 T 문자 대신 허용되지만 시간과 영역 오프셋 사이의 공백은 허용되지 않습니다.

다음은 유효한 ISO8601 형식입니다.

• [2019-01-25T11:44:34-0800]
• [2019-01-25 11:44:34-0800]

지금 가지고 있는 것과 비교:

[2019-01-25 11:44:34 -0800]
                    ^ there is a space here

하지만 배포된 시스템을 깨는 것에 대해 매우 걱정할 것입니다.

잘 구문 분석/재포맷 로그는 logstash와 같은 도구를 쉽게 처리할 수 있으므로 문제인지 확실하지 않습니다. 지금은 그대로 두겠습니다.

사람들이 다른 형식의 액세스 로그를 원하는 경우 특정 식별자를 추가할 수 있습니까? 그렇게 하면 형식이 깨지지 않을 것입니다. 그러나 오류 로그는 형식을 지정하는 방법을 제공하지 않기 때문에 문제가 됩니다. 그러한 경우 환경 변수가 그렇게 할 수 있습니까?

액세스 로그 형식이 변경되어서는 안 된다고 생각합니다. 현재 일반적인 로그 형식이며 --access-log-format 설정이 있습니다.

액세스 로그 형식은 핸들러에 전달되는 액세스 로그의 _message_ 형식만 지정합니다. 그러면 핸들러에는 자체 포맷터가 있습니다.

stdout 및 stderr의 스트림 핸들러에 대한 기본 포맷터는 시작 부분에 타임스탬프를 넣습니다. 이는 기본 구성에서 액세스 로그에 _2_개의 타임스탬프가 있음을 의미합니다. 하나는 시작 부분에, 다른 하나는 메시지에 있습니다.

핸들러의 포맷터를 변경하려면 --logconfig 옵션(파일 또는 사전) 중 하나를 사용해야 합니다.

기본 포맷터에서 ISO8601 타임스탬프를 갖는 것을 고려해야 합니다.

로그 구문 분석/재포맷은 logstash와 같은 도구를 쉽게 처리할 수 있습니다.

예, 하지만 이러한 도구가 기본 제공 패턴으로 타임스탬프를 구문 분석하여 사용자가 정규 표현식을 작성할 필요가 없을 때 매우 편리합니다. 원래 문제는 grok에 ISO8601 타임스탬프에 대한 내장 패턴이 있기 때문에 열렸습니다.

@tilgovi 호환성을 깨고 싶지 않습니다. 또한 NGINX는 ISO8601 형식 또는 공통 로그 형식을 사용하여 시간을 설정할 수 있는 가능성을 제공합니다.

$time_iso8601
local time in the ISO 8601 standard format
$time_local
local time in the Common Log Format

https://nginx.org/en/docs/http/ngx_http_log_module.html

유산을 손상시키지 않기 때문에 똑같이 할 것입니다. Btw 우리는 출력에 액세스 로그 라인을 표시해야 하지 않습니까? PID가 있는 첫 번째 헤더가 없어야 하는 것 같습니다. 생각?

기본 포맷터의 일부로 만드는 것에 대해 일부 도구가 손상될까 걱정됩니다. 사용자 지정 환경 변수 TIME_ISO8601=true 를 사용하여 강제로 적용하는 것은 어떻습니까?

호환성을 깨고 싶지 않습니다.

나도하지 않습니다. 잘못된 이유로 티켓을 닫은 것 같아서 티켓을 다시 열고 싶었습니다. 우리 둘 다 문제가 공통 로그 형식에서 변경되는 것처럼 응답했습니다. 문제는 액세스 로그 메시지 형식이 아니라 기본 포맷터의 타임스탬프입니다. 더 많은 논의를 할 수 있어서 기쁩니다. 하지만 대답은 아마도 여전히 아무것도 하지 않는 것입니다.

Btw 우리는 출력에 액세스 로그 라인을 표시해야 하지 않습니까? PID가 있는 첫 번째 헤더가 없어야 하는 것 같습니다. 생각?

가능한. 잘 모르겠어.

사용자 정의 환경 변수를 갖는 것은 어떻습니까?

괜찮아. 사용자는 고급 로깅 ​​구성을 사용하여 항상 로그를 완전히 제어할 수 있습니다. 사용자가 구성 파일을 사용할 필요가 없도록 --log-level 와 같은 CLI에 대한 일부 설정을 간단하게 만들려고 합니다. --log-date-format 를 추가할 수 있을까요? iso8601 와 같은 기호 문자열도 인식할 수 있습니다. 이 설정은 --log-config 또는 log_config_dict 사용을 원하지 않는 사용자를 위한 것입니다.

한편 @tilgovi 20.0 릴리스는 python 2와의 호환성을 깨고 있으므로 형식을 변경하기에 좋은 시기입니다.

어떤 유산에 대해서도 내가 더 걱정하는 것은 ISO8601이 사람의 눈으로 분석하기 어렵고 나를 포함한 많은 사람들이 콘솔을 사용하여 무슨 일이 일어나고 있는지 관찰하고 있다는 것입니다.

다음을 제안하고 싶습니다.

• [ ] stdout 및 stderr 로그에서 이 형식을 사용하도록 강제하는 -iso8601 옵션을 추가합니다(제안하는 것처럼).
• [ ] 액세스 로그에 이 형식으로 시간을 표시하는 형식에 옵션을 추가합니다.

우리가 여기에 있는 동안 시간 동안 UTC를 사용하기 위해 -utc 옵션을 가질 수도 있습니까? 생각?

확실히 하기 위해 기본값을 변경하면 제안된 diff가 됩니다.

diff --git a/gunicorn/glogging.py b/gunicorn/glogging.py
index 56cc5bd..0735e58 100644
--- a/gunicorn/glogging.py
+++ b/gunicorn/glogging.py
@@ -80,7 +80,7 @@ CONFIG_DEFAULTS = dict(
         formatters={
             "generic": {
                 "format": "%(asctime)s [%(process)d] [%(levelname)s] %(message)s",
-                "datefmt": "[%Y-%m-%d %H:%M:%S %z]",
+                "datefmt": "[%Y-%m-%d %H:%M:%S%z]",
                 "class": "logging.Formatter"
             }
         }
@@ -175,7 +175,7 @@ class Logger(object):
     loglevel = logging.INFO

     error_fmt = r"%(asctime)s [%(process)d] [%(levelname)s] %(message)s"
-    datefmt = r"[%Y-%m-%d %H:%M:%S %z]"
+    datefmt = r"[%Y-%m-%d %H:%M:%S%z]"

     access_fmt = "%(message)s"
     syslog_fmt = "[%(process)d] %(message)s"

액세스 로그 토큰에서 ISO8601 날짜 시간을 사용하는 옵션이 흥미롭다고 생각하지만 이 문제의 동기와 별개입니다.

그건 그렇고, 나는 이것에 대해 강하게 느끼지 않습니다. 😄 저는 단지 문제를 정확하게 표현하고 싶을 뿐입니다.

우리는 그것에 대해 조금 더 생각해야 할 것입니다. 나는 그것을 20.1로 연기하여 우리에게 몇 번을 허락합니다.

친애하는 개발자 여러분,
요청 손실 문제에 직면해 있습니다(Gunicorn과 관련 없음). Apache 서버 중 하나의 이 예에서와 같이 마이크로초를 포함하는 정확한 타임스탬프를 가질 수 있어야 합니다. 2019-10-30 14:27:16.960421 . 그것은 그것을 고려한 멋진 향상이 될 것입니다.

log-date-format iso8601 플래그가 gunicorn의 다음 버전에서 사용 가능하게 된다면 어떤 희망이 있습니까?