Python中Kong API网关在生产环境突然报错,如何排查错误日志找不到原因的问题?
不熟悉的组件真的有风险啊,生产环境上都运行了大半年了突然出错了。
日志截图如下,好像是因为没有找到可执行的 serf,这个东西是干嘛的?
之前都没问题的,求有经验的帮忙解答下
生产环境突然崩了也是没谁了。。。
多亏我启动了 nginx 还能继续用
但是我执行 kong health 显示 serf........not running,这个东东实在不知道是干嘛的
有没有同样遇到过这种问题的小伙伴?
不过平心而论这个 api gateway 确实不错
Python中Kong API网关在生产环境突然报错,如何排查错误日志找不到原因的问题?
serf 是个程序,日志说没找到你就给装上嘛。而且 serf 应该是你一开始用 kong 没有的话就会报错的,怎么会像你说的都上线大半年了才有这个错误。
遇到Kong网关生产环境报错但日志没明确原因的情况,我一般这样排查:
1. 先看Kong的基础状态
# 检查Kong进程状态
kong health
# 查看最近错误日志(最后50行)
tail -n 50 /usr/local/kong/logs/error.log
# 检查数据库连接
kong migrations status
2. 检查Nginx错误日志 Kong底层是Nginx,很多问题在这里:
# 查看Nginx错误日志
tail -f /usr/local/kong/logs/nginx-error.log
# 或者直接看access日志中的异常状态码
grep "50[0-9]" /usr/local/kong/logs/access.log | head -20
3. 数据库问题排查 如果是PostgreSQL后端:
import psycopg2
import json
def check_kong_db():
try:
conn = psycopg2.connect(
host="localhost",
database="kong",
user="kong",
password="your_password"
)
cur = conn.cursor()
# 检查关键表
cur.execute("SELECT COUNT(*) FROM routes")
routes_count = cur.fetchone()[0]
cur.execute("SELECT COUNT(*) FROM services")
services_count = cur.fetchone()[0]
print(f"Routes: {routes_count}, Services: {services_count}")
# 检查最近失败的请求
cur.execute("""
SELECT name, created_at
FROM plugins
WHERE created_at > NOW() - INTERVAL '1 hour'
ORDER BY created_at DESC LIMIT 5
""")
conn.close()
return True
except Exception as e:
print(f"Database error: {e}")
return False
4. 实时监控当前请求
# 查看实时请求(需要kong-debug插件)
curl -i http://localhost:8001/debug/requests
# 或者直接通过admin API检查
curl http://localhost:8001/status
5. 内存和连接检查
# 检查Kong内存使用
ps aux | grep nginx | grep -v grep
# 查看当前连接数
netstat -an | grep :8000 | wc -l
快速处理步骤:
- 先重启Kong:
kong restart - 检查配置文件:
kong check /path/to/kong.conf - 临时启用debug日志:
echo "log_level = debug" >> /etc/kong/kong.conf
kong restart
关键点: 生产环境问题优先检查数据库连接和内存溢出,这两类问题最常导致日志信息不全。
总结建议:先重启再查库,日志不全看Nginx。
备份数据,更新到最新版,最新的已经不再依赖 serf
以前启动的话都是自动安装了 serf,现在我是替换了下 handler.lua 配置文件,然后就起不来了
我知道,0.11.0+不再依赖 serf 了,可是多了好多 health 的状态字段,现在先不想升级,怕出问题
之前我们也考察过 kong,楼主最后解决了吗,怎么解决的。
既然你是来问问题的,就把前因后果描述清楚,在报错之前做了什么操作?
老中医还要问病情呢!上来就一句,人死了…
解决了,早上我又仔细看了下日志,是说没有找到 serf。然后我看了下 github 上 kong 对应的 0.10.0 版本的 pull request,发现上面说已经修复了 serf,说在启动的时候,已经将 serf 可执行文件放在 /usr/local/bin/serf 的已知路径中。当搜索 Serf 时,如果在配置文件中没有指定 serfpath,则将此路径添加为已知路径。
可是我启动时系统确实没有找到这个 PATH,然后做了个软连接,手工连接到了 /bin/serf 就好了
具体可以参考 github-kong 的 request: https://github.com/Kong/kong/pull/1997

