フロントドアとWAFのログをLog Analyticsで確認

 

Azure Froot Door のアクセスログやWAFログを診断設定でLog Analyticsへ転送しクエリで確認してみました。

Azure Front Doorのログではアクセス先のURL等の情報だけではなくキャッシュのヒットなどの情報も分かります。

WAFのログではどのルールでブロックされたのか?なども分かります。例えばレート制限時にはアクセス制限状況も分かります。

その為、Azure Front Doorの使用状況を把握するのには、診断設定で取得出来るログは非常に重要なログになります。

今回実際に実施した作業内容は下記の通りになります。

      • Azure Front Dorrの診断設定
      • Log Analyticsでのログ検索

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

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

WAFの作成についてはこちらを参考にして頂ければと。

Azure Web アプリケーションファイアウォールを作ってみた

Application Gatewayのログについてはこちらを参考にして頂ければと。

Azure Application GatewayのアクセスログをLog Analyticsで確認する

1.Azure Froot DoorやWAFのログ取得設定は診断設定で行います

Azure Froot DoorのアクセスログはApplication Gatewayと同様に診断設定を利用します。

Azure Front Doorのメニューで診断設定を選択します。

下記画面が表示されますので診断設定を追加するを選択します。

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

logに表示されている2項目にチェックを入れます。(必要に応じてMetricにもチェックを入れます。)

今回はLog Analyticsで確認するのでLog Analytics への送信にチェックを入れて、送信先のワークスペース名を選択します。

診断設定の名前を付けて保存します。

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

2.Log AnalyticsでAzure Front DoorやWAFログの検索を行う。

診断設定で選択したLog Analyticsのワークスペースでログを開きます。(Azure Front Doorのメニューでログを選択しても同じ動作になります。)

今回取得設定したのは以下の2つのログになります。

      • FrontdoorAccessLog:Azure Front Doorのアクセスログ
      • FrontdoorWebApplicationFirewallLog:WAFのログ

アクセスログを表示する為のサンプルは下記の通りになります。

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

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

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

FrontdoorAccessLogの主な出力項目としてはこんな内容が表示されます。

      • 時刻
      • リクエストURL
      • User-Agent
      • アクセス元のIP
      • キャッシュヒット
      • ルールエンジン(利用時)

Web Application Firewallのログは下記のクエリで確認可能です。

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

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
 

アクセスログに表示される項目以外に、どのルールにマッチしたのか、ブロックされたのか等の情報が併せて表示されます。

なお許可された通信も表示されます。許可された通信以外(LogやBlock)を表示するには下記のようにします。

#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.Azure Froot Doorのバックエンドプール側のクライアントIPはFront DoorのIPになります。

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 エージェントが原因でCent OSのyum updateが失敗する

 

ある日からCent OS 7のAzure VMのyum updateがエラーになるようになってしまいました。

原因を調べてみると、OMSエージェント関連のパッケージの影響でエラーになっていたようです。
実際に発生した事象と対応した内容を残しておきます。

1.ある日突然Azure VMで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.Azure VM(Cent OS)で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の影響でAzure VMがハングアップした

 

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

調査した結果、Disk領域の使用率が100%になっている事が分かりました。

なぜ100%になってたかですが、OMIエージェントが連続して失敗し続け、30分置きに30MB~40MBのCoreファイルが大量に出力されてました。Coreファイルが溜まる事により最終的にディスク使用率が100%になりAzure VMが落ちるという事象でした。

Coreファイルが出力されているのですがLog AnalyticsのHeartbeatは取得し続けており監視のエラーも出てませんでした。

今回は事象調査から解消するまでの対応内容をメモとして残します。

Log AnalyticsのHeartBeat監視については下記記事に記載しております。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Metric)

1 .Azure VMがOMIエージェントのCoreファイル出力による影響を受けた事を確認する

調べた結果以下の事以下のように、”/”配下が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

どのディレクトリで容量を消費しているのか?をduコマンドで確認しました。

結果、/var/opt/omi/runで24GB以上の容量を使用している事が分かりました。

[ユーザー名@ホスト名 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

.OMIエージェントのログ採取を行う

ログを見てみたのですが調べても原因が分かりませんでした。マイクロソフトサポート様にログ採取をし調査依頼しました。(ユーザー権限でNGの場合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モジュールのアップデートを行った

調査の事象の結果は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のワークスペースのデプロイを以下の2パターンでデプロイしてみました。

      • Azure Portalを使ってデプロイ
      • ARMテンプレート+CSVファイルで複数纏めてデプロイ

まず最初に、Azure Portalを使ってデプロイしてみました。

その次に、ARMテンプレートを利用して実施してみました。パラメータをCSVファイルから読み込み、複数のLog Analyticsワークスペースを一括してデプロイ出来るようしてみました。

テンプレートを使ったデプロイは、下記条件で実施しています。

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

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

1 .Azure Portalを使ってLog Analytics ワークスペースを作る

まず、Azure Portalを使ってLog Analyticsワークスペースをデプロイしてみます。

1)Log Analyticsワークスペースのメニュー画面で追加をクリックします。

2)作成画面になりますので、リソースグループ、名前、地域(Location)を設定します。地域はLog Analyticsの転送元のリソースがある地域(Location)と同じ場所を選択します。

