オーガニゼーションあれこれ

この記事は、Mackerel アドベントカレンダー(全部CRE)の16日目の記事です。

先日、Mackerelには「サービス」と「ロール」という概念がある、という記事を書きましたが、実はさらに上位のグループに「オーガニゼーション」という概念があります。

オーガニゼーション?なんだっけ。いつつくったっけ?という方に、オーガニゼーションの見方、作り方、注意事項などもろもろご紹介します。

オーガニゼーションとは、日本語に訳すと「組織」のことです。 組織とは、大きな括りでは、会社だったり分割すれば部署やチームのことです。

オーガニゼーションはいつ作る?

初回ログイン時に作る

はじめてMackerelを使う場合は、まず サインアップ をします。

f:id:missasan:20181213191502p:plain

サインアップの次に行う必要があるのが、オーガニゼーションの作成です。

f:id:missasan:20181213191515p:plain

追加で作る

オーガニゼーションを追加でつくりたい、という場合は、左上のオーガニゼーション名の横にある[▼]をクリックし、[+作成]を選択して追加のオーガニゼーションを作成することができます。

f:id:missasan:20181215154352p:plain

オーガニゼーションにユーザを招待する

オーガニゼーションを作成すると、作成した人がそのオーガニゼーションのオーナーとなります。 オーガニゼーションには、他のチームメンバーや、Mackerelの画面を見せたい人を招待することができます。

オーガニゼーション名をクリックして表示される、オーガニゼーションの詳細画面で、[メンバー]タブをクリックします。 メンバー一覧画面の右上にある[招待する]ボタンから招待します。

f:id:missasan:20181215155337p:plain

オーガニゼーションに招待するユーザの権限

ユーザーに付与できる権限には以下の4つ種類があります。 詳細はヘルプにまとめられているので、そちらが参考になります。

  • オーナー
  • 管理者
  • 一般ユーザー
  • 閲覧者

ここで、一点注意があります。 ユーザー権限の中でもっとも弱い権限は、閲覧者=ReadOnlyですが、この閲覧者は、オーガニゼーションのすべてのサービスやロール、ホストの情報を見ることができます。 なので、たとえば特定サービスのみでだけ外部の開発会社に協力をお願いしているなどの場合に、その特定のサービスの閲覧権限を付与したいと思ってもそれはできません。 そのような場合は、協力会社の人が見るサービスごと、別のオーガニゼーションにする必要があります。 また、サービス、ロール、ホストは複数のオーガニゼーションをまたいで設定することができない、ということも注意が必要です。 オーガニゼーションを作成するときは、以下を念頭におきながら、どういうまとまりで作成するのか考えるとよいでしょう。

  • 閲覧権限をもつユーザは、オーガニゼーションに含まれるすべてのサービス、ロール、ホストの情報を見ることができる
  • サービス、ロール、ホストは複数のオーガニゼーションをまたいで設定できない

サービスとロールはオーガニゼーションをまたげない

オーガニゼーション一覧が見られるURL

たくさんオーガニゼーションを作っていると、もっと気軽にオーガニゼーションの一覧を見たり、複数のオーガニゼーションを行き来したりしたくなるかもしれません。 そんなときは、オーガニゼーションの一覧画面を見て見る方法があります。 方法は非常に簡単で、以下のURLにアクセスします。

このURLにアクセスるとあなたが所属しているオーガニゼーションの一覧をみることができます。 こんな感じに、オーガニゼーションのアラート数や、サービス数、ホスト数、所属しているメンバー数などの概要を一目でみることができます。

f:id:missasan:20181215162002p:plain

オーガニゼーションの詳細設定を見てみる

オーガニゼーションごとの詳細設定についても見てみましょう。[設定]タブで確認できます。

f:id:missasan:20181215205606p:plain

以下のような設定があります。いちどデフォルトの設定のままで問題ないか、確認してみることをおすすめします。

  • オーガニゼーションのアイコン
    • Gravatar で利用できるメールアドレスを設定することができます。
  • Host Statusの初期状態
    • 新規ホストのステータスを[working]か[standby]から選べます。デフォルトでは[working]です。
  • タイムゾーン
  • プラン
  • IP制限
    • オーガニゼーションにアクセスできるIP範囲のホワイトリストをCIDR記法によって設定します。
  • 招待メールアドレス制限
  • メール設定
    • オーガニゼーションに関連するメールを受け取るアドレスを設定できます。
  • アクセス可能な認証方式
    • missasan-org オーガニゼーションにアクセス可能な認証方式を設定します。
  • オーガニゼーションを削除
    • オーガニゼーションを削除したい場合はここから行います。

