Google SecOps와 함께 Bindplane 사용

다음에서 지원:

Google SecOps SIEM

이 문서에서는 Google Security Operations용 Bindplane을 설명합니다.

Bindplane은 모든 소스의 로그를 수집, 미세 조정하여 Google SecOps로 내보낼 수 있는 원격 분석 파이프라인입니다.

Bindplane은 Google 전용 버전 2개를 제공합니다.

Bindplane에는 다음과 같은 주요 구성요소가 포함됩니다.

• Bindplane 수집기 OpenTelemetry (OTel) Collector를 기반으로 하는 오픈소스 에이전트입니다. Microsoft Windows 이벤트 로그를 비롯한 다양한 소스에서 로그를 수집하여 Google SecOps에 전송합니다. 온프레미스 또는 클라우드에 수집기를 설치할 수 있습니다. 이 구성요소는 OpenTelemetry용 Bindplane 배포 (BDOT) Collector bindplane 에이전트, 수집 에이전트, 수집기 또는 에이전트라고도 합니다.
• Bindplane 서버. OTel 수집기 배포를 관리하기 위한 포괄적이고 통합된 플랫폼 이러한 배포는 Google SecOps 및 Google Cloud에 있을 수 있습니다. Bindplane Server는 온프레미스 또는 Bindplane 클라우드에서 실행할 수 있습니다. 콘솔에 대한 자세한 내용은 Bindplane 관리 콘솔을 참고하세요. 이 구성요소를 Bindplane 관측 가능성 파이프라인 (OP) 관리 콘솔 또는 Bindplane 관리 콘솔이라고도 합니다.

참고: 이는 온프레미스 배포에 Cloud Logging에서 사용하는 솔루션과 동일합니다.

Bindplane의 Google 버전

Bindplane은 Google을 위해 특별히 두 가지 버전(Bindplane(Google 버전) 및 Bindplane Enterprise(Google 버전))을 제공합니다.

Bindplane (Google 버전)

Bindplane (Google 버전)은 모든 Google SecOps 고객에게 제공됩니다.

자세한 내용은 다음 리소스를 참고하세요.

• 온프레미스 설치에 대한 자세한 내용은 온프레미스 배포를 참고하세요.
• 자세한 내용은 OpenTelemetry 기반의 업계 최고 관측 가능성 및 보안을 참고하세요.

Bindplane 클라우드에서 Bindplane (Google 버전)을 셀프 서비스로 사용할 수 있습니다.

Bindplane (Google 버전)을 설치하고 자체 호스팅하는 방법을 알아보려면 Bindplane (Google 버전)을 참고하세요.

Bindplane Enterprise (Google 버전): Google SecOps Enterprise Plus 고객용

Bindplane Enterprise (Google 버전)는 Google SecOps Enterprise Plus 고객에게 제공됩니다.

대규모 배포에는 Bindplane Enterprise (Google 버전)가 권장됩니다.

Google 계정팀에 문의하여 Bindplane Enterprise (Google 버전) 라이선스 키를 받으세요.

Bindplane Google 버전의 차이점

다음 표에는 Bindplane Google 버전의 차이점이 나와 있습니다.

기능	Bindplane (Google 버전)	Bindplane Enterprise (Google 버전)
비용	모든 Google SecOps 고객에게 추가 비용 없이 제공	Google SecOps Enterprise Plus 고객에게 무료로 제공
라우팅/대상	Google만 해당(Google SecOps, Cloud Logging, BigQuery, Google SecOps를 통한 Cloud Storage 포함)	Google(SIEM 마이그레이션을 위한 Google 이외의 대상으로의 라우팅 12개월 포함)
필터링	정규 표현식을 사용한 기본 필터	고급 필터링 프로세서 (예: 조건, 필드, 심각도별 필터링), 데이터 감소, 로그 샘플링, 중복 제거
수정	해당 사항 없음	PII 마스킹
혁신	필드 추가, 필드 이동, 데이터 파싱 (KV, JSON, CSV, XML, 타임스탬프, 정규식으로 파싱), 필드 이름 바꾸기, 이벤트 브레이커	Bindplane (Google 버전)에서 지원되는 모든 기능 더하기 삭제 필드, 빈 값 삭제, 병합
일반 플랫폼 수준 기능	게이트웨이 (에이전트의 데이터 집계), 수집용 Bindplane 에이전트, 온프레미스 또는 클라우드 호스팅용 Bindplane 관리 레이어, 모든 소스, SecOps 프로세서를 통한 자동 호스트 모니터링, 영구 대기열, 원격 분석 보강, HA, RBAC, SecOps 수집 API 지원, 사용자 인증 정보 난독화, 에이전트 그룹화, 동적 로그 유형 할당 등 고급 제품군 관리	Bindplane (Google 버전)에서 지원되는 모든 기능

Bindplane 관리 콘솔

Bindplane 관리 콘솔 사용은 선택사항입니다. 많은 Google SecOps 고객이 Bindplane Server를 사용합니다.

Bindplane 관리 콘솔은 다음과 같은 주요 기능을 제공합니다.

