空前の自炊ブーム

自炊ブーム、定期的に訪れています。

今回の自炊ブームのきっかけは、風邪を引いたこと。寒くなって乾燥してきて、周囲に風邪を引いている人が増えていたので、とにかく暖をとるべく膝掛けやらヒーターやらベットカバーやら買って温まったり、家では冷たい水やジュースではなくお茶を飲む、うがいする、マスクする、早く寝る、R1飲むみたいなことをけっこうやったのに、結局風邪を引きました。

寝込みながら、これはもう、あとは食事と運動では、となって、とりあえず、食事のほうから改善をはじめたしだいです。

前回のブームは前職にいたときのお弁当ブームで、500kcal以内のお弁当を作って持参するということをやっていましたが、あまり続きませんでした。 (今は、はてなランチがあるので、昼の自炊は考えなくてよくてハッピー)

自分が自炊が続かない理由TOP1はもちろん「めんどくさい」ですが、TOP5くらいには入りそうな理由に、自炊による健康効果が見えにくい、というのがあります。 頑張って自炊したところで、痩せるでもなく、元気になるでもなく、めんどうになってやめる、というのがこれまでのパターンです。

ただ、今回はちょっと違ったので、報告です。

なんとなく健康効果がある気がしている

あくまでなんとなくですが、以下のような感じがしています。

  • わりと疲れにくい
  • お腹の調子がよい
  • 朝起きたとき疲れてない
  • お菓子そんなに食べたくならない
  • ジャンクそんなに食べたくならない

若さの貯金が切れて、なんともならなくなった分、こういう活動の効果が見えやすくなったんでしょうか。

特に下二つが顕著な気がしてます。 普段さんざんお世話になっているコンビニにあまり立ち寄らなくなったことが地味にうれしいです。まあまあ課金していたというのと、ほぼ私の体はコンビニでつくられています。と言うくらい頼りにしていたので。最近のコンビニはメニューも豊富でおいしくてすばらしいですよね。 自炊ブームがきてからは、立ち寄っても追加食材をちょっと買うくらい。

めんどくさいも減らしてみた

なんども言ってしまいますが、自炊が長続きしないTOP1はめんどくさいからです。 めんどくさいにもいろいろありますが、私の場合、そもそも買い物がめんどくさい、というのもあります。 これを少しでも楽にするために食材お届けサービスを試してみました。 結果を先に言うと、今のところサイコーです。

Oisix のお試し

比較するならここかなーというところの、大地を守る会、らでぃっしゅぼーや経営統合して、今やみんな仲間じゃん、という感じ。

www.oisix.com

お試しセットの感想は、とにかくサイコーじゃん、です。 野菜がめっちゃうまい。うまい気がする。 スーパーで買った野菜と合わせて何品かつくっても、今日の晩御飯のイチバンは味噌汁のカブだったね。というくらい野菜が主役の座をぶんどっていく感じがします。

味はサイコー、体験もサイコー。みんなぜひお試しセット頼んでみてほしいです。 ただ、お値段は日常使いするには悩ましいところでした。

イトーヨーカドーのネットスーパー

そこで、次に試したのが、こちらです。

www.iy-net.jp

食材に限らず、調味料なども商品数が豊富で、頼もしい。 お値段はスーパー価格を維持。配達料もまあよいか、という範囲。

Oisixのような野菜の味で体験を爆上げするような力強さはないですが、スーパーで何買う?何作る?とぶらぶらして、重い荷物を持って帰るという仕事がなくなるだけでも十分です。

なぜ、イトーヨーカドーにしたかというとセブンイレブンで受け取りができると目にしたから。それなら平日の夜も受け取れるじゃん、となったわけです。 しかしまだやり方がわからずで、ことの真偽もまだわかっていません!(調べようよ、という感じ)

ともあれ、このサービスのおかげで、土曜日の早めの時間帯にやまもり食材を受け取りして、週末はしっかり自炊して、平日も野菜を消費したいモチベーションで適度に自炊ができています。もちろん予定によっては外食もします。

とにかく、ネットスーパーのよさは、移動中とか空いた時間にちょいちょいと買うもの選べるところ。 実際にスーパーにいくわけじゃないから、重いとかそういう理由で買うものを制限せずに一度にどかっと買える。 カゴもって歩き回ったり、持ち帰るということがなくなるだけでこんなに買い物をする心にゆとりができるんですね。ネットってすばらしいですね。

まとめ

  • 自炊ってよい
  • 食材配達はブレイクスルー
  • Oisixの野菜は主役級にうまい
  • ネットスーパーは移動時間に食材選べる

なまけものが自炊続けるのってむずかしいですが、いろいろ便利な世の中になってたすかるねって話でした。しかし、なまけものはなかなか治らないので、またブームが去るときがくるやも。自炊ブームとかいってないで、いい加減生活しっかりしないさいって感じですね。

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

この記事は、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でサービスの異常に気づくための監視ルールと、チェックプラグインについてまとめます。