GMOインターネットのOpenStack public cloud“ConoHa”におけるオープンソース監視ツール“Hatohol” と”zabbix”の適⽤について
How to use opensource monitoring tools Hatohol and zabbix
on GMO Ineternet using OpenStackfor Public Cloud

Slide URL
http://www.slideshare.net/chroum/miracle-linux-seminer-hatohol-and-conoha

ConoHa public cloudhttps://www.conoha.jp/

Miracle Linux ZBX/Hatohol セミナー
Feb 17, 2017
Naoto Gohko (@naoto_gohko)
GMO Internet, Inc.

1

内容(アジェンダ) 0) GMOインターネットのOpenStack public Cloudサービスについて 1) 運⽤管理とはなんぞや 2) これまで運⽤管理に使っていたツールについて 3) ConoHaをマルチロケーションで運⽤するにあたって再検討した最近の運⽤監視ツールについて 4) Hatohol + zabbixを選択した理由について 5) Hatohol + zabbix構成について 6) (参考資料) OpenStack Japan Ops Workshop 2015/12 でのOpenStack
を運⽤している各社の運⽤管理について
20) GMOインターネットのOpenStack public cloudサービス
について

3

We are offering multiple public cloud services.

Public Clouds

4PhysicalServers
Running Infrastructure(2015/10)

25294

1372231508

Physical Server
5

Running VM

Created VM

OpenStack service development team6

Cloud service development team: Now(2016)
Cloud service development team: (abount 30 people)– OpenStack Neutron team:4 people• Neutron driver / modification / engineering– Cloud API development team:
5 people• Public API validation program• OpenStack modification / scaduler programing / keystone– Cloud Infra. development team:11 people• Security engineering / glance driver / cinder driver / nova additional
extensions / construction of OpenStack infra.
– Applicatoin cloud service development team:
5 people• Billing engineering / staff tools / GMO AppsCloud web GUI
Additional engineering team: many people (30 ~)– QA Team / Server Engineering Team / GUI development Team– Network Engineering Team / SaaS development Team
– CRM backend and billing Team7

Cloud service development team: Office(2016) #1

Neutron TeamAnd
Cloud API Team

8Cloud Infra. TeamAnd
AppsCloud TeamCloud service development team: Office(2016) #2

Neutron TeamAnd
Cloud API Team

Cloud Infra. TeamAnd
AppsCloud Team9

Limied number of people.
But, we have to run a lot of OpenStack
service clusters.

10Service developmemt history
by OpenStack

11

GMO Internet, Inc.: VPS and Cloud services
Nova
Keystone

Onamae.com VPS (2012/03) :http://www.onamae-server.com/

Forcus: global IPs; provided by simple "nova-network"tenten VPS (2012/12)

OpenStack Diablo
on CentOS 6.x

Nova network

GlanceShared codes

http://www.tenten.vn/

Shared cluster

Share of OSS by Group companies in Vietnam

ConoHa VPS (2013/07) :http://www.conoha.jp/

Forcus: Quantam(Neutron) overlay tenant network

OpenStack Glizzly
on Ubuntu 12.04

Quantam ovs + gre tunnel overlay
Nova
Keystone
GlanceKeystone
GlanceCinder

GMO AppsCloud (2014/04) : http://cloud.gmo.jp/
OpenStack Havana based 1st region
Enterprise grade IaaS with block storage, object storage,
LBaaS and baremetal compute was provided

OpenStack Havana
on CentOS 6.x

Onamae.com Cloud (2014/11)
http://www.onamae-cloud.com/

Baremetal computeCeilometer
NeutronForcus: Low price VM instances, baremetal compute and object storage
ConoHa Cloud (2015/05/18) http://www.conoha.jp/

OpenStack Juno
on CentOS 7.x

Designate
Keystone
GlanceCinder

LBaaS
Keystone
Ceilometer

Baremetal computeEnterprise grade IaaS with High IOPS Ironic Compute and Neutron LBaaS

