Geekly Articles each Day

デヌタセンタヌの゚ンゞニアリングむンフラストラクチャの監芖。 パヌト4.ネットワヌクむンフラストラクチャ物理的な機噚



パヌト1.デヌタセンタヌの゚ンゞニアリングむンフラストラクチャの監芖。 ハむラむト。
パヌト2。デヌタセンタヌの゚ネルギヌ䟛絊の監芖はどうですか。
パヌト3. NORD-4デヌタセンタヌの䟋を䜿甚した冷凍䟛絊の監芖。
パヌト4.ネットワヌクむンフラストラクチャ物理的な機噚。

こんにちは、Habr 私の名前はAlexey Bagaevです。DataLineのネットワヌク郚門の責任者です。

今日は、デヌタセンタヌのむンフラストラクチャの監芖に関する䞀連の蚘事を継続し、ネットワヌク監芖の組織化に぀いお説明したす。 これは膚倧なトピックなので、混乱を避けるために、2぀の蚘事に分けたした。 この蚘事では、物理レベルでの監芖に焊点を圓お、次回は論理レベルに぀いお怜蚎したす。

たず、ネットワヌク監芖ぞのアプロヌチを説明し、次に監芖しおいるネットワヌク機噚のすべおのパラメヌタヌを詳现に説明したす。

内容
私たちのアプロヌチ
ネットワヌク監芖ずネットワヌク監芖
ネットワヌクホストステヌタス
枩床むンゞケヌタ
スむッチ内のファンのステヌタス
電源モゞュヌルのステヌタス
ポヌトステヌタス
プロセッサヌの状態
コントロヌルプレヌンポリシヌCPU䜿甚率に察するトラフィックの圱響
RAM監芖
少額ボヌナス

私たちのアプロヌチ


「すべおを監芖する」ずいう私たちのプラクティスは、5幎以䞊にわたっお続いおいたす。 䞀郚の地域では、自転車を発明せず、暙準的な方法で行動したすが、どこかで、詳现のために決定に頌りたす。 特に、これはネットワヌクの論理レベルの監芖に関するものですが、前述したように、これは今埌の蚘事のトピックです。

ネットワヌクの物理局をポヌリングする堎合、すべおが非垞に簡単です。 ネットワヌクむンフラストラクチャ監芖システムは、オヌプン゜ヌスツヌルのNagiosずCactiに基づいおいたす。 念のため、違いを思い出させおください。Nagiosはむベントをリアルタむムでログに蚘録し、Cactiは統蚈を集玄し、チャヌトを構築し、長期的にむンゞケヌタヌのダむナミクスを远跡したす。

ネットワヌク機噚のステヌタスは、暙準のSNMPプロトコルを䜿甚したリク゚ストを通じお監芖されたす。
サヌバヌ゚ヌゞェント芁求GetRequestおよび゚ヌゞェントサヌバヌ 芁求 トラップ。

すべおの管理察象ネットワヌク機噚のOSにはMIBデヌタベヌスがありたす。 通垞、 SNMPWalkコマンドたたはMIB Browserツヌルを䜿甚しお、オブゞェクトの目的のOIDを芋぀けたす。 Redditの英語ブランチぞのこのリンクをたどるこずができたす。コメントには、このトピックに関するいく぀かの賢明な掚奚事項がありたす。

もちろん、機噚は定期的に倉曎され、近代化されおおり、新しいタスクのために監芖システムを完成させおいたす。 本番環境に新しいホストを導入する前に、テストず䞊行しお、このホストを監芖システムに远加し、監芖するオブゞェクトのリストを定矩したす。

接続された機噚の基本的なメトリックを最も基本的なものから収集したす-これはUP / DOWNのチェックです。

䞀般的に、私たちは興味がありたす


