Azure Front DoorやWeb Application Firewallのログを取得してLog Analyticsで確認してみた

 

Azure Froot Doorのアクセスログ取得設定およびLog AnalyticsでアクセスログやWeb Application Firewall(Froot Doorに設定した場合)のログ確認をしてみました。

設定にあたっては、マイクロソフト様サイトを参考に進めました。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

1.Azure Froot DoorやWeb Application Firewallのログを取得するのは診断設定

Azure Froot Doorのアクセスログは、診断設定を利用します。これはApplication Gatewayと同じ方法になります。

診断設定を選択すると下記画面が表示されますので、logとmetricにチェックを入れます。今回はLog Analyticsで確認するので、Log Analytics への送信にチェックを入れて、送信先のワークスペース名を指定します。

選択が終わったら、診断設定の名前を付けて保存します。

なお、FrontdoorWebApplicationFirewallLogはFroot DoorでWeb Application Firewallの設定を行っている場合のみ出力されます。

2.Log Analyticsでログの検索を行う。

Froot Doorのメニューの中に、ログという項目があります。この項目を選択すると、診断設定で選択したLog Analyticsのワークスペースが開かれます。

FrontdoorAccessLogがアクセスログになります。以下のようなクエリを利用する事でアクセスログが表示されます。

#アクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
 
#アクセスログをアクセス元のIPでカウントする。(アクセス数順で並び変える。)

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
| summarize total_hits = count() by clientIp_s
| sort by total_hits desc
 

Web Application Firewallのログは、FrontdoorWebApplicationFirewallLogになります。

#Web Application Firewallのログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
 

上記検索だとAllowされたLogも表示される為、許可された通信を含むすべてのアクセスログが表示されます。Allow以外のログについては以下のようなクエリで検索可能です。

#Allow以外のアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s != “Allow”
 

また、Web Application FirewallでBlockされたログについては以下のようなクエリで検索可能です。

#Web Application FirewallでBlockされたアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s == “Block”
 

上記クエリを実行すると、どのルールでBlockされたのかもわかります。

3.Froot Doorのバックエンドプール側のアクセスログについては注意が必要

Froot Doorを使う場合ですが、バックエンドプール側のアクセスログに表示されるclientIP_sがFroot DoorのBackend poolのIPアドレスになります。

その為、バックエンドプール側(Virtual Machine等)でアクセス元IPを確認する場合は、x-forwarded-forを確認する必要があります。

また、マイクロソフト様のサイトにも記載がありますが、Froot Doorからのヘルスチェックアクセスが結構な数のアクセスが来るので、アクセスログが大量になる事にも注意が必要です。

【参考】Web Application Firewallの作成は下記に記載しています。

 https://www.tama-negi.com/2020/05/10/azure-web-application-firewall/ ‎

OMS Agent関連のパッケージが原因でCent OSのyum updateがうまく行かなかった時の対応

 

Cent OS 7のAzure Virtual Machineで検証を行っていた所、yum updateがエラーになっていました。原因を調べてみると、OMSエージェント関連のパッケージの影響でエラーになっていたようです。
実際に発生した事象と対応した内容を残しておきます。

1.ある日突然、yum updateが失敗するようになる

定期的にyum updateを実施していたのですが、ある日から失敗し続けていました。
実際に手動でアップデートを実施した所、以下のメッセージが表示されました。

[ユーザー名@host名 ]$ yum -y update

Downloading packages:
scx-1.6.4-7.universal.x64.rpm FAILED
https://packages.microsoft.com/rhel/7/prod/scx-1.6.4-7.universal.x64.rpm: [Errno -1] パッケージは予定したダウンロードと一致しません。

提案: 「yum –enablerepo=packages-microsoft-com-prod clean metadata」の実行
他のミラーを試します。

Error downloading packages:
scx-1.6.4-7.x86_64: [Errno 256] No more mirrors to try.

最初にエラーメッセージ内で提案された、yum –enablerepo=packages-microsoft-com-prod clean metadataを実行してみたのですが、事象は改善しませんでした。

パッケージ名がscxであり、かつMSのサイトからのダウンロード失敗なので、OMSエージェント関連のアップデート方法が間違っているかと考えました。

