New Relic InfrastructureでOpenStackのインフラを監視する（その１）

# 動機
OpenStackの監視は複雑です。

サービス監視、リソース監視などのインフラ監視ではZabbixやNagiosが使われることが多いようです。しかしそもそもキャパシティプランニングの段階で監視項目をリストアップしたり閾値を定義することは容易ではありません。監視対象になっていない項目は何か起こっても検知できないおそれがあります。コンポーネントの増減のたびに設定を変更するのは大変煩雑です。

一方でNew Relicはひととおり情報を拾ってきて後から必要な項目を絞り込むというSaaSサービスです。最近サーバ監視に特化したInfrastructureが登場しました。Infrastructureを使ってOpenStackのインフラ監視をどこまでシンプルにできるか・・・を模索するのが今回のテーマです。

# New Relic Infrastructureとは
サーバ監視に特化したサービスです。おそらくMackerelに近しいことができるのでは？と思います。基本的にはパブリッククラウド（AWS等）のインフラ監視で効果を発揮するサービスですが、オンプレ監視ができないわけではありません。New Relicといえばこれまでアプリケーションパフォーマンス監視が謳われてきましたが、インフラ監視にも結構力を入れているようです。

# 今回のゴール
まずCentOSを入れたばかりの何もないサーバにNew Relic InfrastructureのAgentを仕込んで初期状態を確認します。そのあとRDOでOpenStackをデプロイします。最後に前後の差分を確認します。

# PoCの準備
## 物理サーバの用意
ESXi上に物理サーバを用意（妙な言い回しですが・・・ちなみにESXiで仮想マシンを作ってその環境でOpenStackを動かす為、Nestedハイパーバイザを有効化とESXi仮想マシンが接続しているネットワークのポートグループで「無差別モード(Promiscuous Mode)」を「承諾(Accept)」にしています）。

| 項目 | 値 |
|:-----------|:------------|
| OS       | CentOS 7 |
| Mem       | 64GB |
| Disk       | 100GB |

## 前作業
あらかじめNetworkManagerの停止やSElinuxの無効化、ネットワークインターフェースのIPv6無効化、firewallの無効化などをしておきます。NTPはRDO実行時に入ります。

