こんにちは、SCSKの嶋谷です。 サーバを監視する際には、監視項目と検知条件を決定する必要があります。 監視項目はCPUやメモリ、ログといったように監視項目のイメージが湧きやすいと思います。 これら監視項目に対する検知条件を皆さんは即座に決定することができるでしょうか。 長年サーバ監視の業務に携わっている方であれば、経験則から一般的な設定値を理解しているでしょう。 しかし、経験が浅い方は「CPUはどれくらいになれば異常と判断すればよいのだろう」と即座に判断することが難しいと思います。 Mackerelには、正常時の状態を学習し、異常を検知した際にアラートを発生させる「ロール内異常検知」という機能があります。 今回、この機能が検知条件を決める際の手助けになると考え、実際にロール内異常検知の挙動を確認しました。 ロール内異常検知とは ロール内異常検知は、 機械学習 を用いて学習した正常なパターンから外れたメトリックの経過を異常と判断し、アラートを発生させる機能です。指定されたロールに含まれるサーバの過去のメトリックを学習し、正常な動きのパターンを認識します。 ロールに属するサーバのメトリック(CPU、メモリ、ディスク)を過去数十日分学習し、混合ガウス分布を用いて正常/異常の判定を行います。混合ガウス分布を用いることで、昼夜・平日・週末のように「負荷の波があるパターン」でも対応が可能です。 ロール内異常検知のメリットを下記に記載します。 複雑な監視ルールの設定が不要 ロール内のメトリックデータを機械学習で自動的に学習して正常時の状態を把握するため、 ユーザ自身で細かな閾値を設定する必要がありません 。 閾値の調整やメンテナンスの手間が少ない サーバの特性変化に応じて手作業で検知条件を更新する必要がなく、学習モデルは日々更新される仕様となっています。 そのため、メンテナンスの頻度が減少します。 サーバ監視の初心者でも導入しやすい 専門知識が無くても、簡単な設定で異常検知を実装することが可能です。 詳細は下記をご参照ください。 混合ガウス分布（GMM）の意味と役立つ例 – 具体例で学ぶ数学 ロール内異常検知による監視をおこなう – Mackerel ヘルプ 設定手順 構成 今回の記事ではAWSのEC2を2台を作成して、同じロールに含めて検証を実施しました。 ロール内に含まれるサーバのメトリックデータをMackerelに送信し、Mackerelでロール内異常検知の設定を組み込みことで簡単に異常検知を実装することができます。 設定方法 Mackerelコンソールの監視ルールタブを選択し、「監視ルール追加」をクリック ロール内異常検知をクリック 下記情報を入力 ・対象のロール：監視するロールを選択 ・センシティビティ：検知する変化の粒度を選択(sensitive、normal、insensitiveから選択) ・最大試行回数：アラート発生条件の異常状態継続回数 「作成」をクリック 今回私が作成した設定の一例を下記に示します。 今回は小さな変化も検知できるようにセンシティビティを「sensitive」に設定しています。 ※ロール内異常検知では、エージェントが収集するシステムメトリック全体を学習の対象としているため、 学習対象を個別のメトリックに絞り込むことはできません 。メトリックについては下記をご参照ください。 メトリック仕様 – Mackerel ヘルプ 監視ルールが作成されると、機械学習による学習が開始されます。 学習中は作成した監視ルールに赤いチェックマークが表示され、完了すると緑のチェックマークが表示されます。 これにより、設定が完了し異常検知を実施することができます。   異常検知検証 今回はCPU、Memory、Diskにそれぞれ負荷を与え、ロール内異常検知の挙動を確認しました。 検証に用いたサーバは検証用に作成したため、サーバ上にアプリケーションなどは構築していません。そのため、CPUやMemoryは常時低負荷の状態で推移しています。 CPU 下記コマンドでサーバ1台に対して、CPU使用率が100%で5分間推移するように負荷を与えてみるとアラートが発生しました。 stress-ng --cpu 0 --cpu-load 100 --timeout 5m 発生したアラート内容は以下となります。常時0%の状態から負荷を与えることで通常時とは異なると判断してアラートが発生しました。 掲載している図は100%で負荷を与えた場合ですが、60%や80%の負荷を与えた場合でも同様にアラートが発生しました。 CPUの中でもcpu.user.percentage（アプリケーションがCPUを利用した割合）が高騰しています。 Memory 下記コマンドでサーバ1台に対して、Memory使用率が60%で5分間推移するように負荷を与えてみるとアラートが発生しました。 stress-ng --vm 1 --vm-bytes 60% --timeout 5m 発生したアラート内容は以下で、Memory使用率ではなくCPU使用率でのアラートが発生しました。 疑問に思い、ヘルプページを確認してみると以下の記載がありました。 「ロール内異常検知によるアラートでは、該当ホストで普段と最も様子が異なるメトリックのグラフを表示します。各種通知でもこのグラフが表示されるので、障害の初期対応に活用できます(必ずしも障害の根本原因を表わしているというわけではありません)。」 つまり、Memoryに負荷を与えた際に CPU 使用率が 100% 程度まで上昇したため、Memory高騰よりも CPU 高騰が通常と最も異なる挙動として判定されました。その結果、CPU 使用率の高騰でアラートが発生したようです。 Disk 下記コマンドでサーバ1台に対して、Disk使用率が60%で5分間推移するように負荷を与えてみるとアラートが発生しました。 stress-ng -d 1 --hdd-bytes 4G --temp-path パス --timeout 5m 発生したアラート内容は以下で、CPU使用率の高騰でした。こちらもMemoryでの検証と同様にDisk使用率の高騰と共にCPU使用率も高騰してしまい、CPU使用率の高騰が通常と最も異なると判定されています。 また、CPUの中でもCPU・Memoryの検証で高騰していたcpu.user.percentageとは異なり、cpu.iowait.percentage（ディスク・ネットワーク I/Oの完了待ちでアイドル状態になっている割合）が高騰しています。 CPU・Memory・DiskでCPUアラートが発生しましたが、具体的に高騰している値は異なるものでした。 2台同時に負荷をかけた場合 構成図で示した通り、今回はロール内に2つのサーバを含めています。 これまでは1台のみに負荷を与えることで検証実施しましたが、ここでは2台同時に負荷をかけた場合の挙動について確認します。 下記のコマンドで、1台のみで検証したDiskとは異なるDiskに負荷を与えました。 stress-ng -d 1 --hdd-bytes 8M --temp-path パス --timeout 5m 結果としては、異なるアラートとして2台それぞれでアラートが発生しました。メトリックのグラフ推移としては同様の推移となっております。 ただ、今回高騰しているCPUのメトリックはcpu.system.percentage（カーネルが使用している割合）で、負荷を与えるDsikによっても挙動が変わることに驚きました。ホスト単位でアラートが発生することで、異常状態のホストを見逃すことはないと感じました。 小話 今回のブログを書くにあたり、まず検証でアラートが発生することを確認しました。 この際に、結果のスクリーンショットは撮影していませんでした。 ブログ執筆のため、同様の事象でアラートを発生させようとするとアラートが発生しませんでした。 1/10と1/20に下記コマンドを実行すると、1/10ではアラートが発生し1/20では発生しませんでした。 stress-ng --cpu 0 --cpu-load 100 --timeout 5m --metrics はてな社に問い合わせてみると、学習モデルは定期的に更新されているようで、1/10時点での学習モデルと1/20時点での学習モデルは同じものではありませんでした。1/20の学習モデルは検証で負荷を与えたメトリックデータを含んで学習されていたため、同じ事象(正常)とみなしてアラートが発生しなかったようです。 新しくサーバを作成して同様の事象を発生させることが必要でとても苦労しました。 ただ、学習モデルが自動的に日々更新される点はとても便利な機能だと感じました。 まとめ 今回はMackerelのロール内異常検知の機能に触れてみました。 サーバへ急激に負荷を与えると、正しく異常が検知されたのでAIのすごさも再認識しました。 ヘルプページにも記載されている通り根本原因を検知できるわけではないので、使い方が重要だと感じました。 ロール内異常検知は 正常時と異なる挙動を検知する機能 ですので、導入部分で触れた閾値決定の手助けで利用するのは難しいと感じました。また、学習モデルに使用されるデータは過去数十日のため、月一回の定期作業で発生する負荷を異常として判断する可能性もあります。 そのため別の用途として、サーバの挙動が変化したことに気付き、根本原因調査の足掛かりとして利用できるのではないかと感じました。 ただ、今回は実運用で使用しているサーバを対象としていないため、今後は実運用のサーバでの挙動も確認して利用用途考えていきたいです！ 最後までお読みいただきありがとうございました！

