カテゴリー: Azure

AzureでSendGridアカウントを作った後の設定

投稿日: 投稿者: tama-negi

 

今回はAzureのSendGridアカウント作成後、SendGrid経由でメール送信するまでに必要となる設定を試してみました。

      • 今回実施した設定
        • SendGridメールアドレス確認
        • Single Sender(差出人)認証
        • apikeyの作成しPostfixで設定
        • ドメイン認証

以前はSingle Sender(差出人)やドメイン認証無しでも送信出来ていたのですが、2020年10月時点ではどちらか1つが必須になっています。

今回は、Azure上に構築したメールサーバ(Postfix)を利用して送信確認を実施しています。

設定にあたっては、以下のサイトを参考にさせて頂いております。有難うございます。

https://sendgrid.kke.co.jp/docs/Tutorials/index.html

SendGridアカウントの作成についてはこちらで試しております。

AzureでSend Gridのアカウントを作ってみた

1.AzureのSend Gridアカウント作成後は最初にメールアドレス確認処理を行う

最初にSnedGridアカウント作成時のメールアドレス確認を行います。

１)Azure Portalで作成したSendGridアカウント選択します。SendGridアカウントの画面でManageを選択します。

２)SendGridの管理画面が表示されます。

作成したSendGridアカウントのメールアドレスの確認を要求されます。Send Confirmation Emailを選択し確認メールを送信します。

※最初にSnedGridの管理画面を開いた際に表示されます。

送信完了メッセージが表示されます。

３)送信先に指定したメールアドレスにSendGridから確認メールが来ますので、Confirm Email Addressをクリックします。

確認が完了するとSendGridの管理画面が表示されます。

これでSendGridメールアドレス確認は終わりです。次にSingle Sender(差出人)認証設定もしくはドメイン認証設定を行います。

2.Send Gridアカウント作成後にSingle Sender(差出人)で認証設定

メールアドレスの確認が終わると、認証設定になります。認証の方法には2つあるようです。

      • 認証方法
        • Single Sender(差出人)による認証
        • Domain Instead(ドメイン)による認証

まず、最初にSingle Sender(差出人)による認証を行います。

１)SnedGrid管理画面を開くと下記メッセージが表示されますので、Create a Single Senderを選択します。

２)Senderの作成画面が表示されますので設定します。

      • 設定項目(必須)
        • From Name：任意で設定
        • From Email Address：SendGrid経由で送信する差出人メールアドレス(送信者のメールアドレス)
        • Reply To：個別要件が無ければ、From Email Addressと同じとします。
        • Company Address：任意で設定
        • City：任意で設定
        • Country：任意で設定
        • Nicname：任意で設定

※注意点は、From Email Addressで設定したメールアドレスのみが認証となります。同じドメインでも違う差出人アドレスの場合は別途認証が必要になります。

Createを選択し作成されると下記画面が表示されます。VERIFIEDが×になっておりこの時点では認証が完了していません。

３)From Email Addressのメールボックスに確認メールが来ているのでVeryfy Single Senderをクリックします。

Senderでの認証が完了したことが表示されます。Return to Single Sender Verificationをクリックしステータスを確認します。

Single Sender Verificationが表示されます。

Verifiedのステータス見るとチェックがついており確認が完了している事が分かります。

これで、Single Sender(差出人)による認証が完了です。

3.SendGridでAPI Keyを発行、メールサーバ(Postfix)を使ってSendGrid経由の送信(SMTP)確認

SendGridのAPI Keyを利用してメールサーバ(Postfix)からSendGrid経由でメール送信してみます。

SendGridの送信の認証には大きく分けて2つです。

      • SendGrid送信時の認証方法(SMTP)
          • アカウントの認証情報（ユーザ名／パスワード）(Teammates機能で追加した認証情報を含む)
          • APIキー

なお、アプリケーションでの利用はAPI Keyの利用を推奨されています。

１)Integrate using our Web API or SMTP Relayを選択します。

２)SMTP Realyを選択します。

３)API Keyの発行を行います。API Key Nameに任意名前を設定し、Create Keyを選択します。

４)API Keyのパスワードが発行されます。このパスワードは認証に利用しますのでコピーして保管します。

５)メールサーバ(Postfix)を設定します。2つのファイルに追記します。

/etc/postfix/main.cf

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relayhost = [smtp.sendgrid.net]:Port番号

/etc/postfix/sasl_passwd

[smtp.sendgrid.net]:Port番号 apikey:Password

ファイル編集が完了したら、postmap(postmap /etc/postfix/sasl_passwd)コマンド実行後に、Postfixのサービスを再起動します。

これでメールサーバ側の設定は完了です。

６)SnedGrid管理画面でVeryfy Integrationをクリックします。

７)先ほど設定したメールサーバ(Postfix)経由でメール送信を行います。

今回はSingle Sender(差出人)認証を利用していますので、From Email Addressに設定したメールアドレスから任意の送信先へメール送信します。

無事SendGrid経由で送信が完了すると下記画面が表示され設定が完了している事が確認出来ます。

SendGridのAPI Keyを使ってメール送信が出来るようになりました。

4.SendGridでドメイン認証設定

SendGridではSingle Sender(差出人)認証ではなくドメイン認証を行う事も可能です。

Single Sender(差出人)認証の場合、複数差出人が居ると複数認証設定を行う必要があります。ドメイン認証を利用する事によりドメイン単位での一括した認証設定が出来ます。

ただし、Single Sender(差出人)認証とは異なり、ドメイン認証の場合は認証するドメインのDNSで設定が必要になります。

１)認証設定画面でAuthenticate a domain insteadを選択します。

もしくは、SnedGrid管理画面にあるSender AuthenticationのメニューでDomain Authenticationを選択します。

２)Authenticate Your Domainの画面が表示されます。ドメインを管理するDNS hostを選択します。

brand the links for this domainはここでは設定しないのでNoを選択します

※Azure DNSはリストに無いのでOtherを選択します。

３)From Domainに認証するドメイン名を設定します。

４)Install DNS Recordsが表示されます。CNAMEのレコードが3つ表示されますので、ドメインを管理するDNSでCNAME設定を行います。

DNSの設定完了後に、Verifyをクリックします。

Azure DNSの場合は下記のように、CNAMEレコードの設定を行います。

DNSのレコードが正しく設定されていれば、下記の通りVerifiedの表示になります。

これでドメイン認証は完了です。

その他、Zabbixサーバを利用したメール送信は下記記事に記載しております。併せて見て頂ければと。

ZabbixからSendGrid経由でメール送信してみた

WindowsでAzure ファイル共有を使ってみた

投稿日: 投稿者: tama-negi

 

今回はAzure ストレージアカウントのファイル共有を利用して、Windowsからネットワークドライブとしてマウントする所まで試してみました。

Azure ファイル共有ですが、サーバレスでSMBやNFSプロトコルを介してアクセスできる、フル マネージドのファイル共有サービスになります。

今回実施した内容はこちらの内容になります。

      • Azure ファイル共有用のストレージアカウントを作成
      • Azure ストレージアカウントでファイル共有設定
      • Windows OSからAzure ストレージアカウント(ファイル共有)をマウント

今回は以下の条件で作成を試してみました。

      • StorageV2 (汎用 v2)を利用する
      • Azure VM(Windows)からマウントする

※今回はStorageV2のファイル共有で試しています。Azure Filesは次回以降に試したいと思います。

1.Azure ファイル共有用のストレージアカウントを作成する

マイクロソフトサイト記載の内容にそって設定を行っていきます。

    • Azure ファイル共有を作成する

https://docs.microsoft.com/ja-jp/azure/storage/files/storage-how-to-create-file-share?tabs=azure-portal

まず最初に、ファイル共有するストレージアカウントを作成します。

１)ストレージアカウントのメニューで追加を選択します。

２)ストレージアカウントの作成画面で設定を行います。基本では以下の内容を設定します

    • 主に設定する内容(今回の設定内容) 
      • ストレージアカウント名：任意で設定
      • リソースグループ名：任意で設定
      • 場所：東日本
      • パフォーマンス：Standard
      • アカウント種類：StorageV2
      • レプリケーション：ローカル冗長
      • Blobのアクセスレベル：ホット

