超强:文章相似度检测工具有哪些？如何使用？

　　超强:文章相似度检测工具有哪些？如何使用？

　　许多做 自媒体 的人想知道他们的 文章 相似性。如果相似度很高，很难得到平台的强烈推荐。所以要想提高推荐，就必须降低文章的相似度。我们来看看文章相似度检测工具？如何使用它们？

　　文章相似度检测工具有哪些？

　　一款专门针对自媒体文章上市前的内容相似度检测工具：易小儿。这个检测工具非常强大和全面，基本满足了自媒体平台检测的所有维度。仅需5.8秒即可获得详细的测试报告结果，可以帮助我们快速提高文章的校对效率。

　　说到检测自媒体文章，不得不提一下经常遇到的情况。每次发布文章都会被回调，不然会提示文章违规。信息，只是不告诉你违规在哪里，或者重复太高不推荐。还有一些简单的错误。只有在发布之后，句子中才会出现拼写错误。对于有强迫症的人来说，这很烦人。今天给大家推荐的文章相似度检测工具可以有效规避这些问题。

　　

　　以下是如何使用此工具的简要说明：

　　1.首先，我们需要下载并注册这个工具。可以直接在搜索引擎中搜索关键词“一小儿”，进入官网直接下载。

　　2、下载注册完成后，进入文章编辑栏，将要检测的文章导入编辑器。目前支持复制粘贴和文字导入。完成后，在右侧选择要检测的项目。

　　目前，易小儿支持：文章错别字检测、违规信息检测、标签字段检测、标题风险检测、原创度数检测、图片检测等，您可以根据自己的具体需求进行选择。

　　文章相似度检测有两种方式：

　　1.根据文章内容符号进行分裂检测。

　　

　　2.根据文章内容的字符数进行拆分检测（字符数可以根据自己的要求调整）。

　　指示：

　　1.将需要检测的文章复制到工具中。

　　2.设置检测方法。

　　3. 提交测试。

　　如果文章有不合格的情况，我们可以根据测试报告进行对比修改，使文章的相似度降低，我们的文章也可以变成High-平台推荐优质 自媒体 内容。

　　超强:高可用Prometheus：问题集锦

　　监控系统历史悠久，是一个非常成熟的方向，而Prometheus作为新一代的开源监控系统，已经逐渐成为云原生系统的事实标准，这也证明了它的设计很受欢迎. 本文主要分享Prometheus在实践中遇到的一些问题和思考。如果你对 K8S 监控系统或者 Prometheus 的设计不是很了解，可以先看看容器监控系列。

　　几个原则 Prometheus 限制 K8S 集群中常用的 exporter

　　Prometheus 是一个 CNCF 项目，拥有完整的开源生态系统。与Zabbix等传统代理监控不同，它提供了丰富的exporter来满足你的各种需求。您可以在此处查看官方和非官方出口商。如果还是不能满足你的需求，你也可以自己写一个exporter，简单方便，免费开放，这是一个优势。

　　但是，过于开放会带来选择和试错的成本。以前只需在 zabbix 代理中进行几行配置即可完成的工作，现在您将需要大量的导出器来完成它。还维护和监控所有出口商。尤其是升级exporter版本的时候，很痛苦。非官方的exporter会有很多bug。这是一个用处，当然也是Prometheus的设计原则。

　　K8S 生态系统的组件将提供 /metric 接口以提供自我监控。以下是我们正在使用的：

　　还有各种场景下的自定义导出器，比如日志提取，后面会介绍。

　　K8S核心组件监控和Grafana面板

　　k8s集群运行过程中，需要关注核心组件的状态和性能。比如kubelet、apiserver等，根据上面提到的exporter指标，可以在Grafana中绘制如下图表：

　　模板可以参考dashboards-for-kubernetes-administrators，根据运行情况不断调整告警阈值。

　　这里提到，虽然Grafana支持模板能力，可以方便的进行多级下拉框选择，但不支持模板模式下配置告警规则。相关问题

