NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13で話してきた。 ネットワークの自動化・監視の取り組みについての発表資料となります。

1. P
オペレーション自動化と監視の取り組み
ヤフー株式会社 サイトオペレーション本部
インフラ技術３部
安藤 格也

2. P自己紹介
 安藤 格也(あんどう かくや)
servak
 2011年入社
 決済チームで開発、運用
 2015/10にNWチーム(現職)に異動
2

3. P目次
 オペレーション自動化
 ネットワーク監視
3

4. PP
オペレーション自動化
4

5. P普段のオペレーション 5
利用者 NW担当者
専用ネットワークが欲しい
ネットワークを作ります
機器に応じた設定を人が投入
NW機器

6. P問題点について
 人による作業が多いため、ヒューマンエラーが発生してしまう
 日常的ではない作業ではなおさら間違えやすい
 ヒューマンエラーについて再発防止が難しい
 オペレーションに時間がかかってしまい、多くの依頼をこなせない
 Etc...
6
自動化を進めていこう

7. P自動化の方針について
 NW機器とのやりとりはCLI(SSH, TELNET), SNMP
 CLIだとプログラムで扱いやすい形(JSON, XMLなど)になっていない
 SNMPだと取得できる情報が不十分になってしまう
 新しい機器、バージョンだとWebAPI、Netconfに対応しているもの
もあるが、古い機器でのオペレーションがまだ圧倒的に多い
7
極力構造化されたAPIを利用
出来ないところは努力！

8. P自動化の方針について
 マルチベンダーを利用するがゆえの問題点
 NW機器ベンダーによって使いかたが大きく違う。
 同じベンダーでも複数のOSがあり、情報取得方法が違う。
8
抽象化を進める
自動化へ

9. POS毎のアクセス方法を整理 9
OS API
Cisco IOS CLI
Cisco NXOS Netconf
Juniper JUNOS Netconf
Arista EOS EAPI
Brocade NetIron CLI

10. POS毎のアクセス方法を整理 10

11. Pしかし多くの問題が。。。 11
 やっていくうちに出てくる問題たち(考慮漏れ)
 NETCONFで取れるデータ != 構造化されたデータ
 運用している機器すべてでWebAPIが利用できるわけでなかった
 運用している機器すべてのバージョンを上げることが難しい
 などなど ...
 取得方法をCLIベースに変更

12. P次のステップへ 12
 ログイン時にOSを意識する必要性は無くなった
 コマンド、コマンド結果は未だOSを意識する必要が残った
=> 抽象化は不完全

13. P共通モデルの定義
 取得したい内容を共通モデル化
 コマンド結果の定義化
 コアとなる考えのみ定義
 すべてのOSで扱えるもの
13

14. P共通関数の定義 14
 共通で利用する関数を用意
 共通モデルを取得できる関数
 コマンドでのOSの意識を消す

15. Pコマンド結果のパースが大変。。。 15
 欲しい情報をコマンドから取得するのがとても大変。
 既存のOSSを参考にすることに！

16. Pgoogle/textfsm 16
 CLIの結果を解析するライブラリ
 テンプレート(独自DSL)を記載すると簡単にCLIをパース出来る
 多くのテンプレート実装が用意されている
 Networktocode Orgが多くのテンプレートを用意してくれてる
 https://github.com/networktocode/ntc-templates/tree/master/templates
 OSSとして公開されている
 https://github.com/google/textfsm

17. Pgoogle/textfsm 利用のコード例 17

18. Pgoogle/textfsm コード例 18

19. P抽象化ひとまず完 19
IOS EOS
同じ方法で、色んなOSから情報が取得できるように！

20. Pオペレーション自動化へ
fabric(python)ベースでオペレーションを関数化(タスク化)
20
VLAN3897をTrunkする作業
既にVLAN3897は存在し
ている
Po1 Po1
Po205Po205
Po205 Po205
まだVLAN3897設定して
ない
mnx04.*****.ynwp snx04.*****.ynwp
es-c1e-b007-1 es-c1e-b007-2

21. Pメンテナンスの自動化
 メンテナンスで行う内容
 トラフィック寄せ(OSPF, VRRP)
 インターフェースのダウンアップ
 YAMLファイルに上記の内容を記載することでその状態にしてくれ
るコマンドを作成
 設定を流すだけでなく、Before, Afterの状態を確認する
 YAMLファイルも機器から情報を取得し自動生成
21

22. Pメンテナンスの自動化
 行いたいことを記載することでOSを意識する必要なく、インター
フェースのup/downを実施することが出来るように！
22

23. Pまとめ
 抽象化レイヤーの作成を行ったため、オペレーション自動化する
際のコーディングがとても楽に！
 抽象化レイヤーのコードカバレッジが90％以上になるほどテストを
