Zenn
🐟

【Mackerel】監視初心者のMackerel学習ロードマップ

に公開
AWS
EC2
初心者向け
Mackerel
監視
tech

どうも！前歯すきっ歯です🦷
お仕事でMackrerlを触る機会があったので、今回はそのときの学習した記録を書いていきます！

0.本記事について

0-1.本記事で想定する読者

まさに自分がそうだったのですが、以下のような方を想定しています。

  • 監視自体始めて勉強する。
  • Mackerelを初めて触る。
  • ハンズオンの解説リンクや動画を見て勉強したい。
    ※ハンズオン形式の記事がない場合は、自分が画像を掲載しています。
  • Mackerelの基本的な監視方法(※)を網羅的に実践したい。
  • Mackerelが選ばれる理由を知りたい。

0-2.前提

以下3点を本記事の前提とします。

  • 監視対象のOSはAmazonLinux2023とWindows2022
  • AWS上のEC2が監視対象
  • AWSのNWリソース(VPCやサブネット)、EC2インスタンスは構築済みで通信が可能。
    ※今回は以下画像の構成図が作成済みです。

1.Mackerel動作環境準備に必要な見方・考え方を知る

自分はAWS環境を構築するときに以下2つの疑問を感じました。
　①EC2につけるセキュリティグループではどのIPアドレス、どのポートを開放すればいいのか？
　②Mackerel監視対象のサーバのIPアドレスは固定する必要があるのか？
①～②は、Makerelの監視構造を知れば解決できるので、以下Mackrerlの監視構造をご紹介します。

1-1.監視には大きく分けてPull型とPush型の構造がある。

「Pull型、Push型」どちらの方式で監視を行うかによって通信方法が異なり、基盤環境(今回ならばAWS)の作り方に関わるので、まずは上記用語を抑えましょう。 この話はミドルウェア(=MackerelやZabbix)監視全般に共通する通信方法の話です。

簡潔に言うと、それぞれ以下の図の通りの違いがあります。

（参考：Mackerel サーバ監視[実践]入門 P5）

各監視ミドルウェアによってPull型、Push型どちらを基本にしているかは異なるので、今後皆さんがMackerel以外を扱う機会があれば意識してみてください。例えば、ZabbixはPull型、MackerelやDatadogはPush型を基本として作られています。

1-2.Mackerel基本の監視方式

1-2-1.Mackerelの監視方式の基本はPush型

一部例外はありますが、以下図の通り、MackrerlはPush型を基本として監視を行っています。

（参考：はじめてのMackere Mackerel CREチーム編）

したがって、多くの監視項目ではEC2のセキュリティグループにおけるアウトバウンドの通信を気にかければよく、インバウンドの通信を気にかける必要はないことが分かります。 アウトバウンドの通信は0.0.0.0/0で空けることが多いと思うので、気にかける機会は少ないかもしれません。

1-2-2.アウトバウンドの通信を0.0.0.0/0で空けられないときの対処法

自分で勉強するだけならばアウトバウンドの通信を0.0.0.0/0で空けてもよいですが、お客様によってはアウトバウンドの通信も必要最低限に制限することがありますよね。アウトバウンド通信先のIPアドレスを公式では以下のように紹介しています。

mackerel-agentからMackerelへ、HTTPのREST API経由にて通信しています。
Mackerel側からmackerel-agentが入っているホストに直接通信することはありません。
（参考：mackerel-agentはどのような通信を行いますか？）

mackerel.io / api.mackerelio.com / kcps-mackerel.io 共に以下のレンジでホストされています。変更する際は事前に告知を行います。
13.113.31.156/32
54.92.89.142/32
52.196.35.56/32
52.69.239.167/32
52.198.226.45/32
52.198.218.152/32
13.113.245.173/32
52.199.207.168/32
52.193.231.228/32
ポート番号は443です。
mackerel-agentからのリクエスト先も上記のIPアドレスとポート番号に対しての通信となります。
（参考：サービスがホストされているIPアドレスとポート番号を教えて下さい）

1-2-3.Push型の監視項目ならばIPアドレスの固定が不要

