質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

87.92%

Webアプリケーションの情報を定期的に送信するエージェントを作りたい

解決済

回答 1

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 274
退会済みユーザー

退会済みユーザー

前提・実現したいこと

Webアプリケーションの各情報をあるサーバに定期的に送信するエージェントを作成したいと思っています。

全体的な構成としては、「監視用サーバ」と「Webアプリケーションサーバ」で別れており、今回作りたい「エージェント」はWebアプリケーションの状態を取得(例えばそのWebアプリケーションにメンテナンス用のCLIがある場合、"get status"のようなコマンドを叩いて標準出力される結果をパースする)し、「監視用サーバ」に何かしらの方法で状態の値を送信する、ということを行いたいと思っています。

「監視用サーバ」と「Webアプリケーションサーバ」間については距離としてはかなり近く、セキュリティの配慮は必要ありません。

また、「Webアプリケーションサーバ」は1台ではなく、将来的にはスケールアウトして複数台構成となる想定で、台数毎にエージェントが存在する形になるようなイメージです。
対して「監視サーバ」はスケールアウトせず、1台のままで運用していくイメージとなります。
最終的に、Webアプリケーションの情報を受取るサーバ1台に対して、Webアプリケーションサーバが複数台存在するような形を想定しています。

相談したいこと

「エージェント」から「監視用サーバ」への情報送信のための手段を考えています。
「監視用サーバ」側にREST API実装を行い、「エージェント」からHTTP通信で値を送信することを考えていますが、本来の使い方として間違っている、あるいは「Webアプリケーション」がスケールアウトした際に「監視用サーバ」の負荷が耐えられるかなどの懸念があります。

今回のような場合は、WebSocketの方が適しているのでしょうか。

これ以外の手段がわからないため、ご助言を頂きたいと思っています。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • dameo

    2020/08/09 18:35

    う~ん、SNMPが出てくるとは思いませんでしたが、今使われてるのか知らないけどZabbixみたいな、負荷などサーバー状況を監視/表示するような仕組みなのではないか?と推測します。ZabbixみたいなOSSだけではなく、この分野の製品は昔から結構あると思いますが、多分作るにしては知識が足りてない気がします。

    鯖同士が近くてセキュリティ配慮がいらず、簡単なモノならシェルで集めて、そのままsyslogで一台に集めて、ログをベースに画面を作ればいいのかもしれませんが。。。
    製品レベルのものを作りたいという話なのであれば、ちょっと難しいような気がします。

    って書いていて、回答にコメントがついてるのに今気付きました。推測は当たりのようですね。その内容で質問内容を修正すべきです。

    キャンセル

  • 退会済みユーザー

    退会済みユーザー

    2020/08/09 18:48

    ご指摘ありがとうございます。
    なるほど。質問内容は編集できるのですね。

    > Zabbixみたいな、負荷などサーバー状況を監視/表示するような仕組みなのではないか?
    仕組みとしてはおっしゃるとおりです。今回作成したいのは製品レベルとまではいきませんが、Webアプリケーションのある程度の規模を想定して考えています。

    サーバ同士については距離としてはかなり近く、セキュリティの配慮は必要ありません。

    > そのままsyslogで一台に集めて、ログをベースに画面を作ればいいのかもしれませんが。。。
    なるほど。syslogはたしかに最もシンプルに実現できそうな気がします。
    ですが、このサーバ状態を送信する仕組みは、最終的にrpmなどにパッケージングし、かんたんに導入できるような仕組みにしたかったため、エージェントとして作りたかったのが経緯となります。

    まずはこちらに書いた内容と、ご回答に対する返信をもとに質問を編集しようと思います。
    ありがとうございます。

    キャンセル

  • dameo

    2020/08/11 23:18 編集

    正直に言ってまだ漠然としすぎていて、識者の注意を引くのは難しいかと思います。簡単に言うと、実際に想定している具体的なHWや規模が公開され、実測値に基づいた予測がある状態で、何か特別に配慮が必要な不思議事態が起きているのでなければ、誰の注意も引きません。そういう特別なことがない限り、それはあなたが検証して予算に合ったシステムを組むべき課題だとしか、誰の目にも映らないと思いますよ。

    本当に1台で限界まで負荷に耐えさせたいのなら、rustやgoでスクラッチから組むのが今の流行りのようです。ただ、そこまでしなくてもみんなが使える言語やプロトコルでメンテナンスできた方がいいはずですよね。できるだけ分かりやすく、不必要に効率を下げなければ、後はあなたの工夫次第です。性能と予算と利便性のバランスを取って、課題をクリアできる範囲で、一番コスパのいい形を選択してください。

    キャンセル

  • 退会済みユーザー

    退会済みユーザー

    2020/08/11 23:37

    再度のご指摘ありがとうございました。
    今回の件に関してましては、そもそもシステムの全体像がまだぼやけた状態であることもあり、漠然とした質問内容となってしまっておりました。

    もっと要件などを絞り込み、その上で必要であればまたこちらで質問させていただきたいと思います。
    ありがとうございました

    キャンセル

回答 1

checkベストアンサー

0

要件が不明瞭すぎて、アドバイスが付かないと思います。
一般論でいえば、SNMP を使うのが適切です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/08/09 14:13

    ご回答ありがとうございます。
    すみません。おっしゃるとおり不明瞭かと思いますので、補足説明させていただきます。

    実現したいこととしては、「Webアプリケーションのヘルスチェックを行うエージェントを作成したい」というところは変わりないです。

    全体的な構成としては、「監視用サーバ」と「Webアプリケーションサーバ」で別れており、今回作りたい「エージェント」がWebアプリケーションの状態を取得(例えばそのWebアプリケーションにメンテナンス用のCLIがある場合、"get status"のようなコマンドを叩いて標準出力される結果をパースする)し、「監視用サーバ」に何かしらの方法で状態の値を送信する、ということを行いたいと思っています。

    また、「Webアプリケーションサーバ」は1台ではなく、将来的にはスケールアウトして複数台構成となる想定で、台数毎にエージェントが存在する形になるようなイメージです。
    対して「監視サーバ」はスケールアウトせず、1台のままで運用していくイメージとなります。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 87.92%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る