직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 서버운영14 CloudWatch 데이터 부족 경보: missing·ignore·breaching 선택 기준 CloudWatch의 데이터 부족을 정상값 0으로 단정하지 마세요. 계속 보내야 하는 지표인지, 오류가 있을 때만 보내는 지표인지부터 구분하고 누락 데이터 처리와 경보 이력을 확인합니다.적용 환경: AWS CloudWatch 일반 지표 경보, 공식 문서 2026-10-23 확인. 문서 기반 가이드이며 실제 서비스 설정 변경·시험 결과가 아닙니다.1. 원인: 값이 없는 것과 정상값은 다릅니다수집 장애로 지표가 끊길 수도 있고, 이벤트가 있을 때만 값을 내보내는 설계일 수도 있습니다. 먼저 계정·리전·네임스페이스·차원이 실제 자원과 맞는지 확인합니다. 지표를 잘못 선택한 문제를 누락 처리 설정으로 덮지 않습니다.2. 해결 순서: 지표의 의미에 맞춰 선택합니다값누락값을 평가할 때의 의미notBreaching임.. 2026. 10. 24. curl은 성공인데 HTTP 404일 때: 종료 코드와 응답 상태를 따로 확인 curl의 종료 코드 0만으로 HTTP 요청이 업무상 성공했다고 판단하지 마세요. HTTP 404 응답을 정상적으로 받았을 때 기본 curl은 0으로 끝날 수 있습니다. HTTP 오류를 실패로 처리하면서 본문도 남기려면 지원 버전의 --fail-with-body와 응답 코드를 함께 확인하세요.원인: 통신 처리 결과와 HTTP 의미를 하나로 본다프로세스가 응답을 받는 데 성공했다는 판단과, 서버가 요청한 자원을 제공했다는 판단은 다릅니다. HTTP 4xx·5xx와 연결·DNS·TLS 실패를 같은 오류로 처리하면 잘못된 재시도나 배포 성공 판정으로 이어질 수 있습니다. 자동화에서는 종료 상태와 HTTP 코드와 본문을 각각 기록하는 편이 원인을 좁히기 쉽습니다.조회 방식HTTP 404의 처리본문 처리기본 cu.. 2026. 10. 23. Linux 용량이 남는데 No space left on device: inode와 실제 저장 경로 확인 No space left on device가 나오는데 df -h에 여유가 있다면 실패한 경로의 파일시스템을 기준으로 df -i도 확인하세요. 데이터 블록과 inode 여유는 다른 정보입니다. 홈 디렉터리의 여유 공간을 보고 다른 마운트나 컨테이너의 저장 경로도 괜찮다고 판단하면 원인을 놓칠 수 있습니다.원인: 용량 수치 하나가 모든 자원을 뜻하지 않는다파일시스템은 파일 내용뿐 아니라 파일을 관리하는 정보도 필요합니다. 작은 파일이 많이 쌓이면 총 바이트만으로는 상태를 설명하기 어려울 수 있습니다. 또한 /tmp, 데이터 볼륨, 컨테이너 저장 경로가 서로 다른 파일시스템일 수 있습니다. 오류가 난 정확한 경로와 실행 환경을 먼저 적어야 합니다.관찰다음 확인주의블록 여유 있음같은 경로 df -i다른 마운트 .. 2026. 10. 19. systemd start-limit-hit 해결: 최초 실패를 고친 뒤 reset-failed로 복구 start-limit-hit나 Start request repeated too quickly가 보이면 먼저 제한에 도달하기 전의 최초 실패 로그를 찾으세요. reset-failed는 실패 상태와 시작 제한 카운터를 정리하지만 프로그램의 오류를 수정하지 않습니다. 원인을 고친 다음 대상 서비스만 재개하고 재발 여부를 확인해야 합니다.원인: 마지막 메시지는 시작을 막은 결과일 수 있다서비스가 짧은 시간에 여러 번 시작되면 systemd의 시작 횟수 제한에 걸릴 수 있습니다. 자동 재시작뿐 아니라 수동 시작도 해당 제한과 관계되므로 같은 start 명령을 연속 실행해 해결하려고 하면 진단이 더 어려워집니다. 마지막 제한 메시지 앞에 설정 누락, 실행 파일 오류, 의존 대상 접근 실패 같은 실제 원인이 있는지 .. 2026. 10. 18. Docker no space left on device 해결: 이미지·로그·볼륨 안전 정리 순서 Docker 빌드나 컨테이너 재시작 중 no space left on device가 나오면 무작정 docker system prune -a부터 실행하기 쉽습니다. 그러나 미사용 볼륨이나 이미지에 복구에 필요한 데이터가 있을 수 있습니다. 파일시스템 용량, inode, Docker 사용량을 차례로 확인한 뒤 영향이 작은 항목부터 정리해야 합니다.1. 디스크 용량과 inode를 먼저 구분한다df -hdf -idocker system dfdf -h는 바이트 기준 여유 공간, df -i는 파일 개수 한도인 inode를 보여줍니다. 작은 로그 파일이 매우 많으면 용량이 남아도 inode 부족으로 같은 오류가 날 수 있습니다. docker system df에서는 이미지, 컨테이너, 로컬 볼륨, 빌드 캐시가 차지한 .. 2026. 9. 22. Docker 로그 확인과 용량 관리: compose logs부터 로그 로테이션까지 서비스에 오류가 생겼을 때 로그를 열면 너무 많은 내용이 쏟아지고, 정작 필요한 시간의 기록은 찾기 어려울 수 있습니다. 반대로 로그가 계속 쌓여 서버 디스크를 차지하는 문제도 있습니다. 로그를 읽는 방법과 얼마나 보관할지는 함께 정해야 합니다.이번 글에서는 Docker Compose에서 서비스와 시간 범위를 좁혀 로그를 확인하는 방법, 로그 드라이버의 역할, json-file 로테이션 예시를 살펴봅니다. 헬스체크와 시작 순서 글에서 확인한 오류를 더 자세히 추적할 때 이어서 사용할 수 있는 내용입니다.1. Docker logs는 어떤 로그를 보여줄까?일반적으로 Docker가 수집하는 로그는 컨테이너 프로세스의 표준 출력(stdout)과 표준 오류(stderr)에서 나옵니다. json-file 드라이버는.. 2026. 9. 8. 이전 1 2 3 다음