Push型の監視項目ならばエージェント(=監視対象サーバ)がMackerelへメトリクスを送るだけなので、Mackerel側がエージェンの位置(IPアドレス)を知る必要がありません。したがって、IPアドレスの固定が不要です。 自分はEC2にElastic IPを持たせずにMackrerlで監視しましたが、サーバの起動・停止に伴いパブリックIPアドレスが変わっても監視することができました◎

次項からMackrel内では例外の監視方式（Pull型)で扱われる監視項目についてお話しします。

1-3.Mackerel例外の監視方式

今回実践する中でPull型の監視項目が2つあるのでご紹介します！

1-3-1.Pull型で監視する項目①　～URL外形監視～

まず、URL外形監視とは以下のような監視を指しています。

外形監視とは、指定したURLに定期的にリクエストを送り、ステータスコードやレスポンスボディの中身、レスポンスにかかった時間などを監視する機能です。対象URLへアクセスするプロトコルがHTTPSの場合は、SSL証明書の有効期限を監視することもできます。
(参考：高度な監視)

したがって、Mackerelから監視対象サーバ(=今回はEC2)に対して定期的にリクエストが送られるので、EC2のセキュリティグループのインバウンド通信でMackerelから来るリクエストを許可する必要があります。 許可が必要な通信は以下の通りです。

Mackerelからの通知・外形監視リクエストのリクエスト元IPアドレスレンジは、以下の通りです。変更する際は事前に告知を行います。
52.193.111.118/32
52.196.125.133/32
13.113.213.40/32
52.197.186.229/32
52.198.79.40/32
13.114.12.29/32
13.113.240.89/32
52.68.245.9/32
13.112.142.176/32
（参考：Webhook通知や外形監視などの通知元IPアドレスは？）

1-3-2.Pull型で監視する項目②　～クラウドメトリクスとの連携～

クラウドのメトリクスをMackerelで取得することも可能です。MackerelとAWSのメトリクスを連携することを「AWSインテグレーション」と呼びます。AWSインテグレーションは以下の仕組みで監視されます。

AWSインテグレーションではAWSクラウド製品をMackerelのホストとして管理し、メトリックを監視できます。
AWSクラウド製品のうち、EC2についてはスタンダードホスト、その他の製品についてはマイクロホストとして課金されます。 また、5分ごとに取得対象となるメトリックの数だけAWSのAPIをコールするため、Amazon CloudWatch API利用の料金が発生する場合がありますのでご注意ください。

したがって、AWSインテグレーションにてMackerelがメトリクスを取得するときの通信の流れは「Mackerel⇒Amazon CloudWatch API⇒CloudWatch⇒EC2」となり、MackerelがEC2へ直接通信することがないため、EC2のセキュリティグループのインバウンド通信で特段の設定は不要です。

2.実践①(アカウント開設～対象サーバLinuxの監視設定、通知設定)

2-1.アカウント作成～Linuxサーバの基本的な監視の実践

本項では以下のリンクを用いて実践します。公式のナレッジでここまで丁寧にハンズオン形式で書かれているサービスを始めて見ました…！大変ありがたいです！

🔗手順リンク：Mackerel公式GitHubのハンズオン

上記ナレッジを見ながら進めると、Mackrerlスタートから以下7点を実践できます。
🧑‍🎓実践できること🧑‍🎓＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
・Mackerelアカウント開設
・オーガニゼーション、サービス、ロールの作成(Mackerelの監視対象サーバをグルーピングする概念)
・Mackerelエージェントのインストール（インストール対象サーバLinux）
・リソース監視(CPU使用率/メモリ使用率/ディスク使用率)
・プロセス監視（httpdが対象）
・監視ルールの設定（例：CPU使用率が90％以上だったらアラートを上げる）
・アラート時の通知先の設定
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

2-2.ログ監視(=チェック監視)の勉強

[2-1]のリンクには紹介がないログ監視は以下の記事が詳しく記載してくださっています。

🔗手順リンク：Mackerel を触ってみる（ログ監視編）

※もちろんMackerel公式でもログ監視の方法を記載してくださっていますが、アラートまで起こすことを想定して勉強したかったので上記手順リンクを見ながら勉強しました。

2-3.AWSインテグレーション(EC2のメトリクスを取る)

freeプランになるとできなくなってしまうので、Traial期間のうちに[2-2]までの手順で使っていたLinuxサーバを対象にAWSインテグレーションとの連携をやってみました！

