UDM Pro の応答が遅くなったり、通常よりも頻繁に再起動する必要がある場合は、メモリまたは CPU の使用率が高いことが根本的な原因である可能性があります。
どうして？
UniFi の組み込みツールでは、提供される可視性が限られているためです。
コントローラー ダッシュボードにはいくつかの基本的な統計情報が提供されますが、履歴データの保持やアラートの生成は行われず、速度低下が一時的なものか、それとも大きなパターンの一部なのかを判断するのにも役立ちません。
また、複数のサイトや顧客ネットワークをサポートしている場合、一元的な可視性やアラートがないと小さな問題が急速に拡大する可能性があるため、そのレベルの不確実性は管理できません。
この記事では、UDM Pro の CPU とメモリの使用状況をリアルタイムで監視し、それらのメトリックを解釈し、継続的な可視性とトラブルシューティングの迅速化のために外部監視を設定する方法について説明します。
メモリとCPUの使用率を監視せずにUDM Proを実行するのは、燃料計のない飛行機を飛ばすようなものです。燃料計は正常に動作しているように見えますが、それが故障するまでは正常に動作しません。これらの指標は、パフォーマンスの低下や完全な失速など、何か問題が発生した際に早期の兆候を示します。
メモリがいっぱいになったりCPU使用率が急上昇したりすると、 ディープパケットインスペクション（DPI）、IDS/IPS、またはUniFi Protectは、フリーズ、クラッシュ、または異常な動作をすることがあります。ユーザーから苦情が出たり、ネットワークが切断されたりするまで、すぐには気づかないかもしれません。
一般的な症状には次のようなものがあります:
UniFiの内蔵ダッシュボードにはこれらの機能の一部が表示されますが、機能には限界があります。履歴データもアラートも機能せず、時間の経過に伴う変化を簡単に追跡する方法もありません。
UniFiダッシュボードは基本的なCPUとメモリの使用状況を表示しますが、パフォーマンスインシデント発生時にはあまり役に立ちません。単一の時点のスナップショットを提供するだけです。そのため、一部のユーザーはUniFi APIを使用して可視性を拡張しようとします。
このアプローチはより詳細なデータを返すことができますが、大きなオーバーヘッドが発生します。各API呼び出しはUniFiコントローラーに直接アクセスするため、複数のデバイスを監視したり、頻繁にポーリングしたりするとパフォーマンスに影響する可能性があります。また、単一障害点（SPO）も発生し、コントローラーがオフラインになると監視が完全に停止します。
中には試す人もいる SNMPしかし、UDM ProのSNMPサポートは一貫性がありません。Ubiquitiの実装では、信頼性の高いメモリメトリクスを公開できないことが多く、CPUデータが断続的になったり、完全に欠落したりすることがあります。
タイムラインではなくスナップショットが表示されます。そのため、速度低下が偶然なのか、それともより大きな問題の始まりなのか、判断できません。
UDM Proに組み込まれている監視オプションは、一見すると十分です。しかし、履歴データ、プロアクティブなアラート、あるいはインフラ全体の一元的な可視性を求めるなら、それ以上の機能が必要になります。
そして、LogicMonitor はそれを実現します。
Ubiquiti が SNMP 経由でネイティブにデータを公開していなくても、UniFi デバイスの CPU とメモリの使用状況を追跡できます。
では、ここで LogicMonitor をどのように活用できるでしょうか?
拡張性を活用することで、セキュアシェル（SSH）経由で安全かつ軽量なスクリプトを実行できます。そのためには、以下の2つの方法があります。
スクリプトをスキップしてすぐに監視を開始したい場合は、 ロジックモニター交換 これを実行するための既製のモジュールが用意されています。必要な手順は次のとおりです。
これらのモジュールは、安全なSSH認証を使用して、UniFiデバイスからCPUとメモリのメトリクスを直接収集します。テスト済みでコミュニティによるサポートも受けており、ゼロから構築するよりもはるかに高速です。
DIYアプローチを好む場合や、データの収集方法をカスタマイズする必要がある場合は、Patrik Nordlundが開発したPowerShellベースの方法を使用できます。 リチューンAB.
Retune ABは、さまざまな ユビキタス 企業やブロードバンド環境向けの無線データ通信製品を含む、様々なデバイスが存在します。当然のことながら、チームはこれらのデバイスを監視スタックに組み込みたいと考えていました。
しかし、Ubiquiti の SNMP 実装では、デバイスの健全性を確認するための 2 つの重要な値である信頼性の高いリアルタイムの CPU またはメモリ メトリックが提供されないことがわかりました。
Retune ABのチームは、CPUとメモリの使用量が急上昇し、無期限に高い状態が続くというインシデントを複数回経験しました。リソースを解放するには、手動で再起動するしかありませんでした。
LogicMonitor アラートを構成することで、これらの状況を早期に検出し、ユーザーに影響が出る前に対処できるようになりました。
テスト中に、チームは他のUbiquitiユーザーがCPU使用率の平均（1分、5分、15分間隔）を示す非公式OIDを公開していることも発見しました。しかし、これらの値はRetune ABのデバイス間で一貫して動作しませんでした。メモリの可視性はさらに制限されており、公式のUBNT-Unifi-MIBにはCPUやメモリデータへの参照が全くありませんでした。
LogicMonitor の拡張性のおかげで、チームはコレクターから実行される PowerShell スクリプトを使用した実用的な回避策を見つけました。
あなたもこれを次のように実行できます:
$ username = "## unifi.sshuser ##" $ passwd = "## unifi.sshpassphrase.key ##" $ secpasswd = ConvertTo-SecureString $ passwd -AsPlainText -Force $ device = "## system.ips ##" $ keyFile = "Local_Disk_On_Collector \ privatekey_LM.key" $ creds = New-Object System.Management.Automation.PSCredential（$ username、$ secpasswd）＃デバイスへのSSHセッションNew-SSHSession -ComputerName $ device -Credential $ creds -Keyfile $ keyFile -AcceptKey | Out-Null＃CPU統計を取得$ cpuAll = Invoke-SSHCommand -index（Get-SSHSession -host $ device）.sessionid -Command "cat / proc / stat | grep '^ cpu'"＃セッションを削除Remove-SSHSession（Get- SSHSession -host $ device）| Out-Null＃CPU使用量を計算$ cpuArray = $ cpuAll.Output -split "+" $ cpuTotal =（[int] $ cpuArray [1]）+（[int] $ cpuArray [2]）+（[int] $ cpuArray [3]）+（[int] $ cpuArray [4]）+（[int] $ cpuArray [5]）+（[int] $ cpuArray [6]）+（[int] $ cpuArray [7]）+（ [int] $ cpuArray [8]）+（[int] $ cpuArray [9]）+（[int] $ cpuArray [10]）$ cpuIdle =（[int] $ cpuArray [4]）$ cpuUsage =（$ cpuTotal -$ cpuIdle）/ $ cpuTotal $ cpuUsedPercent = $ cpuUsage * 100 $ cpuPercent =（[int] $ cpuUsedPercent）書き込みホスト "CPUUsage = $ {cpuPercent}" Exit 0
$ username = "## unifi.sshuser ##" $ passwd = "## unifi.sshpassphrase.key ##" $ secpasswd = ConvertTo-SecureString $ passwd -AsPlainText -Force $ device = "## system.ips ##" $ keyFile = "Local_Disk_On_Collector \ privatekey_LM.key" $ creds = New-Object System.Management.Automation.PSCredential（$ username、$ secpasswd）＃デバイスへのSSHセッションNew-SSHSession -ComputerName $ device -Credential $ creds -Keyfile $ keyFile -AcceptKey | Out-Null＃メモリ統計の取得$ memAll = Invoke-SSHCommand -index（Get-SSHSession -host $ device）.sessionid -Command "free | grep'Mem： '"＃セッションの削除Remove-SSHSession（Get-SSHSession -host $デバイス）| Out-Null＃メモリ使用量を計算します$ memArray = $ memAll.Output -split "+" $ memTotal = $ memArray [1] $ memUsed = $ memArray [2] if（$ memTotal -eq "Mem："）{$ memTotal = $ memArray [2] $ memUsed = $ memArray [3]} $ memUsedPercent = [int]（（$ memUsed / $ memTotal）* 100）書き込みホスト "MemoryUsed = $ {memUsedPercent}" Exit 0
彼らのチームは、 Linux コマンドが機能しない場合は、特定のデバイスに合わせてスクリプトを調整する必要があるかもしれません。
これらのメトリクスは、UnifiコントローラーからAPI経由で取得できます。ただし、この場合、各デバイスがコントローラーに対してクエリを生成するため、データが大量に流入し、ネットワーク監視において単一障害点が発生します。
LogicMonitor のおかげで、Retune AB チームはビジネスに不可欠なものを監視できるようになり、Ubiquiti デバイスに関して受信するメトリクスに自信を持てるようになりました。
UDM Proが過熱し、CPUやメモリを常に消費している場合、それはあなただけではありません。これはUniFiフォーラムで最も話題になる問題の一つであり、当然のことです。放置すると、リソースの急増によってネットワークがスローダウンしたり、IDS/IPSやUniFi Protectなどのサービスが停止したりする可能性があります。
では、この急増の原因は何でしょうか?
多くの場合、メモリとCPUの使用率の高さはUniFi Protectに関連しています。UDM ProをネットワークゲートウェイとNVRの両方として使用している場合、特に高解像度のカメラフィードを使用すると、メモリ消費が急速に増加する可能性があります。
その他の一般的な要因は次のとおりです。
正常なものとそうでないもの
使用量には多少の変動が予想されます。一般的な目安は次のとおりです。
パフォーマンスを安定させるための手順
デバイスを再起動する前に、次の手順を試してください。
それでも問題が解決しない場合は、再起動すると通常は問題が解決します。ただし、これは症状を治療するものであり、原因を治療するものではありません。
状況が安定したら、可視性を維持することが重要です。LogicMonitorの履歴監視とアラート機能は、UniFiにはないコンテキストを提供します。継続的なデータ収集により、以下のことが可能になります。
これにより、同じ問題が再びネットワークに影響を及ぼすのを防ぐことができます。
UDM ProのメモリやCPU使用率が高いと感じているのは、あなただけではありません。しかし、スクリプトを実行したりアラートを設定したりする前に、ネットワークのワークロードに適したハードウェアを使用しているかどうかを検討してみる価値があります。
UniFi は、Dream Machine ラインナップのいくつかのバリエーションを提供しています。
似ているように見えるかもしれませんが、違います。それぞれに、高トラフィック、DPI、保護、全体的なリソース負荷の処理方法に影響を与える重要な違いがあります。
これらの違いが何であるかを見てみましょう。
UDM SE は、より多くのストレージやより高速なイーサネット ポートなど、内部がアップグレードされており、UDM Pro Max は、より優れた熱設計とより多くの RAM により、さらに性能が向上しています。
これらの違いは、各デバイスが負荷のかかる状況で監視、記録、およびパケット検査のタスクを処理する方法に直接影響を与える可能性があります。
標準の UDM Pro で CPU またはメモリを最大限に活用している場合は、SE または Max にアップグレードすると、パフォーマンスが向上し、スムーズに動作するために必要なアクティブ モニタリングの量が軽減される可能性があります。
どれがあなたにぴったりか見てみましょう:
リソース制限のトラブルシューティングを頻繁に行う場合は、設定の問題ではなく、ハードウェアの不一致が原因かもしれません。
UDM Pro のメモリ使用率が常に 90% になる場合は、セットアップの問題ではなく、ハードウェアを再検討する時期かもしれません。
| 機能 | UDMプロ | UDM SE | UDMプロマックス |
| RAM | 4 GB | 4 GB | 8 GB |
| CPU | クアッドコアARM | クアッドコアARM | クアッドコアARM（より高速なクロック） |
| Storage | なし（ユーザー追加） | 128 GB SSD（内蔵） | 128 GB SSD（内蔵） |
| 電源 | 内蔵電源ユニット | 内部電源 + PoE | より高ワット数のPSU |
| SFP +ポート | 1 x 10G | 1 x 10G | 2 x 10G |
| 熱設計 | 基本的な冷却 | 冷却の改善 | 空気の流れと熱処理の強化 |
| 理想的な使用例 | 自宅/小規模オフィス | 軽いビジネス用途 | 交通渋滞とカメラの負荷 |
UDM Proを再起動してようやく動作を確認できた経験があるなら、何も見ずに操作するのがいかに面倒かお分かりでしょう。ダッシュボードが不完全だったり、指標が欠けていたり、一貫性がなかったりと、 SNMP サポートが不足していると、常に追いつくのに追われているように感じてしまうことがあります。
だからこそ、多くのチームがLogicMonitorに注目しています。スクリプト、スクリーンショット、そして直感を駆使して作業する代わりに、UniFiデバイスとその他のインフラストラクチャを統合的に把握できます。
1 つの UDM Pro を実行している場合でも、クライアント サイト全体で数十を管理する場合でも、LogicMonitor は事後対応的な修正から事前対応的な可視性への移行を支援します。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
