阿里雲帳號代開 阿裡雲日誌服務（SLS）Logtail 收集日誌失敗（狀態碼 404/主機未心跳）排查

先分清兩種問題

很多人一看到 Logtail 報錯，就把 404 和主機未心跳當成同一件事，其實它們指向的層面不同。404 更像是請求到了服務端，但服務端找不到對應資源，常見於 project、logstore、地域、配置名寫錯；主機未心跳則意味著機器組裡的主機沒有把心跳報上來，通常是 Logtail 進程沒跑、機器組綁錯、網路出站被擋，或者採集端與控制台之間斷聯。

排查的順序也應該不同。遇到主機未心跳，先看代理是否活著、機器是否綁對；遇到 404，先看採集配置和目標資源是否存在。把這兩類問題混在一起處理，最容易在配置細節上兜圈子。

先確認 Logtail 是否真的在工作

阿里雲帳號代開 不管報的是什麼錯，第一步都不要急著改配置，先確認採集端是否正常運行。很多現場問題的根源很簡單：Logtail 服務沒啟動、升級後進程異常退出、安裝目錄被刪掉，或者安全軟件把它攔住了。

看進程和服務狀態

Linux 環境下，可以先看服務和進程是否存在：

systemctl status logtaild
ps -ef | grep logtail

如果服務不存在，先確認安裝是否完成；如果進程在，但服務顯示異常，重點看退出碼和最近的日志。Windows 環境也要看服務面板裡對應的採集服務是否啟動，是否被手工停掉。

查看本地日志

Logtail 自己的日志通常比控制台報錯更接近真相。它會直接寫出連不上哪個地址、哪個配置下發失敗、哪個文件打開失敗。你要找的不是一句籠統的錯誤，而是可定位的關鍵詞，比如心跳失敗、配置拉取失敗、權限不足、文件不存在、解析失敗。

如果日志裡已經出現多次重試、超時、連接重置，說明問題很可能不在 SLS 服務本身，而在本機網路或代理層。

主機未心跳怎麼查

主機未心跳的意思很直白：控制台看不到這台機器按時上報狀態。這時候不要先盯著採集內容本身，而要回到機器組和代理連通性。

檢查機器組綁定

很多心跳問題其實是綁錯機器組。比如你在 A 地域創建了採集配置，卻把機器加進了 B 地域的機器組；或者新建了機器組，卻沒有把實例真正加入。還有一類常見情況是使用了錯誤的 UUID，導致控制台顯示的是另一台機器，現在這台自然就像失聯一樣。

處理這類問題時，先核對三件事：地域是否一致，機器組是否正確，主機標識是否對應到當前實例。只要其中一項出錯，心跳就不會正常出現。

阿里雲帳號代開 檢查出站網路

Logtail 需要穩定訪問日誌服務接口。如果出站 443 被防火牆、雲安全組、代理或公司網關攔住，心跳就會斷。這種斷聯未必是完全無網，可能只是 DNS 解析正常、瀏覽器也能上網，但對 SLS 的接口被策略限制了。

排查時不要只看能不能 ping 通。更有價值的是測試域名解析、HTTPS 連通和代理配置。若機器走代理上網，還要確認 Logtail 是否已正確配置代理，或者代理是否允許相關域名通過。很多現場都是因為代理鑑權改了、CA 替換了、白名單沒加全，導致心跳在表面上看不出明顯異常，實際已經斷了。

檢查時間同步

阿里雲帳號代開 時間偏差看起來是小問題，實際上很容易把心跳和配置下發搞亂。當系統時間漂移過大，請求簽名、證書校驗、重試節奏都可能受影響。尤其是剛從休眠恢復、虛擬機遷移、NTP 失效之後，先校時再排查會省很多時間。

404 一般意味著什麼

如果不是心跳問題，而是上報時直接報 404，通常要先理解這個 404 是從哪裡來的。它不一定代表網站不存在，更常見的是請求的資源名、地域、project、logstore 或採集配置路徑不對。也就是說，服務端收到了請求，但找不到對應目標。

核對 project 和 logstore

