开发同学在开发代码时也经常会有写多余的 console.log、没有注释、变量重复声明等代码不规范的问题，为了解决这些问题，提供了 ESLint、JSLint 等工具来保障代码规范的统一。
在K8S集群中，CPU以及内存资源定义包含在Pod内，用户无法从K8S直接管理。PVC/PV模式解耦了存储资源与节点资源。
除了HTTP方式，还可以通过TCP Socket是否联通成功判定应用服务运行状态。
这种来自K8S而不是应用服务内部的应用运行状态判定逻辑，使得K8S能够掌握应用服务级别的健康状态。
当负载过大时，即使容器进程一直处于健康状态，仍有可能出现该应用服务无法正常提供服务。这种情况，K8S是通过readinessProbe进行检测的。
System-Reserved为节点的操作系统后台进程预留资源，例如sshd, udev等
在上文介绍工作负载时，我们提到可以通过requests和limits来确定容器运行资源消耗的用量和额度。因为节点资源并不能全部用来做资源调度，建议在定义Pod模版时，最好对容器的resources->requests和resources->limits都做明确的定义，以防止工作负载与K8S组件竞争资源导致调度失败。
这种金字塔型的资源分配方式存在着不小的资源碎片的情况。当工作负载竞争资源时，K8S提供了三种级别的服务质量保证。
Best-Effort：Pod不设置requests和limits。这种Pod的QOS优先级最低，当节点资源调度不足或者竞争冲突时，优先销毁或迁移该类Pod。
Guaranteed：Pod设置requests和limits，且requests 等于limits。这种Pod具有最高的资源保证。QOS级别高于Burstable和Best-Effort。所以，建议在定义应用服务的Pod模版时，对于容器资源保证，服务质量要求高的Pod，尽量配置合适的requests和limits。
人工智能机器人是一种可以做出类似人类决策的软件。这些机器人具有获取输入和输出行为的能力，这些行为看起来像人类定期完成的任务。人工智能技术带来了巨大的发现，它正在推动数字世界的发展。
微服务技术让IT系统变得更敏捷、更健壮、更高性能的同时，也给带来了架构复杂度的提升，给应用监控带来了前所未有的挑战。在微服务时代，由于服务的拆分，单个用户请求会经过多个微服务应用，形成复杂的调用链路，使传统的依赖于单机业务日志的监控手段无从下手，这就需要建立全新的监控机制，帮助开发者全面洞察系统运行状态，并在系统遇到异常的时候快速的定位和解决问题。
2 . 功能简单：对主流底层框架的全面支持，丰富的UI界面，完善的诊断机制和报警机制，这些都是一套优秀的全链路监控方案所必备的特质。开源方案在这些方面很难做到尽善尽美。
