Linux でのフォワーダーのインストールと構成

このドキュメントでは、Linux でフォワーダーをインストールして構成する方法について説明します。フォワーダーは、さまざまな Linux ディストリビューション（Debian、Ubuntu、Red Hat、Suse など）にインストールできます。Google Cloud はソフトウェア の提供に Docker コンテナを使用します。Docker コンテナは、Linux を実行している物理マシンまたは仮想マシンで実行して、管理できます。

構成ファイルをカスタマイズする

Google Cloud はデプロイ前に送信した情報に基づいて、フォワーダー ソフトウェアと構成ファイルを提供します。Google Cloud は、構成ファイルをネットワーク上のフォワーダー インスタンスに合わせて調整します。構成を変更する必要がある場合は、Chronicle サポートにお問い合わせください。

システム要件

一般的な最適化案は次のとおりです。システムに固有の最適化案については、Chronicle サポートにお問い合わせください。

  • RAM - 収集されるデータの種類ごとに 1.5 GB。たとえば、エンドポイントの検出とレスポンス（EDR）、DNS、DHCP は別々のデータ型です。3 種類すべてのデータを収集するには、4.5 GB の RAM が必要になります。

  • CPU - 2 個の CPU は、10,000 EPS（1 秒あたりイベント数）（すべてのデータ型の合計）未満を処理するには十分です。10,000 EPS を超えるイベントを転送する予定の場合は、4～6 個の CPU をプロビジョニングします。

  • ディスク - Chronicle フォワーダーで処理するデータの量に関係なく、100 MB のディスク容量で十分です。バックログにあるメッセージをメモリではなくディスクにバッファリングする必要がある場合は、ディスク バッファリングもご覧ください。Chronicle フォワーダーは、デフォルトでメモリにバッファリングします。

ファイアウォール構成を確認する

Chronicle フォワーダー コンテナとインターネットの間にファイアウォールまたは認証プロキシがある場合は、次のホストへのアクセスを開くためのルールが必要です。

接続タイプ 宛先 ポート
TCP malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Splunk データを収集する

Splunk のデータを Chronicle に転送するように Chronicle フォワーダーを構成できます。Google Cloud は次の情報を使用して、Splunk からデータを転送するように Chronicle フォワーダーを構成します。

  • Splunk REST API の URL（例: https://10.0.113.15:8889）

  • 必要な各データ型（index=dns など）のデータを生成する Splunk クエリ。

Splunk アカウントの認証情報を Chronicle Forwarder で利用できるようにする必要があります。

Splunk の認証情報のローカル ファイルを作成し、creds.txt という名前を付けます。最初の行にユーザー名を入力し、2 行目にパスワードを入力します。

  cat creds-file

  myusername
  mypassword

Chronicle フォワーダーを使用して Splunk インスタンスにアクセスするお客様の場合は、creds.txt ファイルを config ディレクトリ（構成ファイルと同じディレクトリ）にコピーします。次に例を示します。

cp creds-file ~/config/creds.txt

creds.txtem> ファイルが正しい場所にあることを確認します。

ls ~/config 

- splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10
      maximum_window_size: 30
      user: admin
      password: letmeinaA1!
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size: Splunk クエリに渡す最小の時間範囲。デフォルト値は 10 秒です。このパラメータは、フォワーダーが安定した状態のときに Splunk サーバーにクエリを行う頻度を変更する必要がある場合に調整に使用されます。また、遅延がある場合、Splunk API 呼び出しが複数回行われることがあります。

maximum_window_size: Splunk クエリに渡される最大時間範囲。デフォルト値は 30 秒です。このパラメータは、遅延がある場合や、クエリごとにより多くのデータが必要な場合に、調整に使用されます。

最小パラメータを変更する場合は、このパラメータを変更します（以上）。遅延ケースは、Splunk のクエリ呼び出しが max_window_size よりも時間がかかる場合に発生することがあります。

Docker のインストール

Docker はさまざまなホスト オペレーティング システムにインストールできます。Docker の実際のインストールはホスト環境によって異なります。Google Cloud では、いくつかの一般的な Linux ディストリビューションに Docker をインストールする際に役立つドキュメントが限られています。とはいえ、Docker はオープンソースであり、十分なドキュメントがすでに利用可能です。