　　官方解释了很多这个功能，但是最新的版本还是不支持。从 issue 中借用一句话吐出：

　　It would be grate to add templates support in alerts. Otherwise the feature looks useless a bit.

　　Grafana的基本用法可以看这个文章

　　采集组件多合一

　　Prometheus 系统中的 Exporter 是独立的，每个组件都各司其职，例如 Node-Exporter 用于机器资源，Nvidia Exporter 用于 Gpu 等。但是Exporters越多，运维压力就越大，尤其是Agent的资源控制和版本升级。我们尝试结合一些Exporters，有两种解决方案：

　　通过主进程拉起 N 个 Exporter 进程，您仍然可以关注社区版本的更新和错误修复。

　　使用 Telegraf 支持各种类型的 Input，N in 1。

　　此外，Node-Exporter 不支持进程监控。可以添加一个Process-Exporter，也可以使用上面提到的Telegraf 来使用procstat 的输入到采集process 指标。

　　黄金指标的合理选择

　　采集的指标很多，我们应该关注哪些呢？Google 在《Sre 手册》中提出了“四个黄金信号”：延迟、流量、错误数和饱和度。在实践中，您可以使用 Use 或 Red 方法作为指导，Use 用于资源，Red 用于服务。

　　Prometheus 采集 中共有三个常用服务：

　　在线服务：如Web服务、数据库等，一般关心请求率、延迟和错误率，即RED方法

　　离线服务：如日志处理、消息队列等，一般关注队列的数量、进行中的数量、处理速度和出现的错误，即Use方法

　　批处理任务：与离线任务类似，但离线任务运行时间较长，批处理任务按计划运行。比如持续集成就是一个批处理任务，对应K8S中的一个job或者cronjob。一般关注耗时，错误次数等，因为运行周期短，很有可能在采集到达之前运行就结束了，所以一般用pushgateway，改pull推。

　　Use和Red的实例请参考容器监控实践-K8S常用指标分析文章。

　　K8S 1.16 中 Cadvisor 的度量兼容性问题

　　在 K8S 1.16 版本中，Cadvisor 指标去掉了 pod_Name 和 container_name 的标签，取而代之的是 pod 和 container。如果之前使用这两个标签进行查询或Grafana绘图，则需要更改Sql。因为我们一直支持多个 K8S 版本，所以我们通过 relabel 配置继续保留原来的 **_name。

　　metric_relabel_configs:- source_labels: [container] regex: (.+) target_label: container_name replacement: $1 action: replace- source_labels: [pod] regex: (.+) target_label: pod_name replacement: $1 action: replace

　　注意使用metric_relabel_configs，而不是relabel_configs，替换在采集之后。

　　Prometheus 采集外接K8S集群，多集群

　　如果Prometheus部署在K8S集群采集，使用官方的Yaml很方便，但是因为权限和网络的关系，我们需要部署在集群外，二进制操作，采集多个K8S集群.

　　Pod模式在集群中运行不需要证书（In-Cluster模式），但需要在集群外声明一个token等证书，并替换地址，即使用Apiserver Proxy采集 ，以Cadvisor采集为例，Job配置为：

　　- job_name: cluster-cadvisor honor_timestamps: true scrape_interval: 30s scrape_timeout: 10s metrics_path: /metrics scheme: https kubernetes_sd_configs: - api_server: https://xx:6443 role: node bearer_token_file: token/cluster.token tls_config: insecure_skip_verify: true bearer_token_file: token/cluster.token tls_config: insecure_skip_verify: true relabel_configs: - separator: ; regex: __meta_kubernetes_node_label_(.+) replacement: $1 action: labelmap - separator: ; regex: (.*) target_label: __address__ replacement: xx:6443 action: replace - source_labels: [__meta_kubernetes_node_name] separator: ; regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor action: replace metric_relabel_configs: - source_labels: [container] separator: ; regex: (.+) target_label: container_name replacement: $1 action: replace - source_labels: [pod] separator: ; regex: (.+) target_label: pod_name replacement: $1 action: replace

