New Relic と Scandock の比較

New Relic は、APM・インフラ・ログなどを扱う監視の基盤です。DB については、APM の Databases の画面にアプリから見たクエリの時間が、PostgreSQL や MySQL の統合 (infrastructure agent) で DB の側の指標やクエリの性能が出ます。

Scandock は、DB の監視に絞ったサービスです。AI が DB のテーブルと実データを読んで何を見張るかを決め、異常があれば原因まで調べてから知らせます。

どちらも DB の異常に気づくための道具ですが、New Relic では人が監視の条件を作り、人が画面を読んで原因を調べます。Scandock では、その両方を AI が行います。この記事では、両方の実際の画面を並べて、その違いを見ていきます。

比較表

何を見張るか: 条件を人が決めるか、AI が決めるか

New Relic

New Relic では、アラートの条件ごとに、見るデータをクエリで決め、判定の方法を固定の閾値 (Static)、異常検知 (Anomaly)、外れ値 (Outliers) から選びます。異常検知を選んでも、何標準偏差を超えたら何分続いたら知らせるか、警告と重大の2段階をどう分けるかは人が決めます。業務データを見張るなら、カスタムクエリの設定も自分で書きます。どのデータが業務に効くかを知っていて、条件を調整し続ける人が要ります。

Scandock

Scandock では、AI がテーブルと実データを読み、決済の成否、決済手段ごとの失敗、注文の流入、配送ジョブの滞留などを監視項目にします。人が条件や閾値を決める必要はありません。AI が推移から異常を判断して「発火」の印を付け、そのまま原因の調査に進みます。

原因の調べ方: 画面を読むか、答えが届くか

New Relic

New Relic では、APM の Databases の画面で、時間を多く使っている DB の操作や、DB ごとの所要時間と回数の推移を見ます。そこから遅いクエリの一覧を開き、どのクエリにどれだけ時間がかかったかを確かめます。PostgreSQL や MySQL の統合を入れれば、DB の側から見たクエリの性能や待ちのダッシュボードも出ます。どの画面で何を見るかを判断し、原因を突き止めるのは人です。

Scandock

Scandock では、異常に気づいた AI が、読み取り専用のクエリで DB を調べます。どこで何が起きているかを根拠つきでまとめ、対処案を添えて Slack やメールに知らせます。人は画面を読み解かなくてよく、届いた結果を読んで、対処を承認するかを決めるだけです。

導入の手順

セルフホストの PostgreSQL (Linux) を、クエリの性能まで監視する場合で比べます。

New Relic

1. DB に届くホストに infrastructure agent を入れ、PostgreSQL の統合 (nri-postgresql) を入れる
2. 監視用の new_relic ユーザーを作り、pg_read_all_stats などの権限を与える
3. pg_stat_statements、pg_stat_monitor、pg_wait_sampling の拡張を入れ、postgresql.conf の shared_preload_libraries に足して DB を再起動し、CREATE EXTENSION を実行する
4. /etc/newrelic-infra/integrations.d に postgresql-config.yml を作り、接続先と ENABLE_QUERY_MONITORING を書く

PostgreSQL は 12 以降が対象です。APM の Databases の画面を使うには、別にアプリへ APM エージェントを入れます。

Scandock

1. 接続文字列を貼って登録する (管理者ユーザーなら、監視用の読み取り専用ユーザーを自動で作る)
2. AI がテーブルと実データを読み、監視項目を決めて見張り始める

Scandock は DB サーバーに何も入れず、DB の設定も変えません。公開していない DB は Cloudflare Tunnel 経由で接続できます。

料金

New Relic は、画面を使う人 (Full Platform User) の数と、取り込むデータの量で決まります。DB の数では決まりません。そこで、使う人の数ごとに比べます。Scandock はプランごとに使える人の数が決まっていて、5人までが Starter、20人までが Business です。