• 중앙 집중식 관리 콘솔을 사용하면 Google Cloud에서 모든 OTel 수집기 배포를 관리할 수 있습니다. 각 배포의 상태를 확인하고 수집기 시작, 중지, 다시 시작과 같은 일반적인 관리 작업을 실행할 수 있습니다.
• 실시간 모니터링 콘솔이 OTel 수집기 배치의 실시간 모니터링을 제공합니다. CPU 사용량, 메모리 사용량, 처리량과 같은 측정항목을 추적하고 로그와 트레이스를 확인하여 문제를 해결할 수 있습니다.
• 알림 및 알림 수집기가 다운되거나 측정항목 기준점이 초과되는 등의 중요한 이벤트가 발생할 때를 대비하여 콘솔에 경고 및 알림을 설정할 수 있습니다.
• 구성 관리 콘솔을 사용하면 OTel 수집기의 구성을 중앙에서 관리할 수 있습니다. 구성 파일을 수정하고, 환경 변수를 설정하고, 모든 배포에 보안 정책을 적용할 수 있습니다.
• Google Cloud와 통합 Google Cloud 에서 OTel 수집기 배포를 만들고 관리하고 콘솔을 사용하여 Google Cloud 리소스에 액세스할 수 있습니다.

Bindplane 에이전트 아키텍처

Bindplane 에이전트는 외부 종속 항목이 없는 경량 웹 서버로 Linux 또는 Docker에서 실행할 수 있습니다.

Bindplane은 BDOT 수집기를 사용하여 개방형 에이전트 관리 프로토콜 (OpAMP)로 원격 분석 관리를 표준화합니다. Bindplane을 사용하여 맞춤 OpenTelemetry Collector 배포를 만들고 관리할 수도 있습니다.

Bindplane OpenTelemetry 수집기의 배포 아키텍처에 대해 자세히 알아보려면 Bindplane OTel 수집기를 참고하세요.

다음 섹션에서는 사용 가능한 아키텍처 옵션을 설명합니다.

수집 에이전트가 게이트웨이 역할을 하는 수집 에이전트에 로그 전송

대규모 배포의 경우 게이트웨이 역할을 하는 Bindplane Enterprise (Google 버전) 에이전트를 사용하는 것이 좋습니다. 이러한 게이트웨이는 네트워크를 통해 다른 수집기에서 원격 분석을 수신하고, 필요에 따라 추가 처리를 실행하고, 데이터를 Google SecOps로 라우팅합니다.

게이트웨이 역할을 하는 수집 에이전트는 다른 모든 수집 에이전트와 동일한 바이너리를 사용합니다.

다음 다이어그램은 게이트웨이 역할을 하는 수집 에이전트로 로그를 전송하는 수집 에이전트를 보여줍니다.

수집 에이전트가 Google SecOps 수집 API에 로그를 직접 전송

다음 다이어그램에서는 수집 에이전트가 Google SecOps 수집 API로 직접 로그를 전송하는 것을 보여줍니다.

수집 에이전트가 Cloud Logging으로 직접 로그를 전송합니다.

다음 다이어그램은 수집 에이전트가 로그를 Cloud Logging으로 직접 전송하는 것을 보여줍니다.

수집 에이전트가 여러 대상에 로그 전송

다음 다이어그램은 수집 에이전트가 여러 대상으로 로그를 전송하는 것을 보여줍니다.

Bindplane 배포 유형

Bindplane은 클라우드 및 온프레미스 배포 옵션을 제공합니다.

참고: Google Cloud에서 다중 노드 구성으로 Bindplane을 배포할 수 있습니다. 자세한 내용은 Google Cloud의 다중 노드 아키텍처를 참고하세요.

온프레미스 배포

온프레미스 Bindplane 서버 사용에는 기존 Google Cloud 서비스 약관이 적용됩니다.

Linux 온프레미스 배포

스크립트를 실행하거나 (권장) 바이너리 파일을 다운로드하고 수동으로 설치하여 Linux에 온프레미스 Bindplane 서버를 설치할 수 있습니다. 자세한 내용은 Bindplane 서버 설치를 참고하세요.

스크립트를 사용하여 Linux에 온프레미스 Bindplane 서버를 설치하려면 다음 단계를 따르세요.

1. 다음 스크립트를 실행합니다.

   curl -fsSlL https://storage.googleapis.com/bindplane-op-releases/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

2. 안내에 따라 서버를 초기화합니다.

바이너리 파일을 사용하여 Linux에 온프레미스 Bindplane 서버를 설치하려면 다음을 실행하세요.

1. 다음 파일 중 하나를 다운로드합니다.

   • Bindplane-ee-linux-amd64.zip
   • Bindplane-ee-linux-arm64.zip
   • Bindplane-ee_linux_amd64.deb
   • Bindplane-ee_linux_amd64.rpm
   • Bindplane-ee_linux_arm64.deb
   • Bindplane-ee_linux_arm64.rpm

2. Bindplane 서버 구성의 안내에 따라 구성 파일을 업데이트합니다.

Docker 온프레미스 배포

자세한 내용은 Bindplane 서버 설치를 참고하세요.

Linux

Linux 배포판:

• Red Hat, Centos, Oracle Linux 7, 8, 9
• Debian 11 및 12
• Ubuntu LTS 20.04 및 22.04
• SUSE Linux 12 및 15
• Alma 및 Rocky Linux

참고: Bindplane은 일반적으로 최신 Linux 배포에서 실행되지만 systemd만 지원되는 init 시스템입니다.

자세한 내용은 다음을 참조하세요.

• Bindplane 서버 설치
• 패키지 다운로드

Docker 컨테이너 이미지

Bindplane Docker 컨테이너 이미지는 다음 위치에서 찾을 수 있습니다.

• GitHub 패키지: ghcr.io/observiq/Bindplane-ee
• Google 아티팩트 저장소: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
• Docker hub: observiq/bindplane-ee

