Mackerel ブログ #mackerelio

Mackerelの公式ブログです

PagerDuty への通知内容を強化しました・エージェントなどをアップデートしました

こんにちは。Mackerelチーム CREの井上(id:a-know)です。 新年あけましておめでとうございます。

今日お知らせするリリースが、2018年の最初のリリースとなります。今年もたくさんの便利な・先進的な機能をたくさん、みなさんにお届けしたいと思っています。どうぞよろしくお願いします。

それでは早速、今週のアップデート内容をお知らせします。

PagerDuty への通知内容を強化しました

Mackerel の通知チャンネルのうちのひとつ・PagerDuty 通知に関して、通知リクエストに含まれる json 内容に対して、以下のような項目を追加しました。

  • ホストに対するアラート通知の場合に、新たに含まれるようになった項目
    • ホストID, ホスト名, そのホストが所属しているロールのリスト
  • サービスに対するアラート通知の場合に、新たに含まれるようになった項目
    • サービス名

PagerDutyのAPI V1, V2 いずれでもご利用いただけます。通知内容をもとに、よりプログラマブルな対応をしていただけるようになりましたので、ぜひ活用してください。

mackerel.io

プラグインの実行タイムアウト秒数を設定できるようになりました

mackerel-agent に対して各種設定可能なプラグイン。非常に便利なのですが、そのプラグインの処理におけるタイムアウト時間は、今までの仕様では一律30秒としていました。

これが、プラグイン毎に任意の秒数を設定できるようになりました。例えばタイムアウトを45秒に設定したい場合には、以下のように記述します。

[plugin.metrics.get-metrics]
command = "ruby /path/to/get-metrics.rb"
timeout_seconds = 45

チェックプラグインに対しても指定可能です。

[plugin.checks.check-state]
command = "ruby /path/to/check-state.rb"
timeout_seconds = 45

プラグインの実行間隔は、デフォルトでは1分です。各プラグイン実行の多重起動の制御はしない仕様になっていますので、 timeout_seconds には実行間隔を超えないような設定をすることを推奨します。(プラグインの処理が完了する前に次のプラグイン処理が開始されてしまいます。)

Mackerel 関連 OSS をアップデートしました

以下のとおり、mackerel-agent をはじめとした各種 OSS をアップデートしました。年末年始期間に、多くの Pull Request、コントリビュートをいただきました。皆様、本当にありがとうございました!

mackerel-agent v0.49.0

  • プラグインの実行タイムアウト秒数を設定できるようになりました(上述)
  • チェック監視通知のリトライ処理を改善しました
  • Dockerホストでメトリックや情報を取得しすぎてしまう問題に対処しました
    • veth で始まるネットワークインターフェースを除外するようにしました
    • dm- で始まデバイス(devicemapper)を除外するようにしました
    • dm- で始まるファイルシステム(devicemapper)を除外するようにしました
  • 中身が空の /var/lib/mackerel-agent/id が存在する場合に起動できなかった点を修正しました
  • [Windows版] check-uptime.exe を同梱するようにしました

mackerel-agent-plugins v0.42.0

  • [mongodb] replica-set を組んだ mongodb で正しくメトリックが取れないことがある点を修正
  • [haproxy] -socket オプションにより、Unix Domain Socketを指定できるようになりました
  • [postgres] 古いバージョン (9.3.14) のPostgresqlでも動作するようになりました

go-check-plugins v0.15.0

  • [mysql] 対象の mysql サーバが readonly かどうかを確認するサブコマンド readonly を追加しました

plugin-registry

  • mackerel-plugin-aws-ecs を追加しました。
    • プラグインインストーラーの機能を利用することで、 mkr plugin install mackerel-plugin-aws-ecs のように利用できます。
    • 既に試してくれているユーザーさんがいますので、以下の記事もぜひ参考にしてみてください!

kakakakakku.hatenablog.com

年末年始期間中におけるサポート窓口対応の休業のお知らせ

いつもMackerelをご利用いただきありがとうございます。

下記エントリにて事前にお知らせさせていただいていましたが、

mackerel.io

