Mackerelでサーバーを監視する手順｜agent導入から料金試算と採用判断まで

Mackerelは、株式会社はてなが開発・提供しているSaaS型の監視サービスです。監視サーバーを自前で建てる代わりに、対象ホストへ mackerel-agent を入れると、CPU・メモリ・ディスクといったホストメトリックが1分間隔で投稿され、Web画面にグラフが並びます。この記事では、agentをUbuntuとRHEL系へ入れてホストを登録するまでのコマンド、mackerel-agent.conf に書く apikey・roles・include の指定、conf.d へ分割したチェック監視の設定、監視ルールをAPIとTerraformでコード管理する手順、スタンダードホスト2,180円・マイクロホスト660円という課金単位からの月額試算、そしてDatadogへ寄せるべき場面の線引きまでを、公式ドキュメントの記述を出典として示しながら整理しました。

まとめ：Mackerelを導入する条件と月額の目安、agent設定の要点

Mackerelの課金は「ホスト単位」です。mackerel-agent を入れたサーバーやVMがスタンダードホストとして月2,180円（税込）、コンテナのPodやタスクがマイクロホストとして月660円（税込）で数えられます。監視項目を増やしても、ホストメトリックが200個（マイクロホストは30個）までなら追加料金は発生しません。台数がそのまま請求額になる構造なので、見積もりは「何を監視するか」ではなく「いくつのホストとして数えられるか」から始めてください。

導入は速い。RHEL系なら setup-all-yum-v2.sh、Ubuntu/Debianなら setup-all-apt-v2.sh にAPIキーを渡すワンライナー1行で、パッケージ導入から自動起動まで終わります。そのあと手を入れるのは mackerel-agent.conf の roles と include の2行、そして conf.d 配下に置くチェック監視の設定ファイルです。監視ルール側はWeb画面のほかAPIとTerraform Providerからも登録できます。

採用の線引きは単価で決まります。数十台規模の国内向けシステムを日本語のサポートで運用するならMackerel、分散トレースを主役に据えたい場合やホスト数が数百を超える場合はDatadogやGrafana系へ寄せる。1台2,180円が分岐点です。

ホスト単位で課金される仕組みとエージェントが数値を送る経路の把握

何が「1ホスト」として数えられるのかを先に掴んでおくと、見積もりが崩れません。数値を集めるのはインストール型のエージェントです。

mackerel-agentが1分ごとに投稿するメトリックとホスト情報の更新間隔

mackerel-agent はGo製の常駐プロセスで、対象ホストからCPU・メモリ・ディスク・ネットワークなどの情報を集めてMackerelへ送ります。公式のmackerel-agent 仕様には、リソース情報の収集と投稿が1分ごと、ホスト情報の更新が1時間ごとと明記されています。この1分という粒度が、そのままグラフの解像度になる。

agentからMackerelへの通信はアウトバウンドのHTTPSで、SaaS側からサーバーへ接続しに来る経路はありません。受信用のポートを開ける作業は不要です。版はGitHubで公開されており、mackerel-agent のリリース一覧で確認できる最新版は v0.87.0（2026年6月26日公開）でした。

スタンダードホストとマイクロホストの区分と含まれるメトリック数の差

Mackerelの料金ページでは、課金対象のホストが2種類に分かれています。この区分を取り違えると見積もりが倍近くずれます。

スタンダードホストは mackerel-agent を入れた物理サーバーやVM、およびEC2のようなVM系インテグレーションのインスタンスです。マイクロホストは mackerel-container-agent を登録したPodやECSタスク、VM系以外のクラウドインテグレーション（ALBやRDSなど）が該当します。上限を超えたメトリックは1個あたり月11円（税込）で加算。プラグインを何本も足す運用では、200個の枠に収まっているかを一度数えておいてください。

コンテナ環境の登録手順はKubernetesへのcontainer-agentセットアップにまとまっています。Podのサイドカーとしてagentコンテナを足す形で、kubelet APIを参照するServiceAccountとClusterRoleの設定が別途要ります。

mackerel-agentをLinuxへ入れてホストを登録するまでの実行手順