컨테이너 이미지에는 출시 버전이 태그로 지정됩니다. 예를 들어 출시 v1.35.0에는 observiq/bindplane-ee:1.35.0 태그가 지정됩니다.

기술 요구사항 및 권장사항

이 섹션에서는 Google SecOps로 Bindplane을 설치하고 실행하기 위한 기술 요구사항과 권장사항을 설명합니다.

대역폭 요구사항

Bindplane은 다음 항목의 네트워크 연결을 유지합니다.

• 수집기 관리
• 수집기 처리량 측정
• 명령줄 및 웹 사용자 인터페이스

연결 요구사항

Bindplane은 기본적으로 포트 3001에서 리슨합니다. 이 포트는 구성할 수 있습니다.

Bindplane 포트는 다음 용도로 사용됩니다.

• OpAMP (WebSocket)를 사용한 수집기 명령 및 제어
• 수집기 처리량 측정 요청 (HTTP POST 요청)
• 브라우저 및 CLI 사용자 (HTTP 및 WebSocket)

수집기는 OpAMP (WebSocket) 및 처리량 측정 (HTTP)을 위해 Bindplane에 대한 연결을 시작할 수 있어야 합니다.

Bindplane은 수집기에 대한 연결을 시작하지 않습니다. Bindplane이 수집기 네트워크에 연결되지 않도록 방화벽을 구성할 수 있지만 수집기 네트워크는 구성된 포트에서 Bindplane에 연결할 수 있어야 합니다.

Bindplane 수집기 일반 기술 요구사항

Bindplane 수집기의 일반적인 기술 요구사항에 대해 알아보려면 다음을 참고하세요.

• GitHub의 Bindplane OTel 수집기
• Bindplane 수집기 설치 및 제거
• 설치 기본 요건
• 수집기 크기 조정 및 확장 가이드라인

수집기 리소스 요구사항

Bindplane의 리소스 요구사항은 관리되는 수집기 수에 따라 다릅니다. 관리형 수집기 수가 증가하면 CPU, 메모리, 디스크 처리량/IOPS, 네트워크 소비도 증가합니다.

CPU, 메모리, 스토리지 용량 크기 조정에는 다음 표를 사용하세요.

수집기 수	Bindplane 노드	내결함성	CPU 코어	메모리	데이터베이스
1~100명	1	해당 사항 없음	2	4GB	bbolt
100~25,000	1	해당 사항 없음	4	16GB	postgres
1~60,000	3	1	2	8GB	postgres
60,001~125,000명	5	1	2	8GB	postgres
125,001~250,000명	10	2	2	8GB	postgres

설치 및 배포 계획

다음 섹션에는 Bindplane 배포를 계획할 때 고려해야 하는 권장사항과 추천이 포함되어 있습니다.

확장 및 내결함성 고려

게이트웨이 수집기는 네트워크를 통해 원격 분석 데이터를 수신합니다. 내결함성과 수평 확장을 모두 제공하려면 로드 밸런서와 페어링하는 것이 좋습니다.

수평 확장은 내결함성을 제공하고 내보내기 프로그램 병목 현상을 제거할 수 있으므로 수평 확장이 더 좋습니다.

필요한 수집기 수 계산

워크로드에 필요한 수집기 수를 계산할 때는 예상 처리량 또는 로그 비율을 고려하고 다음 표를 사용하세요. 이 표에서는 각 수집기에 CPU 코어가 4개 있고 메모리가 16GB 있다고 가정합니다. 표에는 프로세서가 포함된 계산이 포함되어 있지 않습니다. 프로세서를 추가하면 컴퓨팅 요구사항이 증가합니다.

원격 분석 처리량	초당 로그 수	수집기
5 GB/m	250,000	2
10 GB/m	500,000	3
20GB/월	1,000,000	5
100 GB/m	5,000,000	25

내결함성을 위해 수집기 플릿을 과도하게 프로비저닝

내결함성을 보장하기 위해 수집기 플릿을 과도하게 프로비저닝합니다. 하나 이상의 수집기 시스템에 장애가 발생하거나 유지보수를 위해 오프라인 상태가 되는 경우 나머지 수집기가 원격 분석 처리량을 관리할 수 있는 충분한 용량을 갖춰야 합니다.

고정된 수의 수집기를 사용하는 경우 CPU와 메모리의 수직 확장을 구현하여 처리량을 늘릴 수 있습니다.

처리 오버헤드 오프로드

일반적으로 수집기가 최대한 적은 작업을 실행하도록 하는 것이 좋습니다. 처리 요구사항이 많은 경우 해당 처리를 게이트웨이 수집기 플릿으로 오프로드하는 것이 유용할 수 있습니다. 예를 들어 비용이 많이 드는 정규 표현식 작업으로 원격 분석을 필터링하는 대신 게이트웨이 수집기가 이 작업을 실행하도록 할 수 있습니다. 일반적으로 게이트웨이 수집기는 전용 시스템에서 실행됩니다. 데이터베이스 서버에서 실행될 수 있는 비 게이트웨이 수집기와 달리 동일한 시스템에서 실행되는 다른 서비스의 컴퓨팅 성능을 사용하지 않으므로 처리 오버헤드가 정당화됩니다.

게이트웨이 모드 권장사항

Bindplane 수집 에이전트를 게이트웨이(즉, 게이트웨이 모드)로 사용하는 경우 다음 권장사항에 따라 배포를 계획하세요.

