以下のコンテンツはシャン シリコン バレーからのものです。このシリーズの記事は主に私自身が後で閲覧しやすくするために書きました。PDF を持ち歩く必要がなく、探すのが面倒です。
第 19 章 InfluxDB を使用した警報システムの構築
19.1 モニタリングとは
1. モニタリングでは実際にデータを時々計算します。たとえば、一酸化炭素濃度センサーを持っていて、1 分ごとにその 1 分間の室内の一酸化炭素濃度の平均を計算します。この結果をハードコーディングされた標準値と比較し、それを超えた場合は警告します。これが監視の基本ロジックです。
2. したがって、InfluxDB での監視は、実際には FLUX スクリプトで記述されたスケジュールされたタスクです。ただし、HTTP API 上であっても Web UI 上であっても、InfluxDB はスケジュールされたタスクとは別に扱います。
19.2 検査、警報端子、警報ルールを理解する
1. Web UI の左側のツールバーで、[アラート] ボタンをクリックしてアラーム設定ページを開きます。上部のオプション バーには、CHECKS (チェック)、NOTIFICATION ENDPOINTS (アラーム端末)、NOTIFICATION RULES (アラーム ルール) が表示されます。これらは、InfluxDB がアラームを出すために必要な 3 つのコンポーネントにそれぞれ対応します。
2. 3 つのコンポーネントの機能は次のとおりです。
- チェック: これは実際にはスケジュールされたタスクであり、チェック タスクと呼ぶことができます。チェック タスクは、ターゲット バケットからデータの一部を読み取り、しきい値チェックを実行し、最後にタイプ 4 シグナルを生成します。 CRIT (重大)、WARN (警告)、INFO (情報)、OK (良好)。
- NOTIFICATION ENDPOINTS（アラーム端子）：指定したアドレスにアラーム信号を送信するコンポーネントです。
- 通知ルール (アラーム ルール): 問題がある場合にどのチェックが WeChat アラームを送信するか、また問題がある場合にどのチェックが電子メール通知を送信するかを指定できます。 Check 端子とアラーム端子間の配線に相当します。
19.3 例: 一酸化炭素濃度のアラームのシミュレーション
19.3.1 要件
1. 一酸化炭素濃度を収集できるセンサーがあるとします。このセンサーは、IoT ネットワークを介して、サーバー上にデプロイされた InfluxDB に時々データを挿入します。その形式は次のとおりです。
co,code=01 value=0.001 1664851126000
2. ここで、InfluxDB を使用して次のアラーム機能を完成させたいと考えています。
- CO濃度が0.04を超えるとCRIT（クリティカル）レベルの通知信号が発せられます。
- CO濃度が0.04～0.01の場合、WARN（警報）レベルの報知信号を発報します。
- CO濃度が0.01未満の場合はOKレベル通知信号を発します。
3. 最終的には、CO 濃度が基準を超えた場合には、関係職員に連絡が入り、迅速な事故対応ができるようお願いいたします。
19.3.2 補助ツール
1. アラーム端末の効果の検証を容易にするために、POST リクエストのみをサポートする非常に単純な HTTP サービスをここに記述します。次のコマンドを直接使用して、ローカル ポート 8080 でリッスンする POST HTTP サービスを開始します。
./simpleHttpPostServer-linux-x64
2. このコマンドは実行後に端末をブロックし、POST リクエストを受信すると、リクエスト本文の内容を端末に自動的に出力します。 0.0.0.0 がバインドするホストではない場合、またはポート 8080 がすでに占有されている場合。次の 2 つのパラメーターを使用して変更できます。
- h はバインドされたホストを指定します
- p はバインドされたポートを指定します
3. たとえば:
./simpleHttpPostServer-linux-x64 - h localhost -p 8080
4. 詳細については、プロジェクトのアドレスを参照してください: https://github.com/realdengziqi/simpleHttpPostServer
19.3.3 新しいバケットの作成
1. この例のデータと前の例の混同を避けるために、次の図に示すように、ここではまず example_alert という名前の新しいバケットを作成します。
19.3.4 データテンプレートの準備
1. この例では、InfluxDB にデータを 1 つずつ手動で挿入します。そのため、テキスト エディター (このチュートリアルでは vs コードを使用します) を開いて、最初に InfluxDB 行プロトコルのデータ テンプレートを作成し、次にデータを直接コピーできます。値を少し変更して挿入します。データテンプレートは次のとおりです。
co,code=01 value=0.001
19.3.5 事前に 1 つまたは 2 つのデータを挿入する
1. この手順は、後でチェックを作成するときにクエリ コンストラクターにオプションがあることを確認するためのものです。したがって、小切手をスムーズに作成するためには、このステップを省略することはできません。ここでは、行プロトコル データをインポートする Web UI ウィンドウで、毎回 1 つのデータをインポートします。写真が示すように:
2. データは次のとおりです。
- 初め
co,code=01 value=0.0015
- 2回目
co,code=01 value=0.0025
19.3.6 チェックの作成(CHECK)
1. 左側のツールバーの [アラート] ボタンをクリックします。デフォルトでは、図に示すように、CHECKS ページに入ります。
2. 右上隅の [作成] ボタンの上にマウスを置くと、ドロップダウン メニューが表示されます。 2 つのボタンを含む:
- しきい値チェック: このタイプのチェック タスクは主に、データが特定のしきい値制限を超えているかどうかを判断することを目的としています。
- Deadman Check: このタイプのチェック タスクは、新しいデータが特定のシーケンスで書き込まれてからどれくらいの時間が経過したかを判断します。特定のシーケンスのデータが 30 秒以上データベースに入力されなかった場合に警告信号を送信するなどの値を設定することもできます。
3. ここでは、しきい値チェックを選択してしきい値チェックを作成します。後でダイアログ ウィンドウが表示されます。そのレイアウトはデータ エクスプローラーのレイアウトと非常によく似ていますが、機能にはいくつかの違いがあります。
- 上部に「このチェックに名前を付ける」という項目があるので、クリックして現在作成されているチェックに名前を付けます。
- 左上隅にタブがあり、デフォルトで DEFINE QUERY が選択されています。これが上の図に示すページ効果です。
- ページの下部にはクエリ ビルダーがあります。 ここではスクリプト エディタに切り替えることができないことに注意してください。つまり、ここではクエリのみを使用できます。ビルダーを使用してクエリを実装します。
- 一番右にはリストもあります。前述したように、しきい値チェックを作成するには、以下を選択する必要があります。
- フィールド
- 集計関数 (つまり、ウィンドウ処理後の集計関数)
- 1 つ以上の範囲。
4. 次に、クエリを作成する必要があります。以下に示すように。
- バケットで example_alert を選択します
- _measurement で選択してください
- 現在、この測定の下にあるシーケンスは 1 つだけですが、_field=value をフィルター条件に追加する必要があることに注意してください。追加しないと、右上の One Field チェック項目が通過しません。
- 最後に、集計ロジックをデフォルトの平均値から最大値に変更します。
- [送信] をクリックして、データのクエリ効果をプレビューします。
5. 左上隅の「構成チェック」ボタンをクリックします。これにより、しきい値を設定できる新しいページが表示されます。最初に気づくのは、ページの下半分だけが変更されていることです。
- 一番左のカードは、クエリとスケジューリングのさらなる構成に対応します。ここでは、チェックが 15 秒ごとに呼び出されるように、Schedule Every を 15 秒に設定します。
- 中央の STATUS MESSAGE TEMPLATE はステータス メッセージ テンプレートです。ここではシェルスタイルの値構文がサポートされています。 ${}。ここでのｒの意味については後で詳しく説明する。ここではデフォルトのテンプレートを変更せずにそのままにしておきます。
- 右端の THRESHOLDS は値の範囲の設定に対応します。ここには、小切手が発行できる 4 つのステータス メッセージに対応する 4 種類の値フィールドがあります。それらはそれぞれ次のとおりです。
- CRIT（クリティカルの最初の4文字）は重大な緊急事態を意味します。
- WARN（警告）とは警告、警告という意味です
- Info（情報）は一般的な情報、リマインダーを表します
- OK は良好な状態を意味します
6. この時点で、右下隅の CRIT ボタンをクリックすると、次の図に示すように、小さな設定ウィンドウがポップアップ表示されます。
7. これが意味するもの値が より大きい場合、チェックのステータスを CRIT に設定します。ここでは、「値が次を意味する場合」の右側にあるが、これがまだドロップダウン メニューであることがわかります。それをクリックしてみましょう。これには、以下 (未満)、範囲内 (どの範囲内) など、さらにオプションのオプションがあることがわかります。
8. 0.00125 は、現在のクエリ結果に基づいて Web UI によって自動的に入力されます。ここでは、必要に応じて、co の濃度値が 0.04 より大きい場合にのみステータスが CRIT に設定されます。効果は以下の通りです。
9. 同様に、Warn と ok が設定されている場合、Info は設定されません。結果は以下の通り。
10. 最後に、右上隅のチェック マークをクリックしてチェックを保存します。ここで、元の CHECKS ページに戻り、以下のリストに構成したばかりの Check があることがわかります。
19.3.7 テストチェック
1. 次に、データをアップロードするページに戻り、2 つのデータを挿入して、チェックの実行効果をテストします。挿入されたデータは次のとおりです。
co,code=01 value=0.025
2. この時点で、一酸化炭素の濃度は 0.01 ～ 0.03 の間の 0.025 であり、この時点で、作成したばかりの CHECK は WARN レベルの信号を送信するはずです。これで、左側のツールバーの「アラート履歴」をクリックできるようになります。ご覧のとおり、ステータス レコードにはレベル WARN の通知があります。ここで、右側のメッセージは Check:CO_Alert is : warn を示しており、これはメッセージ テンプレートによって生成されたメッセージです。
19.3.8 メッセージテンプレートの変更
1. 現在、メッセージ テンプレートで表示されるメッセージは十分に正確ではないため、警報時に現在の一酸化炭素濃度値も出力できるようにしたいと考えています。この時点で、テンプレートについて公式ドキュメントに記載されている内容を確認すると、r. フィールド名を通じてデータの特定の値にアクセスできることが公式ドキュメントで指摘されていることがわかります。
2. この場合、メッセージ テンプレートを再変更することができ、最終的なメッセージ テンプレートは次のようになります。
3. テンプレート内の r.code と r.value に注意してください。この操作により、データ内のデバイス番号と現在の一酸化炭素濃度値を直接抽出できます。
19.3.9 検証メッセージテンプレート
1. 次に、データを再度挿入します。
co,code=01 value=0.0146
2. 0.0146 は 0.01 ～ 0.03 です。前に作成した CHECK は別の WARN レベル信号を送信する必要があります。ここで、左側のツールバーの「履歴の変更」をクリックして、検査レポートのステータス記録を表示します。新しいステータスレコードのメッセージが変更されていることがわかり、今度はメッセージ内にデバイス番号とその時点の一酸化炭素濃度が表示されます。
19.3.10 アラーム端末(NOTIFICATION ENDPOINT)の作成
1. ステータス記録だけでは不十分で、開発者へのメール送信や電話発信など、外部システムへの情報送信も必要です。次に、外部へのメッセージの送信を担当するコンポーネントは警報端末です。
2. まず、左側のワークバーの [アラート] ボタンをクリックし、ページに入ったら、上部のツールバーの [通知エンドポイント] タブを選択します。
3. 右上隅の「作成」ボタンをクリックすると、以下のようなダイアログウィンドウが表示されます。
4. 左上隅に [宛先] のドロップダウン メニューがあります。これは実際にはアラーム端末の種類で、HTTP、Slack、Pagerduty の 3 つの端末が提供されていることがわかります。海外の開発チームがよく使うコミュニケーションソフトはSlackとPagerdutyですが、ここではHTTPを選択します。
5. HTTP を選択すると、ウィンドウ内の設定項目が変更されることがわかります。いわゆる HTTP ターミナルは、実際にはターゲット アドレスに POST リクエストを送信します。
6. 当面は Ruixiang Cloud には接続せず、HTTP ターミナルから送信されるデータのデータ構造を観察する方法を探します。ここでは、ヘルパー ツール SimpleHttpPosyServer がパッケージに含まれています。 Linux仮想マシンにコピー後、以下のコマンドを実行します。
./simpleHttpPostServer-linux-x64
7. 実行後、プログラムはアドレス 0.0.0.0:8080 を監視します。 POST リクエストを受信すると、受信したデータを端末に出力します。これで、InfluxDB の HTTP ターミナル アドレスを http://127.0.0.1:8080 に設定できます。次の図に示すように:
8. 最後に、右下隅の [通知エンドポイントの作成] をクリックしてターミナルを作成します。
19.3.11 アラームルール(NOTIFICATION RULES)の作成
1. アラームルールはアラーム情報と端末間のルーティングの役割を果たします。アラーム ルールでは、どのチェックをどのレベルの情報をどの端末に送信するかを指定できます。
2. 注意！アラーム ルールを作成するための前提条件は、少なくとも 1 つのアラーム ターミナルが作成されていることです。そうでない場合は、Web UI の [アラーム ルールの作成] ボタンが灰色になり、アラーム ルールを作成できないことを意味します。
3. まず、左側のツールバーの [アラート] ボタンをクリックし、次に上部のタブで [通知] をクリックします。次に、「作成」ボタンをクリックします。
4. アラーム ルールを設定するためのポップアップ ウィンドウが表示されます。以下に示すように。
5. スケジュール時刻は上部で設定でき、スケジュールされたタスクのように見えます。真ん中の条件は条件を意味します。たとえば、現在のデフォルト条件では、InfluxDB の CHECK のステータスが CRIT の場合、アラーム情報の送信に http_endpoint が使用されます。中央の条件には、タグに従ってフィルタリングするためのタグフィルターと呼ばれるボタンもあります。まず、アラームの効果をより早く確認するために、スケジュール時間を 15 秒に設定します。任意の名前を選択できます。結果は以下の通り。
6. 中央の条件領域で、「タグ フィルタ」ボタンをクリックし、タグ フィルタ条件「_check_name == CO_Alert」を追加します。ここで、CO_Alert は、前に作成したチェックの名前です。検査と通知のルールがどのように機能するかについては後ほど説明します。ここでは最初にこのように設定しましたが、設定後の効果は以下のようになります。
7. ウィンドウ下部のメッセージ領域では、現在 http_endpoint という名前のターミナルが 1 つだけあるため、ここの UI は自動的に http_enpoint を選択するのに役立ちます。現状を維持するだけです。
8. 最後に、下部にある「通知ルールの作成」ボタンをクリックしてルールを作成します。
19.3.12 警報信号送信効果のテスト
1. ここで、InfluxDB で確立されたアラーム リンクをテストしたいと思います。 0.04 より大きい一酸化炭素濃度のシミュレート値を入力するだけです。挿入されたデータは次のとおりです。
co,code=01 value=0.05
2. 図に示すように:
3. 次に、左側のツールバーの [アラート履歴] をクリックしてアラーム履歴ページに移動し、約 15 秒待ちます。通常の状況では、クリティカルレベルのステータスメッセージがチェックステータス履歴に表示されます。
4. 上の [通知] ボタンをクリックすると、通知レコードが表示されます。このリストには、InfluxDB によって送信された通知のレコードが含まれています。このレコードの右端に緑色のチェック マークがあることがわかります。これは、メッセージが http_endpoint 経由で正常に送信されたことを示しています。
5. 前に simpleHttpPostServer を開いたターミナルに戻り、内容を確認します。図に示すように、POST リクエストを正常に受信し、リクエスト本文のデータをコンソールに出力しました。
6. このjsonデータを整形した結果は以下の通りで、データの時刻、警報メッセージ、警報レベル、事件発生時の一酸化炭素濃度値などが含まれていることが分かります。ターミナルに最終的な json が表示されれば、InfluxDB のアラーム設定が完了し、正常に動作できることを意味します。
19.3.13 検査および警報ルールの仕組み
1. 以前にアラーム ルールを設定したときに、アラーム ルールを設定するにはスケジュールの時間間隔を設定する必要があることがわかりました。少し奇妙に感じますが、ルールを時々実行する必要があるのはなぜですか?まずは検査の仕組みから見ていきましょう。
2. InfluxDB がインストールされると、InfluxDB によって _monitoring という名前のバケットが自動的に作成されます。 DataExplorer を使用してその内容をクエリできます。クエリ結果は次のとおりです。
3. クエリ結果には、Check タスクによって生成されたアラーム情報が含まれていることがわかります。たとえば、_check_name という名前のフィールドがあり、その値が CO_Alert であるとします。これは、前に設定したチェック名です。つまり、定期的に実行するチェックでは、実際に example_alert からのデータを定期的にクエリし、それに対してしきい値チェックを実行し、最後にチェックされたステータス情報を _monitoring バケットに書き込みます。結果は以下のようになります。
4. 実際、次の通知戦略もスケジュールされたタスクです。_monitoring から最新期間のデータをクエリし、設定した条件に従ってデータをフィルタリングします。最後に、要件を満たすデータがある場合は、データを転送する http_endpoint を json 形式で送信します。最終的なプロセス全体を次の図に示します。
5. これは、Check、通知ルール、および通知エンドポイントがどのように連携するかです。
19.4 例: Ruixiang Cloud の統合 (警報システム用の Saas ソリューション)
19.4.1 Ruixiang クラウドとは
1. Ruixiang Cloud は、さまざまなアラーム方法を提供するアラーム プラットフォームです。充電し、警察に電話することを選択し、指示に従って設定すると、API インターフェイスが表示されます。将来、システムが警察に通報する必要がある場合、コード内のこの API に http リクエストを送信するだけで済みます。設定した電話番号に従って Ruixiang Cloud が電話をかけ、音声でプログラマーに通知します。残業の時間だということ。
19.4.2 Ruixiang クラウドの登録
1. 公式 Web サイトのアドレス: https://www.aiops.com/
2. 登録手順（省略）
19.4.3 独自のアラーム API を作成する
19.4.4 Ruixiang Cloud でアラーム API を作成する
1. まず、Ruixiang Cloud のホームページにアクセスし、左側の [Intelligent Alarm Platform] ボタンをクリックして、Intelligent Alarm Platform の作業ページに入ります。
2. 次の図に示すように、上部タブの統合ボタンをクリックして、統合設定ページに入ります。
3. この時点で、左側に監視ツールのリストが表示されます。Ruixiang Cloud は多くの監視ツールと統合できることがわかりますが、このリストには InfluxDB がありません。ユニバーサル統合ソリューション REST API。 REST API は外部への URL を提供するため、監視ツールが API で必要なデータ形式で Ruixiang Cloud に POST リクエストを送信できる限り、Ruixiang Cloud と統合できます。
4. この時点で、設定ページに入ります。まず、アプリケーション名を設定する必要があります。次に、下の青いボタンをクリックして保存し、アプリケーション キーを取得します。
5. この時点で、ページに赤いテキストの行が表示されます。これが Appkey です。このキーは漏洩しないように注意してください。
6. この時点で、アラーム API が設定されました。
19.4.5 ディスパッチポリシーの作成
1. 外部はインターフェースを通じて Ruixiang Cloud にアラーム情報を送信できるようになりましたが、Ruixiang Cloud プラットフォームはどのようにしてアラーム情報を特定の個人に送信しますか。アラーム情報を特定の人に転送するプロセスは、ディスパッチと呼ばれます。
2. アラーム プラットフォームのホームページに戻り、上部の [設定] ボタンをクリックし、右下の [新しいディスパッチ] ボタンをクリックします。
3. このとき、新しい設定ページが表示されるので、下図の指示に従って操作してください。なお、ここで担当者を設定する際に何も表示されない場合は、アカウントにメールアドレスが紐付けられていませんので、この時点ではご自身でメールアドレスを紐付けてから以降の操作を行ってください。設定後、「保存」をクリックします。
4. TICK_TEST API がアラーム情報を受信すると、特定の人に通知します。
19.4.6 InfluxDB が Ruixiang Cloud への接続を試みる
1. これで、Ruixiang Cloud に接続できるようになりました。後は、InfluxDB から送信される通知データを Ruixiang Cloud API の要件に準拠させるだけのようです。 Ruixiang Cloud で作成した API のドキュメントを振り返ることができます ([統合] -> 右側の [アプリケーション リスト] -> 自分で作成した REST API アプリケーションを検索 -> [編集] をクリック -> の下部に表示されます)図に示すように、どのような形式のデータを送信すればよいかを説明します。
19.4.7 警報端子の欠点
1. Web UI の [アラート] ページに戻り、http_endpoint の編集ページをクリックします。送信されたデータの形式を変更する場所がないことがわかります。はい、InfluxDB のアラーム端末では送信するデータ形式を設定できません。したがって、この時点で私たちの努力はすべて無駄になってしまいました。次のセクションでは、検査と警報の最下層に直接触れます。
19.5 例: ノートブックとアラームの最下層
1. 以前、Notebook を使用してアラーム タスクを作成することもできると言いましたが、それ以来 Notebook には触れていません。このセクションでは、Notebook を直接使用して、アラームの最下層にアクセスします。
19.5.1 ノートブックを使用してアラーム タスクを作成する
1. まず、左側の「ノートブック」ボタンをクリックして、ノートブック構成ページに移動します。次に、「アラートの設定」テンプレートをクリックして、新しいノートブックを作成します。
2. Notebook に入ると、最初の Cell がクエリ コンストラクターであることがわかります。ここでは、バケットを example_alert に、_measurement を co に、_field を value に設定します。結果は以下のようになります。
3. 上の [実行] ボタンをクリックして、実行結果を表示します。以下の 2 つのセルが表示されます。1 つのセルにはクエリされたデータがそのまま表示され、もう 1 つのセルには
データが折れ線グラフに描画されます。
4. 最後に、下にセルがあり、左上隅にこのセルの名前「New Alert」が表示されます。これは、このセルがアラームの設定に使用されることを意味します。
5. 上部には 2 つのブロックがあり、1 つはアラーム条件の設定に使用され、もう 1 つはスケジュール間隔の設定に使用されます。ここでは、必要に応じてアラームしきい値を 0.04 に設定します。ここで設定できるアラームしきい値は 1 つだけで、crit、warn、info、ok が欠落していることに気づくかもしれません。この問題については後で説明します。設定後の効果を下図に示します。
6. もう一度このセルの一番下を見てください、これはアラーム端子の構成です。ここでは、引き続き http ターミナルを選択します。そして、ターゲット URL を http://host1:8080 に設定します。
7. 上記の操作が完了したら、右下の「EXPORT ALERT TASK」ボタンをクリックします。
8. Notebook が長い FLUX スクリプトを直接生成することに気づくと、嬉しい驚きを感じるでしょう。以下に示すように。ここで、スクリプトをコピーしてデータ エクスプローラーに貼り付けることをお勧めします。後で、このスクリプトを自分たちで研究します。
19.5.2 スクリプトの解釈
1. スクリプトは次のとおりです。
import "strings"import "regexp"
import "influxdata/influxdb/monitor"
import "influxdata/influxdb/schema"
import "influxdata/influxdb/secrets"
import "experimental"
import "http"
import "json"
option task = {
name: "Notebook Task for local_8dc089398e53-41532537902f", every: 10m, offset: 0s} - f5df-447e-
option v = {
timeRangeStart: -24h, timeRangeStop: now()}
check = {
_check_id: "local_8dc08939-f5df-447e-8e53-41532537902f",
_check_name: "Notebook Generated Check", _type: "custom", tags:
{
}}
notification = {
_notification_rule_id: "local_8dc08939-f5df-447e-
8e53Rule", _notification_endpoint_id: "local_8dc08939-41532537902f", _notification_rule_name: "Notebook Generated -f5df-447e-8e53-
41532537902f", _notification_endpoint_name: "Notebook Generated
Endpoint"}
task_data = from(bucket: "example_alert") |> range(start:
v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "co")
|> filter(fn: (r) => r["_field"] == "value")
trigger = (r) => r["undefined"] > 0
messageFn = (r) => "${
strings.title(v: r._type)} for
${
r._source_measurement} triggered at ${
time(v: r._source_timestamp)}!"
task_data
|> schema["fieldsAsCols"](https://pdf2md.morethan.io/)
|> set(key: "_notebook_link", value:
"http://host1:8086/orgs/d2377c7832daa87c/notebooks/0a0bc4b03a6ba0
00")
|> monitor["check"](data: check, messageFn: messageFn, crit:
trigger)
|> monitor["notify"](
data: notification,endpoint: http["endpoint"](url:)( (^)
mapFn: (r) => {
body = {
r with _version: 1}
return {
headers: {
"Content-Type":
"application/json"}, data: json["encode"](v: body)}
},
),
)
次に、このコードを前から後ろに説明します。
19.5.2.1 ガイドパッケージ
1. 上部のインポート コードは省略し、これ以上の説明は省略します。
19.5.2.2 オプションタスク
1. オプション タスクは実際にはスケジュールされたタスクの設定です。コードのこの行は実際に名前を示しています。ノートブックによって生成されたアラーム スクリプトは、本質的には InfluxDB のスケジュールされたタスクです。
19.5.2.3 オプション v
1. コードの最初の行、オプション v はレコード型変数を宣言します。この変数には 2 つのキーと値のペアが含まれており、実際にはクエリ時間範囲の開始と終了を表します。ここでは -24 時間と表示されていますが、実際にはノートブックで直接操作する場合、右上隅の時間範囲が -24 時間に設定されているためです。後で -15 秒に変更します。
19.5.2.4 チェック変数と通知変数
1. これら 2 行のコードはそれぞれレコードを宣言しており、実際には後続の監視関数のパラメーターとして使用されます。_check_id、_check_name、_type などのフィールドは _moitoring バケットに必要であるため、ノートブックが自動的に生成されます。自動的に手配されます。
19.5.2.5 クエリデータ
1. 上の図のコードは、example_alert バケットのクエリを完了します。そして、クエリされたテーブル ストリームは、task_data という名前の変数に割り当てられます。
19.5.2.6 しきい値関数の宣言
1. ここにはtriggerという名前の関数があり、その主なロジックは述語式であることがわかります。ここで関数を宣言する理由は、後で述語関数を渡す必要があるモニター関数があるためです。さらに、この関数のロジックは、一酸化炭素濃度が 0.04 を超えているかどうかを判断するために使用されていることがわかります。
19.5.2.7 メッセージテンプレート
1. これも関数ですが、文字列を直接返し、内部のコンテンツは実際にはメッセージ テンプレートです。
19.5.2.8 アラームロジック
1. 次の大きなセクションは、警報のロジックです。
- まず、schema["fieldAsCols"] 関数はデータ構造を変換する役割を果たします。結果は以下のようになります。
- set 関数は、テーブル ストリームに定数フィールドを追加します。
- monitor["check"] 関数はステータスをチェックする役割を果たします
2. data パラメータによって渡されるチェック変数は、実際には _check_id などの変数であることに注意してください。そして_check_name。 messageFn はメッセージ テンプレートです。crit は前の CHECK ではアラーム レベルでしたが、ここでは関数の仮パラメータになります。渡される関数の値はtrigger で、これは前述の述語関数です。
3. また、ノートブックによって生成されたスクリプトでは crit パラメーターが値によって渡されますが、monitor["check"] 関数には実際には渡すことができる他のパラメーターがあることにも注意してください。以下に示すように:
4. info、ok、warn パラメータもあることがわかります。したがって、実際には、スクリプトを手動で変更してこれらの値の範囲を満たすことができます。
5. 外部にデータを送信するためにmonitor["notify"]関数を使用していますが、その中でhttp端子が宣言されていることがわかります。最後に、body というローカル変数があることに注意することが重要です。
6. これは実際には、POST リクエストを送信するときのリクエスト本文です。 r はテーブル ストリーム内のデータであるため、Ruixiang Cloud への接続失敗の核心はここにあります。 Ruixiang Cloud API の要件を満たす形式に本体を変更するだけです。
7. if else ロジックを直接使用して大なり小なりチェックを完了し、リクエストを直接外部に送信して、この機能を完了するために 2 つの特殊なモニター関数を使用しないのはなぜでしょうか。主な理由は、監視機能が改変履歴に痕跡を残すためです。つまり、monitor["check"] 関数とmonitor["notification"] 関数は、チェック レコードと通知レコードを _monitoring
バケットに書き込みます。これは非常に重要です。
19.5.3 Ruixiang Cloudを統合するためのスクリプトの変更
1. 最後に、Ruixiang Cloud API で必要な形式を満たすようにローカル変数本体を変更します。
2. 変更したコードは上の図のとおりです。
19.5.4 スケジュールされたタスクの作成
1. 左側の「タスク」ボタンをクリックし、右上の「タスクの作成」ボタンをクリックします。
2. 変更したスクリプトを編集エリアに貼り付け、コードのオプション タスク行の情報を左側の設定フォームに書き込み、元のオプション タスク コードを削除します。
3. 最後に、右上隅の「保存」ボタンをクリックして、このスケジュールされたタスクを作成します。
19.5.5 アラームの効果をテストする
1. ここで、ドッキング効果をテストするために、0.04 より大きい値を持つデータをアップロードします。
2. しばらく待っていると、一酸化炭素濃度の値が 0.04 を超えているとの電話がかかってきました。
19.6 例: 警報システムの改善
19.6.1 現在のアラームのアーキテクチャ
1. Ruixiang Cloud は可用性の高いアラーム サービスと考えることができます。つまり、Ruixiang Cloud は 24 時間いつでも障害なくアクセスできます。その後、Ruixiang Cloud と組み合わせることで、InfluxDB はデータの合理性をチェックするスケジュールされたタスクを設定し、最新のデータを時々抽出して計算することができます。データが不適切な場合、アラーム信号が Ruixiang Cloud に送信され、Ruixiang Cloud から特定の技術担当者に通知が開始されます。
19.6.2 より信頼性の高いアーキテクチャ
1. 前のセクションのアーキテクチャに問題があり、一晩経過すると、InfluxDB が異常終了します。 InfluxDB がダウンしている場合、当然、Ruixiang Cloud にアラーム情報は送信されません。夜は過ぎ、よく眠ったはずですが、今日は本当にクリスマスイブですか?
2. したがって、Ruixiang Cloud が InfluxDB がまだ生きているかどうかを知ることができれば素晴らしいと思います。 Ruixiang Cloud が、私の InfluxDB がまだ存在し、使用できるかどうかを時々チェックできれば最高です。この動作は、営業可能性チェックと呼ばれます。この図では、オレンジ色の矢印が Ruixiang Cloud による InfluxDB の検査です。
19.6.3 次の例のアーキテクチャ
1. Ruixiang Cloud を使用してアラームを鳴らすことは、実際には Ruixiang Cloud からソフトウェア サービスを購入することであり、このソフトウェアは貴社のサーバーではなく、Ruixiang Cloud のサーバー上にあります。このアプローチは SaaS (サービスとしてのソフトウェア) と呼ばれます。この場合、Ruixiang Cloud が InfluxDB サービスにアクセスできるようにするには、InfluxDB サービスをパブリック ネットワークに公開する必要があります。現時点では、InfluxDB はパブリック ネットワーク自体上に存在するか、イントラネットを使用して侵入します。ここでのデモ環境はイントラネットであるため、イントラネットの伝統を構築する必要があります。最終的な全体構成は以下の通りです。
2. このようにして、内部ネットワークの侵入が崩壊しても、InfluxDB が崩壊しても、アラームがトリガーされます。
19.6.4 イントラネット侵入の設定
1. このチュートリアルでは、Peanut Shell が提供するイントラネット侵入ツールを使用して、イントラネット侵入を実現します。新しい Peanut Shell アカウントには、無料のイントラネット ペネトレーション クォータと無料の 1 M 帯域幅があります。
19.6.4.1 ピーナッツシェルイントラネットペネトレーションクライアントのインストール
1. 公式 Web サイトのダウンロード ページにアクセスします: https://hsk.oray.com/download
2. システムに合ったインストール パッケージの選択に注意してください。ここでは CentOS の使用をデモしているため、ここでは CentOS Linux (x86_64) を選択します。
3. 次のコマンドを使用して deb パッケージをインストールします。
sudo rpm -ivh ./phddns_5.2.0_amd64.rpm
4. インストールが完了すると、Phtunnel という名前のサービスが自動的に開始され、このサービスを制御できる phddns というコマンド ライン ツールが使用できるようになります。すべての関連情報は、インストール後に出力されるプロンプト メッセージに表示されます。
19.6.4.2 SNのアクティブ化
1. 通常の状況では、phddns はインストール後に自動的に実行されます。 phddns status コマンドを使用して、プログラムの実行ステータスを表示できます。
phddns status
2. ONLINE と表示されていれば正常に動作しています。ここで、デバイス識別コードである SN コードに注目してください。さらに、ここでは、リモート管理アドレス http://b.oray.com があることが示されています。ブラウザでこのアドレスにアクセスしてください。以下に示すように、ログイン ページに入ります。
3. 次に、SN ログインに切り替えます。ここでデバイスの SN コードを入力する必要があることがわかります。先ほどインストール中に、初期パスワードが admin であることを確認するメッセージも表示されました。 SN コードとパスワードを入力し、クリックしてログインします。
4. ここでは、Berry アカウントを登録してアクティブ化する必要があります。
19.6.4.3 イントラネットペネトレーションの構成
1. アクティベーションが成功した後、管理ページが表示されたら、左側のツールバーのイントラネット ペネトレーション ボタンをクリックしてイントラネット ペネトレーション管理パネルに入り、[マッピングの追加] をクリックします。
2. 図のシーケンスに従います。イントラネット ホストは、イントラネット ペネトレーションをインストールしたばかりのホストを指すことに注意してください。試用版の最大帯域幅は 1 Mbps のみです。変換されたアップリンクおよびダウンリンク速度は 128 kb/s である必要があります。[OK] をクリックすると、イントラネット ペネトレーションの管理ページに戻ります。
3. 下の図に示すカードが表示されている場合は、イントラネット侵入が正常に構成されていることを意味します。
4. 今後、https://1674b87n99.oicp.vip/ にアクセスすると、ローカル 1 27.0.0.1:8086 にアクセスするのと同じになります。
19.6.5 ビジネス可用性検出の構成
19.6.5.1 監視タスクの作成
1. まず、Ruixiang Cloud のホームページに戻り、左側の図でマークされているビジネス可用性監視プラットフォームをクリックします。
2. 監視タスクのホームページにアクセスしたら、図にマークされている緑色のボタン (監視の作成) をクリックします。
3. まず監視設定を完了します ここでは、監視アドレスをイントラネット侵入用に構成したばかりのアドレスに設定する必要があります。アドレスは /health を使用しており、このアドレスに Get リクエストが発行されると、通常の状況では、InfluxDB が現在正常かどうかを示す json 形式のデータが返されます。さらに、リクエストが成功した場合、ステータス コードは 200 になるはずです。最後に、このインターフェイスに get リクエストを行う場合、トークンの祝福は必要ありません。
4. 応答部分の設定は下図のようになりますが、ここでの意味は、インターフェースが 2 秒以内に応答を完了すれば十分な速度であり、2 ～ 5 秒であれば比較的遅いという意味です。 5 秒を超える場合は、非常に遅いことを意味します。
5. 右上隅の結果検証をクリックし、応答コードを 200 に設定します。これは、応答コード 200 が予期される正常な状態であることを意味します。
6. 監視頻度は 15 分に設定されていますが、無料版では最速でも 15 分に 1 回しかアクセスできませんが、充電するとさらに高いアクセス頻度が得られます。
7. オペレータおよび監視エリアとは、インターフェイスへのアクセスに使用する省およびオペレータのネットワークを指します。これは、インターフェイスがチャイナ モバイルのネットワークにはアクセス可能でも、チャイナ ユニコムのネットワークにはアクセスできない場合があるためです。最終的にはホストを 1 つだけ選択します。以下に示すように。
8. 上記の操作が完了したら、右上隅の「保存」ボタンをクリックします。
19.6.5.2 アラームルールの構成
1. 監視リストに戻ると、ページ上にすでに監視項目があることがわかります。
2. 左側のアラーム ボタンをクリックして、アラーム チャンネルを設定しましょう。
3. ご覧のとおり、アラーム ルール、アラーム戦略、アラーム動作という 3 つの概念に直面しています。 InfluxDB と同様に、ここでのアラーム ルールは検査タスクに対応しており、データを警告、重大、正常の 3 つの信号に変換します。警報動作は警報端末に相当し、メール送信か電話発信かを選択できます。アラーム ポリシーは、アラーム ルールとアラーム動作を結び付けるために使用され、InfluxDB のアラーム ルールに相当します。
4. まず、アラーム ルールを設定しましょう まず、左側のアラーム ルール ボタンをクリックし、次に + 記号をクリックします。
5. ルールに名前を付け、ルール タイプで [API 監視] を選択します。
6. 上部タブのアラーム オブジェクトをクリックすると、左側に作成した API 監視タイプの監視タスクが表示されます。左側の InfluxDB 健全性ステータスを選択し、中央の >> ボタンをクリックして追加しますここに来て「次へ」をクリックしてください。
7. ご覧のとおり、ここでは重大な条件を設定する必要があります。これは、InfluxDB で CRIT しきい値を設定するのと同じです。ここでは、過去 15 分間の可用性率が 100% でない場合に重大なエラーが発生するように設定します。が発生しました。図に示すように、右下隅にある「次へ」を再度クリックします。
8. このステップは警告条件と呼ばれ、InfluxDB の警告に相当します。ここでは、青いボタンを直接クリックして厳しい条件から同じ条件をコピーし、右下の [保存] をクリックします。
9. 最後に、すべてが正常であれば、次の図に示すように、アラーム ルール リストが 1 つ増えます。
19.6.5.3 アラーム動作の構成
1. 左側のアラーム動作ボタンをクリックし、+ 記号をクリックして新しいアラーム動作を作成します。
2. まず、ポップアップ ウィンドウで動作タイプを選択します ここでは Webhook を選択します。ここでは URL が必要であることがわかります。これは、リクエストをアウトバウンドに送信することと同じです。したがって、この URL で指定されているユーザーは、処理のために実際に Ruixiang Cloud に接続する必要があります。
3. インテリジェント アラーム プラットフォームの統合ページに戻り、統合ツールで Ruixiang Cloud を見つけます。クリックして作成します。
4. まず名前を付けて、すぐ下にある [保存] をクリックしてアプリケーション キーを取得します。
5. 構成説明の URL が、キーとなるランダムな文字列で自動的に完成されることがわかります。さあ、コピーしてみましょう。
6. アラーム動作を作成するウィンドウに戻り、URL を入力して、「テスト」をクリックします。テスト結果に接続成功が表示された場合は、構成が正しいことを意味します。右下隅にある「保存」をクリックします。
19.6.5.4 ディスパッチポリシーの変更
1. これで、アラーム プラットフォームに 2 つのアプリケーションが作成されました。ただし、REST API によって受信されたすべてのアラーム通知を特定のユーザーに転送するディスパッチ戦略を以前に作成しました。ただし、作成したばかりの Webhook は、このディスパッチ戦略にはまだ含まれていません。ここで、前に設定したディスパッチポリシーを見つけて、右側の編集ボタンをクリックします。
2. 編集ページに入ったら、図に示されている「追加」ボタンをクリックします。
3. ご覧のとおり、ここでは 2 つのアプリケーションが表示されます。つまり、これら 2 つのインターフェイスで受信したアラーム通知は、指定したユーザーに転送されます。最後に、「保存」をクリックすると、ディスパッチポリシーが正常に変更されます。
19.6.5.5 アラームポリシーの作成
1. 監視プラットフォームとアラーム管理ページに戻ります。まず左側のアラーム ポリシー ボタンをクリックし、次に + 記号をクリックしてアラーム ポリシーを作成します。
2. トリガーストラテジの構成は下図のとおりです。
3. 上のトリガー動作設定ボタンをクリックし、右側の追加ボタンをクリックします。
4. 選択できるタブがあることがわかります。これは以前に作成したアラーム動作です。マウスをクリックして選択し、右下の選択ボタンをクリックします。
5. アラーム動作が正常に追加された場合は、右下隅にある保存ボタンをクリックします。この時点で、警報戦略は正常に確立されました。
