Kubernetes运维生态-cAdvisor分析

Kubernetes的生态中,cAdvisor是作为容器监控数据采集的Agent,其部署在每个节点上,内部代码结构大致如下:代码结构很良好,collector和storage部分基本可做到增量扩展开发。

关于cAdvisor支持自定义指标方式能力,其自身是通过容器部署的时候设置lable标签项:io.cadvisor.metric.开头的lable,而value则为自定义指标的配置文件,形如下:

{
  "endpoint" : {
    "protocol": "https",
    "port": 8000,
    "path": "/nginx_status"
  },
  "metrics_config"  : [
    { "name" : "activeConnections",
      "metric_type" : "gauge",
      "units" : "number of active connections",
      "data_type" : "int",
      "polling_frequency" : 10,
      "regex" : "Active connections: ([0-9]+)"
    },
    { "name" : "reading",
      "metric_type" : "gauge",
      "units" : "number of reading connections",
      "data_type" : "int",
      "polling_frequency" : 10,
      "regex" : "Reading: ([0-9]+) .*"
    },
    { "name" : "writing",
      "metric_type" : "gauge",
      "data_type" : "int",
      "units" : "number of writing connections",
      "polling_frequency" : 10,
      "regex" : ".*Writing: ([0-9]+).*"
    },
    { "name" : "waiting",
      "metric_type" : "gauge",
      "units" : "number of waiting connections",
      "data_type" : "int",
      "polling_frequency" : 10,
      "regex" : ".*Waiting: ([0-9]+)"
    }
  ]

}

当前cAdvisor只支持http接口方式,也就是被监控容器应用必须提供http接口,所以能力较弱,如果我们在collector这一层做扩展增强,提供数据库,mq等等标准应用的监控模式是很有价值的。在此之前的另一种方案就是如上图所示搭配promethuese(其内置有非常丰富的标准应用的插件涵盖了APM所需的采集大部分插件),但是这往往会导致系统更复杂(如果应用层并非想使用promethuse)

在Kubernetes监控生态中,一般是如下的搭配使用:

时间: 2024-10-24 04:19:44

Kubernetes运维生态-cAdvisor分析的相关文章

Kubernetes运维之使用ELK Stack收集K8S平台日志

kubernetes运维之使用elk Stack收集k8s平台日志目录: 收集哪些日志 elk Stack日志方案 容器中的日志怎么收集 k8S平台中应用日志收集 一.收集哪些日志 ? k8s系统的组件日志 比如kubectl get cs下面的组件 master节点上的controller-manager,scheduler,apiservernode节点上的kubelet,kube-proxy? k8s Cluster里面部署的应用程序日志 标准输出 日志文件elk Stack日志方案,改怎

当前运维素质的分析

当前运维素质的分析... ---------------------- 将目前从事运维职业的朋友按时间大致分了三个类别: 第一批:2007年之前,目前这类朋友基本占据各公司中高层职位 第二批:2008年-2013年,这部分运维朋友基本是公司的中流砥柱,在主要的技术或是管理岗位 第三批:2013年之后从事运维工作的朋友,基本在做最基础的运维工作 第一类:学校里计算机学习成绩不错的一般都往BAT一二线公司去了,大部分还是从事研发类工作,留下一部分学习成绩一般的学生勉强去面试运维工作. 第二类:由于当

Kubernetes运维之部署主流JAVA应用

基于kubernetes部署JAVA项目将项目迁移到k8s平台是怎样实现的? 1制作镜像 2 控制器管理Pod 3 Pod数据持久化 4 暴露应用 5 对外发布应用 6 日志/监控 1制作镜像分为三步:第一基础镜像,是基于哪个操作系统,比如Centos7或者其他的第二步中间件镜像,比如服务镜像,跑的像nginx服务,tomcat服务第三步项目镜像,它是服务镜像之上的,将你的项目打包进去,那么这个项目就能在你这个服务镜像里面运行了 一般我们运维人员都是提前将我们的镜像做好,而开发人员就能直接拿这个

