#はじめに
AzureVMのログを管理するための方法としてAzure Monitor Log(LogAnalytics)というソリューションがあります。
VMにエージェントを入れてLogAnalyticsのワークスペースにログを転送する仕組みとなっています。
今回はこのエージェントの中身を見ていくことで、セキュアな使い方やトラブルシュートの際に何を見るべきか、などを確認します。
#VMの作成
まずはVMを作ります。今回はAzure CLIで作っていきます。
自分はWindows TerminalのAzure Cloud Shellを使いました。
$rg=rg_sadakata
$location=japaneast
$vmname=sada.monitor.test
$az vm create \
--resource-group $rg \
--name $vmname \
--image RHEL \
--admin-username XXXX \
--authentication-type password \
--admin-password XXXXXXXXXXXXXX
パブリックIPアドレスに対してSSHログインしてみます。
2020/06/23 04:53:31 $ hostname
sada.monitor.test
無事ログインできホスト名も合ってます。
#LogAnalyticsワークスペースの作成
では次にLogAnalyticsのワークスペースを作ります。これもAzure CLIで。
$ lga=sadakataloganalytics
$ az monitor log-analytics workspace create \
> --resource-group $rg \
> --workspace-name $lga
Command group 'monitor log-analytics workspace' is in preview. It may be changed/removed in a future release.
{- Finished ..
・・・中略
"provisioningState": "Succeeded",
}
#エージェントのインストール
ではAzure Monitorのエージェントをインストールしましょう。
マニュアルによるとLogAnalytics WorkspaceのワークスペースIDとキーが必要となります。
https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/agent-linux
しかしよく見るとその下にそのままコピペできるコマンドが用意されてますね。
転記するのが面倒な場合はそのままコピペしてしまいましょう。
2020/06/23 05:03:19 $ wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w $wsid -s $wskey
・・・中略・・・
Shell bundle exiting with code 0
無事にインストールできました。
インストール前後で何が変わったのか、OSの世界で見てみます。
インストール前後で以下のコマンドたちをたたいてdiffしてみました。
・systemctl -l
・ps -ef
・netstat -antup
・ll /opt
・ll /var/opt
・ll /etc
2020/06/23 05:27:53 $ diff systemctl_bef systemctl_aft
> omid.service loaded active running OMI CIM Server
> omsagent-a9016fc8-37a9-4610-b7e9-272633794de5.service loaded active running Operations Management Suite agent
2つのサービスが登録されています。
次に起動しているプロセスを比較します。
2020/06/23 05:20:24 $ diff ps_bef ps_aft
> root 12257 1 0 05:04 ? 00:00:00 /opt/omi/bin/omiserver -d
> omi 12258 12257 0 05:04 ? 00:00:00 /opt/omi/bin/omiengine -d --logfilefd 3 --socketpair 9
> root 12320 12257 0 05:04 ? 00:00:02 /opt/omi/bin/omiagent 9 10 --destdir / --providerdir /opt/omi/lib -> omsagent 40681 12257 0 05:15 ? 00:00:00 /opt/omi/bin/omiagent 9 10 --destdir / --providerdir /opt/omi/lib --loglevel WARNING-loglevel WARNING
> omsagent 40638 1 0 05:15 ? 00:00:01 /opt/microsoft/omsagent/ruby/bin/ruby /opt/microsoft/omsagent/bin/omsagent -d /var/opt/microsoft/omsagent/a9016fc8-37a9-4610-b7e9-272633794de5/run/omsagent.pid -o /var/opt/microsoft/omsagent/a9016fc8-37a9-4610-b7e9-272633794de5/log/omsagent.log -c /etc/opt/microsoft/omsagent/a9016fc8-37a9-4610-b7e9-272633794de5/conf/omsagent.conf --no-supervisor
omsagentだけでなくomiserver、omiengine、omiagentというプロセスも起動していますね。
次にnetstatです。プロセスIDが出るようにpオプションを付けます。
2020/06/23 05:43:26 $ diff netstat_bef netstat_aft
> tcp 0 0 0.0.0.0:25324 0.0.0.0:* LISTEN 40638/ruby
> tcp 0 0 10.0.0.4:44090 40.79.194.105:443 TIME_WAIT -
> tcp 0 0 10.0.0.4:37460 169.254.169.254:80 TIME_WAIT -
> udp 0 0 127.0.0.1:25224 0.0.0.0:* 40638/ruby
同じプロセス(40638/ruby)が2ポートでリッスンしています。これはpsの結果からomsagentとわかります。
さらに2プロセスが外部にHTTP(S)で通信しています。
> tcp 0 0 10.0.0.4:37460 169.254.169.254:80 TIME_WAIT -
こちらはAzureVMがホストと内部通信するためのものなので割愛します。詳細は以下。
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/instance-metadata-service
> tcp 0 0 10.0.0.4:44090 40.79.194.105:443 TIME_WAIT -
これがおそらくLogAnalyticsのワークスペースへのはずです。
これを調べるために有用なのがAzureのデータセンタIPアドレスです。
https://www.microsoft.com/en-us/download/details.aspx?id=56519
ここからjsonファイルをダウンロードしてIPアドレスを検索してみましょう。
レンジで記載されているので、検索はちょっと面倒です。
{
"name": "AzureMonitor.JapanEast",
"id": "AzureMonitor.JapanEast",
"properties": {
"changeNumber": 3,
"region": "japaneast",
"platform": "Azure",
"systemService": "AzureMonitor",
"addressPrefixes": [
・・・中略・・・
"40.79.194.104/29",
・・・中略・・・
]
}
},
東日本リージョンのAzure Monitorであることがわかります。
最後にパッケージをインストールしたときによくディレクトリが作成される/optや/var/optを比較します。
2020/06/23 05:28:52 $ diff opt_bef opt_aft
> drwxr-xr-x. 5 omsagent root 85 Jun 23 05:04 dsc
> drwxr-xr-x. 6 root root 63 Jun 23 05:04 microsoft
> drwxr-xr-x. 5 root root 56 Jun 23 05:04 omi
2020/06/23 05:29:27 $ diff varopt_bef varopt_aft
1a2,3
> drwxr-xr-x. 6 root root 63 Jun 23 05:04 microsoft
> drwxr-xr-x. 8 root root 81 Jun 23 05:03 omi
このあたりにomsagent関連のファイルが入っていることがわかります。
トラブルシュートの際にはこの中を見ていくことになります。
#さいごに
今回はここまで。
次回は外部への通信をより詳細に把握するためにHTTPプロキシを立てて通信を見ていきます。
お楽しみに。