こんにちは。Mackerelチームで CRE（Customer Reliability Engineer）をやっている id:a-know です。この記事は、Mackerel アドベントカレンダー（全部CRE）の1日目の記事です。 このアドベントカレンダーは、その名前のとおり、もうひとりのCREである id:missasan とともに、CREだけで Mackerel の話題をお届けし続けるものになる予定です。今日からクリスマスまでの25日間、駆け抜けていきたいと思います！どうかお付き合いいただけたら幸いです！ 今日は、「2018年の Mackerel のアップデート内容をふりかえる」と題して、今年・2018年におこなわれた Mackerel のアップデートのうち、特に主要なもの・便利なものをダイジェストでお届けしたいと思います！ 2018年の Mackerel のアップデート内容のダイジェ

著者: 坪内佑樹(*1), 古川雅大(*1) 所属: (*1) 株式会社はてな 研究会: Web System Architecture研究会#3 はじめに ウェブシステムは，一般的に，分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される． 相互にネットワーク通信するシステムにおいて，システム管理者があるネットワーク内のノードに変更を加えた結果，ノードと通信している他のノードに変更の影響がでることがある． ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど，システム管理者が個々の通信の依存関係を記憶することは難しくなる． さらに，常時接続しておらず必要なタイミングで一時的に通信するケースでは，あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない． その結果，システムを変更するときの影響範囲がわからず，変更のたびに依

こんにちは。Mackerelチーム CRE の井上（id:a-know）です。 昨日、同じくCREの三浦（id:missasan）より、Mackerelのアップデート告知をお知らせしましたが、その中で以下のようなアップデートが含まれていたかと思います。 go-check-plugins v0.22.1 のリリースで、check-log プラグインでログファイルを追尾する際にinode番号を参照するよう変更しました。 これによりログローテーションされた際のログファイルの追尾精度が向上しました。 今日のこのブログ記事では、その変更内容について少し詳細に解説したいと思います。 当記事の要約 check-log のチェック対象ログファイルの追跡を、これまでの「ファイル名のみ」に加えてinode番号も加味して追跡するようにしたことで、追尾可能なケースを増やしました。 従来までの check-log

この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer

こんにちは。Mackerelチーム CRE の三浦（id:missasan）です。 今回は、多くのユーザの方々からご要望があったタイトルの機能以外にも、はてなサマーインターン生による追加機能、コントリビューターの方による追加・改善など盛りだくさんの内容です。 ぜひ詳細までお読みください。 それでは、アップデート情報です。 AWSインテグレーションによるEC2連携ホストの自動退役機能を追加しました AWSインテグレーション機能で連携したEC2ホストを、自動退役できる機能を追加しました。 この機能を有効にすると、インスタンスの削除を行った際に、Mackerel上で自動で退役処理が実行されます。 設定方法は、AWSインテグレーション設定画面にて 自動退役を有効にする にチェックを入れてください。 すでに登録されているAWSインテグレーションの設定では、無効となっています。新規に登録される場合は、

こんにちは！　Mackerelチーム CREの井上（id:a-know）です。こちらのブログではお久しぶりとなります。 さて今回は、昨日・8月2日（木）に開催した Mackerel の公式イベント、Mackerel Meetup #12 Tokyoの開催レポートをお届けします！ 公式ミートアップとしては、前回から約半年ぶりの開催となりました。参加できた方も、そうでない方も、ぜひこちらのレポートで会場の雰囲気を味わっていただけたら、と思います！ 開催会場はドリコム様のセミナースペース ＆ カフェスペース！ Mackerel Meetup の第12回会場となる場所をお借りさせていただいたのは、Mackerelのユーザーさまでもある株式会社ドリコム様！ ミートアップを開催する度に思うのですが、毎回このような素敵な会場をお借りすることができて、本当にありがたい限りです......！ 受付の様子。ク

