Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

収集用の Bindplane エージェントをデプロイする

以下でサポートされています。

Google SecOps SIEM

このドキュメントでは、Google Security Operations の Bindplane について説明します。

Bindplane は、任意のソースからログを収集、絞り込み、Google SecOps にエクスポートできるテレメトリーパイプラインです。

Bindplane には、Google 向けの 2 つのエディションが用意されています。

Bindplane には、次の主要コンポーネントが含まれています。

Bindplane コレクタ。OpenTelemetry（OTel）Collector に基づくオープンソースエージェント。Microsoft Windows イベントログなど、さまざまなソースからログを収集し、Google SecOps に送信します。コレクタはオンプレミスまたはクラウドにインストールできます。

このコンポーネントは、OpenTelemetry（BDOT）Collector 用の Bindplane ディストリビューション、Bindplane エージェント、コレクションエージェント、コレクタ、エージェントとも呼ばれます。
Bindplane サーバー。OTel Collector のデプロイを管理するための包括的で統合されたプラットフォーム。これらのデプロイは、Google SecOps と Google Cloudに配置できます。多くの Google SecOps のお客様は Bindplane Server を使用していますが、その使用は任意です。Bindplane Server は、オンプレミスまたは Bindplane クラウドで実行できます。サーバーの詳細については、Bindplane サーバーをご覧ください。

このコンポーネントは、Bindplane Observability Pipeline（OP）管理コンソールまたは Bindplane 管理コンソールとも呼ばれます。

Bindplane の Google エディション

Bindplane には、Google 向けに Bindplane（Google エディション）と Bindplane Enterprise（Google エディション）の 2 つのエディションが用意されています。

Bindplane（Google エディション）

Bindplane（Google エディション）は、すべての Google SecOps のお客様に提供されます。

Bindplane（Google エディション）は、Bindplane クラウドでセルフサービスで利用できます。

Bindplane（Google エディション）のインストールとセルフホストを開始する場合、またはオンプレミスの Bindplane サーバーのキーを生成する場合は、Bindplane（Google エディション）をご覧ください。

Bindplane Enterprise（Google エディション）- Google SecOps Enterprise Plus と Google Unified Security（GUS）のお客様向け

Bindplane Enterprise（Google エディション）は、Google SecOps Enterprise Plus と GUS のお客様に含まれています。

大規模なデプロイには、Bindplane Enterprise（Google エディション）をおすすめします。

Bindplane Enterprise ライセンスキーをダウンロードする

Google SecOps Enterprise Plus と GUS のお客様は、Bindplane Enterprise（Google エディション）のライセンスキーをプラットフォームコンソールから直接ダウンロードできます。

Google SecOps コンソールで、[設定] > [データマネジメント] > [コレクションエージェント] に移動します。
[Bindplane ライセンス] カードで、[ライセンスをダウンロード] をクリックして、ライセンスキーファイルを保存します。
ダウンロードしたライセンスキーを Bindplane Server のインストールに適用します。詳しくは、Bindplane ライセンスを適用するをご覧ください。

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 サーバー（Bindplane 管理レイヤ）、すべてのソース、Google SecOps プロセッサによるサイレントホストモニタリング、永続キュー、テレメトリーの拡充、高可用性、RBAC、両方の Google SecOps 取り込み API のサポート、認証情報の難読化、コレクタのグループ化を含む高度なフリート管理、動的なログタイプの割り当て	Bindplane（Google エディション）でサポートされているすべての機能

Bindplane コレクタのアーキテクチャ

Bindplane は、BDOT Collector（一般にコレクタと呼ばれる）を使用して、Open Agent Management Protocol（OpAMP）によるテレメトリー管理を標準化します。Bindplane を使用して、カスタム OpenTelemetry Collector ディストリビューションを作成して管理することもできます。

コレクタは、外部依存関係のない軽量のウェブサーバーとして Linux または Docker で実行できます。

