在IBM云上的Red Hat OpenShift中安装Prometheus（使用内置运算符）
达到的结果或者希望实现的目标
由于OpenShift默认集成了Prometheus，但由于收集到的指标没有持久化，所以在实际运营中使用起来会有些困难。因此，我们可以利用OpenShift内置的Operator Hub，在那里额外安装Prometheus进行尝试。
然而，IBM可能会说，如果仅仅是为了这个目的，可以使用IBM Cloud Monitoring with Sysdig而不是Prometheus。然而，Prometheus的PromQL具有灵活的表达能力，并且可以通过与各种Exporter的协作收集各种指标数据，这是非常有价值的。
另外，由于Prometheus Operator仍存在一些行为异常和信息不足的问题，请自行承担使用责任。
前提 – 目前所讲的是在某件事情发生之前或者成立之前存在的条件。
- 検証環境: Red Hat OpenShift on IBM Cloud 4.3
操作步骤
操作员的确认
您可以从Web控制台上进行确认。
运营者的订阅
我们将从这里开始使用CLI进行操作。我们会订阅操作员。
$ oc create -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: prometheus
spec:
channel: beta
installPlanApproval: Auto
name: prometheus
source: community-operators
sourceNamespace: openshift-marketplace
startingCSV: prometheusoperator.0.32.0
EOF
对RBAC进行设置
有一个名为prometheus-k8s的ServiceAccount已经创建，但奇怪的是它没有被分配任何ClusterRole。因此，需要手动设置ClusterRole和ClusterRoleBinding。
$ oc get sa prometheus-k8s
NAME SECRETS AGE
prometheus-k8s 2 3m29s
$ oc create -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: ${ClusterRole名}
rules:
- apiGroups:
- ""
resources:
- nodes
- nodes/proxy
- services
- endpoints
- pods
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- configmaps
verbs:
- get
- apiGroups:
- "extensions"
resources:
- ingresses/status
- ingresses
verbs:
- get
- list
- watch
- nonResourceURLs:
- "/metrics"
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: ${好きな名前}
subjects:
- kind: ServiceAccount
name: prometheus-k8s
namespace: ${サブスクライブしたネームスペース}
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: ${ClusterRole名}
EOF
创建Prometheus实例
创建Prometheus实例。这次我们将收集的指标永久保存在文件存储中。
$ oc create -f - <<EOF
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: server
labels:
prometheus: k8s
spec:
replicas: 1
serviceAccountName: prometheus-k8s
securityContext: {}
serviceMonitorSelector: {}
ruleSelector: {}
alerting:
alertmanagers: []
retention: 400d # メトリクスの保存期間
storage:
volumeClaimTemplate:
metadata:
labels:
billingType: hourly # またはmonthly
region: jp-tok # リージョン名
zone: tok02 # ゾーン名
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: ibmc-file-bronze-gid # ストレージクラス名
EOF
永久卷轴不支持预定义的PersistentVolumeClaim，它采用动态配置。
Prometheus以非root用户执行，请使用带有-gid的存储类。此外，由于bronze速度太慢，建议在实际环境中使用silver或gold。
当等待数分钟后，Pod将启动。
$ oc get pods | grep ^prometheus-server
prometheus-server-0 3/3 Running 1 114s
将File Storage转换为NFS v3（选项）
将文件存储的挂载设置为NFS v3。这是在IBM Cloud中的推荐方法。
$ _pv=$(oc get pv | grep prometheus-server-db-prometheus-server-0 | awk '{ print $1 }')
$ oc patch pv/${_pv} -p '{"spec":{"mountOptions":["nfsvers=3","hard","intr","lookupcache=none"]}}'
添加要抓取的目标
在这个阶段，我们还没有进行任何网页抓取，所以需要添加抓取目标。有两种方法可以实现这一点。
-
- CRDで定義
- AdditionalScrapeConfigsで定義
根据需求，CRD会定义PodMonitor、ServiceMonitor等资源作为OpenShift的资源。通过将AdditionalScrapeConfigs中的传统Prometheus配置文件进行Secret化并指定。
作为操作员，我本想使用CRD来完成这个任务，但由于信息有限，往往会变得试错性很强。而另一方面，Prometheus的配置文件在网络上有很多信息，经验丰富。这次我们将使用AdditionalScrapeConfigs。
为了简单起见，这是一个收集Prometheus自身指标的示例。
- job_name: prometheus
static_configs:
- targets:
- localhost:9090
我会将这个进行加密处理。
$ oc create secret generic prometheus-scrape-config --from-file additional-scrape-config.yaml --dry-run -o yaml | oc replace --force -f -
然后在Prometheus实例的additionalScrapeConfigs中指定密钥名和文件名。
$ oc edit prometheus/server
spec:
additionalScrapeConfigs: # 追加
name: prometheus-scrape-config # 追加
key: additional-scrape-config.yaml # 追加
等待片刻，爬取将开始。
如果要添加要爬取的目标，请重新创建Secret，prometheus-config-reloader会自动将其添加（最多等待数分钟）。