システムに Docker をインストールした後は、使用している Linux ディストリビューションにかかわらず、残りの Chronicle Forwarder のインストール プロセスは同じです。

次のコマンドを実行して、Docker がシステムにインストールされていることを確認します（高度な権限が必要）。

# docker ps

次のレスポンスは、Docker が適切にインストールされていることを示しています。

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

次のコマンドを使用して、Docker のインストールに関する追加情報を収集できます。

# docker info

Docker に問題がある場合は、Chronicle のサポートがデバッグの実施を支援するために、このコマンドの出力をリクエストする可能性があります。

フォワーダーをインストールする

このセクションでは、Docker コンテナを使用して Linux システムに Chronicle フォワーダーをインストールする方法について説明します。

ステップ 1. フォワーダー構成ファイルのダウンロード、転送、インストール

Google Cloud には、ご使用のオペレーティング システム（Linux または Windows）に固有のフォワーダー構成ファイルが用意されています。Chronicle の担当者から提供されたリンクから、ノートパソコンのローカル ディレクトリ（chronicle など）にこれらのファイルをダウンロードします。以下の手順を完了したら、ノートパソコンからユーザーのホーム ディレクトリ内にあるフォワーダーの ~/config ディレクトリに構成ファイルを転送します。

  1. ターミナルから Linux フォワーダーに接続します。

  2. Linux フォワーダーで新しいユーザーを作成します。

    # adduser <username>

    # passwd <username>

    # usermod -aG wheel <username>

  3. ディレクトリを、Docker コンテナを実行する新しいユーザーのホーム ディレクトリに変更します。

  4. Chronicle フォワーダーの構成ファイル # mkdir ~/config を格納するディレクトリを作成します。

  5. ディレクトリの移動

  6. ファイルが転送されたら、構成ファイルが ~/config ディレクトリにあることを確認します。

    # ls -l

ステップ 2. Docker コンテナ内でフォワーダーを実行する

次の手順を使用して最初に Chronicle フォワーダーを起動し、Chronicle コンテナの最新バージョンにアップグレードします。

--log-opt オプションは、Docker 1.13 以降で利用可能です。これらのオプションはコンテナ ログファイルのサイズを制限するものであり、Docker のバージョンがサポートしている限り、使用する必要があります。

  1. アップグレードする場合は、まず、以前に実行した Docker をクリーンアップします。以下の例では、Docker コンテナの名前は cfps であり、その後、下記の # docker pull コマンドを使用して Google Cloud から最新の Docker イメージを取得します。

    # docker stop cfps
# docker rm cfps

  2. Google Cloud から最新の Docker イメージを取得します。

    # docker pull gcr.io/chronicle-container/cf_production_stable

  3. Docker コンテナから Chronicle Forwarder を起動します。

    docker run \

  --detach \

  --name cfps \

  --restart=always \

  --log-opt max-size=100m \

  --log-opt max-file=10 \

  --net=host \

  -v ~/config:/opt/chronicle/external \

  gcr.io/chronicle-container/cf_production_stable

これらのコマンドは、run_docker_production_stable.sh というシェル スクリプトとしても提供されます。

Docker コンテナ（および Chronicle Forwarder）は、システムの再起動後も維持されます。

ステップ 3: フォワーダーをモニタリング、管理する

以下の Docker コマンドにより、Chronicle フォワーダーのモニタリングと管理ができます。

  • Docker コンテナが実行されているかどうかを確認します。

    docker ps

  • コンテナからログを表示します。これにより、大量の出力が生成される可能性がありますが、デバッグに有用です。

    docker logs cfps

  • コンテナ内で実行されている内容を確認するには:

    docker top cfps

  • コンテナを停止するには:

    docker stop cfps

syslog データを収集する

Chronicle フォワーダーは、Syslog サーバーとして動作できます。つまり、TCP または UDP 接続を介した syslog データの送信をサポートする任意のアプライアンスまたはサーバーを構成して、Chronicle フォワーダーにデータを転送できます。アプライアンスまたはサーバーが Chronicle フォワーダーに送信するデータを正確に制御できます。その結果、Chronicle フォワーダーがデータを Chronicle に転送できるようになります。

構成ファイル（Google Cloud が提供）では、転送されるデータの種類ごとにモニタリングするポートを指定します（例: ポート 10514）。デフォルトでは、Chronicle Forwarder は TCP 接続と UDP 接続の両方を受け入れます。

