Mackerel アドベントカレンダー(全部CRE)やってみた

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

クリスマスイブですね。

さて、Mackerel CREチームでは、この度全部CREでアドベントカレンダーをやってまいりました。

ブログという形で、日々文章を書いてアップし続けた経験ははじめてです。 最後は、アドベントカレンダーをやってみた感想をつらつら書いて終わりたいと思います。

まずはやってみる

はじめにid:a-knowさんに「今年も全部CREやろうと思うんだけどどう?」と言われたときは、いやー無理だろうと思いました。 Mackerelのアドベントカレンダーといえば、毎年すごいエンジニアの人が手を変え品を変え、面白い記事をアップしているものだし、前年のid:Soudaiにいたっては、毎日Mackerelのプラグインについて解説を書くというとんでもない所業をしでかされていた後だったので。 でも無理と思うようなこともできたらいいなと思うことはまずはYESと言ってみる、というスタイルで暮らしているところがあるので、今回もまずはトライしてみたという次第です。

実際にお題を考えたり、ブログを書き貯めたりすることはけっこう大変でしたが、最初に思考停止してYESと言ったおかげで、この体験をやってみることができてかつ最後までこれたのでよかったです。

2日に1回ブログ投稿する

高頻度のブログ更新のためにやったことはこんな感じ。

お題は先に決める

2日に1回ブログを投稿するために、まずは目次を書き出しました。 その日その日にお題を決めていくのは、難しいと持ったので、はじめにあたりをつけておく作業です。 自分が普段こういうものまとめたいなーとか、自分のなかで一度きちんと整理したいなーとか思っていたことを書き出しました。 それが、精査されて、アドベントカレンダーの記事になっています。

自分が今かけるものを書く、すごい記事を目指さない

途中までは、ばくぜんとすごい記事を書かなければ、と思っていました。ところが、すごい記事とはいったい…となってぜんぜんネタが思いつきません。思いついてもそれやるには結構準備や勉強が必要で、そもそも間に合わないのではと思うものばかり。投稿日が近づいた頃、やっと、自分が今かけるものを書こう!憧れるクオリティをめざすまえにやり遂げねば!と開き直ることにしました。ここにたどり着けてよかったです。

探せばヘルプに書いてあるようなこともあるし、誰かがもっとうまくまとめていることもあるかもしれないけど、そういうことじゃないんじゃないかと。 CREは実際に対面でことばでMackerelのあれこれについて説明することが多いです。どこかに書いてあったら説明できるかということそうではないし、自分の言葉でまとめることに意味があると思いました。

毎日ちょっとずつ満遍なく書く

目次が決まってからは、一個ずつ仕上げるのではなく、全部の記事を毎日ちょっとずつ満遍なく書いていきました。

最終的には今自分が本当に書きたい、あったら便利なお題にできたので、比較的に筆が進んで、あとは週末にコツコツ書き貯めたりしてなんとか2日に1回投稿することができました。 この一連の記事、自分ではけっこう満足しています。

毎日のご飯のように書く

先日、Mackerelとはまったく別件で、自炊する話についてブログを書きました。

自炊にはまりながら、料理の本を読んでいました。

この本の第1章にあたるところの最初のタイトルが秀逸です。

夕飯作りの「敗北宣言」をする

手の込んだものを作ることは大変だけどおいしいご飯は食べたい。そういう夜は、敗北宣言をして、ちょっとしたメソッドにしたがって手間のかからないご飯をつくっておいしく食べるというのがこの本のコンセプトです。私のアドベントカレンダーへのマインドに近いので、おもしろいです。

これ以外にも、うんうん頷きながら読めるフレーズがいくつも登場します。自分に刺さったエッセンスを書いておきます。本文そのままではなく、私の解釈です。

  • 構成するもの少なくてもいい
  • こうしとけば絶対においしい、という型をつくる
  • レパートリーは少なくてよい
  • 余計なことをしない

