Stackdriver を利用した実戦的なサーバ監視・運用方法
•
1 j'aime•3,944 vues
MSP 企業が語る「 Stackdriver 」を利用した実戦的なサーバ監視・運用方法
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Stackdriver を利用した実戦的なサーバ監視・運用方法
Similaire à Stackdriver を利用した実戦的なサーバ監視・運用方法 (20)
Stackdriver を利用した実戦的なサーバ監視・運用方法
- 1. MSP 企業が語る 「 Stackdriver 」を 利用した実戦的な サーバ監視・運用方法 原岡 昌寛 代表取締役, 株式会社ビヨンド 2018/9/20 Copyright © 2007-2018 Beyond Co., Ltd. All Rights Reserved.confidential
- 2. 原岡昌寛 株式会社ビヨンド 代表取締役 Google Certified Professional Cloud Architect Oracle DBAから LINUXベースのインフラエンジニアへ Speaker
- 3. Agenda 1. 会社紹介 2. Stackdriver について 3. 他の監視ツールとの違い 4. Stackdriver と運用監視
- 4. 1 会社紹介
- 5. ビヨンドについて 会社紹介 ■ 会社名 株式会社ビヨンド ■ 設立年月日 2007年4月4日 ■ 事業内容 ・サーバー事業 ・システム開発事業 ・Webサービス事業
- 10. Stackdriver とは Google Cloud Platform（GCP）の運用監視ツール アプリケーションのモニタリングサービス マルチクラウド環境の監視 エラー検知・分析、デバッグ
- 11. Stackdriver の特長 GCP 環境でのネイティブ統合 GCP 、AWS の監視を統合して行える 各種クラウドサービスとの連携 （Slack、PagerDuty） モニタリングを数分で簡単に開始できる アプリケーション開発の効率化 スマートなデフォルト設定
- 12. Stackdriver が提供する機能 機能 概要 Stackdriver Monitoring メトリクス監視、指標・イベント収集、ダッシュボード、グラ フ、アラート Stackdriver Logging ログデータ・イベントの検索・分析・モニタリング・通知、公 開API Stackdriver Error Reporting クラッシュをカウントして、分析と集計を実施、エラー管理イ ンターフェース、エラー詳細 Stackdriver Trace 分散トレース システム、レイテンシ データ収集、パフォーマ ンス分析 Stackdriver Debugger リアルタイム アプリケーション デバッグ、本番環境のコード 分析
- 14. Stackdriver の使いどころ GCP 環境 ・Google プロダクトのネイティブ統合 BigQuery、Cloud Pub/Sub、etc AWS とのマルチクラウド環境 ・可用性向上のためのバランシング ・適材適所によるパフォーマンス向上 BigQuery、Cloud Bigtable ・コスト削減
- 15. インフラエンジニアから見たいいところ ・GCP / AWSの両方が監視可能 ・WEB/Applicationの外形監視のレイテンシ が世界各国から見える ・BigQuery と連携（BQ利用状況を視覚化） ・Kubernetes ネイティブである （Kubernetesのノード、ポッド、デプロイメントのメトリクスを収集する） ・advanced logs filter（高度なログフィルター）
- 16. 3 他の監視ツールとの違い
- 18. Cloudwatchとの違い ■ CloudWatch ・対象：AWS ・メトリクス：死活、ログ ・通知方法： Amazon SNS ・データ保持期間：2週間 ■ Stackdriver ・対象：GCP / AWS ・メトリクス：死活、プロセス、Web、ログ、トレース、デバッグ ・通知方法：メール、Webhook、Slack、PagerDuty等 ・データ保持期間：6週間
- 19. mackerel との違い ■ Mackerel ・対象：AWS/クラウド/オンプレミス ・メトリクス：死活、プロセス、Web、ログ ・料金：1ホスト1800円～ Trial 14日間 ・通知：メール、Webhook、Slack、PagerDuty、TypeTalk、ChatWork ・データ保持期間：460日 ■ Stackdriver ・対象：GCP / AWS ・メトリクス：死活、プロセス、Web、ログ、トレース、デバッグ ・料金：無料プラン/有料プラン ・通知方法：メール、Webhook、Slack、PagerDuty等 ・データ保持期間：6週間
- 20. Zabbixとの違い ■ ZABBIX ・対象：クラウド/オンプレミス ・サーバ：必要 ・通知方法：メール（カスタムで多種の連携も可能） ・料金：サーバ費用 ・データ保持期間：特に制限なし（指定した分だけDBに蓄積） ■ Stackdriver ・対象：GCP / AWS ・サーバ：不要 ・料金：無料プラン/有料プラン ・通知方法：メール、Webhook、Slack、PagerDuty等 ・データ保持期間：6週間
- 21. image Webサイト監視サービス アプミル ● GCP 環境で構築 ● Webの外形監視のみのシンプル設定 ● エンジニア以外の利用を想定 ● URL設定だけで通信、コンテンツ、 セキュリティのチェックが行える https://appmill.work
- 22. GCP でのアプミルシステム構成 Cloud Storage Compute Engine Cloud Load Balancing Cloud SQL Cloud Datastore Cloud Pub/Sub Cloud Functions Logging Error Reporting Monitoring
- 24. Stackdriver でのアプミル監視設定 監視項目 間隔 閾値 CPU使用率 1分 平均90％以上 CPU LoadAverage 平均5以上 Memory使用率 平均90％以上 Swap使用率 平均20％以上 ディスク使用率 平均80％以上 DB接続数 1分当たりの平均100以上 OSログ 常時 syslog ミドルウェアログ Nginx アプリケーションログ プログラムエラーログ
- 25. 運用監視のポイント 1. 対応速度 2. コミュニケーション 3. 対応スキル 4. 情報共有
- 27. アラート内容のカスタマイズ ・素早い対応はアラート内容の工夫から ・メール文言のカスタマイズで障害箇所への 素早いアプローチ Alerting / Policies / Create / 3Documentation マークダウン方式
- 28. アラートノイズを減らす ・重要でないアラートが増える ⇒オペレーション担当者の疲弊 ⇒重要なアラートに気付かない ・まめなメンテナンス 閾値の変更 Alerting / Policies / Edit 時間の調整
- 34. 監視フローの作成
- 35. ４．情報共有 ・24時間365日は一人では見れない ・対応のばらつきをなくす ⇒ マニュアル化、訓練 ・アラートをためておく ⇒ 過去の事例の共有、検索 ・正確なデータを保つ ⇒ データのメンテナンス
- 36. アラートのレベル分け Aランク サービスが止まっている可能性が高いため最優先で対応 Bランク このまま放置しておくとサービスが止まる可能性が高いため優先的に対応 Cランク すぐにサービスに影響が出る可能性はないが対処が必要
- 37. アラート発生頻度を集計する 監視項目別 ランク 件数 割合 Ping監視 A 9 1% 37% ポート監視 A 152 18% URL監視 A 145 18% ロードアベレージ監視 B 6 1% 53% CPU監視 B 310 38% メモリ監視 B 4 1% プロセス監視 B 114 14% SWAP監視 C 35 4% 10% ディスク使用量監視 C 51 6% 合計 826 （2018/某月の実績）
- 38. 上位アラートの発生頻度 アラート別統計 A B C 総計 306 434 86 上位10件合計 82 204 0 割合（％） 26.7% 47.0% 0% （2018/某月の実績）
- 40. Copyright © 2007-2018 Beyond Co., Ltd. All Rights Reserved.confidential まとめ ● Stackdriver は運用管理者にとって非常に有用 ● 環境によって使い分けを ● アラート対応の工夫によってより良い運用を！