2018/02/05 https://mackerelio.connpass.com/event/76678/
2018/02/05 https://mackerelio.connpass.com/event/76678/
この記事は、Mackerel Advent Calendar 2017の19日目の記事です。 前日は fullsat_ さんによる Lambdaを使ってMackerelのアラートをRedmineのチケットにする でした。 ウェブシステムの障害発生時に、どのコンポーネントの処理が滞っているかをざっくり知りたいことがあります。 そこで、ウェブシステムは待ち行列の集合体であることに着目し、各コンポーネント状態を把握するダッシュボードを最近作成しています。 待ち行列については、自分もそれほど詳しいわけではありませんが、待ち行列システムをみるとざっと把握できます。 簡単な例として、安定した系であれば、リトルの法則により、平均待ち行列数Lは、平均到着率λと平均待ち時間Wの積に等しいことがわかっています。 リトルの法則とキャパシティプランニング - ゆううきメモ これらのパラメータをウェブシステムでよく
先日開催されたServerlessconf Tokyo 2017にスピーカーとして参加しました。 2017.serverlessconf.tokyo Mackerelの今の時系列データベースは、マネージドサービスを組み合わせて作っています。 検証・実装・投入フェーズを終えて、運用・新機能開発フェーズに入っています。そんな中で、監視サービスを提供する私たちが、サーバーレスアーキテクチャで作ったミドルウェアをどのように監視しているかについてお話しました。 何かしら役に立つことや発想の元となるようなことをお伝えできていたらいいなと思います。 私も他の発表から様々なことを学びました。特に面白かった発表を挙げておきます。 真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用 ゲーム開発を支えるBaaSを開発されるなかで得られた様々な知見についてお話されていました。 プッシュ通知のために大量の
だいぶ遅くなっちゃった。10月5日開催の Mackerel DAY で登壇していただいたユーザー企業・四社の発表内容のポイントとサマリーを、今更ながらにまとめた。どちらかというと自分用メモ。 アプリケーションエンジニアがMackerelで楽しく監視構成している事例・DMM.com ラボさん アプリケーションエンジニアがMackerelで楽しく監視構成している事例 from Keiko Nishioka www.slideshare.net ポイント 「アプリケーションエンジニア」が Mackerel というツールをどのように捉えているか、という貴重な事例! アプリケーションもインフラも、と、エンジニアの責務は増える・広がる傾向は業界としてあると思う 同じような境遇の方の判断材料のひとつになるのでは。 アプリケーションエンジニアなので「コード」を書いたり管理するのは得意! 監視設定の
去る 10月5日に、Mackerel DAY というイベントが開催された。サーバー監視サービス・Mackerel のリリース3周年を祝っての大型イベントで、豪華登壇陣をゲストに迎え、お昼過ぎから懇親会まで、非常に濃密な時間だった。僕もスタッフとして参加し、また登壇もさせていただいた(僕の登壇スライドはこちら)。 豪華登壇陣、と書いたが、本当に豪華で、非常に多種多様な観点でのお話を聴くことができ、中の人としても・いちユーザーとしても、大変貴重な時間だった。そんななか、ガツンと脳天に響いたセッションが、メルカリ社の SRE チーム所属・プリンシパルエンジニアの id:kazeburo ( @kazeburo )さんの発表だった。 speakerdeck.com 内容としては、メルカリ社における Mackerel のサービス/ロール設計のお話と、独自に作成しておられるカスタムスクリプト/プラグイ
先週、とうとう Mackerel にグラフアノテーション機能がリリースされました。 mackerel.io この機能を使えば、「デプロイ実施」とか「ミドルウェアの設定を変更」などといったオペレーションの実施の記録に加えて、「経験値2倍キャンペーン開始」「CM放映スタート」といったビジネス施策としてのイベントの投稿もできるようになります。これらのイベントの以前・以後、といったグラフの見方がしやすくなるので、これは便利!! "Mackerel オタク" を自称している身(参考)としてはスルーできないワクワク機能!ということで、早速自分のアプリケーションにも組み込んでみることにしました。 capistrano のデプロイタスクにグラフアノテーションの POST を組み込む 今回はとりあえずのお試しということで、capistrano のデプロイタスクのうち deploy:starting でデプロ
この記事は Mackerel Advent Calendar 2016 の 12/13 日の記事です。 はじめに 皆さんは golang で書かれたプロセスの監視はどの様に行われているでしょうか。builderscon 2016 でも登壇された Dave Cheney 御大の gcvis をお使いでしょうか。 確かに gcvis は便利なのですが一つ悩ましい点があり、gcvis 自信がプロセスを起動しないといけないという点にあります。作り上致しかたないのですが、コマンド引数にて起動するプロセスを指定する仕様になっています。つまり起動には gcvis が必要になるのです。監視の際にアプリケーションを止められるのならばいいのですが、そうでないときは使えない事もあります。 ところで昨日 golang で書かれたプロセスを監視/操作するためのツール「gops」をご紹介しました。 この gops で
SREチームの @siroken3 です。 以前、メルカリでリリース手段としてChatOpsを採用していることを本ブログで紹介しました。今回は内部で使っている技術の一部を紹介したいと思います。 tech.mercari.com tl;dr メルカリではデプロイにAnsible使ってる 毎日デプロイしつつサーバが増加/入れ替え激しいと心が削れる MackerelのAPIとAnsibleを組み合わせたらハッピーになった Insideデプロイ メルカリではデプロイ用のサーバでSlack Botが働いており、デプロイの事前要件を満たしているか確認した後、大まかには以下の処理を実行しています。 GitHubからデプロイ対象ソースの取得 composer install / gulp などのビルド処理 対象サーバにrsyncでデプロイ これらの処理は構成管理ツールであるAnsibleを使用しています。
この記事は, Mackerel Advent Calendar 2015の21日目の記事です. 昨日の記事は, @stanakaさんの年末年始のディスク容量アラートを回帰分析で回避しようでした. はじめに ...まず最初に, せっかくの機会なので自分とMackerelの関係(?)について書いておこうかと思います. Mackerelを使い始めたのはかなり初期で, 記憶ではベータ版が公開されてすぐに登録して, 私用で使っているVPSに導入して試していた記憶があります. とはいえいきなり事業に投入! という訳にはいかず(社内には既にZabbixなどを使った監視の仕組みがあったので), そこから1年くらいは定期的に開催されるMackerel Meetupに参加するなどして情報を集めていました. 流れが変わったのは, 今年の春のことです. いろいろあってReactioチームに所属することになり, そ
Norikra でクエリした結果を Mackerel に投げたい場合、これまでは fluent-plugin-norikra で取得して fluent-plugin-mackerel で送信する、という作りにしていたと思います。 Norikra 1.2以降では Listener plugin が使えるようになったので、クエリ結果を直接 Norikra 上で扱うことが可能になりました。 ということで、norikra-listener-mackerel (rubygems) を書きました。Norikra 単体で、クエリ結果を Mackerel のサービスメトリクスとして送信できます。 使い方 $ gem install norikra-listener-mackerel norikra が動作する ruby でインストールすれば、norikra start 時に自動的に読み込まれます。 クエリ
前々から書こうと思ってて, すっかり忘れてたので, 書きます! Mackerelの監視 Mackerelでは, ホストの状態(CPU, メモリ, ファイルシステムの利用率とか, Mackerelと繋がっているかとか...)やURLの死活などを監視することが出来るのですが, 8月末に監視設定APIがリリースされ, これらのパラメータをAPI経由で実施出来るようになりました. というわけでReactioの開発チームでも, 早速このAPIを利用して, 以下のような仕組みを作ることで, Mackerelの監視パラメータを"コード"で管理するようにしました. 仕組み Reactioには, 開発者支援ツールが詰め込まれた「Reactio-HQ」というリポジトリがあるのですが, そこにMackerelの監視設定ファイルを用意しました. ちなみにReactioの開発者支援ツールは, Reactioそのもの
Profile id: Songmu (ソンムー) Masayuki Matsuki おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU 趣味はCPANizeです はてな東京オフィス チーフエンジニア Mackerel ディレクター 最近作ったgoライブラリ https://github.com/Songmu/prompter https://github.com/Songmu/enslaver prompter Goでプロンプト簡単に出すやつ twitterID := prompter.Prompt("Enter your twitter ID", "") lang := prompter.Choose("Which language do you like the most?", [
追記(2015/08/14) Docker 1.8 のリリースに含まれていた追加仕様 により dd-agent からホスト側 cgroup のマウントポイントが見えない状態が発生していたようだ。 github.com 既に上記にて対応済みとなっているが、まだ dd-agent の最新版には反映されていないので注意が必要。すぐに対応が必要な場合には以下のように最新の docker.py を取得して独自にコンテナをビルドする必要があると思われる。 $ git diff Dockerfile diff --git a/Dockerfile b/Dockerfile index 17f11f5..d4a1343 100644 --- a/Dockerfile +++ b/Dockerfile @@ -26,7 +26,12 @@ RUN mv /etc/dd-agent/datadog.conf.
久しぶりに喋ってきました。Mackerel meetup #4とShibuya.pm Tech Talk #17ではLTを、Norikra meetup #2では少し長めの話をさせて頂きました。 資料3つ貼っておきます。 メルカリでもサーバ・運用周りの仕事をしています。メルカリではzから始まるモニタリングツールをメインに使用していて、サーバ周りのさまざまなデータを突っ込んで監視に役立てていますが、カジュアルにグラフをつくって、アラートを仕掛けるという用途には向いていないなぁと思ってます。 そこで、Norikra と Mackerelを組み合わせて柔軟にログの可視化+閾値の設定を行うってのを思いついて設定したところ、結構うまく行って、それについてtwitterでつぶやいていたところ、今回のような機会を頂いたというわけです。 harukasanのログ解析ツールのまとめは非常にわかりやすく、fu
今週のMackerelアップデートです。 スクリプトによるチェック監視ができるようになりました Nagiosプラグイン互換のフォーマットで監視結果を出力するコマンドをエージェントに登録することで、その出力を可視化し、監視対象とすることができるようになりました。 この機能を活用することで、より柔軟な監視が可能となります。 詳しくはヘルプをご参照ください。 mackerel.io また、当機能を利用するにはmackerel-agent 0.16.0 以降が必要となります。 任意のタイムゾーンを設定できるようになりました グラフや通知時に表示される時刻に対するタイムゾーンの設定を、オーガニゼーションごとに任意に設定できるようになりました。初期値はご利用のブラウザのユーザエージェントから取得されます。 設定はオーガニゼーションの詳細設定 で変更していただけます。 検索結果から退役したホストを除外で
チェック監視はチェックプラグインの実行結果を監視する機能です。エージェントはチェックプラグインを定期的に実行し、その結果を Mackerel に送信します。チェック監視項目は 1 つあたり 1 ホストメトリックとしてカウントされます。ホストメトリック監視やサービスメトリック監視との違いについては メトリック監視とチェック監視の違い を参照してください。 チェックプラグインについて エージェントへの設定例 設定項目 action の記述方法 action で利用可能な環境変数 環境変数の活用例 チェックプラグイン仕様 チェック監視のアラート通知 メトリック監視とチェック監視の違い Ruby によるチェックプラグインのサンプル チェックプラグインについて チェック監視を行うためには目的の監視処理を行うプログラムが必要です。そのために利用できるものとして、公式のチェックプラグイン集を公開していま
『ユーザーストーリーマッピング』 出会いと適用 / User Story Mapping encounter and application
AWSでautoscallingを使用しているとインスタンスが不定期で入れ替わるので、ターミネートされるタイミングでmackerel上で退役扱いにしてあげることが必要なんですが、Amazon Linuxだとなんかうまくいかなくてその時のメモ。 やることは一つでmackerelのAPIをコールする起動スクリプトを作成し、chkconfigで登録するだけ。 #!/bin/bash ### BEGIN INIT INFO # Provides: mackerel-retire # Required-Start: $network $local_fs # Required-Stop: $network $local_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # description: mackerel retire ### END INI
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く