Squzy-インシデントと通知を備えた無料のオープンソースセルフホスト監視システム

ある暑い冬の夜、私たちは、エラーが発生したときに通知する機能を備えた、勤務先の会社のサイトマップをチェックするためのアプリケーションを作成するというアイデアを思いつきました。



徐々に、このアイデアは実装に移り、改善の考えがあり、ホストの監視が現れ、次にアプリケーションの監視、そしてケーキの上のアイシングのように、通知付きのインシデントが発生しました。



その結果、完全にユーザー定義のインシデントを伴う、外部通信を持たない完全にオープンソースのセルフホストソリューションである本格的な監視システムを手に入れました。



そして、この投稿では、結果として得られる製品を紹介したいと思います。



技術的な詳細



開発にはマイクロサービスアーキテクチャが選択されました。バックエンドは、マイクロサービスを開発するための高速で便利な言語としてGoLangで開発されました。 gRPCを使用してサービス間の通信を行いました。 gRPCがHTTP / 2で動作するという事実に加えて、protoを介したサービスインターフェイスの記述により、ユーザーは、必要に応じて、システムの個々の部分の独自の実装を作成できます。



このプロジェクトでは、Mongoをクイックアクセスデータベースとして使用し、Postgresを使用して収集した統計を保存します。



Bazelは組み立てと展開に使用されました。Bazelを使用すると、Golangのパッケージ間の依存関係と関係を宣言的に記述することができます。さらに、リモートキャッシュを使用してBazelのテストを開始しました。これは、システムの速度にプラスの影響を及ぼします。Bazelはまた、Docker内のすべてのアプリケーションを収集し、ユニットテストを整理します。これらはすべてGithubアクションに統合されています。



システムのダッシュボードはAngular9で記述さ



れています。すべてのエンティティがカバーされている時点で、ユニットテストでバーを維持しようとしています。近い将来、システムの最も完全なサポートのために、統合およびE2Eテストの実装が計画されています。



システムの説明



上記のように、Squzyは相互に作用する一連のマイクロサービスであり、それぞれが個別のタスクを処理します。



サービスのリスト:



  • Agent Client — , . , . Agent Server.
  • Agent Server — , . Mongo, Storage.
  • Application Monitoiring — , / Squzy , . GoLang NodeJS, — PHP & Java .
  • Monitoring — external/internal .
  • Storage — . Postgres, ClickHouse.
  • Incident Manager- . ( ). Mongo, Storage.
  • Notification Manager — . Webhook & Slack.
  • API — API Gateway


サービスの相互作用スキームは次のとおり







です。Squzyの機能を示すために、独自のサーバーを監視し、ダッシュボードでシステムを監視できるデモが開発されました:https//demo.squzy.app/



新しいエンティティの追加/削除などの一部の機能はデモでは無効になっていますが、システムのすべての部分を確認して感じることができます。以下では、各タイプの監視について詳しく説明します。



システムのこの部分は、外部/内部チェックを担当します。現時点では、次のタイプのエンドポイントにリクエストを送信し、レスポンスを期待することができます。



  1. Tcp-オープンポートチェック;
  2. gRPC-プロトコルチェック;
  3. Http-ステータスコードへの準拠を確認します。
  4. SiteMap-サイトマップのすべてのURLが200OKで応答することを確認します
  5. JsonValue-JSON応答からの特定の値のコレクション。


Squzyを使用すると、あらゆる種類のHTTPチェックにカスタムヘッダーを追加できます。



Squzyダッシュボードを介してチェックを追加するためのインターフェイスは、次のようになります。







ここで、intervalはチェック間の間隔(秒単位)であり、timeoutはチェックが失敗したと見なされるまでの時間です。



作成後、ユーザーはチェッカー構成にアクセスできます。







チェックのタイプごとに、インシデントルールを作成できます。インシデントの詳細については以下で説明しますが、ここでは例を示します







。この場合、サイトからのドル為替レートの値を測定し、80を超える場合はインシデントを作成します。



デモへのリンク。



インシデントは次の場所で作成できます。



  • 検証の期間(サーバーからの応答を受信する時間)。
  • ステータス(返されたステータスコード);
  • 値(チェッカーで送信される情報)。


スクイーズエージェント



サーバーにインストールされたSquzyAgentは、システム内のホストを監視するために使用されます。現在、次の統計を収集しています。



  • CPU-プロセッサ負荷;
  • メモリ-使用済み/空き/合計/共有;
  • ディスク-各ディスクの使用済み/空き/合計。
  • ネット-各ネットワークインターフェイス用。


