Slide 1

Slide 1 text

フルマネージドホスティングの フルマネージドホスティングの 運用監視に Mackerel を導入した話 運用監視に Mackerel を導入した話 Kenichi Morimoto 2018 / 08 / 02 Mackerel Meetup #12

Slide 2

Slide 2 text

もくじ もくじ 自己紹介 既存の監視・運用の問題点 Mackerel 導入理由 Mackerel 導入後 監視利用例

Slide 3

Slide 3 text

自己紹介 自己紹介 名前: 森本 健一 2006~ インフラエンジニア GCP Cloud Architect AWS Solutions Architect Associate @hogem

Slide 4

Slide 4 text

法人向けフルマネージド ホスティング 法人向けフルマネージド ホスティング 自社基盤メイン 既存 ISP の回線設備を有効活用 クラウド基盤 VMware / 約700VM 物理 専用サーバ、共用サーバ / 約500 台 NW 機器 / 約300 台 パブリッククラウド AWS 、GCP 、(Azure)

Slide 5

Slide 5 text

抱えていた問題 抱えていた問題 ユーザへの障害通知のタイムラグ 混在している監視システム たびたび起こる監視設定の間違い 監視サーバの設計上の問題

Slide 6

Slide 6 text

ユーザへの障害通知のタイムラグ ユーザへの障害通知のタイムラグ 手動で連絡 営業へのメール 障害Web ページへの掲載 どうしても連絡が遅くなる 同時に複数の障害が発生した場合 社内の複数部署と連携しているシステム

Slide 7

Slide 7 text

混在している監視システム 混在している監視システム Zabbix Pandora FMS Cacti ( 2つ) GrowthForecast 各担当者が個別に用意して運用が煩雑に

Slide 8

Slide 8 text

Cacti Cacti L2/L3 SW の interface 全部 グラフにするとかは楽 snmp 、mib の知識が必要 ( やや特殊) cacti plugin 作成の学習コスト お手軽にグラフ描きたい!

Slide 9

Slide 9 text

GrowthForecast GrowthForecast cacti より簡単にグラフ化したいので採用! API 経由でグラフ作成 単体ではアラート通知機能がない 通知の必要がない統計グラフに利用している

Slide 10

Slide 10 text

Pandora FMS Pandora FMS オープンソースの監視ソフトウェア クラウド基盤構築時に導入 子会社 ( システム運用、監視、障害対応) にコミ ッタがいたので採用

Slide 11

Slide 11 text

Pandora FMS 問題点 Pandora FMS 問題点 リソース結構使う 普段は問題ない 大規模障害時にアラート来なかった 監視サーバのスペック CPU: Intel Xeon E5-2407 2.20GHz 4 コア Memory: 40GB

Slide 12

Slide 12 text

Pandora FMS 監視数 Pandora FMS 監視数 監視ホスト数: 約600 監視項目数: 約3500

Slide 13

Slide 13 text

リソース状況 リソース状況 $ sar 00:00:00 CPU %user %nice %system %iowait %stea Average: all 39.53 0.00 25.00 3.27 0.0

Slide 14

Slide 14 text

監視サーバの設計の問題 監視サーバの設計の問題 当初予算の制約 同一H/W で監視とログサーバを兼ねていた Pandora FMS が想定よりリソース食う クラウド基盤と同一NW 内に監視サーバを配置

Slide 15

Slide 15 text

ある日 大規模な NW 障害が発生 ある日 大規模な NW 障害が発生 NW 環境が不安定に 一部のホストとストレージが切断 約1時間、影響 数百VM Pandora 上はステータスが“ 不明” となりアラート 通知が飛ばなかった 後日調査: Pandora のリソース不足が原因だった 可能性が高い

Slide 16

Slide 16 text

たびたび起きる監視設定ミス たびたび起きる監視設定ミス サーバ構築者が監視担当者に依頼 監視設定間違い (ex: ホスト、ポート) アラート送信設定間違い (ex: 送信未設定、宛先) サーバ構築者が監視依頼を忘れていた 根本的な原因: レビューがない

Slide 17

Slide 17 text

