Zabbixのマスターとレプリカの間のパケット損失を監視する必要がありました（チャネルがあまり良くない場合、複製は悪く感じます）。 これを行うために、Zabbixには組み込みのicmppinglossパラメータがあり、一連のICMPパケットがリモートホストに送信され、結果が監視システムに記録されます。 そして、パラメーターが追加され、トリガーが構成されました。 ただし、「信頼するが検証する」というsayingにあるように、タスクは完了しているように見えます。 損失が実際に発生する場合にトリガーが機能することを確認する必要があります。 それでは、パケット損失をシミュレートする方法は？ これは、それだけでなく、カットの下で議論されます。
私の頭に浮かんだ最初の考えは、iptablesを使用することでした。 実際、短い検索で統計モジュールに導かれました。要するに、このモジュールはパケットを処理し、プロセスに統計的確率を導入します。
一般に、問題は次のルールを使用して解決されました。
iptables -A INPUT -p icmp -s zabbix_ip -m statistic --mode random --probability 0.1 -j DROP
または：
iptables -A INPUT -p icmp -s zabbix_ip -m statistic --mode nth --every 10 -j DROP
ここでわかるように、2つのオプションがあります--mode random --probability 0.1-パッケージがランダムに選択されることを意味します。確率は10％です。 --mode nth --every 10-10パケットごとに処理します。 このようにして、約10％のパケット損失を達成し、トリガーが機能し、すべてが正常に動作しました。
これは停止する可能性があるようですが、偶然に原子力サブシステムのネットワークQoSからネットワークエミュレーターなどの機能について学びました。 さらに、NetEm機能は統計モジュールよりもはるかに広いです。
- delay-指定されたインターフェイスで送信されたパケットに指定された遅延を追加します。
- 分布-遅延の分布を指定できます。
- drop-パケットの損失を指定できます。
- 破損-パケット破損の可能性を判断します。
- 複製（複製）-パケットをキューに入れる前に複製を決定できます。
- reorder-パケットの並べ替えを定義します（遅延と組み合わせて使用）。
- limit-上記のオプションの効果を指定されたパケット数に制限します。
これについて、さらに詳しく説明します。
ネットワークエミュレーターは2.6カーネルからサポートされており、現時点ではすべての最新のディストリビューションに存在します（もちろんLinuxについて話します）。 カーネルでのネットワークエミュレーターのサポートを確認するには、/ boot（または/proc/config.gz）のカーネル構成を確認します。
出力からわかるように、サポートはモジュールの形式であるため、それをロードします。 iprouteパッケージのtcユーティリティも必要です。
何もない場合は、カーネルを再構築する必要があります。 カーネルアセンブリに精通している方-簡単なヒント、ネットワークエミュレータはこちら：
Networking --> Networking Options --> QoS and/or fair queuing --> Network emulator
カーネルの構築に慣れていない場合は、ディストリビューションのドキュメントでカーネルの構築に関する記事を探してください。
すべての準備ができたら、続行できます。 ローカルネットワーク上の任意のノードへのpingを開始する2番目のセッションを開くことをお勧めします。 したがって、導入されたエミュレーションは非常に明確に観察されます。
実験には、iproute2パッケージのtcユーティリティが必要です。 完全な構文は次のとおりです。
tc qdisc ACTION dev DEVICE add netem OPTIONS ACTION := [ add | change | delete ] OPTIONS := [ LIMIT ] [ DELAY ] [ DROP ] [ CORRUPT ] [ DUPLICATION ] [ REORDER ] LIMIT := limit packets DELAY := delay TIME [ JITTER [ CORRELATION ]]] [ distribution { uniform | normal | pareto | paretonormal } ] DROP := drop PERCENT [ CORRELATION ] CORRUPT := corrupt PERCENT [ CORRELATION ]] DUPLICATION := duplicate PERCENT [ CORRELATION ]] REORDER := reorder PERCENT [ CORRELATION ] [ gap DISTANCE ]
1）パケットを遅延させます。パケットの送信に100msの遅延を追加します。
ここでは、ジッター、つまり既存の100ミリ秒の遅延を示し、±10ミリ秒の偏差を追加します。
ここで相関を追加し、次のパケットの送信の遅延が前のパケットの遅延に依存するようにします。
2）配信の遅延。前の例では、送信されたパケットの合計数にほぼ均等に遅延の分布を受け取りました。 ただし、現実の世界では、ネットワーク遅延は完全に不均一です。 より現実的な画像を取得するために、分布が使用されます（デフォルトでは、分布を明示的に指定しない場合、正規分布が使用されます）。
以下の例では、パレート、正規、パレート正規の分布も利用可能であることを示しています-遅延は数式を使用して計算されます。 さらに、独自の配布テーブルを
作成できます。 私の意見では、これはかなり具体的なアプリケーションのケースですが、突然誰かが興味を持ちます。
3）パケット損失。はい、それですべてが始まりました...
20％のパケット損失を示します。
さらに、相関を指定できます。この場合、乱数ジェネレーターのランダム性は低くなり、損失の急増を観測できます。
4）パケットの損傷。意図的なパケット破損、どのように行われますか？ 示された確率で、ランダムに選択されたパケット内のランダムな場所に誤ったビットが書き込まれます。 その結果、チェックサムは収束しません-パケットは破棄されます。 損失と同様に、相関を指定してバーストを形成できます。
5）パッケージの複製。パケットの複製は、パケットの損失または破損と同じ方法で定義されます。 そしてもちろん、相関関係も示すことができます。
6）パケットの並べ替え次の例では、パケットの30％がすぐに送信され、残りは100ミリ秒遅延します。
以下の例では、最初の4パケット（ギャップ-1）は100ミリ秒遅延し、後続のパケットは25％の確率（+ 50％の相関）ですぐに送信され、逆の場合は75％の確率で遅延します。 パケットが並べ替えられるとすぐに、反復が繰り返され、次の4つのパケットが遅延され、残りはすぐに送信されるか、指定された確率で遅延されます。
この件について気にするのが面倒な人には、小さな
デモビデオがあります。
これらは物です。 ご清聴ありがとうございました。健康の実験をしてください。