基于Prometheus的OpenFaaS监控数据异常的排查方法

一、先搞懂为啥要排查异常

很多人用OpenFaaS做无服务器函数，就是图它能快速部署、自动扩缩容，比如电商大促时临时加的秒杀函数、日常用的图片压缩接口，都是OpenFaaS的常用场景。但用着用着经常会碰到各种问题：比如明明函数没报错，监控里却显示请求延迟飙到好几秒；或者明明没多少人用，函数实例却突然变多，占了不少服务器资源；更糟的是Prometheus突然不显示OpenFaaS的监控数据了，完全不知道函数跑成啥样。

这时候排查就成了必须要做的事——要是放任不管，轻的是用户体验差，重的是服务器资源浪费、业务出问题。而且Prometheus是专门做监控数据收集的工具，它和OpenFaaS的搭配本来是很成熟的，但就是因为配置、网络、数据采集这些环节容易出问题，才需要一套清晰的排查方法。

二、排查前的准备工作

2.1 确认基础环境状态

在动手排查之前，得先确认最基础的环境有没有问题，不然连Prometheus和OpenFaaS都没正常运行，再怎么查都是白搭。这里我们用Kubernetes作为统一技术栈，所有操作都围绕K8s里的OpenFaaS和Prometheus展开。

首先要检查两个核心组件的Pod是不是正常运行，命令如下：

# 检查OpenFaaS的核心服务pod状态，默认命名空间是openfaas
kubectl -n openfaas get pods
# 检查Prometheus的pod状态，默认命名空间是monitoring
kubectl -n monitoring get pods

如果这两个命令输出的Pod状态不是Running，那先解决Pod本身的问题，比如有没有OOMKilled、CrashLoopBackOff这类异常，解决完再继续排查。

2.2 确认Prometheus的采集配置

Prometheus要收集OpenFaaS的监控数据，得先知道从哪里取数据，这个信息存在它的配置文件里。我们可以先导出当前的配置，看看有没有问题：

# 导出Prometheus的配置到本地文件，方便查看
kubectl -n monitoring exec -it prometheus-0 -- cat /etc/prometheus/prometheus.yml > prometheus_config.yml

正常情况下，OpenFaaS的采集配置应该是这样的：

scrape_configs:
  # 专门针对OpenFaaS的采集配置
  - job_name: 'openfaas'
    # 采集间隔，默认15秒，可根据需求调整
    scrape_interval: 15s
    # 采集的目标地址，这里是OpenFaaS的网关服务，网关是OpenFaaS的核心入口，所有函数的监控数据都从这里取
    static_configs:
      - targets: ['gateway.openfaas:8080']

如果导出的配置里没有这段内容，或者targets写错了（比如写成了gateway.openfaas:8081这类错误端口），那就是配置的问题，先改配置再重新加载。

三、常见异常的排查步骤

3.1 异常一：Prometheus完全没有OpenFaaS的监控数据

这是最常见的问题，表现为打开Prometheus的Web界面，搜索openfaas相关的指标（比如openfaas_function_requests_total），完全没有结果。我们可以分三步排查：

第一步，先确认OpenFaaS的网关有没有暴露监控数据。OpenFaaS的网关会把所有函数的监控数据暴露在自己的/metrics接口，我们可以直接访问这个接口，看看有没有数据：

# 用curl命令访问OpenFaaS网关的metrics接口，这里假设网关的服务地址是gateway.openfaas:8080
kubectl -n monitoring exec -it prometheus-0 -- curl gateway.openfaas:8080/metrics

如果这个命令返回的内容里没有openfaas开头的指标，那说明OpenFaaS本身的监控数据没生成，这时候要检查OpenFaaS的网关配置，或者升级OpenFaaS的版本，因为旧版本可能有监控数据不生成的bug。

第二步，确认Prometheus和OpenFaaS网关的网络连通性。有时候配置是对的，但网络不通，Prometheus也拿不到数据。我们可以在Prometheus的Pod里直接ping网关的地址：