Bindplane OpenTelemetry コレクタのデプロイアーキテクチャの詳細については、デプロイをご覧ください。

以降のセクションでは、使用可能なアーキテクチャオプションについて説明します。

コレクタがゲートウェイとして機能するコレクタにログを送信する

大規模なデプロイでは、ゲートウェイとして機能するコレクタを使用することをおすすめします。これらのゲートウェイは、ネットワーク経由で他のコレクタからテレメトリーを受信し、必要に応じて追加の処理を実行して、データを Google SecOps にルーティングします。

ゲートウェイとして機能するコレクタは、他のすべてのコレクタと同じバイナリを使用します。

次の図は、ゲートウェイとして機能するコレクタにログを送信するコレクタを示しています。

コレクタがゲートウェイとして機能するコレクタにログを送信する

コレクタはログを Google SecOps 取り込み API に直接送信します。

次の図は、コレクタがログを Google SecOps Ingestion API に直接送信している様子を示しています。

コレクタはログを Google SecOps 取り込み API に直接送信します。

コレクタがログを Cloud Logging に直接送信する

次の図は、コレクタがログを Cloud Logging に直接送信している様子を示しています。

コレクタがログを Cloud Logging に直接送信する

コレクタが複数の宛先にログを送信する

次の図は、コレクタが複数の宛先にログを送信している様子を示しています。

コレクタが複数の宛先にログを送信する

Bindplane サーバー

Bindplane サーバーには、次の主な機能があります。

一元管理。このサーバーを使用すると、 Google Cloud全体ですべての OTel コレクタのデプロイを管理できます。各デプロイのステータスを表示し、コレクタの起動、停止、再起動などの一般的な管理タスクを実行できます。
リアルタイムモニタリング。サーバーは、OTel コレクタのデプロイをリアルタイムでモニタリングします。CPU 使用率、メモリ使用量、スループットなどの指標を追跡できます。また、ログとトレースを表示して、問題のトラブルシューティングを行うこともできます。
アラートと通知。サーバーでは、コレクタがダウンしたときや指標のしきい値を超えたときなど、重要なイベントに関するアラートと通知を設定できます。
構成管理。このサーバーを使用すると、OTel コレクタの構成を一元管理できます。構成ファイルの編集、環境変数の設定、すべてのデプロイへのセキュリティポリシーの適用が可能です。
Google Cloudとの統合。 Google Cloud で OTel コレクタのデプロイを作成して管理し、サーバーを使用して Google Cloud リソースにアクセスできます。

Bindplane には、クラウドとオンプレミスのデプロイオプションが用意されています。詳細については、Bindplane サーバーを使用するをご覧ください。

技術要件と推奨事項

このセクションでは、Google SecOps で Bindplane をインストールして実行するための技術要件と推奨事項について説明します。

帯域幅の要件

Bindplane は、次のネットワーク接続を維持します。

コレクタの管理
コレクタのスループット測定
コマンドラインとウェブユーザーインターフェース

接続要件

Bindplane はデフォルトでポート 3001 をリッスンします。このポートは構成可能です。

Bindplane ポートは次の目的で使用されます。

OpAMP（WebSocket）を使用したコレクタのコマンド＆コントロール
コレクタのスループット測定リクエスト（HTTP POST リクエスト）
ブラウザと CLI のユーザー（HTTP と WebSocket）

コレクタは、OpAMP（WebSocket）とスループット測定（HTTP）のために Bindplane への接続を開始できる必要があります。

Bindplane がコレクタへの接続を開始することはありません。Bindplane がコレクタネットワークにアクセスできないようにファイアウォールを構成できます。ただし、コレクタネットワークは、構成されたポートで Bindplane にアクセスできる必要があります。

Bindplane コレクタの一般的な技術要件

Bindplane コレクタの一般的な技術要件については、以下をご覧ください。

コレクタのリソース要件

Bindplane のリソース要件は、管理対象コレクタの数によって異なります。マネージドコレクタの数が増えると、CPU、メモリ、ディスクスループット / IOPS、ネットワーク消費量も増加します。