rsyslog を構成する

rsyslog を構成するには、各ポートのターゲット（例: 各データ型）を指定する必要があります。正しい構文については、システムのドキュメントをご覧ください。rsyslog のターゲット構成の例を次に示します。

  • TCP ログ トラフィック: dns.* @192.168.0.12:10514

  • UDP ログ トラフィック: dns.* @192.168.0.12:10514

syslog 構成用の TLS の有効化

Chronicle フォワーダーへの syslog 接続用の TLS を有効にできます。Chronicle フォワーダーの構成ファイルで、次の例に示すように、自己生成の証明書と証明書鍵の場所を指定します。

証明書 "/opt/chronicle/external/certs/client_generated_cert.pem"
certificate_key "/opt/chronicle/external/certs/client_generated_cert.key"

示している例に基づいて、Chronicle フォワーダーの構成は次のように変更されます。

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
  tcp_address: 0.0.0.0:10515
  tcp_buffer_size: 65536
  connection_timeout_sec: 60
  certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

batch_n_bytes の値は 5 MB を超えないようにしてください。

構成ディレクトリの下に証明書ディレクトリを作成し、証明書ファイルを保存できます。

ファイルデータを収集する

Docker コンテナから Chronicle フォワーダーを起動します。

  docker run \

    --name cfps \

    --log-opt max-size=100m \

    --log-opt max-file=10 \

    --net=host \

    -v ~/config:/opt/chronicle/external \

    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \

     gcr.io/chronicle-container/cf_production_stable

この docker run コマンドは、読み込みボリュームをコンテナにマッピングするのに不可欠です。

この例に基づいて、Chronicle フォワーダーの構成を次のように変更します。

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: /opt/chronicle/edr/output/sample.txt
       filter:

パケットデータを収集する

Chronicle フォワーダーでは、Linux の libpcap を使用してネットワーク インターフェースから直接パケットをキャプチャできます。パケットはキャプチャされ、ログエントリではなく Chronicle に送信されます。パケット キャプチャはローカル インターフェースからのみ処理されます。システムのパケット キャプチャを有効にするには、Chronicle のサポートにお問い合わせください。

Google Cloud は、パケットをキャプチャするために使用される Berkeley Packack Filter（BPF）式を使用して Chronicle フォワーダーを構成します（たとえば、localhost ではなく、ポート 53）。

データ圧縮を切り替える

ログ圧縮により、ログを Chronicle に転送する際のネットワーク帯域幅の使用量が削減されます。ただし、圧縮によって CPU 使用率が増加する場合があります。CPU 使用率と帯域幅のトレードオフは、ログデータのタイプ、データの圧縮率、フォワーダーを実行しているホスト上の CPU サイクルの可用性、ネットワーク帯域幅の使用量の削減の必要性など、さまざまな要因によって決まります。

たとえば、テキストベースのログは圧縮率が高く、低い CPU 使用率によって帯域幅を大幅に削減できます。一方、未加工のパケットの暗号化されたペイロードは圧縮率が低く、CPU 使用率が高くなります。

ログ圧縮はデフォルトで無効になっています。ログ圧縮を有効にすると、帯域幅の消費が減少する可能性があります。ただし、ログ圧縮を有効にすると CPU 使用率も増加する場合があります。トレードオフに注意してください。

