はじめに
うちのサービスは1月の後半に正式リリースをして約2ヶ月。
スピード重視という言い訳をしつつ、監視をあまりやってこなかったのでここらへんでMackerelを使って監視していきたいと思う。
↓ 監視ちゃんと取り込むきっかけになった自分のブログ
Mackerelはサーバーの監視をするためのSaaSである。
特に何が良いって、はてなのインフラのノウハウがベースなのと、日本語ってのがいい。
似ているサービスとしては海外のDatadog
同じく海外のNew Relicがある。
そもそも監視の勉強が先？
自分は監視に関してはやんわりしか理解してないため、まずは入門本を読もうと思っていた。ただ、まずは監視の設定を先にやらないと今このとき何か起こったとき間に合わないため今回はMackerelの方を先に読んだ感じだ。
こちらは読む予定の本。
ソフトウェアエンジニアのための ITインフラ監視[実践]入門
目次
- 1章 Mackerelとは何か
- 2章 Mackerelをはじめる
- 3章 監視する
- 4章 アラートを通知する
- 5章 プラグインを作る
- 6章 各種ツール連携と運用の効率化
- 7章 クラウド環境におけるMackerel
- 8章 発展的な機能
- 9章 付録
学んだこと
Mackerelの設定本として買ったつもりが、監視をする意義や監視すべき設定など細かく書いてあってすごくためになった！監視の初学 + Mackerelの設定が同時にできるいうお得な気分だ。
第2章: Mackerelをはじめる
はじめてみた
導入して最初に目がついたのが、CPU200%。。。。（笑えないやつ）
でも、バッチ自体が止まったことないしなーとおもって細かくみてみると
stealに200%もとられている。
t2インスタンス特有？のCPUクレジットの枯渇が問題っぽいのかー。
確かに最近バッチサーバーはずっと動いてたから、こちらは他のインスタンスに変更しよう。
キャパシティプランニングへの応用
こういう言葉があること自体初めて知った。
システムに求められるキャパシティ要件として、ビジネスレベル(データ処理需要、同時利用ユーザー数、同時セッション数など)、サービスレベル(トランザクション量、ネットワークトラフィック量、応答時間など)、リソースレベル(CPU利用率、ディスク利用率、ネットワーク利用率など)を検討し見積もりをする。この際、現状の最大負荷だけでなく、将来予測される最大負荷時にもサービスの水準を維持できるような設計を検討する必要がある。
引用: https://it-words.jp/w/E382ADE383A3E38391E382B7E38386E382A3E38397E383A9E383B3E3838BE383B3E382B0.html
まずはリソースを可視化したら、自分たちのCPUなどがどれくらい使われているのか？ピーク時には足りているのか？余らせてないか？などみてみる。
ちなみに自分たちのAPIサーバーは
やばい。使わなすぎている。無理して良いの使いすぎた・・・下げよう。
サービスメトリックス
PVなどもサービスの状態を可視化して経営層とみよう！ってことが書かれていたけど、今時別のツール使ってみてないかな？というツッコミ。
第3章: サーバ監視
何を監視
- 外形監視
- 死活監視
- リソース監視
- その他監視
ミドルウェアの監視
mysqlなどの場合別途プラグインをいれる。
行ロックなどの数も取れたりするみたい。
RDSの場合はこちらから。（後の章で説明ある）
監視ルールの考え方
「実際に対応するものだけに限定すべき」
設定する前は適当にCloudWatchで色々設定してしまってたの反省。
オススメの監視設定フロー
① 全てのサーバに対してのCPU使用率、メモリ使用率、スワップ使用率、ファイルシステムの使用率の監視ルールを設定する ② 各種エラー系のメトリックの監視ルールを設定しておく ③ いったん様子見を見て、特定のロールだけ頻繁にアラートが来るようなら除外条件で無視するか、別途当該ロール用の監視ルールを作成する ④ 障害が発生したときに、特徴的な値の変化をしたメトリックについて監視ルールを作成する。同じ障害を早めに検知できるように、回帰的に監視ルールを育てる。
監視ルールを育てるって良い。 ②までやったけど、③と④はサービスごとによしなに設定だからこれからうちのも育ててこう。
Webシステムにおけるロール編成
構成については以下を参照とのこと。
Linuxでより多くのパラメーターを取得するには、mackerel-plugin-linuxでとれる。
Mackerelのプラグインは豊富で誰でも作れるのでよさそう。
システムメトリックスの見方
コラムなのに６ページくらい使って監視項目の見方とか書いてくれてる。 少しだけ抜擢すると
ロードアベレージ 「ロードアベレージがある値以上になったら即座に問題である」はあまり意味がない。 それ以上に、どんどん右肩上がりのグラフになっているかの方が問題。マルチコアの考慮もして「loadavg/コア数」を指標とする方が良いみたい。 mackerel-pluglin-multicoreとかでうまく対応できる。
ここら辺のコラムが一番参考になったかもしれない・・・。
CPUのほうはメモ
cpu.user: カーネル以外が使用した時間の割合 cpu.iowait: I/O街により、アイドル状態であった時間の割合 cup.system: カーネルが使用した時間の割合 cpu.idle: I/O街がなく、かつCPUがアイドル状態であった時間の割合
6章: 各種ツール連携と運用の効率化
tmux-cssh x MackerelAPIで同時に多数のサーバーに入る技。
以前それを改造してawsのログイン機能作ったのでついでに（便利だよ）。
7章: クラウド環境におけるMackerel
AWSインテグレーションを使って、勝手に連携できる。
RDSとかも含めて複数台でパラメーターとってる場合はどうするんだろうっておもってたけど、同じホストとしてパラメーター取得でもできるようで便利。
8章: 発展的な機能
CLIを通じて、グラフなどもすべてJSONで記述が可能とのこと。
Infrastructure as Codeができるし、Ansibleなどと合わせてインフラ周りを全てコードで管理できそう。
以前の会社でもdatadogのグラフ情報をコードにしてる方もいたなぁ。
まとめ
Mackerelを設定するために読み始めた本だが、監視のいろはなども書いてあって凄く勉強になった。とりあえず監視を始めてみよう！って方にはオススメ。
まだまだデータ取り始めたばかりなのでこれからどんどん育てていった結果もかきたい。
