為解決因容器引擎層的不透明性而導致的故障排查困難問題，阿里雲Container Service for Kubernetes (ACK)團隊推出作業系統核心層的容器監控可觀測能力，為您提供更可靠、透明的容器引擎層，助力您更順利地進行容器化遷移。本文介紹如何使用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問題。
為解決以上問題，阿里雲Container Service for Kubernetes (ACK)團隊與阿里雲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核心層容器監控。
登入Container Service管理主控台，在左側導覽列選擇叢集。
在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇。
在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啟用的核心能力，請參見核心功能與介面概述。