12Keystone
Ceilometer

GlanceCinderSwift
Upgrade
Juno
Swift

GSLB
Nova
Ceilometer
NeutronGMO AppsCloud (2015/09/27) : http://cloud.gmo.jp/
2nd region by OpenStack Juno based

Swift

Nova

GlanceNeutronNova

Shared codes

Forcus: ML2 vxlan overlay, LBaaS, block storage, DNSaaS(Designate)
and original services by keystone auth

Swift cluster

Nova

IronicNeutron

Swift
LBaaS
Swift

LBaaS

OpenStack Juno cluster:• ConoHa (Juno) and Z.com cloud• AppsCloud (Juno)

13

# ConoHa has data centers in 3 Locations

TokyoSanjose

Singapore14

# User-registration is possible in Japan only
SingaporeTokyo

SanJoseDo notcreate/delete
users
Tokyo

Our Customer base

Do notcreate/delete
users

Keystone API

Keystone API

User administration

Singapole

API Manag ement

Keystone API
API Manag ement

R/W

Token
Token

READ/WRITE
DB ReplicationUser/tenant
Token15

Keystone API
API Manag ement

READUser/tenant

Keystone API
API Manag ement

API Manag ement

DB Replication

READUser/tenant
User/tenant
Token
TokenR/W

# Now(2017); data centers in 5 Locations

TokyoVN
ThaiSanjose

Singapore16

OpenStack: we have many cluster

Mikumo = 美雲 =Beautiful cloud

Mikumo ConoHa
17

Mikumo Anzu

OpenStack Juno: 2 service cluster, released•
•
•

•
•••
•••
•

Service model: Public cloud by KVM
Network: 10Gbps wired(10GBase SFP+)
Network model:– Flat-VLAN + Neutron ML2 ovs-VXLAN
overlay + ML2 LinuxBridge(SaaS only)– IPv6/IPv4 dualstack
LBaaS: LVS-DSR(original)
Public API– Provided the public API (v2 Domain)
Compute node: ALL SSD for booting OS– Without Cinder bootGlance: provided
Cinder: SSD NexentaStore zfs (SDS)
Swift (shared Juno cluster)
Cobbler deply on under-cloud– Ansible configuration
SaaS original service with keystone auth
– Email, web, CPanel and WordPress18•
••

•
•
•
•
•
•
•
•

Service model: Public cloud by KVM
Network: 10Gbps wired(10GBase SFP+)
Network model:– L4-LB-Nat + Neutron ML2 LinuxBridge VLAN
– IPv4 only
LBaaS: Brocade ADX L4-NAT-LB(original)
Public API– Provided the public API
Compute node: Flash cached or SSD
Glance: provided (NetApp offload)
Cinder: NetApp storage
Swift (shared Juno cluster)Ironic on under-cloud– Compute server deploy with Ansible config
Ironic baremetal compute– Nexsus Cisco for Tagged VLAN module– ioMemory configuration

191) 運⽤管理とはなんぞや

20

1) (システム)運⽤管理 とは?
 システム運⽤に関する管理 è ITIL (Information Technology Infrastructure Library) などの例
ほぼデファクトのツール
ITサービスを管理するために、ITサービスの品質向上を⽬指す、中⻑期的なコスト削減を⽬指す(⼈的、⾦銭的) いわゆる “PDCA” サイクル的なものを、回していく必要がある

21

システム運⽤管理 と カイゼン

22

システム運⽤管理 と PDCA
「えっ、なんで?」23Ex) とある障害発⽣
お客のVPSのwebサーバのコンテンツが⾒えないと連絡
On call … …
お客のVPSのネットワークにDDoS攻撃来ていた!!
IPを上位ネットワークで⽌めてもらう
On call終了
ふぅっ24Ex) とある障害発⽣
お客のVPSのwebサーバのコンテンツが⾒えないと連絡
On call … …
お客のVPSのネットワークにDDoS攻撃来ていた!!
IPを上位ネットワークで⽌めてもらう
On call終了
ふぅっ25