# 在Prometheus的Pod里ping OpenFaaS网关的服务地址
kubectl -n monitoring exec -it prometheus-0 -- ping gateway.openfaas

如果ping不通，那就是网络的问题，比如K8s的命名空间隔离、网络插件的问题，这时候要检查K8s的网络配置，确保两个命名空间的Pod可以互相访问。

第三步，检查Prometheus的采集状态。Prometheus有专门的页面显示每个采集任务的状态，我们可以打开Prometheus的Web界面，找到Status下的Targets，然后找到openfaas这个任务，看看状态是不是UP。如果是DOWN，那页面上会显示具体的错误原因，比如“connection refused”就是端口不对，“context deadline exceeded”就是网络超时，根据错误原因调整就行。

3.2 异常二：OpenFaaS函数的监控数据有异常波动

这种情况是Prometheus能看到OpenFaaS的监控数据，但数据不对，比如函数的请求延迟突然飙高、请求量突然为0、实例数量异常等。我们以请求延迟飙高为例，详细说排查步骤：

首先，先确认Prometheus里的延迟指标是不是正确的。OpenFaaS的请求延迟指标是openfaas_function_duration_seconds，我们可以在Prometheus的查询界面输入这个指标，看看数据的波动情况。如果确实有突然的峰值，那再看峰值对应的时间点，同时检查这个时间点的其他指标，比如openfaas_function_requests_total（请求总量）、openfaas_function_instances（函数实例数量）。

然后，我们可以通过具体的函数日志来排查，比如有个叫“image-resize”的函数，延迟飙高，我们可以导出它的日志：

# 导出image-resize函数的日志，时间范围是最近1小时
kubectl -n openfaas-fn logs --since=1h -l function=image-resize

如果日志里有很多错误信息，比如“too many open files”、“connection timed out”，那就是函数本身的问题，比如函数代码有bug、依赖的外部服务（比如数据库、存储）出问题了。

如果日志里没有错误，那再看函数的资源配置，比如这个函数的CPU和内存限制是不是太低了：

# 查看image-resize函数的部署配置，看CPU和内存的限制
kubectl -n openfaas-fn describe deployment image-resize

如果配置里的CPU限制是100m（0.1核），而函数的实际CPU使用量经常达到这个限制，那就是资源不够导致的延迟，这时候要调高CPU和内存的限制。

3.3 异常三：OpenFaaS的监控数据延迟高

这种情况是Prometheus能拿到数据，但数据不是实时的，比如当前时间是10点，Prometheus里显示的最新数据是9点50分的，差了10分钟以上。

首先，检查Prometheus的采集间隔配置。之前我们提到过，Prometheus的采集间隔默认是15秒，如果这个间隔被改成了5分钟甚至更长，那数据自然会延迟。我们可以看之前导出的prometheus_config.yml里的scrape_interval，确保是15秒或者更短的时间。

然后，检查Prometheus的存储配置。如果Prometheus的存储不够，或者存储的IO性能差，那采集到的数据会被延迟写入，导致查询的时候看到的数据不新。我们可以检查Prometheus的存储使用情况：

# 查看Prometheus的存储卷使用情况
kubectl -n monitoring exec -it prometheus-0 -- df -h /prometheus

如果存储的使用率超过了80%，那说明存储不够，需要扩容存储，或者调整Prometheus的存储保留时间，减少旧数据的存储量。

另外，还要检查Prometheus的自身负载，如果Prometheus的CPU使用率太高，比如经常超过90%，那它处理采集任务的速度会变慢，也会导致数据延迟。我们可以用Prometheus的自身指标来查看它的CPU使用率：

# 在Prometheus的查询界面输入这个指标，查看它的CPU使用率
process_cpu_seconds_total{job="prometheus"}

如果CPU使用率太高，那需要给Prometheus分配更多的CPU资源，或者优化Prometheus的配置，减少不必要的采集任务。

四、应用场景、优缺点及注意事项

4.1 应用场景

这套排查方法主要适用于以下场景：

