我正在研究用于监视我们在Swisscom的云代工厂中安装的选项。我的目标如下:
到目前为止,我了解以下选项(包括某些BUT):
这对于跟踪/临时监视非常有用,但对于认真的基础结构监视却不是很好。
据我所知,它可以作为应用程序部署,以与TOP cf插件类似的方式完成工作。
问题是,它需要注册的客户端,因此可以通过多普勒端点进行身份验证。出于某种原因,top-cf-plugin会自动/以另一种方式执行此操作。
例如,可以使用Datadog完成。但这似乎还需要专门的uaa客户来注册Nozzle。
我想检查一下,如果有人在类似的道路上,是否有一些发现。
最终,我想向swisscom社区支持提出以下问题:
答案 0 :(得分:2)
由于它需要管理员权限,因此我们无法为Firehose分发UAA客户端。 但是,有多种方法可以获取用户上下文中的指标。
CF API
您可以通过轮询CF API来获取特定应用的基本指标: https://apidocs.cloudfoundry.org/5.0.0/apps/get_detailed_stats_for_a_started_app.html
但是,由于您必须轮询(针对每个应用),因此不建议这样做。
系统日志消耗中的指标
CF允许开发人员将其日志转发到系统日志流失;在最新版本中,CF还向该系统日志消耗发送指标(请参见https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html#container-metrics)。 例如,您可以使用Swisscom的Elasticsearch服务存储这些指标,然后使用Kibana对其进行分析。
使用loggregator(firehose)的指标
firehose允许流日志流到客户端,以提供两种角色:
将 all 日志流式传输给管理员(需要具有管理员权限的UAA客户端),并将 app 日志和度量标准流式传输给具有应用程序空间权限的开发人员。这也是cf logs
命令所使用的。 cf top
也以这种方式工作(it enumerates all apps and streams the logs of each app).
但是,您会发现大多数利用firehose的开源工具仅在admin模式下工作,因为它们是为平台操作员编写的。
当然,您也可以通过检测它(白盒方法)来监视您的应用程序,例如,通过在Spring引导应用程序中配置Spring执行器或包括您最喜欢的APM供应商(Dynatrace,AppDynamics等)的代理。 ..)
我猜这是最常见的方法;我们已经看到许多团队通过对应用程序进行测试而取得了成功。尤其是由于高级监控无论如何都需要您创建自己的指标,因为Firehose提供的cpu /内存指标在微服务领域并不那么强大。
但是,选项2也值得一试,特别是因为ELK的堆栈度量支持越来越好。