阿里云prometheus（阿里云盘福利码）

本文目录一览：

• 1、Prometheus采集抓取间隔时间15秒与1秒的区别 scrape_interval
• 2、2020-08-25
• 3、两大容器管理平台，Kubernetes与OpenShift有什么区别？

Prometheus采集抓取间隔时间15秒与1秒的区别 scrape_interval

使用wrk施压 1000 并发连接, 采集间隔1s实时数据图表很快体现出来了 1002 ，采集间隔15s的数据是 781 ，最low的是阿里云SLB的监控数据，1分钟后才展示出最大活跃连接数 792 。

时间在 03:30 数据是一致的

1.在服务器上也可以使用 netstat -apn|grep 'nginx: worker'|wc -l 查看nginx连接并发数；

2.如果nginx启用了 --with-http_stub_status_module 模块也可以使用 curl -s curl | grep connections 查看。

3.我上图nginx采集使用的是 nginx-module-vts

4.来张启用 --with-http_stub_status_module 模块数据采集的监控图表(采集间隔1s)

2020-08-25

Prometheus 实现邮件告警（Prometheus+Alertmanager+QQ邮箱或者网易163邮箱，目前测试过这两种邮箱都可以发送告警邮件）

Prometheus实现邮件告警原理如下：

Prometheus官方有一个附带的中间件：alertmanager，通过设置rules规则和路由转发可以实现邮件告警，前提是你需要有一个可以发送邮件的邮件服务端（可以自建或者使用互联网公司提供的免费邮箱）

告警原理图

Prometheus完整架构图

我之前得出的错误结论如下：

推荐直接在虚拟机操作系统上直接安装Prometheus和Alertmanager，不推荐其中任何一方在容器中运行，因为测试过在容器中运行Prometheus和alertmanager，结果出现如下错误情况

第一种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus却提示节点依然在线？有时候却能够正常显示节点掉线跌机，生成告警发送邮件

第二种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus提示节点掉线，告警生成，但是没有发送邮件，我手动恢复node-exporter后，告警解除，邮件能正常发送邮件提示告警已经解除。。。。

第三种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus提示节点掉线，告警生成，正常成功发送邮件，我手动恢复node-exporter后，告警解除，邮件没有发送出来。。。。

以上三种情况之前经常出现，当时第一步以为是自己设置的scrape_interval不合理导致的，结果调试几次，问题没有解决，第二步以为是自己的服务器时间没有做到精确同步，然后我去设置和阿里云的ntp服务器同步，结果问题依然没有解决，第三步，换个方向，把alertmanager迁移到虚拟机操作系统上安装运行，问题解决！

北京时间是GMT+8小时，有些同志的时间可能是UTC的，但是如果是在要求不太十分精确的情况下，UTC时间是刚刚好等于GMT时间

为了避免时区的混乱，prometheus所有的组件内部都强制使用Unix时间，对外展示使用GMT时间。

要改时区有两个办法

1 .修改源码，重新编译。

2. 使用 docker 运行 Prometheus，挂载本地时区文件

docker run --restart always -e TZ=Asia/Shanghai --hostname prometheus --name prometheus-server -d -p 9090:9090 -v /data/prometheus/server/data:/prometheus -v /data/prometheus/server/conf/prometheus.yml:/etc/prometheus/prometheus.yml -u root prom/prometheus:v2.5.0

正文开始

安装alertmanager

容器安装方式：

docker run -d --name alertmanager -p 9093:9093 -v /usr/local/Prometheus/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml prom/alertmanager:latest

先在宿主机/usr/local/Prometheus下创建一个文件夹alertmanager，然后在文件夹里创建alertmanager.yml配置文件，待会才能映射到alertmanager容器里的/etc/alertmanager目录下

global：全局配置

   resolve_timeout: 问题解决的超时时间

   smtp_from: 发送告警邮件的邮箱账号

   smtp_smarthost: 邮箱 SMTP 服务地址,这里是以QQ邮箱为例，也可以用网易163邮箱，这个和我之前设置zabbix邮件告警时的配置一样

   smtp_auth_username: 如果没有设置邮箱别名，那就是账户名

   smtp_auth_password:  邮箱的授权码，不是 账户密码，你可以在QQ邮箱或者网易163邮箱网页端设置，开启 POP3/SMTP 服务时会提示，和配置zabbix邮件告警的时候几乎一样

   smtp_require_tls: 是否使用 tls，根据环境不同，来选择开启和关闭。如果提示报错 email.loginAuth failed: 530 Must issue a STARTTLS command first，那么就需要设置为 true。着重说明一下，如果开启了 tls，提示报错 starttls failed: x509: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 来跳过 tls 验证。

templates： 告警模板目录，可以不编写模板，有默认模板

    Subject: '{{ template "email.default.subject" . }}'

    html: '{{ template "email.default.html" . }}'