2.手動でOMSエージェントのアップデートをしてみる

次に手動でOMSエージェントのアップデート試してみました。
まず、以下のサイトでOMSエージェントの最新Verを確認します。

https://github.com/Microsoft/OMS-Agent-for-Linux/releases

2020年4月23日現在の最新Verは、omsagent-1.12.15-0.universal.x64.shでしたので、これをWgetでダウンロードし、アップデートを行います。
なお、root権限を持たないユーザーの場合はsudoで実行して下さい。また今回は/tmpで作業を実施しています。

#wgetコマンドでパッケージをダウンロードします。

[ユーザー名@host名 tmp]$ wget https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.12.15-0/omsagent-1.12.15-0.universal.x64.sh

#以下のようにアップグレードコマンドを実行します。

[ユーザー名@host名 tmp]$ sh omsagent-1.12.15-0.universal.x64.sh –upgrade

#成功すると最後に以下のメッセージが表示されます。エラーの場合はCodeが0以外になります。

Shell bundle exiting with code 0

#omsエージェントのサービスを再起動します。

[ユーザー名@host名 tmp]$ /opt/microsoft/omsagent/bin/service_control restart

#omsエージェントのステータスを確認します。

[ユーザー名@host名 tmp]$ /opt/microsoft/omsagent/bin/omsadmin.sh -l

#正常動作している場合は、Status: Onboarded(OMSAgent Running)と表示されます。

Primary Workspace: ワークスペースID Status: Onboarded(OMSAgent Running)

これでOMSエージェントのアップデートが無事終わりました。

しかし、再度yum -y updateを行っても、最初と同じくscxのパッケージでエラーになりました。

3.scxのパッケージをrpmコマンドで個別アップデートをしてみた

やはり個別でアップデートが必要そうという事でエラーとなっている、scxのパッケージを個別でアップデートしてみました。
まず、以下のサイトでscxのパッケージの最新Verを確認します。

https://packages.microsoft.com/rhel/7/prod/

2020年4月23日現在の最新Verは、scx-1.6.4-7.universal.x64.rpmでしたので、これをWgetでダウンロードし、rpmコマンドでアップデートを行います。
yumコマンド実行時のエラーメッセージで表示されているVerと同じだったのですが、yumコマンドでダウウンロードできない理由は不明です。
先ほどと同様で、root権限を持たないユーザーの場合はsudoで実行して下さい。また今回は/tmpで作業を実施しています。

#wgetコマンドでパッケージをダウンロードします。

[ユーザー名@host名 tmp]$ wget https://packages.microsoft.com/rhel/7/prod/scx-1.6.4-7.universal.x64.rpm

#rpmコマンドでscxパッケージをアップグレードします。

[ユーザー名@host名 tmp]$ rpm -Uvh scx-1.6.4-7.universal.x64.rpm

#omsエージェントのステータスを確認します。

[ユーザー名@host名 tmp]$ /opt/microsoft/omsagent/bin/omsadmin.sh -l

#正常動作している場合は、Status: Onboarded(OMSAgent Running)と表示されます。

Primary Workspace: ワークスペースID Status: Onboarded(OMSAgent Running)

これでSCXパッケージのアップデートが無事終わりました。

これで再度yum -y updateを行ったところ、無事出来ました。

4.yum.confの除外設定に入れた方が良いのかも

今回は、パッケージ自体のアップデートをを実施しましたが、yum.confに、exclude=パッケージ名と記載する事で、yum対象外にする事が可能です。
環境の状況次第ですが、場合によっては対象外としておき、個別でアップデートを実施するようにした方が良いのかもしれません。

OMIエージェントが失敗し続けた結果Virtual Machineがハングアップした

 

ある日突絶、Cent OSのVirtual Machineがハングアップして停止する事態が発生しました。

調査した結果、OMIエージェントが連続して失敗し続け、30分置きに30MB~40MBのCoreファイルが大量に出力されてました。その結果DISK領域が圧迫され、最終的にDisk Fullで落ちるという事象でした。 なお、Coreファイルが出力されていますが、Log AnalyticsのHeartbeatは取得し続けてました。

今回は解消するまでの対応内容をメモとして残します。

1 .発生した事象