🔗手順リンク：Mackerel を触ってみる（AWS インテグレーション編）

※上記もMackerel公式の記事がありますが、EC2の監視をするだけならば、個人的には上記リンク手順の方がシンプルで見やすいと感じました。

2-4.URL外形監視

こちらの項目もTrial期間が終了すると試せなくなってしまうので、今のうちにやっておきます！
自分は先ほどから使っているApacheインストール済みサーバを用いて実践しました。
忘れずにMackerelから来る通信をセキュリティグループで許可しましょう～

🔗手順概要ハンズオンリンク：クラウドの運用にMackerelを使ってみた(第3回：プロセスやログ等の詳細監視設定)

🔗手順詳細ハンズオンリンク：Mackerel で Basic 認証、IP アドレス制限を利用している URL を外形監視する

🔗監視項目詳細リンク：URL外形監視をおこなう（Mackerel公式）

2-4-1.自分が実践した監視項目の設定

Apacheをインストールしたのみで特別な設定をしていなければ、デフォルトでアクセスするパスはhttp://[監視対象サーバのIPアドレス]/になると思います。したがって、自分は以下画像の通り設定してみました。もしよければ参考にしてください。
※自分はApacheをベースにしてWordPressを構築したサーバで実践したので、画像のようにレスポンスボディのチェックを入力しています。

URL外形監視 設定項目例

2-4-2.エラーの出方

自分が設定をミスして色々とエラーが出たので、その時の様子をご共有します笑
（各項目どんな感じでエラーが出るかシンプルに気になるのは自分だけですか？）

▼①セキュリティグループのインバウンドルールで許可を忘れたとき

HTTP Request timed out

▼②レスポンスボディが異なるとき（アクセス速度も見られるんですね！！！）

response body does not contain

3.実践②(Windowsサーバ特有の監視項目)

Linuxサーバで行ったことは省略します。具体的には、以下3つのことを実践しました。
🧑‍🎓実践すること🧑‍🎓＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
・WindowsサーバへMacekrelエージェントインストール
・イベントログ監視（PowerShellのコマンドで意図的にイベントを発生させ、それを監視します）
・サービス監視（対象はW3SVC）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

3-1.エージェントインストールとイベントログ監視

下記手順リンクが公式のリンク内で足りないハンズオンやアラートを出してみる作業を補ってくれます！

🔗手順リンク：MackerelでWindowsのイベントログ監視を行う

3-2.サービス監視

Windowsだとプロセスと別にサービスもあるので、サービスの監視も設定しました。
ネット上にハンズオン形式のサイトが見つからなかったので、画像は後ほど記載します。

🔗手順リンク：チェックプラグイン - check-ntservice

3-2-1.サービスとプロセスの違いってなに？

プロセスとサービスの違い…、いつそや勉強したのですが、すぐに答えろと言われても難しいのでネットの力を借りましょう！

🔗参考リンク：Windowsにおけるプロセスとサービスの概要や両者の違いについて

3-2-2.プロセス監視でサービス監視が補えない理由

プロセス監視でサービス監視が補えない理由は、下記引用の通りサービスには存在するが、プロセスには存在しないものがあるからですね！上記サービスとプロセスの違いを理解していると理解しやすいかと思います。例えば、WindowsサーバにSSHでアクセスするOpenSSHがサービスの例として挙げられますね！

check-procsはWindows版も用意されています。 実はNTサービスとプロセスはWindowsの場合、別々に監視する必要があります。 実際にIISなどNTサービスには存在するがプロセスでは存在しないサービスが居るため、Mackerelではそれぞれのプラグインを用意しています。
（参考：Windowsの監視 ~ check-ntserviceを読み解く）

3-2-3.サービス監視のハンズオン

ハンズオンで載せているサイトがなかったので、念の為に以下に記載します。
上記リンク内設定例にあるW3SVCサービスを試してみたので、手順を見たい方はどうぞ！

サービス監視手順
  1. C:\Program Files\Mackerel\mackerel-agent\mackerel-agent.confに以下を追記します。
mackerel-agent.conf 追記内容
[plugin.checks.ntservice]
command = ["check-ntservice", "--service-name", "W3SVC"]

※追記後全文は以下です。

