こんにちは、SCSKの嶋谷です。 弊社が提供している監視サービスではSQL Serverを監視したいというお客様が一定数います。 Mackerelでは、SQL Serverのキャッシュヒット率や接続ユーザ数といった基本的な情報を監視することができます。 ただし、これらの情報だけでは把握しきれないポイントもあります。（後述） そのため、Mackerelを利用してSQL Serverの監視サービスを提供する場合、取得できるデータが限られた形での提供となってしまいます。 これまでにMackerelでのOracle Databaseの監視について紹介しましたが、今回はSQL Serverを対象に同様の方法を試してみました。SQL Serverからデータを取得し、それをMackerelに連携することで監視できるのか、実装を通して検証しています。 MackerelでOracle Databaseを監視してみた – TechHarmony MackerelでのSQL Server監視 Oracle Database監視に関する記事を投稿した際に、MackerelではSQL Serverの状態を監視する機能がないと記載しておりましたが誤りでした。メトリックプラグインを利用してSQL Serverの状態を監視することができます。 ただし、プラグインは オンプレミスサーバ や EC2上のサーバ に自前でSQL Serverを構築している場合に有効です。 メトリックプラグイン – mackerel-plugin-mssql – Mackerel ヘルプ AWS RDSで構築したSQL Serverを監視する場合は、AWSインテグレーションの機能を利用して監視することができます。 AWSインテグレーション – Mackerel ヘルプ プラグインで取得できるデータには限りがあり、 DBインデックス断片化率などのデータは取得不可です。 また、プラグインがサポートするSQL Serverのバージョンは下記となっており、古いバージョンではプラグインも利用不可です。 ・Microsoft SQL Server 2017以降 ・Microsoft SQL Express 2017以降 今回は、「プラグインでのデータ取得」と「プラグインで取得できないデータや古いバージョンでのデータ取得」の2つの方法を検証してみました。 プラグイン利用を利用したSQL Server監視 今回はSQL Serverのライセンス込みのAMIを利用して、AWS EC2上にSQL Serverを構築して検証を実施しました。 これにより、SQL Serverがインストールされた状態でサーバが起動するため、即時利用が可能となります。 取得可能データ まずは、プラグインで取得可能なデータの一覧を下記に記載します。 グラフ名 メトリック 説明 MSSQL Buffer Cache Hit Ratio ディスクから読み出すことなくバッファーキャッシュで見つかったページの割合 Page Life Expectancy ページが参照されないままバッファープールに留まった秒数 Checkpoint Pages チェックポイントや、すべてのダーティページをフラッシュする必要がある他のオペレーションによって、1秒間にディスクにフラッシュされたページ数 MSSQL Stats Batch Requests 1 秒間に受信した Transact-SQL コマンドバッチの数 SQL Compilations 1 秒あたりの SQL コンパイル数 SQL Re-Compilations 1秒あたりのステートメント再コンパイル数 Connections SQL Server に現在接続しているユーザー数 Lock Waits 1 秒あたりの File IO Provider のロックの待機数 Procs Blocked 現在ブロックされているプロセスの数 MSSQL Access Page Splits インデックスページがオーバーフローした結果、1 秒間に発生したページ分割の数 設定方法 mackerel-agent.confに下記を記載し、mackerel-agentのサービスを再起動するのみです。 ( 前提として、mackerel-agentがインストールされている必要があります。 ) [plugin.metrics.プラグイン名] command = [ "mackerel-plugin-mssql" , "-instance" , "SQLEXPRESS" ] ※インスタンス名(-instance)はデフォルトのインスタンス名として設定される SQLSERVER と SQLEXPRESS の 2つのみに対応しているため、ユーザ固有のインスタンス名の場合はデータが取得できません。 メトリックプラグイン – mackerel-plugin-mssql – Mackerel ヘルプ データの一例 Mackerelコンソール上に表示されたデータの一例を示します。 今回はMSSQL Bufferのグラフを示します。3つのデータを個別・複合的に分析することでDBの傾向を読み取ることができます。 スクリプトを利用したSQL Server監視 プラグインで取得不可のデータに対しては、下記の流れをPowerShellスクリプトで実装し、データ取得・連携をしています。 ①SQL Serverに接続 接続にはSQL認証を利用しているため、SQL認証を許可する必要があります。(設定の詳細は割愛いたします。) ②SQL文を実行してデータ(数値)を取得 ③取得データをエージェントを利用してMackerelに投稿 スクリプト概要 今回はスクリプトに修正を加えることを減らすために、接続情報やSQL文を別のファイルとして用意しました。 修正が必要な場合には、スクリプトではなくsqlファイルやiniファイルを修正することを想定しています。 ファイル名 説明 mackerel_sqlserver_connect.ps1 SQL Serverに接続してデータを取得後、Mackerelに連携するスクリプト mackerel_sqlserver_connect.sql 実行するSQL文を記述したファイル mackerel_sqlserver_connect.ini SQL Serverへの接続情報などを記載したファイル 以下が作成したスクリプトです。 # PowerShell スクリプト例: SQL Server 接続とクエリ実行 param( 　[string]$sql_file, # 実行するSQLを記述したファイル 　[int]$item_number, 　[string]$figure_name, 　[string]$metric_name, 　[string]$failure_status, 　[string]$alert_monitorname ) function Create_Json($HOSTID, $alert_monitorname, $failure_status, $mackerel_output_error, $unixtime, $maxCheckAttempts) { 　# JSONにしたいデータを「オブジェクト」で作る 　$bodyObject = @{ 　　reports = @( 　　　@{ 　　　　source = @{ 　　　　type = "host" 　　　　hostId = [string]$HOSTID 　　　} 　　　name = [string]$alert_monitorname 　　　status = [string]$failure_status 　　　message = [string]$mackerel_output_error 　　　occurredAt = [long]$unixtime 　　　maxCheckAttempts = [int]$maxCheckAttempts 　　　} 　　) 　} 　# JSON文字列へ 　$POSTJSON = $bodyObject | ConvertTo-Json -Depth 10 　return $POSTJSON } #APIキーの取得 function Get-MackerelApiKey { 　param ( 　　[string]$filePath 　) 　$configContent = Get-Content -Path $filePath 　foreach ($line in $configContent) { 　　if ($line -match "apikey\s*=\s*`"(.+)`"") { 　　　return $matches[1] 　　} 　} 　return $null } #TLS1.2を強制 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # APIキーを取得 $MACKEREL_APIKEY = Get-MackerelApiKey -filePath ".\mackerel-agent.conf" # hostIDの取得 $HOSTID = Get-Content -Path ".\id" # ヘッダーの設定 $headers = @{ 　"X-Api-Key" = $MACKEREL_APIKEY 　"Content-Type" = "application/json; charset=UTF-8" } # 現在時刻をエポック秒で取得 $currentUtcTime = [DateTime]::UtcNow $unixtime = [int][double]((Get-Date $currentUtcTime -UFormat %s)) # ユーザ自身で接続情報(ユーザ名やパスワード)とSQL文を別のファイルに準備していただき、そのファイルを読み込み $filePath = "mackerel_sqlserver_connect.ini" $PARAM = @{} try { 　Get-Content $filePath -ErrorAction Stop | % { $PARAM += ConvertFrom-StringData $_ -ErrorAction Stop } } catch { 　Write-Error "File not exists: $filePath" 　exit 0 } # 取得した接続情報を各変数に代入 $Server = $PARAM.Server $UserName = $PARAM.UserName $Pass = $PARAM.Pass $maxCheckAttempts = $PARAM.maxCheckAttempts try { 　# 接続文字列（SQL認証） 　$connectionString = "Server=$Server; 　User Id=$UserName; 　Password=$Pass; 　" 　# 接続とコマンド実行 　$connection = New-Object System.Data.SqlClient.SqlConnection 　$connection.ConnectionString = $connectionString 　$connection.Open() 　$command = $connection.CreateCommand() 　$Query = Get-Content -Path $sql_file -Raw -Encoding UTF8 　$command.CommandText = $query 　$adapter = New-Object System.Data.SqlClient.SqlDataAdapter $command 　$dataset = New-Object System.Data.DataSet 　$adapter.Fill($dataset) | Out-Null 　#数値結果が取得できている場合、エラーが解消されていると判断してSQLServer関連のエラーがあればクローズ 　$alert_response = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/alerts" -Method Get -Headers $headers 　# 取得したアラート($alert_response)にはMackerel発生しているアラートすべてが含まれている 　# アラートからSQLServerに関するアラートだけを取得し、ホストIDとアラート内容でクローズを判定 　$response_removes = @() 　$response_removes += $alert_response.alerts | Where-object { 　　# メッセージが存在し、指定のエラーパターンに一致 　　($_.message -ne $null) -and ($_.message -match "SQLServer Error") -and 　　# 同一ホストIDのみを対象 　　($_.hostId -eq $HOSTID) 　} 　if ($response_removes.Length -ne 0) { 　　#Write-Host "not null" 　　$body = @" { 　　　"reason": "solve" } "@ 　#アラートをクローズ 　$utf8Bytes = [System.Text.Encoding]::UTF8.GetBytes($body) 　for ($i = 0; $i -lt $response_removes.Length; $i++) { 　　$return = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/alerts/$($response_removes[$i].id)/close" -Method POST -Headers $headers -Body $utf8Bytes 　　#Write-Output $return 　　} 　} 　else { 　　#Write-Output "null" 　} 　# 結果表示 　$dataset.Tables[0] | Format-Table -AutoSize 　$connection.Close() 　#返り値を配列に格納(レコードごとではなく、1データずつ) 　$table = $dataset.Tables[0] 　$resultRow = $table.Rows | ForEach-Object { ,$_.ItemArray} 　$sql_result = @($resultRow | ForEach-Object { $_ } | ForEach-Object { $_ }) 　Write-Host $$resultRow[0] 　Write-Host $sql_result[$item_number-1] 　#Mackerelにデータ投稿される形式で出力 　Write-Host "sqlserver.$($figure_name).$metric_name`t$($sql_result[$item_number-1])`t$unixtime" 　exit 0 } catch { 　#エラー発生時にチェック監視としてアラートを投稿 　$exception_error = "SQLServer Error_net : " + $_.Exception.Message 　Write-Host $exception_error 　$POSTJSON = Create_Json $HOSTID $alert_monitorname $failure_status $exception_error $unixtime $maxCheckAttempts 　$utf8Bytes = [System.Text.Encoding]::UTF8.GetBytes($POSTJSON) 　Write-Host $POSTJSON 　$response = Invoke-RestMethod -Uri "https://api.mackerelio.com/api/v0/monitoring/checks/report" -Method Post -Headers $headers -Body $utf8Bytes 　Write-Host $response 　exit 1 } 以下にスクリプトの簡単な仕様を記載します。 (1)必要情報の取得 スクリプト実行における必要な情報を取得します。 ・MackerelAPIKey ・ホストID ・DB接続情報(サーバ名・ユーザ名・パスワード) ・Mackerelに表示されるグラフ名、メトリック名 ・SQL文 (2)SQL Serverに接続してデータを取得 DB接続情報、SQL文をもとにSQL Serverに接続してデータを取得。 データが取得できない場合は、エラー内容を文字列で取得し、アラートとしてMackerelに連携します。 エラーの原因は下記が考えられます。 ・DB接続情報の設定ミス ・SQL文の記述ミス ・ネットワークエラー　など Mackerelの仕様上、一度投稿されたアラートはMackerel上に表示され続けます。 そのため数値データを取得できた場合は、アラートが解決されたと判断してSQL Serverに関する投稿済みのアラートを自動でクローズします。 (3)データの連携 取得したデータをMackerelに連携します。連携したデータはグラフとして可視化されるので、(1)の処理で取得したグラフ名やメトリック名も同時に連携します。 利用手順 (1)以下のファイルをmackerel-agent.confが格納されているフォルダに配置 ・mackerel_sqlserver_connect.ps1 ・mackerel_sqlserver_connect.sql ・mackerel_sqlserver_connect.ini (2)mackerel_sqlserver_connect.iniにDB接続情報を記述 ・接続するサーバ ・ユーザ名 ・パスワード (3)mackerel_sqlserver_connect.sqlにSQL文を記述 (4)mackerel-agent.confに以下を追記 [plugin.metrics.プラグイン名] command = [“powershell”, “-File”, “mackerel_sqlserver_connect.ps1”, “-sql_file”, “mackerel_sqlserver_connect.sql”, “-item_number”, “連携するクエリ結果の列番号”, “-figure_name”, “グラフ名”, “-metric_name”, “メトリック名”, “-failure_status”, “WARNINGもしくはCRITICAL”, “-alert_monitorname”, “アラート名”] ※プラグイン名・グラフ名・メトリック名・アラート名は任意で設定可能です。 (5)mackerel-agentの再起動 データを取得できた場合 データを取得できた場合、Mackerelに連携されて下記のグラフのように可視化されることを確認しました。 このグラフはセッション総数を可視化しています。 今回はセッション総数のグラフを可視化してみましたが、SQLを実行して取得できる数値データはすべて連携できます。 データを取得できない場合 データを取得できない場合、以下のようなアラートがMackerel上に表示されることを確認しました。 DB接続情報の設定ミス時のエラー SQL文の記述ミス時のエラー 上記のエラー内容は一例ですが、エラー内容を連携することでアラートの原因を一目で理解できます。 まとめ 今回はSQL ServerからSQL文を用いてデータを取得して、Mackerelに連携するスクリプトを作成しました。 Oracle Databaseを対象とした開発を経験していたこともあり、比較的簡単に実装することができました。 現在のスクリプトには課題が多くあり、機能として提供するには程遠い状態です。 自分一人の力では限界があるので、部署の方と協力して提供レベルにまで高度化していきたいです。 最後までご覧いただきありがとうございました！

こんにちは、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のクラウドインテグレーションに関する記事を投稿してきましたが、ひとまず今回の記事で一区切りとなります。最後までお読みいただき、ありがとうございました！ 今後も、新しい気づきや皆さまに役立つ情報があれば、随時記事を更新していきます。 次回の投稿をぜひお楽しみに！