수집 측정항목 개요

다음에서 지원:

Google SecOps는 보안 데이터 파이프라인의 상태, 볼륨, 처리 상태를 파악할 수 있도록 상세한 수집 측정항목을 제공합니다. 이러한 측정항목을 모니터링하는 것은 데이터가 올바르게 흐르도록 하고, 잠재적인 문제를 식별하고, Google SecOps 배포를 최적화하는 데 매우 중요합니다.

수집 측정항목이 중요한 이유

  • 상태 모니터링: 데이터 피드 및 수집 에이전트의 상태를 추적합니다.
  • 문제 해결: 데이터 삭제, 파싱 오류, 연결 문제와 같은 문제를 신속하게 진단합니다.
  • 볼륨 추적: 다양한 소스에서 수집되는 데이터의 양을 파악합니다. 이는 용량 계획 및 비용 관리에 유용합니다.
  • 정규화 통계: 통합 데이터 모델 (UDM)로 파싱되는 로그의 성공률을 모니터링합니다.
  • 알림: 데이터 흐름의 이상, 오류 또는 볼륨 변경에 대한 알림을 구성합니다.

수집 측정항목에 액세스하는 위치

  • Google Cloud Monitoring:

    • Google SecOps 측정항목을 Cloud Monitoring에 통합하여 수집된 로그 수, 크기, 정규화 이벤트와 같은 측정항목의 기준에 따라 대시보드를 만들고 알림 정책을 설정할 수 있습니다.
    • 측정항목은 Chronicle Collector 및 Chronicle Log Type과 같은 프리픽스 아래에서 사용할 수 있습니다.
    • 참조: 수집 통계에 Cloud Monitoring 사용

  • Google SecOps 상태 허브:

    • 상태 허브는 Google SecOps 플랫폼 내에서 데이터 소스 상태, 수집 볼륨, 파싱 상태를 모니터링할 수 있는 중앙 집중식 뷰를 제공합니다. 오류를 강조 표시하고 자세히 알아볼 수 있는 링크를 제공합니다.
    • 참조: 상태 허브 사용

  • BigQuery Export:

주요 측정항목 카테고리 및 필드

수집 측정항목은 수집 파이프라인의 여러 구성요소 (예: 전달자, 수집 API, 정규화 도구, 피드)로 분류됩니다. 다음은 표시되는 몇 가지 주요 필드입니다.

  • 볼륨 측정항목:

    • log_count: 수신 또는 처리된 원시 로그 항목 수입니다.
    • log_volume: 수신 또는 처리된 로그의 총 크기 (바이트)입니다.
    • event_count: 파싱 후 생성된 UDM 이벤트 수입니다.

  • 정규화 측정항목:

    • state: 로그의 정규화 프로세스 결과입니다 (예: parsed, failed_parsing, failed_validation).
    • total_events: 유효성 검사를 통과한 UDM 이벤트 수입니다.
    • total_error_events: 파싱 또는 유효성 검사에 실패한 이벤트 수입니다.
    • drop_reason_code: 로그 또는 이벤트가 삭제된 이유입니다.

  • Health 및 성능:

    • last_heartbeat_time: 수집기 또는 피드가 마지막으로 활성화된 시간을 나타냅니다.
    • drop_count: 구성요소에서 삭제된 로그 수입니다.
    • cpu_used, memory_used, disk_used: Bindplane 에이전트 또는 기존 전달자와 같은 온프레미스 구성요소의 리소스 사용률입니다.
    • latency_count: 수집과 정규화 사이에 걸린 시간과 관련된 측정항목입니다.

  • 할당량 측정항목 (수집 API):

    • quota_rejected_long_term_log_volume: 할당량 한도를 초과하여 거부된 로그의 볼륨입니다.

측정기준 이해