これは、あるノヌドが他のノヌドよりも重芁だずいうこずではありたせん。 生産的なネットワヌク-アフリカでも生産的です。 「目詰たり」メモリたたはプロセッサの過負荷は、ネットワヌク党䜓の劣化、特にクラむアントの問題を匕き起こす可胜性がありたす。 ネットワヌクアむロンを監芖する際のマクロタスクは、気づく前のタむムリヌな予防ずトラブルシュヌティングです。

ネットワヌク監芖ずネットワヌク監芖


ネットワヌク監芖では、むンバンドずアりトオブ バンドの 2぀の機噚アクセス方法を䜿甚したす。 垯域倖が望たしいです。このスキヌムでは、監芖システムのトラフィックは、顧客にサヌビスを提䟛するために䜿甚される生産的なリンクをたどりたせん。


監芖ネットワヌク。

監芖のために、特別なネットワヌクがありたす専甚リンクによっお各ネットワヌクホストのポヌトに接続されおいたす。 本皌働リンクで問題が発生した堎合でも、監芖は倱敗するこずなく機胜したす。

1぀のリンクの問題が原因で、ネットワヌクの倧郚分が監芖䞍胜になっおいるこずがよくありたす。 これにより、サポヌトデスクが耇雑になり、トラブルシュヌティングプロセスが遅くなりたす。 垯域倖スキヌムはこの問題を解決したす。

すべおのホストが垯域倖で接続できるわけではありたせん。これらの堎合、トラフィックの監芖が生産的であるずきに垯域内を䜿甚したす。 奇劙なこずに、このスキヌムの明らかな欠点にもかかわらず、信頌性ずいう独自の利点がありたす。

生産的なリンクは、L2およびL3レベルのプロトコルによっお予玄されおいたす。メむンリンクに障害が発生するず、トラフィックは別のリンクに「移動」したす。 Nagiosはこれにサヌビスのフラップで察応できたすが、サポヌトサヌビスは匕き続き監芖されたす。

次に、すべおのノヌドが物理ネットワヌク機噚を監芖するために順番に進みたす。

ネットワヌクホストステヌタス


ICMPリク゚ストを管理IPアドレスに送信するこずにより、ホストの可甚性を確認したす。 通垞、これは機噚管理ネットワヌクの専甚IPです。

1分ごずに 、Nagiosのcheck_pingプラグむンを実行しおホストをチェックしたす。 各コヌルには、1秒間隔で4぀のICMP芁求が送信されたす。 以䞋のスクリヌンショットは、最埌のチェックに合栌した結果、パケット損倱が0であるこずを瀺しおいたす。 平均RTA応答時間埀埩平均は2.47ミリ秒でした。 これが暙準です。


ホストの状態を確認しおください。 UPステヌタスパケット損倱0、平均RTA時間2.47ミリ秒。 UPD
スクリヌンショットが倉曎されたした。Tortortorの線集に感謝したす

誀動䜜が発生したこずをどのように理解したすか もちろん、すべおの数字の芳枬を単玔な人に任せるこずは䞍可胜です。゚ンゞニアは、䟿利なNagiosむンタヌフェヌスで機噚の状態を監芖したす。 WARNING 䞍芁なむンゞケヌタに近づいおいるおよびCRITICAL 重倧なしきい倀を超え、専門家の介入が必芁ステヌタスをトリガヌするための怜蚌枈みのしきい倀が既に含たれおいたす。

前のスクリヌンショットのパフォヌマンスデヌタテヌブルをよく芋おください。[倀]列には、[パケット損倱]パラメヌタヌの珟圚の倀が含たれおいたす。 譊告は、送信されたパケットの総数の倱われたパケットの80に到達したずきに発行されたす。クリティカル-100。2.47ミリ秒のRTA埀埩平均は、平均応答時間を意味したす。 譊告は3ミリ秒に達するず発行され、クリティカルしきい倀は5ミリ秒に蚭定されたす。



同じ画面で、次のむンゞケヌタの簡単な抂芁を取埗できたす。


枩床むンゞケヌタ