• 부하 분산기 뒤에 수집기를 두 개 이상 배치합니다.
• 각 수집기에는 코어가 2개 이상 있어야 합니다.
• 각 수집기에는 최소 8GB의 메모리가 있어야 합니다.
• 각 수집기에는 영구 대기열에 사용할 수 있는 공간이 60GB 있어야 합니다.

필요한 경우 부하 분산기 사용

고가용성 모드에서 Bindplane을 운영하는 경우 부하 분산기가 필요합니다.

게이트웨이 모드에서 Bindplane 수집 에이전트를 사용하는 경우 부하 분산기를 사용하여 성능과 중복성을 높이세요. 부하 분산을 사용하면 게이트웨이 Fleet을 수평으로 확장하고 중단 없이 장애를 견딜 수 있습니다.

Bindplane 수집 에이전트는 게이트웨이 모드로 작동할 때 다양한 부하 분산기와 함께 작동할 수 있습니다. 이 문서에서는 특정 옵션을 다루지 않습니다. 가장 인기 있는 부하 분산 솔루션은 여러 수집기를 안정적으로 운영하는 데 필요한 기능을 지원하기 때문입니다.

자세한 내용은 부하 분산기를 참고하세요.

부하 분산 포트 및 프로토콜

Bindplane은 기본적으로 포트 3001에서 리슨합니다.

OpenTelemetry에서 다양한 네트워크 기반 수신기를 지원하려면 부하 분산기가 다음을 지원해야 합니다.

• TCP/UDP 전송 프로토콜
• HTTP 및 gRPC 애플리케이션 프로토콜

부하 분산 크기 조정

Bindplane 노드는 최대 내결함성을 위해 30,000개 이하의 수집기를 관리해야 합니다. 각 수집기는 Bindplane에 대한 두 개의 연결을 엽니다 (OpAMP 원격 관리를 위한 연결 하나와 처리량 측정항목 게시를 위한 연결 하나). 이 한도는 대부분의 부하 분산기에서 적용하는 백엔드 인스턴스당 연결 한도(약 65,535개)를 초과하지 않도록 하는 데 도움이 됩니다.

조직에 수집기가 100,000개 있는 경우 클러스터 크기가 3이면 충분하지 않습니다. 각 노드는 약 33,000개의 수집기를 담당하므로 Bindplane 인스턴스당 66,000개의 TCP 연결이 됩니다. 유지보수를 위해 한 노드가 오프라인 상태가 되면 이 상황은 더욱 악화됩니다. 각 나머지 Bindplane 인스턴스가 50,000개의 수집기 또는 100,000개의 TCP 연결을 관리하기 때문입니다.

부하 분산 크기 조정 권장사항

• 상태 점검 구현 수집기가 트래픽을 수신할 준비가 되었는지 확인하도록 부하 분산기를 구성합니다.
• 연결을 균등하게 분배합니다. 연결은 수집기 간에 균등하게 분산되어야 합니다.

• 필수 프로토콜 지원 OpenTelemetry에서 다양한 네트워크 기반 수신기를 지원하려면 부하 분산기가 다음을 지원해야 합니다.

  • TCP/UDP 전송 프로토콜
  • HTTP 및 gRPC 애플리케이션 프로토콜

자세한 내용은 수집기 복원력을 참고하세요.

소스 유형 부하 분산

네트워크를 통해 원격 시스템에서 원격 분석을 수신하는 모든 소스 유형은 부하 분산에 적합한 후보입니다. 여기에는 다음이 포함됩니다.

• OTLP
• Syslog
• TCP/UDP
• Splunk HEC
• Fluent Forward

프로덕션 환경에서 고가용성 모드 사용

단일 인스턴스 또는 다중 인스턴스 구성으로 Bindplane 인스턴스를 배포할 수 있습니다. 고가용성 (HA)과 복원력이 필요한 프로덕션 배포의 경우 다중 인스턴스 (HA) 배포 모델을 사용하는 것이 좋습니다.

Bindplane이 25,000개 이상의 수집기를 관리하는 경우 고가용성 (HA) 모드에서 Bindplane을 운영하는 것이 좋습니다.

Bindplane의 HA에 대해 알아보려면 고가용성을 참고하세요.

HA용 수집기 및 Bindplane 서버 수 계산

HA 모드에서 Bindplane을 운영할 때는 각 Bindplane 서버가 처리할 수집기 수를 고려해야 합니다.

총 Bindplane 인스턴스 수를 가져와 유지보수로 인해 사용할 수 없게 될 것으로 예상되는 최대 노드 수를 뺍니다. 노드 장애 발생 시 각 노드가 30,000개 이하의 수집기를 관리해야 합니다.

HA용 Postgres

HA 모드에서 Bindplane을 운영하는 경우 Postgres가 필수입니다.

HA용 Prometheus

HA 모드에서 Bindplane을 운영하는 경우 Prometheus가 필요합니다.

자세한 내용은 Prometheus를 참고하세요.

HA용 이벤트 버스

Bindplane은 이벤트 버스를 사용하여 Bindplane 내 구성요소 간에 통신합니다. HA 모드에서 Bindplane을 운영할 때 이벤트 버스를 사용하여 Bindplane 서버 간에 이벤트를 전송할 수 있습니다.

자세한 내용은 이벤트 버스를 참고하세요.

테스트 환경 또는 개념 증명을 위해 단일 인스턴스 배포 사용

테스트 환경이나 개념 증명의 경우 단일 인스턴스 배포를 사용하는 것이 좋습니다.

