grafana

Operator Operator 是由 CoreOS 公司开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。 Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的一些专业知识，比如创建一个数据库的 Operator ，则必须对创建的数据库的各种运维方式非常了解，创建 Operator 的关键是 CRD （自定义资源）的设计。 CRD 是对 Kubernetes API 的扩展，Kubernetes 中的每个资源都是一个 API 对象的集合，例如我们在YAML文件里定义的那些 spec 都是对 Kubernetes 中的资源对象的定义，所有的自定义资源可以跟 Kubernetes 中内建的资源一样使用 kubectl 操作。 Operator 是将运维人员对软件操作的知识给代码化，同时利用 Kubernetes 强大的抽象来管理大规模的软件应用。目前 CoreOS 官方提供了几种 Operator 的实现，其中就包括我们今天的主角： Prometheus Operator ， Operator 的核心实现就是基于 Kubernetes 的以下两个概念： 资源：对象的状态定义 控制器：观测、分析和行动，以调节资源的分布

新型完整的监控告警工具 主要特点： 多维数据模型，时间序列数据由度量名称和键/值对标识 一种灵活的查询语言来利用这种维度 不依赖分布式存储;单个服务器节点是自治的 时间序列收集通过HTTP上的拉模型进行 通过中间网关支持时间序列的推送 通过服务发现或静态配置发现目标 多种模式的绘图和仪表板的支持 机器IP：118.190.107.96 (阿里云) 1、安装 # 下载地址 https://prometheus.io/download/ #prometheus # centos下载linux压缩包即可。 # 上传到服务器 解压 tar xf prometheus-2.17.1.linux-amd64.tar.gz # mv文件夹名称 cd prometheus-2.17.1.linux-amd64 mv prometheus-2.17.1.linux-amd64 prometheus # 更改配置ip vim prometheus.yml # 将 localhost 改成自己的ip地址 如下图 static_configs: - targets: [ '118.190.217.164:9090' ] 2、启动 ./prometheus 3、web ui 登录访问: 118.190.217.164:9090 Prometheus自带有简单的UI prometheus.yml的配置

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

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

更多精彩内容欢迎订阅我的博客：https://fuckcloudnative.io/ Thanos [1] 和 VictoriaMetrics [2] 都是用来作为 Prometheus 长期存储的成熟方案，其中 VictoriaMetrics 也开源了其 集群版本 [3] ，功能更加强大。 这两种解决方案都提供了以下功能： 长期存储，可以保留任意时间的监控数据。 对多个 Prometheus 实例采集的数据进行全局聚合查询。 可水平扩展。 本文就来对比一下这两种方案的差异性和优缺点，主要从 写入 和 读取 这两个方面来比较，每一个方面的比较都包含以下几个角度： 配置和操作的复杂度 可靠性和可用性 数据一致性 性能 可扩展性 先来看一下这两种方案的架构。 1. 架构 Thanos Thanos [4] 包含以下几个核心组件： Sidecar [5] : 每个 Prometheus 实例都包含一个 Sidecar ，它与 Prometheus 实例运行在同一个 Pod 中。它有两个作用：1) 将本地超过 2 小时的监控数据上传到对象存储，如 Amazon S3 或 Google 云存储。2) 将本地监控数据（小于 2 小时）提供给 Thanos Query 查询。 Store [6] Gateway : 将对象存储的数据提供给 Thanos Query 查询。 Query [7] :

正文共729字 预计阅读时间：2分钟😂 相信大家看过 《听说，你的Loki还是单体?(上篇)》 之后对Loki的分布式架构有了一定的认识 ，那么本篇主要就是对上篇内容的实践。小白主要提供 docker-compose 和 helm 两种方式将部署Loki集群的Demo版本。 在正式部署之前，我们还是先来看下Loki整体架构如下图： 我们本次部署清单里面主要涉及到的组件如下： 组件 副本数 说明 Cassandra 1 Loki Index存储 Minio 1 Loki S3存储 Consul 1 Loki 组件状态和哈希环存储 Redis 1 Loki 缓存 Gateway 2 Loki 网关 Distributor 3 Loki 组件 Ingester 3 Loki 组件 Querier 3 Loki 组件 Query-Frontend 2 Loki 组件 Table-Manager 1 Loki 组件 下载部署代码 $ git clone https://github.com/CloudXiaobai/loki-cluster-deploy.git 声明：以下部署均适用于demo环境，大家切勿直接用于生产环境 对于生产环境，请务必先解决Cassandra和Consul服务的高可用 通过docker-compose部署 启动服务 $ cd loki-cluster-deploy

