使用new relic监控Azure Kubernetes集群中的应用程序
需求-对作为kubernetes集群一部分在pods中运行的应用程序进行新的Relic监控。
我已经在我的集群上安装了Kube-state-metrics，并且能够使用新的见解查看kubernetes仪表板。
此外，还需要为其配置应用程序监控。下列的https://blog.newrelic.com/2017/11/27/monitoring-application-performance-in-kubernetes/同样的。
有一些同样的问题-
>
这是否可以使用kube州指标实现？
我是否需要为每个包含许可证密钥的pod提供单独的yaml文件？
我是否也需要在应用程序中进行更改，或者在规范中添加信息也可以？
我是否需要在每个pod中安装Java代理？如果是，它会消耗资源吗？
不知何故，应用程序监控的安装变得越来越复杂。请解释安装的确切要求
共有1个答案
您没有提到您的堆栈，您应该按照他们网站上的说明了解您的语言。通常，您只需拉入他们的代理库并配置凭据即可开始。您不应该有理由区分您的pod，因此所有pod的代理凭据都应该相同
在架构体系中安装代理可以让您获得架构体系数据。因此，如果您运行内存溢出/空间/cpu等，您会收到警报。基础设施代理不可能知道应用程序数据。如果您想要应用程序性能数据（apm），您也需要在应用程序级别安装代理，如果它是Web服务器，您将获得超文本传输协议请求率、错误率和响应时间等数据。您还可以使用所有特定于应用程序的数据来注释当前事务。他们有很多客户端代理，看看是否有一个适合您的堆栈。例如，您需要的nodejs服务只是应用程序和配置顶部的要求（'newrelic'）
-
Kubernetes 使得管理复杂环境变得更简单，但是对 kubernetes 本身的各种组件还有运行在 kubernetes 集群上的各种应用程序做到很好的洞察就很难了。Kubernetes 本身对应用程序的做了很多抽象，在生产环境下对这些不同的抽象组件的健康就是迫在眉睫的事情。 我们在安装 kubernetes 集群的时候，默认安装了 kubernetes 官方提供的 heapster 插件，
-
在前面的安装heapster插件章节，我们已经谈到Kubernetes本身提供了监控插件作为集群和容器监控的选择，但是在实际使用中，因为种种原因，再考虑到跟我们自身的监控系统集成，我们准备重新造轮子。 针对kubernetes集群和应用的监控，相较于传统的虚拟机和物理机的监控有很多不同，因此对于传统监控需要有很多改造的地方，需要关注以下三个方面： Kubernetes集群本身的监控，主要是kube
-
上一节我们和大家介绍了Prometheus的数据指标是通过一个公开的 HTTP(S) 数据接口获取到的，我们不需要单独安装监控的 agent，只需要暴露一个 metrics 接口，Prometheus 就会定期去拉取数据；对于一些普通的 HTTP 服务，我们完全可以直接重用这个服务，添加一个/metrics接口暴露给 Prometheus；而且获取到的指标数据格式是非常易懂的，不需要太高的学习成本
-
集群监控的本质是一个聚合功能。 单台机器的监控指标难以反应整个集群的情况，我们需要把整个集群的机器（体现为某个HostGroup下的机器）综合起来看。比如所有机器的qps加和才是整个集群的qps，所有机器的request_fail数量 ÷ 所有机器的request_total数量=整个集群的请求失败率。 我们计算出集群的某个整体指标之后，也会有“查看该指标的历史趋势图” “为该指标配置报警” 这种
-
我们使用 Giantswarm 开源的 kubernetes-promethues 来监控 kubernetes 集群，所有的 YAML 文件可以在 ../manifests/prometheus 目录下找到。 需要用到的镜像有： harbor-001.jimmysong.io/library/prometheus-alertmanager:v0.7.1 harbor-001.jimmysong.
-
集群运行起来后，你可以用 ceph 工具来监控，典型的监控包括检查 OSD 状态、监视器状态、归置组状态和元数据服务器状态。 交互模式 要在交互模式下运行 ceph ，不要带参数运行 ceph ，例如： ceph ceph> health ceph> status ceph> quorum_status ceph> mon_status 检查集群健康状况 启动集群后、读写数据前，先检查下集群的健