　　Bearer_token_file 需要提前生成，这个可以参考官方文档。记住base64解码。

　　对于cadvisor来说，__metrics_path__可以转换成/api/v1/nodes/{1}/proxy/metrics/cadvisor，代表Apiserver代理到Kubelet，如果网络能通，其实可以直接用Kubelet的10255作为目标，可以直接写成：{1}:10255/metrics/cadvisor，意思是直接请求Kubelet。规模大的时候，也减轻了Apiserver的压力，即服务发现使用Apiserver，采集不使用Apiserver

　　因为cadvisor暴露了主机端口，所以配置比较简单。如果是kube-state-metric之类的Deployment，是以endpoint的形式暴露出来的，写法应该是：

　　- job_name: cluster-service-endpoints honor_timestamps: true scrape_interval: 30s scrape_timeout: 10s metrics_path: /metrics scheme: https kubernetes_sd_configs: - api_server: https://xxx:6443 role: endpoints bearer_token_file: token/cluster.token tls_config: insecure_skip_verify: true bearer_token_file: token/cluster.token tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] separator: ; regex: "true" replacement: $1 action: keep - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme] separator: ; regex: (https?) target_label: __scheme__ replacement: $1 action: replace - separator: ; regex: (.*) target_label: __address__ replacement: xxx:6443 action: replace - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_endpoints_name, __meta_kubernetes_service_annotation_prometheus_io_port] separator: ; regex: (.+);(.+);(.*) target_label: __metrics_path__ replacement: /api/v1/namespaces/${1}/services/${2}:${3}/proxy/metrics action: replace - separator: ; regex: __meta_kubernetes_service_label_(.+) replacement: $1 action: labelmap - source_labels: [__meta_kubernetes_namespace] separator: ; regex: (.*) target_label: kubernetes_namespace replacement: $1 action: replace - source_labels: [__meta_kubernetes_service_name] separator: ; regex: (.*) target_label: kubernetes_name replacement: $1 action: replace

　　对于端点类型，需要将__metrics_path__转换为/api/v1/namespaces/{1}/services/{2}:${3}/proxy/metrics，需要替换命名空间、svc名称端口等。 ，这里的写法只适用于接口为/metrics的exporter，如果你的exporter不是/metrics接口，则需要替换此路径。或者像我们一样将此地址用于统一约束。

　　这里的__meta_kubernetes_service_annotation_prometheus_io_port的来源是部署exporter时写的注解。大多数 文章 只提到 prometheus.io/scrape: 'true'，但它也可以定义端口、路径和协议。为了方便采集时的替换处理。

　　其他一些relabels比如kubernetes_namespace是为了保留原创信息，方便做promql查询时的过滤条件。

　　如果是多集群，可以多次编写相同的配置。一般来说，一个集群可以配置三种类型的作业：

　　获取 GPU 指标

　　nvidia-smi 可以查看机器上的 GPU 资源，而 Cadvisor 实际上暴露了 Metrics 来指示容器的 GPU 使用情况。

　　container_accelerator_duty_cyclecontainer_accelerator_memory_total_bytescontainer_accelerator_memory_used_bytes

　　如果想要更详细的 GPU 数据，可以安装 dcgm exporter，但只有 K8S 1.13 可以支持。

　　更改 Prometheus 的显示时区

　　为了避免时区混淆，Prometheus 使用 Unix Time 和 Utc 专门用于在所有组件中显示。不支持在配置文件中设置时区，也无法读取原生的/etc/timezone时区。

　　事实上，这个限制并不影响使用：

　　有关时区的讨论，请参阅此问题。

　　如何采集 LB 后面的 RS 度量

　　如果你有负载均衡LB，但是网络上的Prometheus只能访问LB本身，不能访问后续的RS，采集RS应该如何暴露metrics呢？

　　版本选择

