New Relicを使ったPING監視の特徴

Transcript

1. New Relicを使ったPING監視の特徴 マネージドサービス部 塩野 正人 2024年04月24日
2. 目次 1. 自己紹介 2. 受賞した記事の紹介 3. 記事執筆に至った背景 4. 効果について
3. 自己紹介
4. 4 自己紹介 名前 塩野 正人（しおの まさと） 所属： 株式会社サーバーワークス マネージドサービス部 趣味 読書（ラノベ、小説）、音楽鑑賞、AI画像生成 かわいいネコ動画を見る 自分の興味範囲での知識の深堀り SNS X(旧Twitter)：@shioccii 保有資格 CAT5という超カッコいい、 「LANケーブルの曲」があるので、 もし興味があれば調べてみてください
5. 所属会社と業務内容の紹介
6. 6 東京の他、 大阪・仙台・福岡 現在はリモートワークを 基本として日本全国からお客 様をサポート 主な拠点 サーバーワークスは、AWSの専業クラウドインテグレーターです サーバーワークスについて 本社所在地 〒162-0824 東京都新宿区揚場町1-21 代表者 大石 良 設立 2000年2月21日 資本金 3,250,993,939円 従業員数 319名 (2024年2月末現在/役員除く) 事業内容 AWS専業のクラウドインテグレーター 営業所 大阪・仙台・福岡 資格等 AWS Premier Tier Services Partner AWS Managed Service Provider Partner AWS Migration Services Competency Partner ISO /IEC 27001（JIS Q 27001） 主な株主 弊社役員、株式会社テラスカイ エヌ・ティ・ティ・コミュニケーションズ株式会社、 株式会社エヌ・ティ・ティ・データ 関連会社 株式会社G-gen（東京都新宿区） 株式会社スカイ３６５（北海道札幌市） 株式会社トップゲート（東京都新宿区） エンジニア 営業・バックオフィス 関連会社
7. 7 ご提供サービス サーバーワークスマイスターズ AWS トータルソリューション サーバーワークスマイスターズ 請求代行に加え、内製化の支援や導入、監視・運用まで、ワンストップでお客様 のAWS活用をご支援するサービスです AWS請求代行サービス アドバンスドプラン ディスカウントプラン スタートアッププラン AWS 導入コンサルティング AWS構築・移行支援 内製化・トレーニング 特化ソリューション 導入支援 AWS運用代行・ 監視サービス AWS運用最適化サービス コスト削減 コンサルティング 保守 独自開発 Cloud Automator 自動化 請求代行・技術サポート 設計・構築・伴走支援 監視・運用・最適化 ジョブ・ポリシー管理 基本サービス ご要件・ご要望に応じてご選択可能 私の所属している部署 の業務概要
8. 8 お客様のご要望に柔軟に対応する AWS運用・サポート お客様 • 運用管理担当者様の登録 • AWS利用料金確認ページ での ご利用料金確認 • お問合せ窓口からの 各種ご依頼 サーバーワークス サポート体制 AWS請求代行サービスを軸に多様なサポートサービスをラインナップ AWSの運用においてはお客様の体制や要望によって選択ができるよう単純な技術サポートからSREのような担 当チームによるバックアップまでご用意しています サポートセンター 平日営業時間帯 • AWSの仕様に関するお問い合わせ • 上限緩和などの各種申請 • AWS請求代行サービスご契約やご利用 に関するお問い合わせ 24時間365日 • AWSの障害に関するお問い合わせ AWS技術サポート(AWS請求代行サービス) 24時間365日 • 死活/パフォーマンス監視 • バックアップ管理 • 障害対応（再起動、バックアップから のリストア） • 代行作業（弊社指定作業） AWS運用代行・監視サービス 貴社担当SEチーム • 貴社担当SEをアサイン • 貴社担当者と定期的なお打ち合わせ、 コミュニケーションツールを使った情報共有 • 監視・サポートチームと密に連携し 現状の運用状況を把握 • 運用改善提案、コスト最適化、日々の技術問 い合わせに対応 • 新しいサービスの情報展開 AWS運用最適化サービス • 上記CSMに加えて更に拡張し、実運用作業にま で踏み込んで実施し、お客様のAWS環境の安定 運用をチームで強力にバックアップします • 新しいサービスの情報展開 SRE(Site Reliability Engineering) 定形・標準対応中心 個別カスタマイズ サポート拡充 ご希望の場合 私の所属している部署 の実際の業務範囲
9. 受賞した記事の紹介
10. 10 受賞した記事の紹介 記事のタイトル New Relicを使ったPING監視の実情 記事概要 ネットワーク機器などを監視したい要件があり、 New Relicを使って PING（ICMP）死活監視 をどう実現できるかという内容 記事の中で選択可能な手段や設定方法などについて紹介 受賞記事URL https://blog.serverworks.co.jp/newrelic-ping-monitoring
11. 関連記事含めて簡単に記事のポイントをご紹介
12. 12 受賞した記事の紹介 New Relicを使ったPING（ICMP）監視の方法は大きく分けて下記の３つ Syntheticsを使ったPING監視 Flexを使ったPING監視 Private Minion(Ktranslate) を使ったPING監視 次のページ以降で、それぞれの特徴を見ていきましょう！ ※当ページ以降ではPING監視のことをICMP監視と記載しています
13. 13 受賞した記事の紹介 Syntheticsを使ったICMP監視の特徴について New Relicが管理しているSynthetics監視システム(Public minion)からの監視 Scripted API機能を使い、内部的にプログラムを動かすことで監視を実現 監視対象が多い、またはポーリング時間が短い環境の場合は、コストが高くなる可能性も パブリック環境のみ監視が可能 管理画面で死活監視以外の詳細な情報は見れない New Relic 監視対象 Public subnet Private subnet 監視対象 ICMP監視 プライベート 環境の監視は できない 参照元記事 https://blog.serverworks.co.jp/newrelic-ping-monitoring
14. 14 受賞した記事の紹介 Flexを使ったICMP監視の特徴について New Relicのドキュメントには設定方法の記載はないが、こうした形で無理やり監視することは可能 Infrastructure Agentがインストールされたホストでコマンドを実行して監視対象の状況を確認し、 実行結果をNew Relicサーバに送信することで監視を実現 管理画面で死活監視以外の詳細な情報は見れない New Relic Infrastructure Agentが インストールされたホスト Public subnet Private subnet 監視対象 ICMP監視 監視データ送信 設定ファイルに 書かれた監視用の コマンドを実行 参照元記事 https://blog.serverworks.co.jp/newrelic-icmp-ping-monitoring-using-flex
15. 15 受賞した記事の紹介 Private Minion(Ktranslate) を使ったICMP監視の特徴について New Relic推奨の設定で、ネットワーク監視専用のdockerコンテナからICMP監視を実施 死活監視以外の遅延情報といったメトリクスなども管理画面で確認できる 動作環境は、x86系64bit CPU、コアあたり2.5GiBのメモリ、ホストあたり50GiB以上のHDDが必要 設定ファイルはyaml形式だが、ドキュメントが少ないため、編集難易度は若干高め New Relic dockerがインストール されており、コンテナで ktranslateが動作している Public subnet Private subnet 監視対象 ICMP監視 監視データ送信 docker上の コンテナから 監視を実現 参照元記事 https://blog.serverworks.co.jp/newrelic-icmp-monitoring-with-ktranslate
16. 記事執筆に至った背景
17. 監視基盤の仕様による課題について
18. 18 監視基盤の仕様による課題について 弊社サービスのおさらい MSP（マネージドサービスプロバイダー）事業を展開しており、そのサービスの中の AWS運用代行・監視サービスでは、標準メニューとしてお客様にご提供している監視項目がある New Relicの動作特性上、弊社標準メニューではICMP死活監視は含まれていない 対象リソース 監視項目 EC2 CPU使用率 ： ： New Relic監視基盤 標準監視項目 対象リソース 監視項目 その他 ICMP死活監視 ： ： New Relic監視基盤 サービス提供対象外項目
19. 19 監視基盤の仕様による課題について Zabbix監視基盤とNew Relic監視基盤との動作特性の違い New Relic環境の場合は、クライアントからサーバに対して通信をおこなう仕様 弊社で運用しているZabbix環境の場合は、サーバ側からクライアント側に対して通信をおこなう仕様 New Relic環境 Zabbix環境 Zabbix Proxy 監視対象 監視対象 ※Zabbix設定がパッシブモードの場合
20. 20 監視基盤の仕様による課題について Zabbix監視基盤とNew Relic監視基盤との動作特性の違い Zabbix環境の場合は、途中で中継しているZabbix Proxyサーバから、 エージェントに対しての疎通、 監視対象に対してICMP死活監視 といった通信が可能 弊社Zabbix環境 Zabbix Proxy 監視対象 監視データ取得 エージェントへの通信 ICMP死活監視 ※Zabbix設定がパッシブモードの場合
21. 21 監視基盤の仕様による課題について Zabbix監視基盤とNew Relic監視基盤との動作特性の違い 弊社環境以外の一般企業様の場合は、社内にZabbixサーバを構築するケースも多く、 Zabbix Proxyを立てていないケースでも社内ネットワーク間の通信となるため、 Zabbixサーバ側の設定のみで容易にICMP監視ができるケースは多い Zabbix サーバー 監視対象 エージェントへの通信 ICMP死活監視
22. 22 監視基盤の仕様による課題について Zabbix監視基盤とNew Relic監視基盤との動作特性の違い New Relic環境の場合は、監視エージェントからサーバに向けて通信しているため、 そのままの環境でのICMP死活監視は不可能 途中に中継監視サーバを立てれば理論的にはICMP死活監視が可能 という状況のため、 New Relic環境 中継監視サーバ 監視対象 エージェントからの通信 ICMP死活監視 ※監視対象にNew Relic Infrastructure agentのインストールが必要 エージェントからの通信
23. 23 監視基盤の仕様による課題について Zabbix監視基盤とNew Relic監視基盤との動作特性の違い New Relic環境の場合は、監視エージェントからサーバに向けて通信しているため、 そのままの環境ではICMP死活監視は不可能 途中に中継監視サーバを立てれば理論的にはICMP死活監視が可能 New Relic環境 中継監視サーバ 監視対象 エージェントからの通信 ICMP死活監視 ※Zabbix設定がパッシブモードの場合 エージェントからの通信 ・インターネットに通信ができれば、 中継サーバは監視要件として必須ではない ・標準で中継サーバを立てる構成だと リソースの無駄遣いになる ・上記より、標準的な仕様に含める理由がない ため、ICMP死活監視は標準監視の対象外
24. 顧客側の課題について
25. 25 顧客側の課題について 顧客側がかかえている課題 慢性的な人材不足 エンドユーザーから様々な依頼がある中で、検証や新技術のキャッチアップに時間が割けない そのため、定型的な監視をアウトソースして、サーバ運用保守費用のコストダウンや、 自分たちがより注力したい課題に取り組みたいという要望 Zabbix 監視対象 管理部門 エンドユーザー 監視設定 既存の監視運用含めて アウトソースしたい
26. 管理運用上の課題について
27. 27 管理運用上の課題 弊社側の運用面での課題 ICMP監視だけ既存のZabbix環境で実施した場合、 監視項目毎に管理画面が分かれてしまう 障害発生時の対応遅れやミスにつながりやすい 情報管理の観点でも混乱につながる可能性が高い ICMP死活監視のためだけにZabbixサーバを運用するのは効率が悪い Zabbix画面 （ICMP死活監視） New Relic画面 （ICMP死活監視以外）
28. 効果について
29. 29 課題解決による効果 プロジェクトの関係で実際の監視導入は未だ 監視標準化により、横展開がしやすくなった New Relicに情報を集約することにより、情報管理が楽になったことや、 複数画面を開かなくてよいなどの観点で、弊社側の管理工数が削減される見込み