GCP Resource 생성 확인 하기 - 로그 탐색

 개요

리소스 생성 되는 로그를 카운팅하고, 알림을 받을 수 있도록 구성하기


쿼리 예시

🔸 Compute Engine VM 생성 확인

resource.type="gce_instance"

protoPayload.methodName="v1.compute.instances.insert"

🔸 Cloud Storage 버킷 생성 확인

resource.type="gcs_bucket"

protoPayload.methodName="storage.buckets.create"


🔸 IAM 사용자 생성 또는 서비스 계정 생성

protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"


🔸 Cloud SQL 인스턴스 생성

resource.type="cloudsql_database"

protoPayload.methodName="cloudsql.instances.insert"


🔸 Pub/Sub 주제 생성

resource.type="pubsub_topic"

protoPayload.methodName="google.pubsub.v1.Publisher.CreateTopic"


✅ 3. 공통 쿼리 필터로 생성 확인하기

protoPayload.methodName:("create" OR "insert")

위 쿼리는 모든 서비스에서 생성 관련 이벤트를 포괄적으로 탐색할 수 있어 유용합니다.
단, 너무 많은 결과가 나올 수 있으므로 시간 필터(오른쪽 상단) 또는 리소스 타입을 추가로 지정하는 것이 좋습니다.


✅ 4. 로그에서 확인 가능한 정보

로그 항목을 클릭하면 다음을 확인할 수 있습니다:

  • authenticationInfo.principalEmail → 누가 생성했는지

  • resourceName 또는 resource.labels.* → 어떤 리소스가 생성되었는지

  • timestamp → 언제 생성되었는지


로그 카운트 생성하기
Log-based Metrics 에서 Create metric 예시


버킷


모니터링 확인









댓글

댓글 쓰기

이 블로그의 인기 게시물

10.15 부동산 대책, 오피스텔도 LTV 40%인가요? 혼선 정리

라벨: 부동산대책 , 10·15대책 , 오피스텔 , LTV , 비주택대출 , 부동산정책 , 서울규제지역 , 대출규제 , 토지거래허가구역 , 정책해설 10월 15일 발표된 부동산 대책(10·15 대책) 이후 “오피스텔도 LTV 40% 로 줄었다”는 말이 돌고 있습니다. 하지만 이는 초기 문서와 보도 간 혼선 에서 비롯된 것으로, 정부 공식 해명에 따르면 비주택(오피스텔·상가)은 기존 LTV 70% 유지 가 맞습니다. 즉, 주택만 규제지역 지정으로 LTV 70% → 40% 이 적용됩니다. 1️⃣ 이번 대책의 핵심 변경점 규제지역 확대: 서울 전역과 경기 12곳이 조정대상지역·투기과열지구로 지정되었습니다. 주택 LTV: 규제지역 내 주택 구입 시 LTV 70% → 40% 로 하향 조정되었습니다. 토지거래허가구역: 서울 전역이 포함되며, 10월 20일경부터 효력이 발생합니다. 즉, 이번 대책의 직접적 영향은 **아파트 등 주택담보대출** 중심으로 적용됩니다. 2️⃣ “오피스텔도 40%?” — 혼선의 원인 정부 발표문 초안에는 “비주택 담보대출(오피스텔·상가) LTV 70% → 40%” 라는 문구가 포함되어 있었습니다. 언론이 이 문장을 그대로 인용하면서 “오피스텔도 40%로 제한된다”는 보도가 확산되었습니다. 하지만 이후 국토교통부와 금융위원회는 “ 비주택은 이번 규제 적용 대상이 아니다 ”라고 정정했습니다. 따라서 실제로는 **오피스텔 대출은 기존 70% LTV가 유지됩니다.** 3️⃣ 정부의 공식 정정 내용 오피스텔·상가 등은 비주택 으로 분류되어, 이번 주택담보대출 규제의 직접 적용 대상이 아님. ‘비주택 LTV 40%’ 표기는 자료 작성 오류 또는 과도한 포괄 표현 이었다고 정부가 해명함. 따라서 실무상으로는 기존처럼 LTV 70% 수준의 대출이 유지됩니다. 4️⃣ 실제로 어떻게 확인하면 될까요? 현재 금융기관별로 시행령 및 세부지...
자세한 내용 보기