자세한 내용은 단일 인스턴스를 참고하세요.

백엔드 사용자 인증 정보 격리

모든 수집기 시스템에 사용자 인증 정보를 배포하는 대신 게이트웨이 수집기에만 사용자 인증 정보를 유지할 수 있습니다. 이렇게 하면 사용자 인증 정보 순환이 간소화되고 사용자 인증 정보 배포를 시스템의 하위 집합으로 제한하여 보안 공격 표면이 줄어듭니다.

게이트웨이 수집기 방화벽 설정

내부 네트워크에서 방화벽으로 보호되는 경계 네트워크 내에 게이트웨이 수집기를 배치할 수 있습니다. 다른 수집기가 게이트웨이 수집기로 데이터를 전달하도록 허용하면서 게이트웨이 수집기가 애플리케이션 네트워크에 액세스하지 못하도록 네트워크를 구성할 수 있습니다. 이렇게 하면 엔드포인트에 인터넷 직접 액세스 권한을 부여하지 않고도 클라우드 기반 백엔드에 원격 분석을 전송할 수 있습니다.

방화벽은 구성된 포트에서 Bindplane에 도달하는 HTTP 트래픽을 허용해야 합니다.

방화벽 구성 확인

에이전트와 인터넷 사이에 있는 방화벽이나 인증된 프록시를 사용하려면 다음 호스트에 대한 액세스 열기 규칙이 필요합니다.

연결 유형	대상	포트
TCP	malachiteingestion-pa.googleapis.com	443
TCP	asia-northeast1-malachiteingestion-pa.googleapis.com	443
TCP	asia-south1-malachiteingestion-pa.googleapis.com	443
TCP	asia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	australia-southeast1-malachiteingestion-pa.googleapis.com	443
TCP	europe-malachiteingestion-pa.googleapis.com	443
TCP	europe-west2-malachiteingestion-pa.googleapis.com	443
TCP	europe-west3-malachiteingestion-pa.googleapis.com	443
TCP	europe-west6-malachiteingestion-pa.googleapis.com	443
TCP	europe-west12-malachiteingestion-pa.googleapis.com	443
TCP	me-central1-malachiteingestion-pa.googleapis.com	443
TCP	me-central2-malachiteingestion-pa.googleapis.com	443
TCP	me-west1-malachiteingestion-pa.googleapis.com	443
TCP	northamerica-northeast2-malachiteingestion-pa.googleapis.com	443
TCP	accounts.google.com	443
TCP	oauth2.googleapis.com	443

프로덕션 배포에 PostgreSQL 사용

Postgres는 Bindplane의 프로덕션 배포에 필요합니다.

Postgres는 HA 모드에서 Bindplane을 운영하기 위한 필수 요건입니다.

참고: BBolt는 PostgreSQL을 대신하여 지원 중단되었으며 개념 증명 배포에만 사용해야 합니다.

CPU 코어 수와 사용 가능한 메모리는 일반적으로 PostgreSQL 스토리지 백엔드의 성능을 제한합니다. 솔리드 스테이트 드라이브 (SSD)와 같이 지연 시간이 짧고 처리량이 높은 스토리지를 사용하여 PostgreSQL 스토리지를 지원하는 것이 좋습니다.

수집기 수	CPU 코어	메모리
1~60,000	4	16GB
60,001~125,000명	8	32GB
125,001~250,000명	16	64GB

자세한 내용은 다음을 참조하세요.

• PostgreSQL 문서
• Postgres 설정 가이드
• Postgres 스토어 구성
• Postgres TLS 설정

적절한 인증 구현

Bindplane은 다음 프로토콜 및 서비스를 사용한 인증을 지원합니다. 올바르게 구현되었는지 확인하세요.

• Azure Entra LDAP 자세한 내용은 Azure LDAP 및 Bindplane 인증 유형 변경을 참고하세요.
• LDAP.
• OpenID Connect(OIDC).
• 지역
• SAML
• Postgres TLS 자세한 내용은 Postgres TLS를 참고하세요.
• Kubernetes 자세한 내용은 GKE 워크로드 아이덴티티를 참고하세요.

Bindplane 관리 콘솔 설치

대부분의 Google SecOps 고객은 Bindplane 관리 콘솔을 사용합니다. 설치하는 경우 storage.googleapis.com에 액세스할 수 있어야 합니다. 에이전트만 설치하는 경우에는 이 액세스 권한이 필요하지 않습니다.

Google 고객도 Bindplane Cloud를 사용할 수 있습니다. 무료 버전을 다운로드하고 [e-mail]으로 이메일을 보내 Google 지원 버전으로 업그레이드를 요청하세요.

Bindplane 관리 콘솔을 배포하는 방법에는 세 가지가 있습니다.

• Bindplane Cloud: Bindplane Server용 Bindplane의 SaaS 제품입니다.
• 다운로드하여 Linux 호스트에 설치: DEB 패키지, RPM 패키지, 또는 Docker 이미지로 이용 가능합니다.
• Google Cloud Marketplace에서 설치하여 프로비저닝.

참고: Bindplane Cloud 서버와 관련된 문제는 Bindplane 지원팀에 문의하세요. 온프레미스 Bindplane Server와 관련된 문제는 Google SecOps 지원팀에 문의하세요.

Bindplane 에이전트 설치

이 섹션에서는 다양한 호스트 운영체제에 Google SecOps용 Bindplane 에이전트를 설치하는 방법을 설명합니다.

