最详细的基于 Prometheus 的 Azure 指标监控
本文的 Azure 监控主要描述 Azure 中国的监控方式,其他国家的 Azure 或者 Azure 全球可以参考,并且查询官方文档进行相应的配置更改。
采集组件采用 RobustPerception 的 azure_metrics_exporter ,这个 Exporter 也在持续维护中,维护者是 Prometheus 的作者 Brian Brazil ,也算是某种意义上的官方,比较靠谱。唯一的问题是已经有 1 年没有更新。GitHub 地址如下:
https://github.com/RobustPerception/azure_metrics_exporter
使用 Azure metrics exporter 来监控 Azure 需要准备如下步骤。
开通 Azure Monitor
Azure 中注册应用
配置 Azure metrics exporter
配置 Prometheus
Grafana 画图
开通 Azure Monitor
要监控 Azure 的云服务资源使用情况需要借助自身的云服务 Azure Monitor ,Azure Monitor 是 Azure 中的一项完整的监视服务,提供了一整套用于监视 Azure 资源以及其他云和本地资源的功能。所以为了监控上边的运行的服务资源,我们需要打开 Azure Monitor 服务。详细的开通步骤可以参考官网,这里就不过多的描述了。
Azure 中注册应用
Azure Monitor 打开以后,我们可以在 Azure Monitor 中看到各个资源的监控指标,但是每次都只能在控制台上查看,我们需要把监控数据保存到我们的 Prometheus 中,在统一的监控系统里查看。
我们需要在 Azure 门户中注册一个应用,以便 Microsoft 标识平台可为该应用程序及其用户提供身份验证和授权服务。
注册应用程序会在应用与 Microsoft 标识平台之间建立信任关系。 信任是单向的:应用信任 Microsoft 标识平台,但标识平台并不信任应用。
Azure 里进行注册一个监控可以的应用主要是 2 部分,应用注册和授权。
应用注册
登陆 Azure 门户,进入控制台,如果可以看到多个账号,那么选择要注册应用的账号。
接下来在控制台页面寻找 Azure 活动目录(Azure Active Directory),打开进入。
在右侧管理栏下有一个应用注册(App registrations)的菜单,点击打开。
在页面的上方有一个注册新应用(New application registration)的按钮,点击按钮进行应用创建。
创建过程中需要输入如下内容:
名称(Name):应用的用户会看到这个名字,后期可以修改。
支持的账户类型(Supported account types):支持两种账户类型,分别是当前账户和全局账号,选择当前应用只能在这个账户中看到,选择全局账号任意账号都能看到这个应用。【PS:官方文档不这么说,但是是这个意思】
重定向 URI(Redirect URI):这个选项是可选的,我们这里不填,不填不会影响后续的使用。
填写好以后点击注册(Register)即可。
注册完成后,Azure 控制台页面会显示应用注册的 总览
页面。 在这个页面可以看到应用程序 ID (Application ID / client ID),也被称为客户端 ID,它可唯一地标识 Microsoft 标识平台中的应用程序。
另外这个页面还可以看到 Directory ID 或者 tenant ID ,这两个 ID 先记下来,后边会用到,忘记了也可以到这个页面来查看。
应用创建好以后,我们需要为这个应用创建一个密码,或者叫凭证。
点击应用页面右侧的 凭证和秘钥(Certificates & secrets),这里这样创建秘钥(证书)方式的,也可以创建密码方式的,我们这里选择创建密码,点击 New client secret
,填写这个秘钥的描述,然后选择过期时间,过期时间可以是 1 年、2 年或者永不过期,然后点击 添加 (add) 就好。永不过期并不是真的永远不会过期,而且是过期时间被设置在了大约 300 年以后,我这里看到的是 2299.12.31 。
成功以后会看到这个描述的后边有几个值,分别是 Expires 、Value 、ID ,将其中的 Value 记录下来,切记切记,一定要记录好了。这个 Value 就是我们创建的密码,这个 Value 的显示时间比较短,几分钟的样子,如果没有记录下来,以后就看不到了,只能删了重新创建一个密码。
这样我们就收集到了后边要配置需要的 4 个参数中的 3 个。
client_id
client_secret
tenant_id
接下来就需要授权了。
授权
上边创建好应用以后,我们获得了需要的 ID,但是这个应用现在是没有权限的,所以我们需要对这个应用进行授权,步骤如下:
首先登陆订阅服务的控制台,在订阅页面的左侧,有一个访问控制(Access control (IAM)),点击这个菜单。
在打开的页面查找 角色管理 (Role assignment),点击新建,在新建里选择添加角色 (Add role assignment)。
在添加角色页面进行授权,在这个小页面里,Role 一栏选 “Monitoring Reader”,在搜索栏里搜索找到上边创建的应用,并且选中。其他项保持默认即可。
点击保存,授权就完成了。
记录下这个订阅的 subscription_id ,我们需要的配置参数就收集全了。
配置 Azure metrics exporter
官方没有提供编译好的二进制执行文件,可以自行编译,或者从 docker images 里拷贝一个出来。
下载 docker images , images ID 是 71b159cb4cb3
准备好镜像文件以后就可以准备配置文件了,配置文件采用 Yaml 格式进行描述,下面是一个缺省的配置文件。
azure_metrics_exporter 缺省的配置文件为
官方对配置文件的描述如下:
其中配置的 active_directory_authority_url
和 resource_manager_url
缺省配置的是 Azure 全球的地址,使用其他国家区域的建议通过 Azure Environments 查找对应的环境来进行配置,这样可能会快一些,中国区建议配置 AzureChinaCloud
里的 URL。
subscription_id、client_id、client_secret、tenant_id 这 4 个参数在上边已经收集好了,填入即可。
接着我们选择 targets 、resource_groups、resource_tags 任意一种进行配置来采集需要的资源指标数据。
配置 Prometheus
Azure metric exporter 配置好以后是可以通过 curl
命令来查看采集到的数据的。接下来,我们需要配置 Prometheus ,让监控数据存储起来,方便查询和告警。
在 Prometheus 中添加如下内容,添加好以后重新加载配置文件或者重启 Prometheus 服务使得配置生效。
配置中配置了 Prometheus 每隔 60 秒会从 Exporter 获取一次数据存储到 TSDB,超时时间为 60 秒。Azure API 对于监控有一个拉取数据频率的限制,默认是每小时 12000 次请求,超过这个限制以后会被限制,在配置的时候需要计算所有的请求是否会超出限制。
打开 Prometheus 的 Graph 页面,输入要采集的 Metric ,一切正常的话,是可以看到要采集的指标的。
Grafana 画图
在 Prometheus 中配置好采集以后,虽然在 Prometheus Graph 页面可以看到采集的指标,但是并不能长久存储,我们还是在 Grafana 中进行画图。
Grafana 搭建和 Prometheus 数据源的配置就不在这里讲解了,我们讲接下来的画图部分。
对于画图,我们需要首先把要采集的指标列到一个表里,并且把各个指标的数据类型也备注上,对于 Azure 的监控,我们使用下面的表格来进行梳理。
梳理好以后选择合适的 Panel 类型将数据画出来。
如果觉得自己画图比较麻烦,也可以到 Grafana Dashboards 上去搜索别人画好的 Dashboard ,但是 Azure 相关的 Dashboards 比较少,基于 Prometheus 的更少,大概率的情况下还是需要自己画的。
遇到的问题
1、只能监控到 account 指标,无法监控到 blob 、queue 等指标。
当前版本无法监控所有指标,因为 apiversion 版本的限制,
exporter 在获取 aipversion 的时候获取的是 2018-02-01
在 https://github.com/RobustPerception/azure_metrics_exporter/blob/HEAD/azure.go 的 401 ~ 424 行是用来返回指定的资源组和资源的,
在这一段,指定了 apiVersion 为 2018-02-01
azure 的最新 apiversion 版本为 2019-06-01 ,
在 2018-02-01 版本上针对的 Storage 的 Resource Type 只有 Storage Accounts,
在 2019-06-01 版本上针对的 Storage 的 Resource Type 有 Storage Accounts 、Blob Services 、File Services 、Queue Services、Table Services 等接口。
所以无法监控到 Blob 、File、Queue、Table 等数据。
2、无法监控到部分负载均衡的指标
负载均衡有两种 SKU ,分别是标准版和基础版,两者在功能、规模、售价方面有区别,对于监控来说,我们使用 Azure Metric Exporter 主要是获取指标数据。标准版提供基于 Azure Monitor 的监控指标,基础版只提供基于 Azure Log 的日志。所以无法获取基础版的监控指标。另外文档里提到 SKU 是不可变的,无法更改现有资源的 SKU。所以只有迁移才能变更 SKU,如果需要升级可以参考升级文档。
SKU 对比文档:https://docs.microsoft.com/zh-cn/azure/load-balancer/skus
版权声明: 本文为 InfoQ 作者【耳东】的原创文章。
原文链接:【http://xie.infoq.cn/article/a2aa07136fa63d18673ed538c】。文章转载请联系作者。
评论 (1 条评论)