# New Relic Infrastructre Agentのインストール
New Relicの登録は済んでいるものとします。License Keyが要求されますのでNew Relicのアカウントが必要です。インストール手順はこちら。
[Install Infrastructure for Linux](https://docs.newrelic.com/docs/infrastructure/new-relic-infrastructure/installation/install-infrastructure-linux)

インストール時に自動起動の設定もされます。Agentのプロセスは以下のコマンドで確認できます。stop,startで再起動。

```
systemctl status newrelic-infra
```

# OSインストール後のInfrastructure画面
## Compute
Infrastructure画面にアクセスするとAgentを仕込んだすべてのサーバが表示されます。
![01.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/299a9088-5bf7-27d0-8c5a-dcfd28761619.jpeg)

## フィルタ機能
ホストが増えてきたときはフィルタ機能で絞り込みをするのが便利です。
![02.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/98d3bf8a-e2ac-9657-a528-3ca20c8c1a08.jpeg)

## Network
ネットワーク監視。CentOSのインターフェース（ens160）の情報が見えます。
![03.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/8d4d3bed-1e60-66b8-68fa-00cfece8f34a.jpeg)

## Processes
プロセス監視。一番上のnewrelic-infraはNew RelicのAgentのプロセスです。
![04.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/5f0e3c62-24ac-f1f8-bddf-5048c4c3f001.jpeg)

## Inventry
インベントリ情報。アーッ！さっきSELinuxを停止するとか書いていたのに忘れていたことに気づきました。現状はホスト1台ですが冗長化やすケースアウトでマシンが増えた際にまとめて設定を確認するのに便利です。OpenSSLの脆弱性対策をしている時などにマシンに入らずとも不揃いを見つけることができます。
![05.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/c4bb16ca-fbe5-7b3f-e3d7-1c55322f0d65.jpeg)

# RDOの実行
## 実行
RDOでOpen Stackをデプロイしました。今回はNewtonが入りました。
[RDOの実行手順](https://www.rdoproject.org/install/quickstart/)

こちらも参考にさせて頂きました。
[RDOを試してみる](http://qiita.com/teratsyk/items/554044ae417d8c43084a)

## ネットワークインターフェースの修正
デプロイ完了後、ネットワークインターフェースの設定を変更をします。br-exにens160を割り当てることで仮想マシンがハイパーバイザー外部と通信できる設定を行います。

### Before

```
# cat /etc/sysconfig/network-scripts/ifcfg-ens160
TYPE="Ethernet"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
#IPV6_AUTOCONF="yes"
#IPV6_DEFROUTE="yes"
#IPV6_FAILURE_FATAL="no"
NAME="ens160"
UUID="{UUID}"
DEVICE="ens160"
ONBOOT="yes"
IPADDR="{サーバのIP}"
PREFIX="24"
GATEWAY="{GWのIP}"
DNS1="8.8.8.8"
#IPV6_PEERDNS="yes"
#IPV6_PEERROUTES="yes"
#IPV6_PRIVACY="no"
#
```

### After

```
# cat /etc/sysconfig/network-scripts/ifcfg-ens160
DEVICE="ens160"
ONBOOT=yes
TYPE=OVSPort
OVS_BRIDGE="br-ex"
DEVICETYPE="ovs"
#
```

```

# cat /etc/sysconfig/network-scripts/ifcfg-br-ex
DEVICE="br-ex"
DEVICETYPE=ovs
ONBOOT=yes
NETBOOT=yes
IPV6INIT=no
BOOTPROTO=static
TYPE=OVSBridge
NAME="br-ex"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPADDR="{サーバのIP}"
NETMASK="255.255.255.0"
GATEWAY="{GWのIP}"
DNS1="8.8.8.8"
#
```

変更したらネットワーク、OVS、neutron-serverのプロセスを再起動しておきます。ネットワークインターフェース情報がこんな感じで表示されます。

```
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000
    link/ether 00:0c:29:3c:92:39 brd ff:ff:ff:ff:ff:ff
    inet {サーバのIP} brd {ブロードキャストアドレス} scope global ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe3c:9239/64 scope link
       valid_lft forever preferred_lft forever
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 92:c4:e8:c3:05:97 brd ff:ff:ff:ff:ff:ff
4: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 12:0c:03:90:fb:43 brd ff:ff:ff:ff:ff:ff
5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:0c:29:3c:92:39 brd ff:ff:ff:ff:ff:ff
    inet {サーバのIP} brd {ブロードキャストアドレス} scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe3c:9239/64 scope link
       valid_lft forever preferred_lft forever
6: br-int: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN
    link/ether ca:9b:55:3f:de:4e brd ff:ff:ff:ff:ff:ff
#
```

# OpenStackデプロイ後のInfrastrucureの画面
## Network
ovs-system、br-ex、ens160、br-int、br-tunとネットワークインターフェースが見えています。順番は負荷の上位順です。さっきのip aの表示どおりであることがわかります。
![06.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/6cf0d7ec-8de7-79ac-de3e-155aa667dd99.jpeg)

## Processes
抜粋になりますがopenstackのプロセスが負荷の上位順に見えています。
![07.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/78c58706-7c8b-536b-5ff1-e0071bdcb70b.jpeg)

## Inventry
試しにneutronで検索してみるとneutronと名のつくインベントリ情報がリストアップされました。
![08.jpg](https://qiita-image-store.s3.amazonaws.com/0/150932/fbb82ed3-a945-dcbe-7874-d1c99fea327b.jpeg)

OpenStackのインフラに関してはこのような情報を自動的に拾ってきてくれることが確認できました。

[次回](http://qiita.com/dxtomochika/items/b68d8564e6400f6d7208)は仮想側のインフラ監視をしてみたいと思います。