3)価格レベルを設定します。価格レベルは従量課金制を選択します。

4)タグを設定する場合はタグの設定を行います。設定しない場合は確認および作成を選択し作成します。

これでLog Analyticsワークスペースの作成は完了です。

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

Log AnalyticsワークスペースのARMテンプレートを作成します。

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

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

defaultValue値は環境に合わせて変更してください。

{

“$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
}}}]}

3.Log Analyticsのパラメータを指定するCSVファイルを作成する

Azure Portalを使って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

4. Power ShellでLog AnalyticsワークスペースのARMテンプレートをデプロイする

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

#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上でAzure VMとの接続ステータスは問題がなくても、実際にはログやリソース情報が取得できていない事象に当たる事があります。

Azure VM側のエージェントに問題があったりするケースが多いように見受けられます。

Log Analyitcs-Azure VM間の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 .Azure VMからLog Analyticsワークスペースへのログ/パフォーマンス情報転送状況を確認する

Log Analytics側でのデータ受信状況の確認は、各Azure VMから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が取得出来ている場合でも、実際のログ採取ができてないケースもあります。

メトリックを用いた監視も試しています。こちらについては下記に記載しております。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Metric)

2.Log AnalyticsでAuzre VMからログが取得出来てなかった場合のリカバリを試みる

今回、実施した内容は下記の通りになります。

      • サービスの再起動
      • コマンドラインでのエージェントのアンインストール
      • コマンドラインでのエージェントの際インストール
      • 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とAzure VM接続状況回復の為にやった事

その他にこちらの内容も試しました。

      • LADのアンインストールを先に実施する。LAD(Linux Azure Diagnostics)がインストールされていると、アンインストール、インストールがうまく行かないケースがあるそうです。
      • –installの部分をーーupgradeにしてみました。(installではエラーになるケースがあった為)
      • サーバの再起動。接続は出来ているが、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で削除する必要がわる事がわかったので試してみました。

Log Analyticsワークスペース作成はこちらに記載しております。

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

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 VMからLog Analyticsへのログ転送状況監視をしてみた(Metric)

 

前回に引き続き、Azure Virtual MachineからLog Analyticsへのログ転送状況監視をAzure Monitorを使って実施してみました。

Azure MonitorでLog AnalyticsのメトリックHeartBeatという項目があります。これを利用して監視することで、Azure VMからLog Analyticsへ正常にログ転送が行えているか監視出来ます。

なお、Azure VMからLog Analyticsへの転送はAzure VMにインストールされたOMSエージェントで実施されます。この監視でエラーが発生した場合はOMSエージェントの再起動等が必要になります。

また、メトリック(Metric)を利用した方式だけではなく、Custom log searchで実施する方法もあります。下記記事も併せて参照頂ければと。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Custom log search)

1.Azure Monitorを利用したOMSエージェントHeartBeat監視

Azure Monitorの機能を利用して実施します。

1) Azure Portal上でモニターのメニューにアクセスします。アラートで[+ 新しいアラート ルール] をクリックします。

2)アラートルールの作成でリソースの選択をクリックします。

3)リソースの選択で VMが接続されているLog Analyticsのワークスペースを選択します。選択したら完了をクリックします。

4)次に監視条件の設定を行います。条件の選択をクリックします。

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

6)シグナルロジックの構成画面が表示されます。下記画面の通り選択します。

    • ディメンション名:Computer
    • 演算子:= 
    • ディメンション値:現在および将来のすべての値。

*現在および将来のすべての値を選択する事で、ワークスペースに新規VMが接続された場合も監視が自動的に有効になります。

 “アラート ロジック” にて以下を設定します。

    • しきい値 : Static
    • 演算子 : 次の値より小さい
    • 集計の種類 : 合計
    • しきい値 : 1

これで、過去5分間に1度もHeartBeatが来てない場合にエラーとして検知が可能になります。

“評価基準” にて以下を設定します。

    • 集約粒度 (期間) : 5 分
    • 評価の頻度 : 5 分

7)アクショングループにて電子メールの送信を行うアクションを設定します。

なお、アクショングループの作成についていは、こちらの記事を参照頂ければと。

ARMテンプレートを使ってAzure Monitorのアクショングループをデプロイしてみた

8)アラート ルール名や重要度をを入力します。入力が終わったら作成をクリックします。

これでアラートルールの作成は完了です。

2.OMSエージェントHeartBeatエラー時のアラートメール

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

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

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

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

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

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

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

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

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

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

