对于「Google云管理的Prometheus服务」
首先
以下是关于GCP提供的“Google Cloud Prometheus托管服务”的简要总结。
使用Prometheus的挑战
普罗米修斯的架构和基本功能
请参考：https://prometheus.io/docs/introduction/overview/
以下是一个简化的流程图，在此基础上收集指标并在Grafana中进行可视化，以解决目前稍显复杂的情况。
常见的Prometheus运维问题
-
- Global View
-
- 1個あたりのPrometheusのスクレプの性能限界等により、複数のPrometheusを運用することになったので、複数のPrometheusを横断してクエリを実行したい
-
- Long Term
- Prometheusのメトリクスを1ヶ月や1年等の長期で保管したいが、1個あたりのPrometheusでは性能限界が来ていて難しいので解決したい
为了解决这些问题，我们经常使用Prometheus的远程写入功能将数据写入第三方产品，并在那里使用Grafana进行可视化处理。
运营第三方产品很困难
如果使用第三方产品来解决问题，那么运营这个解决方案本身也是一个问题。以下是Cortex的架构，从中可以看出它非常复杂。尽管产品拥有能够进行水平扩展的配置，但根据累积的数据量来进行扩展，以及每天的运营都需要相应的成本。
参考：https://cortexmetrics.io/docs/architecture/
参考链接：https://cortexmetrics.io/docs/architecture/
有關Google Cloud托管服務的Prometheus
建筑设计
根据官方文档，架构被描述如下。
参考来源：https://cloud.google.com/stackdriver/docs/managed-prometheus
根据提供的功能来看，Monarch增加了与Prometheus度量指标进行累积并使用PromQL进行通信的API。
在许多第三方产品以与Prometheus兼容的方式创建新产品的同时，Monarch已经具备了与Prometheus兼容性的运营经验，这是其特点所在。
“Monarch”指的是
Monarch 是在Google全球分布的内存时序数据库系统。
参考：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/d84ab6c93881af998de877d0070a706de7bec6d8.pdf
请参考此链接：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/d84ab6c93881af998de877d0070a706de7bec6d8.pdf。
Monarch 是在Google上运行的全球分布式内存时序数据库。
用法 fǎ)
这里的内容和官方网站上的“Get started with managed collection”一样，但只有翻译成日语这个附加价值有点不足，所以我还加了一些在确认时的发现。
基于Prometheus的收集器的设置
- CRDのデプロイ
运算符将在使用之前预先部署CRD。
$ kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.1.1/examples/setup.yaml
customresourcedefinition.apiextensions.k8s.io/podmonitorings.monitoring.googleapis.com created
customresourcedefinition.apiextensions.k8s.io/rules.monitoring.googleapis.com created
customresourcedefinition.apiextensions.k8s.io/clusterrules.monitoring.googleapis.com created
customresourcedefinition.apiextensions.k8s.io/operatorconfigs.monitoring.googleapis.com created
- Operatorのデプロイ
将公式图中基于Prometheus的收集器部署。
$ kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.1.1/examples/operator.yaml
namespace/gmp-system created
namespace/gmp-public created
priorityclass.scheduling.k8s.io/gmp-critical created
serviceaccount/operator created
serviceaccount/collector created
clusterrole.rbac.authorization.k8s.io/gmp-system:collector created
clusterrole.rbac.authorization.k8s.io/gmp-system:operator created
clusterrole.rbac.authorization.k8s.io/gmp-system:csr-approver created
clusterrolebinding.rbac.authorization.k8s.io/gmp-system:operator created
clusterrolebinding.rbac.authorization.k8s.io/gmp-system:operator-csr created
clusterrolebinding.rbac.authorization.k8s.io/gmp-system:collector created
deployment.apps/gmp-operator created
service/gmp-operator created
- デプロイ後のpodの確認
$ kubectl get -n gmp-system deploy,po
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/gmp-operator 1/1 1 1 12h
deployment.apps/rule-evaluator 1/1 1 1 12h
NAME READY STATUS RESTARTS AGE
pod/collector-6k9v5 2/2 Running 1 (12h ago) 12h
pod/collector-89phz 2/2 Running 1 (12h ago) 12h
pod/collector-h45q2 2/2 Running 1 (12h ago) 12h
pod/gmp-operator-5c7f6f5dcb-ndgbj 1/1 Running 0 12h
pod/rule-evaluator-7dd659b4fd-gkq5x 2/2 Running 1 (12h ago) 12h
我们可以看到存在三种类型的组件：collector、gmp-operator和rule-evaluator。
由于没有与collector相对应的Deployment资源，因此看起来这个组件是由gmp-operator来管理的。
collectorの確認
$ kubectl get -n gmp-system po collector-6k9v5 -o yaml
apiVersion: v1
kind: Pod
:
containers:
- args:
- --config.file=/prometheus/config_out/config.yaml
- --storage.tsdb.path=/prometheus/data
- --storage.tsdb.no-lockfile
+ - --storage.tsdb.retention.time=30m
- --storage.tsdb.wal-compression
- --storage.tsdb.min-block-duration=10m
- --storage.tsdb.max-block-duration=10m
- --web.listen-address=:19090
- --web.enable-lifecycle
- --web.route-prefix=/
+ - --export.label.project-id=<project-id>
+ - --export.label.cluster=<cluster名>
env:
- name: GOGC
value: "25"
+ image: gke.gcr.io/prometheus-engine/prometheus:v2.28.1-gmp.1-gke.1
:
- args:
- --config-file=/prometheus/config/config.yaml
- --config-file-output=/prometheus/config_out/config.yaml
+ - --reload-url=http://localhost:19090/-/reload
- --listen-address=:19091
:
+ image: gke.gcr.io/prometheus-engine/config-reloader:v0.1.1-gke.0
:
可能是基于 Prometheus（版本号为 v2.28.1-gmp.1-gke.1）构建的系统，该系统收集指标数据并将其发送到 Cloud Monitoring Ingest API 中。与 Prometheus 相关的产品通常以 prometheus/busybox 为基础镜像，但我认为这个系统经过了一些修改，例如更换为 Distroless，通过 Google 的环境进行构建等。
根据图像名称和参数的值来看，prometheus:v2.28.1-gmp.1-gke.1似乎是使用remote write功能，并且该组件似乎会将Cloud Monitoring Ingest API通过remote write接收的数据写入Monarch。但是具体细节我不清楚。
需要一个从多个GKE集群收集指标的标识来识别集群，但根据args中的–export.label，可以看到其中包含和<cluster名字>，因此在这个时机给指标附加了标签。Cloud Monitoring Ingest API的端点是按照项目ID单位存在的，所以在这个时机给指标添加了能够识别集群的信息。
配置重载器:v0.1.1-gke.0定期地调用Prometheus的重载端点。有了这个功能，我们可以通过在ConfigMap中创建配置文件并将其挂载到Pod中，使配置反映到prometheus:v2.28.1-gmp.1-gke.1上。
由于保留期设置为30m，我认为它只是用于通过Cloud Monitoring Ingest API进行远程写入的Prometheus。用于短期抓取的Prometheus是一种常见的方式，但是我觉得Prometheus v2.32.0中新增的Agent Mode似乎适用于这种用途，因此可能会考虑在v2.32.0及以上版本中进行兼容。
gmp-operatorの確認
$ kubectl get po -n gmp-system gmp-operator-5c7f6f5dcb-ndgbj -o yaml
apiVersion: v1
kind: Pod
:
spec:
containers:
- args:
- --ca-selfsign=false
- --public-namespace=gmp-public
- --priority-class=gmp-critical
+ - --image-collector=gke.gcr.io/prometheus-engine/prometheus:v2.28.1-gmp.1-gke.1
+ - --image-config-reloader=gke.gcr.io/prometheus-engine/config-reloader:v0.1.1-gke.0
+ - --image-rule-evaluator=gke.gcr.io/prometheus-engine/rule-evaluator:v0.1.1-gke.0
+ image: gke.gcr.io/prometheus-engine/operator:v0.1.1-gke.0
:
在这里，使用gmp-operator管理的容器映像似乎是由args指定的。
因此，在将来进行更新时，我认为需要更改operator:v0.1.1-gke.0标签以更新gmp-operator，并通过更改args中指定的–image-xxx标签来更新映像。
rule-evaluatorの確認
$ kubectl get -n gmp-system po rule-evaluator-7dd659b4fd-gkq5x -o yaml
apiVersion: v1
kind: Pod
:
- args:
- --config.file=/prometheus/config_out/config.yaml
- --web.listen-address=:19092
+ - --export.label.project-id=<project-id>
+ - --export.label.cluster=<cluster名>
+ image: gke.gcr.io/prometheus-engine/rule-evaluator:v0.1.1-gke.0
:
- args:
- --config-file=/prometheus/config/config.yaml
- --config-file-output=/prometheus/config_out/config.yaml
- --watched-dir=/etc/rules
- --watched-dir=/etc/secrets
+ - --reload-url=http://localhost:19092/-/reload
- --listen-address=:19093
+ image: gke.gcr.io/prometheus-engine/config-reloader:v0.1.1-gke.0
我认为”collector”与之非常相似。正如组件名称所示，它是一个专门评估规则的组件。通过使用它，我们可以向AlertManager发送通知。
为了与AlertManager进行集成，您需要在集群内部部署AlertManager，并添加与AlertManager连接的Service的信息到以下资源中。
$ kubectl -n gmp-public edit operatorconfig config
apiVersion: monitoring.googleapis.com/v1alpha1
kind: OperatorConfig
metadata:
namespace: gmp-public
name: config
rules:
alerting:
alertmanagers:
+ - name: SERVICE_NAME
+ namespace: SERVICE_NAMESPACE
+ port: PORT_NAME
由于每个集群内部设置是独立完成的，因此使用此功能来集中管理多个集群的警报设置似乎是困难的。
直接看CRD的样子，好像没有这样的设置。
% kubectl get crd operatorconfigs.monitoring.googleapis.com -o yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
:
rules:
description: Rules specifies how the operator configures and deployes
rule-evaluator.
properties:
alerting:
description: Alerting contains how the rule-evaluator configures alerting.
properties:
alertmanagers:
description: Alertmanagers contains endpoint configuration for
designated Alertmanagers.
items:
description: AlertmanagerEndpoints defines a selection of a
single Endpoints object containing alertmanager IPs to fire
alerts against.
properties:
:
+ name:
description: Name of Endpoints object in Namespace.
type: string
+ namespace:
description: Namespace of Endpoints object.
type: string
pathPrefix:
description: Prefix for the HTTP path alerts are pushed
to.
type: string
+ port:
anyOf:
- type: integer
- type: string
description: Port the Alertmanager API is exposed on.
x-kubernetes-int-or-string: true
+ scheme:
description: Scheme to use when firing alerts.
type: string
+ timeout:
description: Timeout is a per-target Alertmanager timeout
when pushing alerts.
type: string
tls:
如果您希望在跨多个集群的情况下集中管理警报设置，我认为可以使用Grafana的8.3.0版本中默认启用的统一警报功能。
我认为，Google Cloud Managed Service for Prometheus将每个集群的汇总数据保存在其一侧，因此可以在那里执行PromQL，并且可以在Grafana中集中管理警报设置。这意味着不再需要在每个集群上进行Slack通知设置，这将带来一些优势。
根据Grafana的8.2.0版本，似乎Grafana HA已经支持统一警报功能。因此，我认为在以前将警报功能委托给Grafana时所担心的可用性问题也得到了改善。
由于统一警报的设置在此处，请对带有ha_前缀的设置进行相应调整，可提高可用性。
部署示例应用程序并收集度量指标
- namespaceの作成
$ kubectl create ns gmp-test
namespace/gmp-test created
- サンプルのアプリケーションのデプロイ
$ kubectl -n gmp-test apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.1.1/examples/example-app.yaml
deployment.apps/prom-example created
- サンプルアプリのスクレイプ用のmonitoring.googleapis.com/v1alpha1のデプロイ
$ kubectl -n gmp-test apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.1.1/examples/pod-monitoring.yaml
podmonitoring.monitoring.googleapis.com/prom-example created
以下是样本的monitoring.googleapis.com/v1alpha1。
apiVersion: monitoring.googleapis.com/v1alpha1
kind: PodMonitoring
metadata:
name: prom-example
spec:
selector:
matchLabels:
app: prom-example
endpoints:
- port: metrics
interval: 30s
请参考以下链接获取有关Managed Prometheus设置的相关信息：https://cloud.google.com/stackdriver/docs/managed-prometheus/setup-managed
在这种情况下，Scrape Target是通过标签(label)和端口(port)以及监控间隔(interval)来指定的。看到这里，你可能会对路径(path)的处理方式产生疑问，但是通过查看CRD的内容，你就能理解了。
$ kubectl get crd podmonitorings.monitoring.googleapis.com -o yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
:
spec:
description: Specification of desired Pod selection for target discovery
by Prometheus.
properties:
endpoints:
items:
description: ScrapeEndpoint specifies a Prometheus metrics endpoint
to scrape.
properties:
+ interval:
description: Interval at which to scrape metrics. Must be a
valid Prometheus duration.
type: string
+ path:
description: HTTP path to scrape metrics from. Defaults to "/metrics".
type: string
+ port:
anyOf:
- type: integer
- type: string
description: Name or number of the port to scrape.
x-kubernetes-int-or-string: true
+ timeout:
description: Timeout for metrics scrapes. Must be a valid Prometheus
duration. Must not be larger then the scrape interval.
type: string
type: object
type: array
:
根据以上内容，我们可以知道以下四个设置的功能。
-
- interval
-
- path
-
- port
- timeout
根据描述，说明可以指定路径并且如果未指定，则默认为/metrics。从这里还可以看出可以指定超时值。
使用这个功能来开发应用程序时，可以将输出指标的路径和端口进行共享，并在为k8s确定指标抓取专用标签时始终附加该标签，这样应用程序开发人员就可以在不太意识到的情况下构建收集指标的环境。如果需要更改间隔等内容，最初的做法可能是将共享的标签排除，并单独进行设置，这样会更方便。
由于Google Cloud Managed Service for Prometheus仍处于预览版阶段，因此相关的文档还比较少。但是，您可以直接查看CRD(自定义资源定义)，并阅读其中的描述来了解其功能。通过这样做，您大致可以了解它具有哪些功能，以及在哪些配置下如何运行。
因为仍处于预览版本，所以尽管在CRD中有，但操作者一侧可能尚未实施的部分也可能存在。
我在GKE上增加的CRD已经在下面列出来了，如果文档中没有这些内容，你可以直接阅读这些内容。
$ kubectl get crd
NAME CREATED AT
backendconfigs.cloud.google.com 2021-12-16T14:01:37Z
capacityrequests.internal.autoscaling.gke.io 2021-12-16T14:01:28Z
+ clusterrules.monitoring.googleapis.com 2021-12-16T14:09:50Z
frontendconfigs.networking.gke.io 2021-12-16T14:01:37Z
managedcertificates.networking.gke.io 2021-12-16T14:01:30Z
+ operatorconfigs.monitoring.googleapis.com 2021-12-16T14:09:50Z
+ podmonitorings.monitoring.googleapis.com 2021-12-16T14:09:49Z
+ rules.monitoring.googleapis.com 2021-12-16T14:09:50Z
serviceattachments.networking.gke.io 2021-12-16T14:01:38Z
servicenetworkendpointgroups.networking.gke.io 2021-12-16T14:01:38Z
storagestates.migration.k8s.io 2021-12-16T14:01:33Z
storageversionmigrations.migration.k8s.io 2021-12-16T14:01:33Z
updateinfos.nodemanagement.gke.io 2021-12-16T14:01:34Z
volumesnapshotclasses.snapshot.storage.k8s.io 2021-12-16T14:01:31Z
volumesnapshotcontents.snapshot.storage.k8s.io 2021-12-16T14:01:32Z
volumesnapshots.snapshot.storage.k8s.io 2021-12-16T14:01:32Z
- スクレイプの設定が反映されていることの確認
经过一番确认，我发现名为”collector”的Configmap中管理着collector组件的配置。
$ kubectl get cm -n gmp-system
NAME DATA AGE
collector 1 14h
kube-root-ca.crt 1 14h
rule-evaluator 1 14h
rules-generated 1 14h
如果不存在podmonitorings.monitoring.googleapis.com，则config.yaml的内容将为空。
如果podmonitorings.monitoring.googleapis.com不存在，则config.yaml将为空。
当podmonitorings.monitoring.googleapis.com不存在时，config.yaml的内容会为空。
$ kubectl get cm -n gmp-system collector -oyaml
apiVersion: v1
data:
config.yaml: |
global: {}
kind: ConfigMap
刚才的样本设定后，确认如下。
$ kubectl get cm -n gmp-system collector -oyaml
apiVersion: v1
data:
config.yaml: |
global: {}
+ scrape_configs:
+ - job_name: PodMonitoring/gmp-test/prom-example/metrics
+ honor_timestamps: false
+ scrape_interval: 30s
+ scrape_timeout: 30s
+ metrics_path: /metrics
+ follow_redirects: false
+ relabel_configs:
+ - source_labels: [__meta_kubernetes_namespace]
+ regex: gmp-test
+ action: keep
+ - source_labels: [__meta_kubernetes_pod_label_app]
+ regex: prom-example
+ action: keep
+ - source_labels: [__meta_kubernetes_namespace]
+ target_label: namespace
+ action: replace
+ - target_label: job
+ replacement: prom-example
+ action: replace
+ - source_labels: [__meta_kubernetes_pod_container_port_name]
+ regex: metrics
+ action: keep
+ - source_labels: [__meta_kubernetes_pod_name, __meta_kubernetes_pod_container_port_name]
+ regex: (.+);(.+)
+ target_label: instance
+ replacement: $1:$2
+ action: replace
+ kubernetes_sd_configs:
+ - role: pod
+ follow_redirects: true
+ selectors:
+ - role: pod
+ field: spec.nodeName=$(NODE_NAME)
从这件事情可以看出，Scraper的设置似乎是按照以下方式进行反映的。
-
- 当gmp-operator检测到新的podmonitorings.monitoring.googleapis.com时，将修改Configmap的设置。
被挂载在collector的pod上的Configmap的内容会被kubelet反映。
当config-reloader调用重新加载的端点时，collector会反映出新的脚本配置。
我认为基本上与Prometheus Operator的ServiceMonitor的思想相同。
执行PromQL
- GCP上から操作する
在监控菜单中有一个名为“Managed Prometheus”的选项，您可以从那里进行操作。
我没有积累大量指标并执行复杂的查询，但是感觉一般使用应该没有问题。
由于Prometheus HTTP API以API的形式公开，因此似乎可以按以下方式执行。
$ curl https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/query \
-d "query=up" \
-H "Authorization: Bearer $(gcloud auth print-access-token)"
- Prometheus UIを用いて操作する
由于GCP的Prometheus HTTP API需要进行身份验证，因此我们为Google Cloud Managed Service for Prometheus提供了连接的Prometheus用户界面。
用以下方式将其部署到自己的集群中。
curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.1.1/examples/frontend.yaml |
sed 's/\$PROJECT_ID/PROJECT_ID/' |
kubectl apply -n gmp-test -f -
- 接続用にport-forwardを実施
$ kubectl -n gmp-test port-forward svc/frontend 9090
- ブラウザで確認
您可以访问Google Cloud Managed Service for Prometheus提供的 WebUI，并执行以前的 PromQL。
因此，可以在这里执行PromQL，就像Prometheus一样，因此可以直接迁移Grafana和其他调用PromQL的生态系统。
- Prometheus UIのPodを確認する
kubectl -n gmp-test get po frontend-7cffb58894-tgdmq -o yaml
apiVersion: v1
kind: Pod
:
spec:
containers:
- args:
- --web.listen-address=:9090
+ - --query.project-id=<project-id>
image: gke.gcr.io/prometheus-engine/frontend:v0.1.1-gke.0
:
通過查看上述内容，可以理解前端不是以集群为单位，而是连接到项目ID，因此可以查看其他集群。因此，可以在每个集群中安装基于Prometheus的收集器，并将前端（Prometheus UI）和Grafana管理在另一个集群中，这是一种可能的方法。
运用的形象
我认为只有功能介绍可能让很多人无法理解运营的形象，所以我根据”Google Cloud Managed Service for Prometheus”的功能来制作了一个运营示例。
上述构造设计的要点如下。
-
- 固定应用程序开发时的指标输出方法
-
- 确定应用程序开发时的指标输出的端口和路径（例如8080，/metrics）
-
- 确定在收集指标的应用程序中要附加的标签（例如metris-scrape: true）
-
- 事先部署monitoring.googleapis.com来对指定标签、端口和路径进行指标抓取
通过这样做，可以在无需特别意识的情况下为应用程序开发人员提供收集指标的环境。如果使用node-exporter或kube-state-metrics等开源软件，或者需要单独设置间隔和超时的应用程序，需要单独准备monitoring.googleapis.com。
使用Grafana的统一告警来统一管理告警
如果使用AlertManager，需要为每个集群准备冗余配置的AlertManager，以降低集群的创建和运维成本，为此需要准备运维集群并在其中进行告警管理。
在运维集群中准备具有Prometheus HTTP API和HA配置的Grafana，并使用统一告警来管理告警。
也可以考虑冗余Prometheus HTTP API，将用于告警和用户创建仪表板的Grafana区分开来。
通过将必要的集群功能移到另一个集群中，以降低应用程序部署集群所需的组件数量，从而降低运维成本。将告警目标Slack的凭据信息等从应用程序用的集群中移除，并移到运维集群中，这也是一个优点。
更新方法
如果要更新各组件，则需要更新gmp-operator的args的–image-XXXX指定的镜像。
如果要更新gmp-operator，则需更新gmp-operator。如果有与CRD更新相关的指示，则同时进行更新。
:
spec:
containers:
- args:
- --ca-selfsign=false
- --public-namespace=gmp-public
- --priority-class=gmp-critical
+ - --image-collector=gke.gcr.io/prometheus-engine/prometheus:v2.28.1-gmp.1-gke.1
+ - --image-config-reloader=gke.gcr.io/prometheus-engine/config-reloader:v0.1.1-gke.0
+ - --image-rule-evaluator=gke.gcr.io/prometheus-engine/rule-evaluator:v0.1.1-gke.0
+ image: gke.gcr.io/prometheus-engine/operator:v0.1.1-gke.0
:
请将上述内容作为使用Google Cloud Managed Service for Prometheus的设计示例，请仅供参考。
感受到的情绪或感觉
考虑Prometheus的兼容性时，着眼于下图中的四个接口，会更加清晰明了。
参考: https://sched.co/ibIO。
-
- exposition format ： メトリクスに関する仕様(実質 OpenMetricsのこと)
-
- remote write protocol ： Remote Write機能に対応したプロトコル
-
- PromQL : Prometheusが蓄積してるデータに対するクエリ。Grafanaとかで利用している
- alerting protocol ： アラート機能に関するプロトコル（実質 Alertmanagerとの接続に関する部分）
Prometheus已经实现了与上述四个接口对应的功能，但是您可以使用兼容这些接口的产品来替代这些功能，或者使用一个完全支持所有接口的产品来完全替代Prometheus。
在这次”Google Cloud Managed Service for Prometheus”中，对于4个接口的处理如下。
-
- exposition format ： 各クラスタの単位で管理
-
- 各クラスタ内でmonitoring.googleapis.com/v1alpha1で設定
-
- remote write protocol ： 各クラスタの単位で管理(ユーザからは隠蔽されているように見える)
PromQL : プロジェクト単位で管理
各クラスタを横断してメトリクスを操作できる
alerting protocol ： 各クラスタの単位で管理
各クラスタ内でmonitoring.googleapis.com/v1alpha1で設定
我觉得这是一个考虑到只使用想要的部分而不考虑远程写入协议的服务。请留意每个集群单独管理的和每个项目管理的两种方式。
如果开发应用程序的人能够在OpenMetrics格式中输出指标，并同时部署podmonitorings.monitoring.googleapis.com，我认为会非常方便易用。
亚马逊托管的Prometheus服务是基于Cortex构建的，而“谷歌云托管的Prometheus服务”则是基于Monarch构建的。我觉得这些差异在每个云供应商之间都是有趣的。
起初，虽然各家云供应商都提供了监控服务，但转而提供托管的Prometheus服务方向的决策，显示出市场上对此的迫切需求。
如果市场整体朝着这个方向发展，作为用户，只要意识到使用OpenMetrics格式输出指标，就可以在任何环境中使用PromQL进行操作，这样在切换环境时也能减少学习成本，我认为这是一个好趋势。