最容易出錯的是名稱寫錯，尤其是測試環境和正式環境名稱相近時。比如 logstore 已經刪除、重建過，或者採集配置還在指向舊名字。還有些團隊會在不同地域建立同名資源，表面看起來沒問題，實際請求打到了錯的地域，最後返回 404。

這類問題的排查原則很簡單：不是只看控制台上有沒有同名項，而是要對照採集配置裡的目標、地域和實際資源狀態，逐項核實。

核對採集配置內容

採集配置本身也可能讓服務端找不到目標。比如路徑寫成不存在的目錄、通配符沒有命中實際文件、分隔符設置不對，或者文件編碼和解析規則衝突。這些情況下，Logtail 可能不是完全不工作，而是一直在讀一個不存在或不匹配的源，自然就會在上游看起來像 404 或無數據。

如果是容器環境，還要看掛載路徑是否一致。宿主機上的目錄和容器內的目錄不是一回事，採集規則若只寫了宿主路徑，容器裡當然找不到。

檢查權限和文件可讀性

404 有時候是資源名不對，有時候是採集端根本讀不到文件，只能把問題表現成目標不存在。比如日誌文件權限過緊，Logtail 運行用戶沒有讀權限；或者文件被應用程序頻繁重命名，採集器抓到的是舊 inode。這類問題不一定會直接報權限拒絕，反而常常以讀不到文件、文件切換失敗、采集位置空白的方式表現出來。

一套更實用的排查順序

現場排障最怕來回跳。建議按下面順序來，效率會高很多。

• 先看 Logtail 服務是否啟動，進程是否常駐。
• 再看本地日志，抓第一條真正的錯誤，而不是最後一條重試信息。
• 接著確認機器組、地域、UUID、採集配置是否一一對應。
• 然後測網路出站、DNS、代理和防火牆策略。
• 最後才回到文件路徑、權限、編碼和解析規則。

這個順序的好處是先排掉面最廣的問題，再去處理細節。很多 404 和未心跳，看上去很像配置錯，其實根本原因只是服務沒起來或網路不通。反過來，一旦你先改採集規則，很容易把真正的故障點遮住。

兩個常見案例

案例一：機器組正常，實際是出站被攔

有一次控制台裡機器一直顯示主機未心跳，工程師第一反應是重新安裝 Logtail。結果安裝完成後依然一樣。最後查到是機房新加了出站規則，只放行了少數域名，SLS 的接口沒有在白名單內。因為 DNS 還能解析，表面上看不出異常，所以前半天都在誤判。

這類場景的特徵是本地服務看起來正常，重試也在發生，但心跳就是不上來。只要把域名和 HTTPS 出站放開，問題通常會立刻消失。

案例二：404 不是服務壞了，而是地域配錯

另一個常見場景是採集配置引用了正確的 project 名，卻把地域選成了另一個區域。由於名稱看起來完全一致，排查時很容易忽略。實際上服務端在錯誤地域裡找不到對應資源，返回的就是 404。這種問題最有效的辦法不是反覆重試，而是把地域、project、logstore 三個字段逐項對照。

把問題一次性收斂

如果你希望把這類問題徹底收斂，最重要的不是記住某個報錯代碼，而是建立一個固定的排障習慣。先看服務，再看心跳，再看配置，再看網路，最後看文件。只要流程固定，很多看似複雜的問題都能在幾分鐘內鎖定方向。

另外，日常運維最好養成三個習慣：一是變更後立刻驗證心跳和採集結果；二是機器組、採集配置、地域變更要同步記錄；三是把 Logtail 日志留足，出問題時有據可查。這些做法看起來平常，真正出故障時卻最省時間。

結語

阿里云 SLS 裡的 Logtail 收集失敗，表面上常常只是 404 或主機未心跳，但背後往往是不同層面的問題。404 更偏向資源和配置，主機未心跳更偏向進程和網路。只要把兩者分開看，按照服務、心跳、網路、配置、文件的順序逐步排查，大部分問題都能準確定位，不必靠猜，也不必反覆試錯。