Mackerelとは｜できること・料金・使い方とプラグインの作り方を実例で解説

監視したいサーバーに mackerel-agent（エージェント）を入れると、CPU やメモリなどの値が1分ごとに Mackerel の API へ送られ、グラフと監視ルール（しきい値）と通知に使われます。アプリのトレースやラベル付きメトリックは OpenTelemetry で送ります。

flowchart TD
    P[プラグイン] --> A[mackerel-agent]
    A -->|1分ごとに送信| M[Mackerel API]
    O[アプリ OpenTelemetry] -->|トレース等| M
    M --> G[グラフ・ダッシュボード]
    M --> N[アラート・通知]

急いでいる人向けに、よく調べられることの答えを先にまとめます。

知りたいこと	答え	詳しい節
Mackerelとは	はてなのサーバー監視・オブザーバビリティの SaaS	Mackerelとは
読み方	マカレル（英語で「サバ」）	Mackerelとは
無料で使えるか	フリープランあり（ホスト5台・メトリック500まで）	料金
料金	スタンダードホスト1台 2,180円/月（税込）	料金
始め方	サインアップ→エージェントを入れる→ロール→監視	導入の流れ
設定ファイル	/etc/mackerel-agent/mackerel-agent.conf（TOML）	設定ファイル
独自の値を送る	プラグインが 名前<TAB>値<TAB>時刻 を出す	プラグインの作り方
API で送る	POST /api/v0/tsdb にヘッダー X-Api-Key	API
APM・トレース	OpenTelemetry で送る	APM・ラベル付きメトリック

確認環境：Ubuntu 24.04.4 LTS・Python 3.11.15・GNU bash 5.2.21・curl 8.5.0・OpenTelemetry Python SDK 1.45.1（opentelemetry-exporter-otlp-proto-http・-grpc 1.45.1、grpcio 1.84.1）。外へ出られないネットワーク名前空間（ip netns）の中に、Mackerel API の形で応答する自作の擬似の受け口（HTTP と OTLP の gRPC）を立て、届いたリクエストをすべて記録しました。自作のメトリックプラグインとチェックプラグインを bash で書いて実行し、その出力を公式 API ドキュメントの形で送る小さなエージェント（Python、説明用の自作）と curl・OpenTelemetry SDK から送りました。本物の Mackerel には送っていません。mackerel-agent 本体の設定・メトリック名・コマンド、料金、各機能の仕様は mackerel.io のヘルプ・API ドキュメント・料金ページと GitHub のリリース一覧で、他の製品は各公式サイトで確かめました（確認日 2026年10月23日）。

Mackerelとは（読み方・どこの会社か）

この節では、Mackerel が何をするサービスで、どこの会社が出しているかが分かります。

Mackerel（マカレル）は、株式会社はてなが提供する日本製のサーバー監視サービスです。 サーバーに入れたエージェントが CPU・メモリ・ディスクなどの値（メトリック）を送り、Mackerel の画面でグラフにして、しきい値を超えたらメールや Slack に知らせます。今は APM（アプリの性能監視）やログの機能も加わり、公式サイトは「オブザーバビリティ」のサービスとして紹介しています。

項目	内容
読み方	マカレル（公式サイトの表記「Mackerel（マカレル）」）
英単語の意味	サバ（鯖）。魚の mackerel と同じつづり
提供	株式会社はてな（Hatena Co., Ltd.）
形態	SaaS。監視サーバーを自分で立てる必要がない
画面	https://mackerel.io/。日本語の画面・ヘルプ・メールサポート
料金の通貨	日本円（税込表記）
試す方法	全機能の2週間の無料トライアル、ログイン不要のライブデモ（play.mackerel.io）
エージェント	mackerel-agent（オープンソース、Apache License 2.0）

「監視サーバーが要らない」とはどういうことか

Mackerelでできること（機能の早見表）

この節では、Mackerel の主な機能と、それぞれで何が見られるかが分かります。

ヘルプの目次と料金ページにある機能から、よく使うものをまとめました（名前は2026年10月23日時点のヘルプの表記）。

機能	何をするか	データの入り口
ホストの監視	CPU・メモリ・ディスク・ネットワークなどを1分ごとにグラフにする	mackerel-agent
サービスとロール	ホストを「システム」と「役割」でまとめて、グラフ・監視・通知を一括で扱う	画面・設定ファイル
カスタムメトリック	自分で決めた値（キューの長さ・売上など）をグラフにする	プラグイン・API
チェック監視	サーバーの中で判定した OK・WARNING・CRITICAL を受けて通知する	チェックプラグイン
ログ監視	ログに特定の文字列が出たら通知する	check-log プラグイン
URL外形監視	外から URL に1分ごとにアクセスし、応答・本文・証明書の期限を見る	Mackerel から
式による監視・クエリによる監視	複数のメトリックを計算した値や、クエリの結果を監視する	画面で式・クエリを書く
ロール内異常検知	機械学習で、ロールの中のいつもと違う動きを見つける	画面で対象ロールを選ぶ
クラウドインテグレーション	AWS（28製品）・Azure・Google Cloud のメトリックを取り込む	クラウドの API
コンテナの監視	ECS のタスクや Kubernetes の Pod を監視する	mackerel-container-agent
APM（トレース）	アプリの処理の流れ・遅い処理・エラーを見る	OpenTelemetry
ラベル付きメトリック	ラベル（属性）付きのメトリックを送り、クエリで集計する	OpenTelemetry
ログ機能（β）	ログを集めて検索し、トレースと行き来する（2026年7月15日にヘルプ公開）	OpenTelemetry 準拠の形式
通知	メール・Slack・Microsoft Teams・Webhook など10種類	通知チャンネル
ダッシュボード	グラフを並べた画面を作る	画面・mkr

Mackerelの仕組み（mackerel-agent→API→グラフ・通知）

この節では、データがどの順番で Mackerel に届き、どこで判定されるかが分かります。

ヘルプの「概要」と「mackerel-agent 仕様」に書かれている流れです。

用語の早見表（オーガニゼーション・サービス・ロール・ホスト）

用語	意味	例
オーガニゼーション	最初に作る契約・管理の単位。ユーザーを招待して共同で使う	会社やチームごとに1つ
ホスト	mackerel-agent を入れたサーバー、またはクラウド連携で登録したもの	web-01・RDS のインスタンス
サービス	1台以上のホストをまとめる単位（システム・環境など）	shop・shop-staging
ロール	サービスの中の役割。サービスごとに作る	shop:web・shop:db・shop:batch
ホストメトリック	ホストに付く値。ホストの画面に出る	loadavg5・custom.jobqueue.count.waiting
サービスメトリック	ホストではなくサービスに付く値	売上・外形監視の応答時間
監視ルール	しきい値や判定の決まり	loadavg5 > 4 で WARNING
アラート	ルールに引っかかった状態。直ると自動で閉じる	CRITICAL → OK
通知チャンネル	通知の送り先	Slack のチャンネル