こったものでおもてなしするわけでなく、自分にとって絶対おいしいものを続けられる範囲でつくろう、というマインドがまさに今の自分にぴったりでした。 こういうことって、いろんなことに応用が聞く、なにかを続けるコツなのかもしれないな、と思いました。

というわけで、自分の晩ご飯のようにアドベントカレンダーを書いてしまいました。

最後に

ブログっていいですね。 みんが見られるところに、自分のための記事を書いていることによって、よい効能がいろいろありました。

  • 自分の関心ごとがわかる、人に伝わる
  • 物事への自分の理解度がわかる、人に伝わる
  • 自分の周囲の人との共通言語がうまれる

いちばん新鮮だったのは、はじめてお会いするお客様に、その日の打ち合わせで時間内にどこを重点的にご紹介したらよいか、という質問に「今日集めたメンバーはブログの記事に書いておられたようなことまではなんとなく理解しているメンバーです」と言ってもらえたことです。 こんなふうに社外の人と、ブログの内容をベースに話ができるようになるのか、と目から鱗でした。

直接Mackerelには関係ない感じでラストの記事を書いてしまいました。 自分の晩ご飯のような記事を読んでくださったみなさま、最後までお付き合いいただきありがとうございました。

CREになって考えていることや読んでいる本など。

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

いよいよネタも尽きてきたので、今日は本当にライトなネタです。

先日、MackerelプロダクトオーナーのSongmuさんがex-KAYAC Advent Calendar 2018に向けてこんな記事を書かれていました。

blog.song.mu

その中で、MackerelのMVVについて触れられています。 そのまま引用します。

  • ミッション
    • クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する」
  • ビジョン
    • DevOps中核サービスのデファクトとして進化しつづける
    • サービス監視・運用の価値を高め、面白くする
    • 顧客のサービス成長を加速させる
  • バリューズ
    • Infrastructure as Codeを体現する
    • devops文化を根付かせる
    • ドッグフーディング
    • エンジニアをワクワクさせる
    • OSSエコシステムと共生する

このビジョンのおもしろいところ、というか個人的に興味が惹かれているところは、Mackerelが冠としては「サーバー監視ツール」でありながら、バリューの中には「devops」というカルチャーについてのエッセンスが含まれていることです。

このことが気になってしょうがないので、最近はそればっかり考えているような気がします。 あまりさっと本質にたどり着ける器用な人間ではないので、いろいろな本や社内外の事例などをみたり、先輩に教えを請いながら右往左往して少しずつ頭の中に絵が描かれていっているという具合です。

ちょっと調べてアウトプットして、数日後何かを学んで見直すと、全然わかってないじゃん!というのを繰り返す日々。こういうのは楽しい。

Mackerleで、devopsを根付かせるっていったい何をどうやったらいいんだろう?というのはMackerelチームにいながらもいつも考えている課題です。

これを考えていくためには、いろいろ勉強する必要があるなあと感じています。

とはいえ、まずはdevopsそのものから。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOps教科書

DevOps教科書

ツールについて、カルチャーについて、いろいろな切り口があります。 先日Mackerel Drinkupを開催した際には、参加者の方と「devopsは変更に関する意思決定を早く、効果的にする手法」ということではないか、というは会話したりしていました。よりよい変更であること、それがはやくできる、ということはdevopsにとって重要なキーワードになりそうです。すごく印象に残りました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE本は今運用ということについて考えるときに非常に学びの多い書籍です。 信頼性を高めるのではなく、コントロールする、という考え方が新鮮です。devopsということとSREということがどういった関わりをもつか、ということについてはまだまだ私の中で整理ができていないですが、「SREはdevopsを実現する具体的な手法のひとつ」とおっしゃられていた人もいるので、どちらも合わせて勉強していきたい概念です。

最近、私はMackerelでの運用設計のベストプラクティスをどうやってつくったらどうかということについてもずっと考えていて、そのための、特にモニタリングとインシデント対応については以下の本を参考にしています。