mackerel-agent.conf 全文
# pidfile = 'C:\path\to\pidfile'
# root = 'C:\path\to\root'
verbose = false
apikey = "********************************************************"

# Include other config files
# include = 'C:\path\to\conf\*.conf'

# Configuration for Custom Metrics Plugins
# see also: https://mackerel.io/ja/docs/entry/advanced/custom-metrics
#
# [plugin.metrics.vmstat]
# command = 'ruby C:\path\to\plugins\metrics-vmstat.rb'
# [plugin.metrics.curl]
# command = "ruby C:\\path\\to\\plugins\\metrics-curl.rb"

[plugin.checks.check-eventlog-testevent]
command = ["check-windows-eventlog", "--log", "LOGTYPE", "--type", "Warning", "--source-pattern", "Test Event"]
prevent_alert_auto_close = true

[plugin.checks.ntservice]
command = ["check-ntservice", "--service-name", "W3SVC"]

  1. mackerel-agentの再起動
    サービスの画面を開き、mackerel-agentを再起動して設定を反映させます。

  2. 同じくサービスの画面からWorld Wide Web 発行サービスを選択し、さらにサービスの停止を選択する。

  3. Mackerelのコンソールからアラートを確認する。

  4. サービスの画面からWorld Wide Web 発行サービスを起動し、元に戻しておく。

4.実践③(閲覧用ユーザーの設定)

お客様とお話ししていると高頻度で出てくる「編集権限のない閲覧用のユーザーって作れますか？」というご要望がありますよね。どうやらMackerelでも可能なようですが、公式の記事にはハンズオンがなくイメージが湧かなかったので実践してみます！
🧑‍🎓実践すること🧑‍🎓＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
・他メールアドレス（＝他メンバー想定）をMackerelのダッシュボードに招待する。
・他メールアドレス（＝他メンバー想定）には閲覧権限しか与えない。
・監視項目を編集できないことを確認する。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

🔗手順リンク：他のユーザーをMackerelに招待する

上記実践している様子を以下⇩にまとめておくので、ハンズオンをご覧になりたい方はこちらからどうぞ！

閲覧用ユーザー追加の様子
  1. [オーガニゼーション詳細ページ]⇒[メンバー]⇒[招待する]の順に選択する。
  2. メールアドレスを入力し、[閲覧者として招待する]⇒[送信]の順に選択する。
  3. 招待メール送信画面に遷移。
  4. 届いているメール内にあるURLを選択して、[パスワードを忘れましたか？]を選択する。
    ※最初はパスワードを設定していないので、ログインできません。
  5. 追加したいユーザーのメールアドレスを入力して、[パスワードを再設定する]を選択する。
  6. メールを確認して、指定されたURLに飛ぶ。
  7. パスワードを入力して、[パスワードを設定する]を選択する。
  8. サインイン画面に遷移するので、7で入力したパスワードを再度入力し、[サインイン]を選択する。
  9. [オーガニゼーション名に参加]を選択する。

    10.Mackerelのコンソールにログイン
  10. 監視ルール画面を確認すると、[監視ルールを追加]ボタン、各ルールの[編集]ボタンがなかったり、通知のミュートを解除できなかったりするので、閲覧権限であることが分かる。

5.Mackerelサーバ監視[実践]入門を読む

手を動かすだけではMackerelの使い方を知るだけで終わってしまった感じがしました。アラートの閾値の設定基準等、監視に対する見方や考え方をさらに学びたく上記の本を読みました。新品だと2000円以上しますが、メルカリだと500円前後で買えてお手軽です！
本を買う前は「Mackerelの仕様についてだけそんなに勉強しなくてもいいかな？」という迷いもあったのですが、監視に対する考え方、監視の運用方法、監視を利用したDevOps…等監視の基礎について勉強になることが多かったので読んでよかったと感じています！

5-1.自分が勉強になったこと

自分が学んだことのメタ認知 兼 本記事読者への本の内容のご紹介として、ここでは監視初心者が勉強になったと感じたり、新たに学んだりしたことを抜粋して記載します！読者の皆さんが本を購入する判断の一助になれば嬉しいです。（ご紹介としては少し雑で申し訳ないのですが、本記事の本筋ではないので箇条書きでご容赦ください… 🙁)