エージェントのタイムライン:



  1. エージェントはエージェントサーバーに登録し、IDを受け取ります(登録時に、監視間隔とエージェント名を指定できます)。
  2. エージェントは特定の間隔でサーバーに統計を送信します。
  3. …。
  4. エージェントはサーバーにシャットダウンについて通知します。


サーバーへの接続がない場合、エージェントは引き続き統計を収集し、接続が復元されたときに統計が送信されます。



エージェントのデモバージョンは、次の場所 で確認できます。https//demo.squzy.app/agents/5f142b6141a1c6518723483a/live



エージェントには、インシデントをチェックするための一連のルールを設定することもできます





Squzyアプリケーションの監視



アプリケーションを監視するために、Go / NodeJの一般的なフレームワークとの統合が開発されました(成功したマーケターが言うように、さらに詳しく)。統合により、トランザクションのタイプ(Http / Router / gRPC / WebSocket /など)が決定され、エンジン/要求からの応答が解析されます。



Squzyは、複数のサーバー/サービスの関連トランザクションを監視できるトランザクショントレースもサポートしています。ダッシュボードでこのようなトランザクションを監視する例:https//demo.squzy.app/transactions/om8l8LP96PRsvx67UxkES



GoおよびNodeJに統合するためのライブラリ。





中核となるライブラリは、トランザクションを送信する前の時間と処理された後の時間を計り、応答を分析するミドルウェアです。また、サンプルのGO監視アプリケーションを作成しました:https//github.com/squzy/test_tracing。



独自のトランザクションを作成し、それらの実行時間、ステータス、およびエラーを測定できます。これには、コアパッケージを使用します。製品サポートを容易にするために、すべての言語は、動作を定義するパッケージに同じ名前を使用します。



次のデータに基づいて、トランザクションごとにインシデントを作成できます。



  • トランザクションの期間。
  • トランザクションステータス。
  • 受信したエラー。
  • トランザクションタイプ。


Squzyインシデントマネージャー+通知マネージャー



Squzyのインシデントはルールベースです。新しいエンティティをストレージに追加すると、説明されているルールがチェックされ、そうである場合は、インシデントが作成されます(まだ作成されていない場合)。



ルールはexprの拡張バージョンでありLast(ストレージから最後のnレコードを取得)、Use(これに特定のフィルターを使用などのシステム仕様を考慮して、特定のルールが追加されます。すべてのルールの詳細な説明はhttps://squzy.app/usage/squzy-incident/incident-rulesにあります。ここでは、説明的な例に焦点を当てます。



1,792個のプロセッサ、256 GBのRAM、16TBのハードディスク容量を備えたサーバーがあるとします。そして、あなたは本当にあなたのdevopsがCPU負荷モニターでDoomを実行していないことを確認したいです。サーバーにサービスを提供する1ページのサイトを維持しても、1分を超えて8個を超えるプロセッサが100%ロードされることはありません。さらに、RAMは半分以上空いています。ハードドライブには1TBの空き容量が確保されていますが(有名なアーカイブを自宅に保管しない場合は、妻に表示されます)。この場合、メトリックが10秒ごとに収集されることがわかっているので、次のルールを定義して、サーバーが正しく機能していることを確認できます。



any(Last(7, UseType(All)), 
    {all(.CpuInfo.Cpus, {.Load > 80}) &&
    .MemoryInfo.Mem.UsedPercent < 50 &&
    .DiskInfo.Disks["System"].Free > 1000000000000}
)


同様に、Squzyを使用すると、不要なシステム動作のさまざまなパターンを記述することができます。



ルールチェックが成功した(または失敗した)後、インシデントが作成され、構成されている場合はユーザーに通知されます。



アクティブなインシデント、つまりユーザーによってまだ検証されていないインシデントは、適切なオプションが選択されている場合、ある時点で検証に合格しなかった場合に、自動的に閉じることができます。



アプリケーション/チェッカー/エージェントであるかどうかにかかわらず、チェックされたエンティティごとに、インシデントに関する独自の通知を作成できます。



結論



現在、ITコミュニティからフィードバックやコメントを収集中です。



製品開発については、すでにいくつかの計画があります。



  1. Java / PHP統合の追加。
  2. データベースチェッカー;
  3. PostgresからClickHouseへの移行。
  4. その他の通知方法。
  5. kubernetesとの統合。
  6. ドキュメントの改善。
  7. GQL API;
  8. 統合およびE2Eテスト。
  9. モバイルアプリケーションの監視。
  10. UIのインシデントルールの自動完了


ご意見やご提案をお待ちしております。



リンク





PS:Vonotirax

の記事をありがとう1クリックで試す






All Articles