作者：Almudena Sanz Olivé, Katrin Freihofner, Tom Grabowski

通過本指南，你的 SRE 團隊可以實現增強的警報修復和事件管理。

可觀測性 AI 助手可幫助用戶使用自然語言界面探索和分析可觀測性數據，利用自動函數調用來請求、分析和可視化數據，將其轉換為可操作的可觀測性。 該助手還可以建立一個由 Elastic Learned Sparse EncodeR (ELSER) 提供支持的知識庫，以提供來自私人數據的附加上下文和建議，以及使用 RAG（檢索增強生成）的大型語言模型 (LLM)。 Elastic 的 Stack — 作為一個向量數據庫，具有開箱即用的語義搜索以及 LLM 集成和可觀測性解決方案的連接器 — 是一個完美的工具包，可以將公司獨特的可觀測性知識與生成式 AI 相結合，從而獲得最大價值。

增強 SRE 故障排除

由于資源分散且可能過時，大型組織中的站點可靠性 (SRE) 在查找必要的工程師信息以排除警報、監控系統或獲取見解方面經常面臨挑戰。 對于經驗不足的 SRE 來說，這個問題尤其重要，即使有操作手冊，他們也可能需要幫助。 重復發生的事件會帶來另一個問題，因為待命人員可能缺乏對之前解決方案和后續步驟的了解。 成熟的 SRE 團隊通常會投入大量時間來改進系統，以最大程度地減少 “救火”，并利用廣泛的自動化和文檔來支持待命人員。

Elastic? 通過使用 RAG 將生成式 AI 模型與內部數據的相關搜索結果相結合來應對這些挑戰。 Observability AI Assistant 的內部知識庫由我們的語義搜索檢索模型 ELSER 提供支持，可以在對話過程中的任何時刻回憶信息，并根據內部知識提供 RAG 響應。

該知識庫可以通過你組織的信息來豐富，例如操作手冊、GitHub 問題、內部文檔和 Slack 消息，從而允許 AI 助手提供特定幫助。 在排除問題時，助手還可以記錄和存儲與 SRE 正在進行的對話中的特定信息，從而有效地創建操作手冊以供將來參考。 此外，助手還可以生成事件摘要、系統狀態、操作手冊、事后分析或公告。

這種檢索、總結和呈現上下文相關信息的能力對于 SRE 團隊來說是一個游戲規則改變者，將工作從追逐文檔和數據轉變為直觀的、上下文敏感的用戶體驗。知識庫（請參閱需求）充當中央存儲庫。的可觀察性知識，打破文檔孤島并整合部落知識，使借助 LLMs 的力量增強的 SRE 可以訪問這些信息。

你的 LLM 提供商在使用人工智能助手時可能會收集查詢遙測數據。 如果你的數據屬于機密或包含敏感細節，我們建議你驗證你向 AI 助手提供的 LLM 連接器的數據處理政策。

在這篇博文中，我們將介紹通過內部信息豐富你的知識庫 (KB) 的不同方法。 我們將重點關注特定警報，該警報表明帶有 “502 Bad Gateway” 錯誤的日志數量有所增加，并且已超出警報的閾值。

如何使用知識庫對警報進行故障排除

在知識庫充實內部信息之前，當 SRE 向 AI 助手詢問如何解決警報問題時，LLM 的響應將基于其在訓練期間學到的數據； 然而，LLM 無法回答與私人、近期或新興知識相關的問題。 在這種情況下，當詢問解決警報問題的步驟時，響應將基于通用信息。

但是，一旦你的操作手冊豐富了知識庫，當你的團隊收到有關 “502 Bad Gateway” 錯誤的新警報時，他們可以使用 AI Assistant 訪問內部知識來排除故障，使用語義搜索在知識庫。

在本博客中，我們將介紹向知識庫添加有關如何排除警報故障的內部信息的不同方法：

1. 讓助手記住現有操作手冊的內容。
2. 要求助手總結對話期間采取的步驟并將其存儲在知識庫中，并將其存儲為操作手冊。
3. 使用我們的連接器和 API 將你的 Runbook 從 GitHub 或其他外部源導入到知識庫。

將操作手冊添加到知識庫后，AI 助手現在可以調用操作手冊中的內部信息和特定信息。 通過利用檢索到的信息，LLM 可以提供更準確和相關的建議來解決警報問題。 這可能包括建議警報的潛在原因、解決問題的步驟、未來事件的預防措施，或要求助理使用功能幫助執行操作手冊中提到的步驟。 有了更準確、更相關的信息，SRE 可能會更快地解決警報，從而減少停機時間并提高服務可靠性。

你的知識庫文檔將存儲在索引 .kibana-observability-ai-assistant-kb-* 中。 請記住，LLMs 對模型一次可以讀取和寫入的信息量有限制，稱為 token 限制。 想象一下，你正在讀一本書，但一次只能記住一定數量的單詞。 一旦達到這個限制，你就會開始忘記之前讀過的單詞。 這類似于 LLM 中 token 限制的工作方式。

