我們某台Docker Host不斷發出CPU Alert，也就是CPU長時間不斷在高百分比情況。關於執行中的容器，我們可以使用docker stats觀察容器的CPU、RAM、I/O等整體狀態。雖然有幾秒會突然有某個容器衝高CPU的情況，但在某個AP容器被呼叫的情況，且只有短短幾秒，看起來合情合理。但如上圖，為何dockerd.exe的CPU一直持續在某個高點？而且不斷往上成長，雖然成長速度不快。所有容器服務在此台Docker Host都很正常執行，但就是想不到何為dockerd.exe為何持續佔用CPU。陷入苦思許久，苦思針對dockerd.exe我要如何偵錯；要針對某個處理程序（process）要偵錯，說起來不容易。
Microsoft Biztalk是一套專注於B2B資料交換的平台軟體。除了大型B2B（例如：EDI、RosettaNet）之外，一般常見的檔案傳輸方式也是有支援，例如：FTP。我們有個SFTP的定時上傳檔案需求，一般可能寫個C# Console或PowerShell加上排程來處理。但Biztalk本身內建了許多Adapter，其中包含了SFTP Adapter，透過設定就能做到的事情，當然選擇Biztalk來做。
近期，我們有意將 Windows Container 升級至最新半年通道 Windows Server 2004，從 1709、1803、1809、1903、1909 一路被虐過來，總覺得會越走越輕鬆，結果沒有。前面，在解決了 VMTools 造成容器服務會被中斷的問題之後。馬上又碰到第二個問題。
話說，工作電腦突然得到好人哭哭卡一張。重開機後用 BlueScreenView 去看了一下，原因是：SYSTEM_SERVICE_EXCEPTION，嗯，好吧，這好像不是我能處理的。
重開機之後，想說繼續之前被中斷的工作，其中一項是更新 Visual Studio 2019，結果：
在某個時間點之後，我們的 Docker for Windows 服務測試區進入了非常不穩定期。一開始不容易發現的原因是，預設執行中的容器(Container)有下 --restart=always 而且又是在測試區，也就是說，當你部署新的容器服務時，會有10-15鐘很正常，然後中間會有個有個瞬斷。容器被中止後，因為 --restart=always 參數的關係， Docker 服務會用最快的時間重啟一個容器還給你用。所以總會覺得怎麼最近寫的容器應用程式怎麼過一段時間就卡卡的。在某次下 docker ps 時看到才發現到這些容器的啟動時間怪怪的。
近來，我們的 Docker Build 主機上經常過一段時間就會出現以下的錯誤造成 docker build 失敗。
在前一篇解決 Symantec Endpoint Protection 與 Docker 相容性問題碰到一個問題，Docker for Windows 預設 NAT 網路無法重設，主要是想統一開發人員的 NAT 網路設定，這樣 IT 單位才方便統一套用防火牆規則。
我測試以下幾種方式：
fixed-cidrdocker network rm nat 移除，直接顯示「daemon: nat is a pre-defined network and cannot be removed」訊息Get-NetNat 沒有任何訊息，Get-ContainerNetwork | Remove-ContainerNetwork 更顯示沒有此指令。基本是都行不通。最後實在沒找到辦法才請開發人員統一自訂一條 NAT 網路。
不過就在不死心的狀態下，又在我個人的 Surface Pro 上又試了一次。
當我們導入了 Azure Container Monitor 之後，取得另外一個好處，內建的 Log Analytics 提供強大的日誌分析功能。而且 Log Analytics 經過設計之後，這些數據分析的資料能輸出為儀表板(Dashboard)。我們製作了一個 Dashboard，然後放到團隊的電視上，圖中很明顯出現直線下滑的曲線，而那條線是 Memory 的可用率！連入主機查詢，又是可惡的 99% 記憶體。
前情提要：「我們透過 Container Monitoring 發現了一個 Portainer Agent 的錯誤。」最簡單的修正就是每次當 Portainer 發現 Portainer Agent 連不上時，去 Portainer 裡去設定 Portainer Agent 重啟後的新 IP Address。此 Portainer Agent 本身位於 Docker Swarm 的 Overlay 網路上，Overlay 網路預設會分配一個 10.x.x.x/24，第一條通常是 10.0.0.0/24，第二條 10.0.1.0/24 以此類推。
一般當 Docker Host 與 Container 的越來越多時就能發現，在管理與處理 Docker Host 與 Container 因為太分散的關係(Docker Swarm / Kubernetes 本身就分散式架構)反而費時費力，在內網可以採用 Portainer 來管理，Portainer 好用是好用，但 Portainre 本身還是比較是單一個 Docker 與 Container 服務來查詢與管理，要想整合多個 Docker 資訊時，它就比較使不上力了。在嘗試使用 Container Monitoring solution 之後，發現這真是個好服務，用個簡單實例來看看如何使 Container Monitoring 來快速進行問題定位與處理。
Visual Studio 2019 最有感的改變之一就是一開始的「啟動畫面(startup)」不一樣。不過好景不常，這個啟動畫面在我公司舊筆電(比例非常高)與自用的 Surface Pro 6 上都會出現：
在導入 Docker for Windows 之後，使用 PowerShell 的比重越來越高，而且在 CD(持續發布)的過程，也相當依賴 PowerShell 來進行作業。平常，可以透過 Docker CLI 來直接對 Docker Host 來下達指令(docker -H host command)。但今天如果是要直接對 Windows Server 下達 PowerShell 指令，也就是，我在 A 電腦直接透過指令視窗對 B 電腦下 PowerShell 指令，而非使用遠端桌面，那麼可以使用 PSRemoting。
同事詢問一個靈異的狀況。美國同事的電腦，不論如何測試就是無法登入最近採用 ASP.NET Core + Razor Pages 開發的一個新服務網站。此網站使用預設 [Authorize] 來驗證，後端沒有什麼太深的程式碼，就是驗證帳密通過設定驗證 HTTP Cookie。
一開始的方向還在通想會不會是 ASP.NET Core 本身有雷，這個技術還很新，不敢說我們的掌握度還很好，可是想想可能性非常的低，這個 [Authorize] 的發展從 ASP.NET MVC 到 ASP.NET Core 應該算成熟的應用。反覆測試，發現一奇特現像。
同事反應，ASP.NET Core 專案無法正常進行中斷點(breakpoint)偵錯。簽出專案，下中斷點偵錯取得以下資訊：
The breakpoint will not currently be hit. No symbols have been loaded for tis document.
如果這時你下關鍵字「asp.net core breakpoint」去搜尋，在第一筆你就能找到解決方案。
他的解決方案是叫你「關閉：Enable Just My Code」與「開啟：Microsoft symbols Server」。
如果這樣就解決了，那我還要寫這篇嗎？
我們有個專案的架構如下：
JS Framework <--> ASP.NET MVC <--> ASP.NET Web API(Service) <--> UDSP <--> ASP.NET Web API(Authorzation)
專案網站有個怪問題，如果網站2到3小時的時間無人使用，那麼閒置時間後第一個第一次使用的人會特別慢。針對IIS的Application Pool的啟動模式由OnDemand改為AlwaysRunning，針對IIS站台的預先載入也已經修改為true，但效果有限。相關停頓、反應時間過長等情境在本地端(Local)模擬不出來，由於分層(tier)過多追起來費時費工。
有無什麼好辦法，可以針對發行至IIS的站台進行線上的偵錯？有的，目前我知道的有三種方法：
WinDBG功能強大，但指令參數複雜，而且取得Dump檔的過程不是那麼友善。針對這樣的問題，WinDBG近期有推出一支Microsoft Store App - WinDBG Preview，可以透過GUI來查詢分析Dump檔案。IntelliTrace Collector也是強大，但推廣不易，因為IntelliTrace定位在Visual Studio企業版才能使用。DebugDiagnostic Tool是本篇的主角，選擇它的原因很簡單，第一、它安裝與使用容易。第二、它收集Dump容易。第三、它分析Dump容易。
首先，你必須先下載Debug Diagnostic Tool v2 Update 2並安裝至IIS所在的伺服器上。安裝好會多三套工具，DebugDiag 2 Collection、DebugDiag 2 Analysis、DebugDiag 2 RuleBuilder(beta)。
關於的Web.config瞭解與使用，在開發的網站規模越來越大時，需要瞭解的越多，之前也做有幾次的討論：
但這一次是碰到VSTS在自動化建置後產出Web.config一直不正常，一開始有點鬼打牆的狀態，但在新聞追追追的精神下，讓我又對Web.config組熊轉換又更進一步瞭解。
專案升級套件後，Web、API相繼掛點，出現黃白畫面：
Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
同事反應，在Visual Studio 2017當要關閉修改過資料庫專案檔案時，整個 VS 2017 會停止回應數十秒才會關閉。在我電腦測試，確實會停頓個2-3秒時間才會關閉。本來以為是 SSDT 的問題，因為 SSDT 在目前的 VS 2017 還沒準備好。我猜，SQL Server 2017 GA 時應該會一併更新 SSDT for VS 2017 吧。
還好，轉個彎下對關鍵字，看到一個很瞎的解決方式。
重開 VS 2017，問題立即解決。
參考：