route：报警的分发设置

    group_by：分组

    group_wait: 分组等待时间

    group_interval: 5m 每组时间间隔

    repeat_interval: 10m 重复间隔

    receiver: 接收方式，请注意！这里的名字要对应下面receivers中的任何一个名字，不然会报错，这里其实就是选择方式，有邮箱，企业微信，wehook，victorops等等

receivers：接受方式汇总，即告警方式汇总

例子：

receivers:

- name:'default-receiver' 

email_configs:

- to:'whiiip@163.com'    

  html: '{{ template "alert.html" . }}'    

  headers: { Subject: "[WARN] 报警邮件test"}

inhibit_rules:   抑制规则

当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。

包括源匹配和目标匹配

alertmanager官方是这样说的

Inhibition

Inhibition is a concept of suppressing notifications for certain alerts if certain other alerts are already firing.

Example:  An alert is firing that informs that an entire cluster is not reachable. Alertmanager can be configured to mute all other alerts concerning this cluster if that particular alert is firing. This prevents notifications for hundreds or thousands of firing alerts that are unrelated to the actual issue.

Inhibitions are configured through the Alertmanager's configuration file.

当存在与另一组匹配器匹配的警报（源）时，禁止规则会使与一组匹配器匹配的警报（目标）静音。目标警报和源警报的equal列表中的标签名称都必须具有相同的标签值。

在语义上，缺少标签和带有空值的标签是同一件事。因此，如果equal源警报和目标警报都缺少列出的所有标签名称，则将应用禁止规则。

为了防止警报禁止自身，与规则的目标和源端 都 匹配的警报不能被警报（包括其本身）为真来禁止。但是，我们建议选择目标匹配器和源匹配器，以使警报永远不会同时匹配双方。这很容易进行推理，并且不会触发此特殊情况。

接着是规则rules

不解释了，自己研究官方文档

alertmanager的非容器安装方式是

 wget

tar xf alertmanager-0.20.0.linux-amd64.tar.gz

mv alertmanager-0.20.0.linux-amd64 /usr/local/alertmanager

vim /usr/lib/systemd/system/alertmanager.service

[Unit]

Description=alertmanager

Documentation=

After=network.target

[Service]

Type=simple

User=root

ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml

Restart=on-failure

[Install]

WantedBy=multi-user.target

Alertmanager 安装目录下默认有 alertmanager.yml 配置文件，可以创建新的配置文件，在启动时指定即可。

其余方式和上面一样

接着是Prometheus，我之前的博客里有写了容器安装和非容器安装的方法，自己去翻阅

然后是在prometheus.yml里修改相关配置

首先去掉alertmanager的注释，改成IP加你设置的端口号，默认是9093

接着在rule_files: 下面写下规则文件的绝对路径，可以是具体文件名，也可以是*，也可以分几级文件，*默认是全部匹配

接着是被监控项的设置，这里设置完成可以在Prometheus网页里的targets里看得到

请注意，这里设置的参数名字要和rule规则中设置的参数名字一模一样，否则你的prometheus服务会无法启动，然后报错

如果不在特定的job下设置scrape_interval（优先级高于全局）,则默认采用gobal下的scrape_interval

最后模拟节点掉线，手动关闭node-exporter或者Cadvisor

docker stop node-exporter 或者容器ID

docker stop cadvisor 或者容器ID

或者把up{{job='prometheus'}} == 1 设置成1，反向设置，不用关掉服务，就可以看看告警成不成功

说明一下 Prometheus Alert 告警状态有三种状态：Inactive、Pending、Firing。

Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。

Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing 状态。

Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。

没有配置告警模板时的默认告警格式是这样的

节点恢复后邮件告知是这样的

写了模板后是这样的

还要重新映射模板文件夹路径到alertmanager容器里的相对路径，然后重启alertmanager，当然，如果目录下没有模板文件，则不显示

告警模板

在alertmanager.yml中修改相关设置

重启alertmanager

docker restart alertmanager

最终效果不是很好

两大容器管理平台，Kubernetes与OpenShift有什么区别？

容器化是开发和部署应用的热门趋势，因为它们是加速开发的有效方式。容器的使用量在过去几年呈指数增长。

但是，跨基础架构管理容器可能会变得十分复杂，所以容器管理平台对于任何企业来说都是必不可少的工具。Kubernetes和OpenShift是市场上最受欢迎的两个容器管理平台。而OpenShift是基于Kubernetes的，那么二者之间到底有哪些区别呢？

OpenShift是由红帽（Red Hat）开发的容器化软件解决方案。他们的主要产品是OpenShift容器平台，这是基于Kubernetes管理的平台即服务（PaaS）。它是用Go和AngularJS编写的，并且有Apache许可证。

OpenShift Origin是红帽基于开源的云平台，允许开发人员构建，测试和部署云应用。该系统在Kubernetes核心之上添加工具，以实现更快的应用开发，轻松部署和扩展。