ヘルプでは、1台のホストは複数のサービス・複数のロールに入れられ、サービスに入ったホストは必ずどれかのロールに入ると説明しています。サービス名は後から変えられないので、名前の付け方（システム名か、環境名か）を先に決めておきます。

flowchart TD
    O[オーガニゼーション] --> S1[サービス shop]
    S1 --> R1[ロール web]
    S1 --> R2[ロール db]
    R1 --> H1[ホスト web-01 web-02]
    R2 --> H2[ホスト db-01]

エージェントが集めるメトリック（Linux）

ヘルプ「メトリックの仕様」にある、Linux のエージェントが集める値です。どれも /proc などの OS の情報から読んでいます。

グラフ	メトリック名	読む元
loadavg	loadavg1・loadavg5・loadavg15	/proc/loadavg
cpu	cpu.user.percentage・cpu.iowait.percentage・cpu.system.percentage など9種	/proc/stat
memory	memory.used・memory.available・memory.total・memory.swap_used など（カーネル 3.14 以降）	/proc/meminfo
disk	disk.*.reads.delta・disk.*.writes.delta	/proc/diskstats
interface	interface.*.rxBytes.delta・interface.*.txBytes.delta	/proc/net/dev
filesystem	filesystem.*.size・filesystem.*.used	df（/dev/ で始まるもの）

* にはデバイス名（sda・eth0 など）が入ります。名前の最後のドットまでが同じメトリックは、1つのグラフにまとまります。

Mackerelの料金と無料（フリープラン）

この節では、Mackerel の料金がどの単位で決まり、無料でどこまで使えるかが分かります。

Mackerel の料金は、主に「ホストの台数」と「メトリックの数」と「スパン（トレース）の数」で決まります。 料金ページの価格です（税込、1か月あたり。2026年10月23日時点）。

課金の単位	フリー	スタンダード
スタンダードホスト（mackerel-agent を入れたホスト・EC2 など）	無料（マイクロホストと合わせて5台まで）	2,180円/台
マイクロホスト（サイドカーのコンテナ・RDS などのクラウドの部品）	同上	660円/台
メトリック	500まで	11円/1メトリック
スパン（APM）	5M（500万）まで	5M まで無料、超えた分は 330円/1M
最低利用料金	―	課金対象を使った月は 2,180円から

料金ページの説明では、1メトリックは「毎分1か月間投稿した場合」に1と数えます。スタンダードホスト1台には200メトリック、マイクロホスト1台には30メトリックが含まれます。ホストの台数は1時間ほどの間隔で数えた1か月の平均で、オートスケールで増減しても平均で計算されます。

フリープランとスタンダードプランの違い

項目	フリー	スタンダード
ホスト	合わせて5台まで	台数に応じて課金
グラフの表示期間	1日	460日
監視ルール	10件	100件（依頼で増やせる）
カスタムダッシュボード	1つ	100（依頼で増やせる）
ユーザー	無制限	無制限
プラグイン・API	使える	使える
AWS・Azure・Google Cloud インテグレーション	ヘルプでは Trial と Standard のみ	使える
機械学習による異常検知	料金ページはスタンダードの課金だけを記載	対象ロールのホスト5台ごとに1スタンダードホスト分

URL外形監視は、料金ページのフリーの欄に「20件まで」とある一方、外形監視のヘルプには「Trialプランまたは有料プランでのみご利用いただけます」とあり、記載が分かれています（2026年10月23日時点）。フリーで使う予定なら、画面で設定できるかを確かめます。スタンダードでは20件までが最低利用料金に含まれ、20件を超えるごとに1スタンダードホスト分がかかります。

月額の試算

スタンダードホスト5台（Web・DB）、マイクロホスト4台（AWS インテグレーションの RDS・ALB など）、サービスメトリック20個、スパン月12M の構成を、料金ページの単価で計算しました。ホストメトリックは各ホストの含まれる数（200・30）に収まる想定です。

この構成では、費用の大部分はスタンダードホストの台数です。 RDS などエージェントを入れない部品はマイクロホスト（660円）として数えられます。

トライアル・上位プラン・支払い

項目	内容（2026年10月23日時点）
トライアル	新しく作ったオーガニゼーションで2週間、スタンダード相当を無料。終わると自動でフリーへ移る
トライアル中のスパン	料金ページの「よくあるご質問」では100M（1億）スパンまで
ビジネスプラン	月55,000円（税込）、最低6か月。SAML 連携・上位サポートなど
プレミアムプラン	月110,000円（税込）、最低1年。ビジネスの内容に加えて TAM・Slack でのサポート
支払い	クレジットカード（Visa・Mastercard・JCB・American Express・Diners Club・Discover）で月ごと
サポート	メール。営業日10:00〜19:00 の対応は料金に含まれる

ビジネス・プレミアムはスタンダードに足して契約する上位オプションで、ホスト数に関係なく定額です。

Mackerelの始め方（導入の流れ）

この節では、サインアップしてから通知が届くまでの順番が分かります。

mackerel-agent のインストール（OS別）

ヘルプにある方法です（2026年10月23日時点）。

OS	方法
Ubuntu・Debian	新規ホストの登録画面のコマンド（apt のリポジトリの設定とインストール）
Amazon Linux・RHEL 系	新規ホストの登録画面のコマンド（yum のリポジトリ）
Windows Server	MSI のインストーラー
バイナリ（tar.gz）	GitHub リリースのファイルを展開して起動
macOS	公式のサポート対象外（ヘルプの記載）
コンテナ（ECS・Kubernetes）	mackerel-container-agent をサイドカーで動かす

Ubuntu・Debian で、ヘルプに書かれているコマンドです。<YOUR_API_KEY> は画面の API キーに置き換えます。

# インストール（新規ホストの登録画面に出るコマンド）
wget -q -O - https://mackerel.io/file/script/setup-all-apt-v2.sh | MACKEREL_APIKEY='<YOUR_API_KEY>' sh

# 設定を変えたら再起動、ログを見る
sudo systemctl restart mackerel-agent
sudo journalctl -u mackerel-agent.service

# 更新
sudo apt-get update
sudo apt-get install mackerel-agent

# アンインストール（設定ファイルと id を残す／消す）
sudo apt-get remove mackerel-agent
sudo apt-get purge mackerel-agent

GitHub のリリース一覧では、最新の mackerel-agent は v0.87.0（2026年6月26日）でした。この版では、プラグインが出した時刻を使う変更（#1223）が入っています。

エージェントのコマンド

コマンド	何をするか
mackerel-agent init -apikey <APIキー>	設定ファイルに API キーを書く（README）
mackerel-agent configtest	設定ファイルの書き方を確かめる
mackerel-agent once	メトリックを1回集めて画面に出す。送らない
mackerel-agent retire	このホストを退役させる（-force で確認を省く）
mackerel-agent -conf=<パス>	設定ファイルの場所を指定して起動

プラグインを足したら、configtest で設定を、once で集まる値を確かめてから再起動すると、書き間違いに早く気付けます。

mackerel-agent.confの書き方（設定ファイル）

この節では、設定ファイルの場所と、よく使う項目の意味が分かります。