Kubernetes运维之微服务生产环境采坑分享

生产环境经验 1.限制了容器资源,还经常被杀死? 2.滚动更新之健康检查重要性 3.滚动更新之流量的丢失 先说一下第一个问题,限制容器资源,还经常去杀死的原因?就是说部署的java应用,不一会就重启了,其实重启就是在重建了,这就意味着你的pod是不健康的,然后k8s重新再帮你去拉取了,这样的话就要去找问题去排查了,说白了其实就是被杀死了,可以通过describe去查看一下事件,一般都会能看到,由于健康状态检查没通过,然后再去拉取的,因为是java应用,由于堆内存溢出,然后被kill掉,在日志最后

打造高效的运维日志收集与分析平台

0x01 背景      面对与日俱增的日志信息,最传统的日志收集方式已难以满足运维人员的基本需求.So,我们何不利用如今丰富的开源工具来打造一款高效实用的运维日志收集分析平台呢.以下就我们目前尝试在做的运维日志平台进行简要介绍,希望能与各位交流心得经验. 0x02 平台架构     我们并没有采用ELK的架构进行日志收集,而是采用了多款日志收集工具结合的方式,即EKF(K/Z), elasticsearch + kafka-zookeeper + Flume + kibana/zabbix.

2016全球运维大会,优云蒋君伟演讲“CMDB+自动化的管理融合”成一大亮点

2016全球运维大会于9月23日-24日在上海盛大开幕.作为国内运维行业的重量级大会,优云产品总监蒋君伟在自动化专场与来自全国各地的运维同行一起探讨.分享业内自动化运维的最佳实践.现场情绪热烈,气氛高涨,成为了本届全球运维大会的一大亮点. 全新梳理自动化与CMDB的融合之道 全球运维大会当天,运维自动化专场很多大牛针对自动化运维管理中的CMDB进行了激烈的讨论.来自优云软件的产品总监蒋君伟关于<CMDB+自动化的管理融合>作了精彩的主题演讲.蒋君伟提出了一个观点:“CMDB建设一定要以消费场景

智能运维解决方案:TOC -IT技术运行中心

TOC--IT技术运行中心(Technoical Operation Center )是网利友联在多年运维经验基础上,全新打造的一套综合智能运维解决方案. 运维现状 运维行业经过几十年的发展,基本上每个用户的信息中心都已经建立了一套完整的运维体系,这其中不乏最重要几个部分:人.物.数.业务在变,运维目标也在时刻发生着变化.如今的运维体系现状是有团队.有工具.有数据.但是面向智能运维生态的发展趋势,面对大数据分析计算场景,缺少的是数据汇聚.数据融合.告警关联分析.数据统一展现等.总结起来就是整个运

双态运维分享之:业务场景驱动的服务型CMDB

最近这几年,国内外CMDB失败的案例比比皆是,成功的寥寥可数,有人质疑CMDB is dead?但各种业务场景表明,当下数据中心运维,CMDB依然是不可或缺的一部分,它承载着运维的基础,掌握运维的命脉. 分析以往失败的案例,静静的想一想,失败无非两点: 一.CMDB自身建设能力不够,无法适应当下数据中心和云环境的新形势.当下数据中心的特点是敏捷.动态.持续发展.甚至当风暴来临时,数据中心的环境是瞬息万变.传统型CMDB跟不上节奏,只能望洋兴叹,频繁应付处理各式各样的问题. 二.非场景驱动,无法支

MongoDB 运维常用操作

MongoDB 运维常用操作     分析方法:    1. 通过top.free.iostat.iftop等工具查看Linux服务器平均负载.CPU利用率.IO.内存.swap.网络流量等,先定位到压力源头. 2. 通过mongostat.mongotop等分析MongoDB读写压力.观察Page Faults.Connections.Queues等性能指标. 3. 日志中默认记录超过100ms的请求,过滤出Overflow查询,再使用Mtools跟踪分析MongoDB日志文件中的慢查询语句.