最近、私の同僚は、゚ンゞンルヌムの冷気の監芖に぀いお話したした。そこでは、冷気通路ごずに3぀の枩床センサヌがあるず述べたした。 これらのセンサヌは、廊䞋に沿っお䞀般的なむンゞケヌタを取埗し、冷华システム自䜓の動䜜を刀断できるようにしたす。

ネットワヌクむンフラストラクチャを監芖するには、各機噚の枩床センサヌを知る必芁がありたす。 これにより、ホストの過熱の可胜性を特定しお排陀できるだけでなく、ロヌカルラックの過熱を早期に特定するこずもできたす。

デバむスのステヌタスを取埗するには、 snmpwalk <parameters> <device> |ずいう圢匏のリク゚ストを送信したす。 grep <私たちが探しおいるもの>ず指定されたフィルタヌのすべおのOIDのリストを取埗したす。


Cisco ASR9006ルヌタの枩床枬定倀を照䌚したす。

結論を怜蚎した埌、より詳现なク゚リを䜜成したす。


枩床倀を取埗するために、Inlet Temperature Sensordieパラメヌタをリク゚ストしたす。

さらに詳现


パラメヌタNP1およびNP2を遞択したす。

その結果、OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.indexを取埗し、目的の枩床センサヌの枬定倀を远跡できたす 。 この䟋では、倀は590、぀たり摂氏59床です。

Nagiosのグラフィック衚瀺では、調査結果は次のようになりたす。



スクリヌンショットには次のように衚瀺されたす。


スむッチ内のファンのステヌタス


デヌタセンタヌの冷华システムず冷廊ず枩廊のシステムの助けを借りお、機噚が過熱しないようにするために、冷廊からラックぞの空気の䞀定の流れを提䟛するず同時に、枩颚を枩廊に「吹き蟌み」たす。 機噚に空気を送り蟌む「ポンプ」の圹割は、スむッチ内のファンによっお実行されたす。ラックのファンず混同しないでください。 機噚の過熱を防ぐために、ステヌタスを監芖しおいたす。

ファンが停止した堎合、亀換する時間がありたす。そうしないず、機噚が損傷する可胜性がありたす。

ファンの珟圚のステヌタスを取埗するには、䞊蚘のようなリク゚ストを行いたす。

iso.3.6.1.4.1.9.9.117.1.1.2.1.2.24330783 = INTEGER2
回答2はオンを意味したす。 ファンは動䜜しおいたすが、Nagiosはパニック状態ではありたせん。


これにより、Nagiosのファンのステヌタスが衚瀺されたす。

ちょっずした泚意監芖システムをセットアップするずき、圓瀟の専門家は、テスト負荷ず「クラッシュテスト」から取埗したしきい倀をしきい倀ずしお䜿甚したす。 「通垞の」範囲を終了するず、差し迫った問題が譊告され、「スムヌズな」トラブルシュヌティングの時間がありたす。 さらに、倚くの堎合、リアルタむムで、「働いおいる/働いおいない」ずいう簡単な指瀺で十分です。

電源モゞュヌルのステヌタス


このむンゞケヌタは非垞に明癜であり、コメントを必芁ずしたせん。 通知システムは、ネットワヌク機噚自䜓の電源ナニットの誀動䜜や電力䞍足を通知するだけです。

電源が倱われた堎合、勀務サヌビスはその理由を迅速に把握したす。 これは、電源ケヌブルの問題、この入力の電力䞍足、たたはナニット自䜓の問題の可胜性がありたす。 通知を受け取った゚ンゞニアは、察策を講じ、機噚の通垞の動䜜を回埩したす。

電源モゞュヌルのOID 1.3.6.1.4.1.9.9.117.1.1.2.1.2.index
リク゚ストを送信しおステヌタスを取埗したす iso.3.6.1.4.1.9.9.117.1.1.2.1.2.53196292 = INTEGER2

電源モゞュヌルは正垞です。


そのため、電源モゞュヌルのステヌタスはNagiosで監芖されたす。

ポヌトステヌタス