設定ファイルは Linux では /etc/mackerel-agent/mackerel-agent.conf で、TOML という形式で書きます。 必須は apikey だけです。起動時に読むので、変えたら再起動します。日本語を書くときは UTF-8 で保存します。

apikey = "<YOUR_API_KEY>"
display_name = "batch-01"          # 画面に出る名前
roles = ["shop:batch"]             # サービス:ロール

[host_status]
on_start = "working"               # 起動時の状態
on_stop  = "poweroff"              # 停止時の状態

[filesystems]
ignore = "/dev/ram.*"              # 正規表現で除外

[plugin.metrics.jobqueue]          # メトリックプラグイン
command = ["/usr/local/bin/mackerel-plugin-queue.sh"]

[plugin.checks.nightly-batch]      # チェックプラグイン
command = ["/usr/local/bin/check-heartbeat.sh", "/var/spool/jobqueue/heartbeat", "600", "1800"]
max_check_attempts = 2
notification_interval = 60
memo = "夜間バッチのハートビートが30分以上更新されていない"

項目	意味
apikey	Mackerel と通信する API キー（必須）
display_name	画面の表示名。設定から消しても名前は残る
roles	サービス:ロール の配列。画面で変えた内容は設定ファイルに戻らない
host_status	起動時・停止時の状態（working・standby・maintenance・poweroff）
http_proxy・https_proxy	プロキシ。HTTPS だけプロキシを使わないときは https_proxy = "direct"
cloud_platform	auto（既定）・ec2・gce・azurevm・none。Docker などで1台に複数のホストを作るときは none
filesystems・disks・interfaces	集める対象から外すものを正規表現で指定
include	別の設定ファイルを glob で読み込む
verbose・silent	DEBUG のログを出す／WARN より下を出さない
diagnostic	エージェント自身のメモリなどもメトリックとして送る
pidfile・root	PID ファイルの場所、ホスト ID を置く場所

apibase（API の送り先）は、この記事の実験で擬似の受け口に向けるために使った項目です。ふだんは書かず、既定の https://api.mackerelio.com/ に送ります。

Mackerelのプラグインの作り方（メトリック・チェックの実物）

この節では、公式のプラグインの入れ方と、自分の値を送るプラグインの書き方が、実際に動かした出力で分かります。

公式のプラグイン集を入れる

パッケージ	中身	入れ方（apt の場合）
mackerel-agent-plugins	メトリックプラグイン（mackerel-plugin-mysql・-nginx・-redis など）	sudo apt-get install mackerel-agent-plugins
mackerel-check-plugins	チェックプラグイン（check-log・check-procs など）	sudo apt-get install mackerel-check-plugins
mkr でレジストリ・GitHub から	上の集まりに無いプラグイン	sudo mkr plugin install <名前>

公式のプラグイン一覧のページには、mackerel-plugin- で始まるメトリックプラグインが55個載っていました（AWS 12個、Web サーバー・PHP など14個、DB・キャッシュ・キュー12個など）。パッケージで入れたものは /usr/bin に、mkr plugin install で入れたものは既定で /opt/mackerel-agent/plugins/bin に置かれます。設定は1行です。

[plugin.metrics.nginx]
command = ["mackerel-plugin-nginx"]

[plugin.checks.check_cron]
command = ["check-procs", "-p", "crond"]

メトリックプラグインの形（名前・値・時刻をタブで区切る）

メトリックプラグインは、標準出力に {metric name}\t{metric value}\t{epoch seconds} を1行ずつ出すだけのプログラムです。 言語は問いません。名前には英数字・-・_・. が使え、エージェントが先頭に custom. を付けます。

ジョブの待ち行列の長さを出すプラグインを bash で書きました。

#!/bin/bash
# 自作のメトリックプラグイン：ジョブの待ち行列の長さと、処理中・失敗の件数を出す
SPOOL=${QUEUE_DIR:-/var/spool/jobqueue}

if [ "$MACKEREL_AGENT_PLUGIN_META" = "1" ]; then
  echo "# mackerel-agent-plugin"
  cat <<'EOF'
{"graphs":{"jobqueue.count":{"label":"Job queue","unit":"integer","metrics":[{"name":"waiting","label":"待ち","stacked":true},{"name":"running","label":"処理中","stacked":true},{"name":"failed","label":"失敗","stacked":false}]}}}
EOF
  exit 0
fi

now=$(date +%s)
printf "jobqueue.count.waiting\t%d\t%d\n" "$(ls "$SPOOL/waiting" | wc -l)" "$now"
printf "jobqueue.count.running\t%d\t%d\n" "$(ls "$SPOOL/running" | wc -l)" "$now"
printf "jobqueue.count.failed\t%d\t%d\n"  "$(ls "$SPOOL/failed"  | wc -l)" "$now"

待ち7件・処理中2件・失敗1件のファイルを置いて実行した出力です。タブが見えるように cat -A を通し、タブを ^I で表示しています。

$ ./mackerel-plugin-queue.sh | cat -A
jobqueue.count.waiting^I7^I1792755585$
jobqueue.count.running^I2^I1792755585$
jobqueue.count.failed^I1^I1792755585$

グラフの定義（MACKEREL_AGENT_PLUGIN_META=1）

エージェントは起動時に、環境変数 MACKEREL_AGENT_PLUGIN_META=1 を付けてプラグインを実行します。1行目が # mackerel-agent-plugin なら、続く JSON をグラフの定義として読みます。

$ MACKEREL_AGENT_PLUGIN_META=1 ./mackerel-plugin-queue.sh
# mackerel-agent-plugin
{"graphs":{"jobqueue.count":{"label":"Job queue","unit":"integer","metrics":[{"name":"waiting","label":"待ち","stacked":true},{"name":"running","label":"処理中","stacked":true},{"name":"failed","label":"失敗","stacked":false}]}}}

キー	意味
graphs のキー	グラフ名（custom. を除いた、最後のドットより前の部分）。#・* のワイルドカードも使える
label	グラフの表示名
unit	float・integer・percentage・seconds・milliseconds・bytes・bytes/sec・bits/sec・iops
metrics[].name	系列の名前（ドットは使えない）
metrics[].stacked	true で積み上げ、false で線

設定ファイルの項目（plugin.metrics）

項目	意味	既定値
command	実行するコマンド。配列で書くとシェルを通さない	必須
timeout_seconds	タイムアウト（秒）	30
include_pattern・exclude_pattern	正規表現で送るメトリックを絞る	なし
user	実行するユーザー（Windows は不可）	エージェントのユーザー
env	コマンドに渡す環境変数	なし
custom_identifier	別のホスト（クラウド連携のホストなど）に送る	なし
use_plugin_timestamp	プラグインが出した時刻を使う（前後15分以内のみ）	false

セクション名は plugin.metrics.<名前> で、ドットはちょうど2つです。現在から24時間より前、または未来の時刻の値は投稿されません。

チェックプラグインの形（終了ステータスで判定）

チェックプラグインは、終了ステータスで状態を返し、標準出力がメッセージになります。 0 が OK、1 が WARNING、2 が CRITICAL、それ以外は UNKNOWN です。メッセージは1024文字までです。

