ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy

P

オペレーション自動化と監視の取り組み

ヤフー株式会社サイトオペレーション本部インフラ技術３部安藤格也

P自己紹介

安藤格也(あんどうかくや)

servak

2011年入社

決済チームで開発、運用

2015/10にNWチーム(現職)に異動

2

P目次

オペレーション自動化

ネットワーク監視

3

PP

オペレーション自動化

4

P普段のオペレーション 5

利用者 NW担当者

専用ネットワークが欲しい

ネットワークを作ります

機器に応じた設定を人が投入

NW機器

P問題点について

人による作業が多いため、ヒューマンエラーが発生してしまう

日常的ではない作業ではなおさら間違えやすい

ヒューマンエラーについて再発防止が難しい

オペレーションに時間がかかってしまい、多くの依頼をこなせない

Etc...

6

自動化を進めていこう

P自動化の方針について

NW機器とのやりとりはCLI(SSH, TELNET), SNMP

CLIだとプログラムで扱いやすい形(JSON, XMLなど)になっていない

SNMPだと取得できる情報が不十分になってしまう

新しい機器、バージョンだとWebAPI、Netconfに対応しているもの

もあるが、古い機器でのオペレーションがまだ圧倒的に多い

7

極力構造化されたAPIを利用出来ないところは努力！

P自動化の方針について

マルチベンダーを利用するがゆえの問題点

NW機器ベンダーによって使いかたが大きく違う。

同じベンダーでも複数のOSがあり、情報取得方法が違う。

8

抽象化を進める

自動化へ

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

OS API

Cisco IOS CLI

Cisco NXOS Netconf

Juniper JUNOS Netconf

Arista EOS EAPI

Brocade NetIron CLI

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

Pしかし多くの問題が。。。 11

やっていくうちに出てくる問題たち(考慮漏れ)

NETCONFで取れるデータ != 構造化されたデータ

運用している機器すべてでWebAPIが利用できるわけでなかった

運用している機器すべてのバージョンを上げることが難しい

などなど ...

取得方法をCLIベースに変更

P次のステップへ 12

ログイン時にOSを意識する必要性は無くなった

コマンド、コマンド結果は未だOSを意識する必要が残った

=> 抽象化は不完全

P共通モデルの定義

取得したい内容を共通モデル化

コマンド結果の定義化

コアとなる考えのみ定義

すべてのOSで扱えるもの

13

P共通関数の定義 14

共通で利用する関数を用意

共通モデルを取得できる関数

コマンドでのOSの意識を消す

Pコマンド結果のパースが大変。。。 15

欲しい情報をコマンドから取得するのがとても大変。

既存のOSSを参考にすることに！

Pgoogle/textfsm 16

CLIの結果を解析するライブラリ

テンプレート(独自DSL)を記載すると簡単にCLIをパース出来る

多くのテンプレート実装が用意されている

Networktocode Orgが多くのテンプレートを用意してくれてる

https://github.com/networktocode/ntc-templates/tree/master/templates

OSSとして公開されている

https://github.com/google/textfsm

Pgoogle/textfsm利用のコード例 17

Pgoogle/textfsmコード例 18

P抽象化ひとまず完 19

IOS EOS

同じ方法で、色んなOSから情報が取得できるように！

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

Pメンテナンスの自動化

メンテナンスで行う内容

トラフィック寄せ(OSPF, VRRP)

インターフェースのダウンアップ

YAMLファイルに上記の内容を記載することでその状態にしてくれ

るコマンドを作成

設定を流すだけでなく、Before, Afterの状態を確認する

YAMLファイルも機器から情報を取得し自動生成

21

Pメンテナンスの自動化

行いたいことを記載することでOSを意識する必要なく、インター

フェースのup/downを実施することが出来るように！

22

Pまとめ

抽象化レイヤーの作成を行ったため、オペレーション自動化する

際のコーディングがとても楽に！

抽象化レイヤーのコードカバレッジが90％以上になるほどテストを

しっかりしたことも有り、バグがとても少なくなった

ベンダー毎に取り扱っている情報が違うため、すべてに置いて共

通化は出来なかったが重要概念はしっかり共通化できた

23

PP

ネットワーク監視

24

Pネットワーク監視の見直し 25

PING監視

smokeping

リソース監視

MRTG

問題点

情報が散らばってしまう

ツールがバラける(確認箇所の増加)

情報の詳細度が低い

UIがイケてない

Pネットワーク監視でやったこと

PING監視

パケットが落ちていないこと

複数拠点から

NW機器のリソース監視

トラフィック使用率

トラフィックが溢れていないこと

SFP故障によるパケットのドロップ

監視のHA化

26

P利用したツール Prometheus

Alertmanager

Grafana

27

PPrometheusとは Pull型(HTTP)のメトリクス監視ツール

Inspired by Google’s Borgmon

Alert管理機能を標準装備

Alertを発生させることが出来るし、管理ができる

多彩なService Discoveryに対応

OpenStack, Kubernetes, StaticFile ...

監視対象を自動的に見つけてくれる

公式で様々なメトリクス取得方法を提供

snmp_exporter, blackbox_exporter, node_exporter ...

28

PExporterについて

snmp_exporter

SNMPによる情報取得が出来る

node_exporter

*NIXのメトリクスを集めることが出来る

blackbox_exporter

外部監視をすることが出来る(pingなど)

29

Prometheus snmp_exporter

定期的に監視(HTTP) NW機器からトラフィック情報を取得(SNMP)

例: snmp_exporter

P

Prometheus

Prometheusの集約について(Federation) 30

Prometheus同士の集約・監視が可能

Prometheus

Prometheus

snmp_exporter

snmp_exporter

blackbox_exporter

P

Prometheus

Alertmanagerについて 31

• Prometheusから来たアラートをルールに応じてグループ化、通知先を変更可能• アラートの黙認など柔軟に設定が出来る

Alertmanager

Chatツール

メール送信

黙認

アラート

Pネットワーク監視でやったこと PING監視


複数拠点から





監視のHA化

32

PPING監視について 33

BlackboxExporterを利用

ICMP監視

Aggregateも2台構成



複数拠点(4箇所)すべてでPING失敗であったのが30s継続した場合、ア

ラートを発生させる監視設定を追加





複数拠点から





監視のHA化

37

Pリソース監視について 38

SnmpExporterを利用

監視・可視化のため16指標

の情報を取得

情報量が多いため、短期用

のPrometheusと長期の

Prometheusを設置



以下は定常的にアラート化していないが、いつでも確認できる状態に



トラフィック溢れによるパケットのドロップ

マイクロバーストや上限を超えるトラフィックがきたときに、

ifDiscardsが上昇するためそちらに閾値を設けアラートを実施



パケットが壊れている時など、ifErrorsが上昇するためそちらに閾値

を設けアラートを実施



複数拠点から





監視のHA化

43

PHA化について 44

AlertManagerをHA構成で稼働

アラートは2つのAlertManagerに連携されるが実際に通知される

のは1件のみになる。

Pアラート通知内容 45

Pまとめ情報を集約することで、適切なアラートだけ上げることが出来るようになった。

アラートに応じて、条件を細かく指定できることが良かった。

Alertmanagerによりアラートをグループ化することが出来るため、一気にア

ラートが来たときもグループでまとまりわかりやすくなった。

46

P今後について監視ツールとしての信頼性を高めていく

まだsmokeping, MRTGを利用して監視通知を上げている状態でもあるため、

それを完全に切り替えていきたい。

長期データの保持について考えていく

47

P

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

48

Technology

ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy