Beatsを使用したDockerおよびKubernetesのヒントベースの自動探知機能（Autodiscover）

6.0より、Beatsへの新機能の追加を開始し、コンテナー監視のサポートを改善しています。そして最近、新たな機能を導入しました。FilebeatおよびMetricbeatの自動探知機能です。DockerとKubernetesをサポートします。自動探知機能（Autodiscover）で設定のセットを定義しておくと、ある設定を起動するとき、Beatsによって動的に起動させることができます。コンテナーは動的な性質を持つため、その監視にはこの機能が特に役立ちます。

コンテナー監視の課題

従来のインフラストラクチャーでは、通常、新しいホストをセットアップし、そこで稼働させるサービスのすべてを設定し、それらに定期的にクエリを送信する監視エージェントを設定します。設定管理ツールがそのタスクに役立ちますが、それでもかなり静的です。

コンテナーアーキテクチャーなら、すべてが動的になります。デプロイは動的で、拡大、縮小、消失することがあり、コンテナーはノードからノードの間を移動します。メトリックの取得対象の固定IPはありません。

追跡するためには、特定のツールが必要になります。

自動探知機能

自動探知機能の設定を見てみましょう。下記はサンプルです。

metricbeat.autodiscover:
  providers:
   - type: docker
     templates:
       - condition.contains:
           docker.container.image: etcd
         config:
          - module: etcd
            metricsets: ["leader", "self", "store"]
            hosts: "${data.host}:2379"

output.elasticsearch:
  hosts: ["localhost:9200"]

これは、自動探知機能プロバイダーのdockerを使用するようにMetricbeatを設定しています。使用するテンプレートのリストを定義し、トリガーされる条件と紐づけることができます。この場合、その条件は「etcdを含むコンテナーイメージと一致」となります（ 「コンテナー」を、名前とタグのペアを格納するイメージフィールドとして使用しています）。etcdコンテナーが作成されると、Metricbeatはそれを監視するためにetcdモジュールを起動し、変数の${data.host}をそのコンテナーのIPに置き換えます。

詳細を見て行きましょう。

1.自動探知イベント

Beatsの自動探知機能は複数のプロバイダーをサポートします。現在は、KubernetesとDockerです。プロバイダーが、特定のプラットフォーム上でのイベントを監視する方法を実装します。イベントが発生すると、その対処に必要なすべての情報が含まれた自動探知イベントをプロバイダーが発行します。

2.条件の一致

各イベントは、プロセッサーと同じ設定形式を使用して、条件のリストに照らしてチェックされます。1つの条件がイベントに一致すると、所定の設定のセットが起動されます。

3.変数展開

設定テンプレートには変数を含めることができます。変数は、条件をトリガーしたイベントの実際の値に置換されます。この仕組みにより、IPアドレスなど、コンテナーのステータスに依存する動的な設定を定義できます。ただし、ラベルと注釈を使用することでさらに複雑な設定も可能です。

4.開始/停止の設定

最後の設定を作成すると、自動探知プロセスによって起動されるようになります。有効な設定には、 MetricbeatおよびFilebeatのモジュールが含まれており、またFilebeatには入力も含まれます。

開始と停止の両方のイベントがあり、自動探知機能によって起動される設定はコンテナーが移動すると自動的に停止します。このために特別な設定は必要ありません。

自動探知機能の使用時に役立つ追加機能により、探知によって発生するすべてのイベントでは、自動的にDockerまたはKubernetesのメタデータが追加されるため、adddockermetadataまたはaddkubernetesmetadataプロセスを使用する必要はありません。このメタデータは、ログおよびメトリックを確認するときに、フィルターしたり重要ポイントに焦点を絞るのに便利です。

ヒントの導入

6.3リリースでは、 コンテナーの監視方法を定義するためのヒントを使用できます。新たに展開されたアプリケーションの監視を設定する場合、従来はBeats設定を更新する必要がありました。

ヒントベースの自動探知機能では、監視設定の制御の概念が逆転しています。つまり、監視設定を中央ではなくアプリケーションコンテナの隣に保存できるようにすることで、アプリケーションを構築および展開するチームがその監視方法の定義の責任を担うようにするのです。

この設定により、Kubernetesコンテナーログ向けのヒントベースの自動探知機能が実現します（この変更はFilebeat向けのKubernetesマニフェストリファレンスなどを参照して実行できます）。

filebeat.autodiscover:
  providers:
    - type: kubernetes
      hints.enabled: true

これだけです。Kubernetesポッドの注釈またはDockerのラベルを使用して、コンテナーログの処理方法をFilebeatおよびMetricbeatに指示することができます。たとえば、ポッドでJavaアプリケーションを実行している場合、次の注釈を追加できます。

annotations:
  co.elastic.logs/multiline.pattern: '^\['
  co.elastic.logs/multiline.negate: 'true'
  co.elastic.logs/multiline.match: after

ポッドが起動すると、Filebeatは注釈を処理し、Javaスタックトレースをまとめるために、所定の複数行パターンでログの読み取りを開始します。利用可能なすべてのヒントについては、ドキュメントを参照してください。

また、モジュールを使用して、ログを構造化データにできます。たとえば、NGINXサーバーを実行している場合、下記の注釈を追加するだけでそのすべてのログが処理され、アクセスに関するインサイトが得られます。

annotations:
  co.elastic.logs/module: nginx
  co.elastic.logs/fileset.stdout: access
  co.elastic.logs/fileset.stderr: error

ご覧のとおり、ログ出力の各ストリームが異なるファイルセットにマッピングされています。co.elastic.logs/filesetとすれば、すべてのストリームを単一のファイルセットにマッピングできます。

また、Metricbeatを使用する際にはヒントが役に立ちます。下記は、同じNGINXインスタンスで、Metricbeatがメトリックを取得するように設定する方法です。ここでは変数展開も利用でき、コンテナーのIPアドレスを取得するために${data.host}を使用しています。

annotations:
  co.elastic.metrics/module: nginx
  co.elastic.metrics/metricsets: stubstatus
  co.elastic.metrics/hosts: '${data.host}:80'
  co.elastic.metrics/period:10s

FilebeatとMetricbeatの両方を実行している場合、両方のヒントを使用できることを覚えておいてください。

まとめ

ヒントベースの自動探知機能は、監視するアプリケーションの隣に監視設定の構成を移動します。これによって、特にマルチテナントのシナリオにおいて、チームに適切なツールが提供されます。また、シンプルな一連のインストラクションも提供されるため、エクスペリエンスがシンプルで要領を得たものになります。

ここでは、自動探知機能でできることのほんの一部のみを紹介しました。ぜひフィードバックをお寄せください。皆さまがどのように使用しているかについて教えていただければと思います。また、Beatsフォーラムにぜひお越しいただき、皆さまのエクスペリエンスについてお教えください。