Kubernetes Pod Pending 해결법: FailedScheduling 원인별 실전 점검 가이드

이미지
Kubernetes를 운영하다 보면 Deployment를 배포했는데 Pod가 Pending 상태에서 움직이지 않는 경우가 있습니다. 재시작부터 해보거나 무작정 노드를 증설하기 전에, 스케줄러가 남긴 이벤트를 읽으면 대부분의 원인을 빠르게 찾을 수 있습니다. 이 글에서는 실무에서 자주 만나는 FailedScheduling 메시지를 기준으로 CPU·메모리 부족, taint, nodeSelector, PVC, Pod 수 제한 문제를 순서대로 점검하는 방법을 정리합니다. 1. Pending은 장애 원인이 아니라 현재 상태다 Pending은 Pod 객체가 생성됐지만 아직 실행할 노드가 결정되지 않았거나, 컨테이너 실행에 필요한 준비가 끝나지 않았다는 뜻입니다. 따라서 kubectl get pods 결과만 보고는 원인을 알 수 없습니다. kubectl get pods -A --field-selector=status.phase=Pending 문제가 발생한 Pod를 찾았다면 가장 먼저 상세 정보와 이벤트를 확인합니다. kubectl describe pod <pod-name> -n <namespace> kubectl events -n <namespace> --for pod/<pod-name> describe 출력의 맨 아래 Events 영역에 있는 Reason과 Message가 핵심입니다. 여러 메시지가 반복된다면 가장 최근의 Warning / FailedScheduling 부터 읽습니다. 2. 가장 흔한 원인: CPU 또는 메모리 부족 다음과 같은 메시지가 보인다면 Pod가 요청한 리소스를 수용할 노드가 없다는 뜻입니다. 0/3 nodes are available: 3 Insufficient cpu. 0/3 nodes are available: 2 Insufficient memory. Kubernetes 스케줄러는 현재 사용률이 아니라 Pod에 설정된 resources.requests 의 합계를 기준으로...
자세한 내용 보기

애플 비전 프로 새 밴드 착용감 어떨까? Dual Knit Band 착용 경험 리뷰

새 밴드 착용감 어떨까? Dual Knit Band 착용 경험 리뷰 Apple Vision Pro의 Dual Knit Band 는 착용감과 안정성을 개선하기 위한 새로운 밴드 설계입니다. 본 글은 공개된 정보와 초기 평가를 참고해 착용 체감, 무게 분산, 통기성, 핏 조절 을 중심으로 정리했습니다. (실제 체감은 두상·머리 형태 및 사용 환경에 따라 달라질 수 있습니다.) 1) Dual Knit Band는 무엇이 달라졌습니까? 이중(dual) 구조 : 상단/후면 스트랩 분리 설계로 무게를 분산합니다. 통기성 니트 소재 : 장시간 착용 시 답답함을 줄이는 것을 목표로 합니다. Fit Dial 조절: 좌우 다이얼로 상·하 스트랩을 미세 조정해 개개인 핏을 맞출 수 있습니다. 사이즈 옵션 : 보통 Small / Medium / Large 선택지를 제공합니다. 호환성 : 지역/판매 정책에 따라 다를 수 있으나, 기존 모델과 호환 가능하다는 보도가 있습니다. 2) 착용감 체감 포인트 항목 체감 요약 코멘트 압박감 얼굴 전면 압박이 다소 완화 상·후면으로 무게가 나뉘어 이마/광대 압박이 줄어드는 느낌입니다. 무게 분산 뒤쪽 밸런스 향상 후두부 쪽 지지가 늘어 장시간 사용에서 안정감이 개선되었습니다. 통기성 열감/답답함 완화 니트 소재 특성상 땀·열 배출이 이전 대비 자연스럽습니다. 핏 조절 미세 조정 용이 ...
자세한 내용 보기