Mackerelサーバ監視[実践]入門 を読んだ感想

※章ごとに分けて記載していますが、他章にも同様の記載があった時はまとめて書いている場合があります。
【全体を通して】

  • 全体的にとても丁寧に書かれており、初心者でも読みやすい。
  • 少し古い本（2017年）ですが、監視に対する普遍的な内容が扱われており、今(2025年)読んでも勉強になる本だった。

【1章：Mackerelとは何か】

  • 監視が必要な理由、監視の仕組み(Push型、Pull型とか)を学ぶことができた。(P5)
  • MackerelはSaaSだから、監視システムの構築と運用の工数を劇的に減らすことができる。
    • 実際Mackerel社には『数十のサービスを支えるための数百の役割をもった数千のホスト』が存在するが、数名のインフラエンジニアでそれらを運用している。(P298)
    • 監視サーバの監視、冗長化やバックアップを気にしなくてい。(P9)

【2章：Mackerelをはじめる】

  • グラフの使い方を知ることができた。構築や運用監視以外の立場の人(PMさんや営業さん)にも共有しやすいし、非常に見やすいと感じた。(P42)
    例）スライダー、アノテーション、カメラボタン、シェアボタン、全画面表示

【3章：監視する】

  • 閾値の初期の設定方法を学ぶことができた。(P58)
    • 直近1カ月のメトリクスを見て監視項目を設定する。
    • 新規構築する時は厳しめに設定して、徐々に緩めていくことで最終的に適切な閾値に収束させる。
  • 閾値の運用方法を学ぶことができた。(P60)
    実際にアラートが上がったときに、次の段階の閾値を設けるまでどのようなフローで設定するべきか学んだ。閾値は運用しながら育てるもの。
  • サービス、ロールを実際はどのような考え方で分けて、運用していくべきか知ることができた。(P64)
    自分の勉強の中では少ないサーバを対象としているが、監視対象サービスの規模が大きくなってきたときには話が違う。はてな社で実際に行われているサービスとロールのグルーピング方法が書かれており分かりやすかった。DBサーバのマスターとスレーブですらロールを分けることに驚き。監視の運用は奥が深い…。
  • チェックプラグインの仕組み、書き方を知ることができた。(P84)
    Perl,Python,Rubyを使ってプラグインを記述したり、チェック監視の仕組み自体はNacgios,Sensuとの互換性があったりするので、監視設定する人を選ばなかったり、既存監視からの移行がスムーズだったりする。
  • Mackerelの技術選定の理由を実例を通して学ぶことができる。(P95)
    内部で動いている言語やログを保管するDBの選定理由が知れる良い機会だった。
    • 例）MackerelのプラグインはGO言語で書かれているから、パフォーマンスと可読性に優れている。SensuのプラグインはRubyで書かれているから一部動作が重たい。Mackererlで扱うデータが複雑であることからPostgreSQLのJSON型を利用しており、MySQLにはないNoSQL的な側面をも利用している。
  • CPU使用率、ディスク使用率…等の基本的な監視項目とは何か、それに対する見方を学ぶことができた。(P101)
    • 監視項目の意味を漠然と理解している気はするが、サーバの仕組みと照らし合わせながら監視項目の意味を再確認することで、監視項目の意味と必要性が明確になった。
    • 各項目はどういったサーバの場合に注視するべきなのか整理できた。
    • 各項目の読み取り方、他メトリクスと組み合わせた状況把握の方法を知ることができた。
      例）loadavg5の上昇傾向を把握したいときに、そのボトルネックを探る目的でCPU使用率を確認する。CPU使用率の中でもcpu.user,cpu.sustem,cpu.idle…等色々な設定があり、各項目ごとに考えられる原因と対処法がある。

【4章：アラートを通知する】

  • アラートが必要十分に届くように通知先を設定することを知った。はてな社実運用の例があり分かりやすかった。(P122)
    緊急対応が必要ないアラートをあまり関係ない人のもとへ送るとアラートが無視されやすくなってしまうので、通知先の設定も考える必要がある。
    • 例）Slackにて、全てのアラートを送るチャンネル(インフラエンジニアのみ所属)、各サービスごとのアラートを送るチャンネル(ディレクターなども所属)を作る。各サービスのアラートを受け取るチャンネルではディレクター等もいるので、緊急性の低いアラートは送らないようにしている。

