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

この記事は、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で取ってこられるメトリックの種類と概要についてまとめます。

サービスとロール

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

12月に入りました。今月はMackerel CRE アドベントカレンダーに挑戦します。目新しい記事というよりは、ゆるやかに、あらためて自分の理解を自分の言葉で整理するためと、これからもっとお会いしていくであろう未来のMackerelユーザの方々とお話するときに役立ちそうなものをまとめていくような記事を書き溜めていきたいと思います。

qiita.com

第1回目はMackerelの「サービス」と「ロール」という概念についてです。 Mackerelを理解するなら、まずはここからといったところでしょうか。

サービスとロールとは?

サービスとロールとは、監視対象や取得したメトリックをグルーピングする単位です。 Mackerelの中でとても重要な概念で、アラート通知の条件設定やグラフの描画など、いろいろな設定に関わります。 Mackerelを活用していく上で、はじめにこのサービスとロールをどのような形で切り出して行くのかをぼんやりとでも考えておくと、あとの設定がとても楽でわかりやすいものになります。

サーバーが提供する「サービス」

「Mackerelはサーバー監視サービスです。」とよく説明しています。 サーバー監視という言葉を使うと、どうしても対象のサーバーに目がいきがちですが、サーバーとはもともと、サービスを提供するもの、という意味です。 Mackerelでは、サーバー1台1台というよりも、そのサーバーが提供しているサービス全体にフォーカスできるような設計になっています。

サービスは、サーバーが提供しているある程度のまとまりのある機能のことです。 厳密には、管理のしやすさや何かしらの制約によって、まとめたりより細かいコンポーネントごとに分けるということもあるので、必ずそうとは言えませんが、イメージとしてはこのような感じです。 例えば、Webサーバーをたてて、コーポレートサイトを運用しているのであれば、コーポレートサイトがサービスにあたります。ソーシャルゲームであれば、ゲームタイトルごとの環境がそれにあたるでしょう。 はてな にとっては、「はてなブログ」や「はてなブックマーク」がサービスにあたります。 実際に、はてな社内用 Mackerelの「サービス」の設定には、「はてなブログ」や「はてなブックマーク」にあたる設定が入っていて運用に活用しています。

サーバーには役割「ロール」がある

クラウド環境などを利用していると、ひとつのサービスを複数台のサーバーで運用しているということはよくあります。 私もお客様のところにお伺いすると、まず「担当されているサービスは何ですか?」と聞いたあと、そのサービスが何台程度のサーバーで、どんな構成で運用されているのかということをよく聞きます。 この「どんな構成で?」というところが、Mackerelでいうところの「ロール」にどんなものがあるのかのヒントになります。

例えば、以下のようなものです。

  • Webメディアサービスを運用しています
  • ロードバランサーを前段にWebサーバーを3台並列に動かして負荷分散をしています
  • Webサーバーはデータベースに接続しています
  • DBサーバーは、マスターDBサーバーが1台、そこからレプリケーションする参照用のスレーブDBサーバーが2台あります

など。 この中に含まれるロールは、ざっくり以下のようなものでしょうか。もちろんこちらも管理のしやすさなどから、DBサーバーはマスターDBサーバーとスレーブDBサーバーに分けてもよいでしょう。あくまで例です。 本来なら、これ以外にも管理サーバーやログサーバーなども入ってくるかもしれません。

  • ロードバランサー
  • Webサーバー
  • DBサーバー (または マスターDBサーバー と スレーブDBサーバー)

そして、この役割を担う個々のサーバーをMackerelでは「ホスト」と呼びます。 図にするとこんな感じです。

f:id:missasan:20181202002534p:plain

次のブログでは、実施にサービスとロールがMackerelの中でどのように登場してくるのか、どの設定に関わってくるのかというところをまとめてみようと思います。

私のブログはこんな感じでゆるゆると進みます。どうぞみなさまお付き合いくださいませ。

コンサートと村上春樹「意味がなければスイングはない」の話

先日、ちょっと気が向いて、とある大学の管弦楽団定期演奏会に行ってきた。 とくに団員の誰かにゆかりがあるというわけでもないのだけれど、その日の朝にSNSで見かけて、これは最近の少しもやもやしたような煮詰まった気持ちをやり過ごすのによいかもしれないと思ったのだ。実際、とてもよくやり過ごせた。 それに、1000円程でオーケストラの演奏を聴けるというのはリーズナブルで、とてもよい機会だとも思った。

開催されたコンサートホールは広くて立派で客席が3階まであって、私と連れはゆかりのない大学の楽団の定期演奏会ということでなんとなく気後れして、3階の、そのなかではよさそうな席を、当日券を売る団員さんに選んでもらって座った。 ゆったりとしていて、居心地がよくてすばらしかった。

クラシックにとくに詳しいわけでもない。でも、私はほんとうならいわゆるハイコンテクストな理解が必要そうなものをさほど理解もなく楽しむことが得意だ。 絵画も写真も落語もプロレスも、人に誘われていくあまり知らないアーティストのライブとかもそうだ。そこにあるものだけで楽しめる。(今気づいたが、そこにあるものだけで楽しめるようなタイプのアーティストや落語家やレスラーを好きになりがちだ。しかしそれはいったいどんなタイプなんだ。分類できるのか。)

クラシックのコンサートを聴くときは、少し早めに席についたら、パンフレットに書いてある曲紹介を読み込んだり、指揮者の人の写真を眺めながら、もしかすると今日はこんな演奏になるのかもしれないな、と想像する。 曲がはじまったら、うーむこの曲はロマンチックでいいなとか、ディズニーみたいでたのしいなとか、旋律がわかりやすくていいなとか、やっぱりメインの曲が一番演奏がうまいなとか、自分はさっきの曲がほう好きだなとか、アンコールというものは明るい曲をやるからいいなとかそんなことを思いながら楽しむ。考えていることを書きあげると教養のなさとしまりのなさがバレてしまう。

今日はそんなことを思い出していたら、なんだか音楽についての本が読みたくなったので、本屋で、村上春樹の「意味がなければスイングはない」という本を買ってみた。タイトルがよくて目に止まった。「音楽についてそろそろ真剣に、腰を据えて語るべきではないか」という帯もよかった。腰を据えて語るコンテクストをもたない私は深く理解している人に教えて欲しいのだ。

意味がなければスイングはない (文春文庫)

意味がなければスイングはない (文春文庫)

少し読んでみた限りだと、これが実によくて、音楽の教養がなくても、ほほうそれは面白いなとか、ははあそんな解釈があるのかとか、いい曲なんだろなとかいって知らないことを知らないまま楽しく読ませる。私がクラシックのコンサートを楽しむときと同じテンションや取り組み方で読める。 村上春樹さんは文章がうまいなぁ、とまた中身のない適当な感想が出てしまう。

気が向いたので、というような徒然なるままの日常ブログを書いてみた。