基于Kubernetes部署的OpenFaaS和Prometheus组合，这是目前最常见的部署方式；
生产环境的OpenFaaS函数监控异常，比如业务受影响、资源浪费等；
测试环境的OpenFaaS监控问题排查，比如开发新函数时需要确认监控数据是否正常；
新部署的OpenFaaS+Prometheus环境，需要验证监控数据是否正常。

4.2 技术优缺点

这套排查方法的优点很明显：

步骤清晰，从基础环境到具体异常，一步步来，不会乱；
基于K8s的命令行操作，不需要额外的工具，只要能访问K8s集群就能操作；
覆盖了大部分常见的异常情况，从完全没数据到数据波动、延迟，都有对应的排查步骤；
结合具体的示例和命令，容易上手，即使是新手也能跟着操作。

当然也有缺点：

只适用于K8s环境下的OpenFaaS和Prometheus，其他部署方式（比如直接在服务器上部署）不适用；
对于一些复杂的异常，比如Prometheus的内部错误、OpenFaaS的代码bug，这套方法只能定位到问题的大概方向，不能直接解决；
没有覆盖所有的异常情况，比如OpenFaaS的函数实例数量异常，需要根据具体情况调整排查步骤。

4.3 注意事项

在排查的时候，有几个点要特别注意：

操作前要备份配置，比如修改Prometheus的配置前，先把原来的配置备份下来，万一改坏了可以恢复；
不要在生产环境随意修改Prometheus的采集间隔，太短的间隔会增加Prometheus的负载，太长的间隔会导致数据不实时；
查看函数日志的时候，要注意时间范围，比如排查最近1小时的问题，就只看最近1小时的日志，不要看太久的日志，避免干扰；
排查网络问题的时候，要注意K8s的命名空间隔离，比如Prometheus在monitoring命名空间，OpenFaaS在openfaas命名空间，两个命名空间的Pod访问需要用完整的服务地址（比如gateway.openfaas.svc.cluster.local），如果用短地址（gateway.openfaas）可能会有问题。

五、文章总结

基于Prometheus的OpenFaaS监控数据异常的排查，核心是先确认基础环境，再根据具体的异常情况一步步定位问题。首先要保证OpenFaaS和Prometheus的Pod正常运行，然后确认Prometheus的采集配置正确，接着根据不同的异常（完全没数据、数据波动、数据延迟）分别排查：完全没数据要检查监控数据是否生成、网络连通性、采集状态；数据波动要检查函数日志、资源配置；数据延迟要检查采集间隔、存储、自身负载。

在排查的过程中，要结合具体的命令和示例，一步步来，不要跳步骤，这样才能快速定位问题。同时要注意备份配置、不要随意修改生产环境的配置、注意K8s的命名空间隔离这些注意事项，避免在排查的过程中引入新的问题。

最后，这套排查方法不仅适用于OpenFaaS和Prometheus，很多其他的服务和监控工具的组合，也可以参考这套思路，先确认基础环境，再根据异常情况一步步定位，本质上都是类似的逻辑。

基于Prometheus的OpenFaaS监控数据异常的排查方法

一、先搞懂为啥要排查异常

二、排查前的准备工作

2.1 确认基础环境状态

2.2 确认Prometheus的采集配置

三、常见异常的排查步骤

3.1 异常一：Prometheus完全没有OpenFaaS的监控数据

3.2 异常二：OpenFaaS函数的监控数据有异常波动

3.3 异常三：OpenFaaS的监控数据延迟高

四、应用场景、优缺点及注意事项

4.1 应用场景

4.2 技术优缺点

4.3 注意事项

五、文章总结

评论

关联文章

AI助手

一、先搞懂为啥要排查异常

二、排查前的准备工作

2.1 确认基础环境状态

2.2 确认Prometheus的采集配置

三、常见异常的排查步骤

3.1 异常一：Prometheus完全没有OpenFaaS的监控数据

3.2 异常二：OpenFaaS函数的监控数据有异常波动

3.3 异常三：OpenFaaS的监控数据延迟高

四、应用场景、优缺点及注意事项

4.1 应用场景

4.2 技术优缺点

4.3 注意事项

五、文章总结

同分类面试题

关联文章

AI助手