ログ圧縮を有効にするには、次の例に示すように、Chronicle フォワーダー構成ファイルの圧縮フィールドを true に設定します。

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
      secret_key: |
        {
          "type": "service_account",
...

ディスク バッファリング

ディスク バッファリングを使用すると、バックログにあるメッセージをメモリではなくディスクにバッファ保存できます。バックログにあるメッセージは、フォワーダーがクラッシュした場合や基盤となるホストがクラッシュした場合に保存されます。ディスク バッファを有効にするとパフォーマンスに影響する可能性があるので注意してください。

Docker を使用して Forwarder を実行している場合は、分離の目的のため、構成ボリュームとは別のボリュームをマウントすることをおすすめします。また、競合を避けるために、各入力を独自のディレクトリまたはボリュームで分離するべきです。

構成例: ディスク バッファリング

次の構成には、ディスク バッファリングを有効にする構文が含まれています。

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

正規表現フィルタ

正規表現フィルタを使用すると、正規表現と未加工のログの照合に基づいてログをフィルタできます。

フィルタでは https://github.com/google/re2/wiki/Syntax で説明されている RE2 構文を使用します。

フィルタには正規表現を含める必要があります。また、必要に応じて、一致した場合の動作を定義します。一致のデフォルトの動作は「ブロック」です（ブロックとして明示的に構成できます）。

または、allow の動作を指定してフィルタを指定することもできます。許可フィルタを指定した場合、フォワーダーは、少なくとも 1 つの許可フィルタに一致しないログをブロックします。

任意の数のフィルタを定義できます。ブロック フィルタは、許可フィルタよりも優先されます。

フィルタを定義するときに、名前を割り当てる必要があります。アクティブなフィルタの名前は、Forwarder ヘルス指標を介して Chronicle に報告されます。構成のルートで定義されたフィルタは、コレクタレベルで定義されたフィルタと統合されます。名前が競合する場合、コレクタレベルのフィルタが優先されます。ルートレベルまたはコレクタレベルでフィルタが定義されていない場合、動作はすべて許可されます。

構成例: 正規表現フィルタ

次のフォワーダー構成では、ルートフィルタ（allow_filter）に一致しない WINEVTLOG ログがブロックされます。正規表現では、フィルタでは 0 から 99 の間の優先値を持つログのみが許可されます。ただし、「foo」や「bar」を含む NIX_SYSTEM ログは、allow_filter であるにもかかわらずブロックされます。これは、フィルタでは論理 OR が使用されているためです。フィルタがトリガーされるまで、すべてのログが処理されます。

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

任意のラベル

ラベルは、キーと値のペアを使用してログに任意のメタデータを追加するために使用されます。ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が指定されている場合、ラベルには、フォワーダー キーが重複する場合にコレクタのキーが優先してマージされます。

構成例: 任意のラベル

次のフォワーダー構成では、「foo=bar」と「meow=mix」のキーと値のペアの両方が WINEVTLOG ログにアタッチされ、「foo=baz」と「meow=mix」のキーと値のペアが NIX_SYSTEM のログにアタッチされます。

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

名前空間

名前空間ラベルを使用して、異なるネットワーク セグメントのログを識別し、重複する IP アドレスの競合を解決します。名前空間ラベルは、フォワーダー全体に対して、またはフォワーダーの特定のコレクタ内で構成できます。両方が含まれている場合、特定のコレクタの名前空間が優先されます。

フォワーダーに構成された名前空間は、関連するアセットとともに Chronicle のユーザー インターフェースに表示されます。Chronicle の検索機能を使用して名前空間を検索することもできます。

Chronicle のユーザー インターフェースで名前空間を表示する方法については、こちらをご覧ください。

構成例: 名前空間

次のフォワーダー構成では、WINEVTLOG ログが FORWARDER 名前空間にアタッチされ、NIX_SYSTEM ログが CORPORATE 名前空間にアタッチされています。

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Kafka 入力

Syslog の場合と同様に、Kafka トピックからデータを取り込めます。コンシューマ グループを活用することで、最大 3 つのフォワーダーをデプロイし、同じ Kafka トピックからデータを pull できます。

Kafka 消費者グループの詳細については、https://docs.confluent.io/platform/current/clients/consumer.html をご覧ください。

構成例: Kafka の入力

次の Forwarder 構成は、Kafka トピックからデータを取り込むようにフォワーダーを設定する方法を示しています。

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      username: user
      password: password
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

ロード バランシングと高可用性

Chronicle Linux フォワーダーは、データソースとフォワーダー インスタンスの間にレイヤ 4 ロードバランサがインストールされている環境にデプロイできます。これにより、お客様は複数のフォワーダー間でログ収集を分散したり、フォワーダーで障害が発生した場合に別のフォワーダーにログを送信したりできます。この機能は、syslog コレクション タイプでのみサポートされています。

Linux フォワーダーには、ロードバランサからの HTTP ヘルスチェックに応答する組み込み HTTP サーバーが含まれています。また、HTTP サーバーは、フォワーダーの起動またはシャットダウン中にログが失われるのを防ぐこともできます。

フォワーダー構成ファイルの server セクションで、HTTP サーバー、ロード バランシング、高可用性オプションを構成します。これらのオプションは、コンテナ スケジューラやオーケストレーション ベースのデプロイで受信されるヘルスチェックや、従来のロードバランサで受信されるヘルスチェックに応じて返されるタイムアウト期間とステータス コードの設定をサポートします。

ヘルスチェック、準備状況、実行チェックには、次の URL パスを使用します。<host:port> 値は、フォワーダー構成で定義されます。

  • http://<host:port>/meta/available: Kubernetes などのコンテナ スケジューラ/オーケストレーターの liveness チェック。
  • http://<host:port>/meta/ready: readiness チェックと従来のロードバランサのヘルスチェック。

次のフォワーダー構成は、ロード バランシングと高可用性の例です。

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
構成パス 説明
server : graceful_timeout フォワーダーが不適切な準備やヘルスチェックを返していながら新しい接続を引き続き受け入れている時間。これは、停止する信号を受信してから実際にサーバー自体のシャットダウンが開始されるまで、待機する時間でもあります。これにより、ロードバランサがプールからフォワーダーを削除する時間を確保できます。
server : drain_timeout アクティブな接続がサーバーによって閉じられる前に、独自に正常に終了するまでフォワーダーが待機する時間。
server : http : port HTTP サーバーがロードバランサからのヘルスチェックをリッスンするポート番号。1,024 ～ 65,535 にする必要があります。
server : http : host サーバーがリッスンする IP アドレスまたはホスト名。IP アドレスに解決できます。空の場合、デフォルト値はローカル システム（0.0.0.0）です。
server : http : read_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。ヘッダーと本文の両方でリクエスト全体を読み取るための最大時間。read_timeout と read_header_timeout の両方を設定できます。
server : http : read_header_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。リクエスト ヘッダーの読み取りが許可される最大時間。ヘッダーの読み取り後に、接続の読み取り期限がリセットされます。
server : http : write_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。レスポンスの送信に許可される最大時間。新しいリクエスト ヘッダーが読み取られるとリセットされます。
server : http : idle_timeout HTTP サーバーの調整に使用されます。通常、デフォルト設定から変更する必要はありません。アイドル状態の接続が有効である場合に、次のリクエストを待機する最大時間。controller_timout がゼロの場合、read_timout の値が使用されます。両方がゼロの場合、read_header_timeout が使用されます。
routes : meta : ready_status 次のいずれかの状況でトラフィックを受け入れる準備ができた場合にフォワーダーが返すステータス コード。
  • 準備チェックは、Kubernetes などのコンテナ スケジューラまたはオーケストレーターから受信されます。
  • ヘルスチェックは、従来のロードバランサから受信されます。
routes : meta : unready_status フォワーダーがトラフィックを受け入れる準備ができていない場合に返すステータス コード。
routes : meta : available_status 実行チェックが受信され、フォワーダーが利用可能な場合に、フォワーダーが返すステータス コード。実行チェックは、多くの場合、Kubernetes などのコンテナ スケジューラやオーケストレーターによって送信されます。

よくある質問

Docker コンテナとは何か教えてください。

  • Docker コンテナは仮想マシンと同様に、セキュリティ、分離、リソースの管理を強化します。

  • 仮想マシン - 特権空間（Linux カーネル）とユーザー空間（libc、python、ls、tcpdump などのすべて）の両方があります。

  • コンテナにはユーザー空間（libc、python、ls、tcpdump などのすべて）のみあり、ホストの権限空間に依存します。

コンテナを使用して Chronicle フォワーダーが配布される理由を教えてください。

  • 分離によってセキュリティを強化します:
    • お客様の環境と要件は、Chronicle フォワーダーには影響しません。
    • Chronicle フォワーダーの環境と要件は、お客様には影響しません。
    • コンテナ配布メカニズムはすでに存在しており、非公開にして、Google Cloud とお客様向けに分けることができます: https://cloud.google.com/container-registry/

コンテナに対応しているのが Linux のみであるのはなぜですか。Windows についてどうですか？

  • コンテナは最初に Linux 用に開発され、現在本番環境に対応しています。

  • コンテナの Windows サポートは改善されています。コンテナは Windows Server 2016 と Windows 10 で使用できます。

高度な Docker コマンドを使用する必要はありますか？

  • Chronicle のフォワーダーは単一のコンテナを使用するため、Swarm、オーケストレーション、Kubernetes、その他の高度な Docker のコンセプトやコマンドについて学ぶ必要はありません。