プランの利用状況を見る

Mackerelでは、オーガニゼーションごとに利用料金を算出しています。 Freeプラン、Standardプランなどの利用プランを選択するのも、オーガニゼーション単位になります。 Mackerelでは、基本的にはホスト台数ベースでの課金となりますが、メトリック数や外形監視項目数が超過している場合は、追加料金が発生する場合があります。

mackerel.io

課金に影響するようなホスト台数やメトリック数などを現在どの程度利用しているかを確認することができます。 オーガニゼーションの詳細画面の[プラン]タブで確認できます。

f:id:missasan:20181215210852p:plain

オーガニゼーションについて普段であればそれほど意識することはないかもしれませんが、意外といろいろな設定がありますね。

カスタマイズしたグラフをつくってみよう

この記事は、Mackerel アドベントカレンダー(全部CRE)の14日目の記事です。 今回は、Mackerelで取得したメトリックを使って、カスタマイズしたグラフを表示する方法についてまとめます。

先日紹介した、システムメトリックや、カスタムメトリックは、基本的には、ホストの詳細画面や、サービス詳細画面のロールグラフとして、決まったフォーマットで表示することができますが、関数を書くと、取ってきたメトリックを自分が表示したいグラフにカスタマイズして表示することができます。 ここでは、入門的にものすごく簡単な式を書いてみたいと思います。

やってみようカスタマイズグラフ

カスタムダッシュボードをつくる

まずは、カスタマイズグラフを並べるためのダッシュボードをつくります。 [Dashboard] - [カスタムダッシュボードを追加] から新しいダッシュボードをつくることができます。

f:id:missasan:20181208190459p:plain

ダッシュボードにグラフウィジェットで式グラフを追加する

ダッシュボードにグラフウィジェットを追加します。 ダッシュボードの編集画面で、左上にあるグラフウィジェットマークをドラック&ドロップします。

f:id:missasan:20181208190524p:plain:w450

追加するウィジェットの[グラフのタイプ]は[式グラフ]を選びます。 カスタマイズしたグラフを表示したいときは、この式グラフというものを使います。

f:id:missasan:20181208190543p:plain:w450

f:id:missasan:20181208190821p:plain

簡単な式を書いてみる

まずは、関数を使って、特定のホストの特定のメトリックを描画してみます。

利用する関数はhost(hostId, metricName)です。 ホストIDは、以下のホストの詳細画面から取ってこられます。

metricNameは、私はいつも別タブで監視ルールの新規監視ルールを作成画面を開いておいて、検索窓で検索しています。 (もっとよいやり方があるかもしれません。。)

単純に特定ホストのloadavg5のグラフを表示するなら、こんな感じです。

host(
  [hostid],
  loadavg5
)

式がうまくかけると、式を入力する窓の右上がグリーンのチェックに変わります。 さらに、グラフが表示されます。

f:id:missasan:20181208190954p:plain

これを見ながら、式を書いては、きちんと表示されるかを確認するという作業を繰り返しながら少しずつつくっていきます。

特定のメトリックを指定して合計してみる

せっかくなのでわたしが最近つくったグラフを参考例としてあげて見ます。 たとえば、以下のような条件で、グラフを見たい時には関数を使う必要があります。

  • やりたいこと

    • 各サーバーのサービス用途のインターフェースを指定してトラフィックの合計が見たい
  • 条件

    • サーバーにはインターフェースが2つ接続されていて、ひとつはサービス用途、ひとつは管理用途に利用している
    • 物理サーバーを利用しており、サーバーごとにインターフェース名が異なっている

それでは関数を書いていきましょう。 関数を書く前に必要なものをそろえます。 別のグラフをつくる場合は、レシピも変わりますが、今回はこんな感じです。

  • 対象のホストID
  • メトリック名:interface.[インターフェース名].txBytes.delta
  • 使う関数:host(hostId, metricName), group(metrics, metrics, ...), sum(metrics)

利用する関数は、ヘルプページからある程度あたりをつけておくことがおすすめです。