에이전트 수집기는 일반적으로 최소한의 리소스를 사용합니다. 하지만 대량의 로그를 처리할 때는 다른 서비스에 영향을 주지 않도록 리소스 소비량에 유의해야 합니다. 자세한 내용은 기술 요구사항 및 권장사항, 설치 및 배포 계획, 에이전트 크기 조정 및 확장을 참고하세요.

OTel 에이전트 설치 방법에 대해 자세히 알아보려면 Bindplane 수집기 설치 및 제거를 참고하세요.

참고: 수집기와 관련된 문제가 있으면 Google SecOps 지원팀에 문의하세요.

에이전트를 설치하려면 다음이 필요합니다.

• Google SecOps 수집 인증 파일

  인증 파일을 다운로드하려면 다음 단계를 따르세요.

  1. Google SecOps 콘솔을 엽니다.
  2. SIEM 설정 > 수집 에이전트로 이동합니다.
  3. Google SecOps 수집 인증 파일을 다운로드합니다.

• Google SecOps 고객 ID

  고객 ID를 찾으려면 다음 단계를 따르세요.

  1. Google SecOps 콘솔을 엽니다.
  2. SIEM 설정 > 프로필로 이동합니다.
  3. 조직 세부정보 섹션에서 고객 ID를 복사합니다.

• Windows 2012 SP2 이상 또는 systemd가 있는 Linux 호스트

• 인터넷 연결

• GitHub 액세스

배포 도구

이 섹션에서는 Bindplane의 배포 도구에 대해 설명합니다.

GitOps

다음을 포함하는 GitOps 모델을 사용하여 Bindplane 리소스를 배포합니다.

• Bindplane 인증
• Bindplane CLI
• 네트워크 액세스
• GitHub 저장소 및 GitHub Actions와의 통합
• 기존 리소스 내보내기
• 민감한 값 관리
• GitHub Actions 워크플로 설정
• 구성을 커밋하고 테스트하고, 자동 출시를 사용 설정하고, 직접 수정 또는 UI 내보내기 방법을 사용하여 리소스를 업데이트하는 단계별 안내
• 민감한 값 업데이트 및 RBAC 사용

자세한 내용은 GitOps를 참고하세요.

Ansible

Ansible로 Bindplane을 배포하는 방법을 알아보려면 bindplane-agent-ansible을 참고하세요.

Bindplane CLI

Bindplane CLI에 대해 알아보려면 GitOps를 참고하세요.

Terraform

Terraform을 사용하여 Bindplane 리소스를 구성하는 방법을 알아보려면 Bindplane 제공업체를 참고하세요.

Kubernetes

Bindplane을 사용한 Kubernetes에 대해 알아보려면 다음을 참고하세요.

• Kubernetes 동적 클러스터 이름
• Kubernetes Postgres 마이그레이션

Windows에 Bindplane 에이전트 설치

Windows에 Bindplane 에이전트를 설치하려면 다음 PowerShell 명령어를 실행합니다.

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

또는 설치 마법사를 사용하여 설치하려면 Windows용 최신 설치 프로그램을 다운로드하세요. 설치 프로그램을 다운로드한 후 설치 마법사를 열고 안내에 따라 Bindplane 에이전트를 구성하고 설치합니다.

Windows에 Bindplane 에이전트를 설치하는 방법을 자세히 알아보려면 Windows 설치를 참고하세요.

Linux에 Bindplane 에이전트 설치

설치할 패키지를 자동으로 결정하는 스크립트를 사용하여 Linux에 에이전트를 설치할 수 있습니다. 동일한 스크립트를 사용하여 기존 설치를 업데이트할 수도 있습니다.

설치 스크립트를 사용하여 설치하려면 다음 스크립트를 실행합니다.

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

수집기를 구성하는 방법을 자세히 알아보려면 bindplane-otel-collect를 참고하세요.

로컬 패키지에서 설치

로컬 패키지에서 에이전트를 설치하려면 패키지 경로와 함께 -f를 사용합니다.

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

RPM 설치

출시 페이지에서 아키텍처용 RPM 패키지를 다운로드하고 rpm을 사용하여 패키지를 설치합니다. amd64 패키지 설치에 대해서는 다음 예시를 참조하세요.

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

VERSION을 다운로드한 패키지의 버전으로 바꿉니다.

DEB 설치

출시 페이지에서 아키텍처에 맞는 DEB 패키지를 다운로드하고 dpkg를 사용하여 패키지를 설치합니다. amd64 패키지 설치에 대해서는 다음 예시를 참고하세요.

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

VERSION을 다운로드한 패키지의 버전으로 바꿉니다.

자세한 내용은 Bindplane 에이전트 설치를 참고하세요.

Bindplane 에이전트 구성

에이전트를 설치하고 나면 observiq-otel-collector 서비스가 실행되고 구성할 준비가 됩니다.

에이전트는 수동으로 또는 Bindplane 관리 콘솔을 사용하여 구성할 수 있습니다.

에이전트를 수동으로 구성하는 경우 에이전트가 Google SecOps로 인증되도록 내보내기 매개변수를 업데이트해야 합니다.

OTel 수집기 구성 파일

Linux에서 수집기의 구성 파일은 /opt/observiq-otel-collector/config.yaml에 있습니다.

OTel 수집기 서비스 및 로그

에이전트는 기본적으로 C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log에 로깅합니다.

에이전트 프로세스의 표준 오류 로그는 C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err에서 확인할 수 있습니다.

