第9章 OpenShift Dev Spaces のトラブルシューティング


本セクションでは、ユーザーが競合する可能性のある最も頻繁に発生する問題についてのトラブルシューティング手順を説明します。

9.1. OpenShift Dev Spaces ワークスペースログの表示

このセクションでは、OpenShift Dev Spaces ワークスペースのログを表示する方法を説明します。

9.1.1. 言語サーバーおよびデバッグアダプターのログの表示

9.1.1.1. 重要なログの確認

本セクションでは、重要なログを確認する方法を説明します。

手順

  1. OpenShift web コンソールで、Applications Pods をクリックし、すべてのアクティブなワークスペースの一覧を表示します。
  2. ワークスペースが実行されている実行中の Pod の名前をクリックします。Pod 画面には、追加情報が含まれるすべてのコンテナーの一覧が含まれます。
  3. コンテナーを選択し、コンテナー名をクリックします。

    注記

    最も重要なログは、theia-ide コンテナーとプラグインコンテナーログです。

  4. コンテナー画面で、Logs セクションに移動します。

9.1.1.2. メモリー問題の検出

本セクションでは、メモリー不足のプラグインに関連するメモリーの問題を検出する方法を説明します。以下は、メモリー不足のプラグインに関連する 2 つの最もよく見られる問題になります。

プラグインコンテナーがメモリー不足になる
これは、コンテナーにイメージのエントリーポイントを実行するのに十分な RAM がない場合に、プラグインの初期化時に発生する可能性があります。ユーザーはプラグインコンテナーのログでこれを検知できます。この場合、ログには OOMKilled が含まれます。これは、コンテナーのプロセスがコンテナーで利用可能な量よりも多くのメモリーを要求することを示唆します。
コンテナー内のプロセスがコンテナーの通知なしにメモリー不足になる

たとえば、Java 言語サーバー (vscode-java 拡張によって起動する Eclipse JDT Language Server) は OutOfMemoryException を出力します。これは、プラグインが言語サーバーを起動する際、または処理する必要があるプロジェクトのサイズによりプロセスがメモリー不足になる場合などに、コンテナーの初期化後いつでも発生する可能性があります。

この問題を検出するには、コンテナーで実行しているプライマリープロセスのログを確認します。たとえば、Eclipse JDT Language Server のログファイルで詳細を確認するには、関連するプラグイン固有のセクションを参照してください。

9.1.1.3. デバッグアダプター用のクライアントサーバーのトラフィックのロギング

本セクションでは、Che-Theia とデバッグアダプター間のやり取りのログを Output ビューに記録する方法を説明します。

前提条件

  • Debug アダプター のオプションを一覧に表示するには、デバッグセッションを開始する必要がある。

手順

  1. File SettingsPreferences をクリックします。
  2. Preferences ビューの Debug セクションを展開します。
  3. trace 設定の値を true に設定します (デフォルトは false です)。

    すべての通信イベントがログに記録されます。

  4. これらのイベントを確認するには、View Output をクリックし、Output ビューの右上にあるドロップダウンリストから Debug adapters を選択します。

9.1.1.4. Python のログの表示

本セクションでは、Python 言語サーバーのログを表示する方法を説明します。

手順

  • Output view ビューに移動し、ドロップダウンリストで Python を選択します。

    viewing logs for python

9.1.1.5. Go のログの表示

本セクションでは、Go 言語サーバーのログを表示する方法を説明します。

9.1.1.5.1. Go パスの検索

本セクションでは、GOPATH 変数が参照する場所を見つける方法を説明します。

手順

  • Go: Current GOPATH コマンドを実行します。

    Go パスの検索
    Viewing the Go path
9.1.1.5.2. Go の Debug Console ログの表示

本セクションでは、Go デバッガーからのログ出力を表示する方法を説明します。

手順

  1. デバッグ設定で showLog 属性を true に設定します。

    {
      "version": "0.2.0",
      "configurations": [
         {
            "type": "go",
            "showLog": true
           ....
         }
      ]
    }
  2. コンポーネントのデバッグ出力を有効にするには、パッケージを logOutput 属性のコンマ区切りの一覧に追加します。

    {
      "version": "0.2.0",
      "configurations": [
         {
            "type": "go",
            "showLog": true,
            "logOutput": "debugger,rpc,gdbwire,lldbout,debuglineerr"
           ....
         }
      ]
    }
  3. デバッグコンソールは、デバッグコンソールに追加情報を出力します。

    viewing debug console log for go
