單獨使用雲端供應商的監控解決方案無法獲得的 5 個關鍵見解
發布日期：2022/05/13
在與當前或潛在的 Splunk 客戶會面時，我們經常被問到的一個問題是：「我可以使用 AWS Cloudwatch、Azure Monitor 或 GCP Cloud Operations Suite (以前稱為 Stackdriver) 來滿足我的雲端監控需求嗎？」這真是一個好問題！
雲端供應商的監控功能通常被認為「更便宜」、「更容易」或「整合得更好」，因此客戶多半會重度依賴這些工具，尤其是在雲端之旅的早期。我們很常看到這種情形，但相信我們，這種作法大有問題。
在本文中，我們將幫助您瞭解為什麼需要 Splunk。我們將為這個問題提供綜觀全局的解答，並用 5 個見解和可靠的例子來支持這個論點。您永遠不應該只依賴雲端供應商！
綜觀全局的解答
為什麼您需要 Splunk，而不僅僅是雲端供應商的監控解決方案？
用最簡單的方式說，答案是雲端供應商監控解決方案通常只是將資料饋入另一個資料孤島，而這些資料沒有開放，無法被大眾任意使用，只能與其他資料來源相關聯。此外，每個雲端供應商的監控解決方案的特性和功能都是有限的，如 Amazon、Microsoft 和 Google 在功能和可用性方面似乎都只是「還可以」。
這也不是一個新問題。多年來，Splunk 一直是善用和關聯資料的業界標準解決方案。以 VMware 為例。VMware 系統管理員當然可以輕鬆且自在地使用 vSphere 來監控、管理和排除 VMware 平台的問題。但是在 VMware 虛擬機器上執行應用程式的應用程式所有者呢？當應用程式出現問題時，訊息可能沒有被記錄到 vSphere。不過，應用程式問題很可能是由於意外的 vMotion 事件或大量占用資源的鄰近虛擬機器 (noisy neighbor) 所導致的！資料庫、網路、儲存和其他所有技術也是如此。如果無法將來自多個系統的資料彙整到一個地方，那麼當事件發生時，您將難以關聯、調查和找出真正的根本原因。
如果這個綜觀全局的答案還無法說服您，那麼讓我用 5 個實際的例子來支持這個論點，因為您很難使用雲端平台監控功能來獲得這些深入見解。
見解 1：跨多個雲端區域和帳戶的可見性
如果您像大多數組織一樣，必須管理多個雲端帳戶並跨多個區域部署資源。那麼如我所提，您只能獲得帳單上聲稱的基礎架構「完全可見性」。在雲端供應商主控台中一個個地切換帳戶和區域來取得基礎架構的深入資訊是很辛苦的。但使用 Splunk 之後，您將能夠輕鬆回答跨帳戶和跨區域的關鍵基礎架構問題，例如：
1. 哪些帳戶正在部署大量或昂貴的基礎架構？
2. 我們是否持續且有效地標記基礎架構，將服務、團隊和所有者以及其他有助於我們理解和管理成本的資訊歸類？
3. 我們是否無意間在不應該開展業務或儲存資料的地區部署了基礎架構？
圖 1：帳戶中所有 Azure VM 的清單 (按區域分組)
圖 2：Splunk AWS EC2 成本分析儀表板
見解 2：混合應用程式的端對端故障排除
如果您像大多數組織一樣，正在將工作負載移轉到雲端，但這些工作負載仍會使用本地和外部的元件。事實上，保留在本地的工作負載通常是公司最重要、最不可或缺的系統之一。移轉到雲端的工作負載通常會分階段進行，風險較低的部分會先移出去，而且在大多數情況下，它們仍然會呼叫外部元件來完成工作。
在這種情況下如何對應用程式進行故障排除？哦，或許您已經不得不這樣做了！我來猜猜看結果會是什麼。雲端營運團隊會使用特定雲端供應商的監控解決方案，然後回報「一切正常」，IT 營運團隊使用他們的監控工具，也回報「一切正常」。
從我們在 Splunk 的經驗來看，組織若要能夠解決這個複雜的問題，就需要將監控和調查的工作集中到一個平台上；Splunk 搜尋、儀表板和視覺效果工具可成為團隊用來分類、隔離和調查事件的「共通語言」。
圖 3：Splunk 可觀察性執行儀表板中顯示的多雲服務執行狀況評分
圖 4：顯示私有雲主機指標和 AWS 執行個體指標的 Splunk 儀表板
見解 3：細分到每秒鐘的監控和警報
雲端供應商限制了您有權使用的監控資料的類型和精細度 (可以理解)。例如，AWS Cloudwatch 指標是以每 5 分鐘一次的預設間隔收集。最好的狀況下，您可以將精細度提高到每分鐘一次，但沒辦法再密集了。想像一下，雲端供應商就像一個負責照看孩子的保姆。他們整天用手機，只是每 5 分鐘抬頭看一下孩子的狀況，您滿意嗎？當然不！5 分鐘內可能會發生很多事情。
除了精細度之外，您可能還想收集更多的裝置遙測資料，但雲端供應商的指標可能不支援這些遙測資料。我在 AWS 上多配置一些空間，EBS 儲存是依照配置的磁碟空間比例算錢，而不管實際使用了多少空間。那麼，我們就可以使用 Cloudwatch 可視化和監控每個 EBS 磁碟區的儲存百分比來節省雲端成本，沒錯吧？錯！雖然您可以輕鬆檢視磁碟區有多大，但沒有一個指標可以告訴您目前的使用量。糟了！
圖 5：顯示 Splunk 開放遙測 (OTEL) 指標與 AWS CloudWatch 指標對比的圖表
見解 4：具有強大搜尋功能的進階調查和分析
因為 Splunk 絕對是這個領域的霸主，我可以直接了當地說，用雲端供應商的監控工具來搜尋和分析日誌很快就會讓您失望，您需要更多功能。基本的收集、搜尋和深入資訊是有的，但深入調查和整個環境的廣泛保護需要先進的資料收集、解析和搜尋功能，只有在 Splunk 中才有。讓我們舉幾個具體的例子。
假設您想知道最近的程式碼部署是否會讓在環境中出現新問題。一種強大的分析方法是搜尋新看到的堆疊追蹤，但這有一點難度。您如何判斷一個堆疊追蹤何時與另一個相同？透過一些聰明的 SPL，我們可以很容易地偵測到這種情形。
假設您想知道是否有任何 S3 貯體資料被無意中設定為公開可用。如果沒有 Splunk，這件事情就很難辦到！但是藉助 Splunk 強大的搜尋語言，我們可以收集 S3 存取日誌，透過地理位置查找來補充資料，並透過 S3 貯體名稱將它們繪製在地圖上。酷吧！
圖 6：Splunk 儀表板中顯示的 AWS S3 地理位置查找和繪圖
圖 7：Splunk 中的 Stacktrace 搜尋詳細資訊
圖 8：在 Splunk 中偵測和找出堆疊追蹤的動向
見解 5：透過預建內容加快實現價值
最後一點是，取得資料只是第一步。如何使用資料才是真正發揮價值的地方。雖然雲端供應商讓您可以容易地從服務中收集資料，並通常提供特定領域的儀表板，但在跨不同服務關聯和查看資料時大多還是需要手動操作。此外，每個應用程式及其底層架構都是獨一無二的，意即將許多不同資料來源建立有意義的視覺效果是很困難的。
Splunk Infrastructure Monitoring (SIM) 和 Splunk Application Performance Monitoring (APM) 為關鍵資料提供立即可用的工作流程，無論其來源為何。如此一來，您可以立即獲得和內容相關的深入資訊，加快實現投資回報率並從資料中獲得最大價值。此外，開箱即用的儀表板可當作範本，簡化從特定領域儀表板轉換到關鍵性服務的高度相關端對端檢視的過程。您可以輕鬆地從不同的儀表板中複製和張貼圖表和其他視覺效果，製作成自訂的高度可操作儀表板。然後可以與他人共用儀表板，將放在部門的集合中以提升協作能力。
圖 9：Splunk Observability Cloud 中的 AWS 內建儀表板組
圖 10：Splunk Observability Cloud 中的 Google Cloud Platform 內建儀表板組
圖 11：Splunk Observability Cloud 中的 Azure 內建儀表板組
結論
雲端供應商的主要目標是提供基礎架構、平台和軟體即服務。對基礎架構進行有效監控充其量只是次要目標。多年來，隨著技術推陳出新，我們已經充分了解這一點，雲端供應商都是採用這種作法，沒有什麼不同。在 Splunk，我們的主要目標是有效地收集、搜尋、分析和監控各種類型的機器資料，以便您可以將資料轉化為行動。
若要詳細了解 Splunk 能如何幫助您的 IT、雲端營運和開發營運團隊主動觀察和分析不斷變化的雲端資產，請觀看我們的 Splunk Observability Cloud 頁面。
作者
Jeff Wiedemann
在加入 Splunk 之前，Jeff 在一家醫療保健軟體公司擔任了多年的架構師，也是他首次接觸到了 Splunk。事實證明，分析看似不連貫的資料、不斷發現新見解以及做出合理的資料驅動決策是非常有趣的。書呆子萬歲！閒暇之餘，Jeff 會做一些輕鬆有趣的事，只要他搞定兩個小孩的話。