CPU、メモリ、ストレージ容量のサイズ設定については、次の表をご覧ください。

コレクタ数	Bindplane ノード	フォールトトレラント	CPU コアの数	メモリ	データベース
1～100 人	1	なし	2	4 GB	bbolt
100 ～ 25,000	1	なし	4	16 GB	postgres
1 ～ 60,000	3	1	2	8 GB	postgres
60,001 ～ 125,000	5	1	2	8 GB	postgres
125,001 ～ 250,000	10	2	2	8 GB	postgres

インストールとデプロイを計画する

以降のセクションでは、Bindplane のデプロイを計画する際に考慮すべき推奨事項とベストプラクティスについて説明します。

スケーリングとフォールトトレランスを考慮する

水平スケーリングは、フォールトトレランスを提供し、エクスポータのボトルネックを排除できるため、推奨されます。

Bindplane コレクタをゲートウェイモードで実行する場合は、ロードバランサとペアにして、フォールトトレランスと水平スケーリングを提供することをおすすめします。

必要なコレクタの数を計算する

ワークロードに必要なコレクタの数を計算するときは、予想されるスループットまたはログレートを考慮し、次の表を使用します。この表は、各コレクタに 4 つの CPU コアと 16 GB のメモリがあることを前提としています。この表には、プロセッサを使用した計算は含まれていません。プロセッサを追加すると、コンピューティング要件が増加します。

テレメトリースループット	ログ/秒	コレクタ
5 GB/分	250,000	2
10 GB/分	500,000	3
20 GB/分	1,000,000	5
100 GB/月	5,000,000	25

フォールトトレランスのためにコレクタフリートをオーバープロビジョニングする

フォールトトレランスを確保するために、コレクタフリートをオーバープロビジョニングします。1 つ以上のコレクタシステムに障害が発生した場合や、メンテナンスのためにオフラインになった場合でも、残りのコレクタがテレメトリースループットを管理するのに十分な容量を備えている必要があります。

固定数のコレクタを使用している場合は、CPU とメモリの垂直スケーリングを実装してスループットを向上させることができます。

処理のオーバーヘッドをオフロードする

一般的に、コレクタの処理はできるだけ少なくする必要があります。処理要件が厳しい場合は、その処理をゲートウェイコレクタのフリートにオフロードすると便利です。たとえば、コストの高い正規表現オペレーションでテレメトリーをフィルタリングする代わりに、ゲートウェイコレクタにそのタスクを実行させることができます。通常、ゲートウェイコレクタは専用システムで実行されます。これにより、データベースサーバーで実行されている可能性のある非ゲートウェイコレクタとは異なり、同じシステムで実行されている他のサービスのコンピューティング能力を消費しないため、処理オーバーヘッドが正当化されます。

ゲートウェイモードのベストプラクティス

Bindplane コレクタをゲートウェイモードで実行する場合は、次のベストプラクティスに沿ってデプロイを計画することをおすすめします。

ロードバランサの背後に少なくとも 2 つのコレクタを配置します。
各コレクタには、2 つ以上のコアが必要です。
各コレクタには、少なくとも 8 GB のメモリが必要です。
各コレクタには、永続キュー用に 60 GB の使用可能な容量が必要です。

必要に応じてロードバランサを使用する

Bindplane を高可用性モードで運用する場合は、ロードバランサが必要です。

ゲートウェイモードで Bindplane コレクタを実行する場合は、ロードバランサを使用してパフォーマンスと冗長性を向上させます。ロードバランシングにより、ゲートウェイフリートの水平スケーリングが可能になり、サービス停止を引き起こすことなく障害に耐えることができます。

Bindplane コレクタは、さまざまなロードバランサと連携できます。

詳細については、ロードバランサの構成をご覧ください。

ロードバランシングのポートとプロトコル

Bindplane はデフォルトでポート 3001 をリッスンします。