ここからは実際に動かす手順です。Webコンソールでオーガニゼーションを作り、APIキータブからWrite権限のキーを取得したところから始めます。

セットアップスクリプトでAPIキーを渡して登録するワンライナーの実行

ディストリビューションごとに公式のセットアップスクリプトが用意されています。CentOS / RHEL派生OSへのインストールとUbuntu / Debianへのインストールに記載されているコマンドは次のとおりです。APIキーは環境変数として渡します。

# RHEL系（CentOS / Amazon Linux など）
curl -fsSL https://mackerel.io/file/script/setup-all-yum-v2.sh | MACKEREL_APIKEY='YOUR_API_KEY' sh

# Ubuntu / Debian
wget -q -O - https://mackerel.io/file/script/setup-all-apt-v2.sh | MACKEREL_APIKEY='YOUR_API_KEY' sh

このスクリプトはリポジトリ登録・パッケージ導入・設定ファイルへのAPIキー書き込み・自動起動の有効化までを一度に行います。実行が終わると数十秒でWeb画面のHostsにホストが現れる。パッケージ管理を自前で握っている環境では、GitHubのReleasesからdebやrpmを取得して dpkg や yum で入れる手順も選べます。

設定ファイルへ書くapikeyとrolesとincludeの指定方法

設定ファイルは /etc/mackerel-agent/mackerel-agent.conf でTOML形式です。マルチバイト文字を書く場合はUTF-8で保存してください。最初に触るべきは roles と include の2つ。roles を書いておくと、ホストが「サービス:ロール」の単位でまとまり、監視ルールをロール単位で当てられるようになります。

apikey = "YOUR_API_KEY"
root = "/var/lib/mackerel-agent"
pidfile = "/var/run/mackerel-agent.pid"
display_name = "web-01"
roles = [ "Production:app", "Production:web" ]
include = "/etc/mackerel-agent/conf.d/*.conf"

[plugin.metrics.vmstat]
command = ["ruby", "/etc/sensu/plugins/system/vmstat-metrics.rb"]

include を指定すると conf.d 配下のファイルが読み込まれます。nginxの監視は conf.d/nginx.conf、MySQLの監視は conf.d/mysql.conf と監視対象ごとに分けておけば、構成管理ツールからの配布とロールバックが1ファイル単位で済む。本体の conf を全台で共通化し、差分を conf.d に寄せる形が扱いやすい構成です。

systemctlでの起動確認とホストが登録されないときの切り分け手順

設定を変えたあとの反映は再起動です。sudo systemctl restart mackerel-agent を実行し、ログは sudo journalctl -u mackerel-agent.service で確認します。

ホストがWeb画面に出てこないときに見る箇所は3つ。第1にAPIキーの権限で、Read専用のキーではホストを登録できません。第2に外向きHTTPSの到達性で、プロキシ経由なら設定ファイルにプロキシの指定が要ります。第3がホストIDの重複です。agentは登録時に発行されたIDを root 配下に保存するため、そのディレクトリごとコピーしたAMIからVMを量産すると、複数台が同一ホストとして上書きし合います。イメージ化の前にホストIDのファイルを消しておいてください。

プラグインとチェック監視でミドルウェアとプロセスを見る設定の書き方

ホストメトリックだけでは、アプリが200を返しているかまでは分かりません。そこを埋めるのがチェック監視で、任意のコマンドを定期実行し終了ステータスで判定します。

公式チェックプラグイン集の導入とcheck-httpによる死活確認の設定

チェック監視のコマンドは自作もできますが、まずは公式のプラグイン集を入れるのが早道です。mackerel-check-plugins パッケージを導入すると、チェックプラグイン一覧にあるコマンド群が使えます。HTTPの応答を見る check-http、プロセスの生存を見る check-procs、ログの文字列を拾う check-log、証明書の期限を見る check-ssl-cert といった顔ぶれ。設定は conf.d 配下に置きます。チェック監視項目を追加するの記述に沿った例が次の形です。

