Kubernetes 微服务监控体系

67c2f9e64e495b624ec5e0c7ebc3aba4.gif

作者|无敌码农

来源|无敌码农

fdff827af76e2d73199285cc9c2eb01a.png

监控系统是运维体系乃至整个软件产品生命周期中最重要的一环,完善的监控可以帮助我们事前及时发现故障,事后快速追查定位问题。而在以微服务为代表的云原生架构体系中,系统分为多个层次,服务之间调用链路复杂,系统中需要监控的目标非常多,如果没有一个完善的监控系统就难以保证整体服务的持续稳定。

监控对象及分层

aa28819311e05b9374ce638e06e5c632.png

在实际场景中监控系统按照监控的对象及系统层次结构,从底向上可以依次划分为基础层、中间层、应用层、业务层等多个层面的监控。具体可如图所示:

98726ed1a66349e1542ff58c137e1fd8.png

基础层监控就是对主机服务器(包括宿主机、容器)及其底层资源进行监控,以保证应用程序运行所依赖的基础环境的稳定运行。基础层监控主要有两个方向:

  • 资源利用:是对像I/O利用率、CPU利用率、内存使用率、磁盘使用率、网络负载等这样的硬件资源进行监控。避免因应用程序本身或其它特殊情况引起的硬件资源耗尽而出现的服务故障。

  • 网络通信:是对服务器之间的网络状态进行监控。网络通信是互联网的重要基石,如果主机之间的网络出现如延迟过大、丢包率高这样的网络问题,将会严重影响业务。

需要说明的是,在基于Kubernetes容器化技术的新型云原生基础设施中,基础层的监控不仅要对宿主机本身进行监控,也要对Kubernetes集群状态及其容器资源使用情况进行监控。这在后面我们构建基于Kubernetes的基础层监控体系时将会具体介绍。

中间层监控主要是指对诸如Nginx、Redis、MySQL、RocketMQ、Kafka等应用服务所依赖的中间件软件的监控,它们的稳定也是保证应用程序持续可用的关键。一般来说特定的中间件软件都会根据自身特点构建针对性的监控体系。

应用层监控这里就是指对业务性服务程序的监控,一般来说我们对应用程序监控的关注点主要体现在以下几个方面:

  • HTTP接口请求访问。包括接口响应时间、吞吐量等;

  • JVM监控指标。对于Java服务,还会重点关注GC时间、线程数、FGC/YGC耗时等JVM性能相关的指标;

  • 资源消耗。应用程序部署后会消耗一定的资源,例如应用程序对内存、CPU的消耗情况;

  • 服务的健康状态。例如当前服务是否存活,运行是否稳定等;

  • 调用链路。在微服务架构中,由于调用链路变长,还需要重点监控服务之间的调用关系和调用情况,避免局部上下游服务之间的链路故障引发系统全局性雪崩;

业务层监控也是监控系统所关注的一个重要内容,在实际场景中如果你只是让应用程序稳定运行那肯定是远远不够的。因此,我们常常会对具体业务产生的数据进行监控,例如网站系统所关注的PV、UV等参数;后端如交易之类的系统我们则会关注订单量、成功率等。

业务指标也是体现系统稳定性的核心要素。任何系统,如果出现了问题,最先受到影响的肯定是业务指标。对于核心业务指标的设定因具体的业务和场景而异,所以对于业务层的监控需要构建具备业务特点的业务监控系统。

常见的监控指标类型

f4f8d1aba2ca4c98247c6503a4117aa6.png

在指标类监控系统中,通过统计指标可以感性地认识到整个系统的运行情况。出现问题后,各个指标会首先出现波动,这些波动会反映出系统是那些方面出了问题,从而可以据此排查出现问题的原因。下面我们分别来看下统计指标到底有哪些类型,以及常见的统计指标都有哪些,它是我们进一步理解指标类监控系统的基础。

从整体上看,常见的Metrics指标类型主要有:计数器(Counter)、测量仪(Gauge)、直方图(Histogram)、摘要(Summary)这四类。它们的特点分别如下:

1. 计数器(Counter)

计数器是一种具有累加特性的指标类型,一般这个值为Double或者Long类型。例如常见的统计指标QPS、TPS等的值就是通过计数器的形式,然后配合一些统计函数计算得出的。

2. 测量仪(Gauge)

表示某个时间点,对某个数值的测量。测量仪和计数器都可以用来查询某个时间点的固定内容的数值,但和计数器不同,测量仪的值可以随意变化,可以增加也可以减少。比如获取Java线程池中活跃的线程数,使用的是ThreadPoolExecutor中的getActiveCount方法;此外,还有比较常见的CPU使用率、内存占用量等具体指标都是通过测量仪获取的。

3. 直方图(Histogram)

直方图是一种将多个数值聚合在一起的数据结构,可以表示数据的分布情况。比如以常见的响应耗时举例,可以把响应耗时数据分为多个桶(Bucket),每个桶代表一个耗时区间,例如0~100毫秒、100~500毫秒,以此类推。通过这样的形式,可以直观地看到一个时间段内的请求耗时分布,这将有助于我们理解耗时情况分布。

4. 摘要(Summary)

摘要与直方图类似,表示的也是一段时间内的数据结果,但是摘要反应的数据内容不太一样。摘要一般用于标识分位值,分位值其实就是我们常说的TP90、TP99等。例如有100个耗时数值,将所有的数值从低到高排列,取第90%的位置,这个位置的值就是TP90的值,如果这个桶对应的值假设是80ms,那么就代表小于等于90%位置的请求都≤80ms。

Kubernetes微服务监控体系

eb6f6df7442241528f298e7d53134444.png

前面我们从整体上描述了监控系统分层以及理解指标类监控系统所需要掌握的几类常见的指标类型。接下来我们重点探讨基于Kubernetes的微服务监控体系。

从监控对象及系统分层的角度看,监控系统需要监控的范围是非常广泛的,但从微服务监控的角度来说,如果你的微服务部署完全是基于Kubernetes云原生环境的,那么我们需要关注的监控对象主要就是Kubernetes集群本身以及运行其中的微服务应用容器。例如对容器资源使用情况,如CPU使用率、内存使用率、网络、I/O等指标的监控。

当然,这并不是说像基础层的物理机、虚拟机设备或者中间层软件的监控我们不需要关注,只是这部分工作一般会有专门的人员去维护。而如果使用的是云服务,那么云服务厂商大都已经为我们提供了监控支持。此外,对于基础物理层及大部分中间软件的监控并不是本文所要表达的重点,所以也就不再做过多的实践,大家对此有个全局的认识即可。

而回到以Kubernetes为载体的微服务监控体系,虽然曾经Kubernetes项目的监控体系非常复杂,社区中也有很多方案。但是这套体系发展到今天,已经完全演变成了以Prometheus项目为核心的一套统一方案。在本节的内容中我们就将演示如何围绕Prometheus来构建针对Kubernetes的微服务监控系统。

1. Prometheus简介

经过行业多年的实践和沉淀,目前监控系统按实现方式主要可以分为四类:1)、基于时间序列的Metrics(度量指标)监控;2)、基于调用链的Tracing(链路)监控;3)、基于Logging(日志)的监控;4)、健康性检查(Healthcheck)。而在上述几种监控方式中Metrics监控是其中最主要的一种监控方式。

简单理解Metrics的表现形式,就是在离散的时间点上产生的数值点[Time,Value],由某个指标组成的一组[Time,Value]数值点序列也被称为时间序列,所以Metrics监控也常常被称为时间序列监控。

如上所述,我们简单阐述了指标系统的基本特点,而接下来要介绍的Prometheus就是一款基于时间序列的开源Metrics类型的监控系统,它可以很方便地进行统计指标的存储、查询和告警。从整体上看Prometheus的系统结构,如下图所示:

3c51b4c07234b3feb29bef1475c6e589.png

从上图中可以看出,Prometheus工作的核心,主要是使用Pull(拉取)的模式去收集被监控对象的Metrics数据(监控指标数据),然后由Prometheus服务器将收到的指标数据进行聚合后存储到TSDB(时间序列数据库,例如OpenTSDB、InfluxDB)中,以便后续根据时间自由检索。

有了这套核心机制,Prometheus剩下的组件就主要是用来配合这套机制运行的了。比如PushGateway,它可以允许被监控对象以Push的方式向Prometheus推送Metrics数据。而Alertmanager,则可以根据Metrics信息灵活地设置报警。

此外,Prometheus还提供了一套完整的PromQL查询语言,通过其提供的HTTP查询接口,使用者可以很方便地将指标数据与Grafana(可视化监控指标展示工具)结合起来,从而灵活地定制属于系统自身的关键指标监控Dashboard(看板)。