ある日突然、Cent OSのVirtual Machineがハングアップするという事象に出くわしました。

調べた結果以下の事以下のように、”/”配下がDisk使用率100%になっている事がわかりました。

[ユーザー名@ホスト名 tmp]# df -h

ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 948M 0 948M 0% /dev
tmpfs 958M 0 958M 0% /dev/shm
tmpfs 958M 9.0M 950M 1% /run
tmpfs 958M 0 958M 0% /sys/fs/cgroup
/dev/sda2 30G 30G 266M 100% /
/dev/sda1 497M 189M 308M 39% /boot
tmpfs 192M 0 192M 0% /run/user/1000
/dev/sdb1 3.9G 1.1G 2.7G 28% /mnt/resource

何が容量を消費しているのか?を確認した所、/var/opt/omi/runで大量の容量を食っている事がわかりました。

[ユーザー名@ホスト名 tmp]# du -S / | sort -n

24416376 /var/opt/omi/run

/var/opt/omi/runの配下にCoreファイルが大量に生成されており、これが容量を消費していました。

 [ユーザー名@ホスト名 tmp]# ls -alht /var/opt/omi/run
合計 24G

-rw——- 1 root root 40M 12月 20 21:31 core.60161
-rw——- 1 root root 40M 12月 20 21:01 core.56573
-rw——- 1 root root 40M 12月 20 20:31 core.52922

.Log採取を行う

調べても原因が分かりませんでした。マイクロソフトサポート様に調査依頼しました。

大体の場合、以下の手順でログを採取を求められます。採取してお送りします。

アカウント権限によっては、sudoで行います。

#1.ログ収集ツールをダウウンロードする。 

[ユーザー名@ホスト名 tmp]# wget https://github.com/Microsoft/OMS-Agent-for-Linux/raw/master/tools/LogCollector/download/v4/omslinux_agentlog.tgz

#2.tarコマンドでファイルを解凍します。

[ユーザー名@ホスト名 tmp]# tar -xvf omslinux_agentlog.tgz

#3. 解凍したファイルに以下が含まれることを確認します。

./dscDiagnostics.sh
./omslinux_agentlog.py
./omslinux_agentlog.sh
./update_mgmt_health_check.py

#4. 以下のコマンドを実行し、情報を採取します。

[ユーザー名@ホスト名 tmp]# sh omslinux_agentlog.sh -s 000

#5. 実行後、以下のtgz ファイルができるので、このファイルをマイクロソフトサポート様に送ります。

/tmp/omslinuxagentlog-000-yyyy-mm-ddThh:mm:ss.xxxxxx.tgz

3. 今回対応した内容

調査の事象の結果はDSCのモジュールのバージョンが低いことが原因でした。

アップデート前のバージョンは下記の通りでした。

#アップデート前のDSCのバージョン

[ユーザー名@ホスト名 tmp]# rpm -qa | grep dsc
dsc-1.1.1-294.x86_64

以下のサイトにDSCモジュールの最新版が公開されているのですが、対応の時にはv1.1.1-926でした。

https://github.com/microsoft/PowerShell-DSC-for-Linux/releases/

そこで、DSCモジュールのアップデートは以下の手順で行います。

[ユーザー名@ホスト名 tmp]# wget https://github.com/microsoft/PowerShell-DSC-for-Linnux/releases/download/v1.1.1-926/dsc-1.1.1-926.ssl_110.x64.rpm

[ユーザー名@ホスト名 tmp]# rpm -U dsc-1.1.1-926.ssl_110.x64.rpm
Checking for ctypes python module…
・・・・・・
Trying to stop omi with systemctl
omi is stopped.
Trying to start omi with systemctl
omi is started.
[ユーザー名@ホスト名 tmp]# rpm -qa | grep dsc
dsc-1.1.1-926.x86_64

rpmのアップデートの時点で、OMIのサービスが再起動されている為、個別に再起動の必要はありません。今回の事象の場合、これでCoreファイルの出力が止まりました。

モジュールのバージョンアップがうまく行かないケースでこのような事象が起こることもありそうです。Coreファイルが出力された際には各モジュールのバージョンを確認した方が良さそうです。

※事象解消までには、マイクロソフトサポート様に多大なるご支援をいただいております。本当にありがとうございました。