まずは、2つのホストのメトリックを group(metrics, metrics, ...) で1つにまとめます。

f:id:missasan:20181208191147p:plain

このままだと重ね合わせのグラフになってしまうので、合計値の1本のグラフを表示したいです。 そこで、 sum(metrics) 関数を使って、1つにまとめたグラフを合計します。 すると以下のように1本のグラフで表示されます。

f:id:missasan:20181208191208p:plain

と、こんな感じで自分の好きなグラフをつくることができます。

まとめ

  • やりたいことを明確にする
    • どのメトリックつかう?
    • メトリック名は?
  • 使えそうな関数を探す
    • いくつかのメトリックをまとめる必要がある? → group(metrics, metrics, ...)
    • 合計、平均 をとる → sum(metrics), avg(metrics)
    • 定数倍、定数足す → scale(metrics, factor), offset(metrics, factor) などなど。関数は他にもいろいろあります。

できればロールグラフなど標準で見られるもので済ませたいところですが、どうしてもそれだけではまかなえないものについては式監視などを活用したいです。 あとは、うまくかけて、きちんと表示できると達成感もあるので、けっこう楽しいですよね。

半分は折り返したけどストックも切れてきました。残りは週末の私におまかせしよう。

トライアルプランで試してほしいこと

この記事は、Mackerel アドベントカレンダー(全部CRE)の12日目の記事です。 今回は、Mackerelにはじめてログインしたトライアルプランの人にぜひ試してみてほしいこと一覧をまとめてみようと思います。

リストは思いついたら足していく方式にしようと思います。便利URLまとめ記事みたいな感じになりました。

メトリックを取得する

特に、AWSインテグレーション / Azureインテグレーションは無料プランでは利用できないので、ぜひ試していただきたい機能です。

などなど

障害を通知する

ハンズオンなどでもよくやる擬似的に負荷をかける方法は、CPU%などの監視ルールを設定し、yes > /dev/null コマンドを実行するというものです。 手軽に短い時間でアラート検知や通知を試すことができます。 サーバーをシャットダウンしたり、mackerel-agentのプロセスを停止して、connectivityアラートを発報してみるのもお手がるです。

日々の運用で使いこなす

もっとMackerelを使い倒す

おもしろ

以上です。 次回は、このリストにも含めているカスタマイズしたグラフの表示方法について、まだ書き慣れていない人向けにめちゃくちゃ簡単にまとめてみます。

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

この記事は、Mackerel アドベントカレンダー(全部CRE)の10日目の記事です。 今回は、Mackerelでアラートを通知する方法についてまとめます。

通知に関わる設定には、2つあります。 一つめは、誰に何で通知するかという「通知チャンネル」。もう一つは、どのサービスに関するアラートをどの通知チャンネルに通知するかという組み合わせを設定する「通知グループ」です。

通知チャンネル

通知チャンネルでは、以下のようなものが選べます。

f:id:missasan:20181201150337p:plain

よく使うチャンネルをいくつか紹介してみます。

  • メール通知
    • Mackerelに登録のあるユーザのメールアドレスや、任意のメールアドレスを設定できます。
    • たとえば、エンジニアチームのメールアドレスと、ビジネスチームのメールアドレスにそれぞれアラート通知を出し分けたい、というような場合は、メール通知の通知チャンネルを複数作ります。
  • Slack
    • Slack APIの1つであるIncoming Webhooksを利用します。
    • 通知したいSlackチャンネルのURLを取得して設定します。
    • ヘルプはこちら
  • Twilio
    • Twilioで取得した電話番号に通知することができます。メッセージは標準では固定です。
    • ヘルプはこちら
  • Webhook
    • Webhookを利用して他のアプリケーションを実行することができます。
    • ヘルプはこちら

通知グループ

通知グループには、デフォルトで、Default という通知グループがあり、すべてのサービスに関するアラートが、登録されているメールアドレスに通知される設定が入っています。

f:id:missasan:20181201154018p:plain

実際のケースではどう使う?

サービスごとに通知先をわけたい

  • 通知先ごとに通知チャンネルを作ります。
  • サービスごとに通知グループを作り、それぞれ通知したい先の通知チャンネルを設定します。
  • デフォルトの通知グループから該当の通知チャンネルをオフにする。

f:id:missasan:20181201160544p:plain