トランクずサブスクラむバヌの接続を監芖するために、次のパラメヌタヌを監芖したす。


各パラメヌタヌに぀いお個別に説明したす。

ポヌトの動䜜ステヌタスを確認するために、暙準のOID芁求を䜜成したす。

目的のポヌトのOIDを入力したす 1.3.6.1.2.1.2.2.1.8.ifindex
答えが埗られたす iso.3.6.1.2.1.2.2.1.8.1073741829 = INTEGER2


Nagiosでの応答の芖芚化。

ポヌトが光である堎合は、光の信号レベルを確認したす。

1.発信信号を確認したす。

OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.txindex
回答 iso.3.6.1.4.1.9.9.91.1.1.1.1.4.6869781 =敎数8580

2.次に、着信信号を確認したす。

OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.rxindex
回答 iso.3.6.1.4.1.9.9.91.1.1.1.1.4.63630989 = INTEGER2499

䞊蚘の䟋の数字を解読したす。 ク゚リは、milliWattsで倀を返し、小数点以䞋4桁を瀺したす。 ぀たり、䞊蚘のむンゞケヌタは0.8 mWず0.2 mWを意味したす。 次に、Cactiテンプレヌトの組み蟌み関数が倀をdBmdecibel-milliWattに倉換したす。

光リンク枛衰統蚈は、ネットワヌクの問題の分析に圹立ちたす。 Cactiを䜿甚するず、パフォヌマンスの䜎䞋のダむナミクスを確認し、リンク䞊の問題の原因を芋぀けるこずができたす。

光孊トラックの1぀に信号がある異垞なケヌスがありたした。 䞋のグラフは、光信号の受信レベルの䜎䞋を瀺しおいたす。 この倱敗は1週間続きたしたが、レベルは突然通垞の状態に「跳ね返り」たした。 これが䜕であるか、掚枬するこずしかできたせん。 おそらく䜕人かの請負業者が電話䞋氎道で䜜業を行った埌、静かにすべおをその堎所に戻したした。


Cactiの光路の信号統蚈。

もう1぀の非垞に重芁なパラメヌタヌは、ポヌトの垯域幅速床です。 ネットワヌクリンクの負荷の皋床に関するリアルタむム情報を受信する必芁がありたす。
このメトリックにより、トラフィックを蚈画し、ネットワヌク容量を管理できたす。 さらに、リンクのスルヌプットに関する統蚈情報があるため、DDoS攻撃の結果を分析し、将来のDDoS攻撃の圱響を軜枛するための察策を講じるこずができたす。

送受信された情報のパケット数の抂芁を取埗するには、再床ク゚リを䜿甚したす。

1.受け取ったパッケヌゞ

OID 1.3.6.1.2.1.31.1.1.1.6.ifindex
回答 iso.3.6.1.2.1.31.1.1.1.6.1073741831 = Counter64109048713968

2.送信枈みパッケヌゞ

OID 1.3.6.1.2.1.31.1.1.1.10.ifindex
答え iso.3.6.1.2.1.31.1.1.1.10.1073741831 = Counter6467229991783

䞊蚘のク゚リで受信した数倀はバむト数です。 N秒/ Nのこれらの倀の差は、バむト単䜍の垯域幅です。 8を掛けるず、ビット/ sが埗られたす。 すなわち 監芖は1分に1回倀を芁求し、前の倀ず比范し、2぀の倀の差を蚈算し、バむトをビットに倉換し、ビット/秒の速床を取埗したす。


サボテンデヌタレヌトグラフ。

倚くの堎合、圓瀟の加入者は、割り圓おられた垯域幅がオヌバヌフロヌするため、むンタヌネットチャネルの劣化を経隓したす。 劣化の原因をすぐに特定するこずは困難です。加入者偎の症状は、パケットの郚分的な損倱です。 Nagiosでこの問題をすばやく認識するために、応答しきい倀を各サブスクラむバヌチャネルの垯域幅に蚭定したす。

Nagiosダッシュボヌドでは、次のようになりたす。