OpenTelemetry の幅広いネットワークベースのレシーバーをサポートするには、ロードバランサが次のものをサポートする必要があります。

TCP / UDP トランスポートプロトコル
HTTP および gRPC アプリケーションプロトコル

ロードバランシングのサイジング

フォールトトレランスを最大にするには、Bindplane ノードで管理するコレクタの数を 30,000 以下にする必要があります。各コレクタは、Bindplane への 2 つの接続を開きます（1 つは OpAMP リモート管理用、もう 1 つはスループット指標の公開用）。この上限により、ほとんどのロードバランサで課されるバックエンドインスタンスあたりの接続数の上限（約 65,535）を超えないようにできます。

組織に 100,000 個のコレクタがある場合、クラスタサイズが 3 では不十分です。各ノードは約 33,000 個のコレクタを担当することになり、これは Bindplane インスタンスあたり 66,000 個の TCP 接続に相当します。1 つのノードがメンテナンスのために停止すると、残りの各 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 を超えるコレクタを管理する場合は、Bindplane を高可用性（HA）モードで運用することをおすすめします。

Bindplane の HA については、高可用性をご覧ください。

HA 用のコレクタと Bindplane サーバーの数を計算する

Bindplane を HA モードで運用する場合は、各 Bindplane サーバーで処理するコレクタの数を考慮する必要があります。

Bindplane インスタンスの合計数から、メンテナンスにより使用できなくなると予想されるノードの最大数を差し引きます。ノードの停止中に各ノードが管理するコレクタが 30,000 個以下になるようにしてください。

HA 用の Postgres

Bindplane を HA モードで運用する場合、Postgres が前提条件となります。

HA 用の Prometheus

Bindplane を HA モードで運用する場合は、Prometheus が必要です。

詳細については、Prometheus をご覧ください。

HA 用のイベントバス

Bindplane は、イベントバスを使用して Bindplane 内のコンポーネント間で通信します。Bindplane を HA モードで運用する場合、イベントバスを使用して Bindplane サーバー間でイベントを送信できます。

詳細については、Event Bus をご覧ください。

テスト環境または概念実証に単一インスタンスのデプロイを使用する

テスト環境または概念実証には、単一インスタンスのデプロイを使用することをおすすめします。

詳細については、単一インスタンスをご覧ください。

バックエンド認証情報を分離する

すべてのコレクタシステムに認証情報をデプロイする代わりに、認証情報をゲートウェイコレクタにのみ保持できます。これにより、認証情報のローテーションが簡素化され、認証情報のデプロイをシステムの一部に制限することで、セキュリティ攻撃対象領域が縮小されます。

ゲートウェイコレクタをファイアウォールで保護する

ゲートウェイコレクタは、内部ネットワークからファイアウォールで保護された境界ネットワーク内に配置できます。他のコレクタがゲートウェイコレクタにデータを転送できるようにネットワークを構成し、ゲートウェイコレクタがアプリケーションネットワークにアクセスできないようにすることができます。これにより、エンドポイントにインターネットへの直接アクセスを許可することなく、クラウドベースのバックエンドにテレメトリーを送信できます。

ファイアウォールは、構成されたポートで HTTP トラフィックが Bindplane に到達できるようにする必要があります。

ファイアウォール構成を確認する（Ingestion API）

コレクタとインターネットの間にあるファイアウォールまたは認証プロキシには、次のホストへのアクセス権を開放するルールが必要です。

接続タイプ	発信先	ポート
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

Bindplane を使用した Google SecOps の取り込みの前提条件

このセクションでは、Bindplane を使用して Google SecOps にデータを正常に取り込むために必要な前提条件について説明します。特に、Chronicle Ingestion API を利用する場合について説明します。

Chronicle API のネットワーク要件（HTTPS）

HTTPS を使用する Chronicle Ingestion API で Bindplane を使用する場合は、ネットワークとファイアウォールの構成で Chronicle API エンドポイントへのアウトバウンド接続が許可されていることを確認してください。