部署说明： 环境说明： 组件 版本 下载地址 Prometheus 2.6.1 https://prometheus.io/download/#prometheus go 1.11.4 https://golang.org/dl/ Grafana 5.4.2 https://dl.grafana.com/oss/release/grafana-5.4.2-1.x86_64.rpm 安装go 解压安装： [root@cs-linfan local]# tar -C /usr/local/ -xvf go1.11.4.linux-amd64.tar.gz 配置环境变量 [root@cs-linfan local]#vim /etc/profile export PATH=$PATH:/usr/local/go/bin [root@cs-linfan local]#source /etc/profile 验证 [root@cs-linfan local]# go version go version go1.11.4 linux/amd64 安装Prometheus 安装 [root@cs-linfan local]#tar -C /usr/local/ -xvf prometheus-2.6.1.linux-amd64.tar.gz [root@cs-linfan local]#ln

本文来源： http://blog.csdn.net/Linkthaha/article/details/100575651 最近，在对公司容器云的日志方案进行设计时，发现主流的 ELK 或者 EFK 比较重，再加上现阶段对于 ES 复杂的搜索功能很多都用不上，最终选择了 Grafana 开源的 Loki 日志系统，下面介绍下 Loki 的背景。 背景和动机 当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下： 我们的监控使用的是基于 Prometheus 体系进行改造的，Prometheus 中比较重要的是 Metric 和 Alert。 Metric 是来说明当前或者历史达到了某个值，Alert 设置 Metric 达到某个特定的基数触发了告警，但是这些信息明显是不够的。 我们都知道，Kubernetes 的基本单位是 Pod，Pod 把日志输出到 stdout 和 stderr，平时有什么问题我们通常在界面或者通过命令查看相关的日志。 举个例子： 当我们的某个 Pod 的内存变得很大，触发了我们的 Alert，这个时候管理员，去页面查询确认是哪个 Pod 有问题，然后要确认 Pod 内存变大的原因。 我们还需要去查询 Pod 的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了： 如果，这个时候应用突然挂了，这个时候我们就无法查到相关的日志了

原文链接： https://fuckcloudnative.io/posts/monitoring-calico-with-prometheus-operator/ Calico 中最核心的组件就是 Felix ，它负责设置路由表和 ACL 规则等，以便为该主机上的 endpoints 资源正常运行提供所需的网络连接。同时它还负责提供有关网络健康状况的数据（例如，报告配置其主机时发生的错误和问题），这些数据会被写入 etcd，以使其对网络中的其他组件和操作人员可见。 由此可见，对于我们的监控来说，监控 Calico 的核心便是监控 Felix ， Felix 就相当于 Calico 的大脑。本文将学习如何使用 Prometheus-Operator 来监控 Calico。 本文不会涉及到 Calico 和 Prometheus-Operator 的部署细节，如果不知道如何部署，请查阅官方文档和相关博客。 1. 配置 Calico 以启用指标 默认情况下 Felix 的指标是被禁用的，必须通过命令行管理工具 calicoctl 手动更改 Felix 配置才能开启，需要提前配置好命令行管理工具。 本文使用的 Calico 版本是 v3.15.0 ，其他版本类似。先下载管理工具： $ wget https://github.com/projectcalico/calicoctl

一、原因 因客户Red Hat 7.5服务器安装部署grafana无法添加prometheus数据源，以及无法修改初始密码，为确保环境访问安全，特别研究通过账号密码认证访问prometheus，百度了很多资料，但都缺这缺那，所以我这里记录下具体实现过程： 二、安装部署httpd 方法一：使用yum安装 yum -y install apr apr-util httpd 方法二：使用源码安装 yum -y install expat-devel gcc gcc-c++ autoreconf libtoolize automake 1、下载httpd安装包 wget http://mirrors.hust.edu.cn/apache/httpd/httpd-2.4.46.tar.gz 2、解压 tar zxvf httpd-2.4.46.tar.gz 3、下载新的apr、apr-util安装（安装过程会有各种奇葩错误，自行百度解决，这里不具体讲解） wget http://mirror.bit.edu.cn/apache/apr/apr-1.7.0.tar.gz wget http://mirror.bit.edu.cn/apache/apr/apr-util-1.6.1.tar.gz 4、安装apr、apr-util tar -zxvf apr-1.7.0.tar.gz tar