9.1.1.5.3. Output パネルでの Go ログ出力の表示

本セクションでは、Output パネルで Go ログ出力を表示する方法を説明します。

手順

  1. Output ビューに移動します。
  2. ドロップダウンリストで Go を選択します。

    viewing go logs output in the output panel

9.1.1.6. NodeDebug NodeDebug2 アダプターのログの表示

注記

一般的な診断以外の特定の診断はありません。

9.1.1.7. Typescript のログの表示

9.1.1.7.1. Label Switched Protocol (LSP) トレースの有効化

手順

  1. Typescript (TS) サーバーに送信されるメッセージのトレースを有効にするには、Preferences ビューで typescript.tsserver.trace 属性を verbose に設定します。これを使用して、TS サーバーの問題を診断します。
  2. TS サーバーのファイルへのロギングを有効にするには、typescript.tsserver.log 属性を verbose に設定します。このログを使用して、TS サーバーの問題を診断します。ログにはファイルパスが含まれます。
9.1.1.7.2. Typescript 言語サーバーログの表示

本セクションでは、Typescript 言語サーバーのログを表示する方法を説明します。

手順

  1. ログファイルへのパスを取得するには、Typescript Output コンソールを参照してください。

    finding the typescript language server log
  2. ログファイルを開くには、Open TS Server log コマンドを使用します。

    viewing typescript language server log
9.1.1.7.3. Output パネルでの Typescript ログ出力の表示

本セクションでは、Output パネルで Typescript ログの出力を表示する方法を説明します。

手順

  1. Output ビューに移動します。
  2. ドロップダウンリストで TypeScript を選択します。

    viewing typescript logs output in the output panel

9.1.1.8. Java のログの表示

一般的な診断以外に、ユーザーは Language Support for Java(Eclipse JDT Language Server) プラグインの各種アクションを実行できます。

9.1.1.8.1. Eclipse JDT Language Server の状態の確認

手順

Eclipse JDT Language Server プラグインを実行しているコンテナーが Eclipse JDT Language Server のメインプロセスを実行しているかどうかを確認します。

  1. Eclipse JDT Language Server プラグインを実行しているコンテナーでターミナルを開きます (コンテナーのサンプル名: vscode-javaxxx)。
  2. ターミナル内で ps aux | grep jdt コマンドを実行して、Eclipse JDT Language Server プロセスがコンテナーで実行されているかどうかを確認します。プロセスが実行されている場合、出力は以下のようになります。

    usr/lib/jvm/default-jvm/bin/java --add-modules=ALL-SYSTEM --add-opens java.base/java.util

    このメッセージは、使用される Visual Studio Code Java 拡張機能も表示します。言語サーバーが実行されていない場合には、これはコンテナー内で起動していません。

  3. 「OpenShift Dev Spaces ワークスペースログの表示」 で説明されているすべてのログを確認してください。
9.1.1.8.2. Eclipse JDT Language Server 機能の確認

手順

Eclipse JDT Language Server プロセスを実行している場合は、言語サーバーの機能が機能しているかどうかを確認します。

  1. Java ファイルを開き、ホバーや自動補完機能を使用します。誤りのあるファイルの場合、ユーザーはこの Outline ビューまたは Problems ビューで Java を確認できます。
9.1.1.8.3. Java 言語サーバーログの表示

手順

Eclipse JDT Language Server には、エラー、実行されたコマンド、およびイベントについてのログを記録する独自のワークスペースがあります。

  1. このログファイルを開くには、Eclipse JDT Language Server プラグインを実行しているコンテナーでターミナルを開きます。Java: Open Java Language Server log file コマンドを実行してログファイルを表示することもできます。
  2. cat <PATH_TO_LOG_FILE> を実行します。PATH_TO_LOG_FILE/home/theia/.theia/workspace-storage/<workspace_name>/redhat.java/jdt_ws/.metadata/.log になります。
9.1.1.8.4. Java Language Server Protocol (LSP) メッセージのロギング

手順

LSP メッセージのログを Visual Studio Code Output ビューに記録するには、java.trace.server 属性を verbose に設定してトレースを有効にします。

関連情報

トラブルシューティングの手順については、Visual Studio Code Java GitHub リポジトリーを参照してください。

9.1.1.9. Intelephense のログの表示

9.1.1.9.1. Intelephense クライアントサーバー通信のロギング

手順