※環境や利用用途に合わせて適時設定して下さい。

※通常のストレージアカウントと同様にStandard (HDD)やPremium(SSD)などが選択できます。アカウント種類でAzure Filesを選択する場合はPremiumを選択する必要があります。

３)ネットワークの設定を行います。今回はAzure VMからのみの想定なのでVNET(仮想ネットワーク)を指定します。

    • 主に設定する内容
      • 接続方法：パブリックエンドポイント(選択されたネットワーク)
      • 仮想ネットワーク
        • 仮想ネットワーク：接続元Azure VMの仮想ネットワーク
        • サブネット；接続元Azure VMのサブネット

４)データ保護の設定を行います。論理削除やポイントタイムの設定は今回はデフォルト(無し)のままとしています。

５)詳細の設定を行います。今回は変更せず確認および作成を選択します。タグ設定する場合は次へでタグ設定を行います。

確認画面が表示されるので問題が無ければ作成します。

これでストレージアカウントの作成は完了です。

2.Azure ストレージアカウントでファイル共有設定する

作成したストレージアカウントでファイル共有の設定を行います。

１)作成したストレージアカウントを選択します。ファイル共有を選択します。

２)ファイル共有を選択し、新規作成を行います。

 

３)新しいファイル共有作成が表示されます。今回は以下の内容で設定しています。

      • 設定する内容
        • 名前(ファイル共有名)：sharefile-drive(任意)
        • クォーター(ファイル共有のディレクトリサイズ)；1GB
        • 層(ファイル共有アクセス 速度やコスト)：トランザクションが最適化されました

※層に関しての詳細はこちらを確認願います。

https://docs.microsoft.com/ja-jp/azure/storage/files/storage-files-planning#storage-tiers

作成をクリックするとファイル共有が作成されます。

3.Windows OS(PowerShell)からAzure ストレージアカウント(ファイル共有)をマウントする

ファイル共有が利用できるようになったので、Windows OS(今回は2016を利用)からマウントします。

１)作成したファイル共有を選択します。

２)ファイル共有の画面が表示されますので、接続を選択します。

３)PowerShellが表示されますのでコピーします。

４)Windows OSにログインし先ほどコピーしたPowerShellを実行します。

コピーして実行になりますが、PowerShellの実例は下記の通りになります。

 $connectTestResult = Test-NetConnection -ComputerName <ストレージアカウント名>.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
# 再起動時にドライブが維持されるように、パスワードを保存する
cmd.exe /C “cmdkey /add:`”<ストレージアカウント名>.file.core.windows.net`” /user:`“<ストレージアカウント名>`” /pass:`”<アクセスキー>`””
# ドライブをマウントする
New-PSDrive -Name Z -PSProvider FileSystem -Root “<ストレージアカウント名>.file.core.windows.net\sharefile-drive” -Persist
} else {
Write-Error -Message “Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port.”
}
}

PowerShellが正常終了すると下記のようなメッセージが表示されます。

５)Windows OSのエクスプローラーで確認すると、ファイル共有がネットワークドライブとしてマウントされている事が確認出来ます。

６)実際にネットワークドライブにファイル作成すると無事作成できる事が確認出来ました。

4.Windows OS(GUI)からAzure ストレージアカウント(ファイル共有)をマウントする

Windows OSからのマウントはGUIを使っても可能です。

１)エクスプローラーでネットワークドライブの割り当てを選択します。

２)ネットワークドライブの割り当て画面が表示されますので設定します。

      • 設定する内容
        • ドライブ：Z:
        • フォルダー：”ストレージアカウント名”.file.core.windows.net\”ファイル共有名(今回の場合はsharefile-drive)”
        • サインイン時に再接続する；チェック有
        • 別の資格情報を使用して接続する：チェック有

３)Azure Portalのストレージアカウントでアクセスキーを確認しコピーします。

４)ネットワーク情報の資格画面で以下の通りに入力します。入力したらOKをクリックします。

      • 設定する内容
        • AZURE￥ストレージアカウント名
        • アクセスキー
        • 資格情報を記憶する：チェック有

ファイル共有が表示されると、先ほど作成したファイルが表示されます。

Azure バックアップ センターを使ってみた

投稿日: 投稿者: tama-negi

 

Azure バックアップセンターのプレビューが開始されていたので試してみました。

Azure バックアップ センターでは、Azure で管理されるバックアップを一元的に管理する事が出来ます。

    • Azure バックアップセンター

https://docs.microsoft.com/ja-jp/azure/backup/backup-center-overview

特徴はAzureサブスクリプション内(複数のRecovery Serviceコンテナー)の情報を一元的に見る事が出来ます、具体的にはこんな感じの事が出来ます。

      • サブスクリプション内のバックアップアイテムを一覧表示する
      • サブスクリプション内のバックアップジョブ実行結果を一覧表示する
      • Recovery Serviceコンテナーで使用しているバックアップデータ容量(データ転送量時含む)をサマリや一覧表示する。

サブスクリプション内のバックアップジョブ実行結果がすべて一覧表示する事が出来る等、非常に便利な機能となっています。

※現時点では、Recovery Service コンテナーとAzure Database For PostgreSQLでバックアップを取得されるものが対象のようです。

1.Azure バックアップセンターを試してみる

Azure バックアップセンターのメニューを選択すると概要の画面が表示されます。

画面で、過去24時間のバックアップジョブ実行結果やバックアップ対象の数が表示されます。

リンクもちゃんとしており、ジョブ画面の数字を選択するとバックアップジョブの画面へ遷移出来ます。

管理のメニューではサブスクリプション内のRecovery Service コンテナーの情報が見れます。

      • インスタンスのバックアップ：バックアップアイテムの一覧
      • バックアップポリシー：バックアップポリシーの一覧
      • コンテナー：Recovery Service コンテナーの一覧

インスタンスのバックアップを選択するとバックアップ対象と保護状況が一覧表示されます。(別の複数のバックアップアイテムがある環境で見た際もすべて一覧表示されました。)

バックアップポリシーの画面では存在するバックアップポリシーの一覧が表示されます。

※Recovery Service コンテナーが複数の場合等では、DefaultPolicyが一杯並んだりします。(削除していない場合)

コンテナーでは、Recovery Service コンテナーの一覧が表示されます。

監視のメニューではバックアップ実行結果等の情報が見れます。

      • バックアップジョブ：バックアップジョブ実行結果一覧
      • バックアップレポート：バックアップに関する詳細な情報

まず、バックアップジョブでは、すべてのバックアップアイテムのバックアップ状況が表示されます。

※日々のバックアップ設定していない場合でも最終取得日時が表示されます。

バックアップレポートは、Recovery Service コンテナーの診断設定で取得される情報を利用してさらに詳細な情報が確認出来ます。こちらは次の章に記載します。

2.Azure バックアップセンターのバックアップリポートを使うと、Log Analyticsワークスペースからデータ取得して色んな情報が見れます

バックアップレポートではRecovery Service コンテナーの診断設定されたLog Analyticsワークスペースからデータを取得してデータ表示します。

事前にRecovery Service コンテナーの診断設定でLog AnalyticsワークスペースへのLog転送設定を行います。その転送先のLog AnalyticsワークスペースをバックアップレポートのLog Analyticsワークスペースとして選択します。

※指定するのはAzure VMではなく、Recovery Service コンテナーの診断設定転送先になります。

設定後、バックアップレポートの画面でまとめのタブを選択すると、情報が取得出来ている事が分かります。

まとめのタブでは、バックアップアイテムの数や、使用しているストレージ容量(バックアップ)が吹応じされます。

 

バックアップ項目のタブを選択すると、バックアップストレージの利用量の推移等が確認できます。

ジョブのタブを選択すると時系列での表示や成功率、バックアップジョブ単位での転送量等が表示されます。バックアップジョブのメニューで表示される内容より詳細な内容が確認出来ます。

※Log Analyticsワークスペースから情報を取得していますので、診断設定をしていない場合や、別のLog Analyticsワークスペースへ接続しているRecovery Service コンテナーの情報は含まれません。

Microsoft Antimalwareを使ってみる

投稿日: 投稿者: tama-negi

 

