使用 Splunk Observability 事件在 Splunk 產品之間共用相關內容

發布日期：2023/03/16

當 IT 或安全問題影響到開發團隊的軟體時，如何通知他們？您是否還是使用缺乏相關內容的電子郵件發出通知，而且大多數工程師可能將通知從收件匣中過濾掉了？工具和團隊之間各自運作，溝通起來可能很困難。您希望如何將專屬於開發團隊的 IT、安全、舊版流程和業務通知直接放進他們最重要的工具裡？現在您可以辦到！

 

您可以從 Splunk 產品向 Splunk Observability 發送事件，例如：

在許多組織中，開發、安全和 IT 營運團隊都使用 Splunk 工具當作監控和警示的基礎，不過他們可能都是個別使用各種 Splunk 產品。現在，這些工具新增了一個整合功能，可以將警示作為事件及相關的欄位資料發送到 Splunk Observability！這類事件能容易地出現在 Splunk Observability 儀表板上，開發團隊在嘗試解決問題時就會先看到它們。 

由外部環境引起的問題和服務中斷可能會耗去不少工程時間，因為開發團隊必須試圖排除和解決他們無法控制的問題。DDOS、網路問題或資料中心中斷可能會導致開發人員在解決已知原因時浪費許多時間。透過 Splunk Observability 中額外的事件相關內容，不僅可以避免損失時間，還可以標記影響的開始和結束，以供日後稽核或參考。

換句話說，您為什麼不使用 Observability 事件在組織的各單位之間傳遞相關內容呢？不知道應該怎麼做嗎？請繼續看下去！

圖 1：您的開發人員如何知道 Google 雲端資料中心發生過中斷？他們要如何確定運作中斷和恢復運作之間的影響？事件標記！

或者，您的團隊只需要將持續整合/持續交付 (CI/CD) 的事件和欄位從 Splunk Cloud 記錄的資料匯入到 Splunk Observability 中。如此一來，開始、結束、結果、版本編號和其他與部署相關的資料，就可以輕鬆視覺化並疊加在監控儀表板上。實際上，使用 SPL 搜尋的任何內容都可以發送到 Splunk Observability，包括來自匹配資料的欄位

將相關內容提供給您的營運和開發團隊！

開發人員是一群好奇的人，當他們發現軟體無法正常執行時，很可能就會進行調查。但有時問題是由開發團隊無法控制的因素引起的。 

這裡有一個簡略的範例清單： 

  • 外部威脅行為者：Splunk Enterprise Security 識別到 DDOS。開發人員如何得到通知？一封可能被丟進垃圾郵件匣的電子郵件？
  • 業務流程：看到了一個 Splunk ITSI 追蹤的庫存問題？開發人員是否知道這件事，或者他們是否嘗試過確定為什麼需要庫存編號的請求會失敗？
  • 安全掃描和修復：在微服務配置中發現了一個漏洞，並由 Splunk SOAR 自動修復。開發人員是否知道這次補救措施？或者他們是否有調查最近的部署似乎「不見了」？
  • 持續整合/持續整合 (CI/CD)：另一個團隊部署了影響所有下游服務的錯誤程式碼。這些被記錄在 Splunk 中的部署事件，是否可以被下游團隊從監控工具中輕鬆看出來？

以上只是來自 Splunk Enterprise Security、Splunk ITSI、Splunk SOAR 和 Splunk Cloud 的可觀察性事件，將重要的相關內容資料傳遞給開發和營運團隊的幾個範例。 

對於大多數使用案例來說，單是對影響開始和結束加上事件標記就是非常重要的。在您的儀表板上輕鬆視覺化重大事件前後發生的事情，可以減少故障排除時間，同時方便開發人員確定其對服務的影響，以及可能的相關問題，以採取事後行動或事後檢視。

適用每一個產品的解決方案！

Splunk 產品提供來自大量資料的相關內容和見解，這對您的軟體是否能健康執行和開發非常重要。通常，使用這些工具的團隊都是個別運作，並且在組織裡只是個別使用這些工具，但以下連結將詳細說明如何快速將相關內容匯入 Splunk Observability Cloud：

 

Splunk Cloud / Splunk Enterprise：Splunk 會為您的整個組織保存日誌，並且使其成為資料的寶庫！遺憾的是，出於各種安全和業務原因，並非所有員工都能使用所有這些資料。 

Splunk IT Service Intelligence (ITSI):Splunk ITSI 包含我們的業務服務見解、KPI 以及事件資料，這些資料對於在 Splunk Observability Cloud 中與開發人員進行交流或許非常重要。

Splunk Enterprise Security (ES)：Splunk Enterprise Security 可能是軟體開發人員最不熟悉的 Splunk 產品，但它包含影響軟體開發和軟體基礎架構的重要安全相關內容。 