# /etc/mackerel-agent/conf.d/check-http.conf
[plugin.checks.http_healthcheck]
command = ["check-http", "-u", "https://example.com/healthz", "-s", "200"]
check_interval = 5
timeout_seconds = 45
max_check_attempts = 3
notification_interval = 60
memo = "アプリケーションの死活確認"

agent内から叩くため、この経路はサーバー内部から見た死活確認になります。ユーザーと同じ経路で外側から到達性を見たい場合は、Mackerel側の外形監視機能を併用してください。内部監視と外形監視の役割分担については外形監視とは？内部監視との違いと監視項目・実装、導入判断で整理しています。

max_check_attemptsとcheck_intervalで誤報を抑える指定

チェック監視をそのまま入れると、瞬間的なタイムアウトでアラートが飛びます。抑えるつまみは2つ。check_interval が実行間隔（分。既定は1分、指定できる範囲は1〜60分）、max_check_attempts が「連続で何回失敗したらアラートにするか」の猶予回数です。

上の例のように check_interval を5、max_check_attempts を3にすると、失敗が15分続いたときに初めて通知されます。深夜に起こされる基準としては妥当な線。決済系など1分の停止も見逃せない対象では、この2つを詰めて即時に上げます。ほかに実行ユーザーを指定する user、環境変数を渡す env、復旧時にアラートを自動クローズさせない prevent_alert_auto_close があります。

監視ルールをAPIで登録して環境間で同じ設定を配る運用の組み立て方

閾値はagent側ではなくMackerel側の「監視ルール」で持ちます。Web画面でも作れますが、開発・本番で同じ設定を配るならコード化してください。

監視ルール登録APIへ送るJSONの必須フィールドと閾値の指定例

監視ルールAPIのエンドポイントは POST /api/v0/monitors、ベースURLは https://api.mackerelio.com/ です。認証は X-Api-Key ヘッダで、Read と Write の両方の権限が要ります。ホストメトリック監視（type=host）の必須フィールドは type・name・duration・metric・operator の5つで、duration は平均を取る分数（1〜10分）を指定します。

curl -X POST https://api.mackerelio.com/api/v0/monitors \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "host",
    "name": "loadavg5 on app servers",
    "duration": 3,
    "metric": "loadavg5",
    "operator": ">",
    "warning": 4.0,
    "critical": 8.0,
    "maxCheckAttempts": 3,
    "notificationInterval": 60,
    "scopes": ["Production: app"]
  }'

scopes にサービス名やロール名を書くと、そのロールに属するホスト全台へ同じ閾値が当たります。台数が増えても監視ルールは増えません。ホスト1台ずつに閾値を貼る運用をやめてロール単位に寄せれば、サーバー追加時の設定作業が消えます。

Terraform Providerで監視ルールをコードとして管理する運用の型

APIを直接叩く方式は、既存ルールとの差分管理が手作業になります。IaCを使っているならTerraform Provider（mackerelio-labs/mackerel）を挟んでください。2026年4月9日公開の 0.9.1 が最新で、Terraform v1.0以上に対応します。認証は環境変数 MACKEREL_APIKEY で渡せます。

terraform {
  required_providers {
    mackerel = {
      source  = "mackerelio-labs/mackerel"
      version = "0.9.1"
    }
  }
}

resource "mackerel_monitor" "cpu_high" {
  name                  = "cpu % is high"
  is_mute               = false
  notification_interval = 10

  host_metric {
    metric   = "cpu%"
    operator = ">"
    warning  = 80
    critical = 90
    duration = 3

    scopes = ["app", "proxy:ec2"]
  }
}

監視ルールのほか、通知チャンネル、サービス、ロール、AWSインテグレーション、ダッシュボードもリソースとして扱えます。閾値の変更をプルリクエストのレビューに載せられる点が、Web画面で直接編集する運用との差です。

アラート通知をSlackやPagerDutyへ渡すときのチャンネル設定の要点

通知先は「通知チャンネル」として登録し、通知グループでサービスやロールと結び付けます。Slackへ流すならIncoming Webhookを1本作り、どの重大度を流すかをチャンネル側で絞り込む。全部を1つのSlackチャンネルへ投げると、数か月で誰も見なくなります。