측정항목은 일반적으로 측정기준으로 분류되므로 데이터를 필터링하고 그룹화할 수 있습니다.

  • component: 측정항목이 참조하는 수집 파이프라인의 일부입니다(예: Forwarder, Ingestion API, Normalizer, Out-of-Band Processor).
  • log_type: 로그 소스의 유형입니다 (예: WINDOWS_DNS, CS_EDR).
  • collector_id / feed_id: 특정 수집기 인스턴스 또는 데이터 피드의 고유 식별자입니다.
  • namespace: 로그를 구성하는 데 사용되며 API 수집에 자주 사용됩니다.

참고: 수집 측정항목 스키마에 명시된 대로 집계 수집 측정항목은 특정 기간의 정확한 개수가 아니라 대략적인 볼륨의 지표로 취급해야 합니다.

원시 로그 볼륨과 대시보드 로그 볼륨 간의 불일치

Google SecOps 대시보드에 보고된 총 ingestion.log_volume (예: ingestion.component = "Ingestion API"를 쿼리할 때)은 인스턴스에 저장된 원시 로그의 총 볼륨과 크게 다를 수 있습니다. Google SecOps 인터페이스에는 인스턴스가 프로비저닝된 시점부터의 누적 수집 카운터가 표시되지 않습니다. 각 보고 도구는 최대 전환 확인 기간을 적용하므로 인스턴스가 도구의 보관 한도보다 오래되면 누적 총계를 계산할 수 없습니다.

이러한 차이는 다음과 같은 이유로 발생합니다.

  • 기간 및 전환 확인 한도:

    • 원시 로그 저장소: 구성된 인스턴스 보관 정책에 따라 데이터를 보관합니다. 인스턴스는 프로비저닝 이후 여러 해 동안 로그를 수집했을 수 있습니다.
    • Google SecOps 대시보드: 최대 전환 확인 한도인 365일 (또는 Bring Your Own Project (BYOP) 인스턴스의 경우 Cloud Monitoring에서 최대 24개월)까지 선택한 기간에 대해서만 ingestion.log_volume을 계산합니다. 인스턴스가 365일 넘게 데이터를 수집한 경우 대시보드 쿼리는 누적 과거 수집 볼륨보다 낮은 총계를 보고합니다.

  • 데이터 소스 및 수집 파이프라인:

    • 원시 로그 저장소: Google SecOps에 저장된 수집된 원시 로그 일괄 처리의 직접 바이트 크기를 기록합니다.
    • Google SecOps 대시보드: 약 5분 간격으로 비동기식으로 원격 분석을 수집하는 ingestion_metrics 테이블에서 ingestion.log_volume을 쿼리합니다. 이 원격 분석 파이프라인은 수집 지연 시간, 샘플링 또는 일시적인 측정항목 삭제를 경험할 수 있으므로 대시보드 쿼리는 정확한 바이트 수가 아닌 대략적인 볼륨을 제공합니다.

수집 볼륨을 계산하는 위치 및 값의 차이