バッチが最後に書いたハートビートのファイルが古くなっていないかを見るプラグインを書きました。

#!/bin/bash
# 自作のチェックプラグイン：ハートビートのファイルが古くなっていないかを見る
FILE=${1:?usage: check-heartbeat.sh FILE WARN_SEC CRIT_SEC}
WARN=${2:-600}; CRIT=${3:-1800}

if [ ! -e "$FILE" ]; then
  echo "UNKNOWN: $FILE がありません"; exit 3
fi
age=$(( $(date +%s) - $(stat -c %Y "$FILE") ))
if [ "$age" -ge "$CRIT" ]; then
  echo "CRITICAL: 最後の実行から ${age} 秒（しきい値 ${CRIT} 秒）"; exit 2
elif [ "$age" -ge "$WARN" ]; then
  echo "WARNING: 最後の実行から ${age} 秒（しきい値 ${WARN} 秒）"; exit 1
fi
echo "OK: 最後の実行から ${age} 秒"; exit 0

ファイルの更新時刻を touch -d で変えながら実行した結果です。

$ touch heartbeat;                  ./check-heartbeat.sh heartbeat 600 1800; echo "exit=$?"
OK: 最後の実行から 0 秒
exit=0
$ touch -d '-15 minutes' heartbeat; ./check-heartbeat.sh heartbeat 600 1800; echo "exit=$?"
WARNING: 最後の実行から 900 秒（しきい値 600 秒）
exit=1
$ touch -d '-45 minutes' heartbeat; ./check-heartbeat.sh heartbeat 600 1800; echo "exit=$?"
CRITICAL: 最後の実行から 2700 秒（しきい値 1800 秒）
exit=2
$ ./check-heartbeat.sh nofile 600 1800; echo "exit=$?"
UNKNOWN: nofile がありません
exit=3

項目（plugin.checks）	意味	既定値
check_interval	実行間隔（1〜60分。v0.67.0 以降は 10m の形も可）	1分
max_check_attempts	OK 以外が何回続いたらアラートにするか	1
notification_interval	アラートの再通知の間隔（分。10分未満は10分）	再通知しない
timeout_seconds	タイムアウト。check_interval より短くする	30秒
prevent_alert_auto_close	OK に戻ってもアラートを閉じない	false
memo	通知に出すメモ（250文字まで）	なし
action	毎回の実行の直後に動かすコマンド。MACKEREL_STATUS などを参照できる	なし

監視ルールの名前（plugin.checks. の後ろ）にドットは使えません。チェック監視のルールは設定ファイルで作り、画面からは追加・変更できません。

プラグインの値がAPIに届くまで（擬似の受け口で受けた実物）

この節では、エージェントがプラグインの出力をどんな JSON にして API に送るのかが、実際に届いたリクエストで分かります。

上の2つのプラグインを、次の設定で動かしました。送る役は、mackerel-agent.conf と同じ書式の設定を読み、公式 API ドキュメントの形でリクエストを送る説明用の小さなエージェント（Python で自作）です。送り先は、外に出られない netns の中の擬似の受け口（ポート 38701）です。

apikey = "s387-write-key-0000000000000000000000000000"
apibase = "http://127.0.0.1:38701"     # 実験のため擬似の受け口に向ける
display_name = "batch-01"
roles = ["shop:batch"]

[plugin.metrics.jobqueue]
command = ["/usr/local/bin/mackerel-plugin-queue.sh"]

[plugin.checks.nightly-batch]
command = ["/usr/local/bin/check-heartbeat.sh", "/var/spool/jobqueue/heartbeat", "600", "1800"]
check_interval = 5
max_check_attempts = 2
notification_interval = 60
memo = "夜間バッチのハートビートが30分以上更新されていない"

2周（本物は1分ごと、実験では3秒ごと）動かした画面の出力です。応答は擬似の受け口が、API ドキュメントの成功時の形で返したものです。

$ python3 mini_agent.py mackerel-agent.conf 2
register host
  -> POST /api/v0/hosts 200 {"id": "s387host0002"}
graph-defs from plugin jobqueue
  -> POST /api/v0/graph-defs/create 200 {"success": true}
cycle 1: post 6 metrics
  -> POST /api/v0/tsdb 200 {"success": true}
cycle 1: report 1 checks
  -> POST /api/v0/monitoring/checks/report 200 {"success": true}
cycle 2: post 6 metrics
  -> POST /api/v0/tsdb 200 {"success": true}
cycle 2: report 1 checks
  -> POST /api/v0/monitoring/checks/report 200 {"success": true}

2回目の起動では、保存しておいた ID を読み、登録は送りませんでした（host id (from file): s387host0002）。本物のエージェントの /var/lib/mackerel-agent/id と同じ考え方です。

ホストの登録（POST /api/v0/hosts）

POST /api/v0/hosts
  X-Api-Key: s387-write-key-0000000000000000000000000000
  Content-Type: application/json

{
 "name": "vm",
 "displayName": "batch-01",
 "meta": {"agent-name": "s387-mini-agent", "kernel": {"release": "6.18.44-fc-v153", "machine": "x86_64"}},
 "roleFullnames": ["shop:batch"],
 "checks": [{"name": "nightly-batch", "memo": "夜間バッチのハートビートが30分以上更新されていない"}]
}

roleFullnames が設定の roles です。API ドキュメントでは、存在しないロールを指定すると作られ、応答は {"id": ...} の形でホスト ID が返ります。

グラフ定義（POST /api/v0/graph-defs/create）

プラグインのメタ情報の JSON は、API では次の形になります。グラフ名に custom. が付き、系列の名前は「グラフ名.系列名」になっています。

[
 {
  "name": "custom.jobqueue.count",
  "displayName": "Job queue",
  "unit": "integer",
  "metrics": [
   {"name": "custom.jobqueue.count.waiting", "displayName": "待ち", "isStacked": true},
   {"name": "custom.jobqueue.count.running", "displayName": "処理中", "isStacked": true},
   {"name": "custom.jobqueue.count.failed", "displayName": "失敗", "isStacked": false}
  ]
 }
]

メトリックの投稿（POST /api/v0/tsdb）

1回目の投稿の中身です。プラグインの1行が1つの {hostId, name, time, value} になりました。

[
 {"hostId": "s387host0002", "name": "loadavg1", "time": 1792755730, "value": 2.35},
 {"hostId": "s387host0002", "name": "loadavg5", "time": 1792755730, "value": 2.28},
 {"hostId": "s387host0002", "name": "loadavg15", "time": 1792755730, "value": 1.41},
 {"hostId": "s387host0002", "name": "custom.jobqueue.count.waiting", "time": 1792755730, "value": 7.0},
 {"hostId": "s387host0002", "name": "custom.jobqueue.count.running", "time": 1792755730, "value": 2.0},
 {"hostId": "s387host0002", "name": "custom.jobqueue.count.failed", "time": 1792755730, "value": 1.0}
]

チェック結果（POST /api/v0/monitoring/checks/report）