ちょっ、まぁっ、ここで終わったら、次にDDoS来た時にどうするんだ!!

Ex) とある障害発⽣ + 記録 + 改善策 + 記録
お客のVPSのwebサーバのコンテンツが⾒えないと連絡
On call … …
お客のVPSのネットワークにDDoS攻撃来ていた!!
IPを上位ネットワークで⽌めてもらうè対応内容を記載
On call終了
è対策を調査 è http://blog.sflow.com/2013/03/ddos.html
VPSのovs sflow をElasticSearchに⼊れて、AlertAction設定
AlertActionで上位ルータにdev nullに3分間落とす
対策内容を共有、類似のトラブルですぐに確認できるように

26

PDCA: (Plan, Do, Check, Action(Adjust))
 継続的改善

DevOpsへの道

27

システム運⽤管理ソフトウェア とは?
 システム運⽤に関する管理 è カイゼンを回して効率化などを得る
この場では、事例、⽅法論などの知⾒を得ることで、何らかの改善ができればよいと思います
以下の内容(要素)を含みます è ネタはたくさんあります Monitoring System, Security System Notification(ChatOps, PushNotify), redmine(Tiket), RTFM
 CMDB, IPAM, SDN, OpenStack, CloudStack Automation Tools, Infra-spec Tools, Jenkins(Job) Documentation Tools (Wiki, RTFM, Jupyter) ……
282) これまで運⽤管理に使っていたツールについて292) これまでの運⽤管理に使っていたツール 1) 監視ツール: Nagios
 Version: 2.0b6(Solaris), 3.0(Solaris), 3.5.1(Nagios Core) OS環境が様々 Solaris 9, 10, OpenSolaris Linux: CentOS 5.x, CentOS 6.x, CentOS 7.x, Ubuntu 14.04
 Notification:
Mail:
IRC: #nagios channel へのircbot (Nagstamon: (Windows): https://nagstamon.ifw-dresden.de)https://github.com/HenriWahl/Nagstamon
 Graph: nagiosgraph (rrd files)
⼊社したときに初めてさわったNagios(ver. 2.0b6)が現役監視
30

è Solarisのシステム

2) なぜNagios 2.0b6とか残っているの?
なぜ?
 Nagios⾃体がほとんど進化していない?
 Nagiosの残念な開発体制と、たくさんのForkの発⽣ Nagios⾃体、仕様がほとんど変わらないので、稼働が始まればupgradeする必要性を運⽤的に感じなかった

 APIなどの不統⼀、オレオレFork
 監視対象もSolarisでgccでコンパイルが通れば問題ない
 監視数が増えないので、スケールアウトとか必要なかった グラフもrrdデータなのでなので、問題なかった(いままでは)31

Nagios plugin(監視)はシンプル
Nrpe agentプログラムを使う場合、監視スクリプトは以下のステータスコードとテキスト標準出⼒を返せばよい
Nagios Exit Codes
Exit codeExitCodestatus

status00

OKOK11WARNINGWARNING

22

CRITICALCRITICAL33UNKNOWN UNKNOWN

Nrpe agent è Nagiosクロールへの通信も、同様な処理監視が作りやすい322-2) これまでの運⽤管理に使っていたツール 2) Hardware監視ツール:
 Director (IBM, Lenovo) SIM [System Insight Manager] (HPE) OpenManage (Dell)
導⼊されたのは、お名前VPSサービス開始後(初めてLinux採⽤)>> IBM IA Serverが初めて導⼊された製品のDefaultでIMMというIPMIの拡張管理ポートがあった
IPMI関連ツールやコンソールの有⽤性から、ここから広まった
Hardware監視ツールが無料で利⽤できたというメリットも33