Mackerel にログインしている状態でヘッダー右上に表示されている「サポートチームへ連絡」からのお問い合わせや、support@mackerel.io 宛へのお問い合わせへの対応について、以下の年末年始期間中はお休みさせていただきます。

年末年始休業期間:2017年12月28日(木)〜2018年1月3日(水)

この期間中にいただいたお問い合わせについては、2018年1月4日(木)以降に順次対応させていただきます。

Mackerelは開発者に会いに行けるサービス

Mackerelチームディレクターの id:daiksy です。

いよいよ年の瀬ですね。今回は、少し変わった視点でMackerelの今年を振り返ってみたいと思います。

会いに行けるサービス

Mackerelは株式会社はてなが提供するサービスで、開発は日本で行われています。 ソフトウェア開発者向けのSaaSといえば、海外製のサービスが多いですが、そのような中においてMackerelは「国産SaaS」です。 これは日本でサービスを展開していく中での1つの強みだと思っています。

つまり、開発者とサービスについて日本語で深くコミュニケーションができる、ということです。

わたしたちも、できるだけ多くのユーザーさんの要望を聞きたいと考えていますし、少しでもコミュニケーションの機会を増やしたいと思っています。 そういったこともあって、Mackerelチームは、日本国内の様々なイベントに出展し、皆さんとお会いする機会を提供しています。(そのほかにもCREが直接ヒアリングしたり、ハンズオンセミナーを開催したりしています)

Mackerel User Groupが管理をするSlackチャンネルもあり、そこでも時々Mackerelスタッフが顔を覗かせています。mackerel-agentなどのOSSは、Githubのissue上は原則英語でのやりとりをお願いしていますが、常に英語での議論だとしんどい場合もあり、そういう時はMackerel User GroupのSlackで日本語で議論してからその結果をissueに書いていただく、といったこともあります。

User GroupのSlackにはこちらのリンクからご参加いただけます。

Join mackerel-ug on Slack!

それでは、今年出展/開催したイベントを見てみましょう

1月26日 Mackerel Meetup #9 (主催)

mackerel.io

2月16, 17日 Developers Summit 2017 (出展)

event.shoeisha.jp

3月22日 Mackerel DrinkUp #4 Tokyo (主催)

mackerelio.connpass.com

4月15日 Mackerel / AWS / Twilio Hands-On Seminar (共催)

4月27日 Mackerel Meetup #10 (主催)

mackerel.io

5月10 〜 12日 クラウドコンピューティングEXPO 2017 春 (出展)

5月31日 〜 6月2日 AWS Summit (出展 & 登壇)

blog.yuuk.io

7月19日 Mackerel DrinkUp #5 Tokyo (主催)

mackerelio.connpass.com

8月30日 〜 9月1日 CEDEC 2017 (出展 & 登壇)

www.youtube.com

9月21日 AWS Cloud Roadshow 2017 大阪 (出展)

aws.amazon.com

9月25日 Mackerel / NewRelic / Elasticsearch Seminar (共催)

mackerelio.connpass.com

9月26日 Mackerel DrinkUp #6 Osaka (主催)

mackerelio.connpass.com

9月27日 AWS Cloud Roadshow 2017 名古屋 (出展)

aws.amazon.com

10月5日 Mackerel Day (主催)

mackerel.io

10月31日 AWS Cloud Roadshow 2017 福岡 (出展)

aws.amazon.com

11月29日 Monitoring Seminar in mercari (共催)

mackerel.io

12月13日 Mackerel × Twilio Hands-On Seminar (共催)

mackerelio.connpass.com

ユーザーさんからのご要望によりリリースされた機能

こういった場でユーザーの皆さんからいただいたご要望は、きちんと開発に反映することを心がけています。 以下は、今年リリースした機能の中で、ユーザーの皆さんからいただいたご要望によって開発した機能となります。

  • [mackerel-plugin-jvm] リモートのモニタリングできるように
  • 監視ルールの変更を通知
  • アクセス元のIPアドレス制限の設定可能な数を増やす
  • [mackerel-plugin-docker] cpu使用率をpercentageでの表示に
  • 外形監視から名前解決時間を除外
  • パスワードポリシー見直し
  • キーボードショートカット追加
  • 通知チャンネルのサスペンドを気が付きやすく
  • オーガニゼーションのリストの並び順を規則性がわかる形でソートするように
  • ホストメトリック監視で最大試行回数(maxCheckAttempts)を設定できるように
  • check監視のオートクローズをしないオプションを追加
  • 監視ルールのメモの内容をメール通知の本文に含める
  • [mackerel-plugin-postgres] metric-key-prefix に対応
  • ログ監視において、AND 条件を簡単に記述できるように