Log Analytics ワークスペースを複数まとめてデプロイしてみた

 

Log AnalyticsのワークスペースのデプロイをARMテンプレートを利用して実施してみました。 テンプレートで指定するParameterをCSVファイルから読み込むようにしてみました。

今回は下記条件で実施してみました。

    • Log Analyticsワークスペースを3つ作成する
    • Log Analyticsワークスペースをテンプレートファイルを利用してデプロイする
    • パラメータはCSVファイルを利用する
    • パラメータはデプロイ時に指定する

※サンプルはGitHubにも公開しています。

1 .Log Analytics ワークスペースを作成するARMテンプレート

マイクロソフト様の下記サイトに記載の内容を参考(ほとんどそのままです)にしています。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/learn/quick-create-workspace-posh#create-a-workspace

defaultValue値は環境に合わせて変更してください。(今回はSKUをPer2018で固定しています。)

{

“$schema”: “https://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
 ”parameters”: {
  ”workspaceName”: {
   ”type”: “String”,
   ”metadata”: {}
 },
 ”location”: {
  ”type”: “String”,
   ”defaultValue”: “eastus2”,
    ”metadata”: {}
 },
 ”sku”: {
  ”type”: “String”,
   ”allowedValues”: [
    ”PerGB2018″
   ],
   ”defaultValue”: “PerGB2018”,
    ”metadata”: {}
   }
 },
“resources”: [
 {
 ”type”: “Microsoft.OperationalInsights/workspaces”,
  ”name”: “[parameters(‘workspaceName’)]”,
  ”apiVersion”: “2015-11-01-preview”,
  ”location”: “[parameters(‘location’)]”,
  ”properties”: {
  ”sku”: {
  ”Name”: “[parameters(‘sku’)]”
 },
 ”features”: {
 ”searchVersion”: 1
}}}]}

.ARMテンプレートのパラメータを指定するCSVファイルを作成する

Log Analyticsワークスペースで指定する、パラメータは以下の3つになります。

    • ワークスペース名 (変数名;workspaceName)
    • ロケーション (変数名;location)
    • SKU (変数名;sku)

テスト用のパラメータCSVファイルは下記通り作成しています。

workspaceName,location,sku

test-201-20200328,eastus2,PerGB2018
test-202-20200328,eastus2,PerGB2018
test-203-20200328,japaneast,PerGB2018

3. Power ShellでARMテンプレートをデプロイする

デプロイ先のリソースグループ名、ARMテンプレートファイルのパス、CSVファイルのパスを指定してデプロイを実施します。

#Log Analyitcs ワークスペースデプロイ用Power Shell

$resourceGroupName = “デプロイ先のリソースグループ名”
$TemplateFilePath = “テンプレートファイルのパス”
$ImportCSVPath = “CSVのファイルのパス”

# Import Parameter Csv
$csv = Import-Csv -path $ImportCSVPath

# Template Deploy
foreach( $c in $csv ){

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName `
 -TemplateFile $TemplateFilePath `
 -workspaceName $c.workspaceName `
 -location $c.location `
 -sku $c.sku
}

作成が成功すると、以下の通りにLog Analyticsのワークスペースが作成されたログが表示されます。

Outputs :

DeploymentDebugLogLevel :

DeploymentName : LogAnalytics_WorkSpace
ResourceGroupName : リソースグループ名
ProvisioningState : Succeeded
Timestamp : 作成時刻
Mode : Incremental
TemplateLink :
Parameters :
Name        Type          Value
=============== ================= ==========
workspaceName    String          test-203-20200328
location       String         japaneast
sku         String                                  PerGB2018

CSVで指定した値で作成した値で作成されている事が確認できます。

Log AnalyticsでLogやリソース情報が取得出来なくなった時にやった事

 

Log Analyticsを使っていると、Azure Portal上で仮想マシンとの接続Statusは問題がなくても、実際のLog送受信やリソース情報が取得できていない事象に当たる事があります。

Log Analyitcs-仮想マシン間のLogやパフォーマンス情報転送を復活させる為に、色々やってみたことをメモとして残します。なお、下記のサイトや、マイクロソフトサポート様に色々教わりながら試行錯誤してみました。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/agent-linux-troubleshoot
https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/agent-manage
https://docs.microsoft.com/ja-jp/azure/azure-monitor/insights/solution-agenthealth

