人在夢中難覺……夢醒……方知味……
因為一直背不起來 OSI七層,上網查了下發現還真的有人發明了口訣 OSI由最上層往下 All People Seem To Need Domino’s Pizza (所有的人看來都需要達美樂比薩)
要算一下各服務所佔的比例, 大方向用VM的機器 cpu來算
一個一個點進去VM機器裡面算CPU的數量是可行,
但我好懶!!!太沒效率了,寫指令撈吧,然後把資料丟去excel做加總。
我一直對nginx不太熟, 目前也只到了會用,大部分的指令看得懂。 但湊在一起,還是要查一下。
這次的錯誤就發生在我以為的問題上
代理伺服器,以前最常用過的應該是Hinet的proxy, 在以前網路不快的時候,有時會掛prxoy,來讓瀏覽速度變快。 proxy的用途主要也是如此,將user的請求透過prxoy去跟網站取得資料,再回給user。
但proxy分成很多種…下面簡單說明
p.s 在交接的時候,我才發現原來http代理不是每個人都知道!?
補充ingest 的 processor
用filebeat 蒐集 nginx的資料,取得的Nginx資料沒再經過分解, 導致沒辦法運用在efk上面。
這邊說的運用,指的是直接在Dscover上面直接用fileter的方式查詢到需要的資料。
因為資料都是一個欄位[Message],所以必須分解後指定他們資料對應的欄位。
最近用istio偵測,常碰到某個服務狀態會掉到80%以下, 那時都有看到APM的程式報錯,但沒人反應,最近有次發生在上班時間, 馬上聯絡同事看他的服務有沒有正常, 最後一路追, 發現狀態碼是回 503 DC ,對這個關鍵字有印象,但常會忘記他的全名。
發現有一整批的資源沒有加過 label , GCE的硬碟、負載平衡的前端轉導規則… 有些條件不一樣,一個一個加會瘋掉。 工程師就是懶…寫sh吧
要把別人寫的yaml拆開,然後整併到自己的image, 才發現service的 base 怎麼沒寫selector , 但佈署時卻有mapping到。
在正式環境,直接上了APM監控, 然後各個圖表代表的意思…, 我查一下。
所以這篇就這樣生出來了。
之前同事是直接自己土炮用golang寫timer, 不過如果碰到執行時間過長,重複執行的話, 就要判斷一堆狀態,決定要不要做, 那就改用k8s的cronJob了吧。
本來想直接用表格闡述兩邊不同的地方, 但發現我不知道從何下手。 只好先用條列代替了, 這兩套我都沒用過,因為…我直接從GKE開始XD。
換了個新版本, 就發現 APM不能用, 後來查了一查,才知道ECK多了一個新東西, Elastic Agent。 目前還有些沒支援,但這應該是未來ECK會走的方向了。