【5章：プラグインを作る】

  • 「初心者にはプラグイン作るなんて難しい」という固定概念が取り払われるいい機会だった。今回は機会がなかったが、「またの機会にプラグイン作ってもいいかも」というきっかけ作りになった。

【6章：各種ツール連携と運用の効率化】

  • Mackerel APIを用いてホストを一元管理することで、インフラ環境構築～テストまでをコードにして自動化できる。また、人のミスを減らしたり、属人化する部分を削減したりすることができる。
    • ChefやAnsibleでMackerelエージェントを自動的にインストールできるようにコード化(P176)
    • ServerspecにてMackrerl APIを用いてホスト名を取得することで、試験対象のサーバの作成や退役を気にせず動的にホスト名を取得し、試験のコードを書き換える手間を減らす。(P186)
    • Mackerelのロール名を指定することで、対象のホスト名をAPIで取得することができる。
      ⇒上記を用いて一斉にSSHログインすることなどが可能

【7章：クラウド環境におけるMackerel】

  • AutoScalingに合わせて(=OSシャットダウン時に)Mackerel監視を自動的に退役させることができる。(P235)
  • ホスト起動時、シャットダウン時にホストステータスを自動変更することで、コールドスタンバイ⇒アクティブに変更したときに自動的にMackerelの監視を行うことができる。(P236)

【8章：発展的な機能】

  • 1週間前のメトリクスと重ねて表示したり、1週間前のメトリクスとの差分も表示させたりすることができる。
  • 線形回帰によるディスク枯渇までの日数の将来予測が可能。
    中学校の数学で「関数の長所は将来的な予測が可能なこと」って教わったと思うんですよ（？）式や関数で表せることはメトリクスにできると考えると可能性が大きく広がっていますね…！

【9章：付録】

  • 実際の企業で使われている例が記載されていて理解が深まった。
    例）GMOぺポバの例では、Mackerelからホスト名とIPアドレスを取得してhostsファイルの更新を自動的に行っている。
  • 上記紹介してきたものが、Mackerelのどのような思想に基づいているか、なぜその思想が大切なのか話されている。
    • 例）監視対象が動的であったとしても、Mackerelを中核においてDevopsツールを用いることで、IaCをより推進できるようにしたい。

5-2.他の方の書評

本を買う時って、色んな人の書評を見て判断しますよね。自分もそうだったのでよく分かります。
自分がネットで見つけた書評をご共有します。

🔗書評リンク1
【書評】「Mackerelサーバ監視実践入門」 を読みました！

🔗書評リンク2
【書評】「Mackerelサーバ監視[実践]入門」Mackerelをイチから学びたい方にお勧めな一冊

6.Mackerelが選ばれる理由を知る

「せっかく勉強するならば多種多様な監視サービスの中でMackerelの特徴とは何か知りたい」と思い、もう少し勉強を進めました。

6-1.Mackerelの方へインタビューしてみて(2024年６月時点)

私はプリセールスエンジニアとして働いている側面があるので、MackerelだけでなくZabbixサーバを扱うこともあります。それゆえに、AWS Summit2024に行ったときにMackerelブースにて、Mackerelの良さを理解したく、競合他社と比べたときの売りをはてな社の方に実際にお聞きしたことがあります。そのときに、はてな社の方から実際にご回答いただいた売りは以下3点でした。

⭐Mackerelの売り-----------------------------------------------------------------

  • mackerelの監視したデータやmackerel自体をAWS東京リージョンに置く
    mackerelの監視したデータやmackerel自体をAWS東京リージョンに置いてあるので、コンプラ的にデータを海外に置きたくない要件がある企業さんには利点となります。

  • 丁寧なカスタマーサービス
    他の大手監視サービスは海外製が多いのでよくわからない言葉のやり取りになることが多いですが、mackerel担当者が迅速に（←ここ大切らしい）日本語で答えてくれます。
    自分も他の製品利用時に「急ぎや技術的にレベルが高い問い合わせは海外チームが対応します。」とのことで、サポート問い合わせ時に返信が遅かったり、雑だったりして困った経験があるので、非常に助かることだと思います。

  • GUIの使いやすさ
    デザイナーと連携しており、使いやすいものとなっています。実際に使ってみると感覚的に操作できる部分が多いので、非IT企業の情シスの方などが管理することを想定すると喜ばれるなと感じました。

