Google Cloud Managed Service for Prometheus에 대한 PromQL 쿼리는 Monitoring Query Language(MQL)를 사용하여 Monarch 백엔드에서 부분적으로 평가됩니다. 쿼리 결과에는 몇 가지 알려진 차이점이 있습니다. 이 문서에서는 이러한 차이점에 대해 설명합니다.
이 문서에 나열된 차이점 외에도 Managed Service for Prometheus의 PromQL은 Prometheus 버전 2.44에서 사용 가능한 PromQL과 동일합니다.
Prometheus 버전 2.44 이후에 추가된 PromQL 함수는 지원되지 않을 수 있습니다.
측정항목 이름 일치
측정항목 이름의 정확한 일치만 지원됩니다. 쿼리에 측정항목 이름의 정확한 일치를 포함해야 합니다.
__name__ 라벨에서 정규 표현식 일치자를 사용하는 일반적인 시나리오에 다음 해결 방법을 사용하는 것이 좋습니다.
Prometheus 어댑터 구성은 여러 측정항목 이름에 일치시키기 위해 =~ 연산자를 사용하는 경우가 많습니다. 이 방법을 수정하려면 각 측정항목에 별도의 정책을 사용하도록 구성을 확장하고 각 측정항목의 이름을 명시적으로 지정합니다. 이렇게 하면 예상치 못한 측정항목을 실수로 자동 확장하는 것도 방지할 수 있습니다.
정규 표현식은 동일한 차트에 여러 무차원 측정항목을 그래프로 표시하는 데 자주 사용됩니다. 예를 들어 cpu_servicename_usage와 같은 측정항목이 있는 경우 와일드 카드를 사용하여 모든 서비스를 함께 그래프로 표시할 수 있습니다. 이와 같은 무차원 측정항목을 사용하는 것은 Cloud Monitoring에서 명시적으로 좋지 않은 방법으로, 이로 인해 쿼리 성능이 크게 저하됩니다. 이 방법을 수정하려면 측정항목 이름에 차원을 삽입하는 대신 모든 차원을 측정항목 라벨로 이동합니다.
여러 측정항목을 쿼리하는 것은 쿼리할 수 있는 측정항목을 확인하는 데 자주 사용됩니다. 대신 /labels/__name__/values 호출을 사용하여 측정항목을 검색하는 것이 좋습니다.
Cloud Monitoring UI를 사용하여 측정항목을 검색할 수도 있습니다.
여러 측정항목을 일치시키면 측정항목별로 스크래핑 및 수집되고 요금이 청구된 샘플 수를 확인하는 데 유용합니다. Cloud Monitoring은 측정항목 관리 페이지에서 이 정보를 제공합니다. 수집된 샘플 측정항목 또는 기여 분석 ID로 작성된 샘플 측정항목을 사용하여 이 정보에 측정항목 데이터로 액세스할 수도 있습니다.
irate 함수의 전환 확인 기간이 단계 크기보다 작으면 기간을 단계 크기로 늘립니다.
Monarch에서 이러한 변경은 출력에서 어떠한 입력 데이터도 완전히 무시되지 않도록 보장하기 위해 필요합니다. 이 차이점은 rate 계산에도 적용됩니다.
rate 및 increase 계산
rate 함수의 전환 확인 기간이 단계 크기보다 작으면 기간을 단계 크기로 늘립니다.
Monarch에서 이러한 변경은 출력에서 어떠한 입력 데이터도 완전히 무시되지 않도록 보장하기 위해 필요합니다. 이 차이점은 irate 계산에도 적용됩니다.
내삽 및 외삽 계산에 차이점이 있습니다.
Monarch는 Prometheus와 다른 내삽 알고리즘을 사용하며, 이러한 차이로 인해 약간 다른 결과로 이어질 수 있습니다.
예를 들어 Monarch 카운터 샘플은 Prometheus에 사용되는 단일 타임스탬프가 아닌 시간 범위로 저장됩니다. 따라서 Monarch의 카운터 샘플은 Prometheus 타임스탬프가 이를 제외하더라도 비율 계산에 포함될 수 있습니다. 특히 기본 시계열의 시작 또는 끝 부분에서 쿼리할 때 일반적으로 더 정확한 비율 결과가 제공됩니다.
histogram_quantile 계산
샘플이 없는 히스토그램의 PromQL histogram_quantile 계산은 NaN 값을 생성합니다. 내부 쿼리 언어의 계산은 값을 생성하지 않습니다. 대신 타임스탬프의 지점이 삭제됩니다.
비율 계산 차이는 histogram_quantile 쿼리에 대한 입력에도 영향을 줄 수 있습니다.
유형이 다른 측정항목에 대한 유형별 함수
업스트림 Prometheus는 약한 유형이지만 Monarch는 강력한 유형입니다. 즉, 이러한 함수가 업스트림 Prometheus에서 작동하더라도 다른 유형의 측정항목(예: GAUGE 측정항목에서 rate() 실행 또는 COUNTER 또는 유형이 지정되지 않은 측정항목에서 histogram_quantile() 실행)에서 단일 유형에 대한 함수 실행은 Managed Service for Prometheus에서 작동하지 않습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-21(UTC)"],[],[],null,["# PromQL compatibility\n\n[PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/) queries in\nGoogle Cloud Managed Service for Prometheus are partially evaluated at the\n[Monarch](https://research.google/pubs/pub50652/) backend, and there are some known differences\nin query results. This document describes the differences.\nOther than the differences listed in this document, the PromQL in Managed Service for Prometheus is at parity with the PromQL available in Prometheus version **2.44** .\n\n\u003cbr /\u003e\n\nPromQL functions added after Prometheus version **2.44** might not be\nsupported.\n\n\u003cbr /\u003e\n\nUTF-8 support\n-------------\n\n\u003cbr /\u003e\n\nPromQL for Cloud Monitoring supports [UTF-8 querying](https://prometheus.io/docs/guides/utf8/#querying).\n\nIf your Prometheus metric name only consists of alphanumeric characters plus the\n`_` or `:`\ncharacters, and if your label keys only consist of alphanumeric characters plus\nthe `_` character, then you can query using traditional PromQL syntax.\nFor example, a valid query might look like\n`job:my_metric:sum{label_key=\"label_value\"}`.\n\nHowever, if your Prometheus metric name uses any special characters\nexcept for the `_` or `:` characters, or if your label keys use any special\ncharacter except for the `_` character, then you have to construct your query\naccording to the [UTF-8 spec for PromQL](https://prometheus.io/docs/guides/utf8/#querying).\n\nUTF-8 metric names must be quoted and moved into the braces. Label names must\nalso be quoted if they contain legacy-incompatible characters. The following\nexample valid queries are all equivalent:\n\n- `{\"my.domain.com/metric/name_bucket\", \"label.key\"=\"label.value\"}`\n- `{__name__=\"my.domain.com/metric/name_bucket\", \"label.key\"=\"label.value\"}`\n- `{\"__name__\"=\"my.domain.com/metric/name_bucket\", \"label.key\"=\"label.value\"}`\n\n\u003cbr /\u003e\n\nMatching on metric names\n------------------------\n\n\u003cbr /\u003e\n\nOnly exact matching on metric names is supported. You must include\nan exact match on the metric name in your query.\n\nWe recommend the following workarounds for common scenarios that use a regular\nexpression matcher on the `__name__` label:\n\n- Prometheus adapter configurations often use the `=~` operator to match on multiple metric names. To fix this usage, expand the config to use a separate policy for each metric and name each metric explicitly. This also prevents you from accidentally autoscaling on unexpected metrics.\n- Regular expressions are often used to graph multiple non-dimensional metrics on the same chart. For example, if you have a metric like `cpu_`\u003cvar translate=\"no\"\u003eservicename\u003c/var\u003e`_usage`, you might use a wildcard to graph all your services together. Using non-dimensional metrics like this is an explicitly bad practice in Cloud Monitoring, and this practice leads to extremely poor query performance. To fix this usage, move all dimensionality into metric labels instead of embedding dimensions in the metric name.\n- Querying over multiple metrics is often used to see what metrics are available to query. We recommend you instead use the `/labels/__name__/values` call to discover metrics. You can also discover metrics using the Cloud Monitoring UI.\n- Matching multiple metrics is useful for seeing how many samples were scraped, ingested, and charged on a per-metric basis. Cloud Monitoring provides this information to you on the [Metrics Management](/monitoring/docs/metrics-management) page. You can also access this information as metric data by using the [Samples Ingested metric or the Samples Written by Attribution ID\n metric](/stackdriver/docs/managed-prometheus/cost-controls#identify-cost-sources).\n\n\u003cbr /\u003e\n\nStaleness\n---------\n\n\u003cbr /\u003e\n\n[Staleness](https://prometheus.io/docs/prometheus/latest/querying/basics/#staleness) is not supported in the\nMonarch backend.\n\n\u003cbr /\u003e\n\nCalculation of `irate`\n----------------------\n\n\u003cbr /\u003e\n\nWhen the lookback window for the [`irate`](https://prometheus.io/docs/prometheus/latest/querying/functions/#irate) function\nis less than the step size, we increase the window to the step size.\nMonarch requires this change to ensure that none of the input\ndata is completely ignored in the output. This difference applies to\n`rate` calculations as well.\n\n\u003cbr /\u003e\n\nCalculation of `rate` and `increase`\n------------------------------------\n\n\u003cbr /\u003e\n\nWhen the lookback window for the [`rate`](https://prometheus.io/docs/prometheus/latest/querying/functions/#rate) function\nis less than the step size, we increase the window to the step size.\nMonarch requires this change to ensure that none of the input data\nis completely ignored in the output. This difference applies to\n`irate` calculations as well.\n\nThere are differences in the interpolation and extrapolation calculations.\nMonarch uses a different interpolation algorithm than\nPrometheus, and this difference can lead to slightly different results.\nFor example, Monarch counter samples are stored with a time\nrange rather than the single timestamp that Prometheus uses. Therefore,\ncounter samples in Monarch can be included in a rate calculation\neven though the Prometheus timestamp would exclude them. This generally results\nin more accurate rate results, especially when querying over the beginning\nor end of the underlying time series.\n\n\u003cbr /\u003e\n\nCalculation of `histogram_quantile`\n-----------------------------------\n\n\u003cbr /\u003e\n\nA PromQL [`histogram_quantile`](https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile)\ncalculation on a histogram with no samples produces a NaN value. The internal\nquery language's calculation produces no value;\nthe point at the timestamp is dropped instead.\n\nThe rate-calculation differences can also affect the input to\n`histogram_quantile` queries.\n\n\u003cbr /\u003e\n\nType-specific functions on\ndifferently typed metrics\n----------------------------------------------------\n\n\u003cbr /\u003e\n\nAlthough upstream Prometheus is weakly typed, Monarch is strongly\ntyped. This means that running functions specific to a single type on a\ndifferently typed metric (for example, running `rate()` on a GAUGE metric or\n`histogram_quantile()` on a COUNTER or untyped metric) doesn't work in\nManaged Service for Prometheus, even though these functions work in upstream\nPrometheus."]]
