监控微信的插件(手机监视对方手机软件) 监控是保障系统稳定性的重要组成部分,在Kubernetes开源生态中,资源类的监控工具与组件监控百花齐放。 cAdvisor:kubelet内置的cAdvisor,监控容器资源,如容器cpu、内存; Kubestatemetrics:kubestatemetrics通过监听APIServer生成有关资源对象的状态指标,主要关注元数据,比如Deployment、Pod、副本状态等; metricsserver:metricsserver也是一个集群范围内的资源数据聚合工具,是Heapster的替代品,k8s的HPA组件就会从metricsserver中获取数据; 还有nodeexporter、各个官方、非官方的exporter,使用Prometheus来抓取这些数据然后存储,告警,可视化。但这些还远远不够。 监控的实时性与准确性不足 大部分资源监控都是基于推或者拉的模式进行数据离线,因此通常数据是每隔一段时间采集一次,如果在时间间隔内出现一些毛刺或者异常,而在下一个采集点到达时恢复,大部分的采集系统会吞掉这个异常。而针对毛刺的场景,阶段的采集会自动削峰,从而造成准确性的降低。 监控的场景覆盖范围不足 部分监控场景是无法通过资源表述的,比如Pod的启动停止,是无法简单的用资源的利用率来计量的,因为当资源为0的时候,我们是不能区分这个状态产生的真实原因。 基于上述两个问题,Kubernetes是怎么解决的呢?11事件监控 在Kubernetes中,事件分为两种,一种是Warning事件,表示产生这个事件的状态转换是在非预期的状态之间产生的;另外一种是Normal事件,表示期望到达的状态,和目前达到的状态是一致的。我们用一个Pod的生命周期进行举例,当创建一个Pod的时候,首先Pod会进入Pending的状态,等待镜像的拉取,当镜像录取完毕并通过健康检查的时候,Pod的状态就变为Running。此时会生成Normal的事件。而如果在运行中,由于OOM或者其他原因造成Pod宕掉,进入Failed的状态,而这种状态是非预期的,那么此时会在Kubernetes中产生Warning的事件。那么针对这种场景而言,如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。 一个标准的Kubernetes事件有如下几个重要的属性,通过这些属性可以更好地诊断和告警问题。 Namespace:产生事件的对象所在的命名空间。 Kind:绑定事件的对象的类型,例如:Node、Pod、Namespace、Componenet等等。 Timestamp:事件产生的时间等等。 Reason:产生这个事件的原因。 Message:事件的具体描述。〔rootmasterwork〕kubectlgeteventallnamespacesLASTSEENTYPEREASONOBJECTMESSAGEdefault14mNormalCreatedpodbusybox2Createdcontainerbusyboxdefault14mNormalStartedpodbusybox2Startedcontainerbusyboxdefault24mWarningFailedpodlitemallall584bfdcd99q6wd2Error:ErrImagePulldefault4m47sWarningFailedpodlitemallall584bfdcd99q6wd2Error:ImagePullBackOff12alikubeeventer 针对Kubernetes的事件监控场景,Kuernetes社区在Heapter中提供了简单的事件离线能力,后来随着Heapster的废弃,相关的能力也一起被归档了。为了弥补事件监控场景的缺失,阿里云容器服务发布并开源了kubernetes事件离线工具kubeeventer。支持离线kubernetes事件到钉钉机器人、SLS日志服务、Kafka开源消息队列、InfluxDB时序数据库等等。 GitHub地址:https:github。comAliyunContainerServicekubeeventer 下面是以企业微信机器人告警发送为例:〔rootnode1monitoring〕catkubeeventer。yamlapiVersion:appsv1kind:Deploymentmetadata:labels:name:kubeeventername:kubeeventernamespace:kubesystemspec:replicas:1selector:matchLabels:app:kubeeventertemplate:metadata:labels:app:kubeeventerannotations:scheduler。alpha。kubernetes。iocriticalpod:39;39;spec:dnsPolicy:ClusterFirstWithHostNetserviceAccount:kubeeventercontainers:image:registry。aliyuncs。comacskubeeventeramd64:v1。2。0484d9cdaliyunname:kubeeventercommand:kubeeventersourcekubernetes:https:kubernetes。default。e。g,dingtalksinkdemosinkdingtalk:〔yourwebhookurl〕label〔yourclusterid〕level〔NormalorWarning(default)〕sinkwebhook:https:qyapi。weixin。qq。comcgibinwebhooksend?key07055f32a04e4ad79cb1d22352769e1levelWlabeloak8ssinkwebhook:https:qyapi。weixin。qq。comcgibinwebhooksend?key07055f32a04e4ad79cb1d223levelWheaderContentTmethodPOSTenv:IfTZisassigned,settheTZvalueasthetimezonename:TZvalue:AsiaShanghaivolumeMounts:name:localtimemountPath:etclocaltimereadOnly:truename:zoneinfomountPath:usrsharezoneinforeadOnly:trueresources:requests:cpu:100mmemory:100Milimits:cpu:500mmemory:250Mivolumes:name:localtimehostPath:path:etclocaltimename:zoneinfohostPath:path:usrsharezoneinfoapiVersion:rbac。authorization。k8s。iov1kind:ClusterRolemetadata:name:kubeeventerrules:apiGroups:resources:eventsconfigmapsverbs:getlistwatchapiVersion:rbac。authorization。k8s。iov1kind:ClusterRoleBindingmetadata:name:kubeeventerroleRef:apiGroup:rbac。authorization。k8s。iokind:ClusterRolename:kubeeventersubjects:kind:ServiceAccountname:kubeeventernamespace:kubesystemapiVersion:v1kind:ServiceAccountmetadata:name:kubeeventernamespace:kubesystemapiVersion:v1data:content:{msgtype:text,text:{content:EventType:{{。Type}}nEventNamespace:{{。InvolvedObject。Namespace}}nEventKind:{{。InvolvedObject。Kind}}nEventObject:{{。InvolvedObject。Name}}nEventReason:{{。Reason}}nEventTime:{{。LastTimestamp}}nEventMessage:{{。Message}}}}kind:ConfigMapmetadata:name:customwebhookbodynamespace:kubesystem 效果: