現(xiàn)在人們普遍認(rèn)為，監(jiān)控只是可觀察性的一個子集。監(jiān)控顯示你的IT基礎(chǔ)設(shè)施和應(yīng)用出了問題，而可觀察性則幫助你了解原因，通常是通過分析日志、指標(biāo)和跟蹤。在今天的環(huán)境中，需要各種數(shù)據(jù)流來確定性能問題的 "根本原因"，可觀察性的圣杯，包括可用性數(shù)據(jù)、性能指標(biāo)、自定義指標(biāo)、事件、日志/跟蹤和事件。可觀察性框架是由這些數(shù)據(jù)源構(gòu)建的，它允許運營團(tuán)隊自信地瀏覽這些數(shù)據(jù)。

可觀察性還可以確定在有或沒有人工干預(yù)的情況下，采取什么樣的規(guī)定性行動，以應(yīng)對甚至防止關(guān)鍵的業(yè)務(wù)中斷場景。要達(dá)到可觀察性的高級水平，需要監(jiān)控從反應(yīng)性到主動性(或預(yù)測性)的演變，最后是規(guī)范性監(jiān)控。讓我們討論一下這種演變包括什么。

不是一件簡單的事情

首先，看一下聯(lián)合IT運營的現(xiàn)狀，就會發(fā)現(xiàn)其中的挑戰(zhàn)?；A(chǔ)設(shè)施和應(yīng)用程序分散在暫存、預(yù)生產(chǎn)和生產(chǎn)環(huán)境中，在企業(yè)內(nèi)部和云中，IT運營團(tuán)隊不斷參與，以確保這些環(huán)境始終可用，滿足業(yè)務(wù)需求。運營團(tuán)隊必須處理多種工具、團(tuán)隊和流程。對于實施可觀察性平臺需要多少數(shù)據(jù)流，以及如何使企業(yè)內(nèi)的業(yè)務(wù)和IT運營團(tuán)隊遵循一個框架，在一段時間內(nèi)改善運營優(yōu)化，人們常常感到困惑。

為了使監(jiān)控工作成熟起來，超越指標(biāo)儀表板，進(jìn)入這種可觀察的態(tài)勢，它通常分三個階段發(fā)展。反應(yīng)性、主動性(預(yù)測性)和規(guī)定性。讓我們來看看這些是什么。

第一階段：反應(yīng)性監(jiān)測。

這些是監(jiān)測平臺、工具或框架，它們設(shè)置性能基線或規(guī)范，然后檢測這些閾值是否被突破并發(fā)出相應(yīng)的警報。它們有助于確定所需的優(yōu)化配置，以防止達(dá)到性能閾值。隨著時間的推移，隨著更多的混合基礎(chǔ)設(shè)施被調(diào)用或部署以支持越來越多的業(yè)務(wù)服務(wù)和擴大的企業(yè)范圍，預(yù)先定義的基線可能會發(fā)生變化。這可能導(dǎo)致糟糕的性能變得正?；?，不觸發(fā)警報，導(dǎo)致系統(tǒng)完全崩潰。然后，企業(yè)期待主動和預(yù)測性監(jiān)測，以提前提醒他們可能表明即將發(fā)生事件的性能異常。

第二階段：主動/預(yù)測性監(jiān)控。

盡管這兩個詞聽起來不同，但預(yù)測性監(jiān)測可以被認(rèn)為是主動監(jiān)測的一個子集。主動監(jiān)測使企業(yè)能夠查看來自環(huán)境的信號，這些信號可能是或可能不是業(yè)務(wù)服務(wù)中斷的原因。這使企業(yè)能夠準(zhǔn)備補救方案或標(biāo)準(zhǔn)操作程序(SOP)，以克服零優(yōu)先級事件。實施主動監(jiān)控的常見方法之一是為 "管理者的管理者 "提供一個統(tǒng)一的用戶界面，運營團(tuán)隊可以訪問來自多個監(jiān)控域的所有警報，以了解其系統(tǒng)的 "正常 "行為和 "性能瓶頸 "行為。當(dāng)某種行為模式與現(xiàn)有的機器學(xué)習(xí)模式相匹配，表明存在潛在問題時，監(jiān)控系統(tǒng)就會觸發(fā)警報。

預(yù)測性監(jiān)測對市場上較新的技術(shù)使用動態(tài)閾值，而沒有對它們應(yīng)該如何執(zhí)行的第一手經(jīng)驗。然后，這些工具了解一段時間內(nèi)的指標(biāo)行為，并在注意到標(biāo)準(zhǔn)偏差時發(fā)出警報，這可能導(dǎo)致最終用戶會注意到的中斷或性能下降?？梢愿鶕?jù)這些警報采取相應(yīng)的行動，防止發(fā)生影響業(yè)務(wù)的事件。

第三階段：規(guī)范性監(jiān)測。

這是可觀察性框架的最后階段，監(jiān)測系統(tǒng)可以從環(huán)境中的事件和補救/自動化包中學(xué)習(xí)，并了解以下情況。

• 哪些警報是最經(jīng)常發(fā)生的，以及針對這些警報從自動化包中執(zhí)行哪些補救行動?
• 某些被觸發(fā)的資源是否屬于同一個數(shù)據(jù)中心，或者是在多個數(shù)據(jù)中心看到的相同問題，這可能導(dǎo)致理解錯誤的配置基線。
• 如果一個警報是季節(jié)性的，可以在以后的階段忽略，而不執(zhí)行不必要的自動化。
• 對作為縱向或橫向擴展的一部分而引入的新資源執(zhí)行哪些補救措施。
• IT運營團(tuán)隊需要適當(dāng)?shù)乃惴▉黻P(guān)聯(lián)和制定這些方案。這可以是ITOM和ITSM系統(tǒng)對IT運營分析引擎的反饋的組合，以建立規(guī)范的模型。

展望未來

監(jiān)控不是可觀察性，而是它的一個關(guān)鍵部分，從反應(yīng)式監(jiān)控開始，當(dāng)預(yù)先定義的性能閾值被突破時，它會告訴你。隨著你將更多的基礎(chǔ)設(shè)施和應(yīng)用服務(wù)上線，監(jiān)控需要轉(zhuǎn)向主動和預(yù)測模型，這些模型分析更大的監(jiān)控數(shù)據(jù)集，并在服務(wù)水平和用戶體驗受到影響之前檢測可能表明潛在問題的異常情況。

然后，可觀察性框架需要分析一系列的數(shù)據(jù)點，以便在檢測到異常的最初幾分鐘內(nèi)確定性能問題或中斷場景的最可能的原因，然后在進(jìn)入作戰(zhàn)室/情況分析電話之前開始努力補救該性能問題。最終的結(jié)果是更好的用戶體驗，一個永遠(yuǎn)可用的系統(tǒng)，以及改善業(yè)務(wù)運營。