来年も今年と同様のペースで、いや、それ以上にアクセルを踏んで開発をしていきます。 ご期待ください!!!

監視ルールの操作を通知チャンネルに通知できるようになりました ほか

こんにちは。Mackerelチーム CREの井上(id:a-know)です。

12月も4週目となった今週、私は毎日が忘年会、という過ごし方をしているのですが、Mackerelユーザーのみなさんはいかがお過ごしでしょうか。

今年も毎週金曜日にお届けしてきたこの Mackerel のアップデートのお知らせも、今年はこれが最後のお知らせとなります。

2014年9月から続けてきた「毎週連続リリース」も、このまま継続できれば来年には200週連続リリースを迎えます。2018年も、様々な良い機能・アップデートをみなさんにお届けしていきたいと思っています!

それでは、今週のアップデート内容をお知らせします。

監視ルールの操作を通知チャンネルに通知できるようになりました

監視ルールを操作(作成/更新/削除)したときに、通知チャンネルにイベント通知をすることができるようになりました。

f:id:mackerelio:20171221155418p:plain

通知チャンネルとして Webhook 通知を選択した場合は、JSON形式の通知内容に監視ルールの変更内容が含まれています。具体的には以下の通りです。

  • 監視ルール作成と更新の場合
    • 操作後の監視ルールの内容が通知されます
  • 監視ルールの削除の場合
    • 削除直前の監視ルールの内容が通知されます

グラフの通知チャンネルへの投稿が LINE と Yammer にも対応しました

グラフメニューのカメラアイコンをクリックすることで利用できる、グラフの通知チャンネルへの投稿機能。アラートに設定していないメトリックについても任意のタイミングでシェアができるので便利な機能なのですが、この投稿先として、LINE、Yammer にも新たに対応しました。

この機能については以下のヘルプページも参照してください。

mackerel.io

Mackerel 関連 OSS をアップデートしました

以下のとおり、mackerel-agent をはじめとした各種 OSS をアップデートしました。コントリビュートくださった皆様、ありがとうございました!

mackerel-agent v0.48.2

  • [Windows向け] ネットワークインターフェースのアドレス情報が取れない問題を修正しました

mackerel-agent-plugins v0.41.1

  • [mysql] AWS Aurora for MySQL の reader node でも InnoDB 関連の stats を一部取得できるようになりました
  • [mysql] その他、微調整をおこないました

今年も1年、ありがとうございました!

冒頭でも書きましたが、今年のアップデートのお知らせはこれが最後となります。2017年も Mackerel をご愛顧いただき、本当にありがとうございました。

Mackerel を通じて、さらに先進的・効率的なサーバー監視、サーバー管理の体験をユーザーのみなさまにお届けできるよう、2018年もアップデートを続けていきたいと思います。

来年も Mackerel をどうぞよろしくお願いします。

プラグインによるコマンド実行に対して環境変数を指定できるようになりました ほか

こんにちは。Mackerelチーム CRE の井上(id:a-know)です。

早いもので、12月も折り返し・今年も残すところ半月です。お仕事に忘年会に、と、皆さんきっとお忙しいところかと思います。 Mackerelが継続している毎週アップデートも、来週お知らせするものが今年最後のアップデート内容となります。

年末年始を穏やかに過ごせるよう、2017年のラストスパートを乗り切っていきましょう。

それでは、今週のアップデート内容です。

プラグインによるコマンド実行に対して環境変数を指定できるようになりました

以下のような設定を conf ファイルに追記することで利用可能な、Mackerel のプラグイン。

[plugin.metrics.mysql]
command = "ruby /path/to/mysql.rb --username user --password password"

