→ luoqr: 把LS多包一層當成自己的程式 然後自己插自己!(誤) 03/10 23:33
→ cowbaying: CLASSLOADER? 03/11 13:17
→ qrtt1: 機器不給力時就該換機器啊 03/11 17:08
我想我得解釋清楚一點(但說起來好累啊)，
倒也不是機器給不給力的問題...
是我們使用ELKstack這個東西，
我們使用架構也如同官方說明:
https://www.elastic.co/guide/en/logstash/5.2/
deploying-and-scaling.html#deploying-message-queueing
(抱歉...請自己接上連結，PTT縮址會被限制發文QQ)
整套ELKstack分散在四台機器上，跟各個要收log的host，
問題就在環境不穩，動不動就網路不通、或者硬碟突然被塞滿、
甚至莫名其妙VM掉下來(不要問我為什麼，我也不想這樣...)
任一個環節出問題，只要Queue滿了，整條路都會不通，
不通之後LS這傢伙從File收到的資料送不出去，
就會被當作錯誤而被丟棄，造成資料遺失...
而我想做的就是監控整個環節，
當異常的時候我需要控制所有shipper(約有20來個LS)停下來，
或者是繁忙的時候，我要讓他們慢下來...
(我知道官方後來推Filebeat當作前端shipper，但目前無法更換架構...)
而我不想修改LS任何東西的原因在於未來升版的話會是一個麻煩點，
因為這樣我的控制機制跟LS有過高的相依性，
所以我才想採用JMX或者是BTrace這種而外侵入的方式來做。
我是有想了很多偏方，就是監控透過SSH進去該台機器下指令停止，
或者LS啟動TCP的input來接受訊號處理。
但我想既然他是JVM，那就透過JMX或其他JAVA的方法來做，比較實際。
一方面是私心想玩java的東西，一方面是如果透過Linux基礎來做，
意味著如果未來有其他OS的log需要納管，這招就會行不通...
說了這麼多，就是想像BTrace一樣，一個JVM跑得好好的，
想隨時插進去看狀況甚至控制一些事情，不曉得這樣各位大大有無好建議?
(仔細想想，這樣好像變成駭客行為，而且一不小心就有漏洞出現QQ)
※ 編輯: NullLife (114.42.65.102), 03/11/2017 21:25:12
→ qrtt1: jvm 無緣無故不見，很可能就是機器本的的資源不足了啊。 03/12 11:52
→ qrtt1: 機器給不給力，不是單看它本身，還有一起共存的程式資源使 03/12 11:53
→ qrtt1: 用量。剩餘資源不夠時（例如記憶體）就可能觸發 oom-killer 03/12 11:54
→ qrtt1: 另外，如果硬碟吃緊。應該優先考慮把檔案弄上 storage， 03/12 11:54
→ qrtt1: 不管是 aws s3 或其他 cloud provider 都有方案或社群的 03/12 11:55
→ qrtt1: plugin 可以使用。不過說到底，這套東西本身就吃比較多資源 03/12 11:55
→ qrtt1: 接 log 部分，可以為成 fluentd (native 版) 的，再導給 03/12 11:56
→ qrtt1: elasticsearch + kibana 會比較順一點。 03/12 11:56
感謝qrtt1大大，
可惜無奈現實考量，不是說缺馬上就有硬體resource可以用的...
但我會研究一下fluentd，感謝<(_ _)>
※ 編輯: NullLife (114.42.68.46), 03/12/2017 19:51:53
推 Killercat: nice他不就好了 o_oa 或者參照cgroups 03/15 14:25