ディスクがパンクして大騒ぎしている日々・・・
ことの発端はディスクがパンクしシステム不具合が発生してから対処するといった情シスながらのアリアリ運用（私の管轄していたサーバーではありませんよ）を目にしたため監視はどうなっているのか尋ねると JP1 のライセンスが足りないとかなんだかで（言い訳にも聞こえましたが）監視が疎かになっていた様子。そんな中、何か安価なツールはないものだろうかと調べていると海外では比較的導入されていそうな SolarWinds やオープンソースの Zabbix, Hinemos などが他にも候補としてありそうだったが、なんかヘビーな感じ。必要なものを金もサーバーも構築せずほとんどかけずに直ぐに開始したい！必要なものは今の時代1時間で対応できずはずだよね・・・と行き着いた先が Azure Monitor 。調べてみるとオンプレも簡単に連携できることがわかり導入をスタート。機能的には Monitor という機能とログ置き場の Log Analytics Workspaces というログ置き場の二つのサービスが関わることになる。
Azure Monitor のコストは？
https://azure.microsoft.com/ja-jp/pricing/details/monitor/
に記載があるものの複雑に見えてよくわからん。ということで、整理すると大きくは
●ログ保管の費用（Data Ingestion）・・・これは保管するメトリックの種類や取得頻度が増えれば増えるほど費用が加算される。オンプレのWindowsサーバーでディスクの%free spaceとfree megabytesといったディスク容量の監視を2個、1分おきに監視を開始した設定では1台あたり月10円程度になりそう。CPUやメモリなど次々監視したいものを増やすこともできるが増やせば増やすほどログが増え課金が増える。このあたりは監視頻度の増減や監視項目の増減を適度に調整、監視し莫大なコストにならぬよう注意をする必要があろう。不安なうちはスモールスタートがよさそうだ。
●アラート設定自体の費用・・・1つのアラート設定につき月11円。一つのサーバーの一つのドライブで1つのアラートという感じなので二つのドライブを見る場合は2つのアラート設定になる。
●アラート送信の費用（メール、SMS、電話音声）・・・メールやAzureアプリの連携が一番安い（1か月1,000件は無料とのこと）。SMSや電話音声は上記料金表にもあるが1回あたり数十円かかりそうなので注意。
オンプレとどう連携させるのか？
ネット接続がNGのサーバーもあると思うが今回はその対応は必要が無いので省略している（Log Analytics Gateway
は使用しない）。Log Analytics Workspaces の Overview または Agents management で WindowsとLinuxとAzureを連携させるプログラムがダウンロードできそれをインストールしないといけない。
インストール中にWorkspace IDと連携キーを聞かれるのでそれはダウンロード画面に表示されている情報をコピペしてセットアップを続行することとなる。また、当該画面においてすでに連携されているWindowsやLinuxがあれば台数が表示される。（本画面では2台が接続済）
"Advanced settings" で吸い上げるオンプレWindows/Linuxログの内容が設定できる。一つのLog Analytics Workspaceで設定できる吸い上げ条件は一つのようなので、条件を変えたい場合は別のLog Analytics Workspaceを作成しなければいけない様子。画像の例ではすべてのディスクの% Free Space, Free Megabytesを1分毎に吸い上げる設定の例となる。これを2台に同時適用しているイメージだ。
ここの設定さえすれば自動でログの吸い上げが始まる。
オンプレサーバーがAzureと接続できているかはコントロールパネルのMicrosoft Monitoring AgentのAzure Log Analytics(OMS)タブで確認できる。グリーンのチェックマークが入っていてsuccessfullyと表示されていれば連携は既にされている。プロキシの設定 タブでプロキシーの設定が必要であれば入力可能にもなっている。
アラートの設定
アラートの設定は Monitor から行う。Manage actions であらかじめ通知先（メールアドレス、例としてTeamsのチャネルにも投稿可能）を登録しておくと使いまわしができるのでお勧め。New alert ruleで新たな通知設定ができる。この画面ではアラートの発報テストをしたので2件発生しており2件クローズしている状況。New, Acknowledged, Closed は人間がステータスコントロールするように作られているが通知はActivated, Deactivatedというステータスをシステムが管理しておりAzureの良いところはアラートの発報 Activated と件名に入るだけではなく、障害解決の Deactivated という件名が入った監視（および解決通知）もちゃんとしてくれているところにある。
メールの通知例：
次の設定では空きディスク容量が3072MB(3GB)を切った場合にアラート通知する設定例。
Conditionの例。
リソースがAzureにある場合はもっとしやすい。また、Webサイトの死活監視もできる。（Webサイトの死活だけであれば（ログ保管は別）その設定自体は無料のようである）。世界各国にあるAzureデータセンターからWebサイトへアクセスし応答が200かまたは別かなど設定しアラートも設定できる。応答時間もわかるので非常にわかりやすい。
Azure SQL Databaseの残容量、Azure Data FactoryのETL実行結果に異常がある場合のアラートも可能だ。アラート設定例。
設定するリソースグループ名には気を付けて
Azure Monitor関係はリソースグループの移動ができないものが多い。従い、移動が発生するようなことがあると大変大変手間なことになる。日本語などアルファベットや数値以外の文字が入っていると後続のリソース作成等で誤作動を行うこともあるのでリソースグループ名には十分気を付けそう。
詳細はこちら
https://qiita.com/mnoda/items/d60d72b78adc894aaf29
公式ドキュメント
https://docs.microsoft.com/ja-jp/azure/azure-monitor/overview
は機能全体が俯瞰されています。
全体像（上記公式サイトより）：
