3.6. 配置可观察性
要配置 OpenShift Dev Spaces observability 功能,请参阅:
3.6.1. Che-Theia 工作区
3.6.1.1. Telemetry 概述
Telemetry 是操作数据的显式和 ethical 集合。默认情况下,Red Hat OpenShift Dev Spaces 不提供遥测(Telemetry),但在 Che- Theia 编辑器中提供了一个抽象 API,允许使用插件机制和 chectl
命令行工具使用数据来收集遥测。此方法用于"红帽托管的 Eclipse Che"服务"为每个 Che-Theia 工作区启用遥测(Telemetry)。
本文档包含介绍如何为 Red Hat OpenShift Dev Spaces 创建自己的遥测客户端,以及 Red Hat OpenShift Dev Spaces Woopra Telemetry 插件的概述信息。
3.6.1.2. 使用案例
Red Hat OpenShift Dev Spaces 遥测 API 允许跟踪:
- 工作区使用率的持续时间
- 用户驱动的操作,如文件编辑、提交和推送到远程存储库。
- 工作区中使用的编程语言和 devfile。
3.6.1.3. 如何使用
当 Dev Workspace 启动时,che-theia
容器会启动遥测插件,该插件负责将遥测事件发送到后端。如果在 Dev Workspace Pod 中设置了 $DEVWORKSPACE_TELEMETRY_BACKEND_PORT
环境变量,遥测插件会将事件发送到侦听该端口的后端。后端将接收的事件转换为特定于后端的事件,并将其发送到配置的分析后端(如 Segment 或 Woopra)。
3.6.1.4. Che-Theia telemetry 插件发送到后端的事件
事件 | Description |
---|---|
WORKSPACE_OPENED | 在 Che-Theia 启动时发送 |
COMMIT_LOCALLY |
使用 |
PUSH_TO_REMOTE |
使用 |
EDITOR_USED | 在编辑器中更改文件时发送 |
在后端插件中可以检测到 WORKSPACE_INACTIVE
和 WORKSPACE_STOPPED
等其他事件。
3.6.1.5. Woopra 遥测插件
Woopra Telemetry 插件是一个插件,用于将遥测从 Red Hat OpenShift Dev Spaces 安装发送到 Segment 和 Woopra。此插件 由红帽托管的 Eclipse Che 使用,但任何 Red Hat OpenShift Dev Spaces 部署都可以利用这个插件。有效 Woopra 域和 Segment Write 密钥以外的依赖项没有依赖项。插件 plugin.yaml 的 devfile v2 具有四个环境变量,可传递给插件:
-
WOOPRA_DOMAIN
- 将事件发送到的 Woopra 域。 -
SEGMENT_WRITE_KEY
- 将事件发送到 Segment 和 Woopra 的写密钥。 -
WOOPRA_DOMAIN_ENDPOINT
- 如果您更不希望直接传递 Woopra 域,则插件将从返回 Woopra Domain 的提供的 HTTP 端点中获取它。 -
SEGMENT_WRITE_KEY_ENDPOINT
- 如果您更不希望直接传递写键,则插件将从返回的 Segment write 键的提供的 HTTP 端点中获取它。
要在 Red Hat OpenShift Dev Spaces 安装中启用 Woopra 插件:
流程
使用正确设置环境变量将
plugin.yaml
devfile v2 文件部署到 HTTP 服务器。配置
CheCluster
自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next 1 plugins: 2 - 'https://your-web-server/plugin.yaml'
3.6.1.6. 创建遥测插件
本节演示了如何创建扩展 AbstractAnalyticsManager
并实施以下方法的 AnalyticsManager
类:
-
isEnabled ()
- 决定遥测后端是否正常运行。这可能意味着始终返回真,或者具有更复杂的检查,例如,当缺少连接属性时返回false
。 -
destroy ()
- 在关闭遥测后端前运行的清理方法。此方法发送WORKSPACE_STOPPED
事件。 -
onActivity ()
- 通知某些活动仍在为给定用户发生。这主要用于发送WORKSPACE_INACTIVE
事件。 -
onEvent ()
- 将遥测事件提交到遥测服务器,如WORKSPACE_USED
或WORKSPACE_STARTED
。 -
increaseDuration ()
- 增加当前事件的持续时间,而不是以小时间内发送多个事件。
以下部分涵盖:
- 创建遥测服务器以将事件回显到标准输出.
- 扩展 OpenShift Dev Spaces 遥测客户端并实施用户的自定义后端。
-
创建一个
plugin.yaml
文件,代表自定义后端的 Dev Workspace 插件。 -
通过从
CheCluster
自定义资源设置workspacesDefaultPlugins
属性,将自定义插件指定到 OpenShift Dev Spaces 的位置。
3.6.1.6.1. 开始使用
本文档描述了扩展 OpenShift Dev Spaces 遥测系统与自定义后端通信所需的步骤:
- 创建接收事件的服务器进程
- 扩展 OpenShift Dev Spaces 库以创建将事件发送到服务器的后端
- 将遥测后端打包到容器中,并将其部署到镜像 registry
- 为后端添加一个插件,并指示 OpenShift Dev Spaces 在 Dev Workspaces 中加载插件
如需完整的遥测后端示例,这里 提供了。
创建接收事件的服务器
出于演示目的,本例演示了如何创建从我们的遥测插件接收事件的服务器并将其写入标准输出。
对于生产环境,请考虑与第三方遥测系统(例如,Segment、Woopra)集成,而不是创建自己的遥测服务器。在这种情况下,使用供应商的 API 将事件从自定义后端发送到其系统。
以下 Go 代码在端口 8080
上启动一个服务器,并将事件写入标准输出:
例 3.12. main.go
package main import ( "io/ioutil" "net/http" "go.uber.org/zap" ) var logger *zap.SugaredLogger func event(w http.ResponseWriter, req *http.Request) { switch req.Method { case "GET": logger.Info("GET /event") case "POST": logger.Info("POST /event") } body, err := req.GetBody() if err != nil { logger.With("err", err).Info("error getting body") return } responseBody, err := ioutil.ReadAll(body) if err != nil { logger.With("error", err).Info("error reading response body") return } logger.With("body", string(responseBody)).Info("got event") } func activity(w http.ResponseWriter, req *http.Request) { switch req.Method { case "GET": logger.Info("GET /activity, doing nothing") case "POST": logger.Info("POST /activity") body, err := req.GetBody() if err != nil { logger.With("error", err).Info("error getting body") return } responseBody, err := ioutil.ReadAll(body) if err != nil { logger.With("error", err).Info("error reading response body") return } logger.With("body", string(responseBody)).Info("got activity") } } func main() { log, _ := zap.NewProduction() logger = log.Sugar() http.HandleFunc("/event", event) http.HandleFunc("/activity", activity) logger.Info("Added Handlers") logger.Info("Starting to serve") http.ListenAndServe(":8080", nil) }
基于此代码创建容器镜像,并将它公开为 openshift-devspaces
项目中的 OpenShift 中的部署。示例遥测服务器的代码位于 telemetry-server-example。要部署遥测服务器,请克隆存储库并构建容器:
$ git clone https://github.com/che-incubator/telemetry-server-example $ cd telemetry-server-example $ podman build -t registry/organization/telemetry-server-example:latest . $ podman push registry/organization/telemetry-server-example:latest
manifest_with_ingress.yaml
和 manifest_with_route
包含 Deployment 和 Service 的定义。前者也定义了 Kubernetes Ingress,后者定义 OpenShift 路由。
在清单文件中,替换 image
和 host
字段,以匹配您推送的镜像和 OpenShift 集群的公共主机名。然后运行:
$ kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
3.6.1.6.2. 创建后端项目
为了在开发时进行快速反馈,建议在 Dev Workspace 内进行开发。这样,您可以在集群中运行应用程序并从前端遥测插件接收事件。
Maven Quarkus 项目构建:
mvn io.quarkus:quarkus-maven-plugin:2.7.1.Final:create \ -DprojectGroupId=mygroup -DprojectArtifactId=devworkspace-telemetry-example-plugin \ -DprojectVersion=1.0.0-SNAPSHOT
-
删除
src/main/java/mygroup
和src/test/java/mygroup
下的文件。 -
参阅 GitHub 软件包 以获取最新版本的 Maven 与
backend-base
协调。 在
pom.xml
中添加以下依赖项:例 3.13.
pom.xml
<!-- Required --> <dependency> <groupId>org.eclipse.che.incubator.workspace-telemetry</groupId> <artifactId>backend-base</artifactId> <version>LATEST VERSION FROM PREVIOUS STEP</version> </dependency> <!-- Used to make http requests to the telemetry server --> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-rest-client</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-rest-client-jackson</artifactId> </dependency>
-
使用
read:packages
权限创建个人访问令牌,以下载来自 GitHub 软件包的org.eclipse.che.incubator.workspace-telemetry:backend-base
依赖项。 在
~/.m2/settings.xml
文件中添加 GitHub 用户名、个人访问令牌和che-incubator
存储库详情:例 3.14.
settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>che-incubator</id> <username>YOUR GITHUB USERNAME</username> <password>YOUR GITHUB TOKEN</password> </server> </servers> <profiles> <profile> <id>github</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>central</id> <url>https://repo1.maven.org/maven2</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>false</enabled></snapshots> </repository> <repository> <id>che-incubator</id> <url>https://maven.pkg.github.com/che-incubator/che-workspace-telemetry-client</url> </repository> </repositories> </profile> </profiles> </settings>
3.6.1.6.3. 创建分析管理器的强制实施并添加特殊逻辑
在 src/main/java/mygroup
下创建两个文件:
-
MainConfiguration.java
- 包含提供给AnalyticsManager
的配置。 -
AnalyticsManager.java
- 包含特定于遥测系统的逻辑。
例 3.15. MainConfiguration.java
package org.my.group; import java.util.Optional; import javax.enterprise.context.Dependent; import javax.enterprise.inject.Alternative; import org.eclipse.che.incubator.workspace.telemetry.base.BaseConfiguration; import org.eclipse.microprofile.config.inject.ConfigProperty; @Dependent @Alternative public class MainConfiguration extends BaseConfiguration { @ConfigProperty(name = "welcome.message") 1 Optional<String> welcomeMessage; 2 }
- 1
- MicroProfile 配置注解用于注入
welcome.message
配置。
有关如何设置特定于您的后端的配置属性的详情,请查看 Quarkus 配置参考指南。
例 3.16. AnalyticsManager.java
package org.my.group; import java.util.HashMap; import java.util.Map; import javax.enterprise.context.Dependent; import javax.enterprise.inject.Alternative; import javax.inject.Inject; import org.eclipse.che.incubator.workspace.telemetry.base.AbstractAnalyticsManager; import org.eclipse.che.incubator.workspace.telemetry.base.AnalyticsEvent; import org.eclipse.che.incubator.workspace.telemetry.finder.DevWorkspaceFinder; import org.eclipse.che.incubator.workspace.telemetry.finder.UsernameFinder; import org.eclipse.microprofile.rest.client.inject.RestClient; import org.slf4j.Logger; import static org.slf4j.LoggerFactory.getLogger; @Dependent @Alternative public class AnalyticsManager extends AbstractAnalyticsManager { private static final Logger LOG = getLogger(AbstractAnalyticsManager.class); public AnalyticsManager(MainConfiguration mainConfiguration, DevWorkspaceFinder devworkspaceFinder, UsernameFinder usernameFinder) { super(mainConfiguration, devworkspaceFinder, usernameFinder); mainConfiguration.welcomeMessage.ifPresentOrElse( 1 (str) -> LOG.info("The welcome message is: {}", str), () -> LOG.info("No welcome message provided") ); } @Override public boolean isEnabled() { return true; } @Override public void destroy() {} @Override public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) { LOG.info("The received event is: {}", event); 2 } @Override public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { } @Override public void onActivity() {} }
由于 org.my.group.AnalyticsManager
和 org.my.group.MainConfiguration
是 alternative Bean,因此使用 src/main/resources/application.properties
中的 quarkus.arc.selected-alternatives
属性指定它们。
例 3.17. application.properties
quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
3.6.1.6.4. 在 Dev Workspace 中运行应用程序
在 Dev Workspace 中设置
DEVWORKSPACE_TELEMETRY_BACKEND_PORT
环境变量。在这里,该值设置为4167
。spec: template: attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167'
- 从 Red Hat OpenShift Dev Spaces 仪表板重启 Dev Workspace。
在 Dev Workspace 的终端窗口中运行以下命令启动应用程序。使用
--settings
标志指定到包含 GitHub 访问令牌的settings.xml
文件的位置的路径。$ mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
现在,应用程序通过前端插件的端口
4167
接收遥测事件。
验证步骤
验证以下输出是否已记录:
INFO [org.ecl.che.inc.AnalyticsManager] (Quarkus Main Thread) No welcome message provided INFO [io.quarkus] (Quarkus Main Thread) devworkspace-telemetry-example-plugin 1.0.0-SNAPSHOT on JVM (powered by Quarkus 2.7.2.Final) started in 0.323s. Listening on: http://localhost:4167 INFO [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated. INFO [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, kubernetes-client, rest-client, rest-client-jackson, resteasy, resteasy-jsonb, smallrye-context-propagation, smallrye-openapi, swagger-ui, vertx]
要验证
AnalyticsManager
的onEvent ()
方法是否从前端插件接收事件,请按 l 键来禁用 Quarkus 实时编码,并在 IDE 中编辑任何文件。应该记录以下输出:INFO [io.qua.dep.dev.RuntimeUpdatesProcessor] (Aesh InputStream Reader) Live reload disabled INFO [org.ecl.che.inc.AnalyticsManager] (executor-thread-2) The received event is: Edit Workspace File in Che
3.6.1.6.5. 实现 isEnabled ()
例如,每当方法被调用时,此方法总是返回 true
。
例 3.18. AnalyticsManager.java
@Override public boolean isEnabled() { return true; }
可以在 isEnabled ()
中放入更复杂的逻辑。例如,托管的 OpenShift Dev Spaces Woopra 后端 会在确定是否启用了后端前检查配置属性是否存在。
3.6.1.6.6. 实施 onEvent ()
在Event ()上
,将后端接收的事件发送到遥测系统。对于示例应用程序,它会将 HTTP POST 有效负载发送到遥测服务器的 /event
端点。
向示例遥测服务器发送 POST 请求
例如,遥测服务器应用通过以下 URL 部署到 OpenShift :http://little-telemetry-server-che.apps-crc.testing
,其中 apps-crc.testing
是 OpenShift 集群的入口域名。
通过创建
TelemetryService.java
来设置 RESTEasy REST 客户端例 3.19.
TelemetryService.java
package org.my.group; import java.util.Map; import javax.ws.rs.Consumes; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; import org.eclipse.microprofile.rest.client.inject.RegisterRestClient; @RegisterRestClient public interface TelemetryService { @POST @Path("/event") 1 @Consumes(MediaType.APPLICATION_JSON) Response sendEvent(Map<String, Object> payload); }
- 1
- 为
POST
请求发出的端点。
在
src/main/resources/application.properties
文件中指定TelemetryService
的基本 URL:例 3.20.
application.properties
org.my.group.TelemetryService/mp-rest/url=http://little-telemetry-server-che.apps-crc.testing
将
TelemetryService
注入AnalyticsManager
并在Event ()中
发送POST
请求例 3.21.
AnalyticsManager.java
@Dependent @Alternative public class AnalyticsManager extends AbstractAnalyticsManager { @Inject @RestClient TelemetryService telemetryService; ... @Override public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) { Map<String, Object> payload = new HashMap<String, Object>(properties); payload.put("event", event); telemetryService.sendEvent(payload); }
这会发送 HTTP 请求到遥测服务器,并在小时间内自动延迟相同的事件。默认持续时间为 1500 毫秒。
3.6.1.6.7. 实现 increaseDuration ()
许多遥测系统识别事件持续时间。AbstractAnalyticsManager
将同一时间段内出现的相同事件合并到一个事件中。这个 增强Duration ()
的实现是 no-op。此方法使用用户遥测供应商的 API 更改事件或事件属性,以反映事件的增加持续时间。
例 3.22. AnalyticsManager.java
@Override public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
3.6.1.6.8. 实施 onActivity ()
设置不活跃超时限制,并使用 onActivity ()
发送 WORKSPACE_INACTIVE
事件(如果最后一次事件的时间超过超时时间)。
例 3.23. AnalyticsManager.java
public class AnalyticsManager extends AbstractAnalyticsManager { ... private long inactiveTimeLimit = 60000 * 3; ... @Override public void onActivity() { if (System.currentTimeMillis() - lastEventTime >= inactiveTimeLimit) { onEvent(WORKSPACE_INACTIVE, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties); } }
3.6.1.6.9. 实施 destroy ()
调用 destroy ()
时,发送 WORKSPACE_STOPPED
事件并关闭任何资源,如连接池。
例 3.24. AnalyticsManager.java
@Override public void destroy() { onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties); }
运行 mvn quarkus:dev
,如 第 3.6.1.6.4 节 “在 Dev Workspace 中运行应用程序” 所述,并使用 Ctrl+C 终止应用程序,将 WORKSPACE_STOPPED
事件发送到服务器。
3.6.1.6.10. 打包 Quarkus 应用程序
有关在容器中打包应用程序的最佳说明,请参阅 Quarkus 文档。构建容器并将其推送到您选择的容器 registry。
用于构建使用 JVM 运行的 Quarkus 镜像的 Dockerfile 示例
例 3.25. Dockerfile.jvm
FROM registry.access.redhat.com/ubi8/openjdk-11:1.11 ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en' COPY --chown=185 target/quarkus-app/lib/ /deployments/lib/ COPY --chown=185 target/quarkus-app/*.jar /deployments/ COPY --chown=185 target/quarkus-app/app/ /deployments/app/ COPY --chown=185 target/quarkus-app/quarkus/ /deployments/quarkus/ EXPOSE 8080 USER 185 ENTRYPOINT ["java", "-Dquarkus.http.host=0.0.0.0", "-Djava.util.logging.manager=org.jboss.logmanager.LogManager", "-Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}", "-jar", "/deployments/quarkus-run.jar"]
要构建镜像,请运行:
mvn package && \ podman build -f src/main/docker/Dockerfile.jvm -t image:tag .
构建 Quarkus 原生镜像的 Dockerfile 示例
例 3.26. Dockerfile.native
FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5 WORKDIR /work/ RUN chown 1001 /work \ && chmod "g+rwX" /work \ && chown 1001:root /work COPY --chown=1001:root target/*-runner /work/application EXPOSE 8080 USER 1001 CMD ["./application", "-Dquarkus.http.host=0.0.0.0", "-Dquarkus.http.port=$DEVWORKSPACE_TELEMETRY_BACKEND_PORT}"]
要构建镜像,请运行:
mvn package -Pnative -Dquarkus.native.container-build=true && \ podman build -f src/main/docker/Dockerfile.native -t image:tag .
3.6.1.6.11. 为您的插件创建 plugin.yaml
创建一个 plugin.yaml
devfile v2 文件,该文件代表在 Dev Workspace Pod 中运行自定义后端的 Dev Workspace 插件。如需有关 devfile v2 的更多信息,请参阅 Devfile v2 文档
例 3.27. plugin.yaml
schemaVersion: 2.1.0 metadata: name: devworkspace-telemetry-backend-plugin version: 0.0.1 description: A Demo telemetry backend displayName: Devworkspace Telemetry Backend components: - name: devworkspace-telemetry-backend-plugin attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167' container: image: YOUR IMAGE 1 env: - name: WELCOME_MESSAGE 2 value: 'hello world!'
- 1
- 指定从 第 3.6.1.6.10 节 “打包 Quarkus 应用程序” 构建的容器镜像。
- 2
- 从 Example 4 设置
welcome.message
可选配置属性的值。
通常,用户将此文件部署到公司 Web 服务器。本指南说明了如何在 OpenShift 中创建 Apache Web 服务器并托管该插件。
创建一个 ConfigMap
对象来引用新 plugin.yaml
文件。
$ oc create configmap --from-file=plugin.yaml -n openshift-devspaces telemetry-plugin-yaml
创建部署、服务和公开 Web 服务器的路由。部署引用此 ConfigMap
对象,并将其放置在 /var/www/html
目录中。
例 3.28. manifest.yaml
kind: Deployment apiVersion: apps/v1 metadata: name: apache spec: replicas: 1 selector: matchLabels: app: apache template: metadata: labels: app: apache spec: volumes: - name: plugin-yaml configMap: name: telemetry-plugin-yaml defaultMode: 420 containers: - name: apache image: 'registry.redhat.io/rhscl/httpd-24-rhel7:latest' ports: - containerPort: 8080 protocol: TCP resources: {} volumeMounts: - name: plugin-yaml mountPath: /var/www/html strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% revisionHistoryLimit: 10 progressDeadlineSeconds: 600 --- kind: Service apiVersion: v1 metadata: name: apache spec: ports: - protocol: TCP port: 8080 targetPort: 8080 selector: app: apache type: ClusterIP --- kind: Route apiVersion: route.openshift.io/v1 metadata: name: apache spec: host: apache-che.apps-crc.testing to: kind: Service name: apache weight: 100 port: targetPort: 8080 wildcardPolicy: None
$ oc apply -f manifest.yaml
验证步骤
部署启动后,确认 web 服务器中存在
plugin.yaml
:$ curl apache-che.apps-crc.testing/plugin.yaml
3.6.1.6.12. 在 Dev Workspace 中指定遥测插件
在现有 Dev Workspace 的
components
字段中添加以下内容:components: ... - name: telemetry-plug-in plugin: uri: http://apache-che.apps-crc.testing/plugin.yaml
- 从 OpenShift Dev Spaces 仪表板启动 Dev Workspace。
验证步骤
验证
telemetry-plug-in
容器是否在 Dev Workspace pod 中运行。此处可以通过检查编辑器中的 Workspace 视图来验证这一点。- 在编辑器中编辑文件,并在示例遥测服务器日志中观察其事件。
3.6.1.6.13. 为所有 Dev Workspaces 应用遥测插件
将遥测插件设置为默认插件。默认插件应用于新和现有的 Dev Workspaces 的 Dev Workspace 启动。
配置
CheCluster
自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next 1 plugins: 2 - 'http://apache-che.apps-crc.testing/plugin.yaml'
验证步骤
- 从 Red Hat OpenShift Dev Spaces 仪表板启动新的或现有的 Dev Workspace。
- 按照 第 3.6.1.6.12 节 “在 Dev Workspace 中指定遥测插件” 的验证步骤,验证遥测插件是否正常工作。
3.6.2. 配置服务器日志记录
可以微调 OpenShift Dev Spaces 服务器中可用的各个日志记录器的日志级别。
整个 OpenShift Dev Spaces 服务器的日志级别使用 Operator 的 cheLogLevel
配置属性全局配置。请参阅 第 3.1.3 节 “CheCluster
自定义资源字段参考”。要在不由 Operator 管理的安装中设置全局日志级别,请在 che
ConfigMap 中指定 CHE_LOG_LEVEL
环境变量。
可以使用 CHE_LOGGER_CONFIG
环境变量在 OpenShift Dev Spaces 服务器中配置各个日志记录器的日志级别。
3.6.2.1. 配置日志级别
流程
配置
CheCluster
自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "<key1=value1,key2=value2>" 1
- 1
- 以逗号分隔的键值对列表,其中键是日志记录器的名称,如 OpenShift Dev Spaces 服务器日志输出和值中所示。
例 3.29. 为
WorkspaceManager
配置调试模式spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
3.6.2.2. 日志记录器命名
日志记录器的名称遵循使用这些日志记录器的内部服务器类的类名称。
3.6.2.3. 日志记录 HTTP 流量
流程
要记录 OpenShift Dev Spaces 服务器和 Kubernetes 或 OpenShift 集群的 API 服务器之间的 HTTP 流量,请配置
CheCluster
自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
3.6.3. 使用 dsc 收集日志
安装 Red Hat OpenShift Dev Spaces 包括几个在 OpenShift 集群中运行的容器。虽然可以从每个运行中的容器手动收集日志,但 dsc
提供了可自动化此过程的命令。
以下命令可使用 dsc
工具从 OpenShift 集群收集 Red Hat OpenShift Dev Spaces 日志:
dsc server:logs
收集现有的 Red Hat OpenShift Dev Spaces 服务器日志,并将它们存储在本地计算机上的一个目录中。默认情况下,日志会下载到机器的临时目录中。但是,这可以通过指定
-d
参数来覆盖。例如,要将 OpenShift Dev Spaces 日志下载到/home/user/che-logs/
目录,请使用 命令dsc server:logs -d /home/user/che-logs/
运行时,
dsc server:logs
会在控制台中指定存储日志文件的目录信息:Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
如果在非默认项目中安装了 Red Hat OpenShift Dev Spaces,则
dsc server:logs
需要-n <NAMESPACE>
; paremeter,其中 <NAMESPACE
> 是 Red Hat OpenShift Dev Spaces 的 OpenShift 项目。例如,若要从my-namespace
项目中的 OpenShift Dev Spaces 获取日志,请使用 命令dsc server:logs -n my-namespace
dsc server:deploy
-
使用
dsc
安装时,会在 OpenShift Dev Spaces 安装过程中自动收集日志。与dsc server:logs
一样,可以使用-d
参数来指定目录日志存储在 中。
其他资源
- "DSC 参考文档"
3.6.4. 使用 Prometheus 和 Grafana 监控
您可以使用集群中运行的 Prometheus 和 Grafana 实例收集并查看 OpenShift Dev Spaces 指标。
3.6.4.1. 安装 Prometheus 和 Grafana
您可以通过应用 template.yaml
来安装 Prometheus 和 Grafana。本例中的 template.yaml
文件提供了基本配置、Deployment 和 Services 的监控堆栈,以便开始使用 Prometheus 和 Grafana。
另外,您可以使用 Prometheus Operator 和 Grafana Operator。
先决条件
- oc
流程
使用 template.yaml
安装 Prometheus 和 Grafana:
为 Prometheus 和 Grafana 创建一个新项目,
监控
:$ oc new-project monitoring
在
monitoring
项目中应用template.yaml
:$ oc apply -f template.yaml -n monitoring
例 3.30. template.yaml
--- apiVersion: v1 kind: Service metadata: name: grafana labels: app: grafana spec: ports: - name: 3000-tcp port: 3000 protocol: TCP targetPort: 3000 selector: app: grafana --- apiVersion: v1 kind: Service metadata: name: prometheus labels: app: prometheus spec: ports: - name: 9090-tcp port: 9090 protocol: TCP targetPort: 9090 selector: app: prometheus --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: grafana name: grafana spec: selector: matchLabels: app: grafana template: metadata: labels: app: grafana spec: containers: - image: registry.redhat.io/rhel8/grafana:7 name: grafana ports: - containerPort: 3000 protocol: TCP --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: prometheus name: prometheus spec: selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: serviceAccountName: prometheus containers: - image: quay.io/prometheus/prometheus:v2.36.0 name: prometheus ports: - containerPort: 9090 protocol: TCP volumeMounts: - mountPath: /prometheus name: volume-data - mountPath: /etc/prometheus/prometheus.yml name: volume-config subPath: prometheus.yml volumes: - emptyDir: {} name: volume-data - configMap: defaultMode: 420 name: prometheus-config name: volume-config --- apiVersion: v1 kind: ConfigMap metadata: name: prometheus-config data: prometheus.yml: "" --- apiVersion: v1 kind: ServiceAccount metadata: name: prometheus ---
3.6.4.2. 监控 Dev Workspace Operator
您可以配置一个监控堆栈示例,以处理 Dev Workspace Operator 公开的指标。
3.6.4.2.1. 使用 Prometheus 收集 Dev Workspace Operator 指标
使用 Prometheus 收集、存储和查询 Dev Workspace Operator 的指标:
先决条件
-
devworkspace-controller-metrics
Service 是在端口8443
上公开指标。默认预配置。 -
devworkspace-webhookserver
服务在端口9443
上公开指标。默认预配置。 -
Prometheus 2.26.0 或更高版本正在运行。Prometheus 控制台在端口
9090
上运行,并带有相应的服务。请参阅 Prometheus 的第一个步骤。
流程
创建一个 ClusterRoleBinding 将与 Prometheus 关联的 ServiceAccount 绑定到 devworkspace-controller-metrics-reader ClusterRole。对于 监控堆栈示例,要使用的 ServiceAccount 的名称是
prometheus
。注意如果没有 ClusterRoleBinding,您无法访问 Dev Workspace 指标,因为访问使用基于角色的访问控制(RBAC)进行保护。
例 3.31. ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: devworkspace-controller-metrics-binding subjects: - kind: ServiceAccount name: prometheus namespace: monitoring roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: devworkspace-controller-metrics-reader
将 Prometheus 配置为从
devworkspace-controller-metrics
Service 公开的端口8443
中提取指标,再从devworkspace-webhookserver
Service 公开的端口9443
中提取指标。注意监控堆栈示例 已创建了带有空配置的
prometheus-config
ConfigMap。要提供 Prometheus 配置详情,请编辑 ConfigMap 的data
字段。例 3.32. Prometheus 配置
apiVersion: v1 kind: ConfigMap metadata: name: prometheus-config namespace: monitoring data: prometheus.yml: |- global: scrape_interval: 5s 1 evaluation_interval: 5s 2 scrape_configs: 3 - job_name: 'DevWorkspace' scheme: https authorization: type: Bearer credentials_file: '/var/run/secrets/kubernetes.io/serviceaccount/token' tls_config: insecure_skip_verify: true static_configs: - targets: ['devworkspace-controller-metrics.<DWO_project>:8443'] 4 - job_name: 'DevWorkspace webhooks' scheme: https authorization: type: Bearer credentials_file: '/var/run/secrets/kubernetes.io/serviceaccount/token' tls_config: insecure_skip_verify: true static_configs: - targets: ['devworkspace-webhookserver.<DWO_project>:9443'] 5
- 1
- 抓取目标的速率。
- 2
- 重新检查记录和警报规则的速率。
- 3
- Prometheus 监控的资源。在默认配置中,两个作业是
DevWorkspace
和DevWorkspace Webhook
,提取由devworkspace-controller-metrics
和devworkspace-webhookserver
服务公开的时间序列数据。 - 4
- 来自端口
8443
的指标的修整目标。将<DWO_project
> 替换为devworkspace-controller-metrics
Service
所在的项目。 - 5
- 来自端口
9443
的指标的修整目标。将<DWO_project
> 替换为devworkspace-webhookserver
Service
所在的项目。
缩减
Prometheus
Deployment 并向上读取上一步中更新的 ConfigMap。$ oc scale --replicas=0 deployment/prometheus -n monitoring && oc scale --replicas=1 deployment/prometheus -n monitoring
验证
使用端口转发在本地访问
Prometheus
服务:$ oc port-forward svc/prometheus 9090:9090 -n monitoring
-
通过查看
localhost:9090/targets
上的目标端点来验证所有目标是否已启动。 使用 Prometheus 控制台查看和查询指标:
-
查看
localhost:9090/metrics
上的指标。 从
localhost:9090/graph
来查询指标。如需更多信息,请参阅使用表达式浏览器。
-
查看
3.6.4.2.2. dev Workspace 特定的指标
下表描述了 devworkspace-controller-metrics
服务公开的 Dev Workspace 特定指标。
名称 | 类型 | Description | 标签 |
---|---|---|---|
| 计数 | Dev Workspace 启动事件的数量。 |
|
| 计数 |
Dev Workspaces 的数量成功进入 |
|
| 计数 | 失败的 Dev Workspaces 数量。 |
|
| Histogram | 启动 Dev Workspace 所需的时间(以秒为单位)。 |
|
名称 | Description | 值 |
---|---|---|
|
Dev Workspace 的 |
|
|
Dev Workspace 的 |
|
| 工作区启动失败的原因。 |
|
名称 | Description |
---|---|
| 由于用于创建 Dev Workspace 的 devfile 无效,启动失败。 |
|
由于以下错误导致启动失败: |
| 未知故障原因. |
3.6.4.2.3. 在 Grafana 仪表板中查看 Dev Workspace Operator 指标
使用示例仪表板查看 Grafana 上的 Dev Workspace Operator 指标:
先决条件
- Prometheus 收集指标。请参阅 第 3.6.4.2.1 节 “使用 Prometheus 收集 Dev Workspace Operator 指标”。
- Grafana 版本 7.5.3 或更高版本。
-
Grafana 在带有对应服务的端口
3000
上运行。请参阅安装 Grafana。
流程
- 为 Prometheus 实例添加数据源。请参阅创建 Prometheus 数据源。
-
导入 示例
grafana-dashboard.json
仪表板。
验证步骤
- 使用 Grafana 控制台查看 Dev Workspace Operator 指标仪表板。请参阅 第 3.6.4.2.4 节 “Dev Workspace Operator 的 Grafana 仪表板”。
其他资源
3.6.4.2.4. Dev Workspace Operator 的 Grafana 仪表板
基于 grafana-dashboard.json
的 Grafana 仪表板示例从 Dev Workspace Operator 中显示以下指标。
Dev Workspace 特定的指标 面板
图 3.1. Dev Workspace 特定的指标 面板
- 平均工作空间开始时间
- 平均工作空间启动持续时间。
- Workspace start
- 成功和失败的工作区启动数量。
- 工作区启动持续时间
- 显示工作空间启动持续时间的 heatmap。
- dev Workspace 成功/失败
- 成功和失败的 Dev Workspace 启动之间的比较。
- dev Workspace 失败率
- 失败的工作区启动数和总工作空间启动数量之间的比例。
- Dev Workspace 启动失败原因
显示工作空间启动失败分布的饼图:
-
BadRequest
-
InfrastructureFailure
-
Unknown
-
Operator 指标 面板(第 1 部分)
图 3.2. Operator 指标 面板(第 1 部分)
- flight 中的 Webhook
- 不同 webhook 请求的数量之间的比较。
- 工作队列持续时间
- heatmap 显示在处理前协调请求在工作队列中的时长。
- Webhook 延迟(/mutate)
-
显示
/mutate
Webhook 延迟的 heatmap。 - 协调时间
- 显示协调持续时间的 heatmap。
Operator 指标 面板(第 2 部分)
图 3.3. Operator 指标 面板(第 2 部分)
- Webhook 延迟(/convert)
-
显示
/convert
webhook 延迟的 heatmap。 - 工作队列深度
- 工作队列中的协调请求数。
- 内存
- Dev Workspace 控制器和 Dev Workspace Webhook 服务器的内存用量。
- 协调计数(DWO)
- Dev Workspace 控制器的平均协调数。
3.6.4.3. 监控 Dev Spaces 服务器
您可以配置 OpenShift Dev Spaces 以公开 JVM 指标,如 JVM 内存和 OpenShift Dev Spaces 服务器的类加载。
3.6.4.3.1. 启用并公开 OpenShift Dev Spaces 服务器指标
OpenShift Dev Spaces 在 che-host
服务的端口 8087
上公开 JVM 指标。您可以配置这个行为。
流程
配置
CheCluster
自定义资源。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: metrics: enable: <boolean> 1
- 1
true
可启用,false
以禁用。
3.6.4.3.2. 使用 Prometheus 收集 OpenShift Dev Spaces 服务器指标
使用 Prometheus 为 OpenShift Dev Spaces 服务器收集、存储和查询 JVM 指标:
先决条件
-
OpenShift Dev Spaces 是在端口
8087
上公开指标。请参阅启用和公开 OpenShift Dev Spaces 服务器 JVM 指标。 -
Prometheus 2.26.0 或更高版本正在运行。Prometheus 控制台在端口
9090
上运行,并带有相应的服务。请参阅 Prometheus 的第一个步骤。
流程
将 Prometheus 配置为从端口
8087
中提取指标。注意监控堆栈示例 已创建了带有空配置的
prometheus-config
ConfigMap。要提供 Prometheus 配置详情,请编辑 ConfigMap 的data
字段。例 3.33. Prometheus 配置
apiVersion: v1 kind: ConfigMap metadata: name: prometheus-config data: prometheus.yml: |- global: scrape_interval: 5s 1 evaluation_interval: 5s 2 scrape_configs: 3 - job_name: 'OpenShift Dev Spaces Server' static_configs: - targets: ['che-host.<OpenShift Dev Spaces_project>:8087'] 4
缩减
Prometheus
Deployment 并向上读取上一步中更新的 ConfigMap。$ oc scale --replicas=0 deployment/prometheus -n monitoring && oc scale --replicas=1 deployment/prometheus -n monitoring
验证
使用端口转发在本地访问
Prometheus
服务:$ oc port-forward svc/prometheus 9090:9090 -n monitoring
-
通过查看
localhost:9090/targets
上的目标
端点来验证所有目标是否已启动。 使用 Prometheus 控制台查看和查询指标:
-
查看
localhost:9090/metrics
上的指标。 从
localhost:9090/graph
来查询指标。如需更多信息,请参阅使用表达式浏览器。
-
查看
3.6.4.3.3. 在 Grafana 仪表板中查看 OpenShift Dev Spaces Server 指标
查看 Grafana 上的 OpenShift Dev Spaces 服务器指标:
先决条件
- Prometheus 收集 OpenShift Dev Spaces 集群上的指标。请参阅 第 3.6.4 节 “使用 Prometheus 和 Grafana 监控”。
-
Grafana 6.0 或更高版本使用对应的服务在端口
3000
上运行。请参阅安装 Grafana。
流程
- 为 Prometheus 实例添加数据源。请参阅创建 Prometheus 数据源。
- 导入示例 仪表板。请参阅 导入仪表板。
在 Grafana 控制台中查看 OpenShift Dev Spaces JVM 指标:
图 3.4. OpenShift Dev Spaces 服务器 JVM 仪表板
图 3.5. 快速事实
图 3.6. JVM 内存
图 3.7. JVM Misc
图 3.8. JVM 内存池(heap)
图 3.9. JVM 内存限值(Non-Heap)
图 3.10. 垃圾回收
图 3.11. 类载入
图 3.12. 缓冲池