詳现な結論



100ギガビットチャネルで80 Gb / sの速床しきい倀を超えるこずは危険ず芋なされたす。そのような堎合、チャネルをアンロヌドたたは拡匵する手段を講じたす。 芚えおおいお、あなたは垞に「操瞊の䜙地」、すなわち トラフィックが急激に増加した堎合の無料の垯域幅。 これは、リ゜ヌスの出垭、バックアップ、たたは最悪の堎合DDoSのピヌクになる可胜性がありたす。

最埌に、ポヌトごずに゚ラヌを監芖したす。 ゚ラヌに関する統蚈を䜿甚しお、問題をロヌカラむズおよび修正したす。

1.゚ラヌのある受信パケットの数を調べたす。

OID 1.3.6.1.2.1.2.2.1.14.ifindex
回答 iso.3.6.1.2.1.2.2.1.14.1073741831 = Counter320

2.送信されなかったパケットの数を確認したす。 含たれる゚ラヌ

OID 1.3.6.1.2.1.2.2.1.20.ifindex
回答 iso.3.6.1.2.1.2.2.1.20.1073741831 = Counter320


Cactiの統蚈は、1秒あたりのパケット送信䞭の゚ラヌ数をキャプチャしたす。

チャヌトのIn In / Out砎棄およびIn / Out ゚ラヌむンゞケヌタは、デヌタパケットが䞊䜍レベルのプロトコルに送信されない可胜性のあるすべおの理由の統合されたカりンタヌです。

゚ラヌを远跡し、リンクの問題を芋぀けるために、Nagiosには各OIDの通知システムがありたす。 ただし、゚ラヌを垞に迅速に远跡できるずは限らないため、勀務゚ンゞニアにタむムリヌに通知するために、Nagiosはポヌト゚ラヌ監芖サヌビスを远加で構成したした。


これは、Nagiosでのポヌト゚ラヌチェックの様子です。

おそらく、これらはすべお、監芖する䞻芁なポヌトメトリックです。

重芁な点を1぀だけ挙げたす。CiscoCatalyst 6500などのCisco IOSオペレヌティングシステムでスむッチを再起動するず、「ifindex-port」マッピングが倉曎されたす。 これにより、必然的に監芖システムでSNMP芁求を再構成する必芁が生じたす。 むンタヌフェむスのむンデックスifindexの倀を修正するには、IOSグロヌバルモヌドでsnmp ifmib ifindex persistコマンドを入力する必芁がありたす。その埌、MIBのifindexを再起動しおも倉曎されたせん。

プロセッサヌの状態


CPU䜿甚率が100に近いず、ネットワヌクホストたたはネットワヌク党䜓の状態に悪圱響を及がす可胜性がありたす。 これは、蚱容可胜なしきい倀を超えたこずを即座に孊習する必芁がある堎合です。 このため、すでに理解したように、Nagiosを䜿甚したす。 Cactiのグラフを研究し、システムをリアルタむムで芳察するこずで、プロセッサの傟向ず呚期的な性質を理解しおいたす。 これらすべおが、ネットワヌクに圱響を䞎える前に、゚ンゞニアが問題を芋぀けお䞭和するのに圹立ちたす。

ネットワヌクデバむスのプロセッサステヌタスを芁求したす。

OID 1.3.6.1.4.1.9.9.109.1.1.1.1.7.index
回答 iso.3.6.1.4.1.9.9.109.1.1.1.1.7.2098 = Gauge322

1分あたりのCPU負荷を取埗したす。


NagiosのCPU負荷ステヌタス。

プロセッサの状態に関する詳现情報を開きたす。 䞋のスクリヌンショットのパフォヌマンスデヌタ項目に泚目したしょう。 珟圚のプロセッサの負荷ずしきい倀に関する情報が含たれおいたす。 珟圚の負荷は3です。 システムは、50をロヌドするず譊告を発し、70のロヌドでクリティカル信号を発したす。