Google SecOps 인터페이스에는 인스턴스 시작 시간부터의 누적 수집 카운터가 표시되지 않으므로 필요한 기간에 따라 다음 위치를 사용하여 수집 볼륨을 계산하세요.

  • Google SecOps 대시보드 (최대 365일):

    • 계산 위치: 대시보드 및 보고서 > 대시보드를 열고 기본 또는 데이터 수집 및 상태 대시보드에서 처리량 위젯을 확인합니다 (수집 - 처리량 (전체 기간) 차트 포함). $event.ingestion.component = "Ingestion API"로 필터링된 sum($event.ingestion.log_volume)에 대한 맞춤 대시보드 쿼리를 실행할 수도 있습니다.
    • 최대 기간: 선별된 수집 - 처리량 (전체 기간) 차트에서도 쿼리는 최대 365일로 제한됩니다.
    • 값의 차이: 대시보드는 약 5분 간격으로 원격 분석을 수집하고 수집 지연 시간 또는 일시적인 측정항목 삭제를 경험할 수 있는 비동기식 ingestion_metrics 테이블을 쿼리합니다. 값은 대략적이며 전체 기간 원시 로그 바이트 또는 최종 청구된 볼륨이 아닌 선택한 기간 동안 수집 API를 통해 수집된 로그만 반영합니다.

  • Cloud Monitoring 측정항목 탐색기 (BYOP 인스턴스의 경우 최대 24개월):

    • 계산 위치: 콘솔 Google Cloud 에서 Monitoring > 측정항목 탐색기를 열고 chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"}에 대한 쿼리를 실행합니다 (단계별 안내는 청구된 수집 볼륨 보기를 참고하세요).
    • 최대 기간: 쿼리는 Cloud Monitoring 측정항목 보관을 기준으로 최대 24개월로 제한됩니다.
    • 값의 차이: Cloud Monitoring은 선택한 기간 동안 수집기 수준 수집 바이트 수를 쿼리합니다. 값은 Google SecOps 대시보드보다 긴 전환 확인 기간 (365일 대신 최대 24개월)을 포함하지만 인스턴스가 24개월보다 오래된 경우 전체 기간 총계를 반영하지 않습니다.

  • BigQuery Export (365일 초과, 데이터 세트 보관에 따라):

    • 계산 위치: ingestion_metrics 테이블을 내보낸 후 BigQuery 프로젝트를 열고 component = "Ingestion API"로 필터링된 SUM(log_volume) (또는 Looker 및 BigQuery의 total_size_bytes)에 대한 쿼리를 실행합니다.
    • 최대 기간: 쿼리는 365일 대시보드 한도가 아닌 내보내기를 사용 설정한 시점부터 BigQuery 테이블에 구성된 보관 기간으로 제한됩니다.
    • 값의 차이: BigQuery는 Google SecOps 대시보드와 동일한 비동기식 ingestion_metrics 테이블을 쿼리합니다. 값은 동일한 기간의 대시보드 쿼리와 일치하지만 전체 기간 원시 로그 바이트 또는 최종 청구된 볼륨이 아닌 대략적인 원격 분석 지표로 유지됩니다.

수집 측정항목 사용

  • 문제 해결: 정규화 도구 측정항목에서 log_type 및 state(예: failed_parsing)로 필터링하여 파싱 문제를 찾습니다. 데이터 손실에 대해 drop_count 및 drop_reason_code를 확인합니다.

  • 알림: Cloud Monitoring에서 알림을 설정하여 중요한 로그 소스의 log_count가 갑자기 감소하거나 total_error_events 비율이 높은 경우를 모니터링합니다. 계약 한도에 대한 일일 수집 볼륨을 모니터링하려면 수집된 총 로그 크기 (chronicle.googleapis.com/ingestion/log/bytes_count) 측정항목을 사용합니다. 다음과 같은 이유로 일일 볼륨 알림에 chronicle.googleapis.com/ingestion/quota_limit 측정항목을 사용하지 마세요.

    • quota_limit 측정항목은 실제 수집된 데이터 볼륨이 아닌 동적 백엔드 한도에 대한 근접성을 측정합니다.
    • 일일 볼륨 알림에 quota_limit를 사용하면 백엔드 기준이 조정될 때 허위 알람이 발생할 수 있습니다.

    일일 볼륨 알림 정책을 설정하는 단계는 일일 수집 볼륨을 모니터링하는 샘플 정책 설정을 참고하세요.

  • 용량 계획: BigQuery에서 log_volume 추세를 분석하여 향후 요구사항을 예측합니다.

  • 구성 검증: 새 데이터 소스를 설정한 후 측정항목을 확인하여 데이터가 흐르고 예상대로 파싱되는지 확인합니다.

이러한 수집 측정항목을 정기적으로 모니터링하고 이해하면 Google SecOps 인스턴스의 안정적이고 효율적인 데이터 파이프라인을 보장할 수 있습니다.

도움이 더 필요하신가요? 커뮤니티 회원 및 Google SecOps 전문가에게 문의하여 답변을 받으세요.