Linux用AzureMonitorエージェントをインストールすることによるOS上の変化

#はじめに
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

```

Azureポータルで見るとこんな感じで作られてます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24194/ece0d16c-2678-0431-7aec-d69eb4d3cfa1.png)

パブリック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",
}
```
無事作成されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24194/48c0a00c-4874-cab0-4895-868edbb8403b.png)

#エージェントのインストール
ではAzure Monitorのエージェントをインストールしましょう。
マニュアルによるとLogAnalytics WorkspaceのワークスペースIDとキーが必要となります。
https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/agent-linux

以下の赤枠にその情報があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24194/10eb2ec5-fd87-e963-a50d-43d9f9168617.png)

しかしよく見るとその下にそのままコピペできるコマンドが用意されてますね。
転記するのが面倒な場合はそのままコピペしてしまいましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24194/7d608a35-bfec-9f16-2a7b-6799511f4515.png)

```
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プロキシを立てて通信を見ていきます。
お楽しみに。