自定义监控指标开发(三):Grafana配置及使用
介绍Grafana 是一款采用 go 语言编写的开源应用，可以从Elasticsearch，Prometheus，Graphite，InfluxDB等各种数据源中获取数据，并通过精美的图形将其可视化。 除了Prometheus的AlertManager 可以发送报警，Grafana 同时也支持告警。Grafana 可以无缝定义告警在数据中的位置，可视化的定义阈值，并可以通过钉钉、email等平台获取告警通知。最重要的是可直观的定义告警规则，不断的评估并发送通知。 由于Grafana alert告警比较弱，大部分告警都是通过Prometheus Alertmanager进行告警. 安装见：https://github.com/behappy-project/behappy-docker-application/tree/master/grafana 图表配置 在时序图表配置场景下，我们需要核心关注配置的有: Metrics:...
自定义监控指标开发(二):Prometheus介绍及PromQL的使用
介绍Prometheus是一套成熟且流行的系统和服务监控系统，它几乎满足了监控的所有能力。 Grafana, 它和Prometheus相比更侧重的是图形化展示，有强大、灵活的仪表盘体系，我们会把基于Prometheus收集的数据作为数据源导入到Grafana。 监控模式目前，监控系统采集指标有两种方式，一种是『推』，另一种就是『拉』： 推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你从程序中将指标使用 TCP，UDP 等方式推送至相关监控应用，只是使用 TCP 的话，一旦监控应用挂掉或存在瓶颈，容易对应用本身产生影响，而使用 UDP 的话，虽然不用担心监控应用，但是容易丢数据。 拉的代表，主要代表就是 Prometheus，让我们不用担心监控应用本身的状态。而且可以利用 DNS-SRV 或者 Consul 等服务发现功能就可以自动添加监控。 如何监控Prometheus 监控应用的方式非常简单，只需要进程暴露了一个用于获取当前监控样本数据的 HTTP 访问地址。这样的一个程序称为Exporter，Exporter 的实例称为一个...
自定义监控指标开发(四):配合K8s收集服务指标信息
介绍 在Kubernetes中，Prometheus Operator可以通过两种方式自动发现监控目标：PodMonitor和ServiceMonitor。PodMonitor用于监控由单个Pod定义的服务，而ServiceMonitor用于监控Kubernetes Service中的所有Pod。 要使用PodMonitor和ServiceMonitor，需要在Kubernetes中定义它们，然后Prometheus Operator将从这些定义中自动发现和创建监控目标。 在Kubernetes中，Prometheus Operator可以通过两种方式自动发现监控目标：PodMonitor和ServiceMonitor。PodMonitor用于监控由单个Pod定义的服务，而ServiceMonitor用于监控Kubernetes Service中的所有Pod。 要使用PodMonitor和ServiceMonitor，需要在Kubernetes中定义它们，然后Prometheus...
自定义监控指标开发(一):基于Docker搭建Prometheus+Grafana
摘自：https://juejin.cn/post/7097166804044218405 安装运行Prometheus(docker版)Grafana是一个开源的功能丰富的数据可视化平台，通常用于时序数据的可视化。它内置了多种数据源的支持 下载镜像包123docker pull prom/node-exporterdocker pull prom/prometheusdocker pull grafana/grafana 启动node-exporter12345docker run -d -p 9100:9100 \ -v "/proc:/host/proc:ro" \ -v "/sys:/host/sys:ro" \ -v "/:/rootfs:ro" \ prom/node-exporter 访问url： http://127.0.0.1:9100/metrics 效果如下: 这些都是收集到的数据，有了它就可以做数据展示了。 启动prometheus新建目录...
利用fabric8结合git-hook动态配置k8s资源
背景 在多分支并行开发的集群下，新建分支以及删除分支都需要开发人员手动维护Istio/K8s的资源对象 目的 结合git hook -》 sync程序 -》 kubernetes API 流程，自动维护k8s以及istio资源对象，减少成本，提高开发效率 技术栈GitLab Api 使用GitLab Api，获取项目分支信息 123456 <!-- https://mvnrepository.com/artifact/org.gitlab/java-gitlab-api --><dependency> <groupId>org.gitlab</groupId> <artifactId>java-gitlab-api</artifactId> <version>${gitlab.version}</version></dependency> gitlab...
wsl配合docker desktop安装k8s
clone k8s-for-docker-desktop 项目1git clone https://github.com/AliyunContainerService/k8s-for-docker-desktop.git 从阿里云镜像服务下载 Kubernetes 所需要的镜像 如果项目未支持想要的镜像版本, 可以通过修改 images.properties 文件自行加载你自己需要的镜像 如果因为安全策略无法执行 PowerShell 脚本，请在 “以管理员身份运行” 的 PowerShell 中执行 Set-ExecutionPolicy RemoteSigned 命令。 在Windows上，使用 PowerShell 1.\load_images.ps1 开启 Kubernetes，并等待 Kubernetes 开始运行 如果在Kubernetes部署的过程中出现问题 可以在 C:\ProgramData\DockerDesktop下的service.txt 查看Docker日志 在...
k8sCrd开发学习-client_go连接k8s(minikube)
client go远程连接k8s(minikube)复制配置文件到本地 先将minikube拷贝到本地(或者只拷贝.kube\config需要的文件) 1cp -r /home/docker_user/.minikube /root/ 拷贝.kube文件夹 1cp -r /home/docker_user/.kube /root/ 添加ssh端口转发本地肯定是访问不了的，所以需要在本地试验环境添加远程主机的端口转发。 windows端口转发，打开windows的cmd，输入命令： 12345# 表示在本地启动18443端口，与远程主机root@192.168.56.101建议连接，端口转发到远程主机192.168.49.2:8443上去, 执行完窗口会hold住# 192.168.49.2是k8s节点ip, 使用`minikube node list`查看C:\Users\a94391> ssh -L 18443:192.168.49.2:8443 -N -f...
k8s Crd开发学习-安装k8s(minikube)
安装 docker使用官方安装脚本自动安装docker12curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyunsystemctl enable docker 配置镜像加速12345678mkdir -p /etc/dockertee /etc/docker/daemon.json <<-'EOF'{ "registry-mirrors": ["https://0vlzmqf0.mirror.aliyuncs.com"]}EOFsystemctl daemon-reloadsystemctl restart docker 安装 Minikube12curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64install minikube-linux-amd64...
prometheus推送告警记录
AlertManager 中的几个容易混淆的参数首先在 Prometheus 中有两个全局的参数 scrape_interval 和 evaluation_interval 。 scrape_interval 参数表示的是 Prometheus 从各种 metrics 接口抓取指标数据的时间间隔 evaluation_interval 参数表示的是 Prometheus 对报警规则进行评估计算的时间间隔。 group_by 为了避免连续发送类似的告警通知，可以将相关告警分到同一组中进行告警。分组机制可以将详细的告警信息合并成一个通知，在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知： 1group_by: ['alertname', 'job'] group_wait 当一个新的报警分组被创建后，需要等待至少 group_wait 时间来初始化告警。 这样实际上就缓冲了从 Prometheus 发送到 AlertManager...
分析Alertmanager发送告警消息的逻辑
摘自: https://blog.csdn.net/qq_35952638/article/details/108077895 本文使用 Prometheus v2.18.1 ，Alertmanager v0.20.0本文主要分析 Alertmanager 什么情况下会发送告警消息，避免对用户造成消息轰炸。 Alertmanager 的一般工作流程 Prometheus 每隔 interval 时长执行一次 alert rule 。如果执行结果包含 n 个时间序列，则认为存在 n 个警报，通过 HTTP 通信发送 alerting 状态的消息给 Alertmanager 。 Alertmanager 收到之后， 先根据 route 判断它属于哪个 group 、应该发送给哪个 receiver 。 再判断该 group 当前是否处于冷却阶段、是否被 Silence 静音、是否被 Inhibit 抑制。如果都没有，则立即发送告警消息给用户。 如果 Prometheus 再次执行 alert rule 时，发现执行结果为空，则认为警报已解决，立即产生 resolved...
公告