此内容没有您所选择的语言版本。

Chapter 9. Troubleshooting Dev Spaces


This section provides troubleshooting procedures for the most frequent issues a user can come in conflict with.

9.1. Viewing Dev Spaces workspaces logs

You can view OpenShift Dev Spaces logs to better understand and debug background processes should a problem occur.

An IDE extension misbehaves or needs debugging
The logs list the plugins that have been loaded by the editor.
The container runs out of memory
The logs contain an OOMKilled error message. Processes running in the container attempted to request more memory than is configured to be available to the container.
A process runs out of memory
The logs contain an error message such as OutOfMemoryException. A process inside the container ran out of memory without the container noticing.

9.1.1. Workspace logs in CLI

You can use the OpenShift CLI to observe the OpenShift Dev Spaces workspace logs.

Prerequisites

  • The OpenShift Dev Spaces workspace <workspace_name> is running.
  • Your OpenShift CLI session has access to the OpenShift project <namespace_name> containing this workspace.

Procedure

  • Get the logs from the pod running the <workspace_name> workspace in the <namespace_name> project:

    $ oc logs --follow --namespace='<workspace_namespace>' \
      --selector='controller.devfile.io/devworkspace_name=<workspace_name>'

9.1.2. Workspace logs in OpenShift console

You can use the OpenShift console to observe the OpenShift Dev Spaces workspace logs.

Procedure

  1. In the OpenShift Dev Spaces dashboard, go to Workspaces.
  2. Click on a workspace name to display the workspace overview page. This page displays the OpenShift project name <project_name>.
  3. Click on the upper right Applications menu, and click the OpenShift console link.
  4. Run the next steps in the OpenShift console, in the Administrator perspective.
  5. Click Workloads > Pods to see a list of all the active workspaces.
  6. In the Project drop-down menu, select the <project_name> project to narrow the search.
  7. Click on the name of the running pod that runs the workspace. The Details tab contains the list of all containers with additional information.
  8. Go to the Logs tab.

9.1.3. Language servers and debug adapters logs in the editor

In the Microsoft Visual Studio Code - Open Source editor running in your workspace, you can configure the installed language server and debug adapter extensions to view their logs.

Procedure

  1. Configure the extension: click File > Preferences > Settings, expand the Extensions section, search for your extension, and set the trace.server or similar configuration to verbose, if such configuration exists. Refer to the extension documentation for further configuration.
  2. View your language server logs by clicking View Output, and selecting your language server in the drop-down list for the Output view.

Additional resources

9.2. Troubleshooting slow workspaces

Sometimes, workspaces can take a long time to start. Tuning can reduce this start time. Depending on the options, administrators or users can do the tuning.

This section includes several tuning options for starting workspaces faster or improving workspace runtime performance.

9.2.1. Improving workspace start time

Caching images with Image Puller

Role: Administrator

When starting a workspace, OpenShift pulls the images from the registry. A workspace can include many containers meaning that OpenShift pulls Pod’s images (one per container). Depending on the size of the image and the bandwidth, it can take a long time.

Image Puller is a tool that can cache images on each of OpenShift nodes. As such, pre-pulling images can improve start times. See https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.15/html-single/administration_guide/index#administration-guide:caching-images-for-faster-workspace-start.

Choosing better storage type

Role: Administrator and user

Every workspace has a shared volume attached. This volume stores the project files, so that when restarting a workspace, changes are still available. Depending on the storage, attach time can take up to a few minutes, and I/O can be slow.

Installing offline

Role: Administrator

Components of OpenShift Dev Spaces are OCI images. Set up Red Hat OpenShift Dev Spaces in offline mode to reduce any extra download at runtime because everything needs to be available from the beginning. See https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.15/html-single/administration_guide/index#administration-guide:installing-che-in-a-restricted-environment.

Reducing the number of public endpoints

Role: Administrator

For each endpoint, OpenShift is creating OpenShift Route objects. Depending on the underlying configuration, this creation can be slow.

To avoid this problem, reduce the exposure. For example, to automatically detect a new port listening inside containers and redirect traffic for the processes using a local IP address (127.0.0.1), Microsoft Visual Code - Open Source has three optional routes.

By reducing the number of endpoints and checking endpoints of all plugins, workspace start can be faster.

9.2.2. Improving workspace runtime performance

Providing enough CPU resources

Plugins consume CPU resources. For example, when a plugin provides IntelliSense features, adding more CPU resources can improve performance.

Ensure the CPU settings in the devfile definition, devfile.yaml, are correct:

components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-latest
      cpuLimit: 4000m 1
      cpuRequest: 1000m 2
1
Specifies the CPU limit
2
Specifies the CPU request
Providing enough memory

Plug-ins consume CPU and memory resources. For example, when a plugin provides IntelliSense features, collecting data can consume all the memory allocated to the container.

Providing more memory to the container can increase performance. Ensure that memory settings in the devfile definition devfile.yaml file are correct.

components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-latest
      memoryLimit: 6G 1
      memoryRequest: 512Mi 2
1
Specifies the memory limit
2
Specifies the memory request

9.3. Troubleshooting network problems

This section describes how to prevent or resolve issues related to network policies. OpenShift Dev Spaces requires the availability of the WebSocket Secure (WSS) connections. Secure WebSocket connections improve confidentiality and also reliability because they reduce the risk of interference by bad proxies.

Prerequisites

  • The WebSocket Secure (WSS) connections on port 443 must be available on the network. Firewall and proxy may need additional configuration.

Procedure

  1. Verify the browser supports the WebSocket protocol. See: Searching a websocket test.
  2. Verify firewalls settings: WebSocket Secure (WSS) connections on port 443 must be available.
  3. Verify proxy servers settings: The proxy transmits and intercepts WebSocket Secure (WSS) connections on port 443.

9.4. Troubleshooting webview loading error

If you use Microsoft Visual Studio Code - Open Source in a private browsing window, you might encounter the following error message: Error loading webview: Error: Could not register service workers.

This is a known issue affecting following browsers:

  • Google Chrome in Incognito mode
  • Mozilla Firefox in Private Browsing mode
Table 9.1. Dealing with the webview error in a private browsing window
Browser

Workarounds

Google Chrome

Go to Settings Privacy and security Cookies and other site data Allow all cookies.

Mozilla Firefox

Webviews are not supported in Private Browsing mode. See this reported bug for details.

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.