DEVOCEAN

AWS Logs

AWS 에서 돌아가는 서비스의 로그는 Cloudwatch 에 남는다. 보통 Cloudwatch 콘솔에 접근하여 log insight를 통해 로그 조회가 손쉽게 가능하다.

그러나 모두가 콘솔에 접근할 수 있는 것은 아니다. 모두를 콘솔에 접근할수 있도록 권한을 여는 것 또한 지양해야한다.

로그를 분석에 활용하기 위해, Cloudwatch 에 적재되는 로그를 Bigquery 등 데이터 적재 플랫폼으로 옮겨서 쿼리형태로 조회할수 있도록 해야한다.

그럼 서비스 배포후에 분석에 활용할 용도는 아니지만 일부 로그를 운영담당자가 아닌 다른 사람이 단발성으로 조회해야될 필요성이 있을때에는 어떤 걸 써야할까.

AWS SDK

Filter-log-events

이때 고려해볼수 있는게 filter-log-events이다. AWS SDK로 제공되는 함수로 aws cli, 와 각 프로그래밍 언어 sdk 로 제공된다.

aws logs filter-log-events --log-group-name /aws/lambda/test-lambda --filter-pattern "GOOD_LOG" --max-item 100`

GOOD_LOG 라는 단어가 들어간 로그 line 들이 필터가 되서 출력된다.

{
    "events": [
        {
            "logStreamName": "v1/i-003597",
            "timestamp": 1688694739833,
            "message": "2023-07-07 01:52:19,825 [INFO ] W-9000-model_1-stdout GOOD_LOG - Listening on port: /home/model-server/tmp/.ts.sock.9000",
            "ingestionTime": 1688694743834,
            "eventId": "37659151111114694581920535581775463561274027093781577769"
        },
        {
            "logStreamName": "v1/i-003597",
            "timestamp": 1688694739833,
            "message": "2023-07-07 01:52:19,826 [INFO ] W-9000-model_1-stdout GOOD_LOG - [PID]37",
            "ingestionTime": 1688694743834,
            "eventId": "37659151111114694581920535581775463561274027093781577770"
        },
....
],
    "searchedLogStreams": [],
    "nextToken": "Bxkq6kVGFtq2y_MoigeqscPOdhXVbhiVtLoAmXb5jCqhcZwWrCXypzoqFCef-6S2A-HSvMcd6sQw5n-fQIocA"
}

이 nextToken을 가지고 다음 검색을 하면된다.

다만 여기서 유의할 점이 있다. max-item 옵션을 줌으로써, return 되는 최대 아이템 개수를 조정할수 있는데 이 부분을 잘 이해해야한다.

즉 100개를 출력하고자하면 딱 100개가 나오는게 아니라 100개 미만이 나올 수 있다. 또한 nextToken 을 유의해야한다.

이슈사항

서비스 도입시에 이슈사항은 요 nextToken 을 넣어 다음 검색을 했을때, 갑자기 빈리스트가 나오고, 계속 검색을 해도 계속 빈리스트가 나오다가,

N번째쯤에 갑자기 결과값이 나오는 상황이었다. 당황스러웠다.

{
    "events": [],
    "searchedLogStreams": [],
    "nextToken": "Bxkq6kVGFtq2y_MoigeqscPOdhXVbhiVtLoAmXb5jCqhcZwWrCXypzoqFCef-6S2A-HSvMcd6sQw5n-fQIocA"
}

엥? 왜 빈리스트가 나오다가 몇번하니깐 결과값이 나오지?

이는 aws filter-logs-event 함수의 검색방식을 먼저 이해해야한다.

startTime 에서부터 stream 을 뒤져서 시간 순대로 검색을 이어나갈때, 검색할수 있는 데이터의 양이 한정되있다.

그 데이터 양을 한 구간이라고 칭해보면 첫 구간까지 검색을 완료했을 때 결과가 없으면 일단 빈리스트를 반환한다.

결과 반환과 함께 반환하는 nextToken 을 요청 파라미터에 첨부하여 다시 요청하면 nextToken 이 포인터 역할을 하여 검색했던 첫번째 구간의 다음 구간을 동일한만큼 다시 검색하고 또 반환.

다만 당연히 이때에도 결과로 또 빈리스트가 올 수 있는 것이다.

이런 과정이 반복된 후에 특정 구간 검색시에 해당 로그가 반환되면 갑자기 결과값이 채워져서 나갈 수 있다.

참고로 nextToken 이 없거나, 이전 token 과 같은 값이 오면 그때는 모든 stream 을 검색한것이다.

이런 검색방식이 정확히 documentation 에 기술되어있지 않아 검색과 실험을 통해 동작방식을 이해할수밖에 없었다.

이러한 동작 방식에서는 반복문을 넣어 빈리스트가 나오지 않을때까지 요청하는 방식으로 코드를 변경할 수 밖에 없다.

Wrap-up

AWS SDK 의 경우 사내 운영서버에서 각 서비스 API(ex. Cloudwatch API)에 접근해서 그 API 에서 또 운영서버의 필요 서비스를 확인하는 것이라서 그런지 속도도 느린편이다.

다행히 실서비스가 아니라 운영 편리를 위해 도입하는 것이기는 하지만 명확하지 않은 사용성이나 성능 측면에서 꼭 필요하지 않다면 도입을 다시 고려해보는 것이 좋을것같다는 생각이 든다.

혹시 필요하신분들 우리 cloudwatch client 설정값 참고하시라고 첨부하고 글을 마친다.

cloudwatch-client:
  client-configuration:
    connection-timeout: 1000
    socket-timeout: 2950
    client-execution-timeout: 15000
    request-timeout: 3000
    max-connection: 200
    max-error-retries: 5