みなさんこんにちは。マネージドサービス課の塩野です。
前回までの記事で、New Relicのネットワーク監視における考え方とメトリクスの読み方を解説してきました。最終回となる今回は、実際の運用でどう活用するか、効果的な監視戦略をどう設計するかを見ていきましょう。すべてのデバイス、すべてのインターフェースを同じ優先度で監視するのは現実的ではなく、本筋ではビジネスへの影響度に基づいて、監視を設計していくといいでしょう。
目次
監視の優先順位を設計する
クリティカルパスを特定する
ネットワーク監視で最初にやるべきことは、「どこが重要か」を明確にすることです。
考えるべき3つの質問
まず、ビジネスクリティカルなアプリケーションはどこにホストされているか？を考えます。売上に直結するECサイト、顧客データベース、基幹システムなど、止まったら困るアプリケーションを洗い出します。
次に、そのアプリケーションへのネットワーク経路は？を確認します。ユーザーからアプリケーションまで、どのルーター、どのスイッチを経由するかを把握します。
最後に、単一障害点（SPOF: Single Point of Failure）はどこか？を特定します。ここが止まったら全体が止まる、という箇所を見つけます。
命名規則を活用する
New Relicの公式アラート条件では、「uplink」を含むインターフェースをデフォルトの監視対象としています。これは、命名規則を活用した良い例だと思います。これはひとつの例ですが、自組織の命名規則に合わせてこのようなキーワードを使ったフィルタリングを考えてみてはいかがでしょうか。
今回はこの例を参考に仕組みを考えてみましょう。「uplink」は上位へのリンク、「core」はコアネットワーク、「critical」はクリティカルなリンク、「production」は本番環境を示します。
例えば、NRQLクエリではこのような感じで表現ができます。
FROM Metric SELECT average(kentik.snmp.IfInUtilization) WHERE if_Descr LIKE '%uplink%' FACET device_name, if_Descr
これで、uplinkという名前が付いたインターフェースだけを抽出できます。
冗長構成を理解する
冗長化されている経路と、されていない経路では、アラートの設定を変える必要があるかもしれません。例えば、冗長化されている経路の場合、1系統がダウンしたらWarning、両系統がダウンしたらCriticalと定義する方法もあります。片方が落ちても通信は継続できるので即座の対応は不要かもしれませんが、放置すると確実に記憶の彼方に忘れさられて後で大きな問題になるので、こうした障害は早めに復旧すべきです。
非冗長の経路の場合、ダウンしたらもちろん即Criticalです。代替経路がないので、即座の対応が必要でしょう。
デバイスタイプ別の監視ポイント
デバイスの役割によって、監視すべきポイントと優先度が異なります。
コアルーター
コアルーターは、全トラフィックが通過する最重要デバイスです。最重要監視項目は、可用性、CPU、メモリ、主要インターフェースです。理由は、全トラフィックが通過し、影響範囲が最大だからです。アラート設定は、最も厳しいしきい値を適用します。
例えば、CPU使用率は70%でWarning、85%でCriticalといった設定にします。
ディストリビューションスイッチ
ディストリビューションスイッチは、複数のアクセススイッチを集約する役割です。重要監視項目は、アップリンクポート、CPU、主要なVLANです。理由は、複数のアクセススイッチを集約しているからです。アラート設定は、中程度の優先度にします。
CPU使用率は80%でWarning、90%でCriticalといった設定が一般的です。
アクセススイッチ
アクセススイッチは、エンドユーザーのPCやサーバーが接続されるデバイスです。監視項目は、アップリンクポートの帯域と状態です。理由は、個別の影響範囲は小さいですが、数が多いからです。アラート設定は、グループでの監視にして、個別の詳細度は低めにします。
例えば、10台のアクセススイッチのうち、3台以上でアップリンクの使用率が80%を超えたらアラート、といった設定にします。
ファイアウォール
ファイアウォールは、セキュリティとパフォーマンスの両立が必要なデバイスです。最重要監視項目は、CPU、セッション数、スループット、ポリシーヒット数です。理由は、セキュリティに関わる指標だからです。アラート設定は、セキュリティに関わる指標は厳しくします。
セッション数が上限の80%に達したら即座にアラート、といった設定が必要です。
エンティティヘルスステータスを活用する
New Relicでは、各ネットワークデバイスがカラーコードされたヘルスステータスで表示されます。これを戦略的に活用しましょう。
カラーコードの意味を理解する
緑は、すべてのアラート条件をクリアしていて、正常稼働している状態です。
黄色（Warning）は、問題の予兆があり、計画的対応が可能な状態です。今すぐ止まるわけではないけど、近いうちに対応が必要です。
赤（Critical）は、即座の対応が必要で、ビジネスへの影響がある状態です。すぐに対応しないと、サービスに影響が出ます。
グレーは、アラート条件が未設定、またはシグナルが不安定な状態です。これが一番危険かもしれません。
グレーを放置しない
グレーのエンティティは「何も監視していない」ことを意味します。これは監視の盲点であり、オブザーバビリティの欠如を示しています。対応策としては、定期的にグレーのエンティティを特定し、そのデバイスに適切なアラート条件を追加します。または、監視対象外であることを明確にドキュメント化します。
例えば、週次でこんなクエリを実行して、グレーのエンティティを確認します。
FROM Metric SELECT uniques(device_name) WHERE instrumentation.provider = 'kentik' SINCE 1 week ago
これで、過去1週間にデータを送信したデバイスのリストが取得できます。New Relic UIでグレー表示されているデバイスがあれば、アラート条件を追加します。
ビューを戦略的に設計する
New Relicでは、保存したビューでエンティティをグループ化できます。これを活用して、目的に応じたビューを作成しましょう。
推奨ビューの例
すべてのデバイスを一つのビューで見るのではなく、目的に応じたビューを複数作成します。
ロケーション別ビュー
「東京データセンター」「大阪データセンター」「AWS環境」といった、物理的または論理的なロケーション別にビューを作成します。これにより、特定のロケーションで問題が発生しているかを一目で確認できます。
役割別ビュー
「コアネットワーク」「ディストリビューション層」「アクセス層」「セキュリティデバイス」といった、役割別にビューを作成します。これにより、ネットワークのどの層で問題が発生しているかを素早く特定できます。
クリティカリティ別ビュー
「Tier1（最重要）」「Tier2（重要）」「Tier3（通常）」といった、ビジネスへの影響度別にビューを作成します。これにより、優先的に対応すべきデバイスを明確にできます。
ビューの活用方法
朝の確認では、すべてのビューをざっと確認して、赤や黄色のエンティティがないかチェックします。障害発生時には、該当するロケーションや役割のビューを開いて、影響範囲を確認します。
定期レビューでは、グレーのエンティティが増えていないか、黄色が長期間続いているエンティティがないかを確認します。
アラート設計の実践
効果的なアラート設計は、誤検知を減らしつつ、重要な問題を見逃さないバランスが重要です。
しきい値の設定方法
静的しきい値 vs 動的しきい値
静的しきい値は、「CPU使用率が80%を超えたらアラート」といった固定値です。シンプルでわかりやすいですが、正常なパターンでもアラートが出ることがあります。動的しきい値（ベースライン）は、過去のパターンから正常範囲を学習し、そこから逸脱したらアラートを出します。誤検知が少ないですが、設定が複雑です。
推奨としては、まず静的しきい値で始めて、誤検知が多い項目は動的しきい値に切り替えるのが良いでしょう。
段階的なアラート
いきなりCriticalアラートを出すのではなく、WarningとCriticalの2段階にします。例えば、帯域使用率の場合、70%でWarning（計画的な対応が可能）、85%でCritical（即座の対応が必要）といった設定にします。これにより、問題が大きくなる前に対応できます。
アラート疲れを防ぐ
アラートが多すぎると、重要なアラートを見逃してしまいます。
ノイズの多いアラートを特定する
定期的に、どのアラートが頻繁に発火しているかを確認します。
SELECT count(*) FROM `NrAiIncident` SINCE 1 month ago FACET policyName,conditionName
頻繁に発火しているアラートは、しきい値が厳しすぎるか、そもそも監視する必要がない項目かもしれません。
アラートの統合
複数の関連するアラートを統合して、一つの通知にまとめます。例えば、同じデバイスの複数のインターフェースで帯域使用率が高い場合、個別にアラートを出すのではなく、「デバイスXで複数のインターフェースに問題」という一つのアラートにします。
メンテナンスウィンドウの活用
計画的なメンテナンス中は、アラートを一時的に停止します。New Relicのミュート機能を使って、特定の時間帯やデバイスのアラートを抑制できます。
ダッシュボードの効果的な活用
最後に、ダッシュボードの設計について見ていきましょう。
階層的なダッシュボード設計
ダッシュボードは、詳細度に応じて階層的に設計します。
レベル1：エグゼクティブダッシュボード
経営層向けの高レベルな情報を表示します。全体のヘルスステータス（緑/黄/赤の割合）、過去24時間のインシデント数、主要なSLA指標（可用性など）を表示します。
レベル2：オペレーションダッシュボード
運用チーム向けの詳細情報を表示します。デバイスタイプ別のヘルスステータス、帯域使用率トップ10、CPU使用率トップ10、最近のアラート一覧を表示します。
レベル3：デバイス詳細ダッシュボード
特定のデバイスの詳細情報を表示します。すべてのインターフェースの状態と使用率、CPU/メモリの時系列グラフ、エラー数の推移、最近のSyslogメッセージを表示します。
実用的なウィジェット例
ネットワーク全体のヘルスマップ
FROM Metric FROM Metric SELECT histogram(kentik.snmp.IfInUtilization) WHERE if_interface_name LIKE '%uplink%' FACET device_name, if_Desc
これをヒートマップで表示すると、どのデバイスのどのインターフェースが高負荷かが一目でわかります。
※画像は作成イメージの例です。
帯域使用率トップ10
FROM Metric SELECT average(kentik.snmp.IfInUtilization) WHERE if_Desc_name LIKE '%uplink%' FACET device_name, if_Desc LIMIT 10
これをバーチャートで表示すると、ボトルネックになりそうなインターフェースが見つかります。
※画像は作成イメージの例です。
エラー率の推移
FROM Metric SELECT rate(sum(kentik.snmp.ifInErrors), 1 minute) WHERE device_name = 'core-router-01' TIMESERIES AUTO
これをラインチャートで表示すると、エラーが増加傾向にあるかがわかります。
継続的な改善
ネットワーク監視は、一度設定したら終わりではありません。継続的に改善していく必要があります。
定期的なレビュー
月次で、以下の項目をレビューします。アラートの発火頻度を確認し、誤検知が多いアラートを調整します。グレーのエンティティを確認し、アラート条件を追加します。しきい値が適切か確認し、必要に応じて調整します。
ドキュメント化
監視設計の意図をドキュメント化しておきます。なぜこのしきい値にしたのか、どのデバイスが重要なのか、アラートが出たときの対応手順はどうするのか、といった情報を残しておきます。
これにより、担当者が変わっても、監視の意図が引き継がれます。
フィードバックループ
実際にインシデントが発生したら、それを監視設計にフィードバックします。検知できなかった問題があれば、新しいアラート条件を追加します。誤検知だったアラートがあれば、しきい値を調整します。
まとめ
3回にわたって、New Relicのネットワーク監視について解説してきました。
第1回では、オブザーバビリティの考え方と、扱うデータの種類をお伝えしました。第2回では、メトリクスの読み方と、実践的な設定のコツを解説しました。そして今回は、監視の優先順位設計と、効果的な運用戦略について取り上げてみました。重要なのは、すべてを同じように監視するのではなく、ビジネスへの影響度に基づいて優先順位をつけること。デバイスの役割に応じて、監視項目としきい値は調整が必要でしょう。また、エンティティのヘルスステータスとビューを活用して、問題を素早く特定することも重要です。たくさんのアラートによる疲弊を防ぐために、ノイズの多いアラートは継続的に見直して改善する必要があります。
New Relicを含めたオブザーバビリティのあるネットワーク監視とは、単なるメトリクス収集ツールとして使用するのではなく、その使い方によって真のオブザーバビリティが実現できるものと信じています。この記事で紹介した考え方や実践方法を活用して、効果的なネットワーク監視をお試し頂ければと思います。
こちらの記事がどなたかのお役に立てれば幸いです。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。
関連記事
blog.serverworks.co.jp blog.serverworks.co.jp
◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X（Twitter）：@shioccii
◆ 過去記事はこちら
前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。
