nginxを実行しているEC2インスタンスがクラッシュし、「接続が拒否されました」-これを監視するにはどうすればよいですか？
EC2インスタンスでnginxがクラッシュすると言います。インスタンスは正常であり、CloudWatch Metricsは優れていますが、サーバーでホストされているすべてのドメインが「接続拒否」になっています。
これは非常に基本的な機能のようです。Webサイトが200を返していることを確認するための監視です。これはCloudWatchのどこかにありますか？何かがちょうどcurl -s -o /dev/null -w "%{http_code}" http://www.example.org/そして、200のリターンコードを受け取らない場合、たとえば5回続けて受け取ると、インスタンスの再起動とSNS通知がトリガーされます。
おそらく、何かに到達できない場合にnginxを再起動するEC2インスタンスで実行する必要があるものがありますか？いずれにせよ、AWSリソースを使用してこれを行う方法を知りたいので、任意のサイトを監視してSNSを開始することもできます。
ここで簡単なものが足りない場合は申し訳ありません。これは簡単に検索できるもののようですが、私はこれを理解するために何ヶ月にもわたって何時間も費やしました。
これは通常、インスタンス上のWebサーバーが実行されているかどうかを検出できるロードバランサー（ALBまたはELB）のジョブであり、そうでない場合はCloudWatch。繰り返しますが、通常、Auto Scaling Groupによるインスタンスの置き換え。
単一のインスタンスのみが必要な場合でも、ASGとALBを使用することは完全に正常です。
または、インスタンスにインストールされているCWエージェントを使用してカスタムCloudWatchメトリックを作成することもできます。その後、あなたはあなたが欲しいものを報告することができます。
それが役に立てば幸い:)
IMHO、Nginxが応答を停止したためにインスタンスを置き換えることは、優れたエンジニアリングソリューションではありません。インスタンスの交換には数分かかる場合があるため、これをAWSに依存すると、その間サービスがオフラインになりますが、単純なNginxのリロードには1秒未満かかります。
Nginxは非常に堅牢なテクノロジーです。信頼性のためにAWSソリューションを検討しているところまで失敗した場合は、おそらく戻ってNginxのセットアップを検討する必要があります。 AWSについて学びたいと思っていることを感謝しますが、これは良いユースケースではないと思います。
質問に答えるには：AWSでサイトの信頼性を実現する方法は無数にあります。単一のインスタンスで追加コストなしで実行したい場合、ターンキーソリューションとしてElasticBeanstalkをお勧めします。それはあなたが提供するヘルスチェックに基づいてあなたが必要とするすべての必要な信頼性メカニズムを適用します。すべてのSRE操作の最終的な宛先であるElasticBeanStalkでDockerを活用することもできます。