2-2) HW監視ツール
 IBM Director
 DB(IBM DB2 or MS SQLなど)の負荷などで、構成の⼯夫は⼊ります Agent less監視 <<= ここ重要
 SIM (HP) PostgreSQL Agent必要 (HP ProLiant Gen9 あたりで、できるようになった?)
 HPは買わなくなりましたw
 Dell MS SQL Server Agent less監視 <<= ここ重要34

2-2) Agentがあると、なにが問題か?
 SIM (HP)
 HPは買わなくなりましたw ç なぜ?
 Agentが強制再起動を発動 (ASR)
 Hung upを検知した時に、強制再起動
 外部の温度で、強制再起動
 思わぬDefault設定 www è 結局Agentを停⽌することに その他、SmartArrayトラブル等、みんな運⽤疲れ

35

2) これまでの運⽤管理に使っていたツール 3) RTFM: Request Tracker
 ⼊社当初のドキュメント/チケット管理ツール(2007, 2008)
 Read the Fucking Manual Site: https://bestpractical.com/rt-and-rtir Document: https://docs.bestpractical.com/rt/4.4.0/index.html
 Apache + mod_perl (環境はもちろんSolaris) ドキュメント管理とチケット管理、Task Flowのツール
程なくして、redmineのチケット管理が⼊ったので、しばらくドキュメント共有ツールとしてつかつていました362) これまでの運⽤管理に使っていたツール 4) redmine: チケット、Task Flow管理 そもさん(お問い合わせ管理ツール)
 SQIP2 (障害管理ツール)
 Liveup/メンテナンス管理
 チーム間業務依頼管理
 Abuse管理 QAバグチケット管理
 プロジェクト管理システム(⼯数管理)

APIでチケットを投⼊したり、参照したりでいろいろ他のシステム連携
⼊社してからIDC OPEチームが導⼊
現在のシステム本部と事業部のTask Flow基盤として
37

2) これまでの運⽤管理に使っていたツール 5) dokuwiki:
 プロジェクトのドキュメント、作業メモ、仕様書記載
 RTのテキストのみから、画像、添付書類がつかえるように XML-RPC (JSONは標準では無い)
⼊社してからIDC OPEチームが導⼊
RTからはドキュメント・データ移⾏38

2) これまでの運⽤管理に使っていたツール *) その他:
 設備機器管理ツール(開発部作成 .Net)
 開発部で作成: ラックの管理なども含む
 オンコール管理ツール(開発部作成 .Net) 電話/メールの連絡先と、ローテーションスケジュールの管理
 IRC
 ChatOpsの原点、作業時の連絡など
 NagiosからAlert Notification393) “ConoHa”をマルチロケーションで運⽤するにあたって、再検討した最新の運⽤管理ツールについて

40

3) ConoHaをマルチロケーションで運⽤時の再検討 A) 監視ツールのNagiosの数がサービスごとに発⽣ NotifyにMailを使っているので、莫⼤なWARN, ALERTメールが発⽣
MialをNotifyにすると、通常業務のMailに負荷がかかり、Mailの障害という⼆重障害が発⽣ ロケーションが違うと、メールの到達性に疑問 B) マルチロケーションをどう管理しやすくするのか
 画⾯上統⼀管理できるか C) 遠隔地は⾃社で運⽤するとは限らなくなる(⽇本だけじゃない、現地法⼈)
 グループ会社、協⼒会社が使っても良いようにユーザ管理できる
 Html5 SSHなど、web画⾯で作業が終端できる、証跡 (記録)41

3) 再検討ツールたち 1) Nagios fork系、インスパイア系
 Nagios監視プラグインが流⽤できる
 2) 新たな構成
 Hatohol + zabbix / Monascaつかえる?
 Hatoholにより、統合できそう Gateone pluginとか作れるかも(zabbixからclick to html5 ssh)
http://tech-sketch.github.io/hyclops/jp/
TISが作ったFork : HyClops for Zabbix 3) そのままNagiosを個別に⽴てる
 ⽅法論は同じだが、「カイゼン」全く無し <<= 抵抗勢⼒はこれが良いとw