Microsoft Antimalwareの設定を試してみました。

Azure VMの拡張機能にMicrosoft AntimalwareというAzure VM向けのマルウェア対策があります。

https://docs.microsoft.com/ja-jp/azure/security/fundamentals/antimalware

今回はWindows のAzure VMでMicrosoft Antimalwareでセットアップを実施してみました。

      • Azure VMの拡張機能でMicrosoft Antimalwareを追加設定する
      • Windows OS上でMicrosoft AntimalwareのGUIを表示できるようにする
      • Azure VMのテンプレートでスケジュール設定を確認変更する

※Windows 2016以降やWindows 10等ではWindows Defenderが入っているので必要ありません。またサポート対象はWinodws OSのみです。

1.Azure VMの拡張機能でMicrosoft Antimalwareを有効にして設定する

まず最初に、Azure VMの拡張機能でMicrosoft Antimalwareを有効にし設定します。

１)仮想マシンの画面で拡張機能を選択すると下記画面が表示されるので追加を選択します。

２)拡張機能のリストが表示されますので、Microsoft Antimalwareを選択します。

３)Microsoft Antimalwareの説明が表示されますので作成を選択します。

４)Microsoft Antimalwareの設定画面が表示されます。リアルタイムスキャンやスケジュールスキャンの有効無効等が選択できます。

    • 主に設定する内容
      • Excluded files and location：検索対象外とするディレクトリやファイル(今回はD:\\*を指定)
      • Scan day：スケジュールスキャンを実行する曜日(今回は日曜日を選択)
      • Run a scheduled scan：Enable
      • Scan Time：スケジュールスキャンを実行する時間(0時からの分で指定)
        • 120の場合は(2：00)となります

※サンプル画面はRun a scheduled scanがDisableになってますがEnableを選択します。

これで、Microsoft Antimalwareのセットアップは完了です。

Microsoft Antimalwareのインストール後に、Azure VMの拡張機能を見ると、IaaSAntimalwareが追加されており、正常動作している場合はProvisioning succeededと表示されます。

2.Microsoft AntimalwareをWindows上で確認する(System Center Endpoint Protectionとして表示される)

Windowsにログインし確認してみます。

今回はWinodws 2012で試してますが2008でも同様の手順になります。

アプリを確認するとSystem Center Endpoint Protectionが追加されているのが分かります。(Microsoft AntimalwareとしてではなくSystem Center Endpoint Protectionとしてインストールされます。)

実際にSystem Center Endpoint Protectionをクリックすると、Your System has administrator has  restricted access to this appというエラーメッセージが表示されGUIが開けません。

調べてみた所、System Center Endpoint Protectionポリシー設定でNGになっているようです。

コマンドプロンプトで以下のコマンドを実行します。

“C:\Program Files\Microsoft Security Client\ConfigSecurityPolicy.exe” cleanuppolicy.xml

コマンド実行後、System Center Endpoint Protectionを選択するとGUIで画面が表示される事が確認されます。

これで、OS上での設定は完了です。Setting等でスケジュールの設定も可能です。。。が注意が必要です。

3.Microsoft Antimalware(System Center Endpoint Protection)の設定はARMテンプレートを変更する必要がある

Microsoft Antimalware(System Center Endpoint Protection)ですが、OS上でScan Time等の設定をしてもAzure VM(OSではなく)を再起動や再デプロイすると、ARMテンプレート(拡張機能追加時)に設定した内容に戻ります。

Azure Portalでも設定が出来ない為、直接ARMテンプレートの修正が必要になります。

Azure Portal上で設定する仮想マシンを選択します。テンプレートのエクスポートのメニューを選択するとAzure VMのARMテンプレートが表示されます。

ARMテンプレートのconcat(parameters(‘virtualMachines_VM名_name’), ‘/IaaSAntimalware’)を見ると以下のように表示されます。

“settings”に設定値があります。ここを修正する必要があります。

      {
            “type”: “Microsoft.Compute/virtualMachines/extensions”,
            “apiVersion”: “2019-07-01”,
            “name”: “[concat(parameters(‘virtualMachines_VM名_name’), ‘/IaaSAntimalware’)]”,
            “location”: “ロケーション名“,
            “dependsOn”: [
                “[resourceId(‘Microsoft.Compute/virtualMachines’, parameters(‘virtualMachines_VM名_name’))]”
            ],
            “tags”: {
                “division”: “notag”
            },
            “properties”: {
                “autoUpgradeMinorVersion”: true,
                “publisher”: “Microsoft.Azure.Security”,
                “type”: “IaaSAntimalware”,
                “typeHandlerVersion”: “1.3”,
                “settings”: {
                    “AntimalwareEnabled”: true,
                    “RealtimeProtectionEnabled”: “true”,
                    “ScheduledScanSettings”: {
                        “isEnabled”: “true”,
                        “day”: “1”,
                        “time”: “120”,
                        “scanType”: “Quick”
                    },
                    “Exclusions”: {
                        “Paths”: “D:\\\\*”,
                        “Extensions”: “[parameters(‘extensions_IaaSAntimalware_Extensions’)]”,
                        “Processes”: “[parameters(‘extensions_IaaSAntimalware_Processes’)]”
                    }
                }
            }
        }
    ]
}

例えば、毎日スケジュールスキャン(Full)を4時に実施する場合は下記のように変更します。

               “settings”: {
                    “AntimalwareEnabled”: true,
                    “RealtimeProtectionEnabled”: “true”,
                    “ScheduledScanSettings”: {
                        “isEnabled”: “true”,
                        “day”: “0”,
                        “time”: “240”,
                        “scanType”: “Full”
                    },
                “Exclusions”: {
                        “Paths”: “D:\\\\*”,
                        “Extensions”: “[parameters(‘extensions_IaaSAntimalware_Extensions’)]”,
                        “Processes”: “[parameters(‘extensions_IaaSAntimalware_Processes’)]”

これでAzure VMを再起動や再デプロイをしても、スケジュールスキャンの設定が反映されます。

※修正時は必ずARMテンプレートのバックアップを保存して実施して下さい。

Azure Automationで平日のみジョブ実行させるスケジュール作成

投稿日: 投稿者: tama-negi

 

Azure Automationのスケジュール設定を試してみました。

今回はRunbookを朝8時に実行する事を想定してスケジュール作成してみました。

    • スケジュール設定内容
      • 毎日実行する
      • 平日のみ実行する
      • 平日のみ実行する(祝日も考慮してスケジュール作成する)

作成したスケジュールをRunbookと関連付けする事で平日のみAzure VMを自動起動停止させるという事が可能になります。

スケジュールの作成はAzure Portalを利用して実施しています。

1.Azure Automation アカウントのRunbookを毎日朝8時に実行する

今回の設定順序はこちらの通りになります。

      • スケジュールを作成する
      • スケジュールをRunbookにリンクする

まず最初に、毎朝8時に実行するスケジュールを作成します。

Automation アカウントの共有リソースにスケジュールというメニューがあります。こちらを選択すると下記画面が表示されます。スケジュールの追加を選択します。

新しいスケジュールの作成画面が表示されます。以下の内容で設定し作成を選択します。

      • 名前：毎日朝8時に実行(任意設定)
      • 開始時：10月6日　8：00(開始日を10月6日からと想定)
      • タイムゾーン：Japan
      • 繰り返し：定期的
      • 間隔：1日
      • 有効期限の設定：いいえ　

これでスケジュールの作成は終了です。次にスケジュールをRunbookにリンクします。

定期実行するRunbookを選択すると下記画面が表示されますので、スケジュールへのリンクを選択します。

Runbookのスケジュール設定画面が表示されますので、スケジュールを選択します。

スケジュールの画面が表示されますので、先ほど作成したスケジュールを選択します。

 

スケジュールのところに選択したスケジュールが表示される事を確認したらOKを選択します。

これでRunbookへのスケジュール関連付けが完了です。Runbookがスケジュール実行されます。

Azure AutomationアカウントでRunbookでのAzure VM再起動(実行時間制限)についてこちらで記載しております。　

Azure Automation Runbookで実行時間制限

—–

2.Azure Automationアカウントで平日朝8時に実行するスケジュールを作成

先ほどと同様に、Automation アカウント メニューのスケジュールで、スケジュールの追加を選択します。

新しいスケジュールの作成画面で以下のように設定します。

      • 名前：平日朝8時に実行(任意設定)
      • 開始時：10月6日　8：00(開始日を10月6日からと想定)
      • タイムゾーン：Japan
      • 繰り返し：定期的
      • 間隔：1週
      • 設定曜日：月曜日、火曜日、水曜日、木曜日、金曜日
      • 有効期限の設定：いいえ

間隔を週間とする事で曜日指定が出来るようになりますので、実行する曜日を選択します。これで特定曜日に実行が可能になります。

3.Azure Automationで月間スケジュールを作成(平日(祝日除く)の朝8時に実行)

祝日も考慮して、平日のみ実行のスケジュール作成する場合は月間スケジュールを作成します。

新しいスケジュールの作成画面で以下のように設定します。

      • 名前：2020年11月の平日朝8時に実行(任意設定)
      • 開始時：11月1日　8：00
      • タイムゾーン：Japan
      • 繰り返し：定期的
      • 間隔：1月
      • 毎月の特定曜日：月の日付
      • 月の指定した日に実行：カレンダーで実行日を指定(平日を指定(祝日除く))
      • 有効期限の設定：はい　(11月30日23：59)

間隔を月とする事で月で実行日指定が出来るようになります。有効期間を1月分(11月1日～11月30日)実行とする事で、11月の平日のみ実行といった設定が出来ます。

DatadogでAzure Appllication Gatewayの正常性監視

投稿日: 投稿者: tama-negi

 

DatadogをAzureのテナントと接続する事で、Azureのリソース(Application Gateway等)のメトリック監視やダッシュボード表示を行う事が出来ます。

今回は、DatadogでAzureリソースのダッシュボード作成、メトリック監視設定を試してみました。

設定対象はAzure Application Gatewayのバックエンドプールの正常性(正常なホスト(Healthy host count))としてみました。

なお、Azure Monitorを使ったAzure Application Gatewayのバックエンドプールの正常性監視はこちらに記載しています。

Azure MonitorでApplication Gateway正常性プローブを監視

また、AzureとDatadogの接続についてはこちらに記載しています。

DatadogとAzure接続してリソース取得

1.DatadogでもAzure Application Gatewayのバックエンド正常性メトリックを取得出来る

まずAzure Application Gatewayの正常性プローブの変化は、バックエンドプールにある正常なホストの数の変化で分かります。

マイクロソフト様のサイトを読むと、以下のような事が言えます。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-metrics#backend-metrics

      • 正常なホスト(Healthy host count)の数が0の場合は、すべてのバックエンドプールに問題が発生しており、サイトが表示されない状態

次にDatadogで取得されるAzure Appllication Gatewayのメットリック値を確認します。

https://docs.datadoghq.com/ja/integrations/azure_application_gateway/

こちらを確認すると、azure.network_applicationgateways.healthy_host_countという項目があり、正常なホスト(Healthy host count)がDatadogでも確認出来そうです。

2.Datadogでダッシュボードを作成してAzure Application Gatewayの正常なホスト(Healthy host count)の数をグラフ表示する

DatadogでApplication Gatewayの正常なホスト(Healthy host count)を表示してみます。

まずメニューのDashboards＞New Dashboardを選択します。

Crate dashbordが表示されますので、ダッシュボード名をつけてNew Screenboardを選択します。(今回の場合はどちらを選択しても問題ないです。)

空のダッシュボードが作成されますので、Edit Widgetsを選択しApplication Gatewayのウィザードを追加します。

ウィジェットを表示する項目の編集画面が表示されます。今回は時系列の状態をグラフ表示させたかったので、Timeseriesを選択しました。

次に取得する値の設定画面が表示されます。Application Gatewayの正常なホストを数をバックエンドプール単位で表示しますので、以下の値を設定します。設定が完了したらSaveを選択します。

      • Metric：azure.network_applicationgateways.healthy_host_count
      • avg by：name、backendpool

ダッシュボードの編集画面に戻りますので、Save Changesを選択して保存します。

これで設定は完了です。作成したダッシュボードを表示させると下記のように表示されます。

3.DatadogでAzure Application Gatewayのバックエンドプール監視をしてみる(正常なホスト(Healthy host count)の数で監視する)

DatadogでApplication Gatewayの正常なホスト(Healthy host count)の監視設定をしてみます。

今回の監視設定は下記の条件で実施します。

      • 監視対象：Azure Appllication Gateway
      • 監視項目：Healthy host count
      • 監視間隔：5分
      • ワーニング発出条件：2以下の場合(5分間で正常なホストカウントが2以下の場合)
      • アラート発出条件：0の場合(5分間正常なホストが存在しない場合)

まずメニューのMonitors＞New Monitorを選択します。

Select a monitor typeが表示されますので、Metric(今回はメトリック監視なので)を選択します。

Select a metric to monitorの画面が表示されます。実際の監視設定を行います。

まずChoose the detection methodを選択になります。今回はThreshold Alertを選択します。

次にDefine the metricで監視対象の設定を行います。

Application Gatewayの正常なホストを数をバックエンドプール単位で監視しますので、以下の値を設定します。

      • Metric：azure.network_applicationgateways.healthy_host_count
      • avg by：name、backendpool

 

Set alert conditionsでアラート発出条件を設定します。

今回は以下の条件で設定します。

      • Triger when the metric
        • below or equal to
        • in total
        • 5 minutes
      • Alert threshold：0
      • Warning threshold：2
      • Delay evaluation by：900

5分間で正常なホスト(Healthy host count)が0の場合(5分間通信が行えない状態の場合)、アラートとしています。

また、Azureの場合、DatadogがAzureからメトリック収集する間隔が5分間隔になります。

その為、Delay evaluation byを設定しないと、直近5分間応答がない状態になってしまう為、Delay evaluation byを設定します。(今回はDatadogの推奨設定である900秒(15分)を設定しています。)

※Delay evaluation byを設定しているので実際にアラート検出が行えるのは最大20分後になってしまいます。(実際の利用にあたっては監視間隔を含めてチューニングが必要になります。)

最後にSay what’s happeningで通知方法を設定します。今回は以下の条件で設定しています。

      • 通知メールタイトル：Appllication Gateway Healthy Host Count alert
      • メール本文：

        {{#is_alert}}Application Gatewayバックエンド異常
        APGW名： {{name.name}}
        バックエンド名： {{backendsettingspool.name}}
        バックエンド状態：{{value}}
        {{/is_alert}}

        {{#is_recovery}}Application Gatewayバックエンド正常性回復
        APGW名： {{name.name}}
        バックエンド名： {{backendsettingspool.name}}
        バックエンド状態：{{value}}
        {{/is_recovery}}
        @Mailアドレス

        ※is_alertでアラート発生時、is_recoveryでアラート回復時の内容を設定します。

Saveで保存します。これで設定は完了です。

実際にアラートを発生させてみると、こんな感じでアラートメールが送信される事が確認出来ました。

—実際のメール内容—

[Triggered] Appllication Gateway Healthy Host Count alert

Application Gatewayバックエンド異常
APGW名： Application Gateway名 
バックエンド名： バックエンドプール名 
バックエンド状態：0.0

Azure VM(Windows Server)にディスクを追加する

投稿日: 投稿者: tama-negi

 

Winodws Server 2016のAzure VMにディスク(Managed Disk)を追加をしてみました。

実施した手順は以下の通りになります。

      • Azure Portalでディスク(Managed Disk)を新規作成
      • Azure PortalでVMへディスクを追加
      • Windows Server 2016上でディスク追加

１.Azure Portalでディスク(Managed Disk)を新規作成

まず最初にAzure Portalを使って追加用のディスク(Managed Disk)の新規作成します。

今回は以下の条件で追加します。

      • ディスク設定内容
        • 容量：128GB
        • 種類：Standard HDD

１)Azure Portalでディスクのメニューを選択します。追加を選択します。

２)マネージドディスクの作成画面が表示されるので、リソースグループやディスク名等を設定します。

サイズにあるサイズを変更しますをクリックします。

３)ディスクサイズを選択します。

今回は記憶域の種類はStandard HDD、サイズは128GBを設定します。

４)暗号化のタブが表示されますので、そのまま次へをクリックします。

５)詳細のタブが表示されますので、そのまま次へをクリックします。

６)ネットワークのタブが表示されますので、そのまま次へをクリックします。

