【发布时间】:2018-08-10 19:04:19
【问题描述】:
在通过 Kubernetes 部署基于 Ruby 的Passenger 独立应用程序时,我们
遇到了失去通过以下方式监控它们的能力的问题
passenger-status。有一个telegraf
plugin
或 passenger exporter 转发指标,这些指标需要访问
passenger-status 二进制。
遵循每个容器拥有一个(主)进程的理念,使用
用于收集指标的 Sidecar 容器在部署到时是合理的
Kubernetes。从另一个容器访问passenger-status 的输出是这里的挑战。将文件链接到另一个容器是not supported。为容器和复制可执行文件设置目录似乎过于复杂。
一个 Pod 中的容器之间的通信是通过环回网络进行的。因此,通过 HTTP 公开指标是导出这些指标的常见模式。因此,我们正在研究通过 HTTP 公开 passenger-status 指标的不同方式:
通过应用程序
通过 Kernel#` 运行命令有点违背了监视它的目的。只有当有足够的乘客进程可以免费回答此请求时,才会返回。一旦乘客队列满了,监控也将不再起作用,这正是我们希望在这里看到的。
CGI 脚本
由于 nginx 只支持 FastCGI,因此必须有类似 fcgiwrap 的东西来执行脚本。 fciwrap 本身需要运行另一个进程,它本身需要监控。此外,它违反了每个容器有一个进程的想法。
Lua 脚本
这样的 lua sn-p 可能会起作用:
location /passenger-status {
content_by_lua_block {
os.execute("/opt/ruby/bin/passenger-status")
}
}
然而,仅仅为此目的将 Lua 脚本添加到每个生产容器中似乎是在用大锤敲碎核桃。
第二个乘客实例
使用第二个小型 ruby 脚本作为监控的乘客端点也可能有效:
http {
...
server {
listen 80;
server_name _;
root /app;
passenger_enabled on;
...
}
server {
listen 8080;
server_name _;
root /monitoring;
passenger_enabled on;
...
}
...
}
总而言之,我认为这些方法中的任何一种都不能令人满意。您对此主题有何想法或解决方案?
【问题讨论】:
标签: nginx kubernetes passenger