Prometheus

1、Rook & Ceph 介绍 1.1、Rook Rook 是专用于 Cloud-Native 环境的文件、块、对象存储服务。 它实现了一个自动管理的、自动扩容的、自动修复的分布式存储服务。 Rook 支持自动部署、启动、配置、分配、扩容/缩容、升级、迁移、灾难恢复、监控以及资源管理。 为了实现所有这些功能，Rook 需要依赖底层的容器编排平台，例如 kubernetes、CoreOS 等。 Rook 目前支持 Ceph、NFS、Minio Object Store、Edegefs、Cassandra、CockroachDB 存储的搭建，后期会支持更多存储方案。 1.2、Ceph Ceph 是一个开源的分布式存储系统，包括对象存储、块设备、文件系统。 它具有高可靠性、安装方便、管理简便、能够轻松管理海量数据。 Ceph 存储集群具备了企业级存储的能力，它通过组织大量节点，节点之间靠相互通讯来复制数据、并动态地重分布数据，从而达到高可用分布式存储功能 使用 Rook 可以轻松实现在 Kubernetes 上部署并运行 Ceph 存储系统，并且提供 Dashboard 供用户查看存储系统信息，Rook 跟 Kubernetes 集成关系示意图如下： 说明一下： Rook 提供了卷插件，来扩展了 K8S 的存储系统，使用 Kubelet 代理程序 Pod 可以挂载 Rook

前言 前一段时间使用SpringBoot创建了一个 webhook 项目，由于近期项目中也使用了不少SpringBoot相关的项目，趁着周末，配置一下使用prometheus监控微服务Springboot。 项目配置 引入坐标 <!-- Exposition spring_boot --><dependency> <groupId>io.prometheus</groupId> <artifactId>simpleclient_spring_boot</artifactId> <version>0.1.0</version></dependency><!-- Hotspot JVM metrics --><dependency> <groupId>io.prometheus</groupId> <artifactId>simpleclient_hotspot</artifactId> <version>0.1.0</version></dependency><!-- Exposition servlet --><dependency> <groupId>io.prometheus</groupId> <artifactId>simpleclient_servlet</artifactId> <version>0.1.0</version></dependency>

之前，我写过几篇有关「线上问题排查」的文章，文中附带了一些监控图，有些读者对此很感兴趣，问我监控系统选型上有没有好的建议？ 目前我所经历的几家公司，监控系统都是自研的。其实业界有很多优秀的开源产品可供选择，能满足绝大部分的监控需求，如果能从中选择一款满足企业当下的诉求，显然最省时省力。 这篇文章，我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括3部分。 必知必会的监控基础知识 监控系统俗称「第三只眼」，几乎是我们每天都会打交道的系统，下面 4 项基础知识我认为是必须要了解的。 监控系统的7大作用 正所谓「无监控，不运维」，监控系统的地位不言而喻。不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么？它能发挥什么作用？ 实时采集监控数据 ：包括硬件、操作系统、中间件、应用程序等各个维度的数据。 实时反馈监控状态 ：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。 预知故障和告警： 能够提前预知故障风险，并及时发出告警信息。 辅助定位故障： 提供故障发生时的各项指标数据，辅助故障分析和定位。 辅助性能调优： 为性能调优提供数据支持，比如慢SQL，接口响应时间等。 辅助容量规划： 为服务器、中间件以及应用集群的容量规划提供数据支撑。 辅助自动化运维：

1、监控linux机器 node-exporter 被监控的机器 安装 https://github.com/prometheus/node_exporter/releases/download/v0.17.0/node_exporter-0.17.0.linux-amd64.tar.gz 这里导入的 数据源非彼数据源 ，而是用 grafana画好的 dashborad 这里的数据源 才是选择 prometeus 的数据源 配置 ---- piechart插件 安装pie插件 官网： https://grafana.net/plugins/grafana-piechart-panel grafana的默认插件目录是/var/lib/grafana/plugins，可以将下载好的插件解压到这个目录， 重启grafana即可 service grafana-server restart /usr/sbin/grafana-cli plugins ls #查看已安装插件 启动 效果图 2、监控Windows机器 wmi-exporter 被监控windows机器安装wmi-exporter，会自动创建一个开机自启的服务 https://github.com/martinlindhe/wmi_exporter/releases 默认wmi-exporter 端口为：9182 - job