しっかりしたことも有り、バグがとても少なくなった
 ベンダー毎に取り扱っている情報が違うため、すべてに置いて共
通化は出来なかったが重要概念はしっかり共通化できた
23

24. PP
ネットワーク監視
24

25. Pネットワーク監視の見直し 25
 PING監視
 smokeping
 リソース監視
 MRTG
 問題点
 情報が散らばってしまう
 ツールがバラける(確認箇所の増加)
 情報の詳細度が低い
 UIがイケてない

26. Pネットワーク監視でやったこと
 PING監視
 パケットが落ちていないこと
 複数拠点から
 NW機器のリソース監視
 トラフィック使用率
 トラフィックが溢れていないこと
 SFP故障によるパケットのドロップ
 監視のHA化
26

27. P利用したツール
 Prometheus
 Alertmanager
 Grafana
27

28. PPrometheusとは
 Pull型(HTTP)のメトリクス監視ツール
 Inspired by Google’s Borgmon
 Alert管理機能を標準装備
 Alertを発生させることが出来るし、管理ができる
 多彩なService Discoveryに対応
 OpenStack, Kubernetes, StaticFile ...
 監視対象を自動的に見つけてくれる
 公式で様々なメトリクス取得方法を提供
 snmp_exporter, blackbox_exporter, node_exporter ...
28

29. PExporterについて
 snmp_exporter
 SNMPによる情報取得が出来る
 node_exporter
 *NIXのメトリクスを集めることが出来る
 blackbox_exporter
 外部監視をすることが出来る(pingなど)
29
Prometheus snmp_exporter
定期的に監視(HTTP) NW機器からトラフィック情報を取得(SNMP)
例: snmp_exporter

30. P
Prometheus
Prometheusの集約について(Federation) 30
Prometheus同士の集約・監視が可能
Prometheus
Prometheus
snmp_exporter
snmp_exporter
blackbox_exporter

31. P
Prometheus
Alertmanagerについて 31
• Prometheusから来たアラートをルールに応じてグループ化、通知先を変更可能
• アラートの黙認など柔軟に設定が出来る
Alertmanager
Chatツール
メール送信
黙認
アラート

32. Pネットワーク監視でやったこと
 PING監視
 パケットが落ちていないこと
 複数拠点から
 NW機器のリソース監視
 トラフィック使用率
 トラフィックが溢れていないこと
 SFP故障によるパケットのドロップ
 監視のHA化
32

33. PPING監視について 33
 BlackboxExporterを利用
 ICMP監視
 Aggregateも2台構成

34. PPING監視について 34
 パケットが落ちていないこと
 複数拠点(4箇所)すべてでPING失敗であったのが30s継続した場合、ア
ラートを発生させる監視設定を追加

35. PPING監視について 35

36. PPING監視について 36

37. Pネットワーク監視でやったこと
 PING監視
 パケットが落ちていないこと
 複数拠点から
 NW機器のリソース監視
 トラフィック使用率
 トラフィックが溢れていないこと
 SFP故障によるパケットのドロップ
 監視のHA化
37

38. Pリソース監視について 38
 SnmpExporterを利用
 監視・可視化のため16指標
の情報を取得
 情報量が多いため、短期用
のPrometheusと長期の
Prometheusを設置

39. Pリソース監視について 39

40. Pリソース監視について 40
 以下は定常的にアラート化していないが、いつでも確認できる状態に
 トラフィック使用率

41. Pリソース監視について 41
 トラフィック溢れによるパケットのドロップ
 マイクロバーストや上限を超えるトラフィックがきたときに、
ifDiscardsが上昇するためそちらに閾値を設けアラートを実施

42. Pリソース監視について 42
 SFP故障によるパケットのドロップ
 パケットが壊れている時など、ifErrorsが上昇するためそちらに閾値
を設けアラートを実施

43. Pネットワーク監視でやったこと
 PING監視
 パケットが落ちていないこと
 複数拠点から
 NW機器のリソース監視
 トラフィック使用率
 トラフィックが溢れていないこと
 SFP故障によるパケットのドロップ
 監視のHA化
43

44. PHA化について 44
 AlertManagerをHA構成で稼働
 アラートは2つのAlertManagerに連携されるが実際に通知される
のは1件のみになる。

45. Pアラート通知内容 45

46. Pまとめ
 情報を集約することで、適切なアラートだけ上げることが出来るようになった。
 アラートに応じて、条件を細かく指定できることが良かった。
 Alertmanagerによりアラートをグループ化することが出来るため、一気にア
ラートが来たときもグループでまとまりわかりやすくなった。
46

47. P今後について
 監視ツールとしての信頼性を高めていく
 まだsmokeping, MRTGを利用して監視通知を上げている状態でもあるため、
それを完全に切り替えていきたい。
 長期データの保持について考えていく
47

48. P
ご清聴ありがとうございました
48