| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
- beebox
- cloud
- bWAPP
- AWS
- datastructure
- pwnable
- c
- EC2
- fork-bomb
- backjoon
- basicrce3
- CodeEngn
- System
- Linux
- 유석종교수님
- 백준
- 자료구조
- acc
- SISS
- 와이어샤크
- Reversing
- mount
- htmlinjection
- S3
- Dreamhack
- Systemhacking
- python
- Reflected
- Upstage
- wireshark
- Today
- Total
목록Upstage (2)
Ctrl + Shift + ESC
작업 동기배포는 자주 일어나지만, 배포 직후 “정말 서비스가 정상 동작하는지”를 확인하는 과정은 생각보다 자주 수동에 의존하게 된다.특히 현재 프로젝트에서는 DEV 환경에서는 배포가 끝난 뒤 주요 기능을 직접 눌러보거나, 문제가 생기면 로그를 보면서 롤백 여부를 판단하는 식으로 운영되는 경우가 많았다. 얼마 전에도 Prod에 배포했는데, 테스트를 진행하지 않고 배포하다 보니 주요 기능에 문제가 발생한 경험이 있었다.이번 작업에서는 이 과정을 조금 더 자동화했다. 목표는 다음과 같다.DEV 배포 직후 핵심 기능이 정상인지 자동으로 확인할 것실패 시 어떤 기능이 깨졌는지 구조화해서 수집할 것원인 후보와 추천 조치를 LLM이 요약할 것 (접근성)운영자는 Discord에서 결과를 보고 다음 액션을 결정할 수 있..
문제 정의현재 저희 시스템의 로그 수집 구조는 다음과 같습니다.EC2 로그→ Promtail→ Loki (로그 저장)→ Grafana (조회, 알림, 시각화) Promtail은 로그 파일이 존재하는 서버에 설치되어 로그를 수집하고, 이를 Loki로 전송합니다.Loki는 Promtail로부터 전달받은 로그를 저장하고, Grafana로부터 들어오는 로그 쿼리 요청에 대해 결과를 반환합니다.개발자는 Grafana를 통해 로그를 조회하거나, 특정 조건에 대한 알림을 설정할 수 있습니다. 문제는 로그의 양입니다.실제 운영 환경에서는 Loki뿐 아니라 CloudWatch Agent 등 다양한 방식으로 로그를 수집하고 있습니다. 하지만 이렇게 수집된 로그들은 분석되지 않으면 그저 쌓이기만 하는 데이터에 불과합니다...