為了使操作手冊保持在檢索增強生成 (RAG) 模型的 token 限制內，請確保信息簡潔且相關。 為了清晰起見，使用要點，避免重復，并使用鏈接獲取附加信息。 定期查看和更新??操作手冊，刪除過時或不相關的信息。 目標是提供清晰、簡潔、有效的故障排除信息，而不會因 token 限制限制而影響質量。 LLM 非常適合總結，因此你可以要求 AI 助手幫助你使操作手冊更加簡潔。

讓助手記住現有操作手冊的內容

將操作手冊存儲到知識庫的最簡單方法就是讓人工智能助手去做！ 打開一個新對話并詢問 “Can you store this runbook in the KB for future reference? - 你可以將此操作手冊存儲在知識庫中以供將來參考嗎？” 然后以純文本形式粘貼操作手冊的內容。

然后 AI 助手會自動幫你存入知識庫，就這么簡單。

讓助手總結對話期間采取的步驟并將其存儲在知識庫中

你還可以要求 AI 助手在對話時記住一些內容 - 例如，在使用 AI 助手解決了警報問題后，你可以要求 “remember how to troubleshoot this alert for next time. - 記住下次如何解決此警報問題”。 AI 助手將創建對警報進行故障排除所采取的步驟的摘要，并將其添加到知識庫中，從而有效地創建操作手冊以供將來參考。 下次你遇到類似的情況時，AI 助手會回憶起這些信息并用它來幫助你。

在下面的演示中，用戶要求助手記住為解決警報的根本原因而遵循的步驟，并在這種情況再次發生時對 Slack 通道執行 ping 操作。 在后來與助手的對話中，用戶詢問類似問題可以做什么，AI 助手能夠記住這些步驟，并提醒用戶 ping Slack 通道。

收到警報后，你可以打開 AI 助手聊天并測試排除警報。 調查警報后，請 AI 助手總結分析結果以及針對根本原因采取的步驟。 為了下次記住它們，我們有一個類似的警報并添加額外的指令，例如警告 Slack 通道。

助手將使用內置功能總結步驟并將其存儲到你的知識庫中，以便在將來的對話中調用。

打開一個新對話，詢問在對與我們剛剛調查的警報類似的警報進行故障排除時應采取哪些步驟。 助手將能夠使用基于 ELSER 的語義搜索來調用存儲在 KB 中的與特定警報相關的信息，并提供故障排除步驟的摘要，包括通知 Slack 通道的最后指示。

使用 API 或我們的 GitHub 連接器將存儲在 GitHub 中的 Runbook 導入知識庫

你還可以通過將專有數據（例如 GitHub 問題、Markdown 文件、Jira 票證、文本文件）提取到 Elastic 中，以編程方式將專有數據添加到知識庫中。

如果你的組織已創建存儲在 GitHub 中的 Markdown 文檔中的 Runbook，請按照本博客文章下一部分中的步驟將 Runbook 文檔索引到你的知識庫中。

將文檔引入知識庫的步驟如下：

將你組織的知識吸收到 Elasticsearch 中

選項 1：使用 Elastic 網絡爬蟲。 使用網絡爬蟲以編程方式從網站和知識庫中發現、提取和索引可搜索內容。 當你使用網絡爬蟲獲取數據時，會創建一個搜索優化的 Elasticsearch? 索引來保存和同步網頁內容。

選項 2：使用 Elasticsearch 的 index API。 觀看演示如何使用 Elasticsearch 語言客戶端從應用程序獲取數據的教程。

選項 3：構建你自己的連接器。 請按照此博客中描述的步驟操作：如何為 Elasticsearch 創建自定義連接器。

選項 4：使用 Elasticsearch Workplace 搜索連接器。 例如，GitHub 連接器可以自動捕獲、同步和索引問題、Markdown 文件、拉取請求和存儲庫。

• 按照步驟在 GitHub 中配置 GitHub 連接器，以從 GitHub 平臺創建 OAuth 應用程序。

• 現在你可以將 GitHub 實例連接到你的組織。 前往你組織的 “Search”>“Workplace Search” 管理儀表板，然后找到 “Sources” 選項卡。

• 在已配置?Sources?列表中選擇 GitHub（或 GitHub Enterprise），然后按照所示的 GitHub 身份驗證流程進行操作。 身份驗證流程成功后，你將被重定向到工 Workplace Search，并提示你選擇要同步的組織。

• 配置連接器并選擇組織后，內容應該同步，你將能夠在 Sources 里看到它。 如果你不需要對所有可用內容建立索引，你可以通過 API 指定索引規則。 這將有助于縮短索引時間并限制索引的大小。 請參閱自定義索引。

• Source 已在 Elastic 中創建了一個索引，其中包含來自你組織的內容（issues、Markdown 文件……）。 你可以通過導航到 “Stack Management” > “Index Management”，激活右側的 “?Include hidden Indices” 按鈕，然后搜索 “GitHub” 來找到索引名稱。