Splunk SOAR：Splunk SOAR 可能正在執行影響開發團隊的自動化。修補作業、失敗的版本和其他自動活動都會影響您的軟體基礎架構。為什麼不將這些事件自動通知給 Splunk Observability Cloud 中的開發和營運團隊？ 

透過使單一產品能夠輕鬆地將資料發送到 Splunk Observability，您可以釋放許多作業、CI/CD、基礎架構和業務資料的潛力。但是透過結合這些工具中的每一個的相關內容，您的開發人員和工程部門可以解鎖重要的細節和歷史分析，這是過去難以或無法獲得的。

將所有線索拉到一起

想像一下，將來自所有工具的相關內容綁定到一個開發人員便於使用介面中，例如 Splunk Observability Cloud，該有多方便。下圖描繪出前述每個 Splunk 工具在回應 DDOS 事件時傳遞的相關內容。

圖 2-1：透過 Splunk ITSI、Enterprise Security、Splunk SOAR 將 DDOS 攻擊及其補救措施傳遞到 Splunk 可Observability 中

  • ITSI 注意到業務服務和異常行為發生的影響，並向 Splunk Observability 發送一個事件，表示影響開始了。
  • Enterprise Security (ES) 關聯 Splunk 中的資料，並將影響識別為一個 DDOS 攻擊。

              ○ ES 發送一個事件通知開發人員出現了 DDOS，並讓他們知道這對他們服務的影響已經超出了控制範圍。 

            ○ ES 啟動 Splunk SOAR 執行腳本，通知網路工程師並執行 SOAR 自動化營運手冊 (playbook) 以嘗試修復 DDOS。 

  • SOAR 完成觸發事件的補救執行程序，並在開始補救時發送事件標記，並預期可以標記影響結束。
  • 開發人員一眼就可以看到整個事件，以及影響開始、修復嘗試和影響結束對事件的影響。

由於每個產品都將事件發送到 Splunk Observability Cloud，因此開發人員可以立即了解基礎架構和軟體之外發生的情況。他們不需要浪費任何時間來診斷問題。擷取這些事件甚至可以使歷史稽核、事後審查和根本原因分析變得更直接。這些事件不僅表示事件開始和結束等重要細節，它們甚至還包括執行動作的詳細資訊。對於任何進行事件管理的團隊，此類事件將是資訊和事故資料的重要來源。 

 

觀看 Splunk Observability 中的以下範例：

圖 2-2：透過 Splunk ITSI、Enterprise Security、Splunk SOAR 將 DDOS 攻擊及其補救措施傳遞到 Splunk Observability 中

1.隨著請求率增加和延遲峰值的發生，影響可能開始於 ~09:37

2.高請求率和延遲峰值開始破壞服務。ITSI 對結帳流程的業務影響向 Splunk Observability 發送一個警示事件。 

  • 平均偵測時間 (MTTD)：我們可以使用以上資料計算平均偵測時間：~09:50 - ~09:37 = ~13m

3.Enterprise Security 識別外部端點上的一次 DDOS，並啟動一個 Splunk Observability 事件和 SOAR 執行腳本以進行補救。

  • 開發人員可以停止故障排除

4.SOAR 執行腳本完成 ~09:59 並向 Splunk Observability  發送一個事件，通知開發人員工作完成。DDOS 流量開始下降，錯誤也逐漸減少。 

  • 平均修復時間 (MTTR)：我們可以使用以上資料來計算平均修復時間：~09:59 - ~09:37 = ~22m

事件是任何可觀察性策略的關鍵要素，有助於了解事件的整個狀況並幫助我們了解所有業務。如果沒有任何指引說發生了什麼、何時何地發生的事件，我們可能很難確定軟體環境、外部影響或業務流程的功能和故障的問題何在。此外，事件使您能夠衡量您的團隊如何應對這些故障，以及評估改進的度量，如 MTTD 和 MTTR。

下一步

匯集所有工具的相關內容！可觀察性事件不會發生相關成本，並且可以將重要資訊新增到您的儀表板和事件回應中。它們是免費的寶藏！補充您的監控資料比以往更容易！

從 SplunkBase 下載並安裝 Splunk Observability Events App，然後在 Splunk SOAR 中預安裝的 SignalFX SOAR Connector App 中試用 Observability 事件。

還不是 Splunk Observability 客戶但正在使用其他 Splunk 產品？您現在可以註冊開始免費試用 Splunk Observability Cloud 產品套件！

 

作者

Jeremy Hicks

Jeremy Hicks 是多家財星 500 大 (Fortune 500) 電子商務公司的可觀測性推廣大使和 SRE 專家。他對監控、韌性工程、雲端運算和開發營運實務極具熱情，為可觀測性領域提供了獨特的觀點。

返回上一頁