モニタprometheusとinfluxdb
2255 ワード
前の文章に続いてprometheusとinfluxdbについて話します.
私はあまり内部構造を話さないで、簡単に使用の違いを話します. prometheusはpullモデルで、influxdbはpushという意味でprometheus serverが起動したとき、どのノードをリスニングしたいのか、ノードを増やしたり減らしたりするたびにprometheus serverを再起動しなければならないのかを教えてください.influxdbは、監視するノードごとにinfluxdb serverのアドレスを自分で構成し、送信すればよい.したがって,prometheusを用いると,各ノードはprometheus serverがどこにあるかを知る必要はなく,死ぬか生きるかを知る.prometheusのserverが切れても、監視データが収集できないだけで、監視されるノード自体には影響しません.一方influxdbサーバが停止すると、すべてのノードからのリクエストがエラーになり、結局性能に少し影響するでしょう(私はそう理解しています).しかし、これはすべて転化することができます.prometheusはpush gatewayによってpushモデルに変換することができ(prometheus serverがネットワーク分離などで監視ノードにアクセスできない問題を解決することができる)、influxdbはcollectorによってpullモデルに変換することができる(influxdb+collectorはシステム全体と見なし、各ノードの監視データを自動的に取得する). prometheusは公式のalert集積があり、influxdbは以前はなかったが、今公式があるかどうか、使いやすいかどうか分からない. prometheus用のストレージスペースは小さいですが、今はハードディスクがそんなに価値がないので、この違いは無視できると思います. influxdbの検索はSQLに似ていて、prometheusの私はほほほ(学習曲線は少し急で、しかも穴の中に落ちやすい) しかありません prometheusのお父さんはgoogleですが、私は何を言うことができますか?(製品の普及はお父さんに頼っていますね.angularとreactを見てください) こんなにたくさん言ったのに、実は牛が追い詰めた製品です.1点目と4点目の違いは、状況に応じて吟味する必要があるほか、個人の好みを見ることです.
以上、多くの場所で分析されています(しかし、具体的な状況はそんなにはっきり言っていません)、ここを見たら、この文章に干物がないと断定します.それでは、おじいさんに感謝します.続けて見てください.
実は次の点、私が主に言いたいのは、使用上の小さな注意点で、あなたのメモリを救って、他のドキュメントに言及していますが、初心者は本当に発見しにくいですね.穴に落ちてもボタンが出ないので、下を見てください.
それらを監視するとき、メモリは速く食べられます.しかしapiの数が少ない場合、メモリが非常に不足している状態が続くと、使い方に問題がある可能性があります.
これらのデータフォーマットは、(呼び出し元の観点から)類似しています(タイムスタンプは省略されています):
influxdbではjob nameはdb nameを指すべきで、labelはtagです.注意して、labelの異なる値はあまり多くありません!たとえばlabel 1に対応するvalue 1の異なる値は、あまり多くはできません.そうしないと、クエリは非常にメモリを食べます.実際の例を挙げます.
methodの値は限られていて、get、post、head、patchなどにほかならない.しかしuserID、ほほほ、その値はとても多くて、監視する時、メモリが限られている情況の下で、できるだけそれを統計しないでください.(英語の説明を見るには、キーワードを探してくださいhigh cardinality)
簡単に言えば、prometheusまたはinfluxdbでuserIDまたはIPを統計しないでください.prometheusまたはinfluxdbでuserIDまたはIPを統計しないでください.prometheusまたはinfluxdbでuserIDまたはIPを統計しないでください.大事なことを3回言う.
しかし、もし本当にこれらを統計する必要があったら、どうしますか?需要者を引き裂いて、泣いたり騒いだりして、彼らにこの需要をキャンセルさせます もう一つの神器を使って、Elasticsearch、あなたは を持つ価値がありますは、より良い、無料、メンテナンスしやすい解決方法があるかもしれません.ありがとうございます
私はあまり内部構造を話さないで、簡単に使用の違いを話します.
以上、多くの場所で分析されています(しかし、具体的な状況はそんなにはっきり言っていません)、ここを見たら、この文章に干物がないと断定します.それでは、おじいさんに感謝します.続けて見てください.
実は次の点、私が主に言いたいのは、使用上の小さな注意点で、あなたのメモリを救って、他のドキュメントに言及していますが、初心者は本当に発見しにくいですね.穴に落ちてもボタンが出ないので、下を見てください.
それらを監視するとき、メモリは速く食べられます.しかしapiの数が少ない場合、メモリが非常に不足している状態が続くと、使い方に問題がある可能性があります.
これらのデータフォーマットは、(呼び出し元の観点から)類似しています(タイムスタンプは省略されています):
job name(label1=value1, label2=value2, label3=value3) = value
influxdbではjob nameはdb nameを指すべきで、labelはtagです.注意して、labelの異なる値はあまり多くありません!たとえばlabel 1に対応するvalue 1の異なる値は、あまり多くはできません.そうしないと、クエリは非常にメモリを食べます.実際の例を挙げます.
api_count(method=POST, userID=1) = 100
methodの値は限られていて、get、post、head、patchなどにほかならない.しかしuserID、ほほほ、その値はとても多くて、監視する時、メモリが限られている情況の下で、できるだけそれを統計しないでください.(英語の説明を見るには、キーワードを探してくださいhigh cardinality)
簡単に言えば、prometheusまたはinfluxdbでuserIDまたはIPを統計しないでください.prometheusまたはinfluxdbでuserIDまたはIPを統計しないでください.prometheusまたはinfluxdbでuserIDまたはIPを統計しないでください.大事なことを3回言う.
しかし、もし本当にこれらを統計する必要があったら、どうしますか?