你可以通過創建數據視圖 (Data View) 并在 “Discover” 中探索來探索已索引的文檔。 轉到 Stack Management > Kibana > Data Views > Create data view 并輸入數據視圖名稱、索引模式（確保在高級選項中激活 “Allow hidden and system indices” ）和時間戳字段：

• 你現在可以使用數據視圖瀏覽 Discover 中的文檔：

使用其語義搜索管道將你的內部操作手冊重新索引到 AI 助手的知識庫索引中

你的知識庫文檔存儲在索引 .kibana-observability-ai-assistant-kb-* 中。 要將從 GitHub 導入的內部 Runbook 添加到知識庫，你只需將文檔從上一步中創建的索引重新索引到知識庫的索引即可。 要向知識庫中的文檔添加語義搜索功能，重新索引還應使用為知識庫預先配置的 ELSER 管道，.kibana-observability-ai-assistant-kb-ingest-pipeline。

通過使用知識庫索引創建數據視圖，你可以探索 Discover 中的內容。

你在 “Management” > “DevTools” 中執行以下查詢，確保在 “_source” 和 “inline” 上替換以下內容：

• InternalDocsIndex ：存儲內部文檔的索引名稱
• text_field ：包含內部文檔文本的字段名稱
• timestamp : 內部文檔中時間戳字段的名稱
• public ：（true 或 false）如果為 true，則使文檔可供定義的 Kibana 空間（如果已定義）或所有空間（如果未定義）中的所有用戶使用； 如果為 false，文檔將僅限于中指定的用戶
• （可選） space ：如果定義，則限制內部文檔在特定的 Kibana 空間中可用
• （可選） user.name ：如果定義，則限制內部文檔可供特定用戶使用
• （可選）“query” 過濾器僅索引某些文檔（見下文）

POST _reindex
{"source": {"index": "<InternalDocsIndex>","_source": ["<text_field>","<timestamp>","namespace","is_correction","public","confidence"]},"dest": {"index": ".kibana-observability-ai-assistant-kb-000001","pipeline": ".kibana-observability-ai-assistant-kb-ingest-pipeline"},"script": {"inline": "ctx._source.text=ctx._source.remove(\"<text_field>\");ctx._source.namespace=\"<space>\";ctx._source.is_correction=false;ctx._source.public=<public>;ctx._source.confidence=\"high\";ctx._source['@timestamp']=ctx._source.remove(\"<timestamp>\");ctx._source['user.name'] = \"<user.name>\""}
}

你可能想要指定在知識庫中重新索引的文檔類型 - 例如，你可能只想重新索引 Markdown 文檔（如 Runbook）。 你可以向源中的文檔添加 “query” 過濾器。 對于 GitHub，Runbook 使用包含字符串 “file” 的 “type” 字段進行標識，你可以將其添加到重新索引查詢中，如下所示。 要添加 GitHub 問題，你還可以在查詢 “type” 字段中包含字符串 “issues”：

"source": {"index": "<InternalDocsIndex>","_source": ["<text_field>","<timestamp>","namespace","is_correction","public","confidence"],"query": {"terms": {"type": ["file"]} }

太棒了！ 現在數據已存儲在你的知識庫中，你可以向 Observability AI Assistant 詢問有關它的任何問題：

結論

綜上所述，利用內部的可觀察性知識并將其添加到彈性知識庫中可以極大地增強 AI 助手的能力。 通過手動輸入信息或以編程方式攝取文檔，SRE 可以創建一個可通過 Elastic 和 LLM 的功能訪問的中央知識存儲庫。 人工智能助手可以調用這些信息，協助處理事件，并使用檢索增強生成為特定環境提供定制的可觀察性。 通過遵循本文中概述的步驟，組織可以釋放其 Elastic AI Assistant 的全部潛力。

立即開始使用 Elastic AI Assistant 豐富你的知識庫，并為你的 SRE 團隊提供卓越所需的工具。 按照本文中概述的步驟操作，將你的事件管理和警報修復流程提升到新的水平。 你邁向更高效、更有效的 SRE 運營的旅程現在就開始了。

本文中描述的任何特性或功能的發布和時間安排均由 Elastic 自行決定。 當前不可用的任何特性或功能可能無法按時交付或根本無法交付。

在這篇博文中，我們可能使用或引用了第三方生成人工智能工具，這些工具由其各自所有者擁有和運營。 Elastic 對第三方工具沒有任何控制權，我們對其內容、操作或使用不承擔任何責任，也不對你使用此類工具可能產生的任何損失或損害負責。 使用人工智能工具處理個人、敏感或機密信息時請務必謹慎。 你提交的任何數據都可能用于人工智能培訓或其他目的。 無法保證你提供的信息將得到安全或保密。 在使用之前，你應該熟悉任何生成式人工智能工具的隱私慣例和使用條款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相關標志是 Elasticsearch N.V. 的商標、徽標或注冊商標。 在美國和其他國家。 所有其他公司和產品名稱均為其各自所有者的商標、徽標或注冊商標。

原文：Enhancing SRE troubleshooting with the AI Assistant for Observability and your organization's runbooks | Elastic Blog