PHP Intelephense 言語のサポートを、クライアントサーバー接続のログを Output ビューに記録するように設定するには、以下を実行します。

  1. File Settings をクリックします。
  2. Preferences ビューを開きます。
  3. Intelephense セクションを拡張し、trace.server.verbose 設定値を verbose に設定してすべての通信イベントを表示します (デフォルト値は off です)。
9.1.1.9.2. Output パネルでの Intelephense イベントの表示

この手順では、Output パネルで Intelephense イベントを表示する方法を説明します。

手順

  1. View Output をクリックします。
  2. Output ビューのドロップダウンリストで Intelephense を選択します。

9.1.1.10. PHP-Debug のログの表示

この手順では、PHP Debug プラグインの診断メッセージのログを Debug Console ビューに記録するように PHP Debug プラグインを設定する方法を説明します。デバッグセッションの開始前にこれを設定します。

手順

  1. launch.json ファイルで、"log": true 属性を php 設定に追加します。
  2. デバッグセッションを開始します。
  3. 診断メッセージは、アプリケーションの出力と共に Debug Console ビューに出力されます。

9.1.1.11. XML のログの表示

一般的な診断以外に、ユーザーが実行できる XML プラグイン固有のアクションがあります。

9.1.1.11.1. XML 言語サーバーの状態の確認

