Dockerコンテナー内で実行されているNode Microサービスをどのように監視しますか？

「Docker化されたアプリケーションはどの程度健全ですか？」に関するこの記事 は監視の問題を説明していますが、Dockerコンテナー内のマイクロサービスを実際に監視する方法の良い例は提供していません。

現在、マイクロサービスを監視するためにPM2モニターを使用していますが、それらをDockerコンテナーに配置すると、それぞれが独自のDockerコンテナーで実行されるすべてのさまざまなマイクロサービスの1つの画面内でこのデータにアクセスできなくなります。

Dockerswarmモニタリングはコンテナーの状態を通知しますが、コンテナー内で実行されているマイクロサービスは通知しません。

この問題を解決する確かな実証済みの方法は何ですか？

これは、Kubernetesが正しいモデルを持っている領域です。機能ヘルスチェックが必要なすべてのシステム間にロードバランサーが必要です。

Nagios、Zabbix、またはその他のタイプのモニタリングをシステムに追加し始めると、大規模な状態マシンの構築を開始します。これは疎結合モデルを壊し、容易なリファクタリングを妨げる相互依存関係を導入します。不変ではありませんが、マイクロサービスとSOAの他のバリアントの主な違いは、この疎結合です。

サービスがきめ細かく、単一の機能を実行する場合は、上流のロードバランサーでヘルスチェックを実装し、アクティブなプールメンバーを監視します。

HAproxyの例として

backend myapp
[...]
option tcp-check
tcp-check send GET\ /health HTTP/1.0\r\n
tcp-check send Host:\ foo\r\n
tcp-check send \r\n
tcp-check expect rstring ^HTTP/1.1\ 200\ Ok
tcp-check expect string container\ Good
server srv1 10.0.0.1:8080 check
server srv2 10.0.0.2:8080 check

理論的には、実際のコンテナのパフォーマンスは気にせず、全体的なパフォーマンスが良いだけです。

この方法により、システムの自己修復が容易になり、最小限の複雑さで拡張できます。

基本的には、必要なシステムの数が生きているかどうかを確認するだけでよく、そうでない場合はさらに起動します。容量を追加する必要がある場合は、予想されるノードの数を変更するだけです。

これにより、外部テストやステートマシンを使用せずにこのテストを複製または変更するだけでよいので、リファクタリングも簡単になります。

また、システムが自己修復するため、ダウンタイムと真夜中のPagerdutyアラートも削減されます。

レイテンシなどの問題を追跡するために必要なシステム全体のメトリックについては、elasticsearchなどのツールを使用して中央の場所にそれらを配置します。syslog、logstash、またはlog4を使用している場合??? 長期的にははるかに役立つメトリックを収集します。システムが小さくシンプルな場合、従来のポーリングベースの監視では十分なメトリックが提供される可能性がありますが、他のシステムとの関係がより重要で、検索可能な形式であることが望ましいです。

monitのようなソリューションはまだ存在しますが、VMやスウォームをホストしているベアメタルなどの長期間有効なコンポーネントを監視することですが、マイクロサービスモデルから最大のメリットを得るには、コンテナー自体をそのシステムから切り離す必要があります。

一般的に使用される1つのソリューション（コンテナー固有ではない）は、監視するすべての機能（DBやその他の依存関係の可用性など）とアプリ自体をテストし、期待される出力（たとえば<サービス>：<ステータス>）。このAPIがすべてのサービスのOKを返さない場合、Nagiosなどのモニタリングサービスからアラートをトリガーできます。これは、マイクロサービス自体が正常でない場合にも失敗します。

このアプローチには、（APIエンドポイントに到達することにより）サービスの機能テストを実行できるという利点もあります。

ただし、このアプローチは一部のエッジケースをカバーしていません。マイクロサービスが実行されます（ただし、特定のAPIは失敗します）。