SNMP（Python + AgentX + systemd + Raspberry Pi）を介してセンサーの測定値を読み取り、別のモニターを作成しました

みなさんこんにちは。









「Universal Control Unitを最大限に活用する」という記事が公開されてから、多くの時間が経過しました（正確には1年以上）。 このデバイス用の通常のソフトウェアスタッフィングを作成するのに十分ではありませんが、十分ではありません。 結局のところ、それは美しさのためではなく、センサーからデータを収集し、このデータが監視システム（私の場合はZabbix）に表示されることを確認する必要があります

パート1-ソフトウェア

過去に、ソフトウェアの充填から以下が実装されました。

• 接続されたすべてが機能していることを示すテストスクリプト
• 温度センサーから測定値を収集するzabbiksaのスクリプト

ntpdとgpsdに別々のモニターを作成する試みがありました。 zabbixがこのデータを読み取れるようにしながら、構成を読み取り、構成に従ってさまざまなソースからデータ収集プロセスを開始し、これらのプロセスからデータを収集し、画面に読み取り値を表示できるはずのスーパーモニターに多くの時間が費やされました。 実際、設定を読み取って必要なプロセスを生成するプロセスマネージャーを実装することが判明し、非常にクールであることが判明した画面上の描画は、設定からレイアウトを読み取り、タイマーによって画面の内容を変更する方法さえ知っており、その時点でプロセスからデータを収集します必要です。 このスーパーモニターには、データを収集する実際のプロセスだけがあります。 さらに、ボタンに機能を割り当てるための信号システムを作成したり、さまざまなデータソースの優先順位を考慮したりするなどのアイデアがありましたが、すべてが私の自由時間に出てきたため、このスーパーモニターは非常に肥大化して巨大なものになりました。



しばらくの間、本格的なソフトウェア充填の開発で得点しました。 Nenuacho、スクリプトは動作し、ルールは「動作する-触れないでください」と彼らが言うように、管理者の聖なるルールです。 しかし、それは不運です-監視したいほど、より多くのスクリプトを記述し、zabbixのSELinuxに追加する必要がある（私はraspiを監視しているだけではありません）これは理解できます。 私は本当にzabbiksのSELinuxを完全に無効にしたくはありませんでした。 したがって、私は考えなければなりませんでした。



そして、監視システムにデータを収集する方法を理解しましょう。

• 開始者は次のとおりです。
  
  
  
  
  • アクティブ監視-監視対象ノードはデータ転送（プッシュ）を開始します
  • パッシブ監視-監視ノードはデータ転送を開始します（プル）
  
  
  
• データ収集方法別：
  
  
  
  
  • エージェントがサポートするメトリックのみを使用した、監視対象ノード上のエージェント経由
  • 監視対象ノード上のエージェントを介して、スクリプトでエージェントを展開します
  • SNMP
  • プリミティブping
  • Telnetで
  • ...など

私はプルの監視を使用していますが、宗教的な理由ではなく、たまたま行われました。 実際、特に軽い負荷では、プッシュとプルの間に大きな違いはありません（以前の作品の1つでは、Nagios + NSCAを行いましたが、大きな違いに気づかなかったので、まだ手で要素を作成する必要があります）。 すでにプッシュモニタリングを行っている場合はzabbix_senderを使用できますが、そこに存在せず、試用版もありません。また、互いに干渉するのは面倒です。 しかし、どのプロトコルを監視するかという問題では、選択肢は大きいように見えますが、そうではありません。検出はエージェントまたはSNMPを介してのみサポートされ、2つのオプションしか残されていません。 説明されているSELinuxの問題により、エージェントが表示されなくなります。 出来上がり、SNMPによるプルモニタリングがまだあります。



ほら！ なぜ乾杯ですか？ Linuxでは、snmpdがあるように見えますが、どうすれば必要なものを返すことができますが、snmpdは何を知らないのですか？ snmpdには、任意のOIDによって任意のデータを提供するための3つの（根本的に異なる）方法があります。