2. Prometheus Operator安装部署

前面我们简单介绍了Prometheus监控系统的基本原理,接下来的内容将以实操的方式演示如何使用Prometheus构建一套针对Kubernetes集群的微服务监控体系。

在实际的应用场景中,针对不同的监控对象Prometheus的部署方式也会有所不同。例如要监控的对象是底层的物理机,或者以物理机方式部署的数据库等中间件系统,那么这种情况下一般也会将Prometheus监控系统的部署环境放置在物理机下。

而如果针对的是Kubernetes集群的监控,那么现在主流的方式是采用Promethues-Operator将Promethues部署到Kubernetes集群之中,这样能以更原生的方式实施对Kubernetes集群及容器的监控。这里所说的Promethues-Operator 是指专门针对Kubernetes的Promethues封装包,它可以简化Promethues的部署和配置。

接下来我们具体演示如何通过Promethues-Operator在Kubernetes中快速安装部署Promethues(Kubernetes实验环境可参考本专栏相关内容),具体步骤如下:

1)安装Helm

在本次安装过程中,将使用到Kubernetes的包管理工具Helm。Helm是Kubernetes的一种包管理工具,与Java中的Maven、NodeJs中的Npm以及Ubuntu的apt和CentOS的yum类似。主要用来简化Kubernetes对应用的部署和管理。

首先从Github下载相应的Helm安装包,具体命令参考如下:

#找到Github中Helm相关的发布包,参考链接如下
https://github.com/helm/helm/releases#确定好相关版本后,将具体安装版本下载至某个安装了kubectl的节点 
wget https://get.helm.sh/helm-v3.4.0-rc.1-linux-amd64.tar.gz

解压,并将下载的可执行Helm文件拷贝到文件夹/usr/local/bin下,命令如下:

tar -zxvf helm-v3.4.0-rc.1-linux-amd64.tar.gz 
#将下载的可执行helm文件拷贝到文件夹/usr/local/bin下
mv linux-amd64/helm /usr/local/bin/

之后执行helm version,如果能看到Helm版本信息,就说明Helm客户端安装成功了,具体如下:

$helm version
version.BuildInfo{Version:"v3.4.0-rc.1", 
GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", 
GitTreeState:"clean", GoVersion:"go1.14.10"}

安装完Helm客户端后,由于一些公共Kubernetes包是在远程仓库中管理的,所以还需要添加helm charts(Helm中的Kubernetes安装包又叫charts)官方仓库,命令如下:

$helm repo add stable https://charts.helm.sh/stable

查看本地helm仓库是否添加成功,命令如下:

$helm repo list
NAME      URL                          
stable    https://charts.helm.sh/stable

此时,查看Helm仓库就能看到各种组件的charts列表了,命令效果如下:

$helm search repo stableNAME                              CHART VERSION   APP VERSION     DESCRIPTION                                       
stable/acs-engine-autoscaler      2.1.3           2.1.1           Scales worker nodes within agent pools            
stable/aerospike 
...

如上所示,此时通过“helm search”命令就可以查看到各种stable版本的Kubernetes安装包了!

2)Helm搜索Prometheus-Operator安装包

在具体安装Prometheus-Operator之前,我们先用“helm”命令搜索Prometheus相关的charts包,命令如下:

$ helm search repo prometheus

具体搜索结果如下图所示:

7081c852faeee3909f7b39bf7492d660.png

如上图所示,我们可以看到Helm仓库中可以搜索到版本为0.38.1的“stable/prometheus-operator”的安装包。接下来就可以通过helm具体安装了!

3)Helm安装Prometheus-Operator监控系统

接下来啊,通过Helm具体安装prometheus-operator监控系统,命令如下:

#创建k8s名称空间
kubectl create ns monitoring#通过helm安装promethues-operator监控系统
helm install promethues-operator stable/prometheus-operator -n monitoring

执行安装命令后,输出结果如下:

WARNING: This chart is deprecated
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
NAME: promethues-operator
LAST DEPLOYED: Mon Oct 26 10:15:45 2020
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
NOTES:
*******************
*** DEPRECATED ****
*******************
* stable/prometheus-operator chart is deprecated.
* Further development has moved to https://github.com/prometheus-community/helm-charts
* The chart has been renamed kube-prometheus-stack to more clearly reflect
* that it installs the `kube-prometheus` project stack, within which Prometheus
* Operator is only one component.The Prometheus Operator has been installed. Check its status by running:kubectl --namespace monitoring get pods -l "release=promethues-operator"Visit https://github.com/coreos/prometheus-operator for instructions on how
to create & configure Alertmanager and Prometheus instances using the Operator.