수집기 구성에 대해 자세히 알아보려면 bindplane-otel-collect를 참고하세요.

Linux에서 수집기의 로그를 보려면 sudo tail -F /opt/observiq-otel-collector/log/collector.log를 실행합니다.

일반적인 Linux OTel 수집기 서비스 명령어는 다음과 같습니다.

• OTel 수집기 서비스를 중지하려면 sudo systemctl stop observiq-otel-collector를 실행합니다.

• OTel 수집기 서비스를 시작하려면 sudo systemctl start observiq-otel-collector를 실행합니다.

• OTel 수집기 서비스를 다시 시작하려면 sudo systemctl restart observiq-otel-collector를 실행합니다.

• 시작 시 OTel 수집기 서비스를 사용 설정하려면 sudo systemctl enable observiq-otel-collector를 실행합니다.

구성 변경사항을 적용하기 위해 에이전트 서비스를 다시 시작합니다.

구성을 변경할 때는 구성 변경사항이 적용되도록 에이전트 서비스를 다시 시작해야 합니다 (sudo systemctl restart observiq-otel-collector).

기본 샘플 구성 파일 사용

기본적으로 에이전트 구성 파일은 C:\Program Files\observIQ OpenTelemetry Collector\config.yaml에 있습니다.

에이전트가 사용하는 샘플 구성 파일과 인증 토큰은 Google SecOps 콘솔 > SIEM 설정 > 수집 에이전트에서 다운로드할 수 있습니다.

구성 파일에서 다음 두 섹션을 맞춤설정합니다.

• 수신 도구: 에이전트가 수집하여 Google SecOps로 전송해야 하는 로그를 지정합니다.
• 내보내기 도구: 에이전트가 로그를 전송하는 대상을 지정합니다. 다음 내보내기 도구가 지원됩니다.
  • Google SecOps 내보내기 도구: 로그를 Google SecOps 수집 API로 직접 전송합니다.
  • Google SecOps 포워더 내보내기 도구: Google SecOps 포워더에 로그를 전송합니다.
  • Cloud Logging 내보내기: (Cloud Logging)으로 로그를 전송합니다.

내보내기 도구에서 다음을 맞춤설정합니다.

• customer_id: Google SecOps 고객 ID입니다.
• endpoint: Google SecOps 리전 엔드포인트입니다.

• creds: 인증 토큰입니다.

  또는, creds_file_path를 사용하여 사용자 인증 정보 파일을 직접 참조할 수도 있습니다. Windows 구성의 경우 백슬래시로 경로를 이스케이프합니다.

• log_type: 로그 유형입니다. 로그 유형으로 WINDOWS_DNS를 선택하는 것이 좋습니다.

• ingestion_labels: 수집 라벨입니다. 이러한 라벨은 Google SecOps에서 로그를 식별합니다.

• namespace: 선택적 네임스페이스입니다.

  각 로그 유형에는 내보내기를 구성해야 합니다.

로그 수집 구성 샘플

다음 섹션에는 로그 수집을 위한 구성 샘플이 포함되어 있습니다.

Windows 이벤트 및 sysmon을 Google SecOps에 직접 전송

샘플에서 다음 매개변수를 구성합니다.

• chronicleexporter

  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

샘플 구성:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "[e-mail]",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "[e-mail]",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

Windows 이벤트 및 syslog를 Google SecOps에 직접 전송

샘플에서 다음 매개변수를 구성합니다.

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

샘플 구성:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows 이벤트 및 syslog를 Google SecOps 포워더에 전송

샘플에서 다음 매개변수를 구성합니다.

• windowseventlogreceiver
• tcplogreceiver
  • listen_address
• chronicleforwarder
  • endpoint

샘플 구성:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

syslog를 Google SecOps에 직접 전송

샘플에서 다음 매개변수를 구성합니다.

• tcplogreceiver
  • listen_address
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • Creds

샘플 구성:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows 이벤트를 원격으로 수집하여 Google SecOps로 직접 전송

샘플에서 다음 매개변수를 구성합니다.

• windowseventlogreceiver
  • username
  • password
  • server
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

샘플 구성:

receivers:
    windowseventlog/system:
        channel: system
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "remote-server"
    windowseventlog/application:
        channel: application
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
    windowseventlog/security:
        channel: security
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: WINEVTLOG
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/system
                - windowseventlog/application
                - windowseventlog/security
            exporters:
                - chronicle/chronicle_w_labels

Cloud Logging으로 데이터 전송

샘플에서 credentials_file 매개변수를 구성합니다.

샘플 구성:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

SQL 데이터베이스를 쿼리하고 결과를 Google SecOps로 전송

샘플에서 다음 매개변수를 구성합니다.

• sqlqueryreceiver
• chronicleexporter
  • namespace
  • ingestion_labels
  • log_type
  • customer_id
  • creds

샘플 구성:

receivers:
  sqlquery/source0:
    datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
    driver: postgres
    queries:
      - logs:
          - body_column: log_body
        sql: select * from my_logs where log_id > $$1
        tracking_column: log_id
        tracking_start_value: "10000"
processors:
  transform/source0_processor0__logs:
    error_mode: ignore
    log_statements:
      - context: log
        statements:
          - set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
  chronicle/chronicle_sql:
    compression: gzip
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "[e-mail]",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    customer_id: customer_id
    endpoint: malachiteingestion-pa.googleapis.com
    log_type: POSTGRESQL
    namespace: null
    raw_log_field: body
    retry_on_failure:
      enabled: false
    sending_queue:
      enabled: false