当時抱えていた問題 ( おさらい ) 当時抱えていた問題 ( おさらい ) 障害通知のタイムラグ 混在している監視システム たびたび起こる監視設定の間違い 監視サーバの設計上の問題

Slide 18

Slide 18 text

Mackerel 導入理由 Mackerel 導入理由 個々の課題の解決方法は色々あった Mackerel を使えば総合的に解決できそう SaaS / マネージドサービス コスト比較 クラウドに Zabbix インスタンス 冗長構成 VPN 、監視運用、管理

Slide 19

Slide 19 text

監視サーバの保守が不要 監視サーバの保守が不要 オンプレ or クラウド上で監視サーバ構築の場合 クラスタ構成(PaceMaker 等) 、複数台構成 Pandora FMS, Zabbix, Zabbix Proxy 台数、容量増加時にスケールできる設計が必要

Slide 20

Slide 20 text

プライベート NW 環境に導入しやすい プライベート NW 環境に導入しやすい セキュリティ要件の厳しい顧客のプライベート ネットワーク環境 api.mackerelio.com 443 port への outbound の許可 があればOK HTTP Proxy or NAT 監視のために 443 通します、という説明は必要 監視サーバからのルーティング、FW 許可などが 不要

Slide 21

Slide 21 text

工夫したこと 工夫したこと 障害情報ページへのリアルタイムの反映 オーガニゼーションをまたがった検索 顧客への通知メールのカスタマイズ

Slide 22

Slide 22 text

マネージドホスティング マネージドホスティング 原則 1 顧客 1 オーガニゼーション 約 70 オーガニゼーション Mackerel 管理画面上でオーガニゼーションを超 えてホスト、アラートが検索できない

Slide 23

Slide 23 text

構成図 構成図

Slide 24

Slide 24 text

自前ダッシュボードの作成 自前ダッシュボードの作成 GCP 上に GCE インスタンスを構築 本当は App Engine を使ってみたかった 本番利用の実績がなく、実装までの時間の都 合上断念 Python + Flask + FlaskAdmin で作成 API Key の管理 登録ホスト、アラート等を JSON で取得 オーガニゼーションごとのホスト数

Slide 25

Slide 25 text