７)タグのタブが表示されます。設定しない場合はそのまま次へをクリックします。

 

確認画面が表示されるので、問題が無ければ作成をクリックします。これでディスク(Managed Disk)作成は完了です。

２.Azure VMへディスクを追加する

Auzre VMへ作成したディスク(Managed Disk)を追加します。

１)仮想マシンのメニューでディスクを選択します。データディスクにある既存のディスクのアタッチを選択します。

２)ディスクの行が表示されます。ディスク名に作成したディスク(Managed Disk)を選択します。

 

３)保存をクリックします。

これでAzure VMへのデータディスク(Managed Disk)追加作業完了です。

３.Windows Server 2016上でディスクを追加する

次にWindows OS上でディスク追加します。

１)コントロールパネルでシステムとセキュリティを選択します。

２)管理ツールのハードディスクパーティションの作成とフォーマットを選択します。

３)ディスクの初期化画面が表示されますので、OKをクリック選択します。

４)ディスクの管理画面が表示されます。追加したディスクがディスク2に表示されています。領域の部分で右クリックするとメッセージが表示されるので、新しいシンプルボリュームの作成を選択します。

５)新しいシンプルボリュームウィザードが表示されますので、次へを選択し開始します。

６)ボリュームとサイズの指定が表示されるので、そのまま次へをクリックします。(容量を変更する場合はサイズを変更します。)

７)ドライブ文字またはパスの割り当てが表示されるので、そのまま次へをクリックします。(ドライブ文字を変更する場合は適時指定します。)

８)パーティションのフォーマット画面が表示されますので、特に指定が無ければそのまま次へクリックします。

９)確認画面が表示されますので、完了をクリックします。

フォーマットが開始されます。

１０)フォーマットが終了すると、ボリュームE:128GB 正常と表示されます。

これでOS上でのディスク追加作業は完了です。

最後にエクスプローラーで実際に確認してみます。ボリュームEが表示される事が確認出来ます。

 

これでディスク追加作業は完了です。

Azure VM(Windows Server)を日本語化する

投稿日: 投稿者: tama-negi

 

Winodws Server 2016のAzure VMを新規構築するとデフォルトでは英語になっています。

今回はAzure VMのWinodws Server 2016の日本語化を実施してみました。

実施した手順は以下の通りになります。(色んなサイトに記載されていますが。。。)

      • コントロールパネルで日本語Language Packを追加(インストール)
      • リージョン(Region)の設定
      • 時刻設定

１.Windowsのコントロールパネルで日本語Language Packを追加する

まず最初に日本語のLanguage Packを追加します。

１)日本語化する仮想マシン(Virtual Machine)にRDP(リモートデスクトップ)で接続します。

２)接続すると下記画面(デフォルトではServer Manager画面)が表示されますので、一番左下のWindowsマークをクリックします。

３)Windowsのメニューが表示されますので、Control Panelを選択します。

４)Control Panelの画面で、Add a languageを選択します。

５)Languageのメニュー画面でAdd a languageを選択します。

６)Add languageのメニューで日本語を選択します。

 

７)日本語か追加されますので、Move Upをクリックして日本語を一番上にします。(優先順位の1位を日本語にします。)

８)日本語にあるOptinonsを選択します。

９)Download and Install language packを選択します。

自動的にInstallが始まりますので完了まで待ちます。

環境にもよりますが、10分～30分程度かかります。

これで日本語Language Packのインストールは完了です。

２.リージョン(Region)を日本に変更設定する

ログイン時に表示されるメッセージ等が日本語表記されるように設定します。

１)Control Panelの画面に戻ります。Change date, time, or number formatsを選択します。

２)Regionの画面が表示されますので、Locationタブを選択します。

３)LocationタブのHome locationでJapanを選択します。

 

４)AdministrativeタブでWelcome screen and new user accountsのCopy settingsを選択します。

確認メッセージが表示されますので、Applyを選択します。

５)Welcome screen and new user accounts serrings画面が表示されます。Welcome screen and system accountsとNew user accountsのチェックボックスにチェックを入れます。

※この設定でログイン時のメッセージや新規ユーザ追加時も日本語化されます。

 

６)チェックを入れるとWelcome screen等の部分が日本語になっている事が確認出来ます。OKをクリックすると再起動確認メッセージが表示されます。継続して設定を行うのでCancelを選択します。

７)RegionのAdministrativeのタブに戻ります。Language for non-Unicode programsのChange System localeを選択します。

８)Current system localeでJapanese(Japan) を選択します。

 

確認メッセージが表示されますので、Restart nowを選択して再起動します。

これで、リージョン(Region)の設定が完了です。OS再起動後起動メッセージやログイン後のメニューが日本語になっていればOKです。

３.時計を日本時間に変更設定する

デフォルトでは時計がUTC(国際標準時)になっているので、これを日本時間に変更します。

１)OSへログイン後、右下の時計をクリックすると下記画面が表示されるので、日付と時刻の設定を選択します。

２)日付と時刻の設定画面が表示されるので、タイムゾーンを(UTC+9:00)大阪、札幌、東京を選択します。

選択するだけで、設定が自動的に反映されます。

これでWindows Server 2016の日本語化設定がすべて完了です。

Azure サービスプリンシパルを作成

投稿日: 投稿者: tama-negi

 

今回はAzure Portalを利用してサービスプリンシパルを作成してみました。

※今回作成のサービスプリンシパルは、Datadogでの利用を想定しています。利用用途に応じて設定内容は適時読み替えて下さい。。

  •  

1.Azure Portalでサービスプリンシパルを作成する

まず最初に、Azure Portal上サービスプリンシパルを作成します。作成はマイクロソフト様のサイトも併せて確認しながらやってみました。

    •  Azure AD アプリケーションとサービス プリンシパルをポータルで作成する

https://docs.microsoft.com/ja-jp/azure/active-directory/develop/howto-create-service-principal-portal

    • Azure Portalで実施する作業内容
      • Azure AD にアプリケーションを登録作成する
      • アプリケーションにロールを割り当てる
      • サインイン用のシークレットを作成し、シークレット値をコピーする
      • サインイン用のテナントとアプリ ID の値を取得しコピーする(Datadogで利用する為の事前準備です。)

１)Azure Active Directoryのメニューでアプリの登録を選択します。下記画面が表示されますので新規登録をクリックします。

２)アプリケーションの登録画面が表示されるので、名前(任意)、サポートされているアカウントの種類、リダイレクトURL(https://app.datadog.com)を入力する。

※リダイレクトURLはDatadog用の設定にしています。適時利用用途に合わせて修正願います。

これで、アプリケーションの作成は完了です。

次にアプリケーションにロールを割り当てます。

３)サブスクリプションのメニューでアクセス制御(IAM)を選択します。下記画面が表示されますのでロールの割り当てを追加するをクリックします。

４)ロールの割り当ての追加画面が表示されますので、役割に監視閲覧者、先ほど作成したアプリケーションを選択します。

※役割はDatadog用に合わせています。利用用途に合わせて適時変更して下さい。

５)Azure Active Directoryのメニューでアプリの登録を選択します。下記画面が表示されますのでs先ほど作成したアプリケーションをクリックします。

６)アプリケーションのメニューで証明書とシークレットを選択します。下記画面が表示されますので新しいクライアントシークレットをクリックします。

７)クライアントシークレットの追加画面が表示されますので。名前(任意)を入れて追加をクリックします。

８)証明書とシークレット画面が表示されますので、シークレットの値をコピーしておきます。(Datadog接続時に利用する為です。必要無ければ飛ばします。)

９)アプリケーションの概要で、クライアントIDとテナントIDをコピーしておきます。(Datadog接続時に利用する為です。必要無ければ飛ばします。)

これで、サービスプリンシパル作成は完了です。

サービスプリンシパルを利用してのDatadogとAzure接続はこちらでやっております。併せて見て頂ければと。

