0、metric_relabel_configs一個常用的用途：drop不需要的數據，不保存在Prometheus 中。
1、統計計算節點已經分配的cpu/memory request占節點Allocatable的百分比（類似kubectl describe node）
sum(kube_pod_container_resource_requests_cpu_cores{} * on(namespace, pod) group_left() (kube_pod_status_phase(phase!="Succeeded", phase!="Failed") == 1)) by (node) / on(node) kube_node_status_allocatable_cpu_cores{} * 100
group_left一般用來在多對一場景下作二元運算時，指定左邊的指標樣本具有更高的基數，比如kube_pod_container_resource_requests_cpu_cores{}這個指標(namespace,pod)是一樣的記錄也可以有多條(container不同)
注意如果pod沒有調度成功(pending)，那么指標kube_pod_container_resource_requests_cpu_cores{}中沒有node label，所以后面kube_pod_status_phase可以不用去掉Pending狀態的Pod，去掉也無所謂
group_left還可以用來實現運算后保留左邊指標的標簽
2、計算一段時間內counter類型指標變化率的最大值，如計算3h內某容器cpu使用率最大值
我們知道求某個指標樣本時間序列range vector數據的最大值應該使用max_over_time，但是promql子語句無法再計算range vector數據，即
irate(container_cpu_usage_seconds_total[5m])[3h]這種寫法是錯誤的，導致max_over_time無法輸入一個cpu使用率的range vector值，可行的一個解決辦法是通過Rules引入一個record（相當於一個新的指標），那么就可以通過這個record的metrics selector來獲取range vector數據，即metrcis{}[time]，如下
1、現在Prometheus配置一個rules文件，內容如下
groups - name: kubernets-pod-cpu-irate rules: - record: container:cpu_usage:irate expr: irate(container_cpu_usage_seconds_total{}[5m])
2、在Prometheus可以直接查詢container:cpu_usage:irate這個指標，那么通過如下PromQL即可計算時間范圍內速率的最大值
max_over_time(container:cpu_usage:irate{}[3h])
3、在grafana面板中添加變量Variables時，如果變量的Type時Query，那么可以通過promQL來獲取變量的取值，其中label_values()可以用來獲取某個指標具體某個標簽的值，而label_names()可以用來獲取所有的標簽名（這個要求prometheus的版本大於2.6）
4、prometheus的指標類型可以分為Counter、Gauge、Histogram、Summary，promQL表達式數據類型可以分為Instant vector、Range vector、Scalar、String
Histogram和Summary的區別是什么呢？
Histogram：客戶端（即暴露指標的服務）設定桶bucket的邊界le，並且計算落在bucket區間樣本的數量（不會保存樣本值），因為只是做一個計數統計，所以性能開銷低（和Counter或Gauge類似），可以通過promQL的histogram_quantile()函數來計算summary分位點數據，但是畢竟沒有保存實際的樣本數據，histogram_quantile計算出的數據可能不准確，但是因為在服務端計算，可以按需指定分位點。
Summary：客戶端已經計算好quantile分位點數據，算法計算過程需要全局鎖保護，所以計算性能相對差。服務端如prometheus不能獲取未指定的分位點數據。
__address__：當前Target實例的訪問地址<host>:<port>
__scheme__：采集目標服務訪問地址的HTTP Scheme，HTTP或者HTTPS
__metrics_path__：采集目標服務訪問地址的訪問路徑
__param_<name>：采集任務目標服務的中包含的請求參數
# The source labels select values from existing labels. Their content is concatenated # using the configured separator and matched against the configured regular expression # for the replace, keep, and drop actions. [ source_labels: '[' <labelname> [, ...] ']' ] # Separator placed between concatenated source label values. [ separator: <string> | default = ; ] # Label to which the resulting value is written in a replace action. # It is mandatory for replace actions. Regex capture groups are available. [ target_label: <labelname> ] # Regular expression against which the extracted value is matched. [ regex: <regex> | default = (.*) ] # Modulus to take of the hash of the source label values. [ modulus: <uint64> ] # Replacement value against which a regex replace is performed if the # regular expression matches. Regex capture groups are available. [ replacement: <string> | default = $1 ] # Action to perform based on regex matching. [ action: <relabel_action> | default = replace ]