非常に基本的なレベルでは、モニタリングは、プロダクションで悪いことが起こったときに簡単に識別できることを意味します。例えば、メールやSlackで通知を受けることで識別します。課題は、あなたの銀行口座を枯渇させることなく、あなたの要件を満たすための適切なツールのセットを選択することです。提案しますが、健全な状態を確保するために監視しなければならないメトリクスのコアセットを定義することから始めましょう - CPU、サーバー RAM、ノードプロセス RAM（1.4GB未満）、最後の1分間のエラーの数、プロセスの再起動の数、平均応答時間。その後、あなたが好きそうないくつかの高度な機能を確認し、あなたの希望のリストに追加してください。豪華なモニタリング機能の例をいくつか紹介します: DB プロファイリング、クロスサービス測定（ビジネストランザクションの測定など）、フロントエンド統合、カスタム BI クライアントへの生データの公開、Slack通知など。
高度な機能を実現するためには、セットアップに時間がかかるか、Datadog や NewRelic などの商用製品を購入する必要があります。残念ながら、いくつかのメトリクスはハードウェア関連（ CPU）であり、他のメトリクスはノードプロセス内に存在する（内部エラー）ため、すべての簡単なツールは追加のセットアップが必要であり、基本的なことでさえも達成することは簡単ではありません。例えば、クラウドベンダーの監視ソリューション（例：AWS CloudWatch、Google StackDriver）は、ハードウェアのメトリクスについてはすぐに教えてくれますが、内部のアプリの動作については教えてくれません。一方、ElasticSearch のようなログベースのソリューションは、デフォルトでハードウェアビューがありません。解決策は、欠落しているメトリクスを補強することです。例えば、一般的な選択肢は、アプリケーションログを Elastic stack に送信し、ハードウェア関連の情報を共有して全体像を把握するために、いくつかの追加エージェント(例えば Beat )を設定することです。
Rising Stack のブログより:
...すべてのサービスのために、これらの信号を見ることをお勧めします: エラー率: なぜなら、エラーはユーザーが直面するものであり、すぐに顧客に影響を与えるからです。 応答時間: 待ち時間が直接顧客やビジネスに影響を与えるからです。 スループット: トラフィックは、エラー率と遅延の増加のコンテキストを理解するのに役立ちます。 飽和: サービスがどの程度「フル」であるかを示します。CPU 使用率が 90% の場合、システムはより多くのトラフィックを処理できますか？…