搜索到
13
篇与
的结果
-
OpenTelemetry数据收集 一、收集器配置详解OpenTelemetry 的 Collector 组件是实现观测数据（Trace、Metrics、Logs）收集、处理和导出的一站式服务。它的配置主要分为以下 四大核心模块： receivers（接收数据） processors（数据处理） exporters（导出数据） service（工作流程）1、配置格式#具体配置项可参考文档https://opentelemetry.io/docs/collector/configuration/ apiVersion: opentelemetry.io/v1beta1 kind: OpenTelemetryCollector # 定义资源类型为 OpenTelemetryCollector metadata: name: sidecar # Collector 的名称 spec: mode: sidecar # 以 sidecar 模式运行（与应用容器同 Pod） config: # Collector 配置部分（结构化 YAML） receivers: # 数据接收器（如 otlp、prometheus） processors: # 数据处理器（如 batch、resource、attributes） exporters: # 数据导出器（如 otlp、logging、jaeger、prometheus） service: # 服务配置（定义哪些 pipeline 生效） pipelines: traces: # trace 数据的处理流程 metrics: # metric 数据的处理流程 logs: # log 数据的处理流程2、Receivers（接收器）用于接收数据。支持的类型有很多， otlp：接收 otlp 协议的数据内容 receivers: otlp: protocols: grpc: # 高性能、推荐使用 endpoint: 0.0.0.0:4317 http: # 浏览器或无 gRPC 支持的环境 endpoint: 0.0.0.0:4318prometheus： 用于采集 /metrics 接口的数据。 receivers: prometheus: config: scrape_configs: - job_name: my-service static_configs: - targets: ['my-app:8080']filelog: 从文件读取日志 receivers: filelog: include: [ /var/log/myapp/*.log ] start_at: beginning operators: - type: json_parser parse_from: body timestamp: parse_from: attributes.time3、Processors（处理器）用于在导出前对数据进行修改、增强或过滤。常用的包括： batch ： 将数据批处理后导出，提高吞吐量。 processors: batch: timeout: 10s send_batch_size: 1024resource ： 为 trace/metric/log 添加统一标签。 processors: resource: attributes: - key: service.namespace value: demo action: insertattributes ： 添加、修改或删除属性 processors: attributes: actions: - key: http.method value: GET action: insert处理器配置可参考文档：https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor4、Exporters（导出器）用于将数据导出到后端系统 otlp: 用于将数据发送到另一个 OTEL Collector、Jaeger、Tempo、Datadog 等。 exporters: otlp: endpoint: tempo-collector:4317 tls: insecure: truePrometheus： 用于暴露一个 /metrics HTTP 端口给 Prometheus 拉取。 exporters: prometheus: endpoint: "0.0.0.0:8889"logging ： 调试用，打印数据到控制台。 exporters: debug: loglevel: debug5、Service（工作流程）service.pipelines 是一个“调度图”，告诉 OpenTelemetry Collector，对于某种类型的数据，比如 trace，请用哪个 receiver 来接收，用哪些 processor 来处理，最终送到哪些 exporter 去导出。service: pipelines: traces: receivers: [otlp] processors: [batch, resource] exporters: [otlp, logging] metrics: receivers: [prometheus] processors: [batch] exporters: [prometheus] logs: receivers: [filelog] processors: [batch] exporters: [otlp]二、Collector 发行版本区别opentelemetry-collector 和 opentelemetry-collector-contrib 是两个 OpenTelemetry Collector 的发行版本，它们的区别主要在于 内置组件的丰富程度 和 维护主体。 -
CICD部署流程 第一步：搭建k8s环境，详情见配置文档：https://axzys.cn/admin/manage-posts.php?page=1第二步：在工具集群安装：Jenkins2.1创建jenkins.yaml文件(ps:镜像文件如果下载不下来的话，需要到阿里云部署一个镜像文件，部署文档：xxx)apiVersion: v1 kind: PersistentVolume metadata: name: jenkins-pv labels: type: local spec: capacity: storage: 5Gi accessModes: - "ReadWriteOnce" hostPath: path: /data/jenkins --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: jenkins-pvc spec: accessModes: - "ReadWriteOnce" resources: requests: storage: 5Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: jenkins spec: replicas: 1 selector: matchLabels: app: jenkins template: metadata: labels: app: jenkins spec: containers: - name: jenkins image: registry.cn-hangzhou.aliyuncs.com/vimermaid/jenkins:1.0 ports: - containerPort: 8080 name: web protocol: TCP - containerPort: 50000 name: agent protocol: TCP resources: limits: cpu: 1500m memory: "6Gi" requests: cpu: 1500m memory: "2048Mi" readinessProbe: httpGet: path: /login port: 8080 initialDelaySeconds: 60 timeoutSeconds: 5 failureThreshold: 12 volumeMounts: - name: jenkins-home mountPath: /var/jenkins_home volumes: - name: jenkins-home persistentVolumeClaim: claimName: jenkins-pvc --- apiVersion: v1 kind: Service metadata: name: jenkins-init-service spec: type: NodePort ports: - port: 7096 name: web1 nodePort: 7096 targetPort: 8080 - port: 50000 name: web2 nodePort: 50000 targetPort: 50000 selector: app: jenkins2.2创建本地目录mkdir -p /data/jenkins chmod o+w /data/jenkins2.3扩大端口范围（原因是：kubernetes默认端口号范围是 30000-32767 ，如果期望值不是这个区间则需要更改vi /etc/kubernetes/manifests/kube-apiserver.yaml将文件配置到末端：- --service-node-port-range=1024-65535展示效果 2.3部署jenkins.yaml文件kubectl apply -f jenkins.yaml2.4查看pod：jenkins.yamlkubectl get pods -o wide2.5pod状态变成running后，再查看Jenkins密码kubectl exec -ti jenkins-548bfffcb-mtc4t cat /var/jenkins_home/secrets/initialAdminPassword2.6查看Jenkins的svc：查询暴漏给外部可访问的端口kubectl get svc |grep jenkins2.7登录Jenkins的web页面192.168.1.111:70962.8输入密码，就是上面2.5获取到的密码，并下载推荐插件 2.9为Jenkins制作动态的slave节点 2.9.1安装并配置k8s插件，名字就叫k8s，不是图上那个 2.9.2制作用于Jenkins链接k8s集群的凭证（工具集群） #将文本凭证信息输出到指定文件certificate_authority_data=$(awk -F': ' '/certificate-authority-data/{print $2}' ~/.kube/config) client_certificate_data=$(awk -F': ' '/client-certificate-data/{print $2}' ~/.kube/config) client_key_data=$(awk -F': ' '/client-key-data/{print $2}' ~/.kube/config) echo "$certificate_authority_data" | base64 -d > ca.crt echo "$client_certificate_data" | base64 -d > client.crt echo "$client_key_data" | base64 -d > client.key#安装导出命令yum install lrzsz -y #lrzsz 是一个包含 rz 和 sz 命令的软件包。这两个命令用于在 Linux 和 Windows 之间通过 XMODEM、YMODEM 和 ZMODEM 协议传输文件。具体来说： #rz：用于从 Windows 机器接收文件到 Linux 机器。 #sz：用于从 Linux 机器发送文件到 Windows 机器。#导出cert.pfx文件#将导出的信息保存到桌面自建文件夹 sz cert.pfx#再生成jenkins使用的PKCS12格式的cert.pfx文件，需要设置密码，注意密码后期jenkins需要（密码建议：admin）openssl pkcs12 -export -out cert.pfx -inkey client.key -in client.crt -certfile ca.crt效果展示 #创建云管理节点 #配置k8s地址及ca证书#Kubernetes地址是：主机IP+apiserver的端口 #查看apiserver的端口 kubectl get pods -n kube-system | grep api | awk '{print $1}' | kubectl describe pods -n kube-system |grep port #查看ca证书 #将结果粘贴到证书页面，见下图 cat ca.crt#测试连接效果展示 #配置Jenkins地址：#查看Jenkins的svc kubectl -n default get svc |grep jenkins #查看Jenkins所在的名称空间 kubectl -n default get svc |grep jenkins |awk '{print $1}' |kubectl describe pods |grep Namespace #查看Jenkins的svc端口号 kubectl get svc |grep jenkins #拼接Jenkins的地址(jenkins的SVC的IP+名称空间+svc.cluster.local+Jenkins的svc端口号) http://jenkins-init-service.default.svc.cluster.local:7096 http://jenkins-init-service.default.svc.cluster.local:50000 创建模版 添加挂载卷 创建一个账号apiVersion: v1 kind: ServiceAccount metadata: name: jenkins namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: jenkins rules: - apiGroups: ["apps"] resources: ["deployments", "ingresses"] verbs: ["create", "delete", "get", "list", "watch", "patch", "update"] - apiGroups: [""] resources: ["services"] verbs: ["create", "delete", "get", "list", "watch", "patch", "update"] - apiGroups: [""] resources: ["pods"] verbs: ["create", "delete", "get", "list", "patch", "update", "watch"] - apiGroups: [""] resources: ["pods/exec"] verbs: ["create", "delete", "get", "list", "patch", "update", "watch"] - apiGroups: [""] resources: ["pods/log", "events"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["secrets"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: jenkins namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: jenkins subjects: - kind: ServiceAccount name: jenkins namespace: default将账号信息填入到模版中 创建一个测试流水线，测试模版，需要注意的是标签保持一致 将代码填入到脚本执行区域echo "测试 Kubernetes 动态生成 jenkins slave" echo "==============docker in docker===========" docker info echo "=============kubectl=============" kubectl get pods sleep 120
-
-
-
docker容器导出为镜像 容器分层可写层:upperdir镜像层(只读层):lowerdir容器被删掉后，可写层的数据就没了，如果我们的需求是基于一个基础镜像制作一个新镜像，那么我们可以这么做，pul一个基础镜像，然后用该镜像run启动一个容器，然后exec进入容器内部署各种软件做好一些配置，这些写操作都留在了upperdir层，一旦销毁容器一切都不复存在，此时可以在容器外使用commit命令把容器整体upperdir+lowerdir导出为一个新镜像下载基础镜像docker pull centos:7启动容器docker run -d --name test111 centos:7 sleep 10000进入容器安装、修改配置、编写启动文件[root@test03 ~]# docker exec -ti test111 sh sh-4.2# mkdir /soft sh-4.2# echo 111 > /soft/1.txt sh-4.2# echo 222 > /soft/2.txt sh-4.2# echo "echo start...;tail -f /dev/null" > /soft/run.sh sh-4.2# exitcommit镜像当前运行的容器，其实就是它的upperdir+lowerdir导出为一个新镜像[root@test03 ~]# docker commit test111 myimage:v1.0 [root@test03 ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE myimage v1.0 adfed0daa724 4 seconds ago 204MB[root@test03 ~]# docker run -d --name test222 myimage:v1.0 sh /soft/run.sh ea04adcee6d7f157f764d2c8028eb5bdfd9c02a436ba3941c87a58304e853dfa [root@test03 ~]# [root@test03 ~]# [root@test03 ~]# docker top test222 UID PID PPID C STIME TTY TIME CMD root 21349 21330 0 11:39 ? 00:00:00 sh /soft/run.sh root 21375 21349 0 11:39 ? 00:00:00 tail -f /dev/null