※実際の環境に合わせて、設定はチューニングするようにして下さい。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Custom log search)

 

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

今回は、Azure Virtual MachineからLog Analyticsへのログ転送状況監視をAzure Monitorを使って実施してみました。

OMSエージェントは死活監視のために、1分おきにLog AnalyticsへHeartBeatを送信します。このHeartBeatが取得出来ているかを監視することで、Virtual MachineからLog Analyticsへログ転送が行われているのか監視出来ます。

最終のHeartBeat取得時間が一定時間以上前の場合にアラートを上げる確認する事で監視を行います。

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

メトリックを利用する方法も併せて参照頂ければ幸いです。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Metric)

1.OMSエージェントのHeartBeat時刻取得

最後にOMSエージェントからHeartBeatアクセスがあった時刻は、Log Analytics上で以下のクエリを実行すると確認できます。(下記サンプルはAzure VM指定での出力になります。)

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

実際に取得される値

2019-08-21T11:23:06.600

この取得時刻を利用して、Azure Monitorの設定を行います。

2.Azure MonitorでのOMSエージェントHeartBeat最終取得時刻で監視を設定する

今回は、HeartBeatの最終取得時刻が5分以上前にAzure Monitorからアラート発出するように設定します。

1) Azure Portal上でモニターのメニューにアクセスします。アラートで[+ 新しいアラート ルール] をクリックします。

2)アラートルールの作成でリソースの選択をクリックします。

3)リソースの選択で VMが接続されているLog Analyticsのワークスペースを選択します。選択したら完了をクリックします。

4)次に監視条件の設定を行います。条件の選択をクリックします。

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

6)シグナルロジックの構成の画面で以下の通り設定ます。”検索クエリ”に以下の内容を設定します。

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

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

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

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

7)アクショングループにて電子メールの送信を行うアクションを設定します。

なお、アクショングループの作成についていは、こちらの記事を参照頂ければと。

ARMテンプレートを使ってAzure Monitorのアクショングループをデプロイしてみた

8)アラート ルール名や重要度をを入力します。入力が終わったら作成をクリックします。

これでアラートルールの作成は完了です。

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

実際のアラートメールを確認する為にはAzure VM側でOMSエージェントを停止すると確認ができます。OMSエージェント停止後5分経過すると以下のメールが来ます。

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

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

Azure Application GatewayのアクセスログをLog Analyticsで確認する

 

今回はApplication GatewayのAccess LogをLog Analyticsで確認してみました。

Application GatewayのログをLog Analyticsに転送することにより、Log AnalyticsでAccess Logの内容を確認することが出来ました。

Log Analyticsへの転送設定はApplication Gatewayの診断設定で実施します。

今回は診断設定からLog Analyticsでのログ検索まで一連の流れを試してみました。

Application Gateway自体の作成はこちらに記載しております。

Azure Application Gatewayを構築してみた

Azure Front Doorでのログ確認も試してみました。併せて見て頂ければと。

フロントドアとWAFのログをLog Analyticsで確認

1.Application GatewayのAccess Logで確認できる内容

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

項目名実際に取得される値 
TimeGenerated2019-07-14T10:36:57Z 
SourceSystemAzure 
clientIP_s66.XX.XX.XX 
httpMethod_sGET 
requestUri_s/ 
userAgent_sMozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/75.0.3770.100+Safari/537.36 
httpStatus_d200 
host_swww.xxxx-xxxx.com 

2.Application Gateway からLog AnalyticsへのLog転送設定方法

Application Gateway のAccess Log取得設定は診断設定にて実施します。

アプリケーションゲートウェイのメニューで診断設定を選択します。そうすると下記画面が表示されますので、診断設定を追加する選択します。

診断設定の画面が表示されますので診断設定の名前を入力します。

次に転送するログを選択します。ApplicationGatewayAccessLogがアクセスログに該当します。なお、ApplicationGatewayFirewallLogはWAF利用時のログになります。

転送先のLogAnalyticsワークスペースを選択します。

保存すれば設定は完了です。

3.Application GatewayのAccess LogをLog Analyticsで確認してみた

では実際のアクセスログを確認してみましょう。アプリケーションゲートウェイのメニューでログという項目をクリックします。そうしますと、診断設定で指定したLog Analyticsワークスペースが表示されます。クエリ入力欄に入力する事でログ検索ができます。

※なお、診断設定から実際のログ収集開始までは5分~10分程度かかります。上記画面は設定直後の為、ログが見つかりませんという表記になっております。

実際にAccess Logを検索するには、下記クエリで実施します。(検索時間はデフォルトでは24時間になります。)

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”

4.Application GatewayのAccess Logをアクセス元IP単位で集計する。

Log Analyticsを利用していますので、色々な集計が可能です。例えば下記のようにする事でアクセス元IPで集計することが可能です。

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

今回は基本的な設定のみですが、色々加工ができそうです。今後色々試してみたい所です。