オンコールの当番表と電話呼び出しまで要るなら、PagerDutyやOpsgenie系を後段に置く構成になります。こちらは1ユーザー単位の課金で、監視ツール本体より高くつくことがある。実額の内訳はPagerDuty料金の実額と落とし穴｜Opsgenie終了後の移行コストにまとめてあります。

コンテナとログ機能を含めた月額の実額と課金が膨らむ場面の見積もり

Mackerelの請求が読みにくくなるのは、ホスト課金に後から別単位の課金が乗るときです。2026年時点で乗ってくるのはAPMのスパン課金と、ログ機能のインジェスト課金の2つ。

スタンダード2180円とマイクロ660円で構成別の月額を試算する手順

試算はホストを数えるだけで済みます。Webサーバー3台・APサーバー4台・DBサーバー2台の構成なら、agent導入ホストが9台でスタンダード9本、月19,620円（税込）。ここへALBとRDSの連携を足すと、VM系以外なのでマイクロホスト扱いで660円ずつ加算されます。

EKS上でPodを30個動かす構成では、mackerel-container-agent を入れたPodが1つあたりマイクロホスト1本で、30本なら19,800円（税込）。ノード側にもagentを入れるならスタンダードが別に乗ります。Podの数が増減する構成では請求も動く点に注意してください。なおスタンダードプランは課金対象機能を使った時点で最低利用料金2,180円（税込）が発生し、使用量が下回っても同額が請求されます。

ログ機能のインジェスト課金とAPMのスパン課金が膨らむ条件の把握

ここが従来のホスト課金と性格が違う部分です。はてなのログ機能の正式リリース告知（2026年8月21日公開）によれば、ログ機能は2026年11月1日に正式リリースされ、課金は取り込み量に応じたインジェスト課金で70円/GB（税抜）となります。保存期間は30日間、フリープランの無料枠は月間1GBまで、スタンダードプランには無料枠がありません。

1日10GBのログを送る構成なら月300GBで21,000円（税抜）、ホスト10台分のスタンダード料金を上回ります。DEBUGレベルを本番のまま流していないか、アクセスログを丸ごと投げていないかを、送信前にフィルタで削っておいてください。APM側は330円/1Mスパン（税込）で、フリープランは5Mスパンまで無料。トレースを全リクエストに入れるとスパン数は容易に跳ねるため、サンプリング率を決めてから有効化します。OpenTelemetry計装の手順はMackerel APMとは何か？可観測性プラットフォームに追加されたAPM機能の概要で個別に扱っています。

Mackerelを採用してよい条件とDatadogへ寄せるべき場面の切り分け

判断の章です。ツール比較の総論ではなく、Mackerelを選ぶ側・外す側の境界だけを条件で書きます。

日本語サポートと課金の読みやすさが効く体制と規模の具体的な条件

採用してよいのは次の3条件が重なるときです。第1に監視対象が数台から数十台で、台数が読める構成であること。1台2,180円という単価は50台で月109,000円（税込）と計算でき、稟議に載せやすい数字になります。第2に監視の担当が専任ではなく、アプリ開発者が兼務していること。ユーザー数無制限の課金体系なので、席数を気にせず開発者全員にアカウントを配れる。第3に日本語での問い合わせ経路が要ること。

台数の読みやすさが崩れる構成——オートスケールでインスタンスが日中3倍になる使い方——では、ホスト課金の見積もりが立ちません。その場合はマイクロホストで数えられるコンテナ構成へ寄せてください。

Mackerelを見送ってDatadogやGrafanaへ寄せるべき2つの場面

見送るべき場面は2つ。1つ目は分散トレースを監視の主役に据える場合で、マイクロサービス間の依存とレイテンシを常時追うなら、APMを後付けした構成よりトレースを中核に設計されたDatadogやGrafana Tempo系が機能の厚みで勝ります。2つ目はホスト数が数百を超える場合。1台2,180円は台数に素直に効くため、300台で月654,000円（税込）となり、セルフホストのPrometheus＋Grafanaを運用する人件費と逆転します。