• 外部スクリプト（exec / sh / execfix / extend / extendfix / pass / pass_persistディレクティブ）の実行は、SELinuxの潜在的な問題と、制御されない一連のスクリプトがダンプになってしまうため、悪いです。 はい、pass_persistはバイナリデータ転送には適していないと言います。 恥ずかしげにうそをついているかもしれませんが、とにかく100万個のスクリプトを作成するという考えは好きではありません。
  
  
  
  
• 組み込みのperlに何かを書くか、.soをダウンロードします-パールを知りたくないし、パールを知りたくない、so-shkiを書きたくない、私はCで書くプログラマーではありません。
  
  
  
  
• 外部エージェント（プロキシ、SMUX、AgentX）からデータを取得します-しかし、それは良さそうに聞こえますが、疎結合は言語に依存しません。 理解しましょう：
  
  
  
  
  • proxy-指定されたホスト上のSNMPエージェントにOIDを要求します。 SNMPプロトコル全体を実装する必要がありますが、これはまったく役に立たず、なぜ別のノードから何かを要求するのか、ローカルでデータを受信したいときにネットワークを使用します。 127.0.0.1の存在については知っていますが、いずれにしてもSNMPはまったく笑いません。
    
    
    
    
  • SMUX-呼び出し側エージェントのsmuxプロトコルもサポートする必要があり、デフォルトでは、net-snmpはsmuxサポートなしで構築されます（そして、すでにntpdはppsをサポートするために再構築されます。 はい。このsmuxはSNMPパケットの単なるラッパーであり、サブエージェントがエージェントに登録する機能を追加しただけです。
    
    
    
    
  • AgentXは基本的にSMUXと同じであり、プロトコルのみがよりシンプルで、パッケージがより軽量です。 まあ、それはデフォルトでnet-snmpにコンパイルされており、これも素晴らしいです。 私たちの選択のように聞こえます。

私はPythonで書いているので、だれかがすでにagentxプロトコルを実装しているかどうかを探しに行きました。 そして、結局のところ、 https://github.com/rayed/pyagentxとhttps://github.com/pief/python-netsnmpagentという素晴らしい人々がいました。 2番目のプロジェクトはより活気があるように見えますが、最初のプロジェクトはよりシンプルに見えます。 私は最初のもの（pyagentx）から始めました。それは動作し、必要なことはすべて行います。 しかし、このライブラリにデータを転送する方法について考え始めたとき、2番目のパッケージ（python-netsnmpagent）を扱いたいと思いました。 pyagentxの問題は、書き込み方法であり、呼び出し関数からデータを受信できないため、新しいデータの要求はsnmpdに更新を送信する関数で直接発生する必要があることです。これは常に便利で常に可能とは限りません。 もちろん、独自の何かを再構築して機能を再定義することもできましたが、実際にはクラスをほぼ完全に書き換える必要がありますが、これもやりたくありませんでした-私たちは膝の上で開発しています。すべてがシンプルで迅速でなければなりません。 ただし、python-netsnmpagentを処理することに抵抗はありますが、pyagentxからアップデーターにデータを転送する方法を見つけましたが、それについては以下で詳しく説明します。



次の質問は-アーキテクチャはどのように見えますか？ データソースをフォークし、そこからデータを読み取るディスパッチャーを作成しようとする試みは既に完了しており、あまりうまく終了しなかったため（上記を参照）、ディスパッチャーの実装を放棄することになりました。 それで、どこかでsystemdについての記事を見たか、それともより密接に対処したいという古い欲求をもう一度くすぐったので、ディスパッチャをシステム化することにしました。 嫌いは嫌いだし、箱から出してすぐにそれがすでにラスピにあるかどうかを私たちは理解します。



私が見つけたsystemdの便利な機能は何ですか？