※これは1例です。残念ながらこれで治らないケースもあります。

1 .Log Analyticsのワークスペースに仮想マシンからのLog、パフォーマンス情報の取得状況確認

実際にデータ転送状況の確認は、Heartbeatの受信確認で行います。Heartbeatが受信出来てない場合はデータも受信出来ていません。

Log Analyticsのログ検索で、以下のコマンドを実行すると、5分以上HeartBeatが取得できていない仮想マシンの情報が取得できます。取得出来ていた場合には結果が表示されません。

Heartbeat
| summarize LastCall = max(TimeGenerated) by Computer
| where LastCall < ago(5m)

対象の仮想マシンがいつまで情報を取得出来ていたのかは、以下のコマンドで取得できます。

Heartbeat
| where Computer == “仮想マシン名”
| summarize LastCall = max(TimeGenerated)

※HeartBeatが取得出来ている場合でも、実際のログ採取ができてないケースもあります。


2
.Log Analyticsで情報取得出来てなかった場合のリカバリを試みる

コマンドラインでのアンインストール、インストール、Azure Portal上での再接続、サーバリブートでした。今回は/tmpで実施しています。(権限上の問題がある場合は、Sudoで実行して下さい)

まず、サービスの再起動を試みます。

[ユーザー名@ホスト名 tmp]$ systemctl restart waagent.service
[ユーザー名@ホスト名 tmp]$ /opt/microsoft/omsagent/bin/service_control restart

今回は、それで改善されなかったため、再インストールを行いました。

現在接続されている、ワークスペースを解除します。

[ユーザー名@ホスト名 tmp]$ /opt/microsoft/omsagent/bin/omsadmin.sh -X

OMSエージェントのパッケージをダウンロードします。

[ユーザー名@ホスト名 tmp]$ wget https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.12.15-0/omsagent-1.12.15-0.universal.x64.sh

#マイクロソフト様のサイトには以下の通り記載があります。こちらでも同じ事が可能です。

#wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh –purge

OMSエージェントをアンインストールします。

[ユーザー名@ホスト名 tmp]$ ./omsagent-1.12.15-0.universal.x64.sh –purge

OMSエージェントをインストールします。

[ユーザー名@ホスト名 tmp]$ sh omsagent-1.12.15-0.universal.x64.sh –install -w ”workspace id” -s “shared key” 

このコマンド実行後にCodeが0になっている場合は、インストールが終わっています。

AzurePortal上で該当のマシンに対して、切断、接続を実施する事で、正しく接続されているはずです。。。ですが、実際には3.そのほかにやった事に書いた通りうまく行きませんでした。

3.その他にLog AnalyticsへのLog転送状況改善にやった事

実際に遭遇した内容としては、以下の通りの事象にあいました。

・LAD(Linux Azure Diagnostics)がインストールされていると、アンインストール、インストールがうまく行かないケースがあるそうです。この場合は、LADのアンインストールを先に実施しました。

・installではエラーになるケースがあった。この場合は、–installの部分をーーupgradeにすることでうまく行くことがありました。

・接続は出来ているが、OMSAgent Runningにならない。この際に、OMSエージェントの再起動でもNGだったため、サーバの再起動で復旧出来ました。(理由はいまだに不明です。)

※いつもの事ですが、マイクロソフトのサポート様にかなり助けて頂いております。

 

Azure Log Analytics ワークスペースの復活から完全削除をやってみた

 

Azure Log Analytics ワークスペースの復活から完全削除を試してみました。

Log Analyticsのワークスペース削除を行った後に、同じ名前で作成しようとした所、エラーになりました。
何故?という事で色々確認させて頂いた所、Log Analyticsのワークスペースについては、論理削除されて14日間は同じワークスペース名で作成しようとしてもエラーになる事がわかりました。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/delete-workspace

ホームページを確認した所、一度復活したのちに、REST APIで削除する必要がわる事がわかったので試してみました。

1 .Log Analytics ワークスペースの復活を行う

REST APIを用いた削除は、Log Analyticsのワークスペースが存在する状態でないとできません。
そこでワークスペースの復活を行います。以下のPower Shellで実行が可能です。