組織で IP ベースのファイアウォール制限を使用している場合は、 Google Cloud IP アドレスの動的な性質を考慮する必要があります。Google SecOps は Ingestion API の静的 IP アドレスの許可リスト登録をサポートしていないため、静的 IP のみに依存することは推奨されません。また、取り込みエラーが発生する可能性があります。

継続的なデータの取り込みを維持するには、次の点を考慮してください。

ドメインベースの許可リスト登録: 推奨されるベストプラクティスは、*.chronicle.googleapis.com ドメイン全体へのアウトバウンド HTTPS（ポート 443）トラフィックを有効にするようにファイアウォールを構成することです。
リージョンエンドポイント: Bindplane は、Google SecOps インスタンスに適したリージョンエンドポイント（us-chronicle.googleapis.com、europe-chronicle.googleapis.com など）を使用するように構成する必要があります。リージョンエンドポイントの完全なリストについては、以前の SIEM API から Chronicle API への移行のドキュメントをご覧ください。
IP の自動更新: ドメインベースの許可リスト登録が不可能な場合は、*.chronicle.googleapis.com に関連付けられた IP 範囲を定期的に取得して更新する自動システムを実装する必要があります。Google API の現在の IP 範囲は、Google IP アドレスのドキュメントに記載されているように、goog.json ファイルと cloud.json ファイルから取得できます。これらのソースに基づいてファイアウォールルールを動的に更新するシステムを実装します。

本番環境のデプロイに PostgreSQL を使用する

Bindplane の本番環境デプロイには Postgres が必要です。

Postgres は、Bindplane を HA モードで運用するための前提条件です。

一般に、CPU コアの数と使用可能なメモリによって、PostgreSQL ストレージバックエンドのパフォーマンスが制限されます。PostgreSQL ストレージは、ソリッドステートドライブ（SSD）などの低レイテンシ、高スループットのストレージでバックアップすることをおすすめします。

コレクタ数	CPU コアの数	メモリ
1 ～ 60,000	4	16 GB
60,001 ～ 125,000	8	32 GB
125,001 ～ 250,000	16	64 GB

詳細については、以下をご覧ください。

適切な認証を実装する

Bindplane は、次のプロトコルとサービスによる認証をサポートしています。これらが適切に実装されていることを確認してください。

Azure Entra LDAP。詳細については、Azure LDAP と Bindplane 認証タイプの変更をご覧ください。
LDAP。
OpenID Connect（OIDC）。
ローカル。
SAML。
Postgres TLS。詳細については、Postgres TLS をご覧ください。
Kubernetes。詳細については、GKE Workload Identity をご覧ください。

BindPlane サーバーを使用する

ほとんどの Google SecOps のお客様は Bindplane サーバーを使用していますが、その使用は任意です。Bindplane サーバーをインストールする場合は、storage.googleapis.com へのアクセス権が必要です。コレクタのみをインストールする場合は、このアクセスは必要ありません。

Bindplane サーバーを構成してログを標準化し、Google SecOps にエクスポートする方法を示すデモについては、Bindplane ユースケースのデモに移動し、[Google SecOps の構成] を選択します。

Bindplane Cloud サーバーを使用する

Bindplane Cloud は Google のお客様にご利用いただけます。

Google エディションにログインします。

Bindplane Cloud Server に関する問題については、Bindplane サポートにお問い合わせください。オンプレミスの Bindplane Server に関する問題については、Google SecOps サポートにお問い合わせください。

Google Cloudで Bindplane サーバーを使用する

Google Cloudで Bindplane サーバーを実行する方法については、Bindplane Enterprise Edition をご覧ください。

Bindplane オンプレミスサーバーを使用する

オンプレミスの Bindplane サーバーの使用には、既存の Google Cloud 利用規約が適用されます。

Linux にオンプレミスサーバーをインストールする

Linux にオンプレミスの Bindplane サーバーをインストールするには、スクリプトを実行するか（推奨）、バイナリファイルをダウンロードして手動でインストールします。詳細については、Bindplane Server をインストールするをご覧ください。

