大家星期五快樂！ 朋友們，今天我們繼續致力於該課程的系列出版物 ，因為該課程的新組的課程將於下週末開始。 那麼，就讓我們開始吧！
監控是 只是。 這是眾所周知的事實。 啟動 Nagios，在遠端系統上執行 NRPE，在 NRPE TCP 連接埠 5666 上設定 Nagios，然後您就可以進行監控了。
這太簡單了，一點也不有趣。 現在您已經有了 CPU 時間、磁碟子系統、RAM 的基本指標，這些指標預設提供給 Nagios 和 NRPE。 但這其實並不是「監控」。 這只是個開始。
（通常他們會安裝 PNP4Nagios、RRDtool 和 Thruk，在 Slack 中設定通知並直接進入 nagiosexchange，但我們暫時不考慮這一點）。
良好的監控 實際上相當複雜，您確實需要了解您正在監視的應用程式的內部結構。
監控很難嗎？
任何伺服器，無論是 Linux 還是 Windows，根據定義都會有一定的用途。 Apache、Samba、Tomcat、檔案儲存、LDAP——所有這些服務在一個或多個方面或多或少都是獨特的。 每個都有自己的功能，自己的特點。 當伺服器處於負載狀態時，有多種方法可以取得您感興趣的指標、KPI（關鍵效能指標）。
照片作者 上
（我希望我的儀表板是霓虹藍的 - 夢幻般地嘆息 - ... 嗯...）
任何提供服務的軟體都必須有收集指標的機制。 Apache有一個模組 mod-status，顯示伺服器狀態頁面。 Nginx 有 - stub_status。 Tomcat 具有顯示關鍵指標的 JMX 或自訂 Web 應用程式。 MySQL 有一個指令「顯示全域狀態」等。
那麼，開發人員為什麼不在他們創建的應用程式中建立類似的機制呢？
只有開發商才會這樣做嗎？
對指標嵌入的某種程度的漠不關心不僅限於開發人員。 我曾在一些公司工作過，他們使用 Tomcat 開發應用程序，但沒有提供任何自己的指標，也沒有服務活動日誌，除了一般的 Tomcat 錯誤日誌。 有些開發人員會產生大量日誌，而這些日誌對於不幸在凌晨 3:15 讀取的系統管理員來說毫無意義。
照片作者 上
使此類產品得以發布的系統工程師也必須對這種情況承擔一定的責任。 很少有系統工程師有時間或精力嘗試從日誌中提取有意義的指標，而沒有這些指標的上下文以及根據應用程式活動解釋它們的能力。 有些人不明白除了「目前（或很快）出現錯誤」的指標之外，他們還能如何從中受益。
不僅開發人員必須改變對指標需求的看法，系統工程師也必須改變這個想法。
對於任何不僅需要回應關鍵事件，而且還需要確保它們不會發生的系統工程師來說，缺乏指標通常是這樣做的障礙。
然而，系統工程師通常不會修改代碼來為公司賺錢。 他們需要首席開發人員了解系統工程師在識別問題、提高對效能問題的認識等方面的責任的重要性。
這就是開發的東西
DevOps 心態描述了開發 (dev) 和營運 (ops) 思維之間的協同作用。 任何聲稱「做 DevOps」的公司必須：
- 說一些他們可能不會說的話（指的是公主新娘模因 - “我不認為這意味著你認為的意思！”）
- 鼓勵持續改進產品的態度。
如果您不知道產品目前的工作原理，那麼您就無法改進產品並知道它已經改進。 如果你不了解產品的組件如何運作、它所依賴的服務、它的主要痛點和瓶頸，你就無法知道產品是如何運作的。
如果您不注意潛在的瓶頸，那麼在事後分析時您將無法遵循「五個為什麼」技術。 您將無法將所有內容放在一個螢幕上來查看產品的工作原理或知道它看起來如何「正常且快樂」。
左移，左移，我說李伊——
對我來說，DevOps 的關鍵原則之一是「左移」。 在這種情況下左移意味著改變可能性（沒有責任，但僅限於功能）來完成系統工程師通常關心的事情，例如建立效能指標、更有效地使用日誌等，在軟體交付生命週期的左側。
照片作者 上
軟體開發人員必須能夠使用並了解公司使用的監控工具，以便以所有形式、指標、日誌記錄、監控介面進行監控，最重要的是， 觀看他們的產品在生產中如何運作。 你無法讓開發人員投入精力和時間進行監控，除非他們能夠看到指標並影響他們的外觀、產品負責人在下一次簡報中向 CTO 展示的方式等。
簡而言之
- 把你的馬牽到水邊。 向開發人員展示他們可以為自己避免多少麻煩，幫助他們為應用程式確定正確的 KPI 和指標，這樣就可以減少產品負責人被 CTO 吼叫的情況。 溫柔而平靜地將它們帶入光明中。 如果這不起作用，則賄賂、威脅和哄騙他們或產品負責人盡快從應用程式中獲取這些指標，然後繪製圖表。 這將很困難，因為它不會被視為優先事項，而且產品路線圖將有許多創收項目懸而未決。 因此，您需要一個業務案例來證明在產品中實施監控所花費的時間和費用是合理的。
- 幫助系統工程師睡個好覺。 向他們表明，對任何正在發布的產品使用「讓我們發布」清單是一件好事。 確保生產中的所有應用程式都包含指標將幫助您在晚上睡得更好，因為開發人員可以看到問題所在以及問題所在。 然而，激怒和挫敗任何開發人員、產品負責人或首席技術長的正確方法是堅持和抵制。 如果您再次等到最後一刻，這種行為將影響任何產品的發布日期，因此請再次左移並儘快將這些問題納入您的專案計劃中。 如有必要，請參加產品會議。 戴上假鬍子和毛氈什麼的，絕對不會失敗。 表達您的擔憂，展示明顯的好處，並傳播福音。
- 確保開發 (dev) 和營運 (ops) 都了解產品指標進入紅色區域的含義和後果。 不要讓維運成為產品健康的唯一守護者，確保開發人員也參與其中（#productsquads）。
- 日誌是好東西，但指標也是。 將它們結合起來，不要讓你的日誌變成一個無用的巨大燃燒球中的垃圾。 向開發人員解釋並向他們展示為什麼沒有人能夠理解他們的日誌，向他們展示在凌晨 3:15 查看無用的日誌是什麼感覺。
照片作者 上
就這樣。 新資料將於下週發布。 如果您想了解更多關於課程的信息，我們邀請您 ，將於週一舉行。 現在我們按照慣例等待您的評論。
來源： www.habr.com