为解决因容器引擎层的不透明性而导致的故障排查困难问题，阿里云容器服务 Kubernetes 版 ACK（Container Service for Kubernetes）团队推出操作系统内核层的容器监控可观测能力，为您提供更可靠、透明的容器引擎层，助力您更顺利地进行容器化迁移。本文介绍如何使用SysOM定位容器内存问题。
前提条件
已创建ACK托管集群或自2021年10月以后新建的ACK Serverless集群，并确保集群版本为1.18.8及以上。关于创建集群的具体操作，请参见创建ACK托管版集群、创建ACK Serverless集群。如需升级集群，请参见手动升级集群。
已开启阿里云Prometheus监控。具体操作，请参见阿里云Prometheus监控。
已开启ack-sysom-monitor监控功能。具体操作，请参见开启ack-sysom-monitor监控功能。
ack-sysom-monitor监控功能费用说明
启用ack-sysom-monitor监控功能后，相关组件会自动将监控指标发送至阿里云Prometheus服务，这些指标将被视为自定义指标。使用自定义指标会引起额外的费用。
为避免产生额外的费用，建议在启用此功能前，仔细阅读阿里云Prometheus的计费概述，了解自定义指标的收费策略。费用将根据您的集群规模和应用数量等因素产生变动。您可以通过资源消耗统计功能，监控和管理您的资源使用情况。
场景描述
容器化已经成为许多企业构建IT架构的最佳实践，因为它能够带来降低成本、提高效率的优点，并提供更大的灵活性和可扩展性。
但容器化在一定程度上引入了容器引擎层的不透明性，带来OOM（Out of Memory）等问题。可能会导致内存占用过高，甚至超出容器的内存限制，从而触发OOM问题。
为解决以上问题，阿里云容器服务 Kubernetes 版 ACK（Container Service for Kubernetes）团队与阿里云GuestOS操作系统团队合作，为您提供操作系统内核层的容器监控可观测能力，制性，从而更好地管理和优化容器的内存使用，避免因内存黑洞问题引起的OOM问题。
容器内存组成
容器的内存由应用程序内存、内核内存和空闲内存组成。
内存大类 | 内存小类 | 说明 |
应用程序内存（Application Memory） | 应用程序内存由以下几个部分组成：
| 应用程序运行时所使用的内存。 |
内核内存（Kernel Memory） | 内核内存由以下几个部分组成：
| 操作系统内核使用的内存。 |
空闲内存（Free Memory） | 不涉及。 | 未被使用的可用内存。 |
实现原理
Kubernetes采用内存工作集（Workingset）来监控和管理容器的内存使用。当容器内存使用量超过了设置的内存限制或者节点出现内存压力时，Kubernetes会根据Workingset来决定是否驱逐或者杀死容器。通过SysOM监控来排查Pod Workingset高的问题，可以提供更全面、精确的内存监控和分析能力，帮助运维和开发人员快速定位和解决Workingset过高的问题，从而提高容器的性能和稳定性。
其中，内存工作集（Workingset）是指在一定时间范围内，容器实际正在使用的内存部分，即容器当前运行所需的内存。Workingset = InactiveAnon + ActiveAnon + ActiveFile。其中，InactiveAnon和ActiveAnon是程序匿名内存总大小，ActiveFile是应用程序活跃文件缓存的大小。
使用SysOM功能
基于阿里云SysOM提供的操作系统内核层Pod、Node维度监控大盘，您可以实时监控内存、网络、存储等的系统层指标。SysOM功能的详细指标信息，请参见SysOM内核层容器监控。
登录容器服务管理控制台，在左侧导航栏选择集群。
在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择。
在Prometheus 监控页面，单击其他页签，然后单击ACK Sysom Pod Kernel Resource Monitor页签，查看监控大盘的Pod内存数据。
根据计算公式Workingset = InactiveAnon + ActiveAnon + ActiveFile，分析如何定位内存黑洞问题。
在Pod内存分布区域，SysOM提供Pod维度的操作系统内核层内存的成分监控。根据Workingset计算公式，在圆饼图中比较inactive_anon、active_anon和active_file三种类型内存的大小，找到占比最大的内存类型。
如下图所示，inactive_anon内存大小占比最大。
在Pod Resource Analysis区域，通过Top工具快速定位集群中InactiveAnon内存消耗最大的Pod。
如下图所示，arms-prom的内存消耗最大。
在Pod内存详情区域，查看Pod的详细内存组成。通过Pod Cache（缓存内存）、InactiveFile（非活跃文件内存占用）、InactiveAnon（非活跃匿名内存占用）、Dirty Memory（系统脏内存占用）等不同内存成分的监控展示，发现常见的Pod内存黑洞问题。
在Pod File Cache区域，查看产生较大缓存内存的原因。
若Pod的内存缓存较大，可能导致Pod工作内存占用升高，这部分缓存的内存会成为Pod工作内存的黑洞，最终影响Pod所在的业务体验。
修复内存黑洞问题。
通过观测发现容器内存黑洞问题，即可通过ACK精细化调度功能进行闭环修复。具体操作，请参见启用容器内存QoS。
相关文档
关于SysOM功能的详细指标信息，请参见SysOM内核层容器监控。
关于ACK容器内存QoS启用的内核能力，请参见内核功能与接口概述。