こんにちは。@katsuhisa__です。
本記事は、「New Relic Advent Calendar 2017」の12/21(木)分です。
前置き
過去、NewRelic に救われた経験があり、その時にどうやって活用していたかを書きます。
1つ1つの機能の使い方はまったくもって普通、かつ超基本的な機能しか活用しておらず、「おお、そんな使い方あったんだ」みたいな話は1つもないと思います。
その代わり、実際にインフラ運用やってる人がNewRelic をどんな感じで使っているのかは知っていただくことができます。
書こうと思っていることは、以下の4つです。
- 何かあればALERT が教えてくれる
- APM の活用「Apdex(Low)ALERT が出た時」
- APM の活用「Error percentage(High)ALERT が出た時」
- もっと早くALERT を整理すれば良かった話
対象読者
NewRelic の超基本はなんとなく知っている方
何かあればALERT が教えてくれる
当時は、監視のほぼすべてをNewRelic に依存していました。そのため、何かが起きたらNewRelic が教えてくれるという状況でした。
Apdexに関するALERT 設定
Apdex は、Apdex を定義してある団体のページに書かれてある通り、
Apdex is a numerical measure of user satisfaction with the performance of enterprise applications.
ユーザーの満足度を測定するための数値指標です。
NewRelic では、Apdex を自動で計算しグラフ化してくれる機能があります。
うちでは、Apdex に関するALERT を以下のように設定しています。
- Warning (yellow) threshold : Apdex < 0.85 for at least 10 mins
- Critical (red) threshold : Apdex < 0.7 for at least 5 mins
0.85, 0.7 に設定してある理由ですが、以下リンクの「What is a good Apdex value?」を読んで頂けると背景が詳しくわかると思います。
http://apdex.org/apdexfaq.html
客観的に見て、ユーザー体験が悪くなっている時にすぐ対応できるような閾値設定をしています。
Errorに関するALERT 設定
こちらは、Error percentage に応じてALERT をしてくれます。
具体的には、以下のように設定しています。
- Critical (red) threshold : Error percentage > 3 % for at least 5 mins
- Critical (red) threshold : Error percentage > 1 % for at least 10 mins
どちらもCritical threshold ですが、記載間違いではありません。これまでの運用経験と、Error percentage の過去の推移を見ていて、これくらいがちょうどよい塩梅だとして今は落ち着いています。具体的になぜこれくらいの閾値にしているか、過去の運用経験が気になる方はどこかの勉強会でお会いした時にでも話しましょう。
近い将来、Error percentage > 1 % for at least 5 mins に統合するつもりでいます。たった1つのエラーだったとしても、その向こうにはユーザーさんの残念体験があり、できるだけ多くのALERT 内容と向き合っていきたい気持ちがあります。ただ、その対応に限定されすぎてしまうと、より大きくユーザーさんに価値提供できる機能提供のスピード感が失われてしまうのはこの仕事の難しいところです。ちょうどよいって難しい・・・
さて、ここまでで、ALERT をどういう風に設定しているかについて書きました。次に、実際にALERT が出た時にAPM をどう活用しているかについて書きます。
APM の活用「Apdex(Low)ALERT が出た時」
TIME PICKER をLast 30 minutes ending now〜Last 3 hours ending nowあたりまで変化させながら、
- Web transactions timeをながめる
- Transactions をながめる
- Web transactions percentiles をながめる
の3つを行います。(もちろん他の機能も見ていますが、多くの場合この3箇所を見れば初期確認としては十分なことが多いです。)
Web transactions timeをながめる
大域的な状況把握として、真っ先に見ることが多いです。
Middleware, Ruby, Database, Web external の比率をそれぞれチェックします。（うちはRuby on Rails アプリケーションなので、Ruby ）
ながめる観点としては、以下2つ。
- 突発的に増えているものなのか、徐々に増えているものなのか
- どこかの比率がいびつに増えていないか
具体的な切り分けの詳細はここではふれませんが、上記観点を持ちながらNewRelic の画面をながめると、障害の概要把握と、うまくいけば原因の切り分けが半分くらい終わります。
Transactions をながめる
次に、アプリケーションの問題起因でありそうな場合は、Transactions をながめます。
App performance から、どこの処理に時間がかかっているのかを見れば、後からログをgrep する時の手がかりがつかめます。ざっくりとRails に原因がありそうなのか、SQL に問題がありそうなのかが把握できるだけでもかなり救われますね。
Web transactions percentiles をながめる
こちらは、大域的な状況把握をする際に補助的に利用することが多いです。
APM の活用「Error percentage(High)ALERT が出た時」
次に、「Error percentage(High)ALERT が出た時にどこを見ているかを紹介します。
もちろん、サイドメニューEVENTS から、Errors を見ます。
まずは、Error Rate の推移グラフを見て、今回も
- 突発的に増えているものなのか、徐々に増えているものなのか
を確認します。
次に、とにかくCount に注視して表示されているError のテーブルをながめます。
見慣れないエラーが突発的に出現した場合は、直近のデプロイを疑います。
また、徐々に増えている場合は、エラーCount がどんな割合で存在しているかを見ます。その結果、既知のエラーを取り除きながら、対象のエラーを絞り込むことが多いです。
ここまでで、ALERT が出た時に具体的にどうやってNewRelic を活用しているかのお話が終わりました。最後にちょっとした失敗談を共有して記事の締めくくりとします。
もっと早くALERT を整理すれば良かった話
過去、検証環境のALERT を、本番環境と同じSlack チャンネルに流すようにしていました。
これは一刻も早くやめたほうがよかったです。複数の環境のALERT なんて混ぜないほうが見やすいに決まっています。
そもそも検証環境のALERT は本当にいるのか他のメンバーと話して、いらなかったら即止めましょう。
まとめ
以上で、インフラ運用すごいたいへんだった頃にNewRelic に救われた話を締めくくります。
NewRelic の基本機能をちゃんと活用することで、日々の運用作業がすごく楽になりました。
ほんとに素晴らしいサービスだと思うので、今後もがんがんつかっていきたいと思います！
なお、直近では、Elastic Stack でつくったログ解析基盤を併用することで、1つ1つのリクエストのより詳細な分析も即可能になりました。これにより、ALERT の初動確認〜原因分析まで非常にスムーズに行うことができるようになりました。SRE 本に書いてあるようなことを引き続き1つずつ実現していきたいと思います。
「New Relic Advent Calendar 2017」の他記事も改めて読んでみようと思います。
どうもお読みいいただきありがとうございました！
@katsuhisa__