　　Prometheus目前最新版本是2.16，Prometheus还在迭代，所以尽量使用最新版本，1.X版本不需要考虑。

　　2.16版本有一套实验UI，可以查看TSDB的状态，包括Top 10 Label、Metric。

　　Prometheus 大内存问题

　　随着规模变大，Prometheus 所需的 CPU 和内存都会增加，内存一般会先达到瓶颈。这里我们先讨论一下*敏*感*词*Prometheus的内存问题。

　　原因：

　　我的指标需要多少内存：

　　以我们的其中一台 Prometheus Server 为例，本地只保留了 2 个小时的数据，950,000 系列，大概占用的内存如下：

　　优化方案是什么：

　　Prometheus 内存使用分析：

　　相关问题：

　　

　　Prometheus 容量规划

　　除了上面提到的内存，容量规划还包括磁盘存储规划，这和你的 Prometheus 架构有关。

　　Prometheus 每 2 小时将已经缓冲在内存中的数据压缩到磁盘上的块中。包括 Chunks、Indexes、Tombstones、Metadata，这些都占用了部分存储空间。一般情况下，Prometheus 中存储的每个样本大约占用 1-2 个字节大小（1.7Byte）。您可以使用 Promql 查看每个样本平均占用多少空间：

　　 rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h])/ rate(prometheus_tsdb_compaction_chunk_samples_sum[1h]){instance="0.0.0.0:8890", job="prometheus"} 1.252747585939941

　　如果粗略估计本地磁盘的大小，可以使用以下公式：

　　磁盘大小 = 保留时间 * 每秒获取样本数 * 样本大小

　　在保留时间（retention_time_seconds）和样本大小（bytes_per_sample）不变的情况下，如果要降低本地磁盘的容量要求，只能降低每秒的样本数（ingested_samples_per_second）。

　　查看当前每秒采集的样本数：

　　rate(prometheus_tsdb_head_samples_appended_total[1h])

　　有两种手段，一种是减少时间序列的数量，另一种是增加采集个样本的时间间隔。考虑到 Prometheus 压缩了时间序列，减少时间序列数量的效果更加明显。

　　例如：

　　以上磁盘容量不包括wal文件。wal文件（Raw Data）在Prometheus官方文档中说明至少会保存3个Write-Ahead Log Files，每个最大大小为128M（实际数量会更多）。

　　因为我们使用的是灭霸的方案，所以本地磁盘只保留2H热数据。Wal 每 2 小时生成一个块文件，每 2 小时将块文件上传到对象存储。本地磁盘基本没有压力。

　　对于 Prometheus 的存储机制，你可以阅读这个。

　　对 Apiserver 的性能影响

　　如果你的 Prometheus 使用 kubernetes_sd_config 进行服务发现，请求一般会通过集群的 Apiserver。随着规模的增加，您需要评估对 Apiserver 性能的影响，尤其是当 Proxy 发生故障时，会导致 CPU 增加。当然，如果单个 K8S 集群规模过大，一般会进行集群拆分，但还是需要随时监控 Apiserver 的进程变化。

　　在监控Cadvisor、Docker、Kube-Proxy的metrics时，我们最初选择Apiserver Proxy到节点的对应端口，统一设置比较方便，后来改成直接拉节点，Apiserver只做服务发现.

　　Rate的计算逻辑

　　Prometheus 中的 Counter 类型主要是针对 Rate 存在的，即计算速率。纯Counter计数意义不大，因为一旦Counter复位，总计数就没有意义了。

　　Rate 会自动处理 Counter 的重置，通常会不断变大。例如，Exporter 启动然后崩溃。最初以每秒约 10 的速率递增，但只运行半小时，rate(x_total[1h]) 将返回每秒约 5 的结果。此外，计数器的任何减少也被视为计数器重置。例如，如果时间序列的值为 [5,10,4,6]，则将其视为 [5,10,14,16]。

　　费率值很少是准确的。由于不同目标的提取发生在不同的时间，抖动会随着时间的推移而发生，query_range 很少被计算为完全匹配提取时间，并且提取可能会失败。面对这样的挑战，Rate 的设计必须稳健。