Power Shell実行時は、ファイル名.ps1 -workspacename “復活するワークスペース名”で実行して下さい。(REST APIでも可能です。)

#LogAnalyticsワークスペースを復活する。
#参考URL
#https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/delete-workspace

param (
[String] [Parameter(Mandatory=$true)] $workspacename
)

$ResourceGroupName = “RG名”
$location = “ロケーション名”

New-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroupName -Name $workspacename -Location $location

2.改めてワークスペースの削除を行う。

2020年1月末時点では、ワークスペースの完全削除については、REST APIを用いた削除しか提供されていません。マイクロソフト様の以下のホームページにREST APIが提供されています。こちらを利用して完全削除します。まず、以下のホームページへ移動し、Try Itの部分をクリックします。

https://docs.microsoft.com/en-us/rest/api/loganalytics/workspaces/delete

Try Itをクリックすると、以下のページが表示されますので、サブスクリプションID、リソースグループ名、削除するワークスペース名、ロケーション名を入力します。
併せて以下のように、name部分にforceと入力し、値部分にtrueと入力します。

Runをクリックし、実行します。
成功するとステータスコードに200 OKが戻ってきます。これで完全削除完了です。

ホームページにも記載の通り、完全に削除すると復活できないので注意して下さい。

※本件、コマンド等については、マイクロソフトサポート様にご教授頂いております。有難うございました。

Azure Monitorを使ってLog Analytics(OMSエージェント)の死活監視を行う(Metricを使う)

 

前回の続きになります。

Log AnalyticsでVirtual Machineのログ取得を行う場合、OMSエージェント自体が動作していないと、ログ取得が行えません。

Azure Monitorを使ってOMSエージェントからLog Analyticsへ送信されているHeartBeatを監視することで、OMSエージェントが正常に動作しているかの監視を行えます。

Azure MonitorのCustom log searchを使う方法と、Metricを使う方法がありますが、今回はMetricを使う方法で実施します。(前回はCustom log searchで実施しました。)

1.監視設定方法

実際に関しを行うには、Azure Monitorの機能を利用して実施します。

1. 以下にアクセスし、[+ 新しいアラート ルール] をクリックします。
[Azure ポータル] – [Log Analytics ワークスペース] – [<対象のワークスペース>]
– [警告]

2. “リソース” が Log Analytics ワークスペースとなっていることを確認します。

3. “条件” にて以下を設定します。
シグナル名 : Heartbeat
シグナルの種類 : Metric
サービスの監視 : プラットフォーム

4. “シグナル ロジックの構成” にて、以下を選択します。
ディメンション名 Computer の “選択” にチェックを入れます。

*  対象のLog Analytics ワークスペースに接続されているすべての仮想マシンが対象となります。

5. “アラート ロジック” にて以下を設定します。
しきい値 : Static
演算子 : 次の値より小さい
集計の種類 : 合計
しきい値 : 1

6. “評価基準” にて以下を設定します。
集約粒度 (期間) : 15 分
評価の頻度 : 5 分

7. アクションにて電子メールの送信を行うアクションを追加します。

8. アラート ルール名を入力し、作成します。

2.実際のアラートメール

OMSエージェントを停止し、15分経過すると以下のメールが来ます。

どのVMのOMSエージェントが停止したかは、Dimensionsに記載されます。

Suject:Azure: Activated Severity: 3  ”アラート名”

 

Dimensions ResourceId = /subscriptions/XXXXXXXXXXXXX/resourceGroups/RG名/providers/Microsoft.OperationalInsights/workspaces/ワークスペース名-01Computer = ”VM名”

3.MetricとCustom log searchで設定した場合の違い

主な違いは以下のような感じになります。Log AnalyticsのHeartBeat監視の場合は、Metricを使った方が良さそうな感じです。

・メール送信タイミングが異なる

 Custom log searchを使用した場合は、回復するまでメールが送信され続けます。

 Metricを使用した場合は、発生時と回復時にのみメールが送信されます。

・コストは、Metricで設定した場合の方が安い。

・Metricで設定する場合は、仮想マシンを一括して設定可能。VM追加時も自動で監視追加できる。

 

