docker應該也屬於交付之間的環節，最終交付之後還是要提供給應用，如何更好提供的服務，就需要去了解docker不同的執行環境和執行狀態。
利用率、記憶體使用率，以及整個對於網路的情況是什麼樣的，可以通過一些檔案來獲得狀態資訊。比如cpu的檔案，以及用網絡卡做監控的時候怎麼做網路的協同。下面有乙個鏈結，有一些公開的指令碼，可以拿這些指令碼定期的去跑，這樣就是說可以拿到docker基礎的狀態。如果說docker裡面的服務出現了問題，提供的服務出現了問題怎麼辦？以往我們做這種狀態獲取的時候，獲取這種狀態有幾種方案。
首先，我們處在乙個注重使用者體驗的時代，隨處都可見的是在講體驗，不管是我們pc頁面，還是軟體的體驗，從使用者體驗的角度來講，它所帶來的概念是說圍繞著這個使用者的價值能不能夠提供乙個很友好的交付頁面，很暢快的體驗，這裡面有幾個東西可以衡量。
流量（pv/uv/吞吐量）
docker有乙個特點是可以做擴容，其中依據是什麼呢？流量的資訊，不管是你pv、uv、吞吐量的資訊，它有可能提供乙個擴容的機制資料，提醒我知道流量到達了多少的時候該去擴容裝置。
拓撲結構
拓撲結構是什麼概念呢？不管是研發人員或者運營人員、技術人員，這種微服務上線之後服務關係變得越來越複雜，怎麼能一目了然的知道為哪個服務提供服務，這個服務調動了多少次服務，邏輯上的拓撲結構也能夠幫助我們定位問題，提供給我們擴容的一些基本資料。
除了剛才講的cpu資訊、記憶體資訊，記憶體的利用率，包括整個服務領域的數量也會影響到服務的狀態。
以往我們應用的**是說有使用者投訴了，到你的服務不可用了，然後客服部門會找到技術團隊說你的技術不能用，這是乙個應用狀態**。
另外乙個是我們更多常規的採用應用的日誌，會對技術做一些匯集，把各種應用狀態分析出來。但是微服務的架構下，在當前的容器下應用的日誌會越來越多，每乙個docker容器會產生一到多個日誌檔案，我們怎麼樣把這個檔案更好的結合在一起，怎麼把應用的關係串聯起來，其實是有一定的難度。就算能夠將這些資訊串聯起來，也有可能會碰到比如說這是突發性的故障，我們根本以前沒有遇到過，或者偶爾幾個月才能遇到一次，這個錯誤出來之後不能得知原因，也不知道它到底代表什麼，可能去找研發人員之後一步一步的去嘗試，難道沒有乙個更好的方式嗎？
隨著技術的發展，apm技術能夠幫我們做一些事情。apm其實有兩個含義，我們更多的理解它是乙個管理，為什麼是管理？應用的狀態不是乙個點，也不是乙個時間段的問題，它是一整個軟體生命週期的問題，所以對於應用效能的是軟體週期中的乙個關鍵點。
這是一張拓撲圖
使用者所能體現的，對應用的直觀感受是什麼樣的？它所獲取到的時間是什麼樣的？以入口服務為主，這個入口服務呼叫了哪些服務？這個下面呼叫了資料庫的服務，在這個服務上訪問了一些其他**。根據業務關係可能會更加複雜，每乙個服務上面是什麼樣的？會通過一定的基準值表現出來，是因為某乙個服務出現了問題導致整個服務有問題，這是乙個應用的邏輯，它能夠告訴你當前應用下你所部署的關係，以及應用和應用之間的關係。
下圖可以看到其中乙個應用，它在乙個打分的情況下出現了54分。
由於應用的響應時間超過了2秒，這時會出現一些使用者體驗的問題，使用者投訴也會隨之而來。如果能在使用者投訴來之前就解決這個問題是現在網際網路企業比較關心的問題。根據這個圖來可以了解到應用出現了哪些問題，響應時間超過了2秒，而這2秒花在哪個地方呢？我們通過另外乙個圖
對於這個應用來講能夠看到是應用**和外部服務時間出現了問題，到底能不能了解到在這個應用下有哪些服務出現了問題，圖中可以看到這個服務調動了很多包括呼叫了opencms以及這條線上會有opencms享受的服務，opencms呼叫了另外乙個服務。這裡面包括每乙個服務對於吞吐率、錯誤率等等的指標，由此就能得知到底是本身的業務出現的問題，還是因為呼叫了其他的服務出現的問題。
在這個應用裡面其中的幾個服務是最慢的，拿其中的乙個來分析：
這個叫rss2的服務，url對應的服務是什麼，可能是和本身業務相關的，而能不能知道在這個服務中它到底呼叫了哪些**？整個呼叫鏈裡面出現了哪些有可能產生效能的問題呢？除了能看到這個服務的呼叫所佔比達到了50%以上以及對資料庫的訪問也佔了15%的情況之外，也可以從單一使用者場景下出現的問題分析。
上圖能看到這一次請求裡面，在spp這個服務裡面消耗的時間是11秒，這11秒的時間通過這個拓撲圖來看呼叫的這個應用所消耗的是133毫秒，opencms消耗的應用在四個時間裡面平均是1.9秒，總共消耗了7秒，在11秒裡面有7.8秒是因為opencms效應過慢導致了對外服務的應用出現了緩慢的問題。再去看opencms，總共呼叫了四次的opencms，opencms對應的是哪些服務？它這個服務到底發生在哪個虛擬的環境下面？這個虛擬的環境下所產生的是什麼樣的？是因為opencms的問題，導致我整個服務出現了問題。
整個**鏈裡面，因為其中乙個函式呼叫了opencms的url，對應opencms應用的例項是這台主機，我們能得知在這台容器裡面它發生的時間主要是在外部服務，也就是說opencms在這4秒裡面所消耗的時間，絕大部分是發生在外部服務裡，通過一步步的鑽取，可以看到在當時的場景下呼叫了這個服務，這4秒花在了什麼地方。
接下來到了opencms的應用，也在這個時間點看到了對應的請求類別，在這裡面我們可以看到當時是因為它呼叫了這個裡面的服務所產生了問題，原因是方法在檔案的127行呼叫的服務。從以上的這兩個圖來看，我們既可以知道是因為什麼樣的服務出現了問題，也可以告知是因為哪一行**呼叫了這個所產生的問題。
由剛才的圖可以看到在這個時間點裡面有一次呼叫所執行的是這個sql，這個sql在當時的執行計畫是什麼樣的，是因為單錶資料量過大而導致了資料庫的反應過慢還是其他原因，有了這個資訊就可以提供一些優化依據來提公升我們的的質量。
剛才有大約10%的使用者受到了服務的影響，這10%當時是不可用的，這些不可用的情況下到底發生了什麼樣的錯誤？也許會看到絕大部分是因為404，也有一些情況是因為編輯的問題，以往這些問題只能通過點去查，或者是沒有日誌出錯的情況下很難定位這個問題。當一步一步看這個錯誤的時候，可以看到錯誤詳情以及當時的呼叫情況，請求資訊所帶來的是什麼樣的，包括出現問題的**和資料，這樣就可以快速的告訴研發哪段**出現了問題趕緊修改，立馬上線，就免於其他更複雜的服務，對10%的使用者可以看到正常的服務。
通過以上，可以看到apm的技術能夠幫助我們快速的了解應用狀態，根據這些應用狀態以及其他資訊來獲取依據，作為去調整服務的依據。
zabbix監控docker應用配置
容器的應用越來越普遍了，但是大量的容器我們怎麼進行管理呢？當然是監控起來！今天這篇文章講的就是使用zabbix監控docker容器！關於zabbix監控的docker的原理 www.cppcns.com 通過zabbix監控docekr的部署大概分為五個部分 1.zabbix agent2 wget...
Docker監控平台
目錄docker監控平台由容器監控元件cadvisor 主機監控元件node exporter 時序資料庫prometheus 告警處理元件alertmanager 圖表展示工具grafana構成，所有元件均已容器方式執行。docker run tid name grafana p 3000 300...
docker容器監控
容器具有以下特性 容器是短期存活的，並且可以動態排程 容器的本質是程序，而不是乙個完整作業系統 由於容器非常輕量，容器的建立和銷毀也會比傳統虛擬機器更加頻繁。docker 容器的監控方案有很多，除了 docker 自帶的docker stats命令，還有很多開源的解決方案，例如 sysdig cad...