　　Rate 不想捕获每个 delta，因为有时 delta 会丢失，例如实例在 fetch 间隔内死亡。如果 Counter 变化缓慢，比如每小时只增加几次，可能会导致 [artifacts]。例如，有一个值为 100 的 Counter 时间序列，Rate 不知道这些增量是否是当前值，或者目标是否已经运行了几年并且刚刚开始返回。

　　建议将 Rate 计算的范围向量的时间设置为至少 4 倍的 fetch 间隔。这将确保即使爬行缓慢和爬行失败，您也始终有两个可用的样本。此类问题在实践中经常出现，因此保持这种弹性很重要。例如，对于 1 分钟的爬网间隔，您可以使用 4 分钟的速率计算，但这通常四舍五入为 5 分钟。

　　如果Rate的时间区间有缺失数据，他会根据趋势做出推断，比如：

　　有关详细信息，请参阅此视频

　　违反直觉的 P95 统计数据

　　histogram_quantile 是 Prometheus 常用的一个函数，例如，一个服务的 P95 响应时间经常被用来衡量服务质量。但是，具体是什么意思很难解释，尤其是对非技术类的学生来说，会遭遇很多“灵魂拷问”。

　　我们常说的P95（P99，P90都可以）的响应延迟是100ms，其实就是说在所有采集到的响应延迟中，有5%的请求大于100ms，95%的请求小于100ms . Prometheus 中的 histogram_quantile 函数接收 0 到 1 之间的小数。通过小数乘以 100 可以很容易地得到对应的百分位数。例如 0.95 对应 P95，也可以高于百分位数。精度，例如 0.9999。

　　当您使用 histogram_quantile 绘制响应时间趋势时，您可能会被问到：为什么 P95 大于或小于我的平均值？

　　正如中位数可能大于或小于平均值一样，P99 完全有可能小于平均值。通常 P99 几乎总是大于平均值，但如果数据分布极端，前 1% 可能会大到推高平均值。一个可能的例子：

　　1, 1, ... 1, 901 // 共 100 条数据，平均值=10，P99=1

　　服务X分两步完成，A和B，其中X的P99耗时100Ms，A进程的P99耗时50Ms。那么B流程的P99的预估时间是多少呢？

　　直觉上，既然X=A+B，答案大概是50Ms，或者至少应该小于50Ms。实际上，B可以大于50Ms。只要 A 和 B 中最大的 1% 不碰巧相遇，B 就可以有一个非常大的 P99：

　　A = 1, 1, ... 1, 1, 1, 50, 50 // 共 100 条数据，P99=50B = 1, 1, ... 1, 1, 1, 99, 99 // 共 100 条数据，P99=99X = 2, 2, ... 1, 51, 51, 100, 100 // 共 100 条数据，P99=100

　　如果让 A 过程最大的 1% 接近 100Ms，我们也能构造出 P99 很小的 B：A = 50, 50, ... 50, 50, 99 // 共 100 条数据，P99=50B = 1, 1, ... 1, 1, 50 // 共 100 条数据，P99=1X = 51, 51, ... 51, 100, 100 // 共 100 条数据，P99=100

　　所以，我们从标题中唯一能确定的就是B的P99不应该超过100ms，而A的P99取50Ms的条件其实是没有用的。

　　类似的问题还有很多，所以对于 histogram_quantile 函数，可能会产生一些反直觉的结果。最好的处理方法是不断调整你的 Bucket 的值，以确保更多的请求时间落在更详细的范围内，比如请求时间只有统计显着性。

　　查询慢问题

　　Promql 的基础见这个 文章

　　Prometheus 提供了一个自定义 Promql 作为查询语句。在Graph上调试的时候会告诉你这个Sql的返回时间。如果太慢，请注意，可能是您的使用有问题。

　　要评估 Prometheus 的整体响应时间，您可以使用以下默认指标：