ハートビートを15分前にしておいたので、終了ステータス1が WARNING になって届きました。

{
 "reports": [
  {
   "source": {"type": "host", "hostId": "s387host0002"},
   "name": "nightly-batch",
   "status": "WARNING",
   "message": "WARNING: 最後の実行から 901 秒（しきい値 600 秒）",
   "occurredAt": 1792755730,
   "maxCheckAttempts": 2,
   "notificationInterval": 60
  }
 ]
}

maxCheckAttempts: 2 なので、Mackerel 側では WARNING が2回続いたときにアラートになります。ヘルプでは、アラートが起きたときと状態が変わったとき（OK に戻ったときを含む）に通知され、メッセージの中身が変わっただけでは通知されません。

Mackerel APIの使い方（curlでメトリックを送る）

この節では、エージェントを使わずに API で値を送る方法と、よく使うエンドポイントが分かります。

API の送り先は https://api.mackerelio.com/ で、ヘッダー X-Api-Key に API キーを付けます。API キーは画面の「API キー」タブで作り、Read と Write の権限を分けられます。

やりたいこと	メソッドとパス	要る権限
ホストのメトリックを送る	POST /api/v0/tsdb	Write
サービスのメトリックを送る	POST /api/v0/services/<サービス名>/tsdb	Write
チェックの結果を送る	POST /api/v0/monitoring/checks/report	Write
グラフの定義を作る	POST /api/v0/graph-defs/create	Write
ホストを登録・更新する	POST /api/v0/hosts・PUT /api/v0/hosts/<hostId>	Write
ホストの一覧を見る	GET /api/v0/hosts?service=…&role=…	Read
最新の値を見る	GET /api/v0/tsdb/latest?hostId=…&name=…	Read
ホストの値を期間で見る	GET /api/v0/hosts/<hostId>/metrics?name=…&from=…&to=…	Read
ホストを退役させる	POST /api/v0/hosts/<hostId>/retire	Write

売上のように、特定のサーバーに付かない値はサービスメトリックで送ります。擬似の受け口に送った結果です（本番は URL を https://api.mackerelio.com にします）。

now=$(date +%s)
curl -sS -w "  HTTP %{http_code}\n" -X POST http://127.0.0.1:38701/api/v0/services/shop/tsdb \
  -H "X-Api-Key: $MACKEREL_APIKEY" -H "Content-Type: application/json" \
  -d "[{\"name\":\"orders.count\",\"time\":$now,\"value\":128},{\"name\":\"orders.amount\",\"time\":$now,\"value\":356400}]"

{"success": true}  HTTP 200

Read 権限だけのキーで同じ投稿をすると、擬似の受け口は API ドキュメントのとおり 403 を返すようにしてあります。

HTTP 403

API ドキュメントの注意点をまとめます。

注意点	内容
24時間より前の時刻	記録されないが、応答は 200
同じ時刻の値を送り直す	上書きされる
最新でない時刻の値	アラートは最新の値で判定するので、しきい値を超えてもアラートにならない
送りすぎ（サービスメトリック）	429。1分ごとにまとめて送る
403	Write 権限が無いキー、または許可した IP アドレスの範囲の外から
チェック結果	1回100件まで。6時間以上前の結果と、同じ名前でより新しい結果が届いている場合の前の結果は無視

mkr（コマンドラインツール）

mkr は Mackerel の公式の CLI です。mackerel-agent が入っていればその設定の API キーを使い、無ければ環境変数 MACKEREL_APIKEY を読みます。ヘルプにある主なコマンドです。

コマンド	何をするか
mkr hosts --service shop --role web	ホストの一覧
mkr status <hostId>	ホストの詳細（-v でメトリック名も）
mkr throw --host <hostId>・--service <名前>	標準入力の 名前<TAB>値<TAB>時刻 を送る
mkr fetch --name loadavg5 <hostId>	最新の値
mkr monitors pull・diff・push	監視ルールをファイルで管理する
mkr alerts	発生中のアラート
mkr wrap -- <コマンド>	バッチが失敗したらチェック監視でアラートにする
mkr plugin install <名前>	プラグインを入れる

mkr throw は、メトリックプラグインと同じ形式を標準入力から読みます。上で作ったプラグインの出力をそのまま流し込める形です。

./mackerel-plugin-queue.sh | mkr throw --service shop

mkr wrap は、cron のバッチが0以外で終わったときに CRITICAL のアラートを出します（-w で WARNING、-a で次に成功したら自動で閉じる、-d で出力も送る）。

11 * * * * mkr wrap -n nightly-report -a -- /usr/local/bin/nightly-report.sh

MackerelのAPM・ラベル付きメトリック（OpenTelemetryの実物）

この節では、APM（トレース）とラベル付きメトリックの送り方と、実際に届くデータの形が分かります。

Mackerel の APM とラベル付きメトリックは、OpenTelemetry の形式（OTLP）で受けます。 送り先とヘッダーはヘルプのとおりです（2026年10月23日時点）。

データ	送り先	形式	ヘッダー
トレース（APM）	https://otlp-vaxila.mackerelio.com/v1/traces	HTTP/protobuf	Mackerel-Api-Key、Accept: */*
ラベル付きメトリック	otlp.mackerelio.com:4317	OTLP（ポート 4317）	Mackerel-Api-Key

API キーは Write 権限のものを使います。トレースの Accept: */* は、Mackerel が内部で AWS Lambda を使っているため常に付けるよう、ヘルプの OpenTelemetry Collector の設定例に書かれています。Python の自動計装では、ヘルプは opentelemetry-distro と opentelemetry-exporter-otlp を入れ、opentelemetry-instrument でアプリを起動する方法を案内しています（Python 3.9 以上）。

注文の処理でトレース（3つのスパン）を作り、注文数のカウンターと決済時間のヒストグラムをラベル付きで記録するプログラムを書きました。送り先は環境変数で擬似の受け口に変えています。

import os, time
from opentelemetry import trace, metrics
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter

key = os.environ["MACKEREL_APIKEY"]
res = Resource.create({"service.name": "shop-api", "deployment.environment.name": "staging"})

# トレース：本番は https://otlp-vaxila.mackerelio.com/v1/traces（HTTP/protobuf）
tp = TracerProvider(resource=res)
tp.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(
    endpoint=os.environ.get("TRACES_ENDPOINT", "https://otlp-vaxila.mackerelio.com/v1/traces"),
    headers={"Mackerel-Api-Key": key, "Accept": "*/*"})))
trace.set_tracer_provider(tp)

# ラベル付きメトリック：本番は otlp.mackerelio.com:4317（gRPC）
mp = MeterProvider(resource=res, metric_readers=[PeriodicExportingMetricReader(OTLPMetricExporter(
    endpoint=os.environ.get("METRICS_ENDPOINT", "otlp.mackerelio.com:4317"),
    insecure=os.environ.get("METRICS_INSECURE") == "1",
    headers=(("mackerel-api-key", key),)), export_interval_millis=60000)])
metrics.set_meter_provider(mp)