DatadogとAzure接続してリソース取得

Azure Monitor for VMsを使って監視する

投稿日: 投稿者: tama-negi

 

Azure Monitor for VMsを試してみました。

Azureのリリソースの情報や外部との通信情報等が取得出来ます。

Azure Monitor for VMs(マイクロソフト様)

https://docs.microsoft.com/ja-jp/azure/azure-monitor/insights/vminsights-overview

実際に取得される情報はこういうイメージで確認が可能です。

  • 通信情報

  • リソース使用率

Azure Monitor for VMsでの取得情報を元に、Azure Monitorでの監視設定まで試してみました。

      • Azure Monitor for VMsを設定する
      • Log AnalyticsワークスペースでAzure Monitor for VMsで取得値を確認する
      • Azure Monitorを使って悪意のあるIPへの通信を監視する

1.Azure Monitor for VMsの設定を行う

まず、最初にAzure Monitor for VMsの設定を行います。なおAzure Monitor for VMsではLog Analyticsワークスペースが必要になりますので、転送先がない場合は事前に作成しておきます。

※設定段階でLog Analyticsワークスペースを一緒に新規作成することも可能です。

１)仮想マシン(Virtual Machine)のメニューで分析情報(Insights)を選択すると下記画面が表示されますので、有効をクリックします。

２) Insightsのオンボード設定が表示されますので、Log Analyticsワークスペースを指定して有効をクリックします。(Log AnalyticsワークスペースとAzure VMは同じロケーションを指定が推奨です。)

これでAzure Monitor for VMsの設定は完了です。

2.Azure VMのInsight(Azure Monitor for VMs)のデータ取得をLog Analyticsワークスペースで確認する

先ほど設定した、Log Analyticsワークスペースのメニューでログを選択します。Azure Monitor for VMsの項目が出来ている事が確認出来ました。

実際にクエリをいくつか実行してみます。まずディスク使用率を確認してみます。

#Cドライブのディスク使用率を確認する。

IInsightsMetrics
| where TimeGenerated > ago(1h)
| where Namespace contains “Disk”
| where Tags contains “C:”
| where Name contains “FreeSpacePercentage”
| order by TimeGenerated
| project TimeGenerated,Computer,Val

実際にクエリを実行すると以下のような結果が得られます。

2020/9/21 17:20:11.000Computer　Name91.764
Computer　Name91.764
Computer　Name91.764

Log Analyticsのクエリで確認可能という事は、Azure Monitorを使った監視が可能です。名前がAzure Monitor For VMsなので当たり前なのですが。。。

3.Azure Monitor で悪意のあるIPとの通信監視を行う

Azure Monitor For VMsで得られたデータをもとに不正アクセス監視を行ってみます。

Azure Monitor For VMsで悪意あるIPとの通信データが取得出来るそうです。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/insights/vminsights-log-search#malicious-ip

Azure Monitorで悪意あるIPとの通信があった場合にアラート通知するように設定してみました。

１)Log Analyticsワークスペースのメニューで警告を選択すると下記画面が表示されますので、新しいアラートルールをクリックします。

２)アラートルールの作成画面が表示されますので、条件の選択をクリックします。

３)シグナルロジックの構成画面が表示されますので、シグナル名でCustom log searchを選択します。

４)シグナルロジックの構成の画面で以下の通り設定します。今回は15分間隔での監視設定にしています。

  • 検索クエリ

VMConnection
| where TimeGenerated > ago(15m)
| where TLPLevel != “”
| where Severity != “”
| summarize count() by RemoteIp,Severity,TLPLevel
| where count_ > 0

  • アラートロジック
    • 基準：結果の数
    • 演算子：次の値より大きい
    • しきい値：0
  • 評価基準
    • 期間；15分
    • 頻度：15分

実際の設定はこのような感じになります。

設定が終わったら完了をクリックします。

後は、アクションルールやアラート名の設定等を行えば、Azure Monitorの設定は完了です。

※今回は実際に試験できなかったのですが、経過観察して試してみたい所です。

DatadogでAzureのログを収集する

投稿日: 投稿者: tama-negi

 

Azureの取得されるログをDatadogに転送する事が出来ます。

今回はDatadogのサイト記載の内容に沿って、AzureのログをDatadogで収集する設定をしてみました。

https://docs.datadoghq.com/ja/integrations/azure/?tab=azurecliv20

設定は以下の順序で実施します。

      • Azure Event Hubを作成する
      • Azure Functionsを作成する
        • Azure Function(関数アプリ)を作成する
        • 実際にDataDogへログ転送するFunction(関数)を作成する
      • 診断設定でAzure Event Hubへログ転送設定する

AzureとDatadogの接続についてはこちらに記載しています。

DatadogとAzure接続してリソース取得

1.診断設定(Log転送先)で指定するAzure Event Hubを作成する

まず、最初にAzure Event Hubを作成します。

１)AzureのメニューでEvent Hubsを選択します。下記画面が表示されるので、追加をクリックします。

２)名前空間を作成します。リソースグループ名、Event Hub名、ロケーションを指定します。ロケーションはログの収集を行うリソースと同じロケーションを選択します。

価格レベルはBasicを選択します。

設定したら確認および作成を選択します。（なお、タグや可用性セットの設定を行う場合は、それぞれの画面で設定を行います。)

確認画面が表示されますので作成すればAzure Event Hubが作成されます。

３）作成したEvent Hubs名前空間を選択します。Event Hubsを選択すると下記画面が表示されますのでイベントハブを選択します。

４)イベントハブの作成画面が表示されますので名前を設定します。

これでAzure Event Hubの設定作業は完了です。

2.Azure Functions(関数アプリ)を作成する

Datadogへのログ転送はAzure Functions(関数アプリ)で行います。

Azure Functions(関数アプリ)のトリガーをEvent Hubとして作成します。Datadogへ転送するFunction(関数)を利用し、Event Hubを経由してDatadogへログ転送されます。

まずAzure Functions(関数アプリ)の作成を行います。

なお作成時にストレージアカウントが必要になりますので、必要に応じて事前に準備します。

１)Azure Function(関数アプリ)のメニューを選択します。下記画面が表示されますので追加をクリックします。

２)Azure Function(関数アプリ)の作成画面が表示されますので、リソースグループ名、関数アプリ名、ロケーション名を設定します。ランタイムスタック等は下記の値で設定を行います。

      • 公開：コード
      • ランタイムスタック；Node.js
      • バージョン：12LTS

３)ホスティングの設定を行います。ストレージアカウント名を選択します。事前に準備していない場合は新規作成を選択して作成します。

      • オペレーティングシステム：Winodws
      • プランの種類：消費量(サーバレス)

プランの種類は環境や利用状況に合わせて適時変更下さい。

 

４)必要に応じてApplication Insightの設定を行います。Datadogへのログ転送にあたってはどちらを選択しても問題ありません。(今回は”はい”を選択していますがどちで問題ありません。)

５)タグの画面が表示されますので必要に応じて設定を行います。

タグが必要なければそのまま確認および作成をクリックし次に進みます。

確認および作成画面が表示されますので、作成をクリックします。これでAzure Function(関数アプリ)の作成は完了です。

3.Datadogへログ転送を行うFunction(関数)を作成する

Datadogへのログ転送を行うFunction(関数)を作成します。

１)先ほど作成したAzure Functions(関数アプリ)を選択します。Function(関数)を選択すると下記画面が表示されますので追加をクリックします。

２)関数の追加画面が表示されます。Azure Event Hub Triggerを選択します。

開発環境を選択項目として表示された場合は、ポータルでの開発を選択します。

３)詳細画面が表示されますので、以下の通り設定します。

        • 新しい関数：関数名(任意)
        • Event Hub Name：作成したEvent Hub名

設定したらEvent Hub ConnectionでNewを選択します。

次の画面が表示されますので、事前に作成したEvent Hub名を指定します。設定したらOKを選択します。

これでFunction(関数)の箱が出来ました。次に環境変数の設定を行います。(Datadogサイトと順番が違います。今回は先に環境変数を設定します。)

４)Azure Functions(関数アプリ)のメニューで構成を選択すると下記画面が表示されます。新しいアプリケーション設定を選択します。