service:
  pipelines:
    logs/source0_chronicle_sql-0:
      receivers:
        - sqlquery/source0
      processors:
        - transform/source0_processor0__logs
      exporters:
        - chronicle/chronicle_sql

정규 표현식과 일치하는 로그 삭제

정규 표현식과 일치하는 로그를 삭제하도록 수집기를 구성할 수 있습니다. 이는 알려진 오류나 디버깅 메시지와 같은 원치 않는 로그를 필터링하는 데 유용합니다.

정규 표현식과 일치하는 로그를 삭제하려면 구성에 filter/drop-matching-logs-to-Chronicle 유형의 프로세서를 추가하세요. 이 프로세서는 IsMatch 함수를 사용하여 정규 표현식에 대해 로그 본문을 평가합니다. 함수가 true를 반환하면 로그가 삭제됩니다.

다음 구성 예시에서는 로그 본문에 <EventID>10</EventID> 또는 <EventID>4799</EventID> 문자열이 포함된 로그를 삭제합니다.

필요한 패턴과 일치하도록 정규 표현식을 맞춤설정할 수 있습니다. IsMatch 함수는 RE2 정규 표현식 문법을 사용합니다.

샘플 구성:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

다음 예에서는 동일한 구성의 파이프라인에 프로세서를 추가합니다.

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

Bindplane 운영 및 유지관리

이 섹션에서는 일상적인 작동 및 유지보수 작업을 설명합니다.

OTel 구성 확인

Bindplane OTel 구성을 확인하는 방법을 알아보려면 OTelBin을 참고하세요.

참고: OTelBin은 OpenTelemetry Collector 구성을 수정, 시각화, 검증하는 무료 도구입니다.

수집기 출시 업데이트

Bindplane은 bindplane-otel-collector/releases를 폴링하여 새 수집기 출시를 감지할 수 있습니다. 이 기능은 선택사항입니다.

Bindplane 구성에서 agentVersions.syncInterval을 0로 설정하여 GitHub 폴링을 사용 중지할 수 있습니다.

agentVersions:
syncInterval: 0

백업 및 재해 복구

Bindplane을 사용한 백업 및 재해 복구에 대해 알아보려면 Bindplane 리소스를 참고하세요.

PostgreSQL 백업 및 재해 복구

Bindplane을 사용한 PostgreSQL 백업 및 재해 복구에 대해 알아보려면 PostgreSQL 문서를 참고하세요.

BBolt 백업 및 재해 복구

Bindplane을 사용한 BBolt (지원 중단됨) 백업 및 재해 복구에 대해 알아보려면 BBolt 스토어 문서를 참고하세요.

복원력 및 재시도

재시도는 재시도를 지원하는 모든 대상 위치에서 기본적으로 사용 설정됩니다. 기본적으로 실패한 요청은 5초 후에 재시도되며 최대 30초까지 점진적으로 백오프됩니다. 5분이 지나면 요청이 영구적으로 삭제됩니다.

자세한 내용은 수집기 복원력을 참고하세요.

심각도 필터로 로그 볼륨 줄이기

로그 볼륨을 줄이는 방법을 알아보려면 심각도 필터로 로그 볼륨 줄이기를 참고하세요.

서드 파티 에이전트와의 Bindplane 통합

에지에서 수집할 때 Bindplane 에이전트를 사용하면 Bindplane이 더 강력해지지만 대부분의 경우 Bindplane은 기존 인프라 내에 유지될 수 있습니다. 예를 들어 Fluent Bit 또는 Splunk Universal Forwarder를 이미 사용하고 있다면 계속 사용할 수 있습니다.

Splunk와의 Bindplane 통합

Bindplane을 사용하는 Splunk에 대해 알아보려면 다음을 참고하세요.

• Bindplane과 함께 Splunk OTEL Collector 사용
• Bindplane과 함께 Splunk UF 사용

다른 서드 파티 에이전트와의 Bindplane 통합

서드 파티 에이전트와의 Bindplane 통합에 대해 알아보려면 OpAMP 확장 프로그램을 사용하여 다른 OpenTelemetry 수집기 연결을 참고하세요.

자동 호스트 모니터링

Bindplane을 사용하여 자동 호스트 모니터링을 수행하는 방법은 다음을 참고하세요.

• Google SecOps 자동 호스트 모니터링
• Google Cloud Monitoring으로 SHM용 Bindplane 구성

Linux에서 Bindplane 업그레이드

끝에 --init 플래그 없이 설치 명령어를 실행하면 Bindplane을 업그레이드할 수 있습니다. Bindplane 서버에서 이 스크립트를 실행하여 Bindplane을 업그레이드합니다. 자세한 내용은 Bindplane 서버 업그레이드, 다운그레이드 또는 제거를 참고하세요.

Bindplane 모니터링

Bindplane 모니터링에 대해 알아보려면 Bindplane 모니터링을 참고하세요.

Kubernetes 모니터링

Bindplane의 Kubernetes 모니터링에 대해 알아보려면 Kubernetes 모니터링을 참고하세요.

추가 참고 문서

Bindplane (이전 명칭: observIQ)에 대해 자세히 알아보려면 다음을 참고하세요.

• Bindplane 권장사항과 함께 Google SecOps 사용하기
• Bindplane 솔루션
• Bindplane 빠른 시작 가이드
• Google Cloud에 지원되는 로그 유형
• 조건 프로세서별 필터링
• Bindplane에서 사용 가능한 소스

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