了解如何可以建立一個早期預警系統，為您的網站的更重要的錯誤，使用服務器日志，看看你應該注意什么。
隨著網絡變得越來越復雜，使用JavaScript框架和庫的前端網站進行網絡應用，單頁應用程序，json-ld，等等，我們越來越多地看到一個更大的表面積出錯。當所有你所得到的是HTML和CSS的鏈接，那么你就有很多混亂。然而，在當今世界的動態生成網站通用JS接口，有很大的誤差空間。

我們面臨的第二個問題是，很難知道什么時候發生了什么問題，或者當谷歌改變了他們如何處理的事情。這是只有當你考慮像復合站點遷移情況或重新設計，在那里你會突然檔案大量舊內容，或重新映射的URL結構。那么，我們如何應對這些挑戰呢？

舊的方式

從歷史上看，你這樣的分析的方式是通過查看您的日志文件，使用的是，或，如果你是鐵桿，日志分析器。這些都是偉大的，但他們需要你知道你有一個問題，或者說，你在尋找和發生的一段日志，有問題的你需要解決的問題。不是不可能的，我們已經寫了這樣做相當廣泛，在我們的博客和我們的日志文件分析指南。

深圳網站制作案例分享:易菲YIFINI
要停止網站鏈接

然而，這個問題是相當明顯的。它需要你的樣子，而不是讓你意識到有東西要找。考慮到這一點，我想我會花一些時間調查是否有可以做的事情，使整個過程花費更少的時間，并作為一個早期預警系統。

援助之手

我們需要做的第一件事是讓我們的服務器在某處發送日志文件。我的標準解決方案，這已成為使用日志旋轉。這取決于你的服務器，你可以使用不同的方法來做到這一點，但在Nginx的它看起來像這樣：
# time_iso8601 looks like this: 2016-08-10T14:53:00+01:00
if ($time_iso8601 ~ "^(d{4})-(d{2})-(d{2})") {
        set $year $1;
        set $month $2;
        set $day $3;
}

access_log /var/log/nginx/$year-$month-$day-access.log;
這允許您查看任何特定日期或日期集的日志，簡單地將數據從與該期間有關的文件中拔起。設置日志的旋轉，我們就可以建立一個腳本，我們會在午夜使用cron，把日志文件，涉及昨日的數據和分析。如果你想，你可以每天看幾次，或每周一次，或在任何時間間隔最適合你的數據量水平。

下一個問題是：我們要尋找什么？嗯，一旦我們有了一天的日志，這是我得到我的系統報告：
30 *狀態碼

生成一個由用戶產生的所有頁面的列表，導致重定向。如果鏈接到該資源的頁面在您的網站上，將其重定向到實際的結束點。否則，聯絡人聯系你讓他們排序鏈接到它應該去的地方。

404狀態碼

類似的故事。任何404ing資源應進行檢查以確保他們應該失蹤。任何應該是有可以調查為什么它沒有解決，并鏈接到任何實際丟失的可以處理在相同的方式作為一個301 / 302代碼。

50 *狀態碼

一些糟糕的事情發生了，你不會有一個好的一天，如果你看到許多50 *代碼。您的服務器正在死亡的請求到特定的資源，或可能是你的整個網站，這取決于到底有多壞這是。

爬行預算

谷歌抓取的每一個資源列表，有多少次被請求，多少個字節被傳送，以及時間來解決這些請求。比較這個與你的網站地圖，以找到網頁，谷歌不會爬行，或它的錘擊，并根據需要修復。

頂部/至少請求的資源

類似上述，但詳細介紹了搜索引擎的最和最不要求的東西。

壞演員

許多機器人尋找漏洞會要求像wp_admin，wp_login，404s，config.php，和其他類似的公共資源的URL。使對這些類型的網址的重復請求的任何IP地址可以自動添加到一個IP黑名單。

模式匹配的網址報告

使用正則表達式匹配請求的URL與預定義的模式很簡單，在你的網站或頁面類型的特定區域報告。例如，你可以對圖像的請求報告，JavaScript文件被調用，分頁，表單提交（通過尋找POST請求），逃跑的片段，查詢參數，或幾乎任何其他。它提供的一個URL和HTTP請求，你可以將它設置為一個片段進行報道。

尖尖的搜索抓取行為

日志由Googlebot請求數量的每一天。如果它增加超過百分之十，這是感興趣的東西。作為一個側面說明，與大多數數字系列，一個計算，以點極端的異常值是不難創造，而且很可能是值得你的時間。
輸出數據

根據任何特定部分的重要性，您可以將數據設置為以兩種方式登錄。首先，大量的40 *和50 *狀態代碼或壞演員的要求將是值得觸發一個電子郵件。這可以讓你很快知道，如果發生的事情，這可能表明一個大問題。然后，你可以得到的頂部，無論是什么，并解決它作為一個優先事項。

作為一個整體的數據也可以通過一個儀表板上的報告。如果你每天的日志中沒有這么多的數據，你可能只想在運行時查詢文件，并在你查看它的時候生成報告新鮮。另一方面，大量的流量的網站，因此更大的日志文件可能要緩存每天的輸出到一個單獨的文件，所以數據不必計算。很明顯，你使用的方法的類型取決于你將在規模上運行的規模和你的服務器硬件是如何強大的。

結論

由于服務器日志和基本的腳本，沒有理由你應該有一個的情況下，某些地方的問題在您的網站上，你不知道。技術問題，主動通知是在一個世界里，谷歌會以更快的速度的一個必要的事情，這意味著他們可以開始把你的排名下降幾小時內到現場停機或錯誤，謝謝。