名称： Thanos 类型： 监控 说明： Thanos是一组组件，组成一个高度可用的度量系统，具有无限的存储容量，无缝地添加到现有的Prometheus部署之上。Thanos利用Prometheus 2.0存储格式，在任何对象存储中高效地存储历史度量数据，同时保留快速查询延迟。此外，它还提供了一个跨所有Prometheus安装的全局查询视图，可以动态地合并来自Prometheus HA对的数据。项目具体目标是：度量的全局查询视图；度量的无限保留；组件的高可用性，包括Prometheus。Thanos由Cloud Native Computing Foundation（CNCF）托管。如果您是一家希望帮助塑造容器打包、动态调度和面向微服务的技术发展的公司，请考虑加入CNCF。有关谁参与以及Thanos扮演角色的详细信息，请阅读Thanos的 建议书 。 https://github.co m/cncf/toc/blob/master/proposals/thanos.md 网站/代码： https://th anos.io/ https://github.com/thanos-io/thanos 文档： https://thanos.io/getting-started.md/ 错误和功能请求： https://github.com/thanos-io/thanos/issues

prometheus监控k8s集群 具体版本 Prometheus:v2.2.1 kubernetes:v1.18.9 Grafana:latest alertmanager:v0.14.0 metrics:v1.3.0 Prometheus是继Kubernetes项目以后CNCF基金会第二个托管项目，最初建于SoundClound，是一个开源的系统监控和警报工具包，独立于任何公司的一个独立的开源项目 详细介绍请查看官方文档： https://prometheus.io/docs/introduction/overview/ 实现思路： 各node_exporter收集的信息Push到Prometheus，集群部署prometheus进行服务发现和采集信息，然后经过Prometheus进行处理后，Grafana进行效果展示，Altermanager进行报警管理 prometheus监控k8s架构 prometheus采用的是StatefulSet有状态部署，我们需要提前搭建好NFS存储，采用动态PV的存储给prometheus； 官方文档地址： https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config 官方部署文档： https://github

摘要：本文以 Docker 为例，依托阿里云日志服务团队在日志领域深耕多年积累下的丰富经验，介绍容器日志处理的一般方法和最佳实践。 背景 自 2013 年 dotCloud 公司开源 Docker 以来，以 Docker 为代表的容器产品凭借着隔离性好、可移植性高、资源占用少、启动迅速等特性迅速风靡世界。下图展示了 2013 年以来 Docker 和 OpenStack 的搜索趋势。 容器技术在部署、交付等环节给人们带来了很多便捷，但在日志处理领域却带来了许多新的挑战，包括： 如果把日志保存在容器内部，它会随着容器的销毁而被删除。由于容器的生命周期相对虚拟机大大缩短，创建销毁属于常态，因此需要一种方式持久化的保存日志； 进入容器时代后，需要管理的目标对象远多于虚拟机或物理机，登录到目标容器排查问题会变得更加复杂且不经济； 容器的出现让微服务更容易落地，它在给我们的系统带来松耦合的同时引入了更多的组件。因此我们需要一种技术，它既能帮助我们全局性的了解系统运行情况，又能迅速定位问题现场、还原上下文。 日志处理流程 本文以 Docker 为例，依托阿里云日志服务团队在日志领域深耕多年积累下的丰富经验，介绍容器日志处理的一般方法和最佳实践，包括： 容器日志实时采集； 查询分析和可视化； 日志上下文分析； LiveTail - 云上 tail -f。 容器日志实时采集 容器日志分类

本章节主要涵盖了Alertmanager的工作机制与配置文件的比较详细的知识内容，由浅入深的给大家讲解。 警报一直是整个监控系统中的重要组成部分，Prometheus监控系统中，采集与警报是分离的。警报规则在 Prometheus 定义，警报规则触发以后，才会将信息转发到给独立的组件 Alertmanager ，经过 Alertmanager r对警报的信息处理后，最终通过接收器发送给指定用户，另外在 Alertmanager 中没有通知组的概念，只能自己对软件重新Coding，或者使用第三方插件来实现。 注意，这个通知组不是Alertmanager中的group概念，下面会详细讲 Group ，不要混淆哦。 前面已经介绍过一些关于 Alertmanager 知识点，本章开始针通过安装 Alertmanager 组件，对配置文件做详细说明，同时介绍 Prometheus 的警报规则的定义，最后使用Email、Wechat（Robot）、Dingtalk（webhook）来接受警报通知。 Alertmanager工作机制 在Prometheus生态架构里，警报是由独立的俩部分组成，可以通过上图很清晰的了解到 Prometheus 的警报工作机制。其中 Prometheus 与 Alertmanager 是分离的俩个组件。我们使用Prometheus Server端通过静态或者动态配置