最近考慮日志收集的事情，主要出發點是：
1、在問題出現后能方便快速地收集相關的線索和證據，幫助快速定位和解決問題。因為反饋問題往往在發生之后，如果在這個時候能快速方便地拿到有用信息是件很舒服的事情，而在獲取日志這塊，我們目前的體驗應該是不太好的。
2、發現潛在問題：通過收集一段時間的實際運行日志來分析，發現使用過程中存在的潛在問題。這樣能發現一些平時未曾暴露或未被成功反饋的問題，幫助我們去完善產品，進而增進產品的穩定性并提升用戶體驗。

? ? 然而要想做到這些，還是有不少挑戰。其中一個要點則是日志的內容——除了通常的程序執行或命令調用的報錯信息，更有意義的應該還是針對性的一些內容。比如，運行過程中的重啟及重新安裝等非常規操作、特定接口調用的錯誤及超時等異常狀況、發生頻率超出正常范圍的重連及出錯、結合業務特點的一些情況等。而這些往往需要預先設計，并且配合工具和人工的分析去達到效果。

? ? 然后就是實現的機制，最好能做到自動上報和事后一鍵采集。當系統識別到預設的特定錯誤條件時，程序自動標定上報點，并根據需要定時或實時采集日志。這種方式應該能降低使用難度，減少對人工的依賴，還能有效減輕采集工作的負擔。

? ? 另外，這個事情似乎不太可能一次性就做得完善，需要在過程中根據情況不斷總結、調整和完善。

這種方式相對于主動分析優化去提升程序的穩定性而言，應該是相輔相成的，屬于目的一致的兩種方法。