Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webサービスを監視するときに僕達が考えたこと / YAPC::Okinawa 2018

120b74af626c2b23f954926ef68ac5d6?s=47 papix
March 03, 2018

Webサービスを監視するときに僕達が考えたこと / YAPC::Okinawa 2018

120b74af626c2b23f954926ef68ac5d6?s=128

papix

March 03, 2018
Tweet

Transcript

  1. Web サー ビスを監視するときに 僕達が考えたこと by id:papix (@__papix__) 株式会社はてな

  2. papix 株式会社はてな アプリケー ションエンジニア (2017 年2 月~) 「 はてなブログ」 をつくっています

    アカウント類 はてな: i d : p a p i x Twitter: @ _ _ p a p i x _ _ GitHub: p a p i x CPAN: P A P I X ブログ: h t t p s ? : / / p a p i x . h a t e n a ( b l o g . ( c o m | j p ) | d i a r y . j p ) / 趣味はPerl と, ( 交通機関を利用した) 旅行など 去年JGC 修行を完遂しました, 折を見てSFC も修行したい...
  3. 「 僕達が考えたこと」 シリー ズ第三弾 YAPC::Hokkaido 「API をPerl で作る時に僕達が考えたこと」 YAPC::Kansai 「Perl

    のWeb アプリケー ションをデプロイする時に僕達が考え たこと」 YAPC::Okinawa 「Web サー ビスを監視するときに僕達が考えたこと」 ←NEW!
  4. 想定している聴衆 初心者向けを想定した内容です: "Web サー ビスの監視" について思いを馳せたことのない学生さん Web サー ビスの監視についての知見が欲しい/ 意見交換がしたい,

    主 にWeb アプリケー ション開発に従事するエンジニア このトー クをきっかけに, 「Web サー ビスの監視」 について思いを馳せて みましょう!
  5. もくじ なぜ僕達は" 監視" をするのか 監視する時に有用なメトリック達 どこまで検知して, 通知する? Web サー ビス開発の現場での監視

    おまけ: まず初めてみる? おうち監視!
  6. Web サー ビスを監視するときに 僕達が考えたこと by id:papix (@__papix__) 株式会社はてな

  7. なぜ僕達は" 監視" をするのか

  8. サー ビスに這い寄る障害達 Web サー ビスには様々 な障害が起きる: ネットワー ク/ サー バの不調...

    爆発的アクセス増による高負荷... バグやオペレー ションミス... どれだけ優秀な人員を揃えても, どれだけ設備投資をしても, どれだ け慎重にオペレー ションしても, 障害は必ず起きる
  9. 障害対応のサイクル 障害対応は次のように対応される: 障害の検知 調査と解決 事後対応と振り返り

  10. 障害の検知 障害が発生したことに気づく段階 ドッグフー ディングをしていて ユー ザからのお問い合わせ Twitter などのSNS でのユー ザの声

    "Web サー ビスの監視機構" から通知が届いて このトー クでは, この" 監視" の部分にフォー カスを当てて 話をします なるべく迅速に気付きたい " 予兆" の段階で気づければ, 実際にユー ザに影響が出る前に対 処できる
  11. 調査と解決 発生している障害の原因を調べ, 解決するために修正やオペレー シ ョンをする段階 憶測ではなく, 事実に基づいて原因を見つける 焦りがちだけれど, 障害の対応が更なる障害を生み出さないよ うに,

    丁寧に ペアプロ/ ペアオペなどで作業を進めていくのも有効 このトー クで話す" 監視" によって得られる情報は, このフェイズでも 非常に役立ちます
  12. 事後対応と振り返り 暫定対応で障害を解決した場合, その恒久対応が必要 また, 再発防止策となる実装, オペレー ションも考慮しないとい けない 似たような障害が発生した時に備えて, 障害の原因や対応を振り返

    り, 共有することも重要 社内障害情報共有のススメ http://developer.hatenastaff.com/entry/2018/02/19/180000
  13. なぜ僕達は" 監視" をするのか 障害の迅速な確認 Web サー ビスに問題があった時, 1 秒でも早く気付き, 対応出来

    るようにする 障害対応の道標 監視の結果から手がかりを得て, 1 秒でも早く障害を解決するこ とを目指す
  14. 障害対応の道標 ~ 推測するな, 計測せよ~ ISUCON でよく聞く言葉 元はRob Pike 氏( 現Google,

    Go の開発者) の発言だそう: ルー ル1: プログラムがどこで時間を消費することになるか知ること はできない。 ボトルネックは驚くべき箇所で起こるものである。 し たがって、 どこがボトルネックなのかをはっきりさせるまでは、 推 測を行ったり、 スピー ドハックをしてはならない。 ルー ル2: 計測すべし。 計測するまでは速度のための調整をしてはな らない。 コー ドの一部が残りを圧倒しないのであれば、 なおさらで ある。
  15. 障害対応の道標 ~ 推測するな, 計測せよ~ 「Web サー ビスの開発/ 保守/ 運営」 でも同様

    日頃から, Web サー ビスやそれを構成するインフラを監視する その情報が, 問題発生時の助けになる 医者の手術と一緒 人体という複雑なシステムと立ち向かう為に, 心拍数, 血圧, 体 温などを計測しながら手術をする Web サー ビスもまた複雑なのである...
  16. Web サー ビスの障害対応 確認が必要な範囲がとにかく広い ネットワー ク, インフラ, ミドルウェア, アプリケー ション...

    全てのレイヤー を手探りで調べるのは非効率 監視とその結果で, 怪しい範囲を絞り込むことができる もちろん, そこから一気に原因を特定できる時もある
  17. Web サー ビスに必要な" 監視" とは? 個人的には, 以下の5 要素が重要: 管理 可視化

    蓄積 検知 通知
  18. 管理 「Web サー ビスを構成する各種インフラ( サー バ/ ミドルウェア) を紐付け て, 役割や状況を明示する」

    これによって, Web サー ビスがどのように構築され, どのように稼働 しているか一目瞭然となる 加えて, これを" 管理台帳のマスター" として, 日々 のオペレー ション に活用することもできる 監視だけじゃない! デプロイにMackerel を使う話 http://tech.mercari.com/entry/2016/11/14/120000
  19. 可視化 「Web サー ビスとそれを構成する各種インフラの状態を, 数値( メトリッ ク) として取得/ 表現し, 統一されたインター

    フェイスで確認できる」 これによって, Web サー ビスを構成する各種インフラの状態を, 数値 で言及することが出来るようになる 障害対応で切羽詰まっている時に, 「 詰まっていそう」「 負荷高そ う」 といった, 抽象的な言葉は混乱を呼び起こす可能性がある 更に, 統一されたインター フェイスで, 複数のインフラの状況を一気 に見る/ 見比べることができる 結果として, Web サー ビスの様子が一目瞭然になる
  20. 蓄積 「 可視化のために取得したメトリックを蓄積し, 時系列に並べて, 表やグラ フで表現出来るようにする」 これによって, 可視化した値の特異点がグラフィカルに認識できる ようになる Web

    サー ビスに何か問題があれば, 表は急激な凹凸を示す 加えて, Web サー ビスとそのインフラの日常の傾向を追いやすくな る 日中はアクセスが増える/ 深夜は減る, など...
  21. 検知 「 可視化のために取得したメトリックに応じて, Web サー ビスやそれを構 成するサー バ/ ミドルウェア等が異常かどうかを識別する」 これによって,

    Web サー ビスやサー バ/ ミドルウェア等のインフラ要 素に対して「 異常な状態」 を定義できる メモリ使用率が80% を越えたら警戒状態, 90% を越えたら異常 状態, など... この定義を定めるのが非常に難しい( 後述)
  22. 通知 「 検知した内容を適切に通知して, 調査や対応を促す」 これによって, 開発者が常時監視していなくても, 異常状態が発生し たことを認知することができる 常時監視しなくても良いとは言え, 誰かが気付けるような体制

    を構築することは重要 その辺りは「 運用」 の話でもあるので, 今回は割愛
  23. " 監視" を実現するツー ル達 それぞれ特長や, 得意/ 不得意がある SaaS かOSS か

    push 型かpull 型か
  24. SaaS かOSS か SaaS 管理/ 可視化/ 蓄積の仕組みがWeb サー ビスとして提供される( フ

    ルマネー ジド) 大抵の場合, 監視するサー バの台数によってコストが線形的に 増加する OSS 各自でサー バを用意して, その上に監視の仕組みを構築する( セ ルフホスティング) 構築/ 運用コストが必要だが, 監視するサー バの台数によって線 形的にコストが増えることはない とはいえ, SaaS でもセルフホスティングが可能なものもあり, OSS でもフルマネー ジドなものもある
  25. push 型かpull 型か 監視するサー バから, どのようにしてメトリックを収拾するか push 型 各サー バから,

    メトリックを蓄積するサー バに投げる pull 型 メトリックを蓄積するサー バが, 各サー バにリクエストを投げ て取得する
  26. 具体例 DataDog Mackerel NewRelic Prometheus Zabbix ※ このトー クでは, 例として筆者が使い慣れているMackerel

    を中心に取り 上げます
  27. 監視する時に有用なメトリック達

  28. 監視する時に有用なメトリック達 " 監視" の仕組みを導入することで, Web サー ビスとそのインフラに 関連する様々 なメトリックを可視化/ 蓄積できる

    しかし, ただ単に" 監視" するだけでは意味がない それらのメトリックの意味, 傾向を掴まなければ, いざと言う時 に役に立たない
  29. 監視する時に有用なメトリック達 Mackerel のエー ジェントをLinux のサー バに導入した際に自動的に 取得される, Linux のシステムメトリックを紹介します: l

    o a d a v g 5 c p u m e m o r y d i s k i n t e r f a c e f i l e s y s t e m
  30. l o a d a v g 5 言わずと知れた「 ロー

    ドアベレー ジ」 5 は5 分間平均( 一般に, u p t i m e や w コマンドでは1/5/15 分平 均のロー ドアベレー ジが見れる) さっくり言えば, 「 システム全体の負荷の様子」 を示す 実行待ちプロセス数と, I/O 待ちプロセス数の合計 = CPU 等に余裕があれば, すぐに実行されるプロセス数
  31. l o a d a v g 5 の見どころ 負荷が高まれば,

    その分 l o a d a v g 5 も上昇する システムやサー ビスの特性によっては, 常にロー ドアベレー ジ が高い場合もある 瞬間的な値ではなく, その数値の傾向を見るのが重要 急増した後, 減少の幅が少ない場合 一定のペー スで増加を続けている場合
  32. c p u CPU( 演算処理装置) の使用率を表す 用途ごとに細かく利用率が見れる: 意味 user カー

    ネル以外( アプリケー ション) が利用したCPU 時間の割合 (nice は含まない) system カー ネルが利用したCPU 時間の割合 iowait I/O 待ちによってCPU が利用されていない時間の割合 idle CPU が使われていない時間の割合(iowait は含まない)
  33. c p u 意味 nice 優先度(nice 値) が指定されたアプリケー ションによるCPU 時

    間の割合 irq ハー ドウェア割り込みによるCPU 時間の割合 softirq ソフトウェア割り込みによるCPU 時間の割合 steal ゲストOS( 仮想マシン) が割り当て待ちとなった時間の割合 guest ゲストOS( 仮想マシン) によるCPU 時間の割合
  34. c p u の見どころ ロー ドアベレー ジと同じく, 負荷が高まればCPU 利用率も高まる サー

    バ上で動作するアプリケー ションやミドルウェアの負荷が 高まれば u s e r の割合が増える アプリケー ションやミドルウェアによるI/O がディスクのI/O 性 能に追いつかない場合, i o w a i t が増える Xen やKVM などの仮想化環境を使っていて, その負荷が高まれ ば s t e a l や g u e s t なども見る必要がある
  35. c p u の見どころ ロー ドアベレー ジと同じく, システムやサー ビスの特性によって値 は変わる

    CPU 利用率を可視化/ 蓄積し, 日頃から傾向を掴んでおくことが 大事( 後述) また, CPU 利用率が低い(= i d l e が多い) ことは, それもまた一種の 問題である CPU 利用率が低い = サー バを効率的に利用できていない 「 負荷低すぎはもはや障害じゃないのか」 http://mikeda.hatenablog.com/entry/2015/02/01/195102
  36. m e m o r y メモリの利用量を表す Mackerel では, u

    s e d + b u f f e r s + c a c h e d + f r e e = t o t a l を前提とする 意味 total 物理メモリの総容量 used 利用している物理メモリの容量 cached ペー ジキャッシュに使われている物理メモリの容量 buffers バッファに使われている物理メモリの容量 free 利用されてない物理メモリの容量
  37. m e m o r y の見どころ Linux では, 利用可能なメモリがあれば,

    ペー ジキャッシュ( c a c h e d ) とバッファ( b u f f e r s ) のために積極的に利用される アプリケー ションによってメモリが必要になった時に開放され る そのため, " メモリの利用率" を考えるなら, u s e d / t o t a l で 考える必要がある Linux kernel 3.14 以降では, M e m A v a i l a b l e というパラメー タがあ る 開放不可能な c a c h e d / b u f f e r s も考慮されている
  38. m e m o r y の見どころ 一方, スワップのメトリックとして, s

    w a p t o t a l , s w a p u s e d , s w a p c a c h e d がある スワップは多くの場合HDD/SSD 上に作られる 物理メモリに比べて速度が遅いため, スワップの発生 = パフォ ー マスの低下と言える 特にWeb サー ビスが稼働するサー バでは, 基本的に「 スワップは発生 させない」 ように意識するべき メモリの利用量が漸増している場合, メモリリー クなど発生してい ないか調査する必要がある
  39. d i s k ディスクの読み書きに関するメトリック 単位はIOPS(= 1 秒辺りに処理できるI/O の数) ディスクのIOPS

    性能は明示されていることが多い Amazon Elastic Block Storage(EBS) でも, IOPS 性能が違うデ ィスクを選ぶことができる
  40. d i s k の見どころ IOPS の余裕がなくなると, ディスクの書き込み/ 読み込みが詰まる RDBMS(MySQL

    など) が動くサー バでは特に重要 IOPS の日頃の増減傾向と, 今後起こりうる瞬間的なIOPS 増(Web サ ー ビスにとってはアクセスの急増) に耐えれるかどうかを見極める 中長期的な視点で監視し, 手を打つことが重要
  41. i n t e r f a c e ネットワー

    ク帯域の利用状況を表す t x が送信, r x が受信, 単位は K B / 秒 ちなみに t x は t r a n s m i t , r x は r e c e i v e のことらしい これもまた, インフラ提供者によってネットワー ク帯域に上限が定 められている クラウドの場合, 更に課金額にも影響が出る
  42. i n t e r f a c e の見どころ

    Nginx やApache が動くプロキシサー バ, コンテンツを配信するサー バでは t x , r x が増えがち コンテンツを配信するサー バであれば, CDN を通すなどで対策 出来る 急激な t x / r x の増加があれば, 瞬間的なアクセス増やDoS 攻撃な どの可能性がある
  43. f i l e s y s t e m

    ディスクとその使用量を表す s i z e はディスクの最大容量, u s e d はディスクの使用量 例えばRDBMS が動くサー バでは, デー タが蓄積される毎に u s e d が 増えていく 言うまでもなく, ディスクの空き容量がなくなると書き込めな くなるので, その前に最大容量を増やす必要がある また, ミドルウェアなどのログの書き込みでも u s e d が増えて いく
  44. f i l e s y s t e m

    の見どころ ディスクの空き容量をすぐに増やせない場合も有り得るので, ある 程度の利用率を越えたら警告するようにしておく 定期的に u s e d の増加量を確認し, 警告が出て, 危険な領域に達 する前に最大容量を増やせるのがベスト u s e d が急激に増えている場合, Web サー ビスやミドルウェアのロ グの出力設定を変更している場合などもある ログがより詳細に出るようになって, 大量のログがディスク上 に保存されている状態
  45. 監視する時に有用なメトリック達 ここまで紹介した6 つのメトリック以外にも, Web サー ビスやそれを 構成するインフラの監視に有用なメトリックがあります アクセスログ( アクセス数, ステー

    タスコー ドの割合, レイテン シ) 外形監視 uptime サー ビス/ ミドルウェアに特化したメトリック
  46. アクセスログ Nginx など, プロキシのアクセスログからメトリックを取得する Mackerel なら: https://github.com/mackerelio/mackerel‑agent‑ plugins/tree/master/mackerel‑plugin‑accesslog

  47. アクセスログ Access Num 1 分間辺りの総リクエスト数と, ステー タスコー ドごとのリクエ スト数 ステー

    タスコー ドは100 の位ごとにまとめられる. A c c e s s R a t e も同様 Access Rate 1 分間辺りのステー タスコー ドの割合 Latency A v e r a g e ... リクエストにかかった秒数( レイテンシ) の平均 9 0 P e r c e n t i l e ... レイテンシの下位90% の秒数 9 5 P e r c e n t i l e ... レイテンシの下位95% の秒数 9 9 P e r c e n t i l e ... レイテンシの下位99% の秒数
  48. アクセスログの見どころ A c c e s s N u m

    Web サー ビスへのアクセス数が増えれば, T o t a l C o u n t が増 えていく A c c e s s R a t e デプロイ後など, バグがあれば H T T P 5 x x P e r c e n t a g e が上昇 しがち L a t e n c y 高負荷によって, CPU 利用率が増えたり, IOPS が上限に達した 場合, レイテンシに影響が出て来る
  49. 外形監視 実際にWeb サー ビスにリクエストを行い, 期待するレスポンスが得 られるか確認する レスポンスのステー タスコー ドなどを確認

  50. 外形監視の見どころ 外形監視の結果が異常であれば, 即ち現在進行系でユー ザに影響が 出ているということ とはいえ, ネットワー クの状態等で偽陽性となることもある レスポンスタイムが遅くなっているなら, レイテンシの様子なども

    見て調査を検討する必要がある
  51. uptime Linux などのOS が, どれくらいの時間稼働しているかを示す Mackerel なら: https://github.com/mackerelio/mackerel‑agent‑ plugins/tree/master/mackerel‑plugin‑uptime

  52. uptime の見どころ uptime が0 になるということは, OS が再起動されたということ つまり, サー バが再起動されたということ

    意図しない再起動であれば, 調査をする必要がある
  53. サー ビス/ ミドルウェアに特化したメトリック Mackerel の場合, プラグインでサー ビス/ ミドルウェアに特化したメ トリックを取得できる https://github.com/mackerelio/mackerel‑agent‑plugins

    Nginx/Apache/h2o といったプロキシ, MySQL/PostgresSQL といっ たRDBMS, Redis/Memcached といったKVS, AWS の各サー ビスな どを対象にしたプラグインが提供されている
  54. 任意のメトリックを取得したい! ~Mackerel では?~ 既存のプラグインで取得できないメトリックであれば, Go 言語でプ ラグインを作り, メトリックを取得して投げればよい g o

    - m a c k e r e l - p l u g i n というヘルパー がある https://mackerel.io/ja/docs/entry/advanced/go‑mackerel‑ plugin とはいえ, フォー マット(Sensu のフォー マットと同じ) が同じであれ ば, Shell Script やPerl, Ruby などで実装しても構わない 公式のプラグインリポジトリ以外にも, ユー ザがそれぞれプラグイ ンをGitHub などで公開していることがある
  55. どこまで検知して, 通知する? ~ 狼少年にならないために~

  56. 正しく検知する難しさ Web サー ビスを監視する時に一番難しいのは, 「 検知の条件」 を組み 立てる部分では...? Web サー

    ビスやそれを構成するインフラが, 異常な状態であれ ば必ず検知したい( 当たり前) 日常的に発生するピー ク, サー ビスの成長による( 想定の範囲内 の) 負荷の上昇は異常な状態としたくない 障害として検知する条件を... 厳しくすると, 実際には問題がないのに, 障害として検知され, 通知が行われてしまう(= 狼少年検知) 緩くすると, 実際に障害が発生するのに, それを検知できなくな ってしまう 一般には「 厳しくしすぎて, 狼少年通知が多発する」 パター ンが多い気がします...
  57. 狼少年検知 「 狼少年」 の寓話 「 狼が来た!」 と嘘をついて騒ぎを起こし続けて, 遂に本当に狼が 来た時に, 「

    狼が来た!」 と言っても誰も相手をしてくれなかった 「 狼少年検知」 Web サー ビスやそのインフラのメトリックに問題がないのに, 異常があると検知され, その通知が飛ぶ状態が続くと, それに慣 れてしまう 本当に対処するべき問題とその通知が, 問題がない通知に埋も れてしまう
  58. 「 狼少年検知」 を防ぐには? 検知の条件/ 通知の条件を定期的に棚卸しする 「 狼少年」 にならないように, 異常状態として検知条件を緩和す る(

    メトリックがより高い数値になったら通知をするようにす る) 前述の通り, 緩和しすぎると逆に異常状態であることに気づけ なくなってしまう 逆に, Web サー ビスやインフラの整備で, 平常時のメトリックの値が 低く推移するようになったら, 通知条件を厳格化する必要がある 棚卸しに活かすためにも, サー ビスの負荷の傾向を追う必要がある
  59. サー ビスの負荷の傾向を追う メトリックが常に同じ値を示し続けることはない 様々 な単位で凹/ 凸のピー クがある サー ビスの負荷( メトリックの変化)

    の傾向を把握することが重要 通知の条件を見直す材料になる メトリックに異常値が発生したときの判断材料になる
  60. 年単位の傾向 年単位のイベントによって負荷が変動することがある 例: 年末年始のLINE, メー ル送信 「 あけおめメー ル」 を送受信するので,

    負荷が高まる
  61. 月単位 月単位のイベントによって負荷が変動することがある 例: 月末/ 月初 Web サー ビスに月単位のイベントが存在するとき, それによっ て負荷が高まる可能性がある

  62. 日単位 週単位のイベントによって負荷が変動することがある 例: B2B サー ビスであれば, 週末や祝日は負荷が低まる 企業向けのサー ビスなので, 企業が休業であることの多い休日

    は利用することが少ない
  63. 時間単位 時間単位のイベントによって負荷が変動することがある 例: 昼休み ブログなどは, 昼休みに閲覧するユー ザが多いので, 12 時前後に ピー

    クが現れる 例: 深夜帯 深夜帯は日中に比べて負荷が低まることが多い( ユー ザが寝て いるので)
  64. 検知からの通知 メトリックの変化を検知できれば, Web サー ビスの問題発生をいち 早く気づくことができる しかし, 可視化されたメトリックを四六時中眺め続けているの は現実的ではない 「

    適切に」 通知をして, メトリックから問題を検知した時に気づ けるようにしないといけない
  65. 監視の結果を通知したい! ~Mackerel では?~ メトリックの値が一定値を越えたり, 外形監視の結果に問題があっ た時, Warning/Critical の通知を送ることができる 対応している送付先: メー

    ル, Slack, HipChat, PagerDuty, ChatWork, TypeTalk, OpsGenie, Reactio, Yammer, LINE, Twilio Twilio を使うことで, 電話での通知も対応することができ る Webhook の送信にも対応しているので, 独自の通知サー ビスと 連携することも可能
  66. 「 通知をしない」 という選択肢 メトリックが異常値になり, 異常状態と検知されることが明らかな 場合, 一時的に通知をOff にすることも有効 瞬間的に高負荷になることが事前に明らかになっている場合 プレスリリー

    スが出る, テレビ/ ニュー スで紹介される等... Mackerel なら... 監視ルー ル単位で時間指定ミュー トをおこなえるようになりま した ほか https://mackerel.io/ja/blog/entry/weekly/20180219
  67. Web サー ビス開発の現場での監視 ~ はてなブログの場合~

  68. None
  69. はてなブログ 今年でリリー スから6 年 今すぐ登録→ h t t p s

    : / / b l o g . h a t e n a . n e . j p / r e g i s t e r Web アプリケー ションエンジニア5 人(+ アルバイト) で開発中 3 人が京都オフィス, 2 人が東京オフィスのリモー ト体制 インフラはAWS もちろんMackerel も活用中
  70. Mackerel を活用した取り組み ‑ PWG Performance Working Group 毎月1 回開催 (

    はてなブログ担当の)Web オペレー ションエンジニアも参加 Mackerel のグラフを見ながら, パラメー タの変化を確認 対応が必要なものはGHE にIssue を立てて着手 たくさんのホスト/ メトリックがあるので, 重要度の高いものをダッ シュボー ドにまとめている
  71. ダッシュボー ドの様子

  72. グラフアノテー ション " 可視化" の観点で非常に便利な機能 デプロイの度にアノテー ションを残す Description として, そのデプロイに紐付いたPull

    Request の URL を記載 グラフに急激な変化があった時, その原因となったPull Request を推 測しやすい
  73. グラフアノテー ションの様子

  74. サー ビスメトリック よくあるサー ビスメトリックははてなブログでも投稿しています ステー タスコー ドの割合, レスポンスタイム...

  75. デプロイにかかる時間 1 回のデプロイに要した時間を記録 c a r t o n _

    i n s t a l l ... ライブラリインストー ルにかかった時間 d e p l o y _ u p d a t e ... ファイルの配布にかかった時間 r e s t a r t ... プロセス再起動にかかった時間 可視化することで問題点を洗い出し, 改善することができる 詳しくは: はてなブログのデプロイを約6 倍高速化したはなし http://this.aereal.org/entry/2016/12/16/170000
  76. 更新が必要なnpm パッケー ジ y a r n o u t

    d a t e d で取得した更新が必要なnpm パッケー ジの数を投 稿し, Mackerel で可視化 詳しくは: 「 更新が必要なnpm パッケー ジを可視化する」 http://developer.hatenastaff.com/entry/2017/06/06/163000
  77. おまけ: まず初めてみる? おうち監視!

  78. まず初めてみる? おうち監視! 「Web サー ビス監視」 のツー ル/ サー ビスは, 身近なところから試して

    みよう 契約しているVPS とか, Mac とか... 一方で, " 自宅の監視" から試してみるのも手です!
  79. EdgeRouter X 米Ubiquiti 製のルー タ Amazon で1 万程度で購入できる割に高性能 VPN が設定できたりするので,

    ネットワー ク周りの技術の入門 にも有用 MIPS の上にEdgeOS が載っている EdgeOS はVyatta( ネットワー ク機器向けDebian ベー スのLinux OS) の派生版 故に, G O O S = l i n u x , G O A R C H = m i p s l e でビルドすれば, m a c k e r e l - a g e n t やGo 製のMackerel プラグインが動く! Perl も5.14.2 が入っている 他, "Raspberry Pi" の上で動かすなどの手もある
  80. mackerel‑plugin‑nasne

  81. mackerel‑plugin‑nasne https://github.com/ayumu83s/mackerel‑plugin‑nasne ソニー のHDD レコー ダー, "nasne" を監視するplugin(Go 製) 録画に成功/

    失敗した番組の数, HDD の残り容量などを監視でき る
  82. mackerel‑plugin‑nature‑remo

  83. mackerel‑plugin‑nature‑remo https://github.com/papix/mackerel‑plugin‑nature‑remo スマー トリモコン"Nature Remo" を監視するplugin( 拙作, Go 製) Nature

    Remo にある, 温度/ 湿度の測定機能の結果をMackerel に投稿できる
  84. Netatmo 温度, 湿度, 気圧, 二酸化炭素, 騒音を測定できるガジェット 10 分毎に値が更新, API 経由で取得できる

  85. Netatmo はてなでは... 社内の各フロアに設置されていて, 一定の数値を越えるとSlack に通知が飛ぶ

  86. さいごに

  87. さいごに 以下のテー マについて話しました: なぜ僕達は" 監視" をするのか 監視する時に有用なメトリック達 どこまで検知して, 通知する? Web

    サー ビス開発の現場での監視
  88. さいごに Web サー ビスが公開され, 利用者がいる以上, 障害は必ず起きます その時に備えて, " 監視" についてしっかり取り組む必要がある

    Web サー ビスの特性, 利用しているインフラ/ ミドルウェアの特性, 開発チー ムの特性など, 様々 な変数によって最適な" 監視" は変わる 変化を恐れず, 試行錯誤をしていきましょう! 知見を共有して, より良い" 監視" を目指していきたいものです...
  89. おわり ご清聴ありがとうございました!

  90. あわせてよみたい Mackerel サー バ監視[ 実践] 入門 http://gihyo.jp/book/2017/978‑4‑7741‑9213‑0 Mackerel でみる Linux

    システムメトリック項目の見方・ 考え方 http://blog.a‑know.me/entry/2017/02/02/215641 突然IT インフラを任された人のための… 監視設計入門 https://www.koemu.com/etc/yapcasia2014/