执行完安装命令后,查看具体的Kubernetes Pods信息,命令如下:

$ kubectl get po -n monitoringNAME                                                     READY   STATUS    RESTARTS   AGE
alertmanager-promethues-operator-promet-alertmanager-0   2/2     Running   0          5m42s
prometheus-promethues-operator-promet-prometheus-0       3/3     Running   1          5m31s
promethues-operator-grafana-5df74d9cb4-5d475             2/2     Running   0          6m53s
promethues-operator-kube-state-metrics-89d8c459f-449k4   1/1     Running   0          6m53s
promethues-operator-promet-operator-79f8b5f7ff-pfpbl     2/2     Running   0          6m53s
promethues-operator-prometheus-node-exporter-6ll4z       1/1     Running   0          6m53s
promethues-operator-prometheus-node-exporter-bvdb4       1/1     Running   0          6m53s

如上所示,可以看到Prometheus监控系统相关的组件都以Pod的方式运行在了Kubernetes集群中。

Prometheus监控效果演示

eafd73756ab4327fdcadd4069d062e75.png

通过前面的实际操作,我们通过Helm的方式已经将Prometheus Operator安装包部署在了Kubernetes集群之中。而此时的Prometheus实际上就已经开始发挥作用,并采集了各类Kubernetes的运行指标信息。可以通过Promethues内置的监控界面对此进行查看,具体步骤如下:

查看Kubernetes中查看内置监控界面所在的Pod节点,命令如下:

kubectl -n monitoring get svc

使用nodeport方式将promethues-operator内置界面服务暴露在集群外,并指定使用30444端口,命令如下:

kubectl  patch svc promethues-operator-promet-prometheus -n monitoring -p '{"spec":{"type":"NodePort","ports":[{"port":9090,"targetPort":9090,"nodePort":30444}]}}'
service/promethues-operator-promet-prometheus patched

此时在浏览器中输入Pod节点所在的宿主机IP+端口地址,URL示例如下:

http://10.211.55.11:30444/graph

此时就可以看到Promethues内置的监控可视化界面了,效果如下图所示:

a84c3dfde620f2fd7e0b763ffcea39ec.png

而如果此时以PromeQL的方式查看一个具体指标,以“http_requests_total”为例,展示效果如图所示:

2ca8a0ceef7e7c79092f80fc3935e2b3.png

由此说明,此时Promethues监控系统已经开始运行,并采集了相关Metrics指标数据!

Grafana可视化监控系统

09bf5ad059713da2b86bd61b23466786.png

Grafana是一个强大的跨平台的开源度量分析和可视化工具,可以将采集的指标数据进行定制化的图形界面展示,经常被用作为时间序列数据和应用程序分析的可视化。Grafana支持多种数据源,如InfluxDB、OpenTSDB、ElasticSearch以及Prometheus。

前面我们在Kubernetes中安装部署Prometheus-Operator时,实际上Grafana就已经被集成并运行了,可以通过Kubernetes的相关命令查询Grafana的实际运行Pod,并将其Web端口对外进行暴露,具体如下:

#查看服务节点信息
kubectl -n monitoring get svc#使用nodeport方式将promethues-operator-grafana暴露在集群外,指定使用30441端口
kubectl  patch svc promethues-operator-grafana -n monitoring -p '{"spec":{"type":"NodePort","ports":[{"port":80,"targetPort":3000,"nodePort":30441}]}}'

需要注意由于Grafana的应用运行的默认端口为80,为避免实验环境冲突,这里映射时将目标容器端口指定为3000,并最终将节点端口映射为30441。完成后,浏览器输入URL:

#IP地址为映射命令执行时所在的节点
http://10.211.55.11:30441

如果映射正常,此时会返回Grafana可视化图形界面的登录界面,如图所示:

f02a5af46e2d8aab53115565839cd090.png

这里缺省登录账号密码为:admin/prom-operator。输入后可进入Grafana主界面如下图所示:

61c7d69ae4960b7331ee30a86506c006.png