　　prometheus_engine_query_duration_seconds{}

　　一般情况下，响应慢的原因是Promql使用不当，或者指标规划有问题，比如：

　　基数

　　高基数是数据库无法回避的话题。对于像 Mysql 这样的 DB，基数是指特定列或字段中收录的唯一值的数量。基数越低，列中重复的元素就越多。对于时间序列数据库，是标签、标签等标签值的个数。

　　比如Prometheus中有一个指标http_request_count{method="get",path="/abc",originIP="1.1.1.1"}表示流量，method表示请求方法，originIP是客户端IP，和方法的枚举值是有限的，但是originIP是无限的，其他标签的排列组合是无限的，没有关联的特征，所以这种高基数不适合作为公制。如果你真的想提取 originIP，你应该使用日志。方式，而不是指标监控

　　时间序列数据库对这些标签进行索引以提高查询性能，以便您可以快速找到与所有指定标签匹配的值。如果值的个数太大，索引就没有意义了，尤其是在做P95等计算的时候，需要扫描大量的Series数据

　　官方文档中对 Label 的建议

　　CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

　　如何查看当前的Label分布，可以使用Prometheus提供的Tsdb工具。可以使用命令行查看，也可以在Prometheus Graph 2.16及以上版本查看

　　[work@xxx bin]$ ./tsdb analyze ../data/prometheus/Block ID: 01E41588AJNGM31SPGHYA3XSXGDuration: 2h0m0sSeries: 955372Label names: 301Postings (unique label pairs): 30757Postings entries (total label pairs): 10842822....

　　top10 高基数指标

　　Highest cardinality metric names:87176 apiserver_request_latencies_bucket59968 apiserver_response_sizes_bucket39862 apiserver_request_duration_seconds_bucket37555 container_tasks_state....

　　高基数标签

　　Highest cardinality labels:4271 resource_version3670 id3414 name1857 container_id1824 __name__1297 uid1276 pod...

　　找到最大的指标或工作

　　top10中的metrics个数：除以metric name

　　topk(10, count by (__name__)({__name__=~".+"}))<br />apiserver_request_latencies_bucket{} 62544apiserver_response_sizes_bucket{} 44600

　　top10中的metrics个数：除以job name

　　topk(10, count by (__name__, job)({__name__=~".+"})){job="master-scrape"} 525667{job="xxx-kubernetes-cadvisor"} 50817{job="yyy-kubernetes-cadvisor"} 44261

　　Prometheus 重启慢且热重载

　　当 Prometheus 重启时，需要将 Wal 的内容加载到内存中。保留时间越长，Wal文件越大，实际重启的时间越长。这是普罗米修斯的机制，没有办法做到。因此，如果可以Reload，就不要重启，必须重启。会导致短期不可用，此时Prometheus的高可用就很重要了。

　　Prometheus 还优化了启动时间。在 2.6 版本中，优化了 Wal 的加载速度。我希望重启时间不会超过1分钟。

　　Prometheus 提供热加载能力，但需要启用 web.enable-lifecycle 配置。更改配置后，可以点击curl下的reload界面。默认情况下更改 prometheus-operator 中的配置将触发重新加载。如果你不使用算子，又想监控 configmap 配置变化来重新加载服务，可以试试这个简单的脚本

　　#!/bin/shFILE=$1URL=$2HASH=$(md5sum $(readlink -f $FILE))while true; do NEW_HASH=$(md5sum $(readlink -f $FILE)) if [ "$HASH" != "$NEW_HASH" ]; then HASH="$NEW_HASH" echo "[$(date +%s)] Trigger refresh" curl -sSL -X POST "$2" > /dev/null fi sleep 5done

　　使用时挂载和prometheus一样的configmap，传入如下参数：

　　args: - /etc/prometheus/prometheus.yml - http://prometheus.kube-system.svc.cluster.local:9090/-/reloadargs: - /etc/alertmanager/alertmanager.yml - http://prometheus.kube-system.svc.cluster.local:9093/-/reload

