适用性:此方案适用于在某些企业多主账号,多TKE环境的统一监控原理:TDCC注册集群,主要作用是让A账号下prom自动的在B账号的TKE下部署proxy-agent,当proxy-agent创建完成之后 ,监控的网络,仅仅只和proxy-server互通,这个时候TDCC即时挂掉,也不影响监控,这里其实完全可以在prom中的关联集群那里增加手动关联选项,这样,只要保证2个vpc是互通的,允许链接proxy-server 使用的vpc也关联到A账号下的CCN中A账号下创建CCN,并关联TKE vpc图片B账号下图片图片图片回到A账号CCN中,同意加入CCN网络,此时,A账号和B账号TDCC和TKE的内网已经可以互通,可以通过 2个vpc下的CVM进行网络测试图片3、在B账号下创建TKE集群图片等待B账号下TKE创建完成图片4、回到A账号,注册集群注册已有集群图片图片查看注册命令图片图片5、B账号,使用yaml创建资源,粘贴上图中的 proxy-server图片图片图片9、到这里,实际上A账号下prom监控B账号下TKE已经可以使用图片
原生节点 POD GPU 监控 如何查看原生节点 POD 基础监控? 前置条件: TKE 提供 elastic-gpu-exporter 组件用于获取 GPU 相关监控指标,需要先安装该组件采集GPU 指标数据,参考基础监控指标采集:容器服务 GPU 监控指标获取-TKE 标准集群指南-文档中心-腾讯云 Pod 中使用了gpu 资源基础监控面板才会有 gpu的 tab,否则将不会显示, 如下图: 超级节点 POD GPU 监控 如何查看超级节点 POD 基础监控? scaleTargetRef: apiVersion: apps/v1beta2 kind: Deployment name: nginx 更多指标参考HPA指标:容器服务 自动伸缩指标说明-TKE 标准集群指南-文档中心-腾讯云 配置 Grafana 面板 导入Grafana 面板数据 可以直接导入 TKE 整理的监控面板文件,如下: { "annotations": { "list
文章《腾讯云TKE-搭建prometheus监控》基于prometheus,手把手教你如何在TKE上搭建全面的平台和业务监控,为业务保驾护航。 这是系列文章的第三篇,前两篇链接如下: 腾讯云TKE-搭建prometheus监控(一):在TKE上搭建prometheus、安装exporter和api server监控。 腾讯云TKE-搭建prometheus监控(二):在TKE上搭建告警系统和图形监控界面。 本文主要介绍基于prometheus,手把手教你如何在TKE上使用telegraf和thanos。 具体可见链接:https://docs.influxdata.com/telegraf/v1.16/plugins/ 使用Telegraf的好处 采用server端采集方式之后,运维将节省大量的维护工作,统一升级 搭建prometheus监控》基于prometheus,手把手教你如何在TKE上搭建全面的平台和业务监控,为业务保驾护航,已经全部完结。
文章《腾讯云TKE-搭建prometheus监控》基于prometheus,手把手教你如何在TKE上搭建全面的平台和业务监控,为业务保驾护航。这是系列文章的第二篇,第一篇见链接。 本文主要介绍基于prometheus,手把手教你如何在TKE上搭建告警系统和图形监控界面。 在tke上,一般用service的内网ip,也就是服务ip。 除了自己写metrics,一个个打造自己的监控面板。grafana官方还提供了各种模版的监控。在import功能中,可以添加官方的模版。 image.png 总结: 本文详细介绍了,如何在TKE上,搭建基于prometheus的告警系统和图形监控界面。下篇文章,将介绍如何在TKE上如何使用telegraf以及thanos。
业务在使用TKE容器服务过程中,需要对集群情况、节点情况、业务pod情况等进行监控。而当集群规模较大时,业务pod种类繁多,如何进行全面的监控一大痛点。 本文基于prometheus,手把手教你如何在TKE上搭建全面的平台和业务监控,为业务保驾护航。 二、在TKE上安装Prometheus prometheus的server端安装,有几种方式:源码编译安装、二进制安装、docker安装。 可以在查询处,输入node,会出现node系列的监控指标: image.png 四、实现api server监控 在prometheus.yml中加上api server监控的job: - job_name 五、总结 本文详细描述了如何在TKE上搭建prometheus监控平台,以及如何安装exporter和api server监控。 下一篇文章将继续描述如何基于TKE实现告警和图形化界面监控。
例如,您可以监控服务的 CPU 利用率、内存使用率和磁盘 I/O。 监控 目前覆盖的监控指标请参见 监控及告警指标列表。 操作场景 腾讯云容器服务默认为所有集群提供基础监控功能,您可以通过以下方式查看容器服务的监控数据。 展开【节点管理】,即可查看节点和 Master&Etcd 节点的监控信息。 选择【节点】>【监控】,即可进入【节点监控】页面,查看监控信息。 单击【监控】,进入【节点监控】页面。 单击【Pod】,将【所属节点】选择为您想查看的节点,即可查看到该节点内 Pod 的监控指标对比图。 选择【Pod 管理】页签,单击【监控】,进入【Pod 监控】页面。
多监控平台统一 | Hawkeye Posted March 27, 2018 近年来出现越来越多的监控平台, 每一个监控平台都是其擅长的地方, 比方说 zabbix 监控收集, 并监控基础服务。 grafana 监控平台可以很好的展示数据, kibana 又是日志相关的监控, 可以很出色的自定义很多业务监控。 总而言之基本上大多数有一定技术规模的公司, 运维都有很多监控平台。 多监控平台虽然好, 但暴露一个问题, 那就是关注度低, 因为有时候祸绝不单行, 一个问题的爆发, 往往在底层或者高层就已经暴露出来, 而我们需要来回的切换各个平台的监控图表, 这样排查起来非常慢。 如果我们能够更立体的看全部的监控报表, 那么暴露的问题也就一目了然了。 我进入 teambition 刚开始就是在做多监控平台统一的事情, 当时想的是把所有的数据全部写到一个平台, 而后通过结构化数据统一生成图表。 但构思太大, 实现起来艰难。 于是此项目难产了。
在系列文章(1)中,实现了用云原生监控采集TKE集群中节点上守护进程的监控指标。接下来,进一步描述下如何用云原生监控来采集TKE集群外组件的监控指标,比如Kong。 前提:网络互通 采集方案 image.png 1 云原生监控支持的监控配置入口有三个:ServiceMonitors、PodMonitors、RawJobs,其中ServiceMonitors是已k8s subsets: - addresses: - ip: 192.0.2.42 ports: - port: 8001 name: http 2 在云原生监控控制台上创建
现在很多业务为了能否在k8s上进行一些定制的二次开发,都会选择tke的独立集群,独立集群,用户可以自行管理master做一下定制化配置,如果是托管集群,需要工单联系后端修改。 对于独立集群,master是用户自行管理,所以master的监控需要自行监控,这里一般可以直接通过腾讯云托管的prometheus(TMP)来监控master,但是tmp不会监控到k8s的etcd,只有 apiserver、scheduler等监控,这个时候etcd的监控就需要我们自己来做。 tke独立集群创建:https://cloud.tencent.com/document/product/457/32189tmp关联tke独立集群:https://cloud.tencent.com/ 官网grafana的etcd模板监控如下图片集成中心etcd模板监控如下图片这里可能有些指标没有或者promsql的label匹配有问题,这里根据实际的label匹配修改下即可。
在TKE集群中,有些组件是以daemonSet或者二进制的方式运行在集群中的节点上,作为了节点上的守护进程。对于这类组件的监控采集,也是支持接入到TKE的云原生监控中。 云原生监控 云原生监控的数据采集配置支持了三个配置入口:ServiceMonitor、PodMonitor、RawJob,其中ServiceMonitor、PodMonitor属于promethues 本文描述的Docker Daemon的监控采集也主要是基于云原生监控的RawJob配置入口来实现。 采集方案 [image2021-2-25_14-34-49.png] 1 通过新增RawJob配置,应用到云原生监控,来采集TKE集群中节点上的docker daemon的监控。 2 云原生监控通过k8s服务发现配置(kubernetes_sd_config)自动从TKE集群同步所有的node实例,并作为当前RawJob的target实例。
腾讯云Prometheus 监控服务(Managed Service for Prometheus,TMP)是针对云原生服务场景进行优化的监控和报警解决方案,全面支持开源 Prometheus 的监控能力 具体的介绍和使用可以参考文档https://cloud.tencent.com/document/product/457/71896现在基本上都会用tmp来监控腾讯云的tke集群,为了能够服务的快速扩缩容 ,很多时候tke集群会加入超级节点,超级节点的相关介绍可以参考文档https://cloud.tencent.com/document/product/457/74014超级节点其实类似于一台超大规格的 当tmp关联了tke集群后,会自动发现监控所有节点,然后加入到kubelet的target,但是实例上超级节点上是不存在对应的metrics接口的,因此tmp页面会显示超级节点的target是down状态 图片虽然这个不影响监控数据的采集和查看,但是有强迫症的人就无法接受这类异常提示,下面我们说下如何取消超级节点kubelet的监控。
监控和异常监控,都需要自己编码定义监控规则和告警,效率很低。 需求 为了解决如上的问题,我整理了一下内部对应监控的可能需求: 1、内部服务的监控(Metrics) 2、网站、服务接口外部可用性监控 3、服务器硬件相关指标监控 4、数据库、中间件等监控 5、 自定义的一些业务指标监控(Exporter) 6、灵活的自定义告警规则(AlertManager) 7、链路监控(skywalking) 产品调研 Zabbix 传统监控产品,主要在服务器相关监控方面有优势 Hertzbeat 国产小众监控,主打无侵入式,无Agent监控,支持JVM,MYSQL,Linux, Kubernetes等应用服务,数据库,操作系统,中间件,云原生等监控。 /docs/ 刚看到的个人开源监控产品,群交流活跃,个人觉得功能够用但是不够美观 Prometheus 云原生时代监控产品,支持自定义配置告警,自定义监控,Go语言开发,资料较多 这是监控三字塔
目录 一、DevOps浪潮下带来的监控挑战 二、统一监控平台架构解析 三、日志监控的技术栈 四、日志监控经典方案ELK 五、微服务+容器云背景下的日志监控实践Journald+fluentd+elasticsearch 监控源的多样化挑战 业务、应用、网络设备、存储设备、物理机、虚拟机、容器、数据库、各种系统软件等等,需要监控的对象越来越多,指标也多种多样,如何以一个统一的视角,监控到所有的数据? 一个好的统一监控平台,应当具备如图所示的能力: 高度抽象模型,扩展监控指标:正如之前所说,监控源、指标的多样化,要求我们必须要进行监控模型的高度抽象,并且针对于指标可以动态扩展,这样才能保证监控平台的健壮性和可扩展性 二、统一监控平台架构解析 统一监控平台由七大角色构成:监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。 ? 考虑到统一日志源,我们最终决定让所有的日志都输入到系统日志journald中,由journald作为统一对外日志发送来源。UMC系统的日志监控架构如图所示: ?
1sentry[1] sentry是一个跨平台的错误监控和搜集的异常上报监控系统。 sentry主要用于实时监控的应用服务,收集相关应用服务在运行状态时出现的异常或者错误日志信息,并且sentry会通过自身集成的通知渠道将错误信息推送给维护人员。 ,即可看到整个项目的状态信息 go-gin-sentry相关信息 7参考 Introducing Snuba: Sentry's New Search Infrastructure 转转商业前端错误监控系统 (Sentry)策略升级 Sentry(v20)云原生架构探索,前/后端监控与事件日志大数据分析,高性能高可用可扩展可伸缩集群 事件存储过程 sentry系列的文章
概述 在某些情况下,Metrics 监控的 2 大顶流: •Zabbix: 用于非容器的虚拟机环境•Prometheus: 用于容器的云原生环境 是共存的。 但是在这种情况下,统一监控展示就不太方便,本文介绍利用 Grafana 对接 Zabbix, 来作为统一监控展示端。Let's go! Grafana-Zabbix 功能亮点 Grafana-Zabbix 是 Grafana 的一个插件,允许可视化来自 Zabbix 的监控数据,并创建用于分析指标和实时监控的仪表板。 该项目的主要目标是扩展 Zabbix 的监控数据可视化功能,并提供快速、强大的方法来创建仪表板。 Grafana 与 Grafana-Zabbix 插件相结合,可以创建很棒的仪表板。 •Logging•Tracing 在这种情况下,将所有的这些监控都视作 Grafana 的数据源,实现监控数据的统一展示和联动: 统一展示:Grafana 可观察性技术栈 联动: 1.在 Slack
简介 相比于大而全的 ELK 日志监控平台,统一异常监控平台更推荐使用——sentry。 ELK是通用数据存储和查询服务,专长是基于关键字的海量搜索,同时通过搭配一些插件以后,它也可以做一些异常日志监控之类的工作,但这个不是ELK的专长。 Sentry是异常监控(error tracking)和告警平台,和普通日志比起来,异常日志相对少。Sentry可以独立部署,内部有各种优化(缓存/异步/限流/分组等),保证高性能处理异常日志。 Senty是专门用来干异常日志监控的,它的核心就是围绕异常日志来建模和设计的,它有很多的异常日志监控特性,包括智能错误分析,归类汇总,自动分配告警到相关团队等等,这些虽然理论上ELK也能实现,但是实现成本比较高
上了一定规模的企业里,在IT运维管理方面一般都上线了相应的监控工具,例如:基础系统监控、网络监控、机房动环监控、应用性能监控、日志监控等。 企业IT业务和技术发展太快,监控能力跟不上; 产品化监控建设思路,导致存在各种监控烟囱; 市场监控产品现状和运维人对于监控认知的误区; 如何解决呢? 由要找一个大而全的监控产品,囊括全部的监控诉求……转变为需要一个具备功能生长性的监控平台,来承载核心监控诉求,并能统一集成外部的各种监控产品,服务于业务监控的目标……。 ? 集成能力,能够对接和集成外部监控工具和系统 监控aPaaS层 我们称之为监控场景工具层,通过调用平台层的监控能力和监控工具,面向具体的应用和业务,提供组装式的、复合的监控场景工具,例如:统一告警中心、监控可视化中心 如此一来,基于平台化监控体系,我们就能够解决文章开头部分的问题,实现:多采集源兼容、监控告警统一关联处理、监控逻辑分层、监控对象灵活扩展、监控架构解耦,避免过往隔三差五重复建烟囱的企业IT监控建设模式,
(一)产品概述 腾讯云容器服务(Tencent Kubernetes Engine,TKE)是高度可扩展的高性能容器管理服务,您可以在托管的云服务器实例集群上轻松运行应用程序。 (二)产品优势 腾讯云容器服务 TKE 对比自建容器服务 优势 腾讯云容器服务(TKE) 自建容器服务 简单易用 简化集群管理 腾讯云容器服务提供超大规模容器集群管理、资源调度、容器编排、代码构建,屏蔽了底层基础构架的差异 腾讯云容器服务 TKE 监控对比自建容器监控 腾讯云容器服务监控为容器集群、服务、实例提供数据收集和数据展示功能。 使用容器服务监控,您可以查看集群、节点、服务、实例、容器等近30个指标的监控统计数据,验证集群是否正常运行并创建相应告警,监控指标覆盖面广,并且在持续增加中。 容器服务 TKE 模块:容器服务核心模块,包括集群的增删改查、服务的增删改查等。
前言 在 腾讯云TKE - 基于 Cilium 统一混合云容器网络(上) 中,我们介绍 TKE 混合云的跨平面网络互通方案和 TKE 混合云 Overlay 网络方案。 BMP 监控 基于 BGP Monitoring Protocol[6] 开发 BMP Server,用于对 BGP 会话的运行状态进行实时监控,包括对等体关系的建立与关闭、路由信息等。 不再由 kube-controller-manager 组件来分配节点 PodCIDR,而是由 tke-ipamd 组件统一给节点分配 PodCIDR Cilium Agent 通过 CiliumNode 腾讯云容器团队打通公有云与 IDC 环境差异,为客户提供统一管理视图,实现多云场景、IDC 场景以及边缘场景的统一。 除了单集群能力的统一,腾讯云容器团队在集群注册、多集群管理、跨云跨集群互访等方面也有统一的方案,欢迎关注与体验。
通过容器等云原生技术,可以屏蔽混合云异构集群底层计算资源基础设施的差异,实现多云场景、IDC 场景乃至边缘等场景的统一。 为了屏蔽底层不同网络环境的差异,TKE 提出了混合云容器网络方案,在容器层面看到的是统一的网络平面,使得 Pod 无需感知其是运行在 IDC 的计算节点还是公有云的计算节点。 客户有时候并不想改变自己 IDC 环境的基础网络设置,却希望能有一套统一的容器网络。 基于 VxLAN 的高度可扩展性,只需要打通节点之间的网络,就可在此之上实现统一的容器网络。 Overlay 的混合云容器网络可以通过隧道模式屏蔽底层不同网络环境的差异,实现容器层面看到的是统一的网络层面。