外形監視などクリティカルな監視ルールに関してだけ、ビジネスチームにも通知したい

  • ビジネスチーム用の通知チャンネルを作ります。
  • 通知グループでは、「通知対象」を選ぶ箇所で外形監視を選び、ビジネスチーム用の通知チェンネルを追加する。
  • デフォルトの通知グループから該当の通知チャンネルをオフにする。

f:id:missasan:20181201160556p:plain

通知を飛ばないようにしたい

通知は基本的には、飛んできたら人が対応しなければなりません。 障害やメンテナンスにあたって、一時的に通知を止めておきたいというときや、特定の監視について、状況を把握するためアラート一覧への起票はしておきたいけれども、通知までは不要というものがあったときに、どのような方法があるかをまとめてみます。

通知全体を止める

通知全体を止めるには、監視ルール一覧画面の上部で、時間を指定して設定することができます。

f:id:missasan:20181201161130p:plain

特定の監視ルールの通知を止める

サービス影響はないバッチサーバーのリソース監視などアラート一覧では確認したいが、通知まではしなくてよいというような、通知全体ではなく、特定の監視ルールに関してのみ通知を止めたい場合は、監視ルール一覧画面の各ルールの左横のミュートボタンで設定できます。

f:id:missasan:20181201161421p:plain

または、監視ルール詳細画面にて時間を指定して通知を停止することができます。

f:id:missasan:20181201163237p:plain

特定のホストの通知を止めたい

ホストの詳細画面や、ホスト一覧画面などで、ホストのステータスを「Standby」にすることで通知を停止できます。

f:id:missasan:20181201163555p:plain

f:id:missasan:20181201163654p:plain

ちなみに、「Maintenance」や「Power Off」にすると、アラート一覧への起票自体も停止できます。(つまりメトリックは取得するけれども、監視ルールの適用外とする、ということです。)

その他

ホストステータスの変更などのイベント通知を設定する

SlackやWebhookなど一部通知チャンネルで、ホストステータスや監視ルールの変更などのイベントを通知対象として選択できます。

mackerel.io

f:id:missasan:20181209131142p:plain

この機能も意外と気づいていない人もいるかもしれません。

通知まわりはなかなか奥が深いです。 やっと基本の概念まわりについてまとめられたので、次は、Mackerelにはじめてログインしたトライアルプランの人にぜひ試して見てほしいこと一覧をまとめてみようと思います。

監視ルールとチェックプラグイン

この記事は、Mackerel アドベントカレンダー(全部CRE)の8日目の記事です。 今回は、Mackerelでサービスの異常に気づくための監視ルールと、チェックプラグインについてまとめます。

2つの設定方法

Mackerelでサービスの異常に気づくための設定方法には大きく2つあります。

一つはMackerel管理画面で設定する方法。もう一つは、サーバー上で設定する方法です。

Mackerel管理画面での設定は「監視ルール」にあたります。サーバー上で設定する方法は「チェックプラグイン」を使う方法です。どちらも、どういった状態を満たしたときに、それを異常とみなすか、という条件を設定するための方法です。それぞれできることが違うので、やりたいことに応じて方法を選びます。合わせて使うこともよくあります。

条件を満たして異常と判断された場合はアラートとして、アラート一覧画面に起票されます。

監視ルールを設定する

監視ルール一覧画面で設定できます。 監視ルールには、以下のような種類があります。

メトリック監視

  • ホストメトリック監視
    • ホストのシステムメトリックやカスタムメトリックに対して、Warning / Criticalといった閾値を設定する
  • サービスメトリック監視
    • サービスメトリックに対して、Warning / Criticalといった閾値を設定する

死活監視・外形監視

  • ホスト死活監視
    • デフォルトでは「connectivity」という名前
    • エージェントから一定時間メトリック投稿が途絶えるとアラートとなる
  • 外形監視

その他

  • 式による監視 (「実験的機能」がオンのときのみ)
    • 関数を使ってカスタマイズしたメトリックに対して、Warning / Criticalといった閾値を設定する

チェックプラグインを活用する

チェックプラグインを利用すると、メトリックとして投稿しにくいもの(数値の推移では表わしにくいもの)なども監視することができます。 これは、メトリックを取得するためのプラグイン同様、エージェントがインストールされたサーバー上にインストールして使います。

mackerel.io