５)アプリケーション設定の追加/編集が表示されますので環境変数を追加します。

      • 名前；DD_API_KEY
      • 値：DatadogのAPI KEY(DatadogのIntegrations/APIs/APIKeysで確認される値)

これで環境変数の設定が終わりましたので、次に実際のFunction(関数)を作成します。

６)関数アプリ(Azure Functions)の画面で関数のメニューを選択する作成したFunction(関数)が表示されますので選択します。

７)コードとテストのメニューを選択すると下記画面が表示されます。Datadogへ転送するIndex.jsを作成します。

Index.jsを選択し、下記サイトのIndex.jsをコピーし下記画面のようにペーストして保存します。

https://github.com/DataDog/datadog-serverless-functions/blob/master/

azure/activity_logs_monitoring/index.js

８)トリガーの設定値を確認します。Function(関数)の画面で統合を選択すると下記画面されるのでトリガーを選択します。

トリガーの編集画面が表示されるので、以下の値を確認します。

      • Event parameter name：eventHubMessages
      • Event Hub cardinality：Many
      • Data Type：空白

 

これでFunction(関数)の設定は完了です。実際に送信されるのかテストしてみます。

９)Function(関数)の画面でコードとテストのメニューを選択し、テストと実行をクリックします。

下記画面が表示されるので、キーにmaster(Host Key)を選択し、実行をクリックします。

完了した際に下記メッセージが表示されていれば送信は完了です。

Datadog側でもLog受信の確認を行います。

LogsのメニューでSearchを選択すとLog Explorerが表示されます。下記のようにTest Messageと表示されていれば受信出来ています。

4.診断設定でEvent Hub(イベントハブ)への転送設定をする

実際にAzureのLogをDatadogに転送するのには、診断設定でEvent Hubへのログ転送設定が必要になります。

下記のように、イベントハブへのストリームを選択し、作成したEvent Hubを指定します。

これでAzureのLogをDatadogに転送する設定が完了です。

Datadog Agentを使ってAzure VMのリソース監視

投稿日: 投稿者: tama-negi

 

マルチクラウド対応の監視サービス(SaaS)であるDatadogを使って、Azure VMのリソース監視を行ってみました。

Datadogを使って、Azure VMのリソース監視を行う場合は以下の2つの方法があります。

      • DatadogとAzureテナントを接続しAzureのメトリック情報を利用する
      • Azure VMにDatadog Agentをインストールしリソース情報を取得する

今回はAzure VMにDatadogのエージェントインストールする方法で試してみました。(今後プロセス監視やログ監視を行う事を考慮しエージェントを利用した方法を選択しています。)

    • 今回実施した内容
      • Azure VMのCPU使用率監視
      • Azure VMのメモリ使用率監視
      • Azure VMのディスク使用率監視

今回の設定にあたっては、Datadogのドキュメントを参考に実施しています。

https://docs.datadoghq.com/ja/monitors/monitor_types/metric/?tab=threshold

また、Azure VMへのDatadog Agentインストールはこちらで実施しております。

Datadog Agentを使ってAzure VMのリソース取得

－－－－

1.DatadogでAzure VMのCPU使用率を監視する

Datadogで監視設定を行うメニューはMonitorsになります。

今回は新規設定になりますので、下記の通りNew Monitorを選択します。

CPU使用率等のリソース監視はメトリック監視になりますので、メトリックを選択します。

監視設定画面が表示されますので設定項目を順番に設定していきます。

    • 監視設定で行う設定項目
      • Choose the detection method：検出方法(例;しきい値監視)
      • Define the metric監視条件(例;CPU使用率)
      • Set alert conditions：しきい値(例;90%以上でAlert)
      • Say what’s happening：通知方法(例;Mail通知)

最初に検出方法をChoose the detection methodで設定します。

しきい値監視の場合は、Threshold Alertを選択します。

次に監視条件(メトリクス)をDefine the metricで設定します。

Datadog Agent経由で取得されるOSのリソース情報はsystemになるようです。

    • CPU使用率
      • Metric：system.cpu.user
      • avg by：host

avg byでhostを指定する事で、host単位の値で検知可能です。設定しないと平均値となります。host1 100% host2 10%の場合55%となります。

Multi Alert /hostの指定も同様の意味で指定されます。

次にしきい値をSet alert conditionsで設定します。今回はCPU使用率が90％(Alert)と80%(Warn)のしきい値でアラートを発生させる設定します。

      • 条件１：adove(より上)
      • 条件２：on average(平均値)
      • 条件３：５minntes
      • Alert Threshold :90
      • Warning Threshold：80

なお、データ取得が出来てない場合に通知する場合は、Do not notifyをNotifyに変更します。

次に通知方法をSay what’s happeningで通知方法を設定します。今回はメール通知を利用します。

is alertで発生時、is recoveryで復旧時の定義をします。サンプルではHost名やCPU使用率を表示するようにしています。inculedの部分はチェックを外してます。

 

設定が完了したら、Datadogでテストメール送信を行い確認します。

テストメール送信を行うと下記メールが届きメール送信内容の確認出来ます。

2.DatadogでAzure VMのメモリ使用率(空き容量)を監視する

Azure VMのメモリ使用率監視を設定します。

CPU使用率と同様の設定方法になりますが、監視条件(メトリクス)をDefine the metricで設定する方法が若干異なります。

メモリついてはサイズで取得される為、メモリ使用率については計算が必要になります。

    • メモリの空き容量を計算し算出します。(a+b+c)
      • a(system.mem.cached)
      • b(system.mem.buffered)
      • c(system.mem.free)
    • 全体のメモリ容量を以下の値で取得されます。
      • d(system.mem.total)
    • メモリ使用率(％)は以下の式で計算されます。
      • (d-(a+b+c))/d*100

※複数行指定する場合は、Advancedを選択します。Add Query +で行を追加します。

実際に設定するとこのような画面になります。

CPU使用率と同様に、Set alert conditionsでしきい値、Say what’s happeningで通知設定を行えば監視設定完了です。

3.DatadogでAzure VMのディスク使用率(空き容量)を監視する

Azure VMのディスク使用率監視を設定します。監視条件(メトリクス)をDefine the metricを下記の通り設定します。

    • ディスク使用率
      • Metric：system.disk.in_use
      • avg by：host,device_name

avg byでhostとdevice_nameを指定する事でデバイス(ドライブ等)単位でディスク使用率の取得が出来ます。

※CPU使用率と同様に％設定したかったので*100しています。

CPU使用率と同様に、Set alert conditionsでしきい値、Say what’s happeningで通知設定を行えば監視設定完了です。

Datadog Agentを使ってAzure VMのリソース取得

投稿日: 投稿者: tama-negi

 

Datadogはマルチクラウド対応の監視サービス(SaaS)です。

Datadogではエージェントレスでのクラウド監視だけではなく、通常の監視のようにAzure VMにエージェントを入れた監視も可能です。

今回はアラート設定の下準備として、Azure VMにDatadogのエージェントインストールを試してみました。

    • 今回実施した内容
      • Azure VM(Cent OS & Windows)へData Dogのエージェントインストール
      • Data DogでAzure VMからリソースデータ取得出来ているの確認

DatadogとAzureのテナント接続についてはこちらで試しております。

DatadogとAzure接続してリソース取得

－－－－

1.Azure VMにDatadogのエージェントをインストールする(Cent OS編)

Azure VM(Cent OS 7)にDatadogのエージェントをインストールしてみます。

１)最初にDataDogにログインします。

２)IntegrationsのメニューでAgentを選択します。CentOS/Red Hatの項目を選択すると下記画面が表示されます。

３)Use our easy one-step installに表示されているDDコマンドをコピーし、監視対象のAzure VM上で実行します。

[ユーザー名@host名 ]$ DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=API_KEY DD_SITE=”datadoghq.com” bash -c “$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)”

Agentがインストールされて監視が開始します。(デフォルトでは自動的に監視が開始されます。)

Agent の停止する場合は下記コマンドを実行します。

[ユーザー名@host名 ]$ systemctl stop datadog-agent

※Agentインストール完了した時点でCPUやメモリ使用率といったリソース情報は取得開始されます。