command に指定した文字列をエージェントが実行し、その結果得られた標準出力(もしくはリターンコード)をもとに Mackerel 本体に対して結果の投稿をおこなう、非常に便利なしくみです。

今週のアップデートで、このプラグインの仕組みよるコマンド実行に対して、環境変数を指定できるようになりました。 以下のような指定方法になります。

[plugin.metrics.mysql]
command = "ruby /path/to/mysql.rb"
env = { "MYSQL_USERNAME" = "user", "MYSQL_PASSWORD" = "password" }

現在公式として提供しているプラグインにおいても、その内部で用いるミドルウェアのパスワード設定などを環境変数経由でおこなえるよう、順次アップデートを実施していきます。

この機能は、チェックプラグイン、メタデータプラグインでも同様に利用することが可能です。ぜひご活用ください!

設定パスワードの強度ポリシーを見直し、セキュリティ強度の弱いパスワードでも設定可能にしました

今週のアップデートにより、以下の2点についてアップデートを実施しました。

  • 設定パスワードの強度ポリシーを見直しました
  • セキュリティ強度の弱いパスワードは設定できないようにしていましたが、これを無視できるようにしました

f:id:mackerelio:20171214185155p:plain

強度チェックを敢えて無視するオプションについて、現在Mackerelでは、GoogleやGitHubによる認証を設定していただければパスワード認証を削除することもできるようになっていますので、これらと組み合わせて適切に活用していただければと思います。

Mackerel 関連 OSS をアップデートしました

以下のとおり、mackerel-agent をはじめとした各種 OSS をアップデートしました。コントリビュートくださった皆様、いつもありがとうございます!

mackerel-agent v0.48.1

  • プラグインによるコマンド実行に対して環境変数を指定できるようになりました(上述)
  • custom_identifier の取得や、IaaSのメタ情報の収集対象を選択するためのオプション cloud_platform を追加しました

mackerel-agent-plugins v0.40.0

  • mackerel-plugin-h2o を追加しました
  • [redis] プラグインが内部的に用いている CONFIG コマンドがそのまま利用できない場合でも利用可能になりました
    • -config-command オプションにより指定します。
  • [redis] レプリケーション遅延のメトリックが新たに取得可能になりました

mkr v0.24.1

mackerel-plugin-accesslog徹底解説

Mackerelプロダクトオーナー(肩書き上はサブプロデューサー)の id:Songmu です。この記事はMackerel Advent Calendar 2017 の9日目の記事です。

今年、mackerel-plugin-accesslog という公式プラグインを書いたのですが、これが便利であり、それなりに頑張って作ったというのもあるので紹介したいと思います。

これは、Webサーバーのアクセスログを集計して、可視化してくれるものです。

インストール方法

mackerel-plugin-accesslogは公式のメトリックプラグインパッケージであるmackerel-agent-pluginsに含まれているため、それがインストールされていればすぐに利用可能です。パッケージのインストール方法は以下のページを参照してください。

ミドルウェアのメトリック可視化に公式プラグイン集を使う - Mackerel ヘルプ

Goの環境がある場合は、以下のように go get することも可能です。

% go get github.com/mackerelio/mackerel-agent-plugins/mackerel-plugin-accesslog

設定方法

mackerel-agent.conf に以下のように指定します。引数にアクセスログのファイル名を指定するだけ非常に簡単です。

[plugin.metrics.accesslog]
command = "mackerel-plugin-accesslog /path/to/access.log"

対応フォーマット

以下のログフォーマットに対応しています。

  • ApacheやNginxで使われている一般的なApache形式のログ(Common/Combined)
  • LTSVログアクセスログ

メジャーなApacheログの他に、はてなで統一的に使われており1、日本のWeb業界ではそれなりに使われるようになったLTSV(Labeled Tab-separated Values)フォーマットのアクセスログ形式をサポートしています。

LTSVアクセスログは、 ltsv.org2 で定められているRecommended Labelを利用した形式である必要があります。設定方法についても、ltsv.orgに記述がありますのでご参考ください。

アクセスログパーザーを頑張って書いた3ので、大方のログをパーズ可能だと自負しております。ただ、実は、LTSVログでの利用を強くオススメします。LTSVの場合のみ、レスポンスのレイテンシの集計が可能です。また、微々たる差だとは思いますが、LTSVのほうがパーズ効率も良いと思われます。