サーバーの状態を条件に基づいてチェックして、OK、NGをMackerelに送ります。 NGを受け取った場合は、アラートとして起票されます。

こんなときはどれを使う?

こんな監視したいなあ、というときに何を使うとよさそうか、ぱっと思いついたものを例に書いてみます。

  • サイトトップページが見えているかどうか確認したい
    • 外形監視を使います。そのページに必ず表示される文字列などがあれば、レスポンスボディの文字列チェックをします。
  • URLごとのレスポンスタイムの平均が1秒を超えたら検知したい
    • メトリック監視を使います。
    • mackerel-plugin-accesslog を有効にし Latency のメトリックを取得します。取得できたメトリックに監視ルールで閾値を設定します。
    • この場合は、アクセスログにLTSVログフォーマットでレスポンスタイムを出力する必要があるので、ログフォーマットを確認します。
  • 500番台のエラーレートを監視したい
  • サーバーのCPUやメモリの使用率に閾値を設定したい
    • エージェントが取得したシステムメトリックをもとにメトリック監視を設定します。
  • サーバー上で動くプロセスの死活監視がしたい
  • 特定のログのエラー文字列が1分間に何回出たか監視したい
    • チェックプラグイン check-log を使い、--warning-over --critical-over などのオプションを使います。
  • MariaDB(MySQL)への接続状況を確認したい
  • SQSのキューのタスクがさばけているかを監視したい
  • AWS CPUクレジットが0になる前に検知したい
  • ファイルのタイムスタンプを監視したい

というように、システムメトリックや、カスタムメトリック(メトリックプラグイン)、監視ルール、チェックプラグインなどなど使いこなすといろいろな監視ができます。

次回は、アラートをどうやって通知するのか、という「通知」の部分についてまとめます。

メトリックの種類

この記事は、Mackerel アドベントカレンダー(全部CRE)の6日目の記事です。 今回は、Mackerelで取ってこられるメトリックの種類と簡単な概要についてまとめます。

Mackerelでは、まずはメトリックを取ってくることから始まります。 メトリックを取得する方法はいくつかあります。

システムメトリック

Mackerelのエージェントをメトリックを取得したいサーバー上にインストールすると、エージェントが標準でいくつかのメトリックを取得してきます。項目はOSによってことなりますが、たとえば、ロードアベレージ、CPU使用量、メモリー使用量、ディスクIO、ネットワークインターフェースの使用率、ファイルシステムの容量などが取得できます。 これらのエージェントが標準で取得するメトリックをシステムメトリックと読んでいます。

f:id:missasan:20181130144154p:plain

カスタムメトリック

Mackerelには、OSやミドルウェアに特化したより詳細なメトリックを取得するための公式のプラグインがたくさんあります。

mackerel.io

インストールはとても簡単で、Linuxサーバーなら yum コマンドでインストールできます。 Windowsサーバなら、よく使うものはエージェントに同梱されています。 このプラグインを利用して取得されたものは、Mackerelではカスタムメトリックとして扱われます。

f:id:missasan:20181130144114p:plain

ちなみに、ホスト上のエージェントを介して取得できるこれらシステムメトリック、カスタムメトリックを合わせてホストメトリックと呼ぶこともあります。

サービスメトリック

システムメトリックやカスタムメトリックは、エージェントを介して投稿され、エージェントが動くホストに紐づくメトリックです。 サービスメトリックは、エージェントを介さずにMackerelのAPIを利用して投稿するメトリックになります。 メトリックを投稿する際は、投稿する先のサービスを選びます。

サービスメトリックは、以下のようにサービス詳細にて確認できます。

f:id:missasan:20181130144638p:plain

この例は、HTTPのレスポンスタイムですが、他にも、PVやビジネスのKPIなどアイディア次第でいろいろなメトリックをMackerelに投稿、グラフ描画できます。 APIを実行する場所も、サーバー上でアプリケーションを動かしたり、AWS Lambda や GAS などサーバーレスで実行できるサービスを利用したりと方法は問いません。

まとめ

f:id:missasan:20181204010357p:plain

  • システムメトリック:mackerel-agentが標準で取ってくるメトリック
  • カスタムメトリック:mackerel-agentのpluginで取ってくるメトリック
  • サービスメトリック:ホストに依らないAPIを叩いて投稿するメトリック

