【必读】如何快速准确的获得 laf 社区帮助 - 案例分析？

maslow

说明

为了更好的为大家提供社区支持，及时有效的获得帮助，促进社区友好交流，特写这一篇，希望对大家有所帮助。

建议在社区论坛 / GitHub Issue 描述清楚问题，后可将该链接再发至群里获得更即时的帮助

为了更容易理解，我们直接通过案例分析：

案例一 ★☆☆☆☆

获得帮助效率： ★☆☆☆☆

除了提供个 Not Found 关键字，没有提供任何其它有效信息，我们知道排查问题是个成本很高的工作，也需要了解很全面的环境上下文信息，所以这种提问，除非是有非常热心又碰巧很闲的群友看到，才有可能被关注。

案例二 ★★★☆☆

获得帮助效率： ★★★☆☆

这个提问就要好很多，首先提供 kubectl get pods -A 命令的执行结果，可以知道集群中各服务都是就绪的，只有 laf-server 启动失败了，这个图的信息量也比较大，比如这个集群服务是 7 天前启动的，laf-server 是刚更新的等等。

上下文信息给的相对充分了，但是和错误点更具体的信息：laf-server 的日志、报错原因相关的信息，这会让人无从下手，需要追问几次才能获得此消息，沟通成本就急剧上升了。

新技能 GET:

kubectl get pod -n laf-system 可查看 laf 的相关服务 pod 的列表
kubectl describe pod laf-server-xxxx-xxxx -n laf-system 可查看指定 pod 的描述信息（可能包含出错原因）
kubectl logs -f laf-server-xxxx-xxxx -n laf-system 可查看指定 pod 的运行日志

（其中 laf-server-xxxx-xxxx 应该改成你实际的 pod 名称）

maslow

案例三 ★☆☆☆☆

获得帮助效率： ★☆☆☆☆

没有提供任何环境上下文信息，唯一的有效信息是 404 Route Not Found，不好下手，并且没有说明是访问 laf 页面报这个错误，还是访问创建的应用错误，不知道到了哪一步。
不过我们仍然可以通过这个有效信息做一些分析，以下借此分享分析思路：

在浏览器看到 404 Route Not Found 可间接获得以下信息：

集群部署大体是成功的，集群网络也是可访问的
网关是启动了的，这个错误是网关(Apisix）报出的
（很有可能是 apisix-ingress-controller 还没有就绪，可进一步查看 apisix 相关的服务健康状态）

可通过 kubectl get pods -A 提供集群内所有 pod 状态的列表，以便指导下一步。

maslow

案例四 ★★★★☆

获得帮助效率： ★★★★☆

该同学提问虽简短，但提供的有效信息十分精准，这是 laf-server 报错具体日志，从日志可看出，就是缺少 METERING_DATABASE_URL 环境变量，我只是扫一眼秒懂他的问题，顺手就回复他了。