グラフ化される項目

以下の項目が集計されグラフ化されます。

  • ステータスコード毎のアクセス数
  • ステータスコード毎の割合
  • レイテンシ(LTSVログの場合のみ対応)
    • 平均
    • 90/95/99パーセンタイル

スクリーンショットを見ると、非常にわかりやすく可視化されることがわかるでしょう。

ちなみに、mackerel-plugin-accesslogは前回実行時に読み出したログファイル内の位置を記録しており、実行時はその続きからログを読み出します。そのためagentから定期実行された場合には、1分ごとの値が集計されます。

また、ログローテートされた場合であっても、可能な限りローテートされる前のファイルを見つけ出し、見つけた場合は、その末尾までログを読みきった後に、新しいログファイルを最初から読み込む挙動となっています。それにより、より正確な集計が実現されています。このあたりの制御は、postailerというライブラリ4により実現されています。

式グラフと組み合わせてロール単位で集計をおこなう

Webサーバーは複数台構成が一般的であるため、ロールで集計したグラフを見たいこともあるでしょう。

Mackerelには式を用いてカスタマイズしたグラフを表示する実験的機能(通称:式グラフ)があります5。この機能を使えばロール単位でのアクセスログを集計したグラフを表示させることができます。

ここでは、ロール単位でのステータスコード毎のアクセス数と割合の積み上げグラフを表示させてみます。また、式グラフは実験的機能であるため、オーガニゼーションの設定で実験的機能を利用する設定を有効にするようにしてください。6

ステータスコード別のアクセス数の積み上げグラフを表示する

上記のグラフを表示させるための式は以下のようになります。ロール名やメトリック名などは適宜書き換えてください。

group(
  stack(alias(sum(
    role(SugoiService:web,custom.accesslog.access_num.2xx_count)),
    '2xx_count')),
  stack(alias(sum(
    role(SugoiService:web,custom.accesslog.access_num.3xx_count)),
    '3xx_count')),
  stack(alias(sum(
    role(SugoiService:web,custom.accesslog.access_num.4xx_count)),
    '4xx_count')),
  stack(alias(sum(
    role(SugoiService:web,custom.accesslog.access_num.5xx_count)),
    '5xx_count')))

ステータスコード別のアクセス割合の積み上げグラフを表示する

上記のグラフを表示させるための式は少し複雑ですが以下のようになります。こちらもロール名やメトリック名などは適宜書き換えてください。

group(
  stack(alias(scale(
    divide(sum(role(SugoiService:web,custom.accesslog.access_num.2xx_count)),
    sum(role(SugoiService:web,custom.accesslog.access_num.total_count))),100),
    '2xx_rate')),
  stack(alias(scale(
    divide(sum(role(SugoiService:web,custom.accesslog.access_num.3xx_count)),
    sum(role(SugoiService:web,custom.accesslog.access_num.total_count))),100),
    '3xx_rate')),
  stack(alias(scale(
    divide(sum(role(SugoiService:web,custom.accesslog.access_num.4xx_count)),
    sum(role(SugoiService:web,custom.accesslog.access_num.total_count))),100),
    '4xx_rate')),
  stack(alias(scale(
    divide(sum(role(SugoiService:web,custom.accesslog.access_num.5xx_count)),
    sum(role(SugoiService:web,custom.accesslog.access_num.total_count))),100),
    '5xx_rate')))

式に対して監視をおこなう

式で求めた値に対して監視をおこなうことも可能です。詳しくはヘルプをご覧ください。

式グラフは強力な機能であり、正しく有用な式が書けた場合は非常に満足感が高いのですが、まだまだ使いづらい機能だとは認識しているため、機能改善につとめていきます。ご要望もお待ちしています。

fluentdを用いた集計方法との比較

公式ヘルプの「fluentdでサービスメトリックを投稿する」では、fluentdを組み合わせてアクセスログ集計を実現する方法を紹介7しています。

mackerel-plugin-accesslogを使えば、fluentdを使わずともアクセスログ集計が実現できるため非常にお手軽です。