　　您的应用需要公开多少指标

　　自己开发服务的时候，可能会暴露一些数据给metrics，比如具体请求的数量，goroutines的数量等等，多少metrics比较合适呢？

　　

　　虽然指标的数量与您的应用程序的大小有关，但有一些建议（Brian Brazil），

　　比如缓存等简单的服务，类似于Pushgateway，有120个左右的指标。Prometheus 本身公开了大约 700 个指标。如果您的应用程序很大，请尽量不要超过 10,000 个指标。您需要合理控制您的标签。

　　节点导出器的问题

　　一些指标名称更改：

　　* node_cpu -> node_cpu_seconds_total* node_memory_MemTotal -> node_memory_MemTotal_bytes* node_memory_MemFree -> node_memory_MemFree_bytes* node_filesystem_avail -> node_filesystem_avail_bytes* node_filesystem_size -> node_filesystem_size_bytes* node_disk_io_time_ms -> node_disk_io_time_seconds_total* node_disk_reads_completed -> node_disk_reads_completed_total* node_disk_sectors_written -> node_disk_written_bytes_total* node_time -> node_time_seconds* node_boot_time -> node_boot_time_seconds* node_intr -> node_intr_total

　　如果之前使用过旧版本的exporter，绘制grafana时指标名称会有所不同。有两种解决方案：

　　kube-state-metric 的问题

　　kube-state-metric的使用和原理可以先阅读

　　除了文章中提到的功能，kube-state-metric还有一个很重要的使用场景，就是结合cadvisor metrics。原来的cadvisor只有pod信息，不知道属于哪个deployment或者sts，但是用kube-state-metric中的kube_pod_info可以在join查询后显示。kube-state-metric 的元数据索引在扩展 cadvisor 的标签方面起到了很大的作用。prometheus-operator 的许多记录规则使用 kube-state-metric 进行组合查询。

　　Pod 的标签信息也可以在 kube-state-metric 中展示，这样可以在获取 cadvisor 数据后进行分组更方便，比如根据 Pod 的运行环境进行分类。但是，kube-state-metric 不会暴露 pod 的注释。原因是下面提到的高基数问题，即注解的内容太多，不适合作为指标暴露。

　　relabel_configs 和 metric_relabel_configs

　　relabel_config 出现在 采集 之前，metric_relabel_configs 出现在 采集 之后。合理的组合可以满足很多场景的配置。

　　喜欢：

　　metric_relabel_configs: - separator: ; regex: instance replacement: $1 action: labeldrop

　　- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_endpoints_name, __meta_kubernetes_service_annotation_prometheus_io_port] separator: ; regex: (.+);(.+);(.*) target_label: __metrics_path__ replacement: /api/v1/namespaces/${1}/services/${2}:${3}/proxy/metrics action: replace

　　Prometheus 的预测能力

　　场景一：你的磁盘剩余空间一直在减少，减少的幅度比较均匀。您想知道达到阈值需要多长时间，并且您想在某个时刻发出警报。

　　场景二：你的 Pod 的内存使用量一直在增加，你想知道需要多长时间才能达到 Limit 值，并在某个时间报警，并在被杀死之前检查。

　　Prometheus 的 Deriv 和 Predict_Linear 方法可以满足这样的需求。Promtheus 提供基本的预测能力，根据当前的变化率，推断一段时间后的值。

　　以 mem_free 为例，最近一小时 free 值一直在下降。

　　mem_free仅为举例，实际内存可用以mem_available为准

　　deriv 函数可以显示一段时间内指标的变化率：

　　predict_linear 方法就是根据这个速度来预测最终可达到的值：

　　predict_linear(mem_free{instanceIP="100.75.155.55"}[1h], 2*3600)/1024/1024

　　您可以根据设置设置合理的报警规则，例如小于10时报警：

<p>rule: predict_linear(mem_free{instanceIP="100.75.155.55"}[1h], 2*3600)/1024/1024