Azure Monitorを使ってLog Analytics(OMSエージェント)の死活監視を行う(Custom log search)

 

Azure Virtual Machineのログ取得をLog Analyticsで行う場合の転送状況監視をAzure Monitorを使って実施してみました。

Virtual MachineからLog Analyticsへのログ転送は、Virtual MachineにインストールされたOMSエージェントで実施されます。その為、OMSエージェントが停止していた場合は、Virtual Machineが動作していてもログ転送が行われません。

OMSエージェントは死活監視のために、1分おきにLog AnalyticsへHeartBeatを送信します。

Log AnalyticsでHeartBeatが取得出来ているかを監視することで、Log AnalyticsとVirtual Machine間がアクセス状況の監視を行えます。

Azure MonitorのCustom log searchを使う方法と、メトリックを使う方法がありますが、今回はCustom log searchを使う方法で実施します。

1.HeartBeatの時刻取得

Log Analytics上で以下のクエリを実行すると、最後にHeartBeatアクセスがあった時刻を取得することが可能です。

Heartbeat | where Computer==“VM名” | summarize max(TimeGenerated) 

実際に取得される値

2019-08-21T11:23:06.600

2.監視設定方法

実際に関しを行うには、Azure Monitorの機能を利用して実施します。

1. 以下にアクセスし、[+ 新しいアラート ルール] をクリックします。
[Azure ポータル] – [Log Analytics ワークスペース] – [<対象のワークスペース>]
– [警告]

2. “リソース” が Log Analytics ワークスペースとなっていることを確認します。

3. “条件” にて以下を設定します。
シグナル名 : Custom log search
シグナルの種類 : Log
サービスの監視 :Log Analytics

4.”検索クエリ”に以下の内容を設定します。

Heartbeat | where Computer==“VM名” | summarize max(TimeGenerated) by Computer | where LastCall < ago(5m)

5. “アラート ロジック” にて以下を設定します。
しきい値 : Static
演算子 : 次の値より大きい
集計の種類 : 結果の数
しきい値 : 0

6. “評価基準” にて以下を設定します。
集約粒度 (期間) : 15 分
評価の頻度 : 5 分

7. アクションにて電子メールの送信を行うアクションを追加します。

8. アラート ルール名を入力し、作成します。

3.実際のアラートメール

OMSエージェントを停止し、15分経過すると以下のメールが来ます。

Suject:We are notifying you because there are 1 counts of ”アラート名”

※Custom log searchを使うと、回復するまでメールが送信され続けます。

Azure Application GatewayのAccessLogをLog Analyitcsで確認する

Application Gatewayの診断設定で、Access LogをLog Analyticsに転送することにより、Application Gatewayのアクセス内容を確認することが可能です。

1.主にAccessLogで確認できる内容

一般的なLogで取得されるような値は取得可能です。実際に以下の値を取得することができます。

項目名 実際に取得される値  
TimeGenerated 2019-07-14T10:36:57Z  
SourceSystem Azure  
clientIP_s 66.249.XX.XX  
httpMethod_s GET  
requestUri_s /  
userAgent_s Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/75.0.3770.100+Safari/537.36  
httpStatus_d 200  
host_s www.tama-negi.com  

2.設定方法

診断ログは、Application Gateway の設定画面にて有効化します。自分が使用するLog Analytics ワークスペースへの出力、出力対象ログを指定するだけです。

アクセスログの取得を行う場合は、ApplicationGatewayAccessLogにチェックを入れます。

3.アクセスログ出力方法

以下のクエリを実行すると、アクセスログの取得が可能です。デフォルトでは24時間になります。

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”

4.アクセスログをアクセス元IP単位で集計する。

以下のような感じでアクセス元のIPを集計することも可能です。

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”
| summarize total_hits = count() by clientIP_s

 

Azure Automation アカウント+LogAnalytics+SendGridを利用してログ検索結果をメールする

 

Azure上で利用できる機能のみを使用して、ログ収集、検索、結果をメール送信を検証してみました。

Log Analyticsにてログ収集、検索を行い、Automationアカウントで実際のログ分析結果をMail送信をしました。メール送信にはSendGridを使っています。