こんにちは。Mackerelチーム CRE の三浦（id:missasan）です。 ついに、Mackerelの連続リリース記録も200週を達成いたしました。 これはひとえに日々Mackerelを活用いただき、プルリクエストやフィードバックをいただいているユーザのみなさまのおかげです。いつも本当にありがとうございます！ リリースを記念して、Mackerelのトップページをリニューアルしました。 それでは、今週のアップデート情報です。 アラートグループ機能をリリースしました これまで、ネットワークやストレージなど広い範囲に影響がある箇所に障害が発生した際などに、大量のアラートが上がって困る、という経験をしたことがある方も多いのではないでしょうか。 大量のアラートに埋もれて重要なアラートを見逃してしまったり、すべての時系列を把握することが難しかったりすることがあります。 今回はそういった、一度に

Mackerelチームのエンジニアのid:itchynyです。 「mackerel-agentを入れるとloadavgが7時間ごとに上昇する」 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。 本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada

https://github.com/Songmu/jfill 標準入力からJSONを受け取り、その値を使ってコマンドラインを組み立てて実行するユーティリティです。以下のような具合です。 インストール % go get github.com/Songmu/jfill/cmd/jfill もしくはGitHub Releasesからご利用ください。 使い方 % echo '{"name":"jfill"}' | jfill echo Hello {{name}}! Hello jfill! {{name}} の部分がプレースホルダーです。それがJSONの入力を元に置換され実行されています。 プレースホルダー内には以下のようにデフォルト値を指定することも可能です。 % echo '{}' | jfill echo Hello {{name:jfill}}! Hello jfill! {{name

Kaizen Platform で Product Manager / Engineering Group Manager をしている @takus です。 Kaizen Platform では多くのアプリケーションで Ruby on Rails を採用しています。Rails には Active Support の Instrumentation 機能というものがあり、これを利用するとアプリケーション内でのイベント処理数や処理時間を計測して Datadog や Mackerel といった監視システムに送ることが簡単にできるので、その話を紹介したいと思います。 TL;DR Rails でイベント処理数や処理時間を計測して監視システムに送りたい Active Support の Instrumentation 機能を使うと簡単にできる 試しに Delayed::Job の Job 処理数と処理

現在仕事で作っている異常検知システムについてPyCon mini Osakaで登壇してきました。異常検知というマイナーなトピックですが、多くの人に聞いてもらえてよかったです。 #pyconjp #pyconosaka 「Pythonを用いた異常検知システム構築の裏側」 吉田康久さんです！ たしかはてなの人だったはず。 pic.twitter.com/hRacSgV59D— PyCon mini Osaka (@OsakaPyConMini) 2018年5月19日 はい、はてなのMackerelチームの中の人です。 機械学習の人からすると「なんだただの混合ガウス分布か」と思われるかもしれませんが、異常検知のシステムを実際に作ろうとすると考えることが色々あります。今回の発表では ユーザーのどのような要望から異常検知機能を作るに至ったか 異常検知とはそもそも何か、どういった問題設定か 異常検知手

2018/02/05 https://mackerelio.connpass.com/event/76678/

Mackerelチームでデザイナーをしているid:takuwologです。 この記事ではMackerelがどのように情報をデザインしているのかを事例を交えて紹介します。 Mackerelとはエンジニアがサーバーを管理・監視するためのサービスです。 mackerel.io サーバーの管理・監視を行なうMackerelでは多くの情報を取り扱うことになります。扱う情報は大きく分けると3つあります。 サーバーの仕様や状態などの情報 サーバーを監視するためにユーザーが追加した設定情報 チームやユーザー個人の設定情報 上記3つを合わせると情報量はとても多くなります。そのため情報を「わかりやすく」ユーザーに提示することがサービスにおいて重要になってきます。 「わかりやすさ」とは何か ユーザーは日常的にMackerelを使用してサーバーの管理・監視を行います。そのため誰がどんな時に何が目的でMackere

監視を Zabbix から Mackerel に移行しています。そこで困ったことを OSS を書いて解決しようシリーズのお時間です。 ホストのダウン検知を早くしたい Mackerel の監視は Push 型と呼ばれるもので、mackerel-agent が Mackerel サーバに対してメトリクスを送信する形態です。そのため、agent を稼働させているホストがダウンしたという事象は、「一定時間サーバに対して情報が送られてこない」ことによって、組み込みのアラート "connectivity" として検知されます。 これによって困ることとしては、以下があります。 ホストが実際にダウンしてから7分程度経過しないとアラートが上がらない あまり短時間で判断してしまうと誤検知が増えるからでしょうか もうちょっと早く検知したいです "connectivity" アラートは Critical レベルし