手順

  1. vscode-xml-<xxx> という名前のコンテナーでターミナルを開きます。
  2. ps aux | grep java を実行して、XML 言語サーバーが起動していることを確認します。プロセスが実行されている場合、出力は以下のようになります。

    java ***/org.eclipse.ls4xml-uber.jar`

    そうでない場合は、「OpenShift Dev Spaces ワークスペースログの表示」 の章を参照してください。

9.1.1.11.2. XML 言語サーバーの機能フラグの確認

手順

  1. 機能が有効にされているかどうかを確認します。XML プラグインは、機能を有効かつ無効にできる複数の設定を提供します。

    • xml.format.enabled: フォーマッターを有効にします。
    • xml.validation.enabled: 検証を有効にします。
    • xml.documentSymbols.enabled: ドキュメントシンボルを有効にします。
  2. XML 言語サーバーが機能しているかどうかを確認するには、<hello></hello> などの単純な XML 要素を作成し、右側の Outline パネルに表示されることを確認します。
  3. ドキュメントのシンボルが表示されない場合は、xml.documentSymbols.enabled 属性が true に設定されていることを確認します。true の場合でシンボルがない場合は、言語サーバーはエディターにフックされない可能性があります。ドキュメントのシンボルがある場合は、言語サーバーがエディターに接続されます。
  4. ユーザーが必要とする機能が、設定の true に設定されていることを確認します (デフォルトでは true に設定されます)。機能のいずれかが機能していないか、または予想通りに機能しない場合は、言語サーバー に対する問題を報告します。
9.1.1.11.3. XML Language Server Protocol (LSP) トレースの有効化

手順

LSP メッセージのログを Visual Studio Code Output ビューに記録するには、xml.trace.server 属性を verbose に設定してトレースを有効にします。

9.1.1.11.4. XML 言語サーバーログの表示

手順

言語サーバーのログは、/home/theia/.theia/workspace-storage/<workspace_name>/redhat.vscode-xml/lsp4xml.log のプラグインサイドカーコンテナーにあります。

9.1.1.12. YAML のログの表示

本セクションでは、一般的な診断のほかに、ユーザーが実行できる YAML プラグインに固有のアクションについて説明します。

9.1.1.12.1. YAML 言語サーバーの状態の確認

本セクションでは、YAML 言語サーバーの状態を確認する方法を説明します。

手順

YAML プラグインを実行するコンテナーが YAML 言語サーバーを実行しているかどうかを確認します。

  1. エディターを使用し、YAML プラグインを実行しているコンテナーでターミナルを開きます (コンテナーの名前の例: vscode-yaml-<xxx>)。
  2. ターミナルで ps aux | grep node コマンドを実行します。このコマンドは、現在のコンテナーで実行されているすべてのノードプロセスを検索します。
  3. コマンド node **/server.js が実行していることを確認します。

    YAML 言語サーバーの状態の確認

コンテナーで実行している node **/server.js は、言語サーバーが実行していることを示します。これが実行されていない場合、言語サーバーはコンテナー内で起動していません。この場合は、「OpenShift Dev Spaces ワークスペースログの表示」 を参照してください。

9.1.1.12.2. YAML 言語サーバーの機能フラグの確認

手順

機能フラグを確認するには、以下を実行します。

  1. 機能が有効にされているかどうかを確認します。YAML プラグインは、以下のような機能を有効および無効にできる複数の設定を提供します。

    • xml.format.enabled: フォーマッターを有効にします。
    • yaml.validate: 検証を有効にします。
    • yaml.hover: ホバー機能を有効にします。
    • yaml.completion: 補完 (completion) 機能を有効にします。
  2. プラグインが機能しているかどうかを確認するには、hello: world などの最も簡単な YAML を入力してから、エディターの右側にある Outline パネルを開きます。
  3. ドキュメントのシンボルがあるかどうかを確認します。yes の場合、言語サーバーはエディターに接続されます。
  4. いずれの機能も機能していない場合は、上記の設定が true に設定されていることを確認してください (デフォルトでは true に設定されます)。この機能が機能していない場合は、言語サーバー に対する問題を報告します。
9.1.1.12.3. YAML Language Server Protocol (LSP) トレースの有効化

手順

LSP メッセージのログを Visual Studio Code Output ビューに記録するには、yaml.trace.server 属性を verbose に設定してトレースを有効にします。

9.1.1.13. OmniSharp-Theia プラグインを使用した .NET のログの表示

9.1.1.13.1. Omnisharp-Theia プラグイン

OpenShift Dev Spaces は、OmniSharp-Theia プラグインをリモートプラグインとして使用します。これは github.com/redhat-developer/omnisharp-theia-plugin にあります。問題が生じた場合は、これを報告し、修正をリポジトリーにコントリビュートします。

このプラグインは omnisharp-roslyn を言語サーバーとして登録し、C# アプリケーションについてのプロジェクトの依存関係および言語構文を提供します。

言語サーバーは、.NET SDK 2.2.105 で実行されます。

9.1.1.13.2. OmniSharp-Theia プラグイン言語サーバーの状態の確認

手順

Omnisharp-Theia プラグインを実行するコンテナーが OmniSharp を実行しているかどうかを確認するには、ps aux | grep OmniSharp.exe コマンドを実行します。プロセスが実行されている場合、以下が出力例になります。

/tmp/theia-unpacked/redhat-developer.che-omnisharp-plugin.0.0.1.zcpaqpczwb.omnisharp_theia_plugin.theia/server/bin/mono
/tmp/theia-unpacked/redhat-developer.che-omnisharp-plugin.0.0.1.zcpaqpczwb.omnisharp_theia_plugin.theia/server/omnisharp/OmniSharp.exe

出力が異なる場合、言語サーバーはコンテナー内で起動していません。「OpenShift Dev Spaces ワークスペースログの表示」 で説明されているログを確認してください。

9.1.1.13.3. OmniSharp Che-Theia プラグインの言語サーバー機能の確認

手順

  • OmniSharp.exe プロセスが実行されている場合、.cs ファイルを開き、ホバーまたは補完機能を試行するか、または Problems または Outline ビューを開いて、言語サーバーの機能が機能しているかどうかを確認します。
9.1.1.13.4. OmniSharp-Theia プラグインログの Output パネルでの表示

手順

OmniSharp.exe が実行されている場合、Output パネルのすべての情報のログが記録されます。ログを表示するには、Output ビューを開き、ドロップダウンリストから C# を選択します。

9.1.1.14. NetcoredebugOutput プラグインを使用した .NET のログの表示

9.1.1.14.1. NetcoredebugOutput プラグイン

NetcoredebugOutput プラグインは、netcoredbg ツールを提供します。このツールは、Visual Studio Code Debug Adapter プロトコルを実装し、ユーザーが .NET Core ランタイムで .NET アプリケーションをデバッグできるようにします。

NetcoredebugOutput プラグインが実行されているコンテナーには .NET SDK v.2.2.105 が含まれます。

9.1.1.14.2. NetcoredebugOutput プラグインの状態の確認

手順

  1. launch.json ファイルに netcoredbg デバッグ設定があるかどうかを確認します。

    例9.1 デバッグ設定のサンプル

    {
     "type": "netcoredbg",
     "request": "launch",
     "program": "${workspaceFolder}/bin/Debug/<target-framework>/<project-name.dll>",
     "args": [],
     "name": ".NET Core Launch (console)",
     "stopAtEntry": false,
     "console": "internalConsole"
    }
  2. launch.json ファイルの configuration セクションの中括弧内で自動補完機能をテストします。netcoredbg が見つかる場合、Che-Theia プラグインは正しく初期化されています。そうでない場合は、「OpenShift Dev Spaces ワークスペースログの表示」 を参照してください。
9.1.1.14.3. NetcoredebugOutput プラグインログの Output パネルでの表示

本セクションでは、Output パネルで NetcoredebugOutput プラグインログを表示する方法を説明します。

手順

  • Debug コンソールを開きます。

    Viewing NetcoredebugOutput plug-in logs in the *Output* panel

9.1.1.15. Camel のログの表示

9.1.1.15.1. Camel 言語サーバーの状態の確認

手順

ユーザーは、vscode-apache-camel<xxx> Camel コンテナーに保存される Camel 言語ツールを使用して、サイドカーコンテナーのログ出力を検査できます。

言語サーバーの状態を確認するには、以下のコマンドを実行します。

  1. vscode-apache-camel<xxx> コンテナー内でターミナルを開きます。
  2. ps aux | grep java コマンドを実行します。以下は、言語サーバープロセスの例です。

    java -jar /tmp/vscode-unpacked/camel-tooling.vscode-apache-camel.latest.euqhbmepxd.camel-tooling.vscode-apache-camel-0.0.14.vsix/extension/jars/language-server.jar
  3. 見つからない場合は、「OpenShift Dev Spaces ワークスペースログの表示」 を参照してください。
9.1.1.15.2. Camel ログの Output パネルでの表示

Camel 言語サーバーは、そのログを $\{java.io.tmpdir}/log-camel-lsp.out ファイルに書き込む SpringBoot アプリケーションです。$\{java.io.tmpdir}/tmp ディレクトリーを参照するため、ファイル名は /tmp/log-camel-lsp.out になります。

手順

Camel 言語サーバーのログは、Language Support for Apache Camel という名前の Output チャネルに出力されます。

注記

出力チャネルは、クライアントサイドで最初にログエントリーが作成される際にのみ作成されます。これは、問題がない場合には存在しない場合があります。

viewing camel logs in the output panel

9.1.2. Che-Theia IDE ログの表示

本セクションでは、Che-Theia IDE ログを表示する方法を説明します。

9.1.2.1. OpenShift CLI を使用した Che-Theia エディターログの表示

Che-Theia エディターログの確認は、エディターによって読み込まれるプラグインについてよりよく理解し、知見を得るのに役立ちます。本セクションでは、OpenShift CLI (コマンドコマンドラインインターフェイス) を使用して Che-Theia エディターログにアクセスする方法を説明します。

前提条件

  • OpenShift Dev Spaces は OpenShift クラスターにデプロイされます。
  • ワークスペースが作成されています。
  • ユーザーは OpenShift Dev Spaces インストールプロジェクトにいます。

手順

  1. 利用可能な Pod の一覧を取得します。

    $ oc get pods

    $ oc get pods
    NAME                                              READY  STATUS   RESTARTS  AGE
    devspaces-9-xz6g8                                 1/1    Running  1         15h
    workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2  4/4    Running  0         1h

  2. 特定の Pod で利用可能なコンテナーの一覧を取得します。

    $ oc get pods <name-of-pod> --output jsonpath='\{.spec.containers[*].name}'

    以下に例を示します。

    $ oc get pods workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 -o
    jsonpath='\{.spec.containers[*].name}'
    > go-cli che-machine-exechr7 theia-idexzb vscode-gox3r

  3. theia/ide コンテナーからログを取得します。

    $ oc logs --follow <name-of-pod> --container <name-of-container>

    以下に例を示します。

    $ oc logs --follow workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 -container
    theia-idexzb
    >root INFO unzipping the plug-in 'task_plugin.theia' to directory: /tmp/theia-unpacked/task_plugin.theia
    root INFO unzipping the plug-in 'theia_yeoman_plugin.theia' to directory: /tmp/theia-unpacked/theia_yeoman_plugin.theia
    root WARN A handler with prefix term  is already registered.
    root INFO [nsfw-watcher: 75] Started watching: /home/theia/.theia
    root WARN e.onStart is slow, took: 367.4600000013015 ms
    root INFO [nsfw-watcher: 75] Started watching: /projects
    root INFO [nsfw-watcher: 75] Started watching: /projects/.theia/tasks.json
    root INFO [4f9590c5-e1c5-40d1-b9f8-ec31ec3bdac5] Sync of 9 plugins took: 62.26000000242493 ms
    root INFO [nsfw-watcher: 75] Started watching: /projects
    root INFO [hosted-plugin: 88] PLUGIN_HOST(88) starting instance

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.