Mackerelでロール内異常検知による監視を取り入れてみた
こんにちわ、札幌のヨシエです。
Mackerel Meetup#13の直前で発表されたロール内異常検知を試してみました。
パブリックベータ版のため、今後仕様変更が発生する可能性がございますので上記のリンクより最新情報をご確認いただけますと幸いです。
ロール内異常検知とは？
Mackerel自体に保存されている過去のメトリック値を機械学習へ取り込み、 メトリック状況を分析することで正常/異常の材料とします。 この材料を用いて、負荷傾向を監視することで通常のリソース消費状況と異なるメトリックが確認できると異常として検知され、アラート発報される機能となります。
この機能の特筆点として、ロール内異常とはMackerelの監視する単位であるロールの単位でこの機能が利用できることです。
ざっくりですが、以下のようなAWS環境を監視しようとします。
各AWSリソース毎にサービスを作成し、役割毎にロールを作成して監視します。
特に分かりやすい例として、APIサーバー群をEC2:APIロールとしてグルーピングするとします。
今回のロール内異常検知をEC2:APIに設定することでロール登録されているAPIサーバー全体のシステムメトリックを分析します。
この環境で何らかの理由により、1台のAPIサーバーでCPU使用率の高騰が発生した場合は監視対象ロールと監視対象サーバーでアラートが検知される形になります。
検証してみる
検証として、一時環境を作成した後にstressコマンド等で負荷をかけようと考えました。 ですが、上記で記載したように監視判断材料となる過去のメトリックを作成する事に手間が発生します。
また、実際の運用に近しく負荷状況が追いやすい環境を監視したい気持ちがあったので、弊社の情シス部門に相談して全社員が利用する社内サーバーでの監視許可を頂きました。 (情シス部門の皆さん、今回のお願いにつきまして快諾ありがとうございました！)
まず、今回利用した社内サーバーのCPU使用率グラフを説明させて頂きます。
これは特定の時間を切り出したCPU使用率のグラフです。 負荷が計測されているポイントと弊社内の業務状況を突き合わせて、下記の状況が想定されます。
- 朝会や週報会といった全部門が対象サーバーを利用
- 09:00 ~ 12:00、13:00 ~ 19:00といった業務時間中の利用が主になっている
- その他時間帯は海外オフィスの利用により負荷が発生している
このようなメトリックを監視している環境へ今回の機能を導入します。
監視ルールの追加
Mackerelの左ペインより、Monitorsを選択
次に画面上部の「監視ルールの追加」を選択
監視ルール設定画面が表示されるので、上部タブから「ロール内異常検知」を選択
監視対象のサービス、ロールを選択肢、センシティビティを選択
監視ルール名の入力後に、作成を選択
以上で、監視ルールの設定が完了です。
設定後に追加された監視ルールを確認すると、以下のような状態になります。
この状態は過去のメトリックを学習している最中となりますが、今回は10分以内で学習が完了しました。
ちなみに取り込むメトリックが少ないロールで実行した際には、以下のような失敗が見えました。
アラート検出
上記の対応から少々の期間をおいて、無事アラート発報が確認できました。
これは17:12あたりからCPU使用率が高くなっており、監視ルールにて設定した3回連続で検知されたことからCriticalとしてアラートが発報されました。 一過性のアクセス集中のため、アラートを検知した2分後にCPU使用率が落ち着いたことでアラートが自動クローズされました。
注意点
本機能を利用する際にはこちらで記載されている点を十分に考慮する形をおすすめします。
上記で記載があるように、ロール設計と一つの監視ルールではなく補足的に機能を重要視して導入を進めることをおすすめします。
ユーザーの皆さんは様々なロールが必要になると考えられますが、冒頭で記載したようにロール全体が分析対象となることから、明らかに用途が違うサーバーなどで負荷状況のバラつきがあると本機能は生きてきません。
また、この機能自体が素晴らしい機能ではありますが、長い期間やサービスの特性から導いた監視ルールを否定するものではなく、一緒に設定することで監視精度を向上させるものと思われます。
この点を十分に考慮すると精神衛生に良い監視が実現出来るかと思います。
最後に
mackerel-container-agentや今回紹介したロール内異常検知機能といった新機能が次々と出てくるMackerelは触ってて飽きないサービスと思います。 しみじみ思いますが、使い方によってさまざまな環境監視が実現出来る点からサービス提供側に今後求められるのは「どのような監視が必要なのか」というところを文化としてエンジニアだけではなく、関係者全体で考えられるようになるとサービスへいい影響を与えられるのではないかと思いました。