423) 再検討: A) Nagiosインスパイア系: Ichinga
 Ichinga https://www.icinga.org/
 CLIも強⼒、分散監視できる
 Nagios pluginをそのままつかえる (pluginが多い)
 Webと本体がわかれている、Timelineてきなインターフェースもよさ気 有償サポートあり、HPE Helion OpenStackもIchingaを採⽤
 WebはPHP ?
 以外にインストール⾯倒
 監視設定処理の概念がNagiosを引き継いでいるので、以外に⾯倒 DBを使う43

3) 再検討: A) Nagiosインスパイア系: Sensu
 Sensu https://github.com/sensu/sensu/
 Ruby、RabbitMQ, Redis, JSON メッセージ志向 (スケールアウトできるように)
 メトリックス送信先で、グラフ書いたりする(Graphite, Librato, etc)
グラフ機能は内蔵されていない
 Chef, puppet, ansibleでのWorkFlowで監視を投⼊できる
 GUIは “uchiwa.io” : https://uchiwa.io/ HandlersでNotifyアクション, GraphiteなどへのメトリクスPOST(グラフ更新)
 素晴らしいんだけど、学習コストいまは⾼そう(ConoHaリニューアル時)、Yahoo Japanは使っている
443) 再検討: A) Nagiosインスパイア系: Shinken
 Shinken
 http://www.shinken-monitoring.org/

shinken.io

 https://github.com/naparuba/shinken/
 PythonでNagiosをよりEnterpriseに作りなおした感じ マルチデータセンタに適合しやすい構成
 Graphite, Nagvis, PNG4Nagios, Nagios OLD cgi webにも!! 対応 Livestatus based API対応 あぁ、普通にNagiosの新しいバージョンとしては良いかも Nagios過ぎて、若⼲引く感じ

453) 再検討: Hatohol + zabbix, Nagios
 Hatohol http://www.hatohol.org/
 https://github.com/project-hatohol/hatohol Miracle Linuxが主要メンバーで開発しているOpensourceなので、githubも⽇本語のissueがある
 Zabbix or NagiosのFrontendとなる
 Metricを実際にするzabbix, NagiosをまとめるFrontendであり、Notify、Actionを統合できるツール
 OpenStack連携の話をイベントの時に聞いたè あ、よさそう
464) Hatohol + zabbix 構成を選択した理由

474) Hatohol + zabbixを選択した理由 A) 監視ツールのNagiosの数がサービスごとに発⽣ Notifyの場所をHatohol⼀箇所にすることで、Action(ex: チケットを作ったり、chatに通知したり、メールに投げたり)を作りやすくする NagiosもZabbixもCeilometerもメトリックとして⼀元化できる、だろう B) マルチロケーションをどう管理しやすくするのか Hatoholに情報ポータルを⼀元化でき、zabbixのスケールアウトとして活⽤できる(zabbix APIで接続) (取得結果はHatohol内部のDBにcache) C) 遠隔地は⾃社で運⽤するとは限らなくなる(⽇本だけじゃない) HAPI(Hatohol Arm Plugin Interface)経由で認証を作ればできる、らしいグループ企業は、web auth APIに対応すれば良い48

zabbix
 エージェントレスでssh baseでもいけますよ(by ⼯藤) (zabbix ver. 2.2系当時)
 GUIはモダンでもないけど、APIが公式である (zabbix API) ライブラリ結構ある: https://www.zabbix.org/wiki/Docs/api/libraries Ex) Php: PhpZabbixApi : http://github.com/confirm/PhpZabbixApi
 Nagiosみたいに分裂、発散せず、zabbix.org としてまとまっているのが良い 情報も探しやすい (オープンソース版、商⽤版) 、情報が多い重要 オープンソース活⽤において、商⽤とコミュニティが活発である (重要) Forkしたくはないけど、pluginぐらいなら作るのはOK まあ、そろそろ他の監視ツールも使ってみたい49

