本節書摘來自異步社群《網絡管理：計費與性能管理政策》一書中的第1章，第1.1節，作者【美】benoit claise, ccie#2868 , ralf wolter，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
網絡管理：計費與性能管理政策
要說明記賬與性能管理之間的相似性和差異性，首先需要對這兩個術語進行解釋。不幸的是，還沒有針對記賬的統一标準定義，這也就導緻有時候不同的組織會給出不同的定義。下面列舉的是用于描述記賬的相對常用的定義。要說明的是，本節闡述的是純粹的理論，本書的目标是要為記賬和性能管理提出一種廣泛而綜合的觀念，之是以先從純理論上進行闡述，也正是基于這樣的考慮。
1． itu-t的定義（m.3400和x.700，osi網絡管理職責的定義）
記賬管理可以通過對osie[開放系統互連環境]資源的使用來建立費用清單，并且同樣可以通過這些資源來确定成本花費。記賬管理包括如下功能：
将成本花費和資源消耗通知給使用者；
可以設定記賬限制以及将使用的資源與花費計劃進行關聯；
如果存在多種資源同時為了完成一個給定通信目标而被調用的話，可以将成本花費與之進行關聯。
2． tmf的定義
tmf根據itu-t對于記賬的定義（m.3400），在增強的電信運作藍圖（etom）中提出了對于記賬的附加細節（見商業流程架構，文檔gb921）。
在tmf的etom中，執行、保證和記賬（fab）模型決定了在保證和記賬之間“網絡資料管理”元件的位置。（網絡資料管理：該流程包含了對有用資料、網絡資訊技術事件的收集，以及用于網絡性能和流量分析資料的收集。在服務管理層面，這些資料同樣還可以被作為用于記賬（計費和折扣計算）流程的輸入資訊，當然這要根據具體的服務及其體系結構。）第3章将會更為詳細地對fab模型進行解釋。
注釋：
3． ietf的定義
在網際網路标準草案（rfc）2975，記賬管理介紹中，給出了如下對記賬的定義：對資源消耗資訊的收集是為了進行性能和趨勢分析、成本配置設定、審計以及計費。記賬管理需要對資源的消耗進行量化、定價和配置設定，并且還要在适當的部門之間進行溝通。
正如前面的定義中叙述的，對于記賬管理來說，根本沒有一種統一通用的定義。itu-t主要考慮資源使用量的計費，這也正是每個服務提供商最主要的需求，但是我們認為該定義的局限性很大。盡管ietf的定義僅存在于rfc中而未被用于标準，但這和我們認為的“記賬管理”幾乎是一緻的。為了不閱聽人多定義及其各自局限性的幹擾，我們決定自己對其進行定義。
本書使用記賬管理這個術語來描述以下流程：
在網絡裝置中收集有用的資料記錄；
不受限制地對裝置生成的資料進行預處理（如過濾、取樣、集中）；
将這些資料從裝置輸出到一台集中伺服器；
在集中伺服器上對這些資料進行處理（如過濾、取樣、集中、複制）；
将有用的記錄轉換成一種通用的格式，以便可以被高層應用（如性能、sla、故障、安全、記賬、設計等）使用，中止程序。
圖1-3描述了多種應用對記賬管理的使用。注意，不同層面的功能與在記錄生成和處理（諸如資料收集、輸出和集中）之間的差別，還要注意将會使用這些記錄的應用。
通常會将記賬與計費聯系起來，因為在詞典（韋氏詞典）中，是如下描述記賬的特點的。
“用于記錄和概括商業以及财政事務，并且對其結果進行分析、檢查和報告。”
在這個定義中絲毫沒有提及到“計費”這個術語，但是卻間接地将記賬關聯到計費上去了。然而，在我們的觀念中，記賬和計費是不同的，因為計費僅僅是記賬的多種應用中的一種而已。
盡管如前所述，還沒有一種統一通用的定義用于記賬管理，但是性能管理至少在各種不同的定義之間有很多相似之處。和介紹記賬定義一樣，本書從研究itu-t以及tmf對性能管理的定義開始。但要注意的是，ietf的rfc中并沒有針對性能管理的定義。最後，将會給出作者自己的定義，該定義同樣也會在全書中貫穿使用。
性能管理根據電信裝置及網絡效力或網絡元件的行為提供評估和報告，它的角色是收集和分析統計資料用于對網絡效力、網絡元件或裝置的監控和糾錯，并且對設計、采購、維護和品質測定提供幫助。
性能管理提供以下功能：
收集統計資訊；
維護和檢查系統曆史狀态日志；
在真實和模拟環境中确定系統性能；
通過改變系統的運作模式來引導性能管理行為。
2． tmf定義
tmf從全網穩定的角度來定義性能管理和sla管理。網絡的穩定程序負責執行前瞻以及運作中的維護，以確定服務提供商到客戶之間通路的持續性，同時還要保證sla或服務品質（qos）的實施級别。它不間斷地檢視資源狀态，并通過性能監控來預見性地檢測可能的故障，同時還會收集運作資料資訊并進行分析，确定潛在的故障，在不影響客戶的情況下将這些故障解決掉。該程序管理着sla，并且将服務性能報告給客戶。相關的文檔是tmf 701，性能報告的概念和定義，tmf gb917，sla管理手冊；都參閱了itu m.3010以及etom的fab模型。根據tmf的定義，性能收集也是網絡資料管理程序中的一部分。
“這個程序包括了對有用資料的收集、網絡和資訊技術事件資訊的收集，其目的是進行網絡性能和流量分析。”
正如你從這些定義中所看到，性能管理還沒有一個統一的分類。itu-t的定義主要考慮的是電信、網絡裝置的行為和效力，但是該定義的局限性太大，因為它沒有涉及到運作在網絡前端服務的監管。tmf的定義主張的是服務等級管理的細節，但隻是簡單地提了一下網絡元件監控的必要性。為了将這些定義中細微的差異進行中和，我們給出了我們自己的定義。
現在，我們已經可以差別性能監控和性能管理了。
性能監控收集裝置、網絡以及服務相關的因素，然後通過圖形化使用者接口、日志檔案等方式将這些記錄報告出來。性能管理淩駕于這些資料收集之上，主動将這些資訊更進一步地通告給管理者，并且在需要的時候對裝置進行配置變更。sla中的資料收集就是這樣的一個例子。性能監控和記賬隻是對資料進行收集，然後在某個集中點将這些資料儲存起來。性能管理将會分析這些資料，并且将其與預先定義好的門限值以及服務水準進行比較。一旦違背了服務級别，性能管理就會生成一塊故障令牌，用于應用糾錯或對裝置進行配置變更。例如，它将會過濾掉盡最大努力傳輸的流量或提高承諾接入速率，等等。
本書使用這個術語來描述以下流程。
（1）性能監控——基于以下的原因，在裝置層面進行網絡活動資訊的收集：
裝置相關的性能監控；
網絡性能監控；
服務性能監控。
監控的基本任務單元包括：
一種可用的監控方式；
響應時間報告；
監控的消耗（鍊路、裝置、cpu、網絡、服務等）；
確定所收集資料的精确性；
檢查服務品質參數；
資料集中。
（2）資料分析——基準和報告。
資料分析的基本任務單元包括：
網絡和裝置流量的特性以及分析的作用；
性能；
例外；
分析能力；
基準；
流量預估。
（3）性能管理——監控隻關心網絡中的活動，但是管理可以變更裝置配置。一般所說的性能管理，表示調整配置來提高網絡性能以及進行流量處理（門限值定義、性能設計等）。
管理的基本任務單元包括：
確定滿足sla和服務等級（cos）的政策及其保證；
定義門限值；
向進階别應用發送通告；
調整配置；
品質保證。
圖1-4描述了性能管理的結構，在将其與記賬的結構進行比較的時候，可以看到很多的相似之處，但同時也有差別，下一小節将讨論兩者的異同。記賬隻涉及被動的收集方法，而性能管理還可以運用主動的度量手段。在該環境中，我們向網絡中人工注入流量，看看網絡是如何進行處理的。
對性能管理的定義隻是部分地混合了對裝置和服務的管理。對性能管理更細緻的定義應該确定以下3種子類：
特定裝置的性能管理；
以網絡為中心的運作管理；
服務管理。
特定裝置的性能管理以一種孤立的模式看待裝置。裝置的狀态差不多都是二進制的：要麼工作正常，要麼就是有故障發生。在網絡元件層面定義了門限值之後，性能監控同樣可以被認為是二進制的。比如說，如果cpu使用率在5%~80%之間被視為正常的話，鍊路的使用率就應該小于90%，同時接口錯誤率不應該超過1%。是以，根據預先定義的門限值是否超出來判斷狀态是正常還是異常。
以網絡為中心的性能管理将關注點擴大到了網絡的邊緣到邊緣觀點。盡管從單個裝置來看，所有的裝置都是正常的，但是整個網絡的性能可能會因為雙工的不比對、生成樹錯誤、路由環路等問題而受到影響。
服務管理将管理級别提高到網絡連通性之上。有些服務可能相對比較簡單，比如域名伺服器（dns）；也可能比較複雜，比如事務處理資料庫系統。無論簡單還是複雜，使用者都希望服務是可用的，并且響應時間是可預計的。服務層面的性能監控除了包括服務監控之外，還需要有管理的功能，以便萬一出現故障的時候對服務組建進行修改和變更。
本小節讨論記賬管理和性能管理之間的相似性和差異性。通過在一些标準定義中的反映，我們看到了性能和記賬之間密不可分的關系。盡管有一些定義的描述略有不同（如fcaps模型），但是基本理念是非常相近的。作為一項非常有意義的研究，tmf将這兩個類别結合到了一起。
這兩者都要對有用的資料進行收集，這些資料随後可能被應用到相同的應用中去，如監控、基準、安全分析等等。諸如簡單網絡管理協定（snmp）計數器之類的一些技術可以配置設定給性能，也可以配置設定給記賬，關于這些技術到底屬于這兩者中的哪一類别的純理論性讨論将會持續很長時間。
記賬和性能監控是非常重要的資訊來源，這不僅僅是為了進行性能管理，還可以用于安全管理——這是另一個常見的類别。安全管理應用可以輸入這些收集來的流量資訊，分析不同類型的協定，以及分析在源和目的地之間的流量類型，等等。将一種資料流與已定義好的基準進行比較，就可以辨別出異常的情況或新的流量類型。此外，同樣的應用還可以通過性能監控收集詳細的資訊，如cpu的使用率。在實際環境中，兩者的結合很可能會是用來确定安全攻擊的一種非常強大的工具。通過安全執行個體來說明性能監控和記賬的好處所在是最合适不過的了。每一種問題自身的征兆（異常的流量或很高的cpu使用率）從本質上說也許并不顯眼，但是如果将所有的征兆都集合起來的話，就很容易說明網絡所處的危險環境了。
從整個網絡的角度來看，性能會考慮諸如網絡負載、裝置負載、吞吐量、鍊路容量、不同的流量類型、丢包率、擁塞之類的細節，而記賬則将這些有用的資料收集起來。
對于記賬和性能監控，資訊收集的間隔是需要分别考慮的因素。性能分析的資料收集程序需要在門限值超出的時候立即通知管理者，是以這種情況下我們通常需要實時地資訊收集。除了像預付費這樣的情況之外，用于計費的記賬資料收集并沒有實時的需求。
曆史的确是一個很好分析參數。但是以計費為目的的記賬收集并不需要維護曆史資料，因為這是計費應用的工作。另一方面，性能管理需要曆史資料來分析是否有異常情況發生，同時還能進行趨勢分析。
在這兩者間，監控裝置使用率的行為也是不相同的。裝置健康狀況監控對于性能監控來說是至關重要的一部分，然而記賬管理關心的是有用的資訊記錄。我們将通過下面的例子來說明這個問題。假設有一個普通的網絡環境，其流量負載适中，現在使用者在沒有通知管理者的情況下自行安裝了一個“感興趣的”軟體。例如，某人安裝了一個監控工具，并且開始用它來發現網絡中的裝置。盡管強烈推薦對裝置的接入需要安全性，并且要用私密的snmp字元串來代替預設的“public”和“private”，但是有時候這些建議并沒有得到采納。如果此時安全限制（如通路控制清單[acl]）也沒有實施的話，使用者就可以獲得網絡以及裝置相關的詳細資訊。如果使用者的監控工具收集網際網路邊緣路由器的路由表的話，情況将是非常嚴重的。例如，要從ram為64mb的cisco 2600路由器中擷取4000條路由條目，需要花費25分鐘的時間，并且要花費掉30%左右的cpu資源。單獨的一種記賬應用根本就不能發現這種問題，因為該問題不會涉及到流量的傳輸，但是事實上，裝置資源正在被消耗。性能監控應用可以立即發現這個問題，并且能夠将它報告給某個故障應用。這個簡單的例子不僅說明了性能和故障管理之間密不可分的關系，同時還說明了無論是記賬管理還是性能管理都無法獨立地用作一種高效的網絡管了解決方案。
另外一種情況就是鍊路的錯誤配置。假設在兩台路由器之間的邏輯鍊路是三條平行鍊路，用作幹線。基于故障排查的原因，管理者将其中的兩條鍊路斷開後，故障得到了解決。然而，假設之後他僅将兩條斷開鍊路中的一條恢複使用，那麼就隻能提供所需帶寬的2/3。流量仍然會被傳輸，記賬記錄還是會生成，但是這兩條可用鍊路使用率的增加隻能通過性能管理工具才能被辨別出來。
這就使得“故障”報告成了另一種在記賬管理和性能管理之間的差異。在第一個例子中，性能管理應用可以發送通告給故障應用，并且可以通過在裝置上配置acp來停止對snmp資訊進行未授權的收集。在第二個例子中，性能管理工具可以自動地将第三條鍊路激活，并且将這一資訊通告給管理者。記賬管理應用不會對裝置健康狀态資訊進行收集，如cup使用率，是以自然也不會關心例子中的問題了。性能管理和故障管理之間密切的關系在一些出版的讀物中都是作為主題來研究的。
監控過程是主動還是被動是各種監控手段之間最基本的差別。記賬管理總是被動的，而性能管理可以是被動的，也可以是主動的。
被動監控模式通過運作度量來收集性能資料資訊。從簡單的接口計數器到一些諸如遠端監控（rmon）嗅探之類的專用應用都是使用這種模式。被動模式需要監控目的地為某台裝置的一些或所有封包。如果并不是所有的封包都被收集，而隻是檢查其中一部分的話，就叫做取樣。在某些環境中，比如測量雙向通信的響應時間，實施被動模式可能會比較複雜，這是因為請求封包和響應封包之間需要進行關聯。舉例來說，應用相應時間（art）管理資訊庫（mib）是rmon 2标準的擴充。art用于測量應用資料流中請求/響應封包序列之間的延遲，如http或ftp的資料流，但是art隻能對使用衆所周知tcp端口的應用進行監控。若要提供端到端的測量，需要同時在用戶端和伺服器端使用art嗅探。cisco在網絡分析模型（nam）中部署art mib。
被動監控模式的好處在于不會對網絡中的資料流量形成幹擾，是以測量的結果基本上沒有誤差。這個好處也可能是一個限制，因為被動模式的先決條件是要有網絡活動。舉例來說，通過對流量的監控可以發現有一門電話機出于活動狀态，但是當沒有産生任何流量的時候，如何辨識這門電話是正常的還是有故障，這種情況下，最好的辦法是發送測試流量給電話，然後監控結果，或者讓這門電話規律性地發送保持存活封包。但是主動監控模式會人為地向網絡注入流量來測量性能參數，比如可用性、響應時間、網絡回程時間、延遲、延遲抖動、重傳、丢包率等。主動模式簡單地提高了可測量性，因為隻需要對已經生成的流量進行分析。cisco ip sla就是一種主動監控模式。關于ip sla更多的細節，請參閱第11章。
通過實踐證明，目前最好的方法是将主動和被動模式相結合，因為它們可以互相補充。
正如前所述，它們之間既存在共性也存在差異，但是在大多數情況下，将記賬管理和性能管理相結合是有好處的。讓我們仔細分析一下下面的情景：網絡操作員同時實施了性能管理和記賬管理，兩者都對裝置進行有用資料的收集，并且儲存于不同的集中伺服器。各自收集的資料集互相獨立，不過都是有用的。如果想要降低測量的誤差，可以對詳細的記錄（記賬管理）和基本的snmp計數器（性能管理）進行收集，然後将其結果進行比較。這樣做可以提高測量的準确性。
圖1-5顯示了不同網絡管理的元件。
總的來說，我們推薦将性能管理和記賬管理、故障管理和安全管理結合使用，以便建構完整的網絡管了解決方案。
這些範例很清晰地回答了“哪種情況适用哪種模型？”這個問題，而不是“為什麼需要記賬管理或性能管理？”。後者，也是最為重要的問題也可以了解為“進行資料收集的目的是什麼？”。當管理者通過嚴密的方法區分安全管理、服務等級管理、計費等的時候，很自然地就将記賬和性能管理貫穿到了整個體系結構中。
為了進行總結，我們要對性能監控和記賬管理為其他各種管理應用收集有用的輸入資料進行強調。性能管理就是從性能監控和記賬中獲利的一個管理類别，當然它還可以主動地進行網絡變更以及自身行為的變更。它們之間是相關的，因為如果沒有性能監控，就無法無障礙地操作網絡。沒有記賬，幾乎就不能确定導緻瓶頸的原因，而性能管理則可以測定運作中的能耗。通常網絡監控在這兩個類别中都存在（請參閱1.2.1節）。是以，對記賬管理和性能管理中的任何資料收集工作來說，網絡監控這個術語是非常普通的。圖1-6顯示了這兩個類别的交疊。
既然我們已經清楚地定義了記賬管理、性能監控和性能管理，那麼接下來我們可以更為深入地了解一下網絡設計者和管理者如何完成這些類别的工作。