Beats shipper のインストール失敗と異常ハートビートのトラブルシューティング - ES

本ガイドでは、Alibaba Cloud Elasticsearch 上で実行される Beats シッパーのインストール失敗または異常なハートビートを診断・解決する方法について説明します。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

以下のチェック項目を順に実施してください。各項目は異なる根本原因に対応しています。

Alibaba Cloud Elasticsearch 上で動作する Beats シッパーは、サポート対象の OS を必要とします。ECS インスタンスが以下のいずれかの OS を実行していることを確認してください。

インスタンスが上記以外の OS を実行している場合、Beats をサポート対象のインスタンスへ移行してください。

ECS インスタンスと Elasticsearch または Logstash クラスターは、同一の仮想プライベートクラウド (VPC) 内にある必要があります。異なる VPC に配置されている場合、Beats は出力先に接続できず、インストールに失敗します。

Beats は、クラウドアシスタントによって管理される Docker コンテナ内で実行されます。これらのいずれかのサービスが存在しない、または停止している場合、シッパーは起動できません。

ECS インスタンスに接続し、以下のコマンドを実行します。

クラウドアシスタントの確認：

systemctl status aliyun.service

正常に動作しているクラウドアシスタントでは、以下と同様の出力が表示されます。

クラウドアシスタントが実行されていない場合は、「クラウドアシスタントクライアントのインストール」をご参照ください。

Docker の確認：

systemctl status docker

正常に動作している Docker サービスでは、以下と同様の出力が表示されます。

Docker が実行されていない場合は、「Alibaba Cloud Linux 2 インスタンスへの Docker のデプロイと使用」をご参照ください。

シッパーの YAML 構成ファイルにおけるパラメーターの誤設定は、インストール失敗の一般的な原因です。ファイルに以下の内容が含まれていることを確認してください。

- type: log
  # この入力構成を有効化するには、true に変更します。
  enabled: true
  # クロールおよびフェッチ対象のパス。ワイルドカードを含むパスを指定できます。
  paths:
    - /var/log/*.log

パラメーター	説明
`enabled`	`true` を設定すると、この入力が有効になります。デフォルト値は `false` です。
`paths`	収集対象のログファイルのパス。ワイルドカード（例：`*.log`）をサポートします。

重要

以下の制約事項にご注意ください。

paths と Filebeat ログファイルパスの違い：YAML ファイル内の paths 値と、構成ページ上の Filebeat ログファイルパス は、それぞれ異なる役割を果たします。Docker は Filebeat ログファイルパス で指定されたパスをマッピングし、そのマッピング後に paths で指定された場所にデータが到達します。収集漏れを防ぐため、両方の値を同一のパスに設定してください。
出力構成の重複：構成ページ上で既に出力を指定している場合、YAML ファイル内に output セクションを追加しないでください。出力構成が重複すると、インストールエラーが発生します。
コメントアウトされたパラメーター：X-Pack 関連などのパラメーターは、# によりコメントアウトされている場合があります。これらのパラメーターのコメントを解除する際は、値の設定に十分注意してください。誤った値を設定すると、シッパーのインストールが失敗する可能性があります。

インストールが正常に完了した後、Beats は /opt/aliyunbeats/ にディレクトリを作成し、その下に conf、data、logs の 3 つのサブフォルダが生成されます。

ECS インスタンスに接続し、該当ディレクトリおよびフォルダが存在することを確認してください。

ディレクトリが存在しない場合、インストールは完了していません。原因を特定するために、前述の手順を再確認してください。

ディレクトリが存在する場合は、問題の特定に役立つエラーメッセージを logs フォルダ内で確認してください。

前述のチェックを実施してもシッパーが動作しない場合、Docker コンテナ自体を直接確認します。

コンテナの状態を確認します。
```
docker ps -a | grep filebeat
```
コンテナの状態が exited の場合、エラーの原因を特定するためにログを取得します。
```
docker logs -f <container-id>
```
<container-id> は、直前のコマンドの出力から取得したコンテナ ID に置き換えてください。