Webエンジニアが知っておきたいインフラの基本

Webエンジニアが知っておきたいインフラの基本

ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)

ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)

どちらも私の前職の先輩方々の教えです。

そして、いよいよ発売される以下の本も非常に楽しみにしています。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

CREをしていて思うのは、本当にMackerelのユーザにはいろいろな人や企業がおられるな、ということです。

オンプレを運用されているところもあれば、クラウドに移行中のところもあり、クラウドを使いこなし、次はマイクロサービスをうまく運用していくことに目を向けられているところもあります。

devopsの文化に関するところついても、1つのチームで開発からインフラまですべてを見ているところもあれば、開発チームとインフラチームが別個に動いているところ、SREsがいるところ、それぞれの形態のチームが混在しているところ。様々です。

運用設計といっても、何がベストプラクティスになるのかは、こういったシステムや組織の状況によってきっと異なると思っています。

それぞれのユーザの方がどんなフェーズにおられて、今後どういう組織や運用を目指されているのか。 どんな段階を経て、その目指す姿に近づいていくのか。Mackerelというツールやチームがその変化に対していったいどんなお手伝いができるのかというのが、気になってしょうがいない今日この頃です。しかしまずは勉強ですね。

まだこのあたりのことについてきちんと自分なりのアウトプットできるところまで整理できていないので、来年またアウトプットできたらいいなと思います。

ネタがつきたといいながら、結果、来年の抱負のようなエントリーになったなあ。

アラートグループを設定してみる

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

みなさんはアラートグループは利用したことはありますか? 今日はアラートグループの設定方法や通知方法についてまとめてみます。

アラートグループとは

アラートグループとは、サービスやロールごとに同じ時間帯に発生したアラートをグループとしてまとめる機能です。

ユースケース

たとえばゲームシステムなどwebサーバーを何台も横並びにして負荷分散しているような環境をイメージしてください。 webという同じロールに200台などのサーバーが登録されています。かつそのwebサーバー群は同じデータベースサーバーに接続にいっているとします。 そのような状況で、データベースサーバーに障害が発生したとしたら、200台からデータベースへの接続エラーのアラートが一斉に送信されてしまいます。

アラートが大量に発生してしまうと以下のような弊害があります。

  • 大量のアラートを確認するために時間を割いてしまう
  • データベース接続エラー以外の重要なアラートが埋もれてしまう

また、このようなことが頻発すると、アラートを見ると人がアラートに慣れてしまって、重要性だという感覚が鈍ってしまう、という弊害もあります。

このような大量アラートをうまく管理するための機能としてアラートグループが開発されました。

思わぬ効能

アラートグループはこのように、同じロールに大量のサーバーが登録されているようなケースを想定して開発されました。では、ロールに登録されているサーバーが少ない場合や、そもそもサービスに登録されているサーバーが少ないような環境では意味をなさないか、というとそうでもありません。 各サーバーが共有するネットワークやストレージなどに障害があった際や、データベースサーバーに限らずDNSサーバーやログサーバーなど各サーバーが共有する機能に障害がおこったときも200台とはいわずとも、たくさんのアラートが発報されます。 または、サーバーの処理量が増加して、リソース監視の閾値ギリギリをふらつくような事象がおきたときに、同時にアプリケーションログにエラーが出力されているような場合もあるかもしれません。 このような時にも、アラートグループは同時間帯に起きたアラートの可読性がよいので便利です。

アラートグループの設定方法

アラートグループは、アラート一覧画面から設定します。 右上の[アラートグループ設定]をクリックします。

f:id:missasan:20181216172425p:plain

アラートグループ設定画面が表示されます。 右上の[新規アラートグループ設定を作成]をクリックします。

f:id:missasan:20181216172826p:plain

新規アラートグループ設定を作成画面が表示されます。

f:id:missasan:20181216172934p:plain:w450

アラートグループはサービス、ロール単位で設定することができます。