Hatohol + zabbix, nagios
 Hatoholにより、監視ツールは異なっても、おなじようにいけるだろう Nagiosのところは、Sensu(ruby), Shinken(python), Ichingaになっても、なんとかなるかもとかんがえられる (置換可能)

 Nagiosのところは、”live status api”がよいかな(2015/05 導⼊当時)

50

51

Hatohol + nagios livestatus API

⽉⽇は流れ、秋ごろ

52

Hatohol + zabbix or nagios
 (2015/Sep) Issueが上がる
 https://github.com/project-hatohol/hatohol/issues/1549
 Mnakagawa-san作る 実装された:
https://github.com/project-hatohol/hatohol/blob/master/server/README.md これにより、NagiosをNDOUtilsにマイグレしなくても、Nagios Livestatus APIの設定のみで連携できるように(我々は、zabbix導⼊後ですが、OKだなと)

53

5) Hatohol + zabbix構成54

5) Hatohol + zabbix構成 (2017/02/17現在)
 各リージョンのOpenStack cloud clusterの監視 : zabbix
 JP (Tokyo)
 US (San Jose) Singapore
 Vietnam (Hanoi)
 Thailand (Bangkok) 情報の集約 : Hatohol (JP (Tokyo)) Notification Action : redmine 1 AlertごとにHatoholがredmineにアラートチケットを発⾏(Action)
 証跡 : redmine アラートをチケット =>> メールとしてNotify
55

# Now(2017); data centers in 5 Locations

TokyoVNThaiSanjose

Singapore565) zabbix
 zabbix単体でのalert通知は利⽤しない
 ZabbixはバックエンドがDatabaseであり、alert履歴など貯めないことでなるべく軽くすることを考えておく
 Zabbixの古い履歴は、Databaseが肥⼤化する
 DB (MySQL, PostgreSQL など)が膨れるので、履歴データを定期的に削除
 履歴はredmineに「証跡」として残すので、気軽に消せる

グラフも紐付いているので、グラフを残したい場合には、別途グラフツールを考える
Zabbix è Graphite + Graphana など

 OpenStack clusterのリージョン(ロケーション)ごとに設置する

57

5) Hatohol Zabbixからの情報の集約とActionの⽣成に専念させる Action : 現在は 「Alert発⽣アクション」をredmine チケットに 「Alert収束(終了)アクション」を通知してほしいとのユーザリクエスト
 Nagiosにはある機能 (今後の課題)

 今後の活⽤ Hatohol APIとchatops (chatworks, slack)との組み合わせ

 オープンソースであるので、開発コミュニティに参加して機能改善していく 運⽤監視の改善プロジェクト

58

59

60

61

Fin.

62

Appendix: OpenStackの運⽤管理63

Appendix6) (参考) OpenStack Japan Ops Workshop 2015/12
 2015年はじめて東京でOpenStack Summitが開催(10⽉)
 Ops Workshop⾃体はSummitの中でもこれまでは開催されていたが、セッションが同時開催だと参加しづらいという側⾯も
 Mid-Cycleとして Summitとの中間時期にも開催されることに OpenStackの開発へのFeedback(blueprintを書けないopsの意⾒取り込み)や、ドキュメント開発(ドキュメント作成は開発と同等となった)への取り組みへの反映
 OpenStack Summitとは⽇本ではずらして開催 東京(7⽉)、沖縄(12⽉)
 次回開催は OpenStack Days Tokyo in July 2016

64Appendix
OpenStack ops docs (ドキュメント) Ops Guide
 HA Guide
 Security Guide New Architecture Design Guide
 Networking Guide
http://docs.openstack.org/ops/
電⼦書籍データ(無料)
http://docs.openstack.org/ja/openstack-ops/content/
html閲覧 オペレーションガイド(ja)http://docs/openstack.org/sec/
html閲覧 セキュリティガイド(en)65Appendix
OpenStack ops ⽇本でどんなツールを使って運⽤しているか
http://superuser.openstack.org/articles/okinawa-openstack-ops-workshop-rides-wave-of-interest
Okinawa OpenStack Ops Workshop rides wave of interest
Etherpad (議事録まとめ)
https://etherpad.openstack.org/p/JP-Ops-workshop