スクリプトを使用して Linux にオンプレミスの Bindplane サーバーをインストールする手順は次のとおりです。

次のスクリプトを実行します。

curl -fsSlL https://downloads.bindplane.com/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh
手順に沿って操作すると、サーバーの初期化が完了します。

バイナリファイルを使用して Linux にオンプレミスの Bindplane サーバーをインストールする手順は次のとおりです。

次のいずれかのファイルをダウンロードします。
Bindplane サーバーを構成するの手順に沿って、構成ファイルを更新します。

サポートされている Linux ディストリビューション:

Red Hat、Centos、Oracle Linux 7、8、9
Debian 11、12
Ubuntu LTS 20.04、22.04
SUSE Linux 12、15
Alma Linux と Rocky Linux

詳細については、以下をご覧ください。

Docker のオンプレミスデプロイ

詳細については、Bindplane Server をインストールするをご覧ください。

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 が付けられます。

Bindplane コレクタをインストールする

このセクションでは、さまざまなシステムに Google SecOps 用の Bindplane コレクタをインストールする方法について説明します。

コレクタは通常、最小限のリソースを使用します。ただし、大量のログを処理する場合は、他のサービスに影響を与えないようにリソースの消費に注意してください。詳細については、技術要件と推奨事項、インストールとデプロイを計画する、エージェントのサイズ設定とスケーリングをご覧ください。

コレクタ（OTel エージェント）のインストール方法については、Bindplane OTel Collector をご覧ください。

GitHub のドキュメント bindplane-otel-collector もご覧ください。

コレクタをインストールするには、次のものが必要です。

Google SecOps の取り込み認証ファイル

ファイルをダウンロードするには、次の手順に従います。
1. Google SecOps コンソールを開きます。
2. [設定] > [データ管理] > [収集エージェント] に移動します。
3. Google SecOps の取り込み認証ファイルをダウンロードします。次のステップは、移行方法によって異なります。
  - gRPC: ダウンロードした認証ファイルを使用します。
  - HTTPS: Google SecOps にリンクされている Google Cloud プロジェクトにサービスアカウントを作成し、Chronicle 編集者ロールを割り当てます。
Google SecOps のお客様 ID

お客様 ID を確認する手順は次のとおりです。
1. Google SecOps コンソールを開きます。
2. [Settings] > [Administration] > [Profile] に移動します。
3. [組織の詳細情報] セクションからお客様 ID をコピーします。
Windows 2012 SP2 以降、または systemd を使用する Linux ホスト
インターネット接続
GitHub へのアクセス

デプロイツール

このセクションでは、Bindplane のデプロイツールについて説明します。

GitOps

GitOps モデルを使用して Bindplane リソースをデプロイします。これには次のものが含まれます。

Bindplane 認証
Bindplane CLI
ネットワークアクセス
GitHub リポジトリと GitHub Actions との統合
既存のリソースのエクスポート
機密値の管理
GitHub Actions ワークフローの確立
構成の commit とテスト、自動ロールアウトの有効化、直接編集または UI エクスポート方法を使用したリソースの更新に関する手順ガイド
機密性の高い値の更新と RBAC の採用

詳細については、GitOps をご覧ください。

Ansible

Ansible を使用して Bindplane をデプロイする方法については、bindplane-agent-ansible をご覧ください。

Bindplane CLI

Bindplane CLI の詳細については、GitOps をご覧ください。

Terraform

Terraform を使用して Bindplane リソースを構成する方法については、Bindplane プロバイダをご覧ください。

Kubernetes

Bindplane を使用した Kubernetes の詳細については、以下をご覧ください。

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

ローカルパッケージからのインストール

ローカルパッケージからコレクタをインストールするには、-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 コレクタを構成する

コレクタをインストールすると、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 にあります。

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 コンソールを開き、[設定] > [データマネジメント] > [収集エージェント] に移動します。

構成ファイルの次の 2 つのセクションをカスタマイズします。

レシーバー: コレクタが収集して 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": "account@malachite-projectname.",
  "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.",
  "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": "account@malachite-projectname.",
  "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.",
  "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 フォワーダーに送信する

サンプルで次のパラメータを構成します。

構成の例:

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": "account@malachite-projectname.",
  "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.",
  "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 をご覧ください。

Collector のリリースアップデート

Bindplane は bindplane-otel-collector/releases をポーリングして、新しいコレクタリリースを検出できます。この機能の許可は任意です。

GitHub のポーリングを無効にするには、Bindplane 構成で agentVersions.syncInterval を 0 に設定します。

agentVersions:
syncInterval: 0

バックアップと障害復旧

Bindplane を使用したバックアップと障害復旧の詳細については、Bindplane のリソースをご覧ください。

PostgreSQL のバックアップと障害復旧

Bindplane を使用した PostgreSQL のバックアップと障害復旧については、PostgreSQL のドキュメントをご覧ください。

BBolt のバックアップと障害復旧

Bindplane を使用した BBolt（非推奨）のバックアップと障害復旧については、BBolt Store のドキュメントをご覧ください。

復元力と再試行

再試行は、再試行をサポートするすべての宛先でデフォルトで有効になっています。デフォルトでは、失敗したリクエストは 5 秒後に再試行され、最大 30 秒間段階的にバックオフされます。5 分が経過すると、リクエストは完全に破棄されます。

詳細については、コレクタの復元力をご覧ください。

重大度フィルタを使用してログの量を減らす

ログ量を減らす方法については、重大度フィルタを使用してログ量を減らすをご覧ください。

サードパーティコレクタとの Bindplane 統合

Bindplane は、エッジでの収集に Bindplane コレクタを使用するとより強力になりますが、ほとんどの場合、Bindplane は既存のインフラストラクチャ内に留まることができます。たとえば、すでに Fluent Bit や Splunk Universal Forwarder を使用している場合は、引き続き使用できます。

Bindplane と Splunk の統合

Bindplane を使用した Splunk の詳細については、以下をご覧ください。

Bindplane と他のサードパーティコレクタとの統合

Bindplane とサードパーティコレクタの統合については、OpAMP 拡張機能を使用した他の OpenTelemetry コレクタの接続をご覧ください。

サイレント・ホスト・モニタリング

Google Security Operations のサイレントホストモニタリングを使用すると、Google Cloud Monitoring を使用して取り込み率の変更に関するアラートを作成できます。コレクタごとにアラートを生成し、取り込み率が定義されたしきい値を下回ると通知します。これは、コレクタが停止している可能性があることを示します。

Bindplane を使用したサイレントホストのモニタリングについては、以下をご覧ください。

Linux で Bindplane をアップグレードする

Bindplane をアップグレードするには、末尾に --init フラグを指定せずに install コマンドを実行するだけで十分です。Bindplane サーバーでこのスクリプトを実行して、Bindplane をアップグレードします。詳細については、Bindplane サーバーのアップグレード、ダウングレード、アンインストールをご覧ください。

Bindplane をモニタリングする

Bindplane をモニタリングする方法については、Bindplane のモニタリングをご覧ください。

Bindplane で Kubernetes をモニタリングする

Bindplane で Kubernetes をモニタリングする方法については、Kubernetes のモニタリングをご覧ください。

その他のドキュメント

Bindplane（旧称 observIQ）の詳細については、以下をご覧ください。

さらにサポートが必要な場合 コミュニティメンバーや Google SecOps のプロフェッショナルから回答を得ることができます。

収集用の Bindplane エージェントをデプロイする

Bindplane の Google エディション

Bindplane（Google エディション）

Bindplane Enterprise（Google エディション）- Google SecOps Enterprise Plus と Google Unified Security（GUS）のお客様向け

Bindplane Enterprise ライセンスキーをダウンロードする