f:id:missasan:20181216173052p:plain:w450

アラートグループの通知設定

アラートグループの通知設定は通知チャンネルに設定できます。 通知チャンネルの編集画面を開くと、[通知するイベント]としてアラートグループを選択することができます。 デフォルトではオフになっています。

f:id:missasan:20181216174642p:plain:w450

この設定を変更すれば、運用の仕方に合わせて通知方法を選択することができます。

  • 通常の個別のアラートとアラートグループを両方通知する
  • 個別のアラートの通知をオフし、アラートグループのみを通知する
  • アラートグループは通知せず、GUIから参照するだけ
  • アラートグループ用の通知チャンネルを別途追加して、アラートグループだけ専用の通知先に分けて通知する

などなど

まずはアラートグループを有効にして様子を見ながら通知をどうするか、適切なものを選んでいくとよいと思います。

可読性のよいGUI

これはイメージですが、このような形で表示されます。 CPU使用率の中に一見だけアクセスログのエラーが混ざっているのもひと目でわかりやすくなっています。

f:id:missasan:20181216175615p:plain

アラートグループをうまく使いこなして、大掛かりな障害にもスムーズに対応できるとよいですね。

API と mkrコマンド を使ってみる

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

Mackerelでは複数のインターフェースを用意しています。 いちばんよく見るGUIの他に、別のアプリケーションなどからMackerelを操作可能にするAPI、そして、APIをより簡単に利用することができる、mkr コマンドです。

APIを叩いてみる

APIには、幅広くMackerelの操作をするためのものが揃っています。

  • サービス
  • ホスト
  • ホストメトリック
  • サービスメトリック
  • チェック監視
  • メタデータ
  • 監視設定
  • 通知チャンネル
  • 通知グループ
  • アラート
  • ダッシュボード
  • グラフアノテーション
  • ユーザ
  • 招待
  • オーガニゼーション

APIcurlでも実行してみることができるので、どんな情報が取得・更新できるのか、使い心地をぜひ試してみてください。 試しに、ホストAPIを使って、指定したサービスとロールに所属するホストの一覧を取得してみます。

curl -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" -X GET https://api.mackerelio.com/api/v0/hosts?service=sample-service\&role=sample-role

APIを叩くスクリプトや、アプリケーションを書くと、いろいろなことを自動化できそうでわくわくしますね。

ドキュメトにもっと詳しいことが載っています。

mackerel.io

mkrコマンドを使ってみる

APIを活用するには、何かしらスクリプトや簡単なコードを書く必要がある場合がありますが、そういったことをしなくても、APIを簡単に実行できるインターフェースが mkr コマンドです。

コマンド できること
status ホストの情報を取得します
hosts ホストの一覧を取得します
create 新規ホストを作成します
update ホストのステータスやロールを変更します
throw ホストメトリックまたはサービスメトリックを投稿します
metrics メトリックの値を取得します
fetch 最新のメトリックの値を取得します
retire ホストを退役させます
services サービスの一覧を取得します
monitors 監視ルールの操作を行います
alerts アラートの一覧を取得、クローズします
dashboards ダッシュボードの操作を行います
annotations グラフアノテーションの操作を行います
org オーガニゼーションの一覧を取得します
plugin プラグインの管理をします
help, h ヘルプを表示します

mkr コマンドを使って同じようにホストの一覧を取得する方法をまとめてみます。

今回は、ローカルのmacOSに mkr コマンドをインストールしていきます。インストールには brew を使います。

まずは、brew tap コマンドでリポジトリを追加します。

$ brew tap mackerelio/mackerel-agent

mkr コマンドをインストールします。

$ brew install mkr

mkr コマンドで利用するAPIキーを環境変数で指定します。

$ export MACKEREL_APIKEY=YOUR_API_KEY

mkr コマンドで、先ほどと同じようにサービスとロールを指定してホストの一覧を取得するとこのような感じです。 パッとホストIDの一覧や、ホスト名などを拾ってきたい場合には便利です。