• 無料の悪魔-simple（またはnotify）タイプのサービスユニットを記述し、このためのコードを1行も記述せずにデーモンを取得します。 さようならpython-daemonおよび/またはdaemonize
• 落下したユニットの自動再起動-ここで、コメントは不要で、一貫性のないエラーを防ぎます
• ソケットの読み取りとソケットの準備がまだできていなくても、ソケットへの書き込みを希望する誰かがこれを行うことができる場合、一般にソケットのアクティブ化とソケット管理は非常に便利です。 さらに、リーダーはソケットへの書き込み時にアクティブになり、RAMを節約できます（ただし、十分ではなかったわけではありません...）
• テンプレートユニット-多数の同一のセンサーがある場合、1つのユニットから多くのプロセスを生成し、異なるパラメーターを全員に渡して楽しむことができます
• （検出が遅すぎ、まだ実装されていない）units-timers-ユニットを定期的に実行できます。 なぜcronではありません-cronの最小期間は1分であり、センサーをより頻繁にポーリングしたいからです。 なぜスリープしないのか（）-待機がアクティブで期間がドリフトし始めるため-はい、センサーをN秒ごとにプルしますが、データの読み取りと処理を考慮すると、データ更新期間はN秒ではなく、N + x、つまりデータ更新期間の読み取りはxに移動します

これらの調査結果を念頭に置いて、アーキテクチャが描かれました。

• systemdは、センサープロセスとコレクタプロセス間の通信用のソケットを開き、すべてのセンサープロセスが同じソケットに書き込みます
• systemdはセンサープロセスのユニットを起動します
• センサープロセスはセンサーからデータを読み取り、ソケットに書き込み、スリープ状態になります（その時点でsystemdタイマーユニットが見つかりませんでした）
• センサーからのデータがソケットに書き込まれるとすぐに、systemdはプロセスコレクターを開始します。プロセスコレクターはセンサーから更新を受け取り、魔法のように処理して内部状態で保存します。 プロセスコレクターは死なない
• コレクタープロセスは別のスレッドを生成します（プロセス間のIPCを回避するために、プロセスではなくスレッドです。このタスクの python では多少悲しいですが、なぜそう思うのかを以下に記述します）。内部状態はagentxプロトコルを使用してsnmpdに転送されます

非常に悪い場所の1つは、コレクターストリームとagentxストリームの間の共有内部状態です。 しかし、Pythonには2つのスレッド間の同期の問題を解決する魔法のGILがあるため、私はこれを許しました。 もちろん、これは非常に悪いことであり、本によるとそうではありません。 共有状態を別のプロセスに移動し、agentxプロセスとコレクタープロセスをソケットを介して状態プロセスで動作させるというアイデアがありましたが、別のソケットを作成し、別のユニットを作成したい、などです。



このタスクに関連して Python で IPCが好きではなかった理由：