6-2.クラスメソッドがMackerelを採用した理由(Youtube動画)

🔗Youtubeリンク：AWS監視サービスの基盤にMackerelを採用した理由　(約27分の動画です)

6-2-1.運用保守サービスをZabbixからMackerelに切り替えた…！

クラスメソッドの運用保守サービスとしてMackerelが使用されています。しかし、以前はZabbixを使用していたのにMackrerlに切り替えたそうです。それに伴い、選んだポイントや使ってみた感想が率直に話されていて勉強になります！実際に企業が監視を採用した理由は説得力があり沁みますね…。

⭐勉強になった or 印象的な部分 --------------------------------------------------

大切なポイントは沢山ありますが、個人的に特に勉強になったことが以下3点ありました。本記事内と繰り返しの部分が多いですが、具体例を知り理解が深まったので記載します。

  • Mackerel自体の障害等のサービス停止はクラスメソッドでの導入開始から2年間ほぼ聞かなかった。
    MackrerlがSaaSであることにより監視に対する管理工数(監視サーバに対する監視、ウイルス対策や冗長化…etc)が減ることは、書籍で理解していたのですが、「サービスが落ちることはないのかな」と疑問に思っていました。しかし、長期的に見てもMackerelのサービス停止はないみたいですね！

  • Zabbixと同様のことをシンプルかつ簡単に実現できる
    構成図を比較すると一目瞭然ですね！自分もZabbixのメールサーバ構築の案件に関わったことがあるのですが、Zabbixはメール通知するだけでもメールサーバを作る場合があるので、エンジニアの工数が減るということは大きいです…！！！

構成図比較


Zabbix採用時のクラスメソッド運用保守サービスAWS構成図

Mackerell採用後のクラスメソッド運用保守AWS構成図

  • ストレスなく扱える。
    ストレスなく使える要因には大きく以下の3つがあると考えます。

    • Mackerel開設に時間がかからずに導入できる。（早い人ならば手順を見ながら3分くらい）
    • UIも優れていて感覚的に使える。
    • 手順書や公式HPが日本語で書かれている

    Mackerelはサーバの監視だけに留まらず、サイトページのレイテンシ、PV数なども調査可能です。また、それらをサーバの情報と組み合わせて経営者の人たちと一緒に確認し議論することがMackerelの思想にあります。「Mackerel導入を勧める立場として、気軽に日本語で使えることは、Mackerelを快く提案できるメリットなんだな」と感じました。

7.その他（後から見返す時に便利そうなリンクまとめ）

今後Mackerel使用時に便利そうなリンクをここに置いておきます！

7-1.諸々の手順一覧(Makerel公式)

いちいち「Makerel 〇〇」とググるのも疲れます…。以下リンクから探したら少しは時短になるかもしれないのでご共有です。
https://mackerel.io/ja/docs/?utm_medium=email&_hsenc=p2ANqtz-9mQ53cugkMnG-uig9fanVc3r_LfQQ6QC5scEoD3xEW_gRBwv5gi_eYjdZUo6rfMajQ7dnB7_obd7NjmFAdzQxWMG7ZSlBoOPuJoOK5XEWEtsVWwu4&_hsmi=343373359&utm_content=343373359&utm_source=hs_automation#alerts

7-2.チェック監視のプラグイン一覧

サービス監視の部分でも紹介していますが、下記リンクの階層から探すと一覧が見られます～
https://github.com/mackerelio/go-check-plugins/tree/master

8.おわりに

学習終了後に感じましたが、「MackerelはSaaSで設定する要素が少ないから、監視を学ぶ第1歩として気楽に学ぶことができたな」と思い、「これから監視を勉強します！」という方にもおすすめできると考えました。 その一方で、Mackerelの仕様を知るだけにならぬよう、監視の見方・考え方を学ぶよう自分で注意を払う必要もあります。

まだまだ監視の勉強はスタートしたばかりなので、引き続き実践を通して勉強していきたいと感じました。何か技術的な誤りや監視の勉強にあたり良い書籍等あれば、どしどしコメントで教えていただけると助かります。

Discussion