$ mkr hosts -s sample-service -r sample-role
[
    {
        "id": "HOST_ID",
        "name": "sample-host",
        "status": "working",
        "roleFullnames": [
            "sample-service:sample-role"
        ],
        "isRetired": false,
        "createdAt": "2018-04-09T13:08:55+09:00",
        "ipAddresses": {
            "eth0": "IP_ADDRESS"
        }
    }
]

mkr コマンドで監視ルールを変更してみる

mkr コマンドのイチオシ機能は、監視ルールを手元で管理することができる monitors オプションです。 使い方はこんな感じです。

まずは、monitors オプションの中身を見てみましょう。 このように、監視ルールの設定をjson形式で見ることができるのが、このオプションです。

$ mkr monitors
[
    {
        "id": "MONITOR_ID",
        "name": "CPU %",
        "type": "host",
        "metric": "cpu%",
        "operator": ">",
        "warning": 80,
        "critical": 90,
        "duration": 1,
        "maxCheckAttempts": 1,
        "scopes": [
            "sample-service: sample-role"
        ]
    },

(省略)

画面で該当箇所を見るとこんな感じです。

f:id:missasan:20181216160518p:plain

このjsonは手元にファイルとしてダウンロードしてくることができます。 それが monitors pull オプションです。

$ mkr monitors pull
      info Monitor rules are saved to 'monitors.json' (6 rules).

ls をしてみると、monitors.json というファイル名でダウンロードされていることがわかります。

$ ls monitors.json 
monitors.json

jsonファイルはそのまま手元で編集することができます。vi コマンドでファイルを編集してみましょう。 今回は、warningの閾値を80%から85%に緩和してみます。

$ vi monitors.json

さらに monitors diff オプションを使うと、変更箇所の差分を見ることができます。 warningの閾値が80%から85%になっていることがわかりやすく表示されています。

$ mkr monitors diff
Summary: 1 modify, 0 append, 0 remove

 {
   "critical": 90,
   "duration": 1,
   "maxCheckAttempts": 1,
   "metric": "cpu%",
   "name": "CPU %",
   "operator": ">",
   "scopes": [
     "sample-service: sample-role"
   ],
   "type": "host",
-  "warning": 80
+  "warning": 85
 },

このままでは、単に手元のjsonファイルが変更されているだけなので、これをMackerel本体に同期します。 monitors push オプションを利用します。

$ mkr monitors push
      info Update a rule.
{
  "id": "3fRyxz3Nez3",
  "name": "CPU %",
  "type": "host",
  "metric": "cpu%",
  "operator": ">",
  "warning": 85,
  "critical": 90,
  "duration": 1,
  "maxCheckAttempts": 1,
  "scopes": [
    "sample-service: sample-role"
  ]
},

アップデートが成功したメッセージが出力され、実際に画面を見ると、閾値が変更されていることがわかります。

f:id:missasan:20181216160947p:plain

このようにして、手元で監視ルールの書き換え、反映を行うことができます。 また、この monitors.json ファイルを git などに置いておけば、バージョン管理をすることもできます。 その他のCIツールなどと連携して、git で変更がコミットされたら、mkr monitors push をキックするなどのような仕組みもつくれます。

mkrコマンドでは他にもさまざまな操作ができます。詳しくはこちらもヘルプをどうぞ。

mackerel.io

API や mkrコマンド を活用して、普段の作業を自動化してみてはいかがでしょう。

空前の自炊ブーム

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

今回の自炊ブームのきっかけは、風邪を引いたこと。寒くなって乾燥してきて、周囲に風邪を引いている人が増えていたので、とにかく暖をとるべく膝掛けやらヒーターやらベットカバーやら買って温まったり、家では冷たい水やジュースではなくお茶を飲む、うがいする、マスクする、早く寝る、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) などなど。関数は他にもいろいろあります。

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

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