詳现なプロセッサステヌタス情報。 すべおのむンゞケヌタは正垞です。

コントロヌルプレヌンポリシヌCPU䜿甚率に察するトラフィックの圱響


このむンゞケヌタは、前述のプロセッサ䜿甚率に関する基本情報を補完したす。 着信トラフィックの䞀郚はプロセッサによっお凊理され、そのタむプず量を個別に远跡したす。 CPU負荷の増加は、DDoS攻撃ず非垞に有効なトラフィックICMP、ARP芁求などの䞡方を匕き起こす可胜性がありたすが、これは単に倚すぎたす。

過剰な量のデヌタを凊理するず、すべおのプロセッサはその時点たで起動でき、ルヌティングプロトコルなどのサヌビストラフィックを凊理できたせん。たずえば、 ルヌティングアップデヌトやhello / keepaliveパケットなどです。 したがっお、隣接するネットワヌク機噚ずの盞互䜜甚が停止し、サヌビスが䜎䞋たたは䜎䞋したす。

実際の䟋を次に瀺したす。


IPv6ルヌティングプロトコルのパケットストリヌムレヌト。


CPU負荷グラフ。

グラフは、IPv6ルヌティングプロトコルパケットがスむッチCPUに「ロヌド」を開始する方法を瀺しおいたす。 この事実はタむムリヌに認識できず、IPv6パケットのフロヌが増加するず、ネットワヌク䞊で非垞に痛い事件が発生する可胜性がありたす。

ネットワヌク機噚のストレステストを䜿甚しお、ネットワヌクデバむスの問題を匕き起こすトラフィックの皮類ず量を特定し、 コントロヌルプレヌンポリシングで各デバむスに最適なしきい倀を蚭定したした。 以䞋のグラフは、しきい倀を超える倀のゞャンプを瀺しおいたす。

補品のスむッチの1぀でCoPPコントロヌルプレヌンポリシングを監芖する䟋


トラフィックパケットの1秒あたりのビット数。 ICMPはCPUで凊理されたす。


UDPパケット。

これらの指暙を芳察するこずで、プロセッサの負荷の増加を防ぎ、ネットワヌクの安定性を維持できたす。 他の監芖デヌタず同様に、Cactiを䜿甚しお履歎を収集し、Nagiosを䜿甚しおモニタヌに珟圚の状況を衚瀺したす。

RAM監芖


ランダムアクセスメモリの堎合の最も危険な状況の1぀は、メモリリヌクです。 短い間隔日、週で、空きメモリの遅いが避けられない枛少が単に気付かない堎合があるため、タむムリヌにそれを防止および排陀するこずが重芁です。

この問題は、Cactiで長期統蚈を収集するこずで郚分的に解決できたす。 メモリオヌバヌフロヌの傟向を远跡し、機噚を再起動するための技術的なりィンドりをスケゞュヌルできたす。 残念ながら、ほずんどの堎合、これはリヌクを「凊理」する唯䞀の絶察的な方法です。

ネットワヌクの寿呜からの別の䟋を次に瀺したす。



゚ンゞニアは、モニタリングむンゞケヌタの次の分析で、スむッチの1぀の空きメモリ量を削枛するダむナミクスを発芋したした。 倉曎は短い時間間隔ではほずんど感知できたせんでしたが、1か月たでの時間スケヌルを増やすず、空きメモリがスムヌズに枛少する傟向が珟れたした。 メモリがいっぱいになるず、ルヌティングプロトコルの奇劙な振る舞いたで、スむッチの結果は予枬できたせん。 たずえば、䞀郚のルヌトはネむバヌにアドバタむズされなくなりたす。 たたは、VSSシステム䞊のランダムなピアリンクが倱敗し始めたす。

䞊蚘の状況は非垞にうたく終わりたした。 お客様のテクノに同意し、スむッチをリロヌドしたした。

それでは、続けたしょう。 サボテングラフは、リヌクの正確な開始時間を刀断するのに圹立ち、ログを比范するこずで、原因を芋぀けお「治療」したす。

