監視では何をしかけておくのがよいのか
この4つになります
- 死活監視（DB接続の正常性を監視、プロセスの正常性を監視）
- ログ監視（DBログの正常性を監視）
- キャパシティー監視（ファイルサイズ、DISK使用率、表領域使用率）
- リソース監視（パラメータ値の余裕率）
また、監視を仕掛ける目的は、
自分たちが担当するレイヤーの正常性を確認するため、
異常があった場合に速やかに検知するためになります。
(何を監視するべきかについても「作業範囲」「役割分担」に基づいて設計、実装することになります）
しーさん
監視項目が足りているのか、閾値が正しいのかはどうやって判断すればいいでしょうか
大方針としては、
「死活」「ログ」「キャパシティ」「リソース」の４つの監視を実装すること。
あとは、運用をしながら、つねに見直しをしていくことになるの
最初から、監視項目や閾値を固定化することはできないんですね。
そうなの
システムは生き物と似ているって思うのよ
アプリリリースや利用者が増えたことで
データベースの使われ方が変わっていくでしょ
そうすると、発生する事象も変わっていくから
監視は常に見直していくことになるの
わかりました
ちなみに、閾値の決め方ってあるんですか？
うちは80%が「Warning」、90%が「Critical」で監視設定されている項目が多いですが、これって正しいんでしょうか?
一般的に、80%「Warning」、90%「Critical」で監視設定することが多いわね。
正しいかどうかはアラートの発生頻度、各種リソースを鑑みて判断することになるので、ここで回答するのは難しいわね。
ただし、閾値の考え方は知っておいてほしいの
オンプレとクラウドで大きく異なるってことを
オンプレ環境では、CPU、メモリ、DISKを増設するには、部品調達、各チームとの調整にかかるリードタイムがあるのね。日ごろからリソースやキャパシティーの増加傾向をウォッチしておくことで、リードタイムから逆算して閾値を設定することになるの
例えば、リードタイムが2-2.5か月。DISK使用率が1か月で10%の増加傾向。このケースではDISK使用率の監視閾値70%に設定すれば、DISKが枯渇する前に増設することができる
クラウド環境だと、部品調達もないし、クラウドベンダーによってはオンラインでリソース増設できるものもあるから、
(オンプレに比べると)閾値を大きな値にして運用するのね
なるほど、言われてみれば、そうですね
今日のまとめ
監視は「死活」「ログ」「キャパシティ」「リソース」を監視する
監視は常に最適化していく
閾値は妥当性はアラート発生頻度、リソースを鑑みて判断する
またオンプレ環境では増設までのリードタイムを考慮して閾値を設定する
コメント