Mackerel と Scandock の比較
Mackerel と Scandock を、監視の作り方、原因の調べ方、導入の手順などで比べます。
2026年11月3日時点
Mackerel は、株式会社はてなが運営する日本のサーバー監視サービスです。サーバーに mackerel-agent を入れてメトリックを集め、グラフで見て、監視ルールでアラートを出します。DB は、エージェントのプラグイン (mackerel-plugin-mysql、mackerel-plugin-postgres など) や、AWS インテグレーションによる Amazon RDS の監視で見られます。
Scandock は、DB の監視に絞ったサービスです。AI が DB のテーブルと実データを読んで何を見張るかを決め、異常があれば原因まで調べてから知らせます。
どちらも DB の異常に気づくための道具ですが、「誰が監視を作り、誰が原因を調べるか」が違います。Mackerel では、閾値を決めるのも、グラフを見て原因を探すのも人です。Scandock では、その両方を AI が行います。この記事では、両方の画面を並べて、その違いを見ていきます。
結論
DB の監視と原因の調査を任せたいなら Scandock をおすすめします。
閾値を決めて調整する作業も、グラフを見比べて原因を探す作業も、AI が代わりに行います。接続文字列を登録するだけで始められ、注文や決済のような業務データの異常も見張ります。サーバーやコンテナの状態を見張ることが主な目的で、閾値の設定と原因の調査を自分たちで行える人がいるなら、Mackerel で足ります。
比較表
| 項目 | Mackerel | Scandock |
|---|---|---|
| 監視項目の設計 | 人がプラグインを入れ、監視ルールを作る | AI がテーブルと実データを読んで決める |
| 異常の判定 | 人が Warning と Critical の閾値を決める (サーバーのシステムメトリックには機械学習の異常検知もある) | AI が推移と過去の結末から判定する |
| 原因の調査 | 人がグラフを見比べて調べる | AI がクエリを実行して調べ、根拠つきで通知する |
| 対処 | 人が手で対処する | 登録した対処を、承認してから実行する |
| 導入 | DB サーバーにエージェントとプラグインを入れ、設定ファイルを書く | 接続文字列を登録する |
| 業務データの監視 | メトリックを投稿するプログラムを自分で書く | 注文数や決済の失敗なども AI が見張る |
| 見られる範囲 | サーバー、コンテナ、クラウド、ログ、トレースなど | DB に絞る |
何を見張るか: 閾値を人が決めるか、AI が決めるか
Mackerel
Mackerel では、監視ルールごとに、見るメトリックと、Warning と Critical の閾値を人が決めます。平均を取る点の数や、何回続いたらアラートにするかも決められます。DB のプラグインが集めるのは、接続数、コミットとロールバックの数、デッドロックの数などです。どの数字がどこまで動いたら困るのかは、人が判断して閾値にします。
機械学習で普段と違う動きを見つける「ロール内異常検知」もあります。ただし対象は mackerel-agent が集める CPU やメモリなどのシステムメトリックで、DB のプラグインのメトリック (カスタムメトリック) は対象外です。
Scandock
Scandock では、AI がテーブルと実データを読み、決済の成否、決済手段ごとの失敗、注文の流入、配送ジョブの滞留などを監視項目にします。閾値は置かず、推移から異常を判断して「発火」の印を付け、そのまま原因の調査に進みます。
原因の調べ方: グラフを読むか、答えが届くか
Mackerel
Mackerel では、アラートを受けたら、人がホストやロールのグラフを開いて、いつから何が変わったかを見比べます。どのクエリやどのデータが原因かまでは、グラフからはわかりません。DB に入って調べる作業は人が行います。
Scandock
Scandock では、異常に気づいた AI が、読み取り専用のクエリで DB を調べます。どこで何が起きているかを根拠つきでまとめ、対処案を添えて Slack やメールに知らせます。人は読んで、承認するかを決めます。
導入の手順
セルフホストの PostgreSQL を監視する場合で比べます。
Mackerel
- DB サーバーに mackerel-agent を入れる
- 公式プラグイン集 (mackerel-agent-plugins) を yum か apt で入れる
- pg_monitor ロールを持つ監視用のユーザーを作る (PostgreSQL 10 以降)
- mackerel-agent.conf に [plugin.metrics.postgres] とユーザー名・パスワードを書き、エージェントを再起動する
- 画面で監視ルールを作り、メトリックごとに閾値を決める
Amazon RDS なら、エージェントの代わりに AWS インテグレーションを使います。AWS で IAM ロールを作って読み取りのポリシーを付け、Mackerel に登録します。集まるのは CloudWatch のメトリックで、監視ルールは同じように人が作ります。
Scandock
- 接続文字列を貼って登録する (管理者ユーザーなら、監視用の読み取り専用ユーザーを自動で作る)
- AI がテーブルと実データを読み、監視項目を決めて見張り始める
Scandock は DB サーバーに何も入れず、DB の設定も変えません。公開していない DB は Cloudflare Tunnel 経由で接続できます。
どちらを選ぶか
Mackerel で足りる会社
- 見張りたいのが主にサーバーやコンテナ、クラウドのリソースで、DB は接続数などのメトリックを見られれば十分
- 閾値の設定と調整、アラートを受けてからの DB の調査を、自分たちで続けられる人がいる
Scandock が向いている会社
- DB に詳しい人がいない、または手が回っていない
- 閾値を決めて調整し続ける作業をやめたい
- 注文数や決済の失敗など、業務データの異常も見張りたい
- アラートを受けてから原因を調べる時間を減らしたい
- 通知を LINE、Microsoft Teams、kintone などで受け取りたい
Mackerel では、監視ルールを作るのも、DB で何が起きたのかを突き止めるのも人の仕事です。Scandock なら、AI が監視を設計し、異常があれば原因まで調べて根拠つきで知らせ、承認すれば対処も実行します。サーバーの監視は Mackerel のまま、DB と業務データの監視を Scandock に任せることもできます。14日間は無料で、接続文字列を登録するだけで見張り始めます。
出典
- Mackerel ヘルプ: 監視・通知を設定する
- Mackerel ヘルプ: 式による監視をおこなう
- Mackerel ヘルプ: ロール内異常検知による監視をおこなう
- Mackerel ヘルプ: ミドルウェアのメトリック可視化に公式プラグイン集を使う
- Mackerel ヘルプ: mackerel-plugin-postgres
- Mackerel ヘルプ: AWS インテグレーション
- Mackerel ヘルプ: AWS インテグレーション - Amazon RDS
- Mackerel 公式サイト
Mackerel の手順・画面は、2026年11月3日に公式サイトで確認したものです。最新の情報は公式サイトで確かめてください。Mackerel は株式会社はてなの商標です。