今回は事前に下記のセットアップが終わっている前提です進めています。

    • LogAnalyticsでのログ収集の設定が完了している。
    • Automationアカウントを作成済みである。
    • Azure Power Shellで自動ログインできる環境が準備できている。
    • SendGridのセットアップが完了している事

 2.Automation にモジュールを追加する。

Automationアカウントで、LogAnalyticsを使う場合、モジュールの追加が必要になります。

1. 以下の URL より LogAnalyticsQuery.psm1 のモジュールをダウンロードします。

https://blogs.technet.microsoft.com/cbernier/2018/02/15/windows-update-compliance-querying-azure-log-analytics-data-using-powershell/

2. ダウンロードしたファイルを zip ファイルとして圧縮します。
3. Automation アカウント -> <Automation アカウント名> -> モジュール の画面へと遷移します。
4. 画面上部の [モジュールの追加] をクリックし、ダウンロード後圧縮した zip ファイルを選択します。

3.AutomationアカウントでRunbookを作成する。

Automationアカウントで実行するジョブは、Runbookのへの登録が必要になります。

1. Runbook をクリックし画面上部の [Runbook の追加] をクリックします。
2. [新しい Runbook を作成します。] をクリックします。
3. [名前] には任意の名称を入力し、[Runbook の種類] は [PowerShell] を選択します。
4. [作成] をクリックします。

5. Runbook の編集画面にて以下の内容を先頭に記述します。

# Import AzureADUtils Module
Import-Module LogAnalyticsQuery

編集が終わったら、保存をクリックします。

4.Runbookサンプル

今回は、以下のクエリを実行し、メール送信を行うようにしています。

・対象ログはメールログ

・検索条件は、24時間以内に、SASL Loginを実行してきたIPの抽出を行う

# Import AzureADUtils Module
Import-Module LogAnalyticsQuery


# 認証する部分
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Connect-AzureRmAccount -ServicePrincipal -Tenant $Conn.TenantID `
-ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint


# 実行するクエリ部分

$query = “Syslog | where SyslogMessage contains ‘SASL LOGIN authentication failed’ | where TimeGenerated > now() – 24h |summarize count() by Mail_SourceIP_CF”
$LogAnaResult = Invoke-LogAnalyticsQuery `
-WorkspaceName LogAnalyticsのワークスペース名 `
-SubscriptionId サブスクリプションID `
-ResourceGroup RG名 `
-Query $query | `
ConvertTo-HTML

# SendGrid の資格情報を取得
$SmtpCredential = Get-AutomationPSCredential -Name “Sendグリッドの資格情報名

function EncodeSubject($s) {
$enc = [Text.Encoding]::GetEncoding(“csISO2022JP”)
$s64 = [Convert]::ToBase64String($enc.GetBytes($s), [Base64FormattingOptions]::None)
return [String]::Format(“=?{0}?B?{1}?=”, $enc.HeaderName, $s64)
}

$From = “Fromアドレス
$Subject = EncodeSubject(EncodeSubject(“Mail Subject名“))

Send-MailMessage `
-To “送信先アドレス” `
-Subject $Subject `
-Body “$LogAnaResult” `
-UseSsl `
-Port 587 `
-SmtpServer ‘smtp.sendgrid.net’ `
-BodyAsHtml `
-From $From `
-Encoding ([System.Text.Encoding]::UTF8) `
-Credential $SmtpCredential

5.送信テストおよび実際に送信されたサンプル

Runbookの作成が終わったら、テスト、公開(利用開始)、スケジュール登録を行います。

1. 画面上部の [テストウィンドウ] をクリックします。
2. 画面上部の [開始] をクリックします。
3. 結果にErrorが表示されないことを確認します。
4. 画面上部の [公開] をクリックし Runbook を公開します。

5.Runbookのスケジュールをクリックしスケジュールの登録を行います。

スケジュールの時間に、以下のようなメールが送られる形になります。

・メール本文例

{“tables”:[{“name”:”PrimaryResult”,”columns”:[{“name”:”Mail_SourceIP_CF”,”type”:”string”},{“name”:”count_”,”type”:”long”}],”rows”:[[“IPアドレス”,回数]

今回送られたIPをNSGに登録する事で、不正アクセスのIPをBlockすることが可能になります。