tracer = trace.get_tracer("shop"); meter = metrics.get_meter("shop")
orders = meter.create_counter("shop.orders", unit="{order}", description="注文数")
latency = meter.create_histogram("shop.checkout.duration", unit="ms", description="決済の所要時間")

with tracer.start_as_current_span("POST /orders", kind=trace.SpanKind.SERVER) as span:
    span.set_attribute("http.request.method", "POST")
    with tracer.start_as_current_span("SELECT stock"):
        time.sleep(0.02)
    with tracer.start_as_current_span("INSERT orders"):
        time.sleep(0.03)

for ms, pay in [(120, "card"), (180, "card"), (95, "card"), (340, "konbini")]:
    orders.add(1, {"payment": pay, "status": "ok"})
    latency.record(ms, {"payment": pay})
orders.add(1, {"payment": "card", "status": "error"})

tp.shutdown(); mp.shutdown()

MACKEREL_APIKEY=s387-write-key-0000000000000000000000000000 \
TRACES_ENDPOINT=http://127.0.0.1:38701/v1/traces \
METRICS_ENDPOINT=127.0.0.1:38717 METRICS_INSECURE=1 \
python otel_app.py

届いたトレース（HTTP/protobuf）

POST /v1/traces  (528 bytes)
  user-agent: OTel-OTLP-Exporter-Python/1.45.1
  content-type: application/x-protobuf
  accept: */*
  mackerel-api-key: s387-write-key-0000000000000000000000000000

protobuf を読んだ中身の要点です。3つのスパンが同じトレース ID でつながり、親子関係が付いていました。

resource: service.name=shop-api, deployment.environment.name=staging, telemetry.sdk.version=1.45.1
POST /orders     SERVER    50.5 ms
├─ SELECT stock  INTERNAL  20.1 ms
└─ INSERT orders INTERNAL  30.1 ms

service.name が、Mackerel の APM の画面で選ぶサービス名になります。

届いたラベル付きメトリック（gRPC）

gRPC のメタデータには mackerel-api-key が付いていました。ラベル（属性）の組み合わせごとに、別の系列として届きます。

/opentelemetry.proto.collector.metrics.v1.MetricsService/Export
  user-agent: OTel-OTLP-Exporter-Python/1.45.1 grpc-python/1.84.1 grpc-c/56.0.0 (linux; chttp2)
  mackerel-api-key: s387-write-key-0000000000000000000000000000

メトリック	ラベル	届いた値
shop.orders（Sum）	payment=card・status=ok	3
shop.orders（Sum）	payment=konbini・status=ok	1
shop.orders（Sum）	payment=card・status=error	1
shop.checkout.duration（Histogram）	payment=card	count 3・sum 395・min 95・max 180
shop.checkout.duration（Histogram）	payment=konbini	count 1・sum 340・min 340・max 340

ヘルプでは、ヒストグラムは全部のバケットではなく、count・sum・min・max・p99・p95・p90 だけが保存され、PromQL の histogram_quantile などの histogram_ 系の関数は使えないと説明しています。値が null・inf・NaN になるものは保存されません。ラベル付きメトリックはクエリ（PromQL の形）でグラフや監視に使います。

gRPC のヘッダー名は小文字にする

同じ送り方で、ヘッダー名を Mackerel-Api-Key（大文字を含む）にすると、送る前に gRPC のライブラリが止めました。

E1023 20:40:40.069066    7735 filter_stack_call.cc:401] Metadata key 'Mackerel-Api-Key' is invalid: INTERNAL: Illegal header key
ERROR:opentelemetry.exporter.otlp.proto.grpc.exporter:Failed to export metrics to 127.0.0.1:38717, error code: StatusCode.INTERNAL, error details: Invalid metadata

gRPC のメタデータの名前は小文字だけが使えます。HTTP で送るトレースは大文字のままでも送れ、受け口には小文字の mackerel-api-key で届きました（HTTP のヘッダー名は大文字・小文字を区別しない）。

OpenTelemetry の計装そのものは、関連記事「OpenTelemetry入門｜Pythonで始めるトレース・メトリクス実装」で扱っています。

外形監視・ログ監視・アラートと通知の設定

この節では、監視ルールの種類と、外形監視・ログ監視の決まり、通知の送り先が分かります。

監視ルールの種類

種類	何を見るか
ホストメトリック監視	ホストの値がしきい値を超えた・下回った（サービス・ロールで対象を絞れる）
サービスメトリック監視	サービスの値。値が途切れたことも監視できる
死活監視	エージェントからの投稿が一定時間途絶えた（エージェントを入れたホストに自動で付く）
チェック監視	チェックプラグインの結果
URL外形監視	外から URL にアクセスした結果
式による監視	複数のメトリックを計算した値
クエリによる監視	ラベル付きメトリックへのクエリの結果
ロール内異常検知	機械学習でロールのいつもと違う動き

しきい値は Warning と Critical の2段階で決め、「直近の何点の平均で判定するか」「何回続いたらアラートにするか」「通知の再送の間隔」を足せます。平均の点数は分ではなく点の数です。

URL外形監視の決まり

項目	ヘルプの内容
間隔	1分ごと（固定）
タイムアウト	15秒（15秒より大きいしきい値を決めても15秒で切れる）
異常とするもの	4xx・5xx、指定以外のステータス、タイムアウト、SSL 証明書の不正、応答時間のしきい値超え、本文に指定の文字が無い、証明書の残り日数
正常	2xx（リダイレクトを追わない設定なら 3xx も）
User-Agent	指定しなければ mackerel-http-checker/x.y.z
リダイレクト	追う設定で3回以上はエラー
応答時間のグラフ	サービスに紐付けると、サービスメトリックとして記録（メトリック1件分の料金）

ログ監視（check-log）

ログに文字列が出たら知らせるには、公式のチェックプラグイン check-log を使います。ヘルプの例です。

[plugin.checks.access-log]
command = ["check-log", "--file", "/var/log/access.log", "--pattern", "ERROR", "--return"]
check_interval = 5
max_check_attempts = 1

オプション	意味
--file・-f	見るファイル（glob も可）
--pattern・-p	正規表現。複数書くと AND
--exclude・-E	除く正規表現
--warning-over・--critical-over	合った行数がこの数を超えたら WARNING・CRITICAL（既定は0）
--return・-r	合ったログの行をアラートに入れる（1024文字で切る）
--icase・-i	大文字・小文字を区別しない
--encoding	ファイルの文字コード
--no-state	前回の位置を覚えず、全部を見る（手で試すとき）

check-log は前回どこまで読んだか（バイト数と inode）を State ファイルに書き、次は増えた分だけを見ます。mackerel-agent から動かすと /var/tmp/mackerel-agent/check-log に置かれます。ローテーションは create 方式に対応し、copytruncate 方式ではコピー先は追いません。

ログそのものを集めて検索したいときは、別の機能の「ログ機能」（β）を使います。ヘルプでは、OpenTelemetry 準拠の形式で集め、サービス単位で横断検索し、取り込んだ量で課金すると説明しています。ログの保持は保証しないと明記されています（2026年10月23日時点）。

通知チャンネルと通知グループ

通知チャンネルは、メール・Slack・Chatwork・Twilio・PagerDuty・Opsgenie・Jira Service Management・Microsoft Teams・Webhook・Amazon EventBridge の10種類です。通知グループを使うと、サービスごとに送り先を分けられます。「Critical only」を付けたグループには Warning が送られません。メンテナンスで止めるときは、ダウンタイムを設定するとその間の通知を止められます。

何をどのしきい値で監視するかは、関連記事「監視設計の項目一覧｜死活・リソース・ログ監視のしきい値例とテンプレート」で扱っています。

Datadog・Zabbix・New Relicとの違い

この節では、よく比べられる監視ツールとの違いを、事実で比べられます。

ツール	形態	料金の単位（2026年10月23日時点）	無料で使える範囲
Mackerel	SaaS（はてな、日本）	ホスト数・メトリック数・スパン数。円・税込	フリー：ホスト5台・メトリック500・グラフ1日
Datadog	SaaS	製品ごと。Infrastructure Pro は1ホスト月15ドル〜（年払い）	Infrastructure Free：5ホスト・保持1日
New Relic	SaaS	取り込むデータ量（GB）＋ユーザー数	月100GB・フルプラットフォームユーザー1人
Zabbix	オープンソース（7.0 から AGPLv3）	ソフトは無料。サーバー代・運用・有償サポート	ソフトは無料

比べる点	Mackerel	Datadog	New Relic	Zabbix
データの集め方	エージェントが送る（push）＋クラウド連携	Agent が送る＋クラウド連携	エージェント・OpenTelemetry が送る	Zabbix エージェント・SNMP など
独自の値	プラグイン（タブ区切りの3列）	DogStatsD など	カスタムイベント・メトリクス	アイテム・zabbix_sender

Datadog の料金の数え方と Agent の通信の中身は関連記事「Datadogとは｜できること・料金・仕組みと他ツールとの違いを実例で解説」で、Zabbix の構成とインストールは関連記事「Zabbixとは｜構成・用語・インストールと使い方を実例で解説」で、New Relic の NRQL と料金は関連記事「New Relicとは｜できること・料金・NRQLと仕組みを実例で解説」で扱っています。

Mackerelのよくあるエラーとデータが出ないとき

この節では、値が画面に出ない・アラートが鳴らないときの原因と直し方を引けます。1行目は実際に出たエラー、ほかは公式ドキュメントの記載から作りました。

エラー・症状	原因	直し方
Metadata key 'Mackerel-Api-Key' is invalid: INTERNAL: Illegal header key	gRPC のメタデータの名前に大文字（上の実測）	mackerel-api-key と小文字で書く
API が 403 を返す	Read 権限だけのキー、または IP アドレスの制限の外	Write 権限のキーを使う。キーの許可範囲を確かめる
サービスメトリックの投稿で 429	1分あたりのリクエストが多すぎる	1分ごとに、複数の値をまとめて送る
200 が返るのにグラフに出ない	時刻が24時間より前（記録されない）	エポック秒（ミリ秒ではない）で今の時刻を送る
プラグインの値が出ない	区切りがタブでない、名前に使えない文字、セクション名のドットが2つでない	cat -A でタブ（^I）を確かめる。mackerel-agent once で値を見る
グラフ定義が反映されない	1行目が # mackerel-agent-plugin でない。API ではグラフ名に custom. が無い	1行目を合わせる。API の name は custom. から始める
ワイルドカードのグラフが消えた	約6〜8時間以上送られなかった定義は自動で消える	送り続ける。再び送れば定義も作られる
チェック監視のルールが無い	ルール名にドット、または設定を変えた後に再起動していない	名前からドットを除き、再起動する
複製したサーバーが同じホストになる	イメージに /var/lib/mackerel-agent/id が入っていた	複製後に id ファイルを消して起動すると、新しいホストとして登録される
トレースが届かない	Write 権限のキーでない、Accept: */* が無い	ヘルプの設定例どおりにヘッダーを2つ付ける
外形監視がタイムアウトする	15秒で打ち切り	応答の遅い URL は、軽い確認用の URL に分ける
AWS インテグレーションの設定が出ない	フリープランでは提供されない（ヘルプの記載）	トライアルかスタンダードで使う