66Appendix
ELKつかってますか? (⽇本のユーザ向け)
Noooooooo.
è なぜか?
⽇本では Logstash よりも Fluentd が好まれます つまりELK(E: ElasticSearch, L: Logstash, K: Kibana)ではなく、EFK(E: ElasticSearch, F: Fluentd, K: Kibana)である
 最近は”Beats”というものもある(Goで書かれているのでちっさく、ツールが⽤途別になっている) >> EBK ?
説明スライドhttp://www.slideshare.net/td-nttcom/collect-summarize-and-notify-of-openstacks-log
Collect, summarize and notify of OpenStack's log
67Appendix
Logstash vs. Fluentd
Logstash Javaである (メモリがっ…) “JRuby” runtime、スケールしない?
 Logのcollect + forward Plugin Input/Output/codec/filterなどのpluginがある(ruby)
Fluentd
 ちっさい、軽い? Norikraなど中間処理に渡して再処理などgateway
 Plugin Online processingがある è Norikra (ここは”JRuby”なんだが) Collectorでcounter組み込み(grep counter, datacalculator, etc.)68Appendix
opsツール(Workshopアンケートより)
Log monitoring tol
 Logstash: 0 Fluentd: 4
 Beaver: 0 << https://github.com/josegonzalez/python-beaver
 Rsyslog: 6
 Splunk: 4
 ELK:
Splunkは有償ソフトだが、4社も使っているとのこと(使いやすい)69

Appendix
log処理で何をやると便利か?
 串刺しで検索して動きを⾒る: 共通IDの検索 Request ID
 Tenant ID
 User ID
 その他 object(flavor, volume, image) ID

70

Appendix
OpenStackの監視系、アンケートより
 Kibana: 1
 Grafana: 2
 Collectd: 1
 Nagios: 1
 Zabbix: 9
 << スケールしない(170,000 metrics)、グラフがpoor Sensu: 2
 Monasca: 0 HRForcast: 1 (data visualizer,
 GrowthForcastがRRDToolに依存しているが、HPForcastはCSV(TSV)とかでOK、
71

Appendix
OpenStackの監視系、アンケートより
Ceilometerはつかつている?: 4 企業 yes Backend: Mongodb
 なににつかっているの?
 Billing: 1 (GMOのみ)
 HeatでのAutoscaleのAlertingに使っているVMの中⾝の監視は?
 Nagios, Sensuなどの通常監視 Libvirtdからの外部からの監視 Guest agent
 Qemu-guest-agent (qemu経由でguestの情報取得)
 https://github.com/rackerlabs/openstack-guest-agents-unix
72Appendix
OpenStackの監視系、アンケートよりCMDB(構成管理DB)とか使っている?
 開発CI, alerting, notification system
 ⾃社CMDB : 3 企業
 CMDBでインフラを管理(NW(IPAM), Server)
 << dynamic Inventory?
その他使っているもの
 Spark ElasticSearch InfluxDB +1
 graphite
73

Appendix
OpenStackのlogのこれから “oslo.log” という共通ライブラリ化により、標準フォーマット化
 Traceback logは複数⾏にまたがっている << Parseしづらい Error codeのoslo.logでの統⼀化

74Appendix
OpenStack deployment tips
 Puppet : 3
 OS-puppet : 0
 Chef : 4
 OS-Chef : 0
 Ansible : 7
 OS-ansible : 1
 Juju : 2
 Fuel : 1
それぞれ、運⽤管理ツールを兼ねているものがある
Fuelなど75

Appendixその他
詳しくは、以下を⾒てください。箇条書きになっていますEtherpad (議事録まとめ)
https://etherpad.openstack.org/p/JP-Ops-workshop

76