可以看到部署完成的Grafana已经默认内置了许多针对Kubernetes平台的企业级监控Dashboard,例如针对Kubernetes集群组件的“Kubernetes/API server”、“Kubernetes/Kubelet”,以及针对Kubernetees计算资源的“Kubernetes/Compute Resources/Pod”、“Kubernetes/Compute Resources/Workload”等等。

这里我们找一个针对Kubernetes物理节点的“Nodes”监控Dashboard,点击打开后看到的监控效果如下图所示:

2143c3ba31fa044c961ba057f9bb1d29.png

上图所示的Dashboard中展示了Kubernetes集群所在的各物理节点CPU、负载、内存、磁盘I/O、磁盘空间、网络传输等硬件资源的使用情况。从这些丰富的视图可以看出Grafana强大的监控指标可视化能力!

后记

adde4a51e2d373b7495f56cdd8f5c383.png

本文给大家从理论到实践简单介绍了Kubernetes微服务监控体系的构建步骤,希望能够对大家学习Kubernetes有所帮助。目前以Kubernetes为代表的容器化技术已经成为现代软件应用发布的标准方式,作为一名普通研发人员,对Kubernetes的学习将有助于我们更深入的理解整体软件系统的构建原理,也是我们进阶提升必不可少的知识储备!

961582518b5e39ba7d599c964d4e01b6.gif

3c08db719efea495ddb865285006246d.png

往期推荐

做安全操作系统,这位技术老兵很认真

云原生时代,底层性能如何调优?

到底什么是“无源物联网”?

张一鸣购得元宇宙入场券,谁将是头号玩家?

e6b9b193ce6d70c44677088b67b41de4.gif

点分享

9ecff2f39d87293cddcfb91a747ac488.gif

点收藏

c90b3c3608d76709c247e695116ada82.gif

点点赞

35ce0b2e8824266431f8867897f54c64.gif

点在看

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/513929.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

python解zuobiaoxi方程_滑坡稳定性分析程序初探---Python版!

0 前言 山体滑坡是常见的自然灾害,从理论分析的角度讲,滑坡的稳定性分析方法源自于高中物理学,如图1所示。前者的滑动分析非常简单,在已知滑块的重量以及接触面摩擦系数的基础上通过计算下滑力和抗滑力的关系即可分析其稳定性&…

php 动态 控件,PHP技术在动态网页表单控件提取中的应用研究

曲小纳摘要:由于电子商务及网络信息技术的飞速发展,动态网站已经逐渐取代传统的静态网站,在不断向人工智能化等方向发展。该篇文章就针对PHP这种技术在动态网页表单控件提取中的应用进行详细的阐述。关键词:PHP;动态网页;表单中图…

冷启动延时缩短50%-80%,阿里云函数计算发布冷启动加速技术

简介: 近日,阿里云函数计算重磅发布冷启动加速技术,将原本属于开发者的镜像优化负担转由函数计算承担,进一步帮助开发者提高生产效率,专注业务创新。该技术源于阿里集团超大规模和场景高度复杂的容器环境,对…

评审恩仇录——IDE也能做代码评审?

简介: 云效Codeup推出了本地IDE插件端的评审,免除了黄药师来回华山的奔波之苦 现代科技公司的同事们平日一起交流开发规约和产品需求,肩上共同扛着业务发展和同行竞争的压力,这份还书贻剑的情谊如何能引来恩仇呢?通过…

云原生数据仓库TPC-H第一背后的Laser引擎大揭秘

简介: 作者| 魏闯先阿里云数据库资深技术专家 一、ADB PG 和Laser 计算引擎的介绍 (一)ADB PG 架构 ADB PG 是一款云原生数据仓库,在保证事务ACID 能力的前提下,主要解决云上海 量数据的实时分析问题。它的架构与传…

新云网、5G、Wi-Fi 6 Plus,探秘2021通信展上的锐捷网络黑科技

供稿 | 锐捷网络 出品 | CSDN云计算 2021年9月27日,主题为“创新点亮数字化未来”的第三十届中国国际信息通信展览会(PT EXPO 2021)在北京如期开幕。展会汇聚业内的科技创新技术专家和优秀企业,共同探讨数字化创新的新趋势、新场…

【OpenYurt 深度解析】边缘网关缓存能力的优雅实现

简介: 阿里云边缘容器服务上线 1 年后,正式开源了云原生边缘计算解决方案 OpenYurt,跟其他开源的容器化边缘计算方案不同的地方在于:OpenYurt 秉持 Extending your native Kubernetes to edge 的理念,对 Kubernetes 系…