• 1エージェントは動いているかjournalctl -u mackerel-agent.service でエラーを見る。verbose = true で DEBUG のログが出る
• 2設定ファイルの書き方は合っているかmackerel-agent configtest で確かめ、変えたら再起動する
• 3プラグイン単体で値が出るかエージェントと同じユーザーで実行し、タブ区切りの3列か確かめる
• 4API キーの権限は Write かRead だけのキーでは投稿できない（403）
• 5外へ HTTPS で出られるかプロキシが要るなら http_proxy・https_proxy を設定ファイルに書く

Mackerelが合う・合わないの判断表

この節では、状況ごとに Mackerel を選ぶかどうかの目安が分かります。

状況	選ぶものの目安
監視サーバーを持たずに、サーバーの監視を始めたい	Mackerel などの SaaS
料金を円で、ホスト数から見積もりたい	Mackerel（ホスト単価・税込の表記）
日本語のヘルプ・サポートで運用したい	Mackerel（日本語のメールサポート、上位プランで TAM）
サーバーの台数は少なく、アプリの性能監視が中心	OpenTelemetry で計装し、Mackerel の APM や New Relic などを比べる
監視データを社外に出せない	Zabbix など、社内で動かせるもの
まず無料で試したい	トライアル2週間の後、フリー（5台・グラフ1日）で続ける
独自の業務の値（キュー・売上）も同じ画面で見たい	プラグインかサービスメトリックで送る

よくある質問

Q. Mackerelとは何ですか？ A. 株式会社はてなが提供するサーバー監視・オブザーバビリティの SaaS です。サーバーに mackerel-agent を入れると、CPU・メモリなどのグラフ、監視ルール、通知が使えます。機能の一覧は「Mackerelでできること」の節にあります。

Q. Mackerelの読み方は？ A. 「マカレル」です。英語の mackerel は魚のサバのことです。

Q. Mackerelは無料で使えますか？ A. 使えます。フリープランは、ホスト5台・メトリック500・監視ルール10件・グラフの表示期間1日までで、ユーザー数は無制限です。新しいオーガニゼーションは2週間のトライアルの後、自動でフリーへ移ります（2026年10月23日時点）。

Q. Mackerelの料金はいくらですか？ A. スタンダードプランは、スタンダードホスト1台 2,180円/月、マイクロホスト660円/月、メトリック11円/月、スパンは5Mを超えた分が330円/1M です（税込、2026年10月23日時点）。試算は「月額の試算」にあります。

Q. mackerel-agentの設定ファイルはどこにありますか？ A. Linux では /etc/mackerel-agent/mackerel-agent.conf です。TOML で書き、必須は apikey だけです。ホスト ID は /var/lib/mackerel-agent/id に保存されます。

Q. Mackerelのプラグインはどう作りますか？ A. 標準出力に 名前<TAB>値<TAB>エポック秒 を出すプログラムを書き、設定ファイルの [plugin.metrics.名前] の command に書きます。チェック監視は終了ステータス（0・1・2・それ以外）で状態を返します。実物は「プラグインの作り方」の節にあります。