• キューは正常に機能しますが、これらのキューには名前が付けられていないため、キューインスタンスを分岐プロセスに渡す必要があります。 私の場合、これはpyagentxを完全に書き換えることを意味します
• マネージャーは私の問題を解決するかもしれませんが、それでもpyagentxを完全に書き換えることを意味します
• posix / sysv ipcは素晴らしいですが、名前付きのキューがありますが、一部のシステムではこれらのキューのサイズは制限されています-非常に不十分に制限されています（たとえば、macosではキューごとに2KBを超えずに設定することもできます不可能）。 sysv ipcの実装により、さまざまな程度の悲惨さを備えたさまざまなシステムで実行する必要があったわけではありませんが、チューニングも行いたくありませんでした。 すぐに元気にしたい
• posix / sysv ipc再び-キューはブロックしています。つまり、キューからの読み取りが「空」を返す前に、最小のタイムアウトが必要です。 pyagentxの場合、update（）でキューからの読み取りをブロックすることは非常に望ましくなく、通常は悲惨です
• posix / sysv ipc-キューの命名に関する問題。 メッセージキューには名前が付けられていますが、名前ではなくキーによって名前が付けられています。 キーは階層的または意味的に明白ではないため、一意でないキーを選択するのは簡単です。 Pythonのposix / sysv ipcの実装では、キューキーを自動的に生成できますが、問題は-何かをpyagentxに渡すことができれば、キューをそこに渡し、苦しめられないことです。 ftokを使用してキーを生成することは可能ですが、ftokはint random() {return 4;}
  
  
  
  よりもキーの一意性に対する信頼性が低いと書いています [「使用方法のヒント」までスクロールし int random() {return 4;}
  
  
  
  
• （外部のキューブローカーが関与しないことはもう気になりませんでした。タスクはキューブローカーを保持するほどのものではありません-追加のサービス、追加の頭痛）

dbusはすべてのトラブルの解決策のように見え、systemdが存在するところならどこにでも存在しますが、問題はpydbusがAPIを公開するためにGLib> = 2.46を必要とし、raspbianでは2.42のみであるということです。 dbus-pythonは非推奨であり、サポートされていません。 要するに、ロバの雄鶏がロバに刺されるまで、私は安全でない方法で状態を共有します。



汚い目的でSNMPを使用する場合、別の問題がありますが、データセットにOIDを選択する方法はありますか？ これを行うために、エンタープライズと呼ばれるプライベートの特別なブランチがあります-.1.3.6.1.4.1。<enterprise_id>。 IANAから一意のエンタープライズIDを取得できます。 OIDスキームが定義されている場合、MIBを記述して、どこで、何を、そしてシステムを監視しやすくするのを忘れないようにしてください。 MIBを書くことへの紹介はここにあります 。



ある時点で、対応するMIBでntpsnmpdを発見し、bげた頭まで喜んでいましたが、この奇跡をコンパイルしたとき、筆者はいくつかのトップレベルの定数を実装するだけで、蒸気が足りないことがわかりました。 コードを少し掘り下げて最後まで掘り下げましたが、作成者がntpd（またはntpq）と巧妙に対話して、出力を気にせずにこれらの定数を引き出す方法を理解していませんでした。 私は確かに1つのことを理解しました-既製のPython APIはありません。つまり、キャッチするものは何もないことを意味し、このMIBを自分で実装する必要があります。





一般に、この設計全体が機能し、非常に粘り強いです。 ディスカバリーはzabbixで機能し、アイテムが作成され、グラフィックが描画され、トリガーがアラートを送信します。幸福に必要なものは他にありますか？ コードはまだ完成していないので、公開しません。

パート2-ハードウェア

ユニットケースを台無しにすることは常に可能というわけではありませんが、壁に鼻水が垂れているような気もしません。 非常にエレガントなソリューション-DINレールがあります。 レール付きの構造物の山は市場で販売されており、ラックマウント電源（私はMeanWell DR-15-5を使用）、およびあらゆる種類の自動機を置くことができます。 したがって、私はraspi用のDINレール上のケースが欲しかった。 これら2人の同志は候補者と見なされました-ItaltronicとRasPiBoxのモデル。 RasPiBoxの利点は、プロトタイピングボードが既にあり、ネジ接点（GPIOのスタビライザーを介して）から電力が供給されることです。これは便利ですが、安全ではない場合があります。 しかし、3倍以上の費用がかかり、レール上のスペースをより多く占有し、透明な窓がありません。 Italtronicモデルも理想的ではありません-その幅は、既製の16x2 LCDスクリーンがすべてその幅に収まらないようなものです。つまり、透明なウィンドウの価値は急激に低下しますが、低価格でこの欠点を許す準備ができていました。



ケースは非常に便利であることが判明し、2枚のプリント回路基板または何かのシートを取り付けるためのスペースがあります。 非導電性のESD保護フィルム、ドレメル付きののこぎりに包まれたアクリルから基板を作成します。







内部のボードは、摩擦力と両側の小さな棚でのみ保持されます。つまり、内部に堅固な固定はありません。 見かけのサイズにもかかわらず、ケースは小さく、特にボードを下のレベルに挿入する場合は、raspi自体の上にあまりスペースが残りません。 また、複数のLEDとRTC付きのボードを配置する必要があるため、ボードが必要です。





温度および湿度センサーを新しいモニターに接続したい。 温度については、ds18b20を選択しますが、動作しますが、読み取り値を信頼できる温度計と比較する価値があり、センサーは仕様に応じて0.5度の位置にあります。 補正するために、構成内の定数の読み取り値の基本的な修正を追加し、そのような温度計でチェックしました：







私のds18b20インスタンスは自分自身に嘘をつかないことが判明しました。 しかし、次のセンサーはちょうど横たわっており、最大0.6度です。 ただし、これもインスタンスに依存します。1つは嘘をつき、もう1つはほとんど嘘をつきませんでした。



湿度があると、それほど単純ではありませんでした。 安価であるか、raspiでま​​ったく機能しない（アナログであるため）、ライブラリがない（すぐに使いたい）、または航空ケーブルのように高価です。 利便性とヒキガエルの妥協点がAdafruit BME280センサーで見つかりました。これは、ボーナスとして温度も表示します（ただし、上記のように嘘をつくこともあります）。



ds18b20を単純に熱収縮で包んで喜ぶことができる場合、BME280ではこのような焦点は機能しません。 ケースについては多くのアイデアがありました-そのままにして、ワイヤーをはんだ付けして接着剤ノズルで埋めます（すでに固定用の耳があり、判明しています）、コンポーネントの基板と同じアクリルからミニケースを作成し、 3Dプリンター、手元にあるので...しかし、その後、私は卵について思い出しました：







これは理想的なケースです。 センサー用の十分なスペースがあり、コネクタを配置したり、メンテナンスのために便利にアクセスしたり、どこにでもぶら下げたり、どこかに投げたりすることができます。



DB9を介してraspiにセンサーを接続することにしました。 USBラインはほとんどなく、RJ45ソケットは寸法に適合しません。 切断されたUSBケーブルの残骸がキャビネットで見つかったため、卵センサーをUSB経由で接続することにしました。







raspiのGPIOコームを保護し、ケースを分解するために、別のコームを取り出してはんだ付けしました。 櫛は角度があり、垂直方向のスペースが少し増えましたが、少し計算しなかったため、この櫛はLEDの抵抗器に埋もれていました。 もちろん、すべてが熱収縮でしっかりと包まれていますが、将来的に覚えておく価値のある瞬間です。 その結果、ケースの半分を分離して、たとえばrtcまたはraspi自体のバッテリーを交換することができます。 他のすべて（より正確には、フラッシュドライブ）は、ケースを開かずに交換できます。





1つの推奨事項-ボタンを保存しないでください。 私はそれを保存したので、ボタンはがたがた音を立てるだけでなく（RPi.GPIOライブラリはがたつきに対する保護を提供します）、非常に特定の位置でのみ機能します。 電源をオフにする必要がある場合に備えて、プログラムでデバイスをオフにするボタンを提供しました（USBフラッシュドライブでFSをずさんなシャットダウンで何度か強制終了しました）が、提供するものがあまりないことがわかりました-また、ドキュメントを読む必要がありました。 あなたが私のようにドキュメントを読んでいない場合、知っている-オーバーレイgpio_shutdownはあなたが期待するかもしれないものではなく、切断されたときにいくつかのピンで高/低レベルを公開するだけなので、例えば外部電源が切れる可能性があります。 ボタンでraspiを無効にするには、カーネルモジュールrpi_power_switch （ただし、コンパイルする必要がありますが、これにはカーネルヘッダーが必要です）またはカスタムデーモンAdafruit-GPIO-Haltがあります。 私は自分のhostdを持っていて、LEDを点滅させますが、同時にボタンに応答します。

おわりに

その結果、監視用のハードウェアとソフトウェアの複合体が拡張可能になり、現在の技術を使用して、障害に強いようになりました。 ソフトウェアの一部は、他の部分とは独立して更新および再起動できます（systemdのおかげで、開発者としての私からの努力は必要ありませんでした）。 そして最も重要なのは、プロセスと結果から多くの喜びを得ることでした。 さて、新しい知識の小さなカートが追加されました。



読んでくれてありがとう！