New Relic InfrastructureでOpenStackのインフラを監視する(その1)
動機
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
インストール時に自動起動の設定もされます。Agentのプロセスは以下のコマンドで確認できます。stop,startで再起動。
systemctl status newrelic-infra
OSインストール後のInfrastructure画面
Compute
Infrastructure画面にアクセスするとAgentを仕込んだすべてのサーバが表示されます。
フィルタ機能
ホストが増えてきたときはフィルタ機能で絞り込みをするのが便利です。
Network
ネットワーク監視。CentOSのインターフェース(ens160)の情報が見えます。
Processes
プロセス監視。一番上のnewrelic-infraはNew RelicのAgentのプロセスです。
Inventry
インベントリ情報。アーッ!さっきSELinuxを停止するとか書いていたのに忘れていたことに気づきました。現状はホスト1台ですが冗長化やすケースアウトでマシンが増えた際にまとめて設定を確認するのに便利です。OpenSSLの脆弱性対策をしている時などにマシンに入らずとも不揃いを見つけることができます。
RDOの実行
実行
RDOでOpen Stackをデプロイしました。今回はNewtonが入りました。
RDOの実行手順
こちらも参考にさせて頂きました。
RDOを試してみる
ネットワークインターフェースの修正
デプロイ完了後、ネットワークインターフェースの設定を変更をします。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の表示どおりであることがわかります。
Processes
抜粋になりますがopenstackのプロセスが負荷の上位順に見えています。
Inventry
試しにneutronで検索してみるとneutronと名のつくインベントリ情報がリストアップされました。
OpenStackのインフラに関してはこのような情報を自動的に拾ってきてくれることが確認できました。
次回は仮想側のインフラ監視をしてみたいと思います。
Author And Source
この問題について(New Relic InfrastructureでOpenStackのインフラを監視する(その1)), 我々は、より多くの情報をここで見つけました https://qiita.com/dxtomochika/items/d535618ba1397c67884d著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .