Prometheus

一、 原先版本是用heapster来收集资源指标才能看，但是现在heapster要废弃了。 从k8s v1.8开始后，引入了新的功能，即把资源指标引入api； 在使用heapster时，获取资源指标是由heapster自已获取的，heapster有自已的获取路径，没有通过apiserver，后来k8s引入了资源指标API(Metrics API)，于是资源指标的数据就从k8s的api中的直接获取，不必再通过其它途径。 metrics-server： 它也是一种API Server，提供了核心的Metrics API，就像k8s组件kube-apiserver提供了很多API群组一样，但它不是k8s组成部分，而是托管运行在k8s之上的Pod。 为了让用户无缝的使用metrics-server当中的API，还需要把这类自定义的API，通过聚合器聚合到核心API组里， 然后可以把此API当作是核心API的一部分，通过kubectl api-versions可直接查看。 metrics-server收集指标数据的方式是从各节点上kubelet提供的Summary API 即10250端口收集数据，收集Node和Pod核心资源指标数据，主要是内存和cpu方面的使用情况，并将收集的信息存储在内存中，所以当通过kubectl top不能查看资源数据的历史情况

1、问题发现 Prometheus报警live服务的某个节点Old GC过多，需要排查。 2、问题分析 查看Prometheus，发现这个节点在11点18分到11点28分，仅仅10分钟内，进行了5次Full GC，根据经验（这样说可能有点扯淡），应该是某个特定接口导致的。 3、使用GCViewer分析GC日志 从图中可以看到，在发生Full GC的时间段内，老年代的使用不到200M，老年代的总大小为760多M。很显然，这个不是由于内存不够导致的。 ###4、查看GC原因 可以看到5次GC的原因都是 System.gc() ，说明代码中调用了方法 System.gc() （当然可能是业务同学自己写的代码，也可能是依赖包中的）。 ###5、在ELK中查看该服务在该时间段内的调用情况 ELK日志显示可能是导出Excel导致（历史原因：严格来讲，线上服务不应该提供这种导出功能，这部分功能正在慢慢向大数据团队迁移，但是还没迁移完） 6、查看代码 根据日志信息查看代码发现确实是导出Excel操作导致，依赖包中的 jxl.read.biff.WorkbookParser 类中，强制使用了方法 System.gc() 进行GC。 来源： oschina 链接： https://my.oschina.net/u/4344027/blog/3393626

RabbitMQ的基本安装 一 docker下安装RabbitMQ 首先使用 docker search rabbitmq命令查找docker仓库是否存在rabbitmq镜像，可以发现docker仓库是存在rabbitmq的 1 [root@admin ~ ]# docker search rabbitmq 2 NAME DESCRIPTION STARS OFFICIAL AUTOMATED 3 rabbitmq RabbitMQ is an open source multi-protocol me… 2809 [OK] 4 bitnami/rabbitmq Bitnami Docker Image for RabbitMQ 35 [OK] 5 tutum/rabbitmq Base docker image to run a RabbitMQ server 20 6 kbudde/rabbitmq-exporter rabbitmq_exporter for prometheus 12 [OK] 7 frodenas/rabbitmq A Docker Image for RabbitMQ 12 [OK] 8 cyrilix/rabbitmq-mqtt RabbitMQ MQTT Adapter 7 [OK] 9 arm32v7/rabbitmq RabbitMQ is an

课程概要 在当下，云原生的火爆不容小觑。随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势，云原生（Cloud Native）的概念也应运而生，更是火得一塌糊涂。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。而作为云原生的基石之一，监控和日志的重要性自是不言而喻。 监控（Monitoring）和日志（Logging），是大型分布式系统中最关键的基础设施之一。因为没有监控，就没办法知晓服务的运行情况，也没办法知道集群中有没有Down机、机器的CPU使用率和负载是否正常、网站的Traffic是否正常，以及服务的出错率是不是在可容忍范围之内。简而言之，监控使得我们可以实时了解网站的运营情况和可用性情况。 监控通常是从整体上了解网站的情况，需要具备实时性，而日志则是详尽地记录着系统运行情况，每一次Service的调用，每一次数据库的访问，都应该写进日志，特别是当系统出现问题时，我们希望日志系统能提供完整的错误堆栈和尽可能完备的上下文，从而为系统维护提供支持。 为了帮助开发者对云原生监控和日志解决方案等概念有个系统的了解和应用，4月1日

工作中用了容器？熟悉这些出自云原生计算基金会的项目吗？ 随着用容器来开发应用的实践变得流行， 云原生应用 也在增长。云原生应用的定义为： “云原生技术用于开发使用打包在容器中的服务所构建的应用程序，以微服务的形式部署，并通过敏捷的 DevOps 流程和持续交付工作流在弹性基础设施上进行管理。” 这个定义提到了构成云原生应用的不可或缺的四个元素： 容器 微服务 DevOps 持续集成和持续交付 (CI/CD) 尽管这些技术各有各自独特的历史，但它们之间却相辅相成，在短时间内实现了云原生应用和工具的惊人的指数级增长。这个 云原生计算基金会（CNCF） 信息图呈现了当今云原生应用生态的规模和广度。 云原生计算基金会项目 我想说，瞧着吧！这仅仅是一个开始。正如 NodeJS 的出现引发了无数的 JavaScript 工具的爆炸式增长一样，容器技术的普及也推动了云原生应用的指数增长。 好消息是，有几个组织负责监管并将这些技术连接在一起。 其中之一是 开放容器倡议 Open Containers Initiative（OCI），它是一个轻量级的、开放的治理机构（或项目），“它是在 Linux 基金会的支持下形成的，其明确目的是创建开放的行业标准的容器格式和运行时。” 另一个是 CNCF，它是“一个致力于使云原生计算普及和可持续发展的开源软件基金会”。 通常除了围绕云原生应用建立社区之外

Loki 是 Grafana Labs 团队最新的开源项目，是一个水平可扩展，高可用性，多租户的日志聚合系统。它的设计非常经济高效且易于操作，因为它不会为日志内容编制索引，而是为每个日志流编制一组标签。项目受 Prometheus 启发，官方的介绍就是： Like Prometheus, but for logs. ，类似于 Prometheus 的日志系统。 介绍 与其他日志聚合系统相比， Loki 具有下面的一些特性： 不对日志进行全文索引。通过存储压缩非结构化日志和仅索引元数据，Loki 操作起来会更简单，更省成本。 通过使用与 Prometheus 相同的标签记录流对日志进行索引和分组，这使得日志的扩展和操作效率更高。 特别适合储存 Kubernetes Pod 日志; 诸如 Pod 标签之类的元数据会被自动删除和编入索引。 受 Grafana 原生支持。 Loki 由以下3个部分组成： loki 是主服务器，负责存储日志和处理查询。 promtail 是代理，负责收集日志并将其发送给 loki 。 Grafana 用于 UI 展示。 安装 DockerHub 上提供了 Loki 和 Promtail 的 Docker 镜像，为了方便我们这里直接使用 docker-compose 进行一键安装，其他方式可以参考 Loki 的 文档介绍 。 首先直接 Clone 源代码： $

Uber一个团队放弃「微服务」改用「宏服务」 https: // t.cj.sina.com.cn/articles/view/3172142827/bd130eeb01900m57y 微服务不是银弹 2020年04月10日 21:52 云头条 语音播报 缩小字体 放大字体 微博 微信 分享 0 人们要么爱微服务，要么恨微服务，没多少人既爱又恨微服务。 因此，当优步（Uber）这种公司的哪怕一个团队宣布从微服务改用宏服务，这颇能说明问题。想想你对优步公司有什么看法，不过从软件角度来看，优步一向是良好的企业公民。 优步支付体验平台的工程经理Gergely Orosz在一条推文中暗示了架构方向发生变化： @GergelyOrosz：郑重申明一下，我们优步正将许多微服务转移到@Cindy Sridharan 所说的宏服务（macroservice，即大小适中的服务）。 对成千上万个微服务进行b/c测试和维护不仅很棘手，长期造成的麻烦比短期解决的麻烦还要多。 微服务确实可以帮助团队尽早迅速行动。 等到你意识到数量更少的服务会很好时，已为时已晚。你需要解决许多服务的“棘手”部分。 我们不断添加更多的服务，但也在停止使用服务，并更慎重地考虑新服务。 @GergelyOrosz： 是的，我们正在这么做，这种方法触及许多微服务的痛点。 每个服务都需要支持租约，包括许多无状态的租约。

一、前言 　　　　鄙人就职于某安全公司，团队的定位是研发安全产品云汇聚平台，为用户提供弹性伸缩的云安全能力。前段时间产品组提出了一个监控需求，大致要求：平台对vm实行动态实时监控，输出相应图表界面，并提供警报（资源不足等问题而产生）等功能。 二、方案调研 　　　　经过团队调研，目前业界流行的监控方案大致有这么几种：基于 zabbix 的、基于 prometheus 的、基于 influxdb 等时序数据库的。结合当前我们的业务场景来讲，zabbix对我们来说有点重，而 influxdb 方案灵活但是投入的研发时间可能是比较多的，prometheus就成了我们的不二之选择。 三、prometheus介绍 　　　　 1. What is prometheus ? 下面是官网的一段原话： 　　　　 Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud . Since its inception in 2012, many companies and organizations have 　adopted Prometheus, and the project has a very active developer and user

No.1 引言 在这个特殊的时期里，有比较多的时间折腾技术，在前段时间折腾完Cobbler以及Ansible Tower后，想着要折腾啥？这时候想起来，之前看技术文章知道最新版本的Ceph Nautilus官方集成了Dashboard界面，只是看过截图，感觉是很炫酷，在Ceph经历了多年的使用多种第三方Dashboard工具，如：Calamari、VSM等后，终于迎来了官方Dashboard，最初只是想体验下原生的Dashboard是什么样子的，在开始搭建的过程中，发现Dashboard的模式不是直接启用模块所有的功能就能正常使用，初始安装好只有最基本的Ceph集群以及RBD管理等功能，像文件存储、对象存储、iSCSI网关、NFS网关、监控都是没有集成的，都需要单独集成，Ceph启用Dashboard的资料网上能找到的多数是直接启用Dashboard模块，集成其它模块的中文资料也很少，因此也开启了一路不断踩坑不断验证的模式，历时数十天终于安装集成完毕，现总结下经验，供同行参考，避免大家浪费时间踩坑，故引出此文。 No.2 Ceph Dashboard介绍 Ceph的官方Dashboard正式是从Ceph luminous版本开始，最初是一个简单的只读视图，可查看Ceph集群的各种运行时信息和性能数据，而无需身份验证或任何管理功能。 Ceph

1、下载 wget https://github.com/prometheus/prometheus/releases/download/v2.17.1/prometheus-2.17.1.linux-amd64.tar.gz & 2、解压 tar -xvf prometheus-2.17.1.linux-amd64.tar.gz 3、配置添加nacos - job_name: 'nacos' # metrics_path defaults to '/nacos/actuator/prometheus' # scheme defaults to 'http'. static_configs: - targets: ['192.168.19.198:8848'] 3、启动 ./prometheus --config.file=prometheus.yml 4、访问 http://192.168.3.212:9090/graph 来源： oschina 链接： https://my.oschina.net/internetafei/blog/3269899