次回は、Mackerelでサービスの異常に気づくための監視ルールと、チェックプラグインについてまとめます。

サービスとロールが効いてくるところ

この記事は、Mackerel アドベントカレンダー(全部CRE)の4日目の記事です。 今回は、サービスとロールがMackerelの中のどういったところに関わってくるのかについてまとめています。

Mackerelでの管理の単位はサービスとロール

Mackerelでは、あらゆる設定にサービスとロールを使います。 グラフの描画、監視ルール、通知など基本的な機能はもちろん、アラートグループといった新しい機能でも設定の単位はサービスとロールです。 これから新しく増える機能もサービスとロールと紐づいて設計されていることが多いと思うので、どういうふうにこの2つの概念が使われるのかをおさえておくとMackerelの設定を考える上でとても便利です。

ロールでまとめる見る「グラフ」

ロールグラフ

Mackerelでは、取得してきたメトリックをグラフ描画することができます。 グラフの見方にもいくつか種類があるのですが、その中でも、「ロールグラフ」はサービスとロールを設定してはじめて描画されるグラフです。 ロールに紐付けをしたホストの各種メトリックが、ロールグラフの中で、重ね合わせだったり、積み上げのグラフで見ることができます。

カスタマイズしたグラフ

また、Mackerelでは、関数を使ってカスタマイズしたグラフを表示することもできます。 ここでも、ロールが効いてきます。 たとえば、ロールに含まれるホストメトリックの平均をとったり、ロールに含まれるホストメトリックの中の最大、最小を取り出したりすることができます。 つまり、WebサーバーやDBサーバーの平均や最大・最小の負荷を見ることができるのです。 その際に使う関数は role(roleFullname, metricName) です。 関数には他にもいろいろあるので、ぜひヘルプをご覧ください。

ロールグラフをダッシュボードに

これらのロールグラフや、カスタマイズしたグラフを、カスタムダッシュボードに並べて、毎日システムの状態を眺めたり、月次のキャパシティプランニングの場で使ったりすることもできます。 「Webサーバーにもう3台追加しよう」とか「DBサーバーのメモリ足りてないんじゃない?」というようなロールを主役にしたそれにフィットしたグラフを見ながらみんなでワイワイ会話することができます。

サービスやロールに「監視ルール」を適用

監視ルールとは、取得してきたメトリックに対して、何を障害とみなしアラートとするかを決める"条件"にあたる設定です。 条件は、たとえば「CPUの使用率が70%を超えたらWarning」というようなものです。監視の世界では、一般的にあるような設定ですよね。 Mackerelの一つの特徴とも言えるのは、この監視ルールをサービスやロール単位に設定できるというところです。

f:id:missasan:20181129140347p:plain

スクリーンショットの例では、監視ルールがそれぞれ以下のとおりに適用されています。

  • CPU% は「sample-service」サービスの「sample-rore」ロールにのみ適用
  • filesystem は「すべて」のサービスに適用
  • connectivity は「すべて」のサービスに適用、ただし「missasanbook」サービスについては除外

なので、このようにサービス、ロールを指定してうまく監視ルールを作っておけば、ホストを適切なサービス、ロールに所属させればすぐに監視ルールを適用させることができます。 サーバを1台構築したからといって、CPU、メモリ、ディスクなどそれぞれの監視ルールを都度設定しなくてもよいので楽ちんです。

Mackerelでは、どのサービス、ロールに所属させるかはエージェントの設定ファイルに書いておくことができます。

サービスにごとに「通知」先を指定

通知とは、起票されたアラートをメールやslackなど人が気が付ける方法でお知らせする仕組みです。 この通知の設定でも、指定したサービスに関わるアラートについては、どこに通知する、といった設定ができます。

f:id:missasan:20181128193625p:plain

この設定では、全てのサービスに関わるアラートをslackに通知しています。

サービスとロールがかかわるその他の機能

アラートグループ

アラートグループというアラートを同時間帯にまとめる機能があります。 これを、まとめる単位もサービスとロールです。

f:id:missasan:20181128194954p:plain

フィルタ

各種フィルター機能を使うときにも、サービスとロールが活躍します。

f:id:missasan:20181129124136p:plain

いかがだったでしょうか。とにかくいろんなところで登場するんだなーということは伝わったのではないでしょうか。 次回はMackerelで取ってこられるメトリックの種類と概要についてまとめます。