こんにちは、SCSKの谷です。 これまでに3大クラウドの各サービスをMackerelのクラウドインテグレーションを利用して監視を実装する記事を投稿してきました。 AWS： Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony Azure： MackerelでAzure環境を監視してみた！ – TechHarmony Google Cloud： MackerelでGoogle Cloudを監視してみた – TechHarmony 最後に総まとめということで、3大クラウドのMackerel監視（クラウドインテグレーション）を比較していきます！ そもそもMackerelのクラウドインテグレーションとは？ これまでの記事の中で各クラウドインテグレーションを利用して監視を実装していましたが、そもそもMackerelのクラウドインテグレーションについて説明していなかったので、簡単に説明させていただきます。 Mackerelのクラウドインテグレーションとは、AWS／Azure／Google Cloudと連携し、それぞれのクラウド環境を「Mackerel上のホスト」として一元監視できる機能です。 ■基本構造 Mackerel側から各クラウドの監視サービスのAPIを利用してホストの情報及びメトリクスを取得 ・ポーリング間隔：5分 ■利用方法 MackerelからAPIを使用するために、それぞれのクラウドに合わせた認証方法を利用します。 AWS：IAMロールで連携　＋　ポリシー付与 Azure：サービスプリンシパル設定　+　ロール割当 Google Cloud：サービスアカウント設定　＋　ロール割当   クラウドインテグレーションで監視可能なクラウドサービス比較 ここでは、Mackerelのクラウドインテグレーションで監視可能なサービスについて比較していきます。 合計サービス比較 現在Mackerelのクラウドインテグレーションで監視可能なクラウドサービスの合計はそれぞれ以下の通りです。 　 AWS Azure Google Cloud 合計サービス数 27 11 3 クラウドインテグレーションで監視できるサービスの数を比べると、クラウド利用者が多い AWS が、他のクラウドを大きく引き離していることがわかります。 サービスカテゴリ比較 各クラウドサービスのカテゴリごとの監視可能サービスの対応状況は以下の通りです。 カテゴリ分けはある程度各クラウドサービスのカテゴリ分けに沿っています。よく利用されるサービスのカテゴリについては太字にしています。 カテゴリ AWS Azure Google Cloud コンピューティング ◎ ◎ 〇 コンテナ 〇 × × データベース ◎ ◎ 〇 ネットワーク ◎ 〇 × ストレージ 〇 〇 × 分析 ◎ × × アプリケーション統合 〇 × × ビジネスアプリケーション 〇 × × セキュリティ 〇 × × 開発者ツール 〇 × × 管理 〇 × × 上記以外のカテゴリ × × × ※３つ以上対応している場合は◎ AWSは監視可能なサービス数が非常に多く、ほぼすべてのカテゴリで1つ以上のサービスに対応しています。さらに、利用頻度が高いカテゴリでは3つ以上のサービスを監視できるものもあり、幅広い選択肢を提供しています。特筆すべきは、AWSのみコンテナ関連のサービス監視に対応している点です。 一方、Azureはコンピューティング系とデータベース系で3つ以上のサービスに対応しているものの、基本的にはよく利用されるサービスに限定されています。 Google Cloudはさらにシンプルで、コンピューティング系とデータベース系のみ監視可能であり、最低限のサービス対応にとどまっています。   クラウドインテグレーションで取得可能なメトリクス ここでは、Mackerelのクラウドインテグレーションを利用して、仮想サーバー系サービスで取得できるメトリクス数と項目を比較していきます。 メトリクス数 現在Mackerelのクラウドインテグレーションで取得可能な仮想マシンサービスのメトリクス数合計はそれぞれ以下の通りです。 比較として、各クラウドの監視サービスで取得可能なメトリクス数も記載しています。 　 AWS Azure Google Cloud Mackerel 21 11 22 クラウド監視サービス 29 64 179 Mackerelでは、CloudWatchなどのクラウド監視サービスからすべてのメトリクスを取得するのではなく、利用頻度の高いメトリクスに絞って収集しているように見えます。特にGoogle CloudやAzureの場合、提供されるメトリクス数が非常に多いため、Mackerel側であらかじめ選定されたメトリクスのみが管理画面に表示されることで、ユーザーは膨大なメトリクスの中から必要なものを探す手間がなく、直感的でわかりやすい監視設定が可能になっていると感じました。 メトリクス項目 現在Mackerelのクラウドインテグレーションで取得可能な仮想マシンサービスのメトリクス項目はそれぞれ以下の通りです。 ■共通するメトリクス 　 AWS Azure Google Cloud CPU CPUUtilization CPUCreditUsage CPUCreditBalance CPUSurplusCreditBalance CPUSurplusCreditsCharged Percentage CPU CPU Credits Remaining CPU Credits Consumed utilization Disk DiskReadOps DiskWriteOps DiskReadBytes DiskWriteBytes Disk Read Operations/Sec Disk Write Operations/Sec Disk Read Bytes Disk Write Bytes read_bytes_count write_bytes_count read_ops_count write_ops_count throttled_read_bytes_count throttled_write_bytes_count throttled_read_ops_count throttled_write_ops_count Network NetworkIn NetworkOut NetworkPacketsIn NetworkPacketsOut Network In Network Out Network In Total Network Out Total received_bytes_count sent_bytes_count received_packets_count sent_packets_count   ■クラウド個別のメトリクス クラウド 分類 メトリクス 説明 AWS Status StatusCheckFailed_Instance StatusCheckFailed_System StatusCheckFailed EC2インスタンスやシステムの正常性を監視するためのステータスチェック結果 Disk (EBS) EBSReadOps EBSWriteOps EBSReadBytes EBSWriteBytes EBSIOBalance% EBSByteBalance% AWS EBS（Elastic Block Store）のI/O性能とバランスを監視するメトリクス群 Azure VM Availability Metric VmAvailabilityMetric Azure VM の稼働可否を示すメトリクス Google Cloud Uptime instance/uptime Compute Engineが起動してからの累積稼働時間を示すメトリクス ミラーリング パケット Mirroring bytes Mirroring packets Mirroring packets dropped ミラーリングされたトラフィック量とパケット数、そしてドロップされたパケット数を示すメトリクス Firewall dropped_bytes_count dropped_packets_count Google Cloud の VPC ファイアウォールでドロップされたトラフィック量（バイト数）とパケット数を示すメトリクス ■共通して取得しているカテゴリ どのクラウドでも、CPU・Disk・Network関連のメトリクスは必ず取得しています。 どのクラウドでもクラウドインテグレーションを使用した場合メモリのメトリクスを取得することができず、仮想マシンにエージェントを入れる必要があります。Mackerelとしてはメモリのメトリクスはエージェントから取得する思想なのかなと感じました。 ■クラウドごとの特色 共通メトリクス以外は、それぞれのクラウド特有の指標が追加されています。 AWS：EBSのI/O性能やステータスチェック（可用性） Azure：VMの可用性を示す VmAvailabilityMetric Google Cloud：ファイアウォールのドロップ数やパケットミラーリングなど、ネットワークセキュリティ関連のメトリクス クラウドインテグレーションの設定手順 最後に各クラウドのMackerelクラウドインテグレーションの設定手順を比較していきます。 詳しい導入手順については、各ブログで紹介していますので、そちらをご覧ください。 設定手順の難易度 今回は以下の指標で導入手順の難易度を比較しています。 設定方法の種類 複数の設定パターン（GUI、CLI）が用意されているかどうか 手順数（GUI） GUIで設定する場合、完了までに必要なステップ数はどれくらいか 設定手順の種類 複数の手順で設定可能か 所要時間（GUI） GUIで設定した場合、初期設定にどれくらい時間がかかるか 上記をまとめた結果は以下の通りです。   AWS Azure Google Cloud 設定方法 △ GUI 〇 GUI、CLI 〇 GUI、CLI 手順数(GUI) 〇 13 △ 16 △ 15 設定手順の種類 〇 ・IAMロール（推奨） ・Access Key IDと Secret Access Key 〇 ・Azure CLI 2.0 ・Azure Portal 〇 ・Cloud SDK ・Cloud Console 所要時間(GUI) 〇 3分2秒 × 7分2秒 △ 4分46秒 今回、AWS・Azure・Google Cloudのクラウドインテグレーション設定を実際に試してみました。その結果、設定のしやすさや所要時間に違いがあり、次のような印象を持ちました。 ・AWS 最もスムーズに設定できました。手順数も少なく、公式ドキュメントを参照しながら進めても特に詰まる箇所はありませんでした。 全体的に直感的で、短時間で設定完了できる印象です。 ・Azure 設定にやや時間がかかりました。公式ドキュメントで指定されている項目の場所をAzureポータル上で探すのに手間取ったことと、手順自体が多かったことです。その分、設定完了までに時間がかかる印象でした。 （慣れてないだけかもしれませんが。。。） ・Google Cloud 設定の大部分はスムーズでしたが、APIライブラリで必要なAPIを有効化する作業に少し手間取りました。公式ドキュメントに記載されて いるAPI名と、Google Cloud Console上で表示される名前が異なる場合があり、確認に時間がかかりました。 ただ、それ以外の手順は問題なく進められました。 総じて、クラウドインテグレーションの設定は比較的簡単に行えると感じました。 AWS・Azure・Google Cloudそれぞれに特徴はありますが、公式ドキュメントを参照すれば、どのクラウドでも大きな障壁なく設定を完了できます。 おわりに 記事は以上になります。いかがでしたでしょうか？ 詳細が気になった方は 公式ヘルプ をご確認ください。 今回は AWS、Azure、Google Cloud における Mackerelのクラウドインテグレーションを比較し、 「監視可能なサービス」、「取得できるメトリクス」、「設定手順」といったポイントを整理しました。 整理したことによりMackerelのクラウドインテグレーションでも、クラウドごとに細かな違いがあることが改めて分かりました。 Mackerelクラウドインテグレーションのメリットは、各クラウド上のリソースをMackerelのホストとして一元管理できることです。 これにより、複数クラウドを利用していても、統一された監視基盤を構築できます。 現状クラウドサービスによって利用できるレベルに差があるので、将来的にはどのクラウドサービスでも同じレベルでクラウドインテグレーションを利用できるようになると、さらに便利になると感じました。 これまで、部署内で Mackerelのクラウドインテグレーションに関する記事を投稿してきましたが、ひとまず今回の記事で一区切りとなります。最後までお読みいただき、ありがとうございました！ 今後も、新しい気づきや皆さまに役立つ情報があれば、随時記事を更新していきます。 次回の投稿をぜひお楽しみに！

はじめに 2025年11月14-15日(金土)に、福岡工業大学にてYAPC::Fukuoka 2025が開催されました。本記事ではYAPCにおけるトークの中から、@yuuk1tこと坪内佑樹さんのトーク「SREのためのテレ […]