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
600
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
enechain company deck
enechain
PRO
7
88k
Company Deck for Engineers
cuolega
0
150
【リクロマ株式会社】20241007_会社紹介・採用説明資料
takahiro4545
0
400
Tokyo支援ナビ
tokyo_metropolitan_gov_digital_hr
1
260
会社説明資料
yanase
0
440
コーチ・エィのご紹介1
coacha
0
140
STUDIO ZERO 組織紹介 2024
plaid
PRO
0
4.6k
Insurance Distribution for Reiwa-era
hakusansai
2
150
マイナンバーを活用した申請手続の簡素化
tokyo_metropolitan_gov_digital_hr
2
270
租税教育コンテンツの製作
tokyo_metropolitan_gov_digital_hr
0
310
【新卒採用】BuySell Technologies会社紹介資料
buyselltechnologies
0
180k
ClipLine株式会社_会社紹介資料
clipline
0
480
Featured
See All Featured
Thoughts on Productivity
jonyablonski
67
4.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
RailsConf 2023
tenderlove
28
860
Six Lessons from altMBA
skipperchong
26
3.4k
Happy Clients
brianwarren
97
6.7k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Speed Design
sergeychernyshev
23
550
Become a Pro
speakerdeck
PRO
24
4.9k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
327
21k
GitHub's CSS Performance
jonrohan
1030
450k
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登録ホスト数の監視