逆転点は「監視基盤を見る担当者を0.5人分置けるかどうか」です。置けないなら台数が多くてもSaaSのままが安く付く。置けるなら自前運用へ移す判断が成立します。選定軸ごとの各ツールの立ち位置はオブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方に整理してあります。

監視だけ入れて運用が回らない失敗と当番体制まで含めた設計の順序

よくある失敗は、agentを全台に入れてグラフを並べた時点で導入完了としてしまうことです。アラートは飛ぶが誰も一次対応しない、Slackチャンネルに赤い通知が溜まるだけ、という状態に落ちる。監視の価値は検知そのものではなく復旧までの時間に出ます。指標の取り方はMTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策で扱っています。

順序としては、監視ルールを作る前に「誰が一次対応するか」「何分応答がなければエスカレーションするか」を決めてください。そのうえで、その体制で対応できる粒度までアラートを絞る。当番を置けない体制なら、検知だけ入れても意味がありません。自社に監視の当番を置く余力がない場合は、運用そのものを外部へ預ける選択肢もあります。一創では保守運用・内製化支援として、監視設計から障害時の一次対応、内製化までの引き継ぎを含めて請け負っています。

よくある質問

導入検討でよく挙がる質問を、公式ドキュメントの記述に沿って整理しました。

Mackerelは無料で使い続けられますか？

フリープランがあり、無料のまま継続できます。ただし機能と保存期間に制限があり、スタンダードプラン相当の機能をひととおり試したい場合は2週間のトライアルを使う形になります。トライアル期間中はAPMのスパンが100Mまで、ログは1TBまで無料です。有料へ移ると、課金対象の機能を1つでも使った月は最低利用料金2,180円（税込）が発生します。1台だけの検証でもこの下限は変わりません。

mackerel-agentは1台あたりどれくらいのリソースを使いますか？

Go製の常駐プロセス1つで、収集と投稿を1分間隔で行う設計です。監視対象の負荷を測る立場のプロセスなので、標準のホストメトリック収集だけであれば軽量に収まります。負荷が増えるとすれば、追加したメトリックプラグインやチェックプラグインの側です。重いシェルスクリプトを短い check_interval で回すと、その分だけCPUを使います。プラグインを増やすときは timeout_seconds を必ず指定して、ハングしたコマンドがagentごと詰まらないようにしてください。

MackerelとDatadogはどちらを選ぶべきですか？

監視対象が数十台までの国内向けシステムで、日本語サポートと台数ベースの分かりやすい課金を求めるならMackerelです。分散トレースを中心に据えたい場合や、監視対象が数百台規模でホスト単価が効いてくる場合はDatadogに分があります。判断の分岐点は1ホスト2,180円（税込）という単価と、監視基盤を専任で見る担当者を置けるかどうかの2点。

Windowsサーバーも監視できますか？

できます。Windows Server向けのインストーラが公式に用意されており、mackerel-agent をサービスとして常駐させる形になる。設定ファイルの書式はLinux版と同じ考え方で、TOML形式でapikeyとrolesを指定します。ただしLinux向けのシェルスクリプト前提のプラグインはそのままでは動かない場合があるため、チェックプラグイン一覧でWindows対応の記載を確認してから組み込んでください。

監視ルールをまとめて別のオーガニゼーションへ移せますか？

APIとTerraform Providerを使えば移せます。監視ルールの一覧取得は GET /api/v0/monitors、登録は POST /api/v0/monitors なので、取得したJSONをそのまま移行先へ投げる手順が組めるでしょう。Terraformで設定を持っていれば、providerの向き先を変えて apply するだけで済みます。オーガニゼーション間の移行予定があるなら、最初からコード側に設定を寄せておいてください。

関連記事

• Mackerel APMとは何か？可観測性プラットフォームに追加されたAPM機能の概要を紹介：APM機能とOpenTelemetry計装の詳細
• 外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説：ユーザー側の経路から到達性を見る手段
• インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装：アラートを受けたあとの対応プロセス
• 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説：監視で守る対象となる稼働率の考え方
• オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方：他ツール込みの選定軸