atop 是一款開源的單機性能監測工具，支持實時觀測的同時、也支持讀取歷史文件排查問題。另外一個優點是除提供 CPU、MEM、DISK 等全局指標外，還提供進程、線程級別的各項指標監控數據。鑒于 atop 的這些優點，字節跳動基于社區的 atop 進行優化，目前已迭代 3 個版本，穩定運行接近三年。本文將和大家分享字節跳動內部 atop 工具的新特性及使用情況。
atop 本身是一個單機性能監測工具，每間隔 interval（實時監控默認間隔是 10s，而后臺采集社區默認間隔是 600s，即 10min）時間去采集本機常用的全局指標和進程指標。直接執行atop即可展示，大致分為上下兩部分，分別展示全局指標和進程指標。同時支持快捷鍵切換多種“界面模式”，用于專門查看進程的 CPU、內存、磁盤等指標信息。
運行方式
根據用戶使用需求，能夠以多種形式運行。一種是直接運行 atop 二進制，顯示實時數據；一種是以服務形式（systemd 或 SysV Init）部署在物理機、虛擬機或容器里，作為常駐進程，采集數據寫入磁盤，以天為分割單位計入不同文件；一種是使用atop -r $atop_log_file按需讀取歷史數據。是一款少見的能夠支持查看詳細歷史記錄的工具，這在定位非實時問題時尤其有幫助。
atop 記錄了很多指標，如全局的 CPU、CPL、MEM、DISK、NET、PSI，進程的 PID、PPID、TID、CMD、SYSCPU、USRCPU、CPUNR、RSIZE、PSIZE、RDDSK、WRDSK 等，稱得上一個大而全的工具。而 atop 本身占有資源很少，并不會帶來額外的性能開銷。因此很多場景都可以使用 atop 來查看各種指標，進而幫助用戶更好的了解業務進程在操作系統中的呈現。舉例如下：
目前上游還不支持 atop 指標在集群粒度的聚合，但字節內部提供 JSON 數據的輸出，可通過數據處理一系列流程將隸屬同一集群的所有機器的 atop 數據都入庫存儲（可選擇性按時間對數據進行稀釋）。并按照業務需求加以展示，如分別對全局常用指標和某類業務（多進程 PID 加以聚合）各項指標繪制成曲線圖，用于觀測 24h 時間周期內的數據變化；也可以用于統計基礎服務的利用率。
在線排查
業務高峰期，如果發現抖動，可直接運行atop綜合查看全局指標和進程指標的哪項指標異常，進而定位排查問題。一般來說先觀察全局指標來縮小范圍，看是 CPU、MEM、磁盤讀寫、網絡中的哪項引發的問題。常見問題有，如果總 CPU 的 sys 態及 user 態飆高、并且只有幾個單 CPU 核很高，多半是綁核不均勻引起的；如果 CPL（CPU Load Average）不高但 CPU 的中斷 irq 很高，多半是 IO 操作引發的。
歷史定位
前文提到過，常用的監控工具中，能夠提供詳細歷史數據并且能高效保存的幾乎沒有；如果需要存儲，需要人工干預、打通整個流程。而 atop 本身提供了日志存儲功能，并自帶日志壓縮機制，盡量確保存儲無壓力。為保證歷史日志不會將系統盤打滿，字節開發了定制化存儲位置和存儲天數的功能，將在下文詳細說明。
功能上線
atop 有個 interval 參數，可通過配置，來定制化數據采集的間隔，如 10s、甚至 1s。如果業務有新功能上線，想自測新功能對系統帶來的影響，可以將 interval 設置成 1 秒，實時觀測各指標的動態變化。
性能優化
atop 提供細粒度的進程態各項指標值的展示，在業務調優過程中，可參考進程態的數據變化來衡量調優是否符合預期。
告警輔助
atop 的數據比較全，有很多其他監控工具不具備的指標，如 oom-kill、per NUMA 指標等?？捎糜诟婢瘮祿碓吹难a充。
atop 針對全局指標和進程指標分別提供了很多快捷鍵，供用戶查看更多的指標。接下來列舉一些常見問題，詳細參數可以通過man atop進行查看。
用戶可直接運行 atop 命令查看實時的信息，也可以通過 atop -r /var/log/atop/atop_$date 文件查看歷史信息。讀取文件時有多種交互方式，比如-b 代表從什么時刻開始讀，-e 代表讀取到什么時刻（在社區支持分鐘級別讀取的基礎上，字節內部支持秒級別讀取）。快捷鍵說明如下圖：
快捷鍵說明b輸入時間，格式為"12:23"（時：分）t前進 10sT后退 10sg按 CPU 使用率排序，默認排序方式m按內存使用率降序排列d按磁盤使用率降序排列y查看線程信息j查看 container 聚合信息c查看詳細的 command linel定制化查看每個 CPU 核/每個磁盤/每個網卡的信息f展示全局指標中 fixed 的指標Q根據進程狀態過濾，如 R|S|D|Z 等I按照 PID 進行搜索（注：大寫的 i）
可以，默認有讀權限。但是安裝包、重啟服務、修改日志存儲天數等還是需要 root 權限。但非 root 用戶按 d 無權限實時查看進程的磁盤信息。這是因為非 root 用戶默認被禁止讀取其他用戶的/proc/$pid/io 文件，反映到 atop 代碼里就是沒有設置相關標志位，導致無法查看磁盤。
但查看歷史文件數據可以打消這個魔咒，也就是說非 root 用戶可以通過atop -r /var/log/atop/atop_$date 查看磁盤相關數據，畢竟 atop 寫日志時是以 root 用戶在運行。
默認只有進程信息展示，按 y 可查看線程。如下圖，白色為進程，黃色為該進程的所有線程。再次按 y，線程展示消失。
進程態網絡相關的指標是通過定制化安裝 netatop kernel module 完成的。本質上是通過 netfilter hook 獲取進程數據，額外有個 netatopd daemon 負責數據記錄及壓縮。在數據量比較大的場景，會影響到性能，因此默認不開啟該功能。如果開啟，可以按 n 查看 per 進程的網絡指標。
隨著云原生場景的推進，各云廠商正嘗試將不同特征的業務（如優先級不同、延遲敏感度不同的多個業務）混部在同一臺物理機上，盡量充分地將機器的物理資源利用起來，以提高單機的資源利用率。常見的混部場景有在離線混部，而常用的混部手法是將不同業務綁定不同 NUMA，從物理上達到隔離。那么查看 NUMA 粒度而不是整機粒度的 CPU、MEM 等指標則更有意義?；谶@迫切的需求，字節內部實現了 NUMA 的監控粒度，相關代碼已被社區接收，展示效果如下：
https://github.com/Atoptool/atop/pull/163
例：一臺 4NUMA 的機器，其 NUM（Memory per NUMA）展示如下圖
例：如上圖 NUM 的 frag 字段。
例：一臺 4NUMA，運行了虛擬機的 arm 機器上，其 NUC（CPU per NUMA）展示如下圖
前文提到過，目前社區不支持 atop 指標在集群粒度的聚合；除此之外，atop 作為一個單機工具，如果業務想查看某臺服務器的監控，需要申請權限登錄到機器上，這在某些場景下比較受限。因此想到有沒有一種方式，針對擁有某個集群機器權限的同學來說，可以直接查看該集群內所有機器的 atop 數據，而無需再走工單申請單臺機器權限，即網頁版 atop。
考慮到數據處理過程中 JSON 數據的強兼容性，敲定將 atop 的原始數據以 JSON 數據輸出：支持輸出到終端，以及寫本地 unix domain socket。針對前者，主要是用于本機的一些數據調試，也可以與其他組件打通，如數據報警等。針對本地 UDS，atop 作為 server 端，提供一種數據輸出的能力；另外需要引入 client 端、監聽并獲取 atop 數據，同時作為數據源端、與數據處理打通、將本機 atop 數據流過數據通路落入數據庫，供業務方使用。整體流程如下：
用法如下：
Currently we support three types of output:
1. atop -O stdio
2. atop -O only
3. atop -O unixsock -w /path/to/file 10 //Make unixsock non-block to make sure this will not block main engine. And if the unix remote server re-launches, atop will re-connect and continue to work.
Usage examples:
./atop
./atop -P ALL
./atop -O only // overwrite parseout, show json to stdio only
./atop -O stdio -P ALL // both parseout and json stdio
./atop -O stdio -w atop.log // print to stdio, as well as file
./atop -O unixsock // overwrite parseout, show json to unixsock
./atop -O unixsock -P ALL // both parseout and json unixsock
./atop -O unixsock -w atop.log // write json to unixsock and file
And the detail JSON output format is as follows:
{
"ip": "a.b.c.d",
"timestamp": 1565256314,
"CPU": {
"hertz": 100,
...
"cpu_nums": 40
},
"cpu": [
{
"hertz": 100,
...
"cpu_id": 0
},
...
{
"hertz": 100,
...
"cpu_id": 39
}
],
...
"PRC": [
{
"pid": 1,
"p_name": "(systemd)"
},
...
{
"pid": 73,
"p_name": "(migration/12)"
}
]
}雖然 atop 的指標很全，且有歷史記錄可以查詢，但依舊有不少聲音提到 atop 做的還有欠缺。比如無法將所有 CPU 的使用情況同時展示，即使將顯示器橫過來也不能解決，這在高達 128 核的物理機上尤其頭痛。為解決這個痛點，參考類似 htop 的展示方式，結合 atop 本身代碼，從零開始用 ncurses 加以繪制，展示效果如下。目前只支持 CPU 和 MEM 的展示，如有其他需求，歡迎聯系我們。
支持類似 htop 直觀的展示所有 CPU 和內存的使用情況，但新增 NUMA 粒度的支持。一是解決因 CPU 核數太多展示不全的問題；進一步可以縱覽所有 CPU 的負載，直觀判斷綁核是否有問題
//注：上面兩張圖為壓測場景
user態：stress -c 20
sys態：iperf -s -i 1 && iperf -c $ip -i 6 -t 600
//numactl -H的結果如下前面提到，atop 支持歷史日志的記錄，這在定位排查非實時問題時非常有幫助。然而在字節內部，曾因 atop 日志過大引發過比較嚴重的問題。起因是 atop 默認會將日志寫到/var/log/atop 目錄下，并且記錄所有的進程、線程信息到日志里。有些業務服務器（如 Java 業務）動輒每 10 秒幾萬個線程，一天的日志量高達幾 G，7 天高達幾十 G，如果服務器本身的系統盤存儲空間很緊張，就會造成系統盤打滿、登錄不上機器的嚴重后果。
為解決日志相關的問題，字節內部在新版本中推出了以下特性：
根據日常排查問題來看，一般只關心 topM 的進程或每個進程的 topN 線程。觀察每個進程，通常超過 top100 線程的 CPU 或 MEM 都處于不活躍狀態，對于排查問題來說意義不大，沒必要記錄到日志。據此字節內部引入-H 參數，通過指定-H 100 可以過濾掉 top100（按照 CPU/MEM/DISK 比例之和倒敘排列）之外的線程，大大減少了日志存儲量，尤其適用于線程數目多達幾千或幾萬的 Java 業務場景。
引用上游最新的 atop-rotate.timer 和 atop-rotate.service，取代之前的 cronjob。避免某些機器修改時區后未重啟 cron.service，導致 cron 服務重啟時間未遵守本機時間，寫 atop 日志時間出錯。
上游默認存儲天數為 30 天，在實際排查問題時必要性不大，反而浪費了系統盤的存儲空間。如有需要，可以通過 atop-json 機制將本機日志傳輸到統一的存儲池子中，采取數據稀釋的方式（如保留 topM 進程、按時間順序增大記錄間隔等）進行保存。字節內部在 atoprc 中引入generations變量，表示存儲天數為generations+2天。
例：echo 'generations 1' >> /etc/atoprc && systemctl restart atop代表只保留存儲最近 3 天的日志
有些服務器雖然系統盤存儲空間小，但數據盤有多塊，容量高達幾 T，針對這種場景，用戶可以通過修改 atop 日志存儲位置，來緩解存儲壓力。字節內部在 atoprc 中引入 logpath 變量，標識日志存儲目錄。
例：echo 'logpath /data00/log/atop' >> /etc/atoprc && systemctl restart atop將日志存儲到/data00/log/atop目錄下
到目前為止，字節已穩定運行接近三年，覆蓋公司全量服務器，推出 3 個版本。
字節內部目前在用代碼已 push 到相關分支，歡迎使用：
相關 repo 請訪問：
其中 master 分支緊跟社區 atop 的 master 分支，其余分支是一些已推社區但尚未被合入的特性或 bug fix（如 Fix atop stuck when reading offline css 雖然本質上是內核的 bug，但可以通過修改 atop 代碼加以規避，避免重啟服務器）。
新版本 atop 的部分特性已經推社區并被上游接收，接下來還會將其余特性繼續推上游，更好的回饋社區。
關于字節跳動系統部 STE 團隊：
字節跳動系統部 STE 團隊 (STE=System Technologies & Engineering，系統技術與工程) 一直致力于操作系統內核與虛擬化、系統基礎軟件與基礎庫的構建和性能優化、超大規模數據中心的系統穩定性和可靠性建設、新硬件與軟件的協同設計等基礎技術領域的研發與工程化落地，具備全面的基礎軟件工程能力，為字節上層業務保駕護航。同時，團隊積極關注社區技術動向，擁抱開源和標準。
更多招聘信息，可郵件聯系 chenziying@bytedance.com 獲取。
Windows 11 安卓子系統 (Windows Subsystem for Android) 包括 Linux 內核和基于 Android 開源項目（AOSP）版本的 Android 操作系統。該子系統在 Hyper-V 虛擬機中運行，就像 Linux 子系統一樣，可以將 AOSP 環境中 App 的運行時和 API 映射到 Windows 圖形層、內存緩沖區、輸入模式、物理和虛擬設備以及傳感器，可以在英特爾、AMD、高通的 CPU 上運行。
官方中文名稱：適用于 Android 的 Windows 子系統
英文名稱：Windows Subsystem for Android
習慣叫法：Windows11/Win11 安卓子系統
英文簡稱：WSA
安卓子系統本身有硬件要求，如果硬件配置較低，運行可能會出現卡頓、甚至無法運行，所以微軟也公布了相關文檔。
以下是基礎要求：
1、內存方面：PC至少有8GB內存才可以下載安裝安卓子系統，微軟推薦16GB內存以獲得最佳體驗
2、存儲方面：Windows 11系統盤必須是固態硬盤才可以安裝安卓子系統，如果是機械盤則不滿足條件
3、處理器方面：滿足Windows 11處理器要求，最低為英特爾第8代酷睿i3+、AMD Ryzen 3000+、高通驍龍8c+
4、處理器類型：x64或ARM64架構，不支持32位處理器，當然Windows 11也沒有32位版
5、虛擬化平臺：需開啟虛擬化支持，虛擬化通常在BIOS里開啟，例如Intel VT虛擬化平臺
滿足條件后如何安裝？
一、獲取安裝
1、這第一步，當然是把Windows 11系統更新到比較新的版本，比如：Win11 22H2；
2、修改國家或地區為美國，這樣做的目的是由于微軟采用分批推送WSA的策略，暫時還不包括中國；
設置 > 時間和語言 > 語言和區域，區域設置為美國
3、打開 Microsoft Store (微軟商店) 搜索 Amazon Appstore，點擊安裝，然后按提示往下操作即可；
4、重啟電腦，進入桌面后，Windows Subsystem for Android 就自動打開了；
然后就進入亞馬遜應用商店登錄界面，有亞馬遜賬戶的用戶，可以選擇登錄進去看看。
不過，在測試的過程中，也發現了進入桌面后，不能自動打開 Windows Subsystem for Android 的情況。這時候，我們可以使用Windows 搜索，找到適用于 Android 的 Windows 子系統設置。
5、第一次使用，打開文件，以測試能否正常運行；
如果能夠直接打開 Android 的文件管理器，那么恭喜你，可以直接運行，如果不能啟動，甚至不能下載安裝，后面還有解決方法。
二、安裝應用
1、打開 WSA 的開發人員模式，確保出現 127.0.0.1:58526 這個本地 IP 及端口；
2、我們可以使用第三方工具，比如WSA工具箱安裝安卓APP；
PS：說到這里，我覺得肯定會有用戶問，為什么不使用ADB命令安裝apk文件呢？是因為命令對于大部分的用戶來說，操作起來較為困難，所以選擇直接通過一些第三方的工具安裝安卓APP會更簡單方便。當然，感興趣的用戶可以了解一下使用ADB命令安裝apk文件的方法。
如果覺得以上步驟操作起來比較麻煩，也可以試試360手機助手推出的Win11安卓助手。360 Win11安卓助手 WsaTool 是一款綠色軟件，無需安裝，也不修改注冊表，殺毒軟件和防火墻也不用關。軟件界面非常簡潔，左邊是連接配置、已裝應用和關于三個選項，右邊是詳細的內容。
WSA無法啟動解決方法
1、無法啟動適用于 Android 的Windows 子系統
1）確保在可選的 Windows 功能中啟用虛擬機平臺
2）確保設備在 bios 中啟用了虛擬化
3）如果正在虛擬機中運行適用于 Android 的Windows 子系統，確保已為主機上的虛擬機啟用嵌套虛擬化
一般情況下，沒有開啟虛擬機平臺和虛擬化，就會彈出這樣的提示。
1）開啟虛擬機平臺
打開控制面板 > 程序 > 啟用或關閉 Windows 功能，勾選虛擬機平臺，確定、重啟電腦即可。
2）BIOS 虛擬化
任務管理器里可以查看是否已啟用虛擬化。
如果已禁用，在主板 BIOS 中啟用虛擬化，一般 Intel 平臺叫 Intel VT ，AMD 平臺叫做 SVM ，而部分 AMD 平臺還需要開啟 NX Mode 。
如果還是無法運行，管理員身份運行Windows PowerShell ，執行以下命令并重啟電腦。
bcdedit /set hypervisorlaunchtype auto
Windows11 – 安卓子系統特色
1）支持將安卓 App 固定到開始菜單或任務欄，并通過鼠標、觸摸或筆輸入與它們交互
2）安卓 App 可集成到 Alt + Tab 和任務視圖中，并能在 App 之間快速切換
3）可在操作中心中查看安卓 App 的推送通知，或在 Windows 應用程序和安卓 App 之間共享剪貼板
4）微軟還添加了無障礙體驗，許多 Windows 輔助功能設置都適用于安卓 App
如果你也想在Win11系統中體驗安卓應用，可以按照上述的方法去安裝適用于 Android 的 Windows 子系統。