インスタンス複製時にMackerelの監視を継続する方法～AMIからの復元やAWS Elastic Disaster Recovery利用時の注意点～

1. 複製元インスタンスの状況

AMIの作成やAWS Elastic Disaster Recoveryでのデータレプリケーション等の対象とするインスタンスはmackerel-agentを導入して監視状態にしておきます。

[root@ip-10-0-10-143 ~]# ec2-metadata -i
instance-id: i-091f2c869bf1e2e9b
[root@ip-10-0-10-143 ~]#
[root@ip-10-0-10-143 ~]# systemctl status mackerel-agent
● mackerel-agent.service - mackerel.io agent
Loaded: loaded (/usr/lib/systemd/system/mackerel-agent.service; enabled; preset: disabled)
Active: active (running) since Wed 2026-03-04 02:41:37 UTC; 40s ago
Docs: https://mackerel.io/
Process: 60188 ExecStartPre=/usr/bin/mkdir -m 777 -p $MACKEREL_PLUGIN_WORKDIR (code=exited, status=0/SUCCESS)
Main PID: 60189 (mackerel-agent)
Tasks: 14 (limit: 2263)
Memory: 9.2M
CPU: 105ms
～省略～
[root@ip-10-0-10-143 ~]#

Mackerelのコンソールでも確認しておきます。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

2. 複製したインスタンスの状況

複製元のインスタンスのAMIを取得し別のインスタンスとして起動、もしくはAWS Elastic Disaster Recoveryを使用してリカバリインスタンスを起動します。

複製したインスタンスの起動後の状態は以下のように、mackerel-agentが動作していない状態となります。

[root@ip-10-1-10-71 ~]# ec2-metadata -i
instance-id: i-019b72d5f470117ab
[root@ip-10-1-10-71 ~]#
[root@ip-10-1-10-71 ~]# systemctl status mackerel-agent
× mackerel-agent.service - mackerel.io agent
Loaded: loaded (/usr/lib/systemd/system/mackerel-agent.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Wed 2026-03-04 05:29:28 UTC; 21min ago
Duration: 1.344s
Docs: https://mackerel.io/
Process: 1808 ExecStartPre=/usr/bin/mkdir -m 777 -p $MACKEREL_PLUGIN_WORKDIR (code=exited, status=0/SUCCESS)
Process: 1812 ExecStart=/usr/bin/mackerel-agent supervise --root $ROOT $OTHER_OPTS (code=exited, status=1/FAILURE)
Process: 1917 ExecStopPost=/bin/sh -c [ "$AUTO_RETIREMENT" == "" ] || [ "$AUTO_RETIREMENT" == "0" ] && true || /usr/bin/mackerel-agent retire -force --root $ROOT $OTHER_OPTS (code=exite>
Main PID: 1812 (code=exited, status=1/FAILURE)
CPU: 86ms

～省略～
[root@ip-10-1-10-71 ~]#

mackerel-agentが起動していない為、Mackerelコンソール上でも複製したインスタンスは登録されておらず、監視ができていない状態となります。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

3. 原因と対処方法

3-1. 原因

複製したインスタンスのmackerel-agentのログを確認すると以下のログを確認することができます。

[root@ip-10-1-10-71 ~]# journalctl -umackerel-agent| grep failed
Mar 04 05:29:28 ip-10-1-10-71.ap-northeast-3.compute.internal mackerel-agent[1869]: command.Prepare failed: failed to prepare host: custom identifiers mismatch: this host = "i-019b72d5f470117ab.ec2.amazonaws.com", the host whose id is "5HaWPJV7HBf" on mackerel.io = "i-091f2c869bf1e2e9b.ec2.amazonaws.com" (File "/var/lib/mackerel-agent/id" may be copied from another host. Try deleting it and restarting agent)

以下のドキュメントから、複製元のインスタンスのidをそのまま引き継いだ状態で、別のインスタンスとして起動してしまうことが、今回の原因です。

原因

• Amazon EC2、Azure Virtual Machine、Google Compute Engineにおいて、ホスト登録を行ったことがある仮想マシンの複製や、ホスト登録を行ったことがある仮想マシンのイメージから仮想マシンを起動して、新たにホスト登録を行おうとした場合に発生します。

custom_identifierとは

• Amazon EC2、Azure Virtual Machine、Google Compute Engineの仮想マシンでは、ホストIDの他にホストごとに一意のcustom_identifierという識別子が生成されます。custom_identifierにはインスタンスIDなど固有の情報が値として使用されます。そのため、複製されたサーバーのcustom_identifierは必ず複製元のサーバーと異なる値になります。MackerelではホストIDとcustom_identifierを紐づけて管理しており、複製元のサーバーのidファイルが残っていると、ホストIDとcustom_identifierの不整合が発生し、mackerel-agentの起動に失敗します。

ホストが登録されない（mackerel-agent）

3-2. 対処方法

対処方法も先程の公式ドキュメントに記載があり、idファイルを削除してからmackerel-agentを再起動します。

対処方法

• idファイルを削除してmackerel-agentを再起動します（新規のホストとして登録されます）。
• ホスト登録を行ったことがあるサーバーを複製する際は、複製されたサーバーのidファイルを削除してからmackerel-agentを起動するようにしてください。
• ホスト登録を行ったことがあるサーバーのマシンイメージを作成する際は、マシンイメージにidファイルを含まないように注意してください。

この時DR等の対応でAMIやAWS Elastic Disaster Recovery等を使用して起動したインスタンスの場合、手動でidファイルを削除してMackerelに登録し直すのではなく、ユーザーデータを利用してインスタンス起動時に自動で削除するように起動テンプレートを構築しておくと良いでしょう。

ユーザーデータのサンプルは以下となります。

AMIやAWS Elastic Disaster Recoveryを用いて「複製起動するインスタンス」を想定しています

#!/bin/bash
systemctl stop mackerel-agent
rm -f /var/lib/mackerel-agent/id
systemctl start mackerel-agent

複製したインスタンスを起動した際に、Mackerelコンソールにて該当のホストを確認できれば動作確認はOKです。

以下の例では大阪リージョンにインスタンスを複製しました（上が複製されたホスト）。

NTT東日本では、AWSなどクラウドに関するお役立ち情報をメールマガジンにて発信していますので、ぜひこちらからご登録ください。

4. さいごに

本コラムでは、Mackerelを利用した監視環境において、AMIやAWS Elastic Disaster Recovery等を使用してインスタンスを複製した際に発生する問題とその対処方法をご紹介しました。

DRや障害対応時は復旧作業に注力しがちですが、監視が自動的に復旧する仕組みを事前に用意しておくことも重要です。Mackerelの場合はidファイルをインスタンス起動時に削除するようにすることで、スムーズに監視を再開することが可能となります。

本コラムが誰かの参考にありましたら幸いです。

NTT東日本では経験豊かなエンジニアが、AWSの構築保守からネットワーク設計を含めエンドツーエンドでのソリューションを提供しております。ぜひお気軽にお問い合わせください。

• Amazon Web Services（AWS）およびその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。