Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
mackerel-ug-kansai-1
Search
ashl for the work
February 12, 2019
Business
0
710
mackerel-ug-kansai-1
フルマネージドホスティングの運用監視に Mackerel を導入した話
at Mackerel UG 関西支部 Meetup #1
ashl for the work
February 12, 2019
Tweet
Share
Other Decks in Business
See All in Business
セーフィー株式会社(Safie Inc.) 会社紹介資料
safie_recruit
6
350k
デジタル証券株式会社・会社紹介
dts
0
730
第9回 情シス転職ミートアップ - わたしのミッションとLayerXに決めた理由
shimosyan
0
410
jinjer recruiting pitch
jinjer_official
0
74k
採用ピッチデック
macloud
3
76k
特別講義 理系のための法学入門
seko_shuhei
2
2.4k
株式会社kubellパートナー 会社説明資料 (MINAGINE事業版)
kubell_partner
2
440
LW_brochure_engineer
lincwellhr
0
34k
三菱商事ロジスティクス_コンサルティング事業紹介
mclogi
0
380
Leading Mark新卒採用資料
unno
0
2.4k
【Progmat】受益証券発行信託に係る税制改正の背景と今後のST市場
progmat
0
220
Recruitment Deck_Growth Strategy_202506
sixtypercent
0
460
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
35
6.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Unsuck your backbone
ammeep
671
58k
GraphQLとの向き合い方2022年版
quramy
49
14k
Statistics for Hackers
jakevdp
799
220k
Rails Girls Zürich Keynote
gr2m
95
14k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
960
Into the Great Unknown - MozCon
thekraken
40
1.9k
A designer walks into a library…
pauljervisheath
207
24k
Building Adaptive Systems
keathley
43
2.7k
Transcript
フルマネージドホスティングの運用監視に Mackerel を導入した話 2019/02/13 Mackerel UG 関西支部 Meetup #1 https://speakerdeck.com/ashl/mackerel-ug-kansai-1
今回のお話 2018年にMackerelを導入するに至った経緯と導入 時の工夫をお話します。 • 自己紹介 • 既存の監視・運用の問題点 • Mackerel 導入理由
• Mackerel 導入時の工夫 • 監視利用例(おまけ:時間があれば)
自己紹介 • Name: 浅原 暁人 • twitter: @HOGEsyndrome • ◦
2008〜2012 & 2017〜 ◦ インフラエンジニア ▪ フルマネージドサービス基盤 ▪ 開発/構築/運用 ▪ 宣伝
既存の監視・運用の問題点
法人向けフルマネージド ホスティング • 自社基盤メイン ◦ 既存 ISP の回線設備を有効活用 ◦ クラウド基盤
VMware / 約1000VM ◦ 物理 専用サーバ、共用サーバ / 約500台 ◦ NW 機器 / 約300台 • パブリッククラウド ◦ AWS、GCP、(Azure ほか)
抱えていた問題 1. ユーザへの障害通知のタイムラグ 2. 混在している監視システム 3. たびたび起こる監視設定の間違い 4. 監視サーバの設計上の問題
1. ユーザへの障害通知のタイムラグ • サービス影響を調べてから手動で連絡 ◦ 手動で営業へのメール ▪ 営業から顧客へメール ◦ 手動で障害Webページへの掲載
• どうしても連絡が遅くなる ◦ 同時に複数の障害が発生した場合 ◦ 夜間休日にリモートで対応 • 社内の複数部署と連携しているシステム
• ZABBIX • Pandora FMS • Cacti (2つ) • GrowthForecast
• その他自製ツール類 (Shell、Perl、Python ほか) 全て使いこなせる人などいるだろうか(反語 2. 混在している監視システム
3. たびたび起こる監視設定の間違い サーバ構築者が監視担当者に依頼 • 監視設定間違い (ex: ホスト、ポート) • アラート送信設定間違い (ex:
送信未設定、宛先) • サーバ構築者が監視依頼を忘れていた 根本的な原因: レビューがない
4. 監視サーバの設計上の問題 • 当初予算の制約 • 同一H/Wで監視とログサーバを兼ねていた • Pandora FMS が想定よりリソース食う
◦ CPU: Intel Xeon E5-2407 2.20GHz 4コア ◦ Memory: 40GB ◦ それでも、大規模障害でメールが溜まると処理落ち • 基盤と同一NW内に監視サーバを配置
障害発生 ( Mackerel 導入の決め手 )
基盤全体のNW障害発生 • とあるNW機器がバグ(仕様)を踏む ◦ 大量のトラフィックが発生 • NWが“不安定”に ◦ 一部のホストとストレージが切断 ◦
約1時間、影響 数百VM
その時、監視は・・・ • ZABBIX ◦ Pandora との住み分けにより、検知せず • Pandora FMS ◦
監視ステータス:不明 ▪ アラート飛ばず ◦ 結論、リソース不足 • Cacti & GrowthForecast ◦ 自身は元々アラート投げず
その時、監視担当者は・・・ • 問い合わせベースで対応 ◦ 大規模障害に気付くまでにタイムラグ • 障害連絡だけでてんやわんや ◦ 影響範囲はどこまでか ◦
調べている間に次々に問い合わせ • 正確な影響範囲調査 ◦ 全サーバにログインして・・・
監視、考え直さんといかんし。
Mackerel 導入理由
監視サーバの保守が不要 オンプレ or クラウド上で監視サーバ構築の場合 • クラスタ構成(Pacemaker等)、複数台構成 ◦ Pandora FMS, ZABBIX,
ZABBIX Proxy • 台数、容量増加時にスケールできる設計 コスト的にもメリットが大きい
プライベート NW 環境に導入しやすい • セキュリティ要件の厳しい顧客のプライベートネッ トワーク環境 ◦ api.mackerelio.com 443 port
への outbound の許可があればOK ▪ HTTP Proxy or NAT ▪ 監視のために 443 通します、という説明は必要 • 監視サーバからのルーティング、FW許可などが 不要
機能拡張性 • APIに項目と値さえ投げれば何でもOK ◦ 独自カスタマイズされたツール類も巻き取り 可能 ▪ 失敗時の連続通知抑制 ▪ アラートレベルによる通知先変更
▪ データ推移
Mackerel 導入
導入にあたって • 原則 1顧客 1オーガニゼーション ◦ メール送り先間違い防止 ◦ 70以上のオーガニゼーションを一括管理 •
Mackerelのメール文面(営業曰く) ◦ 問い合わせ窓口: Mackerel ◦ なに書いてるかわからない ◦ そのままでは顧客・営業に送れない
自前ダッシュボードの作成
GCP 上に GCE インスタンスを構築 Python + Flask + FlaskAdmin で作成
• API Key の管理 • 登録ホスト、アラート等を JSON で取得 • オーガニゼーションごとのホスト数 本当は App Engineを使ってみたかった
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))
Flask Admin + SQLAlchemy ☆かんたん☆
JSON を元に出力した HTML (その後、本家にオーガニゼーション一覧が実装されて半分くらい意味を失う)
JSON を元に出力した HTML (hosts)
通知メールのカスタマイズ • Mackerel からの通知メール ◦ From:
[email protected]
• 営業の要望 ◦
From の変更 ◦ メール本文のカスタマイズ ◦ 簡単な内容で送って欲しい ◦ service ごとに異なる宛先に送りたい
GCP 上に API 用意 • Flask で Webhook 受け取る •
JSON から orgName, hostname 等を取得 • 1ホスト 1サービス で運用 • ユーザへのメール送信には SendGrid を利用 user = db.session.query (Notifications). filter( Notifications .orgname == orgname, Notifications .service == service).first()
補足: GCPのメール送信制限 • ポート 25 を宛先とする送信トラフィック(SMTP) はすべてブロックされます • ポート 465
または 587 を宛先とするほとんどのト ラフィック(SMTP over SSL)がブロックされます • https://cloud.google.com/compute/docs/netwo rks-and-firewalls
Mackerelからの通知メール
書き換えたメール • MackerelのアラートIDをケースIDとして通知 • 問い合わせの際にMackerel 上で追える i-TEC マネージドクラウド 障害を検知いたしました。 発生日時 :
2018-07-26 11:57:04 障害対象サーバ: vmXXXX ケースID : 3k73ZJscVcW 詳細については下記Webサイトをご確認ください。
監視利用例
CDN転送量監視 • J-Stream とパートナー契約 ◦ APIで転送量取得は可能 ◦ 転送量コミット xx TB
/ 月額 oo 万円 ◦ 容量超過時 xx 円 / GB • Mackerel メトリック監視で転送量を監視 ◦ サービスメトリックに投稿 ◦ 容量超過が発生したらアラート通知 ◦ グラフ共有で関係者に転送量状況を共有
CDN転送量監視
バーストアクセスチェック • ECサイトのセール日など、特定の日時にバース トアクセスが見込まれる ◦ アプライアンスL/Bの snmp をとって、アクセ ス数を監視 ◦
監視したい時に入れ、用事がなくなったら外 す
Mackerel登録ホスト数の監視 • default では mackerel-agent.conf は一般ユー ザで読み取り可能 ◦ API Key
がわかる ◦ chmod 600 mackerel-agent.conf し忘れたり • 他部署に root 権限を渡している ◦ 万が一、誤った操作されたら。。。 • 自前ダッシュボードのAPIが正常動作しているか の確認も兼ねてる
Mackerel登録ホスト数の監視