クラウドコンソールでのマイクロサービスのトラブルシューティング
前回は、 マイクロサービスのクライアント拡張 を使って、Liferay でフィードバックエントリが送信されたときのログをテストしました。 さて、KyleはSpring Bootアプリケーションに単純なカウンター変数を追加して、エントリーの総数を記録したいと考えている。
ここでは、 以前にデプロイしたサンプルクライアント拡張プロジェクトを修正し、クラウド コンソールで問題が発生した場合のトラブルシューティングを行い、問題を解決します。
オブジェクトアクション REST コントローラにカウンタを追加する
サンプル Spring Boot クライアント拡張 は ObjectAction1RestController.java ファイルを使用して、Liferay から受け取ったオブジェクトデータをログに記録します。 Kyleは、それぞれの新しいフィードバックエントリをカウントし、新しいログメッセージのための既存のエントリ数に追加する単純な変数を追加したいと考えています。
この動作を実装するためのコードを追加する。
-
liferay-sample-etc-spring-bootフォルダで、 Spring Boot プロジェクトをデプロイした 、src/main/java/com/liferay/sample/ObjectAction1RestController.javaファイルを開きます。 -
count変数をクラスのフィールドとして追加する：public class ObjectAction1RestController extends BaseRestController { private int count = 0; ... -
既存のエントリーの値を注入するために、別のフィールドを追加する：
@Value("${EXISTING_FEEDBACK}") protected int existingFeedback; -
このバリュー・インジェクションが機能するように、
import：import org.springframework.beans.factory.annotation.Value; -
ロギングを追加するには、これらの新しい変数を使用します。
postメソッドのreturnステートメントの前に以下の行を追加する：count++; int total = count + existingFeedback; _log.info("Total feedback so far: " + total);
これで、最小限のカウンターを実装するのに十分なコードができた。
更新されたプロジェクトをデプロイする
liferay-sample-etc-spring-boot/ フォルダでコマンドラインを開き、プロジェクトを再構築してデプロイしてください。
-
プロジェクトを新しいデプロイ可能なLUFFAにビルドする：
../../gradlew clean build -
CLIツールを使用して、ビルドされたLUFFAをデプロイします：
lcp deploy --extension dist/liferay-sample-etc-spring-boot.zipプロンプトが表示されたら、UATクライアントの拡張環境に対応する番号を選択します。
クライアント拡張プロジェクトがデプロイされ、遅れてクラウドコンソールに表示されます。
マイクロサービスをチェックする
liferaysampleetcspringboot サービスがクラウドコンソールに表示されるが、しばらく待っても「Ready」ステータスが表示されないようだ。
以前と同じように、オブジェクトのアクションをトリガーしてみてください。
-
UATのLiferayインスタンスにログインします。
-
フォームの Submit をクリックして、新しいオブジェクトエントリーを作成し、アクションをトリガーする。
-
クラウド・コンソールに戻り、
liferaysampleetcspringbootサービスをクリックする。
分待っても、ログには追加した新しいメッセージは表示されないし、新しいエントリーのログも表示されない。 上にエラーメッセージが表示されているのもわかるだろう。
しばらく待つと、これらのエラーのためにサービスが継続的に再起動していることがわかる。 新しいコードは何かを壊しているようだ。
アプリケーションログの検索
Liferay Cloud のコンソールで、アプリケーションのログを検索し、マイクロサービスで何がうまくいかなかったかの兆候を探します。 ログページを使用すると、フィルタリングや検索ツールを使って関連情報を見つけることができます。
-
左側のメニューから Logs を選択する。
-
Logs ページで、画面上部のドロップダウンメニューから Application logs が選択されていることを確認する。
クライアント・エクステンション・サービスは1つしか実行されていないので、サービス別にフィルタリングする必要はない。
-
"feedback "で検索して、追加した新しい変数に関連するヒントを探してください。
ログは完全なスタック・トレースまでフィルタリングされ、 Exception のルートが、インジェクションによって追加された変数と明らかに関連している。
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'EXISTING_FEEDBACK' in value "${EXISTING_FEEDBACK}"
Spring Bootは EXISTING_FEEDBACK の値をどこにも見つけられないのだ！
不足している環境変数を追加する
Spring Bootはコンテナ内の同名の環境変数から値を注入できる。 サービスの環境変数として EXISTING_FEEDBACK の値を追加してみてください。
-
左側メニューの Services をクリックすると、
liferaysampleetcspringbootサービスが表示される場所に戻ります。 -
liferaysampleetcspringbootサービスをクリックする。 -
［環境変数］ タブをクリックします。
-
レギュラー変数リストに新しい環境変数を追加する。
EXISTING_FEEDBACKをキーに、2を値として追加する（これまでに作成した2つのエントリーについて）。
-
Save Changes をクリックします。
-
画面上部の Actions メニュー(
)をクリックし、 Restart Service をクリックして、新しい変数が適切に初期化されるようにします。
サービスは、新しい環境変数で遅延後に再スタートする。
環境変数が存在することを確認する
シェルを使って、変数がSpring Bootが検出できる環境にあることを確認する。 コンソールでシェルにアクセスすると、マイクロサービスが実行されているコンテナに直接入ることができる。
-
サービスのページで、 Shell タブをクリックします。
-
printenvコマンドを使って、新しい環境変数が存在するかどうかをチェックする：
printenv | grep "EXISTING"
環境変数は、Spring Bootが使用できる場所に存在する。
新しいログをもう一度テストする
新しい変更をもう一度テストしてみてください。
-
UATのLiferayインスタンスに戻ってください（ログインしていることを確認してください）。
-
入力オブジェクトのフォームで Submit をクリックします。
-
再びクラウド・コンソールに戻り、
liferaysampleetcspringbootサービス・ページに移動してログを見る。
これで、オブジェクトアクションクライアントエクステンションが再び機能し、新しいログメッセージが既存のログと一緒に表示されるのがわかります。 Liferayインスタンスでより多くの値を送信すると、カウンタの値はその都度増分します。
Liferay Experience Cloud の最終モジュールが完了しました。 コースの残りは、Liferay Experience Cloud Self-Managedに焦点を当てます。
次へ クラウド構成.