python的类名一定要大写吗_python 类名

广告关闭 腾讯云11.11云上盛惠 ,精选热门产品助力上云,云服务器首年88元起,买的越多返的越多,最高返5000元! 如果我从中执行此操作的函数是实例的类派生的基类,我如何找到在python中创建对象实例的类的名称…

Elasticsearch生态技术峰会 | 阿里云Elasticsearch云原生内核

简介: 开源最大的特征就是开放性,云生态则让开源技术更具开放性与创造性,Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际,我们邀请业界资深人士相聚云端,共话云上Elasticsearch生态与技术…

剑指云原生数据库 2.0,阿里云发布全新一站式敏捷数据仓库解决方案

作为基础软件“三驾马车”之一的数据库,其发展历程可追溯到60年前:从上世纪50年代的层次数据库、网状数据库,70年代的关系型数据库,再到90年代的关系型数据库、数据仓库、PC单机数据库和 2000 年的开源数据库,Oracle等…

深度 | 面向云原生数据湖的元数据管理技术解析

简介: 作者:沐远、明惠 背景 数据湖当前在国内外是比较热的方案,MarketsandMarkets市场调研显示预计数据湖市场规模在2024年会从2019年的79亿美金增长到201亿美金。一些企业已经构建了自己的云原生数据湖方案,有效解决了业务痛点…

sql中“delete from 表名”表示_SQL查询语句知识点总结

为什么要学习SQL?数据分析岗位的基础技能:SQL语句和会使用SQL语句操纵数据库软件;数据量增大的工具需求:excel处理十万以内的数据;数据量增大,需要使用更快速便捷的工具分析数据。SQL知识点总结1数据库基础知识什么是…

Serverless 可观测性的过去、现在与未来

简介: 函数计算可观测性经历了 1.0 -> 2.0 的发展,从闭门造车的可观测发展成开源的可观测,从平台的可观测发展为开发者的可观测,从FaaS Only 的可观测演进成了云原生的可观测。 作者:夏莞 背景 Serverless 将成为…

Gartner:全行业投入人工智能,计算机视觉占比最高

编辑 | 宋慧 供稿 | Gartner Gartner最近一项新调研发现,三分之一拥有人工智能(AI)技术计划的技术和服务提供商企业机构表示,他们在未来两年对人工智能技术的投资将达到100万美元以上。绝大多数将人工智能技术作为主要投资领域的…

爱奇艺大数据生态的实时化建设

简介: 实时化是大数据未来最重要的方向之一。 作者|爱奇艺大数据团队 数据作为互联网时代的基础生产资料,在各大公司企业拥有举足轻重的地位。数据的价值在互联网公司的体现,大致而言可以分成三类: 发掘数据中的信息…

python机械臂仿真_基于Python的3R机器人运动仿真

一、问题描述 如右图所示的三自由度机械臂,关节1和关节2相互垂直,关节2和关节3相互平行。如图所示,所有关节均处于初始状态。 要求: (1) 定义并标注出各关节的正方向; (2) 定义机器人基坐标系{0}及连杆坐标…

AI 事件驱动场景 Serverless 实践

简介: 事件驱动是指事件在持续事务管理过程中,进行决策的一种策略。可以通过调动可用资源执行相关任务,从而解决不断出现的问题。通俗地说是当用户触发使用行为时对用户行为的响应。在 Serverless 场景下,事件驱动完美符合其设计初…

运维质变育新机,华为云能否引领政企运维破局?

头图 | 付费下载于视觉中国 提到IT运维,我们马上想到的,就是“7*24小时待命”、“救火”。作为IT安全运行的保障,长久以来,运维一直都是“不出事看不到价值,一出事全是锅”的角色。例如某企业自动化运维失效导致宕机…

封神-运维大脑 | 日志检测工具

简介: 封神-运维大脑 | 日志检测工具1. 背景目标 阿里云应用业务有问题,云平台监控可以发现问题,但并不能定位到问题根本原因,运维大脑监控底层日志,可快速定位问题原因,帮助现场运维同学解决问题。 运维大…

hive sql练习_经典的SparkSQL/Hive-SQL/MySQL面试-练习题

经典的SparkSQL/Hive-SQL/MySQL面试-练习题​mp.weixin.qq.com第一题需求:已知一个表order,有如下字段:date_time,order_id,user_id,amount。 数据样例:2020-10-10,1003003981,00000001,1000,请用sql进行统…