RAMのロヌドをリク゚ストしたす。

OID 1.3.6.1.4.1.9.9.221.1.1.1.1.18.index
回答 iso.3.6.1.4.1.9.9.221.1.1.1.1.18.52690955.1 = Counter642734644292

倀は、オペレヌティングシステムが䜿甚するメモリプヌルのバむト数を瀺したす。


CactiのRAMロヌド統蚈。

勀務䞭の゚ンゞニアは、 メモリ䜿甚量パラメヌタヌを䜿甚しお、異垞なドロップや空きメモリヌの䞀定の充填の傟向がないこずを確認したす。 Cactiのグラフには、プロセスのメモリ、入力/出力、合蚈メモリ、空きメモリ/占有メモリの量が衚瀺されたす。


スむッチの空きRAMの珟圚の倀は、Nagiosからアンロヌドしおいたす。

スクリヌンショットの䜜成時には、OPの45503272バむトが無料であり、操䜜のしきい倀が蚭定されおいたした。 譊告の堎合-35651584〜39845888バむトの範囲、クリティカルの堎合-0〜35651584バむト

少額ボヌナス


監芖システムが緊急事態をどのように通知するかに぀いお、いく぀かの蚀葉を曞きたす。

私たち自身の「キッチン」では、職務゚ンゞニアが画面䞊のむンゞケヌタを監芖する優れた仕事をしおいるため、远加の電子メヌルやSMS通知を䜿甚したせん。 䟋倖は個々の重芁な指暙であり、その倉化は人的芁因に関係なくすぐに知る必芁がありたす。 これらのむンゞケヌタに察しお、電子メヌルたたはSMSメヌリングを蚭定したす。 クラむアントの芁求に応じお、操䜜ごずに個別のアラヌトを構成できたす。 ここではすべおが個別です。 Nagiosのいずれかのパラメヌタヌがhardに達するず、システムはこのために構成するこずをチャネルを通じお顧客に通知したす。

そしおもう䞀぀の些现なこずですが、楜しいです。 監芖システムを䜿甚するず、むベントに迅速に察応できるだけでなく、勀務䞭のナヌザヌが問題を迅速に解決できるようになりたす。 これを行うには、ホストたたはNagiosサヌビスの指瀺ぞのリンクを配眮したす。



指瀺が蚘茉されたリ゜ヌスぞのリンクは、Redmineを䜿甚する指瀺が蚘茉されたナレッゞベヌスずしお、「レッドブック」アむコン゚クストラホストノヌトの衚瀺の䞋にありたす。 アテンダントはリンクをたどり、トラブルシュヌティングのアクションのシヌケンスを指定できたす。 スクリヌンショットの巊偎には電話の圢の写真があり、そこからこのサヌビスに責任のあるナニットを芋぀けるこずができたす。たた、問題が発生した堎合、むンシデントは本郚のこのナニットに゚スカレヌトしたす。

結論ずしお、Cisco IOSおよびXEオペレヌティングシステムにおけるSNMPプロトコルバヌゞョン1、2c、および3のかなり重倧な脆匱性に泚意を喚起したいず思いたす。 この脆匱性により、攻撃者はシステムを完党に制埡したり、攻撃されたホストのオペレヌティングシステムの再起動を開始したりできたす。 シスコは2017幎6月29日に脆匱性を発衚し、7月䞭旬以降にリリヌスされた新しい゜フトりェアリリヌスでクロヌズされたした。 䜕らかの理由で䞀時的な解決策ずしお゜フトりェアを曎新できない堎合は、次のMIBを無効にするこずをお勧めしたす。


これにより、ネットワヌクむンフラストラクチャのハヌドりェアの監芖が終了したす。 コメントで質問しおください。次回は、論理レベルでのネットワヌクむンフラストラクチャの監芖に぀いお説明したす。

Source: https://habr.com/ru/post/J344188/

More articles:


All Articles