May 20 2022
自建Elasticsearch 8.2
這週在處理在azure自建的elasticsearch相關的狀況，今天處理告一段落後來個小筆記未來遇到才不會又搞了老半天...
為什麼要自建elastic呢？主要因為之前使用azure marketplace建立的elastic cloud的saas服務，現在需要把維運的職責交給SRE團隊， 在移交的過程中發現了azure marketplace所建立的saas服務竟然不能移轉owner！只能將該服務的權限做共享而且必須將訂閱升級到Golden的等級， 代表每個月的azure帳單又要多最少百元美金的支出...未來帳號如果被停用或是變更，有可能elastic cloud上的資料會有所影響，迫於無奈下只好走向自建的路了
在自建時需要選好許多azure的服務相關的infra設計這些工作可少不了...最後決定了這些infra與azure的服務
1. elasticsearch server + kibana server
使用vmss的服務建立虛擬機器，虛擬機器的規格是使用E2s v5的規格，根據過往經驗elasticsearch伺服器在尖峰的狀態下會使用較多的記憶體，而對於cpu要求較少一些 對於網路的頻寬要求與對於硬碟的iops都有較大的要求，所以選用了esv5等級的機器
2. logstash server
logstash 服務也是採用vmss來建立虛擬機器，比較不一樣的是logstash對於cpu的要求較多，他需要去解析log還要針對log做相對應的處理，所以我們選用的是B1s的規格 然後針對他cpu與memory的使用率做scale out/in的處理
在主機中我使用的是container而非直接安裝相關的服務，然後搭配過去preversion的手法來建立伺服器。
3. Storage
存放資料的磁區選用，這個在規劃時的poc最為困擾...在azure直接使用virtual machine的服務可以掛載managed disk的磁區，但使用vmss產生的vm是無法使用managed disk的！ 但...vmss或是vm建立的硬碟會隨這vm刪除或關閉而消失，所以我們必須得用另外一組的硬碟...後來找到了另外一種解決方案，azure file的服務， 這樣一來就可以透過SMB掛載一個永久的硬碟，未來的log就能完整地被保留下來不會因為vm被刪除而消彌。
ps. azure file目前還不知道這樣的使用情境可以支撐多少的iops寫入與讀取，有待未來實驗 根據官方文件指出每秒的iops是20,000 IOPS的讀取的速度基本上可以跟SSD差不多
內建帳號使用 Service account token
在使用8.0過後的版本kibana的服務官方預設不使用帳號密碼的方式登入，需要使用service account token的方式登入連線，然後按照官方的指引點入的連結會請你呼叫建立token的api
response
然後在kibana上使用service account token登入，但只使用這樣的方式建立的token放在kibana上使用是可以登入elasticsearch， 但在操作indices的時候就會出現錯誤security_exception說你沒有權限取得indices的資料
好的，後來發現其實api呼叫的參數不對，官方在錯誤輸出的console上給的網址是會呼叫fleet-server的服務，而不是給kibana使用的所以我們要把fleet-server的token 改成kibana服務的token，這樣就可以登入並且取得indices的資料順利的啟動kibana了
後記
因為azure file使用Transaction optimized等級的價格每GB花費是1.763台幣，價格並不便宜所以只能將hot data存放在該區域中， 在未來會放上elastic使用cluster的方式將hot data與warm data（使用hot等級）區分開來，減少帳單的開支
參考連結
Service Accounts (Official document)