ただ、fluentdを用いた手法が必要なくなるかというとそういうわけはありません。mackerel-plugin-accesslogはあくまで、一つのサーバーのアクセスログに対して決まった集計をおこなうものです。複数サーバーであったり独自の集計をおこなう局面ではfluentdを利用したほうが柔軟で有用な場合もあるでしょう。また、近年ログをサーバーローカルのファイルシステムには書かず、それこそfluentdなどのログコレクタに任せてしまう運用も増えてきており、その場合には、mackerel-plugin-accesslogを利用する事はできません。

まとめ

mackerel-plugin-accesslog、便利ですので、ぜひご利用ください。また、機能追加や要望などのissueやpull requestもお待ちしています。

https://github.com/mackerelio/mackerel-agent-plugins/tree/master/mackerel-plugin-accesslog

ホストメトリック・サービスメトリック監視ルールで最大試行回数を設定できるようになりました ほか

先週もお伝えした Mackerel のアドベントカレンダーですが、ユーザーのみなさまのおかげで、全ての枠が埋まりしました!

qiita.com

ありがとうございます!

また、CRE の id:Soudai が頑張るこちらのアドベントカレンダーも、開始から今日まで一つも落とすことなく、また非常に有益な情報・知見が満載のブログが毎日公開され、継続しています。

qiita.com

クリスマスまでの道のりといっしょに、これらのアドベントカレンダーを楽しんでもらえたらと思います。

それでは、今週のアップデートです。

グラフボードにカスタマイズグラフ(式グラフ)を追加できるようになりました

任意のロールグラフ・サービスメトリックグラフを好きなように配置でき、インタラクティブに操作が可能な「グラフボード」、みなさまご活用いただいているでしょうか。

mackerel.io

今週のアップデートにより、このグラフボードに追加できるグラフの種類が増え、カスタマイズグラフ(式グラフ)を追加できるようになりました!

f:id:mackerelio:20171208074156p:plain

  • あるサーバの、先週の負荷と今週の負荷の様子を重ね合わせてひとつのグラフとして表示する
  • あるロールに属するサーバの負荷の値のうち、最大値/平均値/最小値を計算したものをグラフ表示する

といったようなことが関数式の記述をすることで実現できる、非常に便利なカスタマイズグラフ。その活用が、今までよりもさらにしやすくなると思います。

カスタマイズグラフは実験的機能となっています。詳しくは以下のヘルプページを参照してください。

mackerel.io

mackerel.io

ホストメトリック・サービスメトリック監視ルールで最大試行回数を設定できるようになりました

f:id:mackerelio:20171208073940p:plain

上の画像のとおり、ホストメトリック・サービスメトリック監視ルールで「アラート発生までの最大試行回数」を設定できるようになりました。

今までは、「n分の平均値の監視」という、「平均値監視」のみをサポートしていました。この設定をもちいて、「閾値 5 を継続して越えるようなときにアラート発報させたい」といったときに、

  • 閾値として 5
  • 3分の平均値を監視

といった設定をしていた場合、756といったような経過をたどった場合(この場合の「3分の平均値」は 6)だけでなく、 1161 といったような経過をたどった場合(この場合の「3分の平均値」も 6)でもアラート発報につながり、必ずしも意図したケースだけでアラートを受け取ることが難しい場合がありました。

今回追加した「アラート発生までの最大試行回数」を用いることで、上記のようなケースでも切り分けることができるようになります。監視対象のメトリックに応じて、「n分の平均値の監視」と使い分けてもらえたらと思います。

年末年始期間中におけるサポート窓口対応の休業のお知らせ

Mackerel にログインしている状態でヘッダー右上に表示されている「サポートチームへ連絡」からのお問い合わせや、support@mackerel.io 宛へのお問い合わせへの対応について、以下の年末年始期間中はお休みさせていただきます。

年末年始休業期間:2017年12月28日(木)〜2018年1月3日(水)

この期間中にいただいたお問い合わせについては、2018年1月4日(木)以降に順次対応させていただきます。

年末年始に向けてのサーバー監視設定の見直しなどはぜひお早めに実施していただき、そこでのご不明点は早めにお問い合わせください!