Slide 1
Slide 1 text
フルマネージドホスティングの運用監視に Mackerel
を導入した話
2019/02/13 Mackerel UG 関西支部 Meetup #1
https://speakerdeck.com/ashl/mackerel-ug-kansai-1
Slide 2
Slide 2 text
今回のお話
2018年にMackerelを導入するに至った経緯と導入
時の工夫をお話します。
● 自己紹介
● 既存の監視・運用の問題点
● Mackerel 導入理由
● Mackerel 導入時の工夫
● 監視利用例（おまけ：時間があれば）
Slide 3
Slide 3 text
自己紹介
● Name: 浅原 暁人
● twitter: @HOGEsyndrome
●
○ 2008〜2012 ＆ 2017〜
○ インフラエンジニア
■ フルマネージドサービス基盤
■ 開発/構築/運用
■ 宣伝
Slide 4
Slide 4 text
既存の監視・運用の問題点
Slide 5
Slide 5 text
法人向けフルマネージド ホスティング
● 自社基盤メイン
○ 既存 ISP の回線設備を有効活用
○ クラウド基盤 VMware / 約1000VM
○ 物理 専用サーバ、共用サーバ / 約500台
○ NW 機器 / 約300台
● パブリッククラウド
○ AWS、GCP、(Azure ほか)
Slide 6
Slide 6 text
抱えていた問題
1. ユーザへの障害通知のタイムラグ
2. 混在している監視システム
3. たびたび起こる監視設定の間違い
4. 監視サーバの設計上の問題
Slide 7
Slide 7 text
1. ユーザへの障害通知のタイムラグ
● サービス影響を調べてから手動で連絡
○ 手動で営業へのメール
■ 営業から顧客へメール
○ 手動で障害Webページへの掲載
● どうしても連絡が遅くなる
○ 同時に複数の障害が発生した場合
○ 夜間休日にリモートで対応
● 社内の複数部署と連携しているシステム
Slide 8
Slide 8 text
● ZABBIX
● Pandora FMS
● Cacti (２つ)
● GrowthForecast
● その他自製ツール類 (Shell、Perl、Python ほか)
全て使いこなせる人などいるだろうか（反語
2. 混在している監視システム
Slide 9
Slide 9 text
3. たびたび起こる監視設定の間違い
サーバ構築者が監視担当者に依頼
● 監視設定間違い (ex: ホスト、ポート)
● アラート送信設定間違い (ex: 送信未設定、宛先)
● サーバ構築者が監視依頼を忘れていた
根本的な原因: レビューがない
Slide 10
Slide 10 text
4. 監視サーバの設計上の問題
● 当初予算の制約
● 同一H/Wで監視とログサーバを兼ねていた
● Pandora FMS が想定よりリソース食う
○ CPU: Intel Xeon E5-2407 2.20GHz 4コア
○ Memory: 40GB
○ それでも、大規模障害でメールが溜まると処理落ち
● 基盤と同一NW内に監視サーバを配置
Slide 11
Slide 11 text
障害発生
( Mackerel 導入の決め手 )
Slide 12
Slide 12 text
基盤全体のNW障害発生
● とあるNW機器がバグ（仕様）を踏む
○ 大量のトラフィックが発生
● NWが“不安定”に
○ 一部のホストとストレージが切断
○ 約１時間、影響 数百VM
Slide 13
Slide 13 text
その時、監視は・・・
● ZABBIX
○ Pandora との住み分けにより、検知せず
● Pandora FMS
○ 監視ステータス：不明
■ アラート飛ばず
○ 結論、リソース不足
● Cacti & GrowthForecast
○ 自身は元々アラート投げず
Slide 14
Slide 14 text
その時、監視担当者は・・・
● 問い合わせベースで対応
○ 大規模障害に気付くまでにタイムラグ
● 障害連絡だけでてんやわんや
○ 影響範囲はどこまでか
○ 調べている間に次々に問い合わせ
● 正確な影響範囲調査
○ 全サーバにログインして・・・
Slide 15
Slide 15 text
監視、考え直さんといかんし。
Slide 16
Slide 16 text
Mackerel 導入理由
Slide 17
Slide 17 text
監視サーバの保守が不要
オンプレ or クラウド上で監視サーバ構築の場合
● クラスタ構成(Pacemaker等)、複数台構成
○ Pandora FMS, ZABBIX, ZABBIX Proxy
● 台数、容量増加時にスケールできる設計
コスト的にもメリットが大きい
Slide 18
Slide 18 text
プライベート NW 環境に導入しやすい
● セキュリティ要件の厳しい顧客のプライベートネッ
トワーク環境
○ api.mackerelio.com 443 port への
outbound の許可があればOK
■ HTTP Proxy or NAT
■ 監視のために 443 通します、という説明は必要
● 監視サーバからのルーティング、FW許可などが
不要
Slide 19
Slide 19 text
機能拡張性
● APIに項目と値さえ投げれば何でもOK
○ 独自カスタマイズされたツール類も巻き取り
可能
■ 失敗時の連続通知抑制
■ アラートレベルによる通知先変更
■ データ推移
Slide 20
Slide 20 text
Mackerel 導入
Slide 21
Slide 21 text
導入にあたって
● 原則 1顧客 1オーガニゼーション
○ メール送り先間違い防止
○ 70以上のオーガニゼーションを一括管理
● Mackerelのメール文面（営業曰く）
○ 問い合わせ窓口： Mackerel
○ なに書いてるかわからない
○ そのままでは顧客・営業に送れない
Slide 22
Slide 22 text
自前ダッシュボードの作成
Slide 23
Slide 23 text
GCP 上に GCE インスタンスを構築
Python + Flask + FlaskAdmin で作成
● API Key の管理
● 登録ホスト、アラート等を JSON で取得
● オーガニゼーションごとのホスト数
本当は App Engineを使ってみたかった
Slide 24
Slide 24 text
Flask Admin + SQLAlchemy
class Organizations(db.Model):
id = db.Column(db.Integer, primary_key= True)
name = db.Column(db.String( 50), nullable=False,
index=True)
apikey = db.Column(db.String( 50), nullable=False,
unique=True)
verified = db.Column(db.Boolean)
private = db.Column(db.Boolean)
memo = db.Column(db.String( 200))
admin.add_view(ModelView(Organizations, db.session))
Slide 25
Slide 25 text
Flask Admin + SQLAlchemy
☆かんたん☆
Slide 26
Slide 26 text
JSON を元に出力した HTML
（その後、本家にオーガニゼーション一覧が実装されて半分くらい意味を失う）
Slide 27
Slide 27 text
JSON を元に出力した HTML (hosts)
Slide 28
Slide 28 text
通知メールのカスタマイズ
● Mackerel からの通知メール
○ From: [email protected]
● 営業の要望
○ From の変更
○ メール本文のカスタマイズ
○ 簡単な内容で送って欲しい
○ service ごとに異なる宛先に送りたい
Slide 29
Slide 29 text
GCP 上に API 用意
● Flask で Webhook 受け取る
● JSON から orgName, hostname 等を取得
● 1ホスト 1サービス で運用
● ユーザへのメール送信には SendGrid を利用
user = db.session.query (Notifications). filter(
Notifications .orgname == orgname,
Notifications .service ==
service).first()
Slide 30
Slide 30 text
補足: GCPのメール送信制限
● ポート 25 を宛先とする送信トラフィック（SMTP）
はすべてブロックされます
● ポート 465 または 587 を宛先とするほとんどのト
ラフィック（SMTP over SSL）がブロックされます
● https://cloud.google.com/compute/docs/netwo
rks-and-firewalls
Slide 31
Slide 31 text
Mackerelからの通知メール
Slide 32
Slide 32 text
書き換えたメール
● MackerelのアラートIDをケースIDとして通知
● 問い合わせの際にMackerel 上で追える
i-TEC マネージドクラウド 障害を検知いたしました。
発生日時 ： 2018-07-26 11:57:04
障害対象サーバ： vmXXXX
ケースID ： 3k73ZJscVcW
詳細については下記Webサイトをご確認ください。
Slide 33
Slide 33 text
監視利用例
Slide 34
Slide 34 text
CDN転送量監視
● J-Stream とパートナー契約
○ APIで転送量取得は可能
○ 転送量コミット xx TB / 月額 oo 万円
○ 容量超過時 xx 円 / GB
● Mackerel メトリック監視で転送量を監視
○ サービスメトリックに投稿
○ 容量超過が発生したらアラート通知
○ グラフ共有で関係者に転送量状況を共有
Slide 35
Slide 35 text
CDN転送量監視
Slide 36
Slide 36 text
バーストアクセスチェック
● ECサイトのセール日など、特定の日時にバース
トアクセスが見込まれる
○ アプライアンスL/Bの snmp をとって、アクセ
ス数を監視
○ 監視したい時に入れ、用事がなくなったら外
す
Slide 37
Slide 37 text
Mackerel登録ホスト数の監視
● default では mackerel-agent.conf は一般ユー
ザで読み取り可能
○ API Key がわかる
○ chmod 600 mackerel-agent.conf し忘れたり
● 他部署に root 権限を渡している
○ 万が一、誤った操作されたら。。。
● 自前ダッシュボードのAPIが正常動作しているか
の確認も兼ねてる
Slide 38
Slide 38 text
Mackerel登録ホスト数の監視