（マイクロ）サービスの監視方法

Question

私には一連のサービスがあります。各サービスにはいくつかのコンポーネントが含まれています

は、そのうちのいくつかは、いくつかは非同期である、いくつかは同期され、そのうちのいくつかは、ステートフル、ステートレスです。

私は、監視とアラートに対してさまざまなアプローチを使用しました。

ログベースのアラート収集およびメトリック収集。 New Relic based。自分の自転車。

基本的には、ATM私は1つの場所ですべてのサービスのための重要な指標を一般化して集計する方法、方法を探しています。私が望むのは、別のサービスよりも多くの製品を監視することです。

サービスは、顧客を終了するために使用可能である場合に、最終的な結果として、私は、ウィジェットの量が少ない1つのダッシュボードとして、それを参照してください、私は確かに言うことができるだろうそれらのウィジェットを見ています。

おそらく誰かが私にいくつかのアプローチ/手法をお勧めすることができます。または、いくつかのベストプラクティスを参考にしてください。

Answer 1

私はあなたが達成しようとしているものが好きです！ 完全に監視されていない限り、サービスは実稼動準備ができていません。

私は何your'reを記述することは健康チェックとメトリクスの話題に入ると信じています。

...サービスがエンドカスタマーに使用可能であれば、私は確かに言うことができます。

しかし、現在SLAを確実に実行するには、サービスがすべてa）実行中であり、b）要求通りに実行されていることを確認する必要があります。どちらの問題でも、StatsDツールチェーンを見ることをお勧めします。 Etsyによって最初に開発されたのは、メトリックを収集するための事実上の標準になっています。

すべてのサービスが実行されていることを確認するために、我々はKubernetesを中継しています。実行すべきもの、外部から到達可能なもの、私たちのインフラストラクチャ上のホストに到達するための記述が必要です。それはまた、物事が死ぬべきであることを確かめる - 彼らは再開されるでしょう。それは自動スケーリングなどのものでも役立ちます！ Googleへの素晴らしいツールと名声！ 保証方法は健康チェックです。 Kubernetesによって起動されたサービスノードが生きているかどうかを確認する方法はいくつかあります（つまり、HTTP呼び出しとCLIスクリプトですが、モジュール化する必要があります）。Kubernetesが不健全なノードを検出すると、代わりに別のノードを起動してください。

すべてのサービスが期待通りに機能することを確認したら、メトリックを収集する必要があります。

• 要求/秒などのエラーの
• 数返された（404、...：当社のサービス（およびすべての個々のエンドポイント）のすべてのために、私たちは次のようにStatsDを経由して、いくつかの指標を集めます）
• 応答時間（平均、中央値、パーセンタイルサービスSLA）に応じて、
• ペイロードサイズ（時には平均）
• エンドポイントあたりの同時リクエスト数、インスタンス数は、現在のような
• 一般的なメトリックを実行していますホストは現在のCPUとメモリの使用量と稼働時間をホストします。

メトリックはさらに集計されますが、それは結論です。 StatsDはコンクリート製品よりも「プロトコル仕様」のほうになってきているので、無数のコレクタ、フロントエンド、バックエンドを選択できます。これらは、システムの状態を視覚化するのに役立ちます。多くの場合、何らかのメトリックのアラートが表示されます。

これが有用だった場合はお知らせください。

Answer 2

サービスを展開するホスト、コンポーネント自体、SLAなど、監視する必要があるものは少なくとも3種類あります。これらは、使用しているソフトウェアスタックとアーキテクチャによって異なります。

これは、たとえば、Nagiosを使用してサービスがデプロイされているハードウェアを監視し、サービスメトリック/ SLAについてはSplunkと発生する可能性のあるエラーを監視できます。何かがうまくいかず、より洗練されたサポート構造を持っている場合に備えて、SNMPパッケージを使用することもできます。これがあなたのトリガーとなります。インフラストラクチャー/サービスがどのように設定されているかを知らなければ、より詳細な情報に入るのは複雑です。