Bindplane Google エディションの違い

Bindplane コレクタのアーキテクチャ

コレクタがゲートウェイとして機能するコレクタにログを送信する

コレクタはログを Google SecOps 取り込み API に直接送信します。

コレクタがログを Cloud Logging に直接送信する

コレクタが複数の宛先にログを送信する

Bindplane サーバー

技術要件と推奨事項

帯域幅の要件

接続要件

Bindplane コレクタの一般的な技術要件

コレクタのリソース要件

インストールとデプロイを計画する

スケーリングとフォールト トレランスを考慮する

必要なコレクタの数を計算する

フォールト トレランスのためにコレクタ フリートをオーバープロビジョニングする

処理のオーバーヘッドをオフロードする

ゲートウェイ モードのベスト プラクティス

必要に応じてロードバランサを使用する

ロード バランシングのポートとプロトコル

ロード バランシングのサイジング

ロード バランシングのサイジングに関するベスト プラクティス

ソースタイプ ロード バランシング

本番環境で高可用性モードを使用する

HA 用のコレクタと Bindplane サーバーの数を計算する

HA 用の Postgres

HA 用の Prometheus

HA 用のイベントバス

テスト環境または概念実証に単一インスタンスのデプロイを使用する

バックエンド認証情報を分離する

ゲートウェイ コレクタをファイアウォールで保護する

ファイアウォール構成を確認する（Ingestion API）

Bindplane を使用した Google SecOps の取り込みの前提条件

Chronicle API のネットワーク要件（HTTPS）

本番環境のデプロイに PostgreSQL を使用する

適切な認証を実装する

BindPlane サーバーを使用する

Bindplane Cloud サーバーを使用する

Google Cloudで Bindplane サーバーを使用する

Bindplane オンプレミス サーバーを使用する

Linux にオンプレミス サーバーをインストールする

サポートされている Linux ディストリビューション:

Docker のオンプレミス デプロイ

Bindplane コレクタをインストールする

デプロイツール

GitOps

Ansible

Bindplane CLI

Terraform

Kubernetes

Windows に Bindplane コレクタをインストールする

Linux に Bindplane コレクタをインストールする

ローカル パッケージからのインストール

RPM のインストール

DEB のインストール

Bindplane コレクタを構成する

OTel コレクタ構成ファイル

OTel コレクタ サービスとログ

構成の変更を反映するためにコレクタ サービスを再起動する

デフォルトのサンプル構成ファイルを使用する

ログ収集構成のサンプル

Windows イベントと sysmon を Google SecOps に直接送信する

Windows イベントと syslog を Google SecOps に直接送信する

Windows イベントと syslog を Google SecOps フォワーダーに送信する

syslog を Google SecOps に直接送信する

Windows イベントをリモートで収集し、Google SecOps に直接送信する

Cloud Logging にデータを送信する

SQL データベースに対してクエリを実行し、結果を Google SecOps に送信する

正規表現に一致するログをドロップする

Bindplane の運用とメンテナンス

OTel 構成を確認する

Collector のリリース アップデート

バックアップと障害復旧

PostgreSQL のバックアップと障害復旧

BBolt のバックアップと障害復旧

スケーリングとフォールトトレランスを考慮する

フォールトトレランスのためにコレクタフリートをオーバープロビジョニングする

ゲートウェイモードのベストプラクティス

ロードバランシングのポートとプロトコル

ロードバランシングのサイジング

ロードバランシングのサイジングに関するベストプラクティス

ソースタイプロードバランシング

ゲートウェイコレクタをファイアウォールで保護する

Bindplane オンプレミスサーバーを使用する

Linux にオンプレミスサーバーをインストールする

Docker のオンプレミスデプロイ

ローカルパッケージからのインストール

OTel コレクタサービスとログ

構成の変更を反映するためにコレクタサービスを再起動する

Collector のリリースアップデート

サードパーティコレクタとの Bindplane 統合

Bindplane と他のサードパーティコレクタとの統合