DevOps Taiwan - Monitoring Tools 大亂鬥 - 提問募集

感謝大家今天的參與，大亂鬥順利舉辦完畢，因為時間緣故以下的題目無法全數讓講者們一一回答，歡迎大家持續在社群當中提出與更多社群朋友一起討論喔！

• 活動時間：2018/5/26 14:00 ~ 17:30
• 活動地點：松江101國際會議中心（104台北市中山區松江路101號4樓）
• 票價：300 元
• 活動人數：150 人
• 活動報名：https://devops.kktix.cc/events/monitoring-tools

本場活動將有一段「綜合座談」的時間，歡迎各位直接在此共筆文件中提出各種與 Monitoring 相關的問題，我們將會於該時段詢問各位講者，讓大家能彼此交流相關經驗。

請將問題條列如下，謝謝

（歡迎編輯此清單，提出更多問題～）

1. 可否分享一些你畢生難忘的監控異常事件？
2. 你挑選 Monitoring Tools 時，你會根據哪些項目來選擇工具？
3. 你是如何 Monitoring Monitoring systems？
4. 你目前比較常監控的環境（目標對象），你會監控哪些指標（Metric）？告警的條件又是？
5. 你如何確認你設置的監控指標、告警條件是否正確？是否能正確用來識別服務為正常狀態？
6. 請問如何長期保存監控系統的資料，而不影響系統效能？
7. 針對累積的監控資料，你們會進行後續的分析與利用嗎？會運用在哪些方面？
8. 大量監控項目所形成的資料，資料庫該如何優化？需要優化那些項目才好？
9. 請問監控系統有再串接別的系統來達到自動化處理系統障礙的目標？
10. 關於 Dashboard 的規劃，有沒有什麼建議與經驗可以分享？會區分給不同對象與載具查看的 Dashboard？
11. 如何有效的監控 API 運作情形，API 端開發是否有需要對應的處理?
12. 若是自有機房，如何正確的紀錄所有機器資訊？(OS version, CPU, RAM, Disk..etc)
13. 如果針對於 docker 或 kubernetes 的環境，內部的ip是不固定的，有何方法進行自動發現並監控呢？當該服務不存在時，又有何方法能從 dasboard 上自動消失呢？
14. 是否可以分享針對不同量級（10 ~ 100、100 ~ 500、超過1000 ~）的監控對象，分享您的經驗？像是會遇到的雷與坑？
15. 針對公司已經有許多舊有的監控系統，如何整合或是替換，分享技術方面與人溝通方面的挑戰
16. 在講座中有提到 ELK 的監控上會帶來較高的成本，因此會搭配其他監控服務，請問如何選擇及整合哪種工具，才能達到成本與效能的最佳組合呢？

刪除線的部份為當天來不及探討的題目。