Q. MackerelはMacやWindowsで使えますか？ A. Windows Server には MSI のインストーラーがあります。macOS はヘルプで公式のサポート対象外とされています。

Q. MackerelとZabbixの違いは？ A. Mackerel は SaaS で、監視サーバーを自分で用意せず、ホスト数などに応じて月額を払います。Zabbix はオープンソースで、ソフトは無料ですが、サーバー・データベース・画面を自分で運用します。

Q. MackerelとDatadogの違いは？ A. どちらも SaaS で、無料の範囲はどちらも5ホスト・保持（表示）1日です。料金は Mackerel がホスト数・メトリック数・スパン数（円・税込）、Datadog は製品ごとにホスト数やデータ量（米ドル）で数えます。

Q. MackerelはOpenTelemetryに対応していますか？ A. 対応しています。APM のトレースは https://otlp-vaxila.mackerelio.com/v1/traces に、ラベル付きメトリックは otlp.mackerelio.com:4317 に、ヘッダー Mackerel-Api-Key を付けて送ります。届くデータの実物は「APM・ラベル付きメトリック」の節にあります。

Q. Mackerelでログ監視はできますか？ A. できます。ログに文字列が出たら知らせるには check-log プラグインをチェック監視で使います。ログを集めて検索するには、β版のログ機能を使います。

Q. APIキーはどこで作りますか？ A. 画面の「API キー」タブで作ります。Read と Write の権限を分けられ、値の投稿には Write 権限が要ります。

まとめ

• Mackerel（マカレル）は、はてなのサーバー監視・オブザーバビリティの SaaS。mackerel-agent を入れると、1分ごとのメトリック・グラフ・監視・通知が使える。
• ホストは「サービス」と「ロール」でまとめ、監視ルールや通知先もその単位で決める。サービス名は後から変えられない。
• 料金はスタンダードホスト 2,180円・マイクロホスト 660円・メトリック11円（税込、月）。フリーはホスト5台・メトリック500・グラフ1日（2026年10月23日時点）。
• プラグインは 名前<TAB>値<TAB>時刻 を出すだけで作れ、チェック監視は終了ステータスで状態を返す。実験では、その出力が POST /api/v0/tsdb と /api/v0/monitoring/checks/report の JSON になって届いた。
• APM とラベル付きメトリックは OpenTelemetry で送る。gRPC ではヘッダー名を小文字の mackerel-api-key にする。

参考・出典

確認日はいずれも 2026年10月23日です。

• Mackerel 公式サイト：https://ja.mackerel.io/
• Mackerel「料金」：https://ja.mackerel.io/pricing
• Mackerel「上位オプションプラン」：https://ja.mackerel.io/higher-plan
• Mackerel ヘルプ「Mackerelをはじめる」：https://mackerel.io/ja/docs/entry/getting-started
• Mackerel ヘルプ「Mackerelの概要」：https://mackerel.io/ja/docs/entry/overview
• Mackerel ヘルプ「サービス・ロールについて」：https://mackerel.io/ja/docs/entry/spec/about-service-role
• Mackerel ヘルプ「mackerel-agent 仕様」：https://mackerel.io/ja/docs/entry/spec/agent
• Mackerel ヘルプ「メトリックの仕様」：https://mackerel.io/ja/docs/entry/spec/metrics
• Mackerel ヘルプ「Debian / Ubuntu にエージェントをインストールする」：https://mackerel.io/ja/docs/entry/howto/install-agent/deb
• Mackerel ヘルプ「ホストのカスタムメトリックを投稿する」：https://mackerel.io/ja/docs/entry/advanced/custom-metrics
• Mackerel ヘルプ「チェック監視を行う」：https://mackerel.io/ja/docs/entry/custom-checks
• Mackerel ヘルプ「公式メトリックプラグイン集」：https://mackerel.io/ja/docs/entry/howto/mackerel-agent-plugins
• Mackerel ヘルプ「メトリックプラグイン一覧」：https://mackerel.io/ja/docs/entry/plugins/metric-plugins-list
• Mackerel ヘルプ「公式チェックプラグイン集」：https://mackerel.io/ja/docs/entry/howto/mackerel-check-plugins
• Mackerel ヘルプ「mkr でプラグインをインストールする」：https://mackerel.io/ja/docs/entry/advanced/install-plugin-by-mkr
• Mackerel ヘルプ「CLI ツール mkr」：https://mackerel.io/ja/docs/entry/advanced/cli
• Mackerel ヘルプ「mkr wrap でバッチジョブを監視する」：https://mackerel.io/ja/docs/entry/howto/mkr/wrap
• Mackerel ヘルプ「監視・通知を設定する」：https://mackerel.io/ja/docs/entry/howto/alerts
• Mackerel ヘルプ「URL外形監視」：https://mackerel.io/ja/docs/entry/external-monitoring
• Mackerel ヘルプ「ログ監視をおこなう」：https://mackerel.io/ja/docs/entry/howto/check/log
• Mackerel ヘルプ「check-log」：https://mackerel.io/ja/docs/entry/plugins/check-log
• Mackerel ヘルプ「Mackerel ログ機能の概要」：https://mackerel.io/ja/docs/entry/log/introduction
• Mackerel ヘルプ「AWSインテグレーション」：https://mackerel.io/ja/docs/entry/integrations/aws
• Mackerel ヘルプ「ラベル付きメトリックを投稿する」：https://mackerel.io/ja/docs/entry/howto/labeled-metrics/post-metrics
• Mackerel ヘルプ「PythonのアプリケーションからMackerelにトレースを送信する」：https://mackerel.io/ja/docs/entry/tracing/installations/python
• Mackerel ヘルプ「OpenTelemetry Collectorを導入する」：https://mackerel.io/ja/docs/entry/tracing/installations/opentelemetry-collector
• Mackerel ヘルプ「概算使用量メトリック」：https://mackerel.io/ja/docs/entry/advanced/estimated-usage-metrics
• Mackerel API ドキュメント：https://mackerel.io/ja/api-docs/
• Mackerel API「ホスト」：https://mackerel.io/ja/api-docs/entry/hosts
• Mackerel API「ホストメトリック」：https://mackerel.io/ja/api-docs/entry/host-metrics
• Mackerel API「サービスメトリック」：https://mackerel.io/ja/api-docs/entry/service-metrics
• Mackerel API「チェック監視」：https://mackerel.io/ja/api-docs/entry/check-monitoring
• mackerel-agent（GitHub）：https://github.com/mackerelio/mackerel-agent
• mackerel-agent のリリース（GitHub）：https://github.com/mackerelio/mackerel-agent/releases
• OpenTelemetry Python（PyPI）：https://pypi.org/project/opentelemetry-sdk/
• Datadog「Pricing」：https://www.datadoghq.com/pricing/
• New Relic「Pricing」：https://newrelic.com/pricing
• Zabbix「License」：https://www.zabbix.com/license

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。