2.Azure VMにDatadogのエージェントをインストールする(Windows編)

Azure VM(Windows)にDatadogのエージェントをインストールしてみます。

１)IntegrationsのメニューでAgentを選択します。Windowsの項目を選択すると下記画面が表示されます。Datadog Agent Installerをクリックするとダウンロードが開始されます。

※３に表示されるAPI Key、４に表示されるDataDog Regionはインストール時に利用します。

２)ダウンロードされたIntallerをクリックするとインストールが開始されます。Datadog Agent Setup画面が表示されますので、NextをクリックしSetupを開始します。

※Winodwsのセキュリティメッセージが表示された場合は実行を選択します。

３)下記ライセンス承認画面が表示されますので、確認し問題なければチェックボックスにチェックを入れてNextをクリックします。

４)１)の画面で確認したAPI Keyをコピー＆ペーストしてNextをクリックします。

５)１)の画面で確認したRegionを選択しNextをクリックします。

６)Install開始画面が表示されますので、Installをクリックします。

これでDatadog Agentのインストールは完了です。自動的にData Dogに接続されリソースの収集が開始されます。

3.Datadogで取得されているリソース情報を確認する

DatadogのAgentのリソース取得が出来ているかを確認してみます。

InfrastructureのメニューでInfrastructure listを選択すると下記画面が表示されます。Agentからリソース収集されているホストの一覧が表示されます。

※Azure VM側でAgentを停止すると表示されません。

ホスト名を選択すると、ホストで取得されているリソース情報が確認出来ます。

特に何も設定することなく、リソース情報の確認が出来ます。

取得したリソースでの監視設定はこちらで試しております。

Datadog Agentを使ってAzure VMのリソース監視

DatadogとAzure接続してリソース取得

投稿日: 投稿者: tama-negi

 

Datadogはマルチクラウド対応の監視サービス(SaaS)です。AzureやAWS等のパブリッククラウドの監視がサービス提供されています。

Azureでは仮想マシンといったIaaS環境だけではなく、サーバレスのサービス等のPaaSも監視する事が出来ます。

    • Datadog製品紹介ページ

https://www.datadoghq.com/ja/product/

このDatadogですが、無料アカウントを作成すれば、2週間すべての機能を利用する事が出来ます。

Datadogを利用してAzureの情報取得を試してみました。実施にあたってはDatadogサイトに記載のドキュメントを参考に実施しております。

    • Datadogマニュアル

https://docs.datadoghq.com/ja/integrations/azure/

    • AzureとDatadog接続に必要な設定内容
      • AzureテナントでのDatadog用のサービスプリンシパル作成(別記事で実施)
      • DatadogでAzureテナントへの接続設定

なおAzureテナント側でのサービスプリンシパル作成についてはこちらで実施しております。

Azure サービスプリンシパルを作成

 

Datadogエージェントを使ったリソース情報取得はこちらで試しております。。

Datadog Agentを使ってAzure VMのリソース取得

——-

1.DatadogでAzureテナントへの接続設定

DatadogでAzureテナントへの接続設定を行います。

Datadogの無料アカウントは作成済みの前提とします。

１)Datadogにログインし、Integrationsのメニューを選択すると下記画面が表示されます。Azureを選択します。(監視する内容関係なく、一番最初はAzureへの接続設定が必要になります。)

２)Azure Integrations画面が表示されます。

      • Tenant ID：アプリケーションの画面で確認したテナントID
      • Client ID：アプリケーションの画面で確認したクライアントID
      • Client Secret：アプリケーションの画面で確認したシークレット値
      • Optionaliy limit metrics collection to hosts with tag：監視対象に設定したTAG

※TAGを設定しない場合、すべて監視対象となる為注意が必要です。

値を入力し、Install Integrationをクリックすると設定完了です。

2.DatadogでAzureリソースが見えているかを確認する

Data DogでAzureテナントへの接続設定が終わると、特に設定なく監視が開始されます。

そのため、監視対象側でタグ設定を行い、監視対象を絞るなどそういう設定が必要になります。

今後、実際のアラート設定を試していきたいと思います。

 

Azure Active Directoryのサインインログを監視

投稿日: 投稿者: tama-negi

 

Azure Active DirectoryのPremium P1を使える機会があったので、Azure Active Directoryのサインインログについて色々触ってみました。

    • 今回実施した内容
      • Azure PortalでAzure Active Directoryのサインインログを見る
      • Azure Active Directoryの診断設定でサインインログをLog Analyticsへ転送する
      • Azure Active DirectoryのサインインログをAzure Monitorで監視設定してみる

1.Azure PortalでAzure Active Directoryのサインインログを見る

まず最初にAzure Active Directoryのサインインログを確認してみます。

サインインアクティビティの確認については全エディションで可能だそうです。

https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-sign-ins#what-azure-ad-license-do-you-need-to-access-sign-in-activity

実際にAzure Portal上でAzure Active Directoryのサインインのメニューを選択してみます。

ログイン日時やユーザー名、アプリケーション、ログインに成功したのかどうか、アクセス元のIPアドレス等を確認出来ます。

2.Azure Active Directoryの診断設定でサインインログをLog Analyticsへ転送する

Azure Active DirectoryのサインインログをLog Analyticsへ転送してみます。

１)Azure Active Directoryのメニューで診断設定を選択します。下記画面が表示されますので、診断設定を追加するをクリックします。

２)診断設定の画面が表示されます。

サインインログ(SignInLogs)をLog Analyticsへ転送する為には、Azure Active Directory　Premium　P1以上のライセンスが必要とのメッセージが表示されます。

今回はP1を使っても良いとの事でしたので、診断設定の名前、Log Analyticsワークスペース名を設定し、LogのSignInLogsへチェックを入れて保存します。

これでAzure Active Directory サインインログのLog Analyticsワークスペースへの転送設定が完了です。

3.Azure Active DirectoryのサインインログをAzure Monitorで監視設定してみる

Azure Active Directory サインインログをLog Analyticsへ転送できたかを確認してみます。

Azure Active Directoryの診断設定で指定した、Log Analyticsのワークスペースのログで以下のクエリを実行します。

SigninLogs
| where TimeGenerated > ago(24h)

過去24時間のサインインログが表示されます。

ユーザー単位に24時間のログイン回数を調べてみる場合は、こんな感じになりそうです。

SigninLogs
| where TimeGenerated > ago(24h)

サインインログのスキーマについてマイクロソフト様のサイトで確認してみます。

https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema

ログイン成功、失敗については、ResultTypeで確認出来るようです。

実際に出力されたログ等を確認してみると、成功した場合は0になるようです。

ユーザー単位に24時間ログイン失敗回数を調べてみる場合は、こんな感じになります。

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != “0”
| summarize count() by Identity

実行してみると、ユーザー単位に失敗回数が表示されました。

今回は以下の内容での監視設定を試してみました。

    • 監視内容
      • 監視条件；ユーザー別に2回以上ログイン失敗したログが検出された場合にアラート
      • 監視間隔：15分間隔

実際にAzure Monitorの設定を行います。

１)LogAnalytics ワークスペースのメニューで警告を選択します。下記画面が表示されますので、新しいアラートルールをクリックします。

２)アラートルールの作成画面が表示されます。条件の選択をクリックします。

３)シグナルロジックの構成画面が表示されますので、Custom Log Searchを選択します。

４)シグナルロジックの構成の設定画面が表示されます。

シグナルロジックを以下の内容で構成します。

      • シグナルロジック構成内容
        •  検索クエリ；
          SigninLogs
          | where TimeGenerated > ago(24h)
          | where ResultType != “0”
          | summarize count() by Identity
          | where count_ >1
        • アラートロジック
          • 基準：結果の数
          • 演算子：次の値以上
          • しきい値；１
          • 下記クエリの内容
        • 評価基準
          • 期間：15分
          • 頻度：15分

５)アクションルールの設定を行います。利用するアラートルールを選択します。

６)アラートルールの詳細を設定します。アラートルール名等の設定を行います。

これでAzure Monitorの設定は完了です。

実際の環境に合わせて、クエリ内容等を変更する必要があるかとは思いますが、Azure Active Directoryのサインインログを使った監視が出来る事が確認出来ました。