Flask Admin + SQLAlchemy Flask Admin + SQLAlchemy class Organizations(db.Model): id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(50), nullable=False, index= apikey = db.Column(db.String(50), nullable=False, unique verified = db.Column(db.Boolean) private = db.Column(db.Boolean) memo = db.Column(db.String(200)) admin.add_view(ModelView(Organizations, db.session))

Slide 26

Slide 26 text

簡単に管理画面実装できる 簡単に管理画面実装できる

Slide 27

Slide 27 text

JSON を元に出力した html JSON を元に出力した html

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

JSON を元に出力した html (hosts) JSON を元に出力した html (hosts)

Slide 30

Slide 30 text

通知メールのカスタマイズ 通知メールのカスタマイズ Mackerel からの通知メール From: [email protected] 営業の要望 From の変更 メール本文のカスタマイズ 簡単な内容で送って欲しい service ごとに異なる宛先に送りたい

Slide 31

Slide 31 text

Webhook request body 抜粋 Webhook request body 抜粋

Slide 32

Slide 32 text

GCP 上に API 用意 GCP 上に API 用意 Flask で Webhook 受け取る JSON から orgName, hostname 等を取得 1 ホスト 1 サービス で運用 ユーザへのメール送信には SendGrid を利用 user = db.session.query(Notifications).filter( Notifications.orgname == orgname, Notifications.service == service).first()

Slide 33

Slide 33 text

死活監視の通知メール 死活監視の通知メール

Slide 34

Slide 34 text

書き換えたメール 書き換えたメール Mackerel のアラートID をケースID として通知 問い合わせの際にMackerel 上で追える 2018-07-26 11:57:04 vmXXXX ID 3k73ZJscVcW Web

Slide 35

Slide 35 text

補足 : GCP のメール送信制限 補足 : GCP のメール送信制限 ポート 25 を宛先とする送信トラフィック (SMTP )はすべてブロックされます ポート 465 または 587 を宛先とするほとんどのト ラフィック(SMTP over SSL )がブロックされま す https://cloud.google.com/compute/docs/networks- and-firewalls

Slide 36

Slide 36 text

監視設定手順の簡略化 監視設定手順の簡略化

Slide 37

Slide 37 text

Mackerel 導入後の構成 Mackerel 導入後の構成 エージェントインストールで死活監視は自動的 に開始 これだけで監視漏れがなくなる安心感が得られ る

Slide 38

Slide 38 text

アラートごとの宛先がわかりやすい アラートごとの宛先がわかりやすい

Slide 39

Slide 39 text

Mackerel 導入前 URL 監視設定フロー Mackerel 導入前 URL 監視設定フロー サーバ構築者が監視内容をexcel に記入 サーバ構築者がチケットにexcel を添付 監視担当者がチケット内容を元に監視設定 辛い

Slide 40

Slide 40 text

Mackerel 導入後 ( 予定 ) Mackerel 導入後 ( 予定 ) 担当者が監視内容を設定 mkr monitors pull して編集 branch 切って commit, push ( 社内 Gitlab ) Merge Request 投げる チェック者が Merge Gitlab CI で自動的に設定 mkr monitors push

Slide 41

Slide 41 text

cron を Mackerel に巻き取る cron を Mackerel に巻き取る 定期的なチェック処理等 クリティカルなモノは結果を監視してる 全部してない スクリプト個別に実装すると面倒 失敗時の連続通知抑制 終了ステータスだけ調整すれば check plugin で出 来る

Slide 42

Slide 42 text

監視利用例 監視利用例

Slide 43

Slide 43 text

CDN CDN CDN: J-Stream とパートナー契約 ( 利用状況次第で) AWS より転送単価安い CloudWatch のような通知機能がない API で転送量取得は可能 転送量コミット xx TB / 月額 oo 万円 容量超過時 xx 円 / GB

Slide 44

Slide 44 text

CDN の転送量監視 CDN の転送量監視 Mackerel でメトリック監視で解決 サービスメトリックに投稿 容量超過が発生したらアラート通知 グラフ共有で関係者に転送量状況を共有

Slide 45

Slide 45 text

7 月の某ユーザの traffic graph 7 月の某ユーザの traffic graph

Slide 46

Slide 46 text

公共機関 Web サイト - 大雨の日 公共機関 Web サイト - 大雨の日

Slide 47

Slide 47 text

契約容量を 100 % としたグラフ 契約容量を 100 % としたグラフ このメトリックに監視を設定

Slide 48

Slide 48 text

グラフ式 - 全ユーザの CDN 合計容量 グラフ式 - 全ユーザの CDN 合計容量

Slide 49

Slide 49 text

Mackerel 登録ホスト数の監視 Mackerel 登録ホスト数の監視 default では mackerel-agent.conf は一般ユーザで 読み取り可能 API Key がわかる chmod 600 mackerel-agent.conf し忘れたり 他部署に root 権限を渡している 万が一、誤った操作されたら。。。 自前ダッシュボードのAPI が正常動作しているか の確認も兼ねてる

Slide 50

Slide 50 text

登録ホスト数 登録ホスト数

Slide 51

Slide 51 text

登録ホスト数を監視 登録ホスト数を監視

Slide 52

Slide 52 text

要望 要望

Slide 53

Slide 53 text

通知メールのテンプレート 通知メールのテンプレート From 、To Subject Body

Slide 54

Slide 54 text

ホストのメモ情報 ホストのメモ情報 マニュアルへの link とか書きたい メールには含まれていない Webhook で飛んでくる JSON には含まれている

Slide 55

Slide 55 text

外形監視 外形監視 Mackerel で外部からの監視 URL 外形監視はある 特定ホストの障害として紐づけたい icmp, port 監視 Mackerel 本体で全部やってくれたら嬉しい もしくは OSS を使う https://github.com/fujiwara/maprobe

Slide 56

Slide 56 text

まとめ まとめ エージェントインストールだけで監視が始まる 安心感 API が豊富に提供されていて大抵のことはできる 運用監視を Mackerel に任せることでサービス提 供に集中できる