소개

이것은 Sansan Advent Calendar 2017의 24 일째 기사입니다.

...

프로덕션에서 Lambda의 함수가 xx 개 이상 움직이고 있으며 장애 발생시 조사에는 CloudWatchLogs를 열심히 사용할 수밖에 없다

apex로 로그를 볼 수있는 방법도 없지만 tail하기가 어렵습니다.

CloudWatchLogs에 계속 넣어두는 것도

CloudWatchLogs 빨리 좋은 느낌이 되길 바래

그래서 이미 fluentd등에서 수집하고 있는 어플리케이션 로그나 액세스 로그와 같이 S3에 보관해, Elasticsearch에 올려 Kibana에서 검색, 분석할 수 있도록(듯이) 하고 싶었습니다. CloudWatchLogsAPI와 fluent-plugin-s3을 사용하여 Lambda 로그를 저장, 분석 및 시각화할 수 있습니다.

포기한 방안

fluent-plugin-cloudwatch-logs에서 수집하려고했습니다. 그러나 새롭게 만들어지는 LogStream의 수집이 불가능해 이유도 잘 모르고 포기했다. fluentd를 pry로 멈추고 상당히 디버깅했지만, fluentd 힘 더 원한다…! 되었습니다.
Lambda의 로그는 CloudWatchLogs의 LogGroup 이하에 LogStream으로 만들어져 가지만, LogStream에 [$LATEST]라는 Lambda의 버전 접두사적인 녀석이 들어가기 때문에 fluentd의 buffer_path 설정과 궁합이 나빴습니다. (이 사양 진짜로 그만두었으면 좋겠다.
또, 50개 이상의 LogStreams가 있을 때, 이 plugin에서는 로그를 취급하는 Array가 예기치 않은 중첩 구조가 되어 버렸기 때문에 수정했습니다.
둘 다 병합되었지만 힘 부족으로 인해이 플러그인에서 수집을 완료 할 수 없었습니다.

htps : // 기주 b. 코 m / 료타라이 / f ぅ 엔 t p ぅ 긴 - c ぉ 우도 t ch - ぉ gs / 푸 l / 80
htps : // 기주 b. 코 m / 료타이 / f ぅ 엔 tp ぅ 긴 - c ぉ 우도 t ch - ぉ gs / 푸 l / 84

자세한 설명

피타고라 장비

람다

우선 CloudWatchLogs의 API를 두드리는 Lambda를 만들었습니다. Python3.6에서 구현했습니다.
이 Lambda는 CloudWatchLogs.Client.create_export_task를 두드리고 있습니다.
ht tp // 보라 3. Red d. cs. 이오 / 엔 / 아 st / 레후 렌세 / 세 r ゃ 세 s / ぉ gs. html # C ぉ 우도 tch ぉ gs. C 엔 t. c Ret_E x rt_ta sk

그러나 내보내기 대상으로 하는 기간의 지정은 코드에 두고 싶지 않았습니다. (create_export_task의 from, to 지정)
그 때문에, 전회 실행시의 타임 스탬프를 S3상에 두도록 하고, 이것이 없으면 현재로부터 n시간분 export 하고 있으면 from에 세트 한다고 하는 구현으로 했습니다. 이렇게 하면 실행 타이밍은 CloudWatch Events의 Rule에서만 제공됩니다.

Lambda 주변

fluent-plugin-s3에서는 S3에서 로그를 캡처할 수 있습니다. S3 이벤트 알림으로 SQS에 흐르고 있습니다. 그리고는 비교적 보통입니다.

그림

그건 그렇고

그게 이것이 아-이므로, 실은 앞으로 한 걸음 곳에서 프로덕션 투입할 수 없습니다. 연내에는 해두고 싶습니다.
현재의 직장에서의 특이적인 이야기가 얽히는 fluent-s3-plugin 관련의 설정에 대해서이므로, 근저로부터 덮는 것 같은 이야기가 아닙니다. 만약 같은 구성을 생각하고 있는 사람이 있으면 안심해 주었으면 합니다.

마지막으로

CloudWatchLogs를 사용하기 쉽고 Lambda 로그가 자동으로 S3로 계속 내보내는 설정을 원합니다. Lambda를 위해 Lambda를 만드는 것이 줄어들면 좋겠다고 생각하므로, 산타씨(AWS) 아무쪼록 잘 부탁드립니다.