feature/refactor-monitor

[vegeterianlee]

No description provided.

[ty-kim7]

필요한 부분들 리뷰드렸습니다.

쓰레드의 메인 메시지 같은 경우는 Table보다 blockkit의 Section 기능을 활용해서 시각화 해주시면 더 보기 좋을 듯 합니다. 아래 예시 첨부

[ty-kim7]

현재 repo가 Public인데 아무리 랜덤값이라고 해도 부적절 해보입니다.
gitignore 처리 및 기존 Commit에서 삭제 후 강제 Push 부탁드립니다.

[ty-kim7]

서비스에서는 전월 동기까지는 불필요해보입니다.

[vegeterianlee]

1. iam_to_slack.json 파일을 제거한 후, force push를 적용했습니다. (말씀해주신 다른 사항들 모두 반영했습니다) merge해도 괜찮다면 진행하겠습니다.

2. 첨부해주신 이미지로 확인했을 때, 각 Thread에 Section fields를 적용하는 것으로 이해했습니다. fields 대신 Table Block을 적용한 이유는, Section Block에 아래 두 가지 제한이 있기 때문입니다.

• fields 최대 항목 수 10개 제한
  (https://docs.slack.dev/reference/block-kit/blocks/section-block/)
• text type을 mrkdwn으로 지정했을 때 3000자 제한
  (https://docs.slack.dev/reference/block-kit/composition-objects/text-object/)

해당 메인 메세지의 스레드로 설명드리면, IAM User별 비용 분석에서 aws:createdBy 태그가 없는 항목 단독으로 이미 17개 서비스 행이 존재하는 형태입니다. 이를 fields로 구성했을 때, 10개를 초과하는 형태이긴 합니다.

그리고 EC2 상세 정보의 경우, 각 리전별 인스턴스 목록을 블록으로 담아 보냈었는 데, section의 text가 3000제한을 넘겨서 보내지지 않는 문제가 발생했었습니다.

• 4월 3일 오전 10:21 EC2 Instance Report의 스레드가 없었던 이유가 그렇습니다.

3. 현재 구조는 단일 block의 텍스트 크기를 3000자 이하로 제한하고, 초과 시 동일 메시지 내에서 복수의 block으로 분할하여 테이블을 이어붙이는 식입니다. 그래서 길어질 경우, table이 분리되어 보입니다.

[ty-kim7]

네 고생 많으셨습니다!

slack 제약사항이 많아서 쓰레드 내부의 메시지의 경우 어쩔 수 없을것 같습니다.
메인 메세지 정도는 디자인 개선이 가능해보이는데 한번 적용해봐주실래요? (첨부는 예시입니다!)
section을 여러개 쓸 수 있어서 딱히 Block 수 제한과는 관계 없을 듯 합니다.

[vegeterianlee]

네엡, 말씀해주신대로 적용해보고 push 해두겠습니다.

[vegeterianlee]

말씀해주신 사항 모두 반영했습니다! 머지 이후엔 EventBridge cron으로 lambda를 스케줄링(22시)을 적용해보겠습니다.