검색 후 해결 방법을 찾았지만 누군가가 비슷한 종류의 혼란에 빠지면 여기에 그대로 두십시오. 결국 해상도를 참조하십시오.CloudWatch 로그 이벤트의 이벤트 시간이 잘못되었습니다.
AWS CloudWatch 로그 서비스가 내 로그 이벤트의 올바른 타임 스탬프를 이해하지 못하는 이유를 알아 내려고하고 있습니다. 현재 이벤트의 실제 타임 스탬프가 무엇이든 상관없이 모든 이벤트는 Time 2017-01-01에 저장됩니다.
내가 고정 표시기가 기록 된 이벤트를 절약 시스템 로그에서 로그를 공급하고있어 내가 형식으로 타임 스탬프를 넣어 고정 표시기를 구성 :
datetime_format = %y%m%d/%H%M%S
170105/103242 (%y%m%d/%H%M%S)
나는 매개 변수 awslogs 서비스를 구성
서비스를 다시 시작하고 서버를 누르지 만 CloudWatch로 이동하여 로그 항목을 볼 때 실제로 타임 스탬프 170105/103242로 시작하는 항목까지 실제로 모든 이벤트가 포함 된 날짜 2017-01-01에 속하는 이벤트로 저장됩니다. 01-01에서 01-05 사이
나는 awslogs.log 볼 때 나는 다음 볼 수 있습니다 라인 :
2017-01-05 11:05:28,633 - cwlogs.push - INFO - 29223 - MainThread - Missing or invalid value for use_gzip_http_content_encoding config. Defaulting to using gzip encoding.
2017-01-05 11:05:28,633 - cwlogs.push - INFO - 29223 - MainThread - Using default logging configuration.
이 나를 구성이 아마 실제로/읽기 DATETIME_FORMAT를 사용하지 않는 것을 생각하게하지만 난 그 이유를 이해하지 않습니다 기본값을 사용하여 끝나기로 결정합니다. 나는 일반적인 설정에서
use_gzip_http_content_encoding = true
을 입력하려고 시도했지만 오류는 변경하지 않습니다.
아이디어가 부족합니다. 누구든지 datetime_format이 실제로 올바르게 사용되는 방식으로 awslogger를 구성 할 수 있습니까?
편집 :
좋아, 문제 : 나는 현재 해결 :
에 무슨 일이 일어나고 있는지보고 지역 python2.7의 push.py에 더 많은 콘솔 로그를 해킹하고있어
초기 설치가 생성 된 후에이 프로젝트에 들어갔고 로거가 .conf 파일을 사용하도록 구성되었다고 생각합니다.
/etc/awslogs/awslogs.conf
동적으로 채워졌습니다.
환경에는 awslogs-agent-setup.py에게이 위치를 알려주는 스크립트가 있습니다.이 스크립트는 에이전트가 구성을 여기에서 읽어야한다는 것을 이해하도록했습니다.
그러나이 스크립트는 실제로는 어떻게하고 서비스가 시작했을 때, 실제로 디폴트 값을 포함/var/awslogs/etc/awslogs.conf
에서 설정을 읽을했는데 무엇을하지 않았다.
그래서 실제 해결 방법은 기본 구성에서 datetime_format 매개 변수를 변경하고 서비스가 사용하고있는 구성을 잊어 버리는 것입니다.
내가 다시 빌드하기 전까지 /etc/awslogs/awslogs.conf를 사용하는 EB 환경이 있었지만 대신/var를 사용하기 시작했습니다. 이것은 이상합니다. 왜 그것이 잘못된 경로를 사용하고 있는지 알아 냈습니까? – Sean256