こんにちは。Mackerelチーム CRE の三浦（id:missasan）です。 4月も半ばを過ぎました。Mackerel チームでは、5月、6月にいくつかイベント出展を予定しているのでそろそろ準備が大詰めを迎えています。 新しいノベルティも企画しているので、みなさまお楽しみに！ それでは、今週のアップデート情報です。 外形監視の HTTP リクエストヘッダ に User-Agent を指定できるようになりました 外形監視の HTTP リクエストヘッダ 設定にて、任意の User-Agent を指定できるようになりました。 User-Agent の設定がない場合や値が空の場合は User-Agent: mackerel-http-checker/x.y.zが送信されます（x.y.zはバージョン番号が入ります）。 T2 Unlimited 機能で消費される CPU クレジットを監視できるよ

どうもつるべーです。 私は2018年3月1日から、GMOペパボ本社にてペパボカレッジ（通称ペパカレ）のインフラ研修を受けており、4月6日に無事修了することができました！ 今回は研修で学んだことやこれからやりたいことなどを書いていきます。 以前ペパボへの転職エントリーも書いたので、よければ読んでください！ blog.tsurubee.tech ペパカレって？ ペパカレとは第二新卒エンジニア向け研修のことで、中途で入ってもみっちり研修を受けられます。 私はペパカレ6期生で、これまでWebアプリケーションエンジニアとモバイルアプリケーションエンジニアの採用があったみたいですが、インフラエンジニアのペパカレは今回が初めてだったようです。 ペパボカレッジについては詳しく知りたい方は下の記事を見てください！ www.wantedly.com やったこと 作業環境ハンズオン zshの導入 tmuxの導入

Mackerel Drink Upのご案内 エンジニアをワクワクさせるサーバー監視サービス「Mackerel（マカレル）」の7回目のDrink Upを、はてなの東京オフィスで開催します。 Drink UpはMackerelをお使いいただいてるユーザーの皆様に日頃の感謝を込めて、実施する交流イベントです。 当然、お食事やお飲み物は弊社側で用意させていただきます。 他のMackerelユーザーが、どういう活用をしているか直接たずねたい 新しく出たMackerelの機能をどう使うか皆の意見を聞いてみたい Mackerelスタッフに要望を伝えたい Mackerel導入までの苦労話がしたい／聞きたい などのニーズがございましたら、ぜひご参加ください。 参加資格 Mackerelをご利用中のエンジニアの方(Freeプラン可) 開催概要 日時：2018年4月24日（火） 18:15受付開始、18:30ス

こんにちは。Mackerel開発チームディレクターの id:daiksy です。 Mackerelチームでは、開発プロセスにおけるプラクティスや、チームをうまく機能させるための様々な取り組みに対して、普段から定期的なカイゼンを行っています。 世の中は新年度を迎え、いろいろと新しい取り組みにチャレンジしやすい時期でもありますし、Mackerelチームで行った最近のカイゼンの様子を簡単にまとめてみようと思います。 振り返りでKPTをやめた Mackerelチームではスクラムをベースとした開発サイクルを採用しており、1スプリント2週間というペースで開発イベントが計画されています。スプリント最終日に振り返りを実施し、2週間の間に起きた出来事や課題などを議論して、次のスプリントでカイゼンをする、というルーチンです。 チームではこれまで長い間、KPTという振り返りのフレームワークを採用していました。K

はじめに 初めまして、下記の記事にて紹介がありました インフラエンジニアの榎戸です。 golangを使って開発したWebAPIを1年半運用して改善してきたことー月間20億PVのマンガサービス開発の裏側 場数を踏んできたのかは分かりませんが 笑 23歳エンジニア歴は２年と浅めです。 まだまだ未熟なエンジニアですが 今回はPrometheus + Grafana について紹介させて頂きます。 内容については下記となります。 Prometheus導入の経緯 Prometheus概要 Prometheusでの監視構成 次回お知らせ それでは始めていきます。 Prometheus導入の経緯 まずPrometheusを導入した経緯について少しだけ触れたいと思います。 弊社では月間20億PVのマンガサービスやそれと並行して走っているマンガサービス、また動画配信サービスや、アプリゲームの配信なども行なって