该平台除了可扩展外，还支持Go，Node.js，Ruby，Python，PHP，Perl和Java，允许用户添加对其他语言的支持。关于可扩展性，该平台可以自动或手动扩展容器化应用。

OpenShift提供的一些功能包括：

在整个应用程序生命周期中的安全性 - 安全性检查内置于容器堆栈中。

平台上包含的内置监控功能是Prometheus，一种数据库和应用监控软件。你可以在Grafana仪表板上实时显示应用。

集中式策略管理 - 跨集群的单个控制台为用户提供了实施策略的集中位置。

兼容性-OpenShift是Certified Kubernetes计划的一部分，因此允许与Kubernetes容器工作负载兼容。

使用OpenShift的好处包括：

快速的应用开发 - 平台流传输和自动化容器管理过程，从而增强了DevOps过程。应用开发的这种加速意味着你可以更快地进入市场，从而提高竞争力。

没有供应商锁定提供与供应商无关的开源平台，这意味着用户可以根据需要将其容器流程迁移到新的操作系统，而无需重新进行容器化编排。

自助服务配置 - OpenShift允许用户集成他们最常使用的工具，例如，视频 游戏 开发人员在开发与多个操作系统兼容的 游戏 时可以使用此功能。

Kubernetes是一个开源容器即服务（CaaS）编排系统，用于自动化容器化应用的部署，扩展和管理，从而改进应用程序开发过程。Kubernetes的一些功能包括：

Kubernetes的好处包括：

由于OpenShift基于Kubernetes，因此它们有很多共同之处。但是，两个平台之间存在一些差异。让我们对OpenShift和Kubernetes功能进行比较：

基础

虽然两者都基于Linux，但每个产品都在不同的环境中运行：

Kubernetes在其可运行的操作系统方面更加灵活。但是，包管理器应该是RPM，这意味着选择合适的Linux发行版。因此最好在Fedora，Ubuntu或Debian上运行它。Kubernetes可以部署在任何主要的IaaS平台上，例如AWS，Azure，GCP、阿里云、IBM云平台等。

OpenShift可以安装在Red Hat Enterprise Linux（RHEL）和Red Hat Enterprise Linux Atomic Host（RHELAH）以及Fedora和CentOS上。OpenShift Dedicated允许在云中创建自己的集群，特别是基于AWS。

Rollout

这两种产品在Rollout方面都很复杂：

Kubernetes运行平台的多样性意味着有无数的解决方案可以在本地创建Kubernetes集群。大多数都基于Rancher Kubernetes Everywhere（RKE）或kops等安装程序。

OpenShift可避免在首次Rollout后需要额外的组件。因此，它配备了基于Ansible的专有安装程序，可以使用最少的配置参数安装OpenShift。

Web UI

与通过基于Web的用户界面管理集群的能力相比，OpenShift和Kubernetes之间存在很大差异。

Kubernetes的仪表板必须单独安装，需要通过kube代理访问，以将本地机器的端口转发到集群的管理服务器。此外，它没有登录页面，但你需要手动创建承载令牌以提供身份验证和授权。所有这些复杂性导致Web UI对于真正的日常管理工作而言不是很有价值。

OpenShift的Web控制台有一个登录页面，可以轻松访问，甚至可以让你通过表单创建和更改大多数资源。虽然你无法通过Web管理集群，但可以可视化服务器，项目和集群角色。

集成镜像注册表

关于集成图像注册表的两个系统之间的关键区别：

使用Kubernetes，可以设置自己的Docker注册表，但没有集成镜像注册表的概念。

OpenShift附带了一个集成的镜像注册表，可以与Docker Hub或Red Hat一起使用。它甚至还有一个注册表控制台，可以在其中搜索与集群中项目相关的镜像和镜像流的信息。

Jenkins

虽然Kubernetes中不存在该概念，但可以部署自己的自定义Jenkins镜像。生成的组件是上传到镜像存储库的docker镜像。

OpenShift使用Pipeline构建，这是一种源到镜像构建的形式，它引用包含Jenkins的镜像，而Jenkins又监控ImageStreamsTags。当需要更新时，它可以启动Jenkins构建。

网络

Kubernetes没有本机网络解决方案，但提供可供第三方网络插件使用的接口。

OpenShift有一个开箱即用的本机网络解决方案OpenvSwitch，它提供三种不同的插件。

两者都是开源软件平台，来满足容器编排和应用开发。它们使得以简单易管理的方式部署和管理容器化应用成为可能。OpenShift Web控制台使其非常有用，允许直接通过它执行80％以上的任务。

虽然两者都有类似的核心（毕竟OpenShift内置了Kubernetes），OpenShift通过其开箱即用的功能使安装更容易。安装Kubernetes通常需要交钥匙解决方案或托管Kubernetes集群。

您选择的系统将取决于您的系统要求以及开发过程的关键灵活性或良好的Web界面。