
這週在處理在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
```sh
# create service account token
curl -X POST -u elastic:changeme "localhost:9200/_security/service/elastic/fleet-server/credential/token?pretty"
```
response
```json
{
  "created": true,
  "token": {
    "name": "token1",
    "value": "AAEAAWVsYXN0aWM...vZmxlZXQtc2VydmVyL3Rva2VuMTo3TFdaSDZ"
  }
}
```
然後在kibana上使用service account token登入，但只使用這樣的方式建立的token放在kibana上使用是可以登入elasticsearch，
但在操作indices的時候就會出現錯誤`security_exception`說你沒有權限取得indices的資料
```yaml
# kibana.yml config
server.name: kibana
server.host: 0.0.0.0
elasticsearch.hosts: [ "http://{{elasticsearch}}:{{port}}" ]
xpack.monitoring.ui.container.elasticsearch.enabled: true

elasticsearch.serviceAccountToken: AAEAAWVs......EtHd1E
```
好的，後來發現其實api呼叫的參數不對，官方在錯誤輸出的console上給的網址是會呼叫fleet-server的服務，而不是給kibana使用的所以我們要把fleet-server的token
改成kibana服務的token，這樣就可以登入並且取得indices的資料順利的啟動kibana了
```shell
# for create kibana service account
curl -X POST -u elastic:changeme "localhost:9200/_security/service/elastic/kibana/credential/token?pretty"
```
```shell
# check permission
curl -H "Authorization: Bearer AAE.......1E" -X GET "localhost:9200/_security/user/_has_privileges?pretty" -H 'Content-Type: application/json' -d'
{
  "cluster": [ "cluster:monitor/main" ],
  "index" : [
    {
      "names": [ "logs-apm.app-default", "metrics-apm.app.*-default", "logs-apm.error-default", "metrics-apm.internal-default", "metrics-apm.profiling-default", "traces-apm.rum-default", "traces-apm-default" ],
      "privileges": [ "auto_configure","create_doc" ]
    },
    {
      "names": [ "traces-apm.sampled-default" ],
      "privileges": [ "auto_configure","create_doc","maintenance","monitor","read" ]
    }
  ]
}
'
```

## 後記

因為azure file使用`Transaction optimized`等級的價格每GB花費是1.763台幣，價格並不便宜所以只能將hot data存放在該區域中，
在未來會放上elastic使用cluster的方式將hot data與warm data（使用hot等級）區分開來，減少帳單的開支

## 參考連結

[Service Accounts (Official document)](https://www.elastic.co/guide/en/elasticsearch/reference/current/service-accounts.html)

[Create service account token api (official document)](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-create-service-token.html)

[azure file iops](https://docs.microsoft.com/en-us/azure/storage/files/storage-files-scale-targets)


這週在處理自建的elasticsearch相關的狀況，今天處理告一段落後來個小筆記未來遇到才不會又搞了老半天...

自建Elasticsearch 8.2


最近又在規劃ELK的設定，這次比較不一樣的地方我選擇了elastic cloud以及服務部署的方式都採用PaaS的方式作為部署，
加掛volume或是在機器上安裝filebeat都是一個比較困難的事情，所以一開始考慮使用azure blob queue的方式存放log，
但後來選擇了官方有提供的input套件，Azure Event Hub來寫log在使用logstash去讀取傳送到elasticsearch上

根據官網的文件操作後會一直出現
`The configuration will result in overwriting offsets. Please ensure that the each Event Hub's consumer_group is using a unique storage container.`
這樣的錯誤訊息，也採用了進階的設定去使用，但因為只有一組採用進階的方式設定有點太過複雜所以又改回原本設定，後來想我的event hub的connection string有兩組會不會因為這樣我需要多個storage container的存放空間，
後來將其中一組刪除後即可正常運作

```config
# 會出錯的logstash pipeline config
input {
    azure_event_hubs {
        event_hub_connections => ["Endpoint=sb://<<event hub>>.servicebus.windows.net/;SharedAccessKeyName=logsta...",
            "Endpoint=sb://<<event hub>>.servicebus.windows.net/;SharedAccessKeyName=logsta..."]
        storage_connection => "DefaultEndpointsProtocol=https;..."
        consumer_group => "logstash"
        decorate_events => true
        threads => 8
    }
}
filter {
    json {
        source => "message"
    }
    date {
        match => [ "Timestamp", "ISO8601" ]
        target => "@timestamp"
    }
    mutate {
        rename => ["MessageTemplate", "message" ]
        rename => ["Level", "level" ]
        merge => { "message" => "Exception" }
        remove_field => ["Exception", "Timestamp"]
    }
}
output {
    elasticsearch {
        cloud_id => "<<Cloud id>>"
        cloud_auth => "<<user>>:<<password>>"
        index => "demo-%{+YYYY.w}"
    }
}
```

```config
# 最後的 logstash pipeline config
input {
    azure_event_hubs {
        event_hub_connections => ["Endpoint=sb://<<event hub>>.servicebus.windows.net/;SharedAccessKeyName=logsta..."]
        storage_connection => "DefaultEndpointsProtocol=https;..."
        consumer_group => "logstash"
        decorate_events => true
        threads => 8
    }
}
filter {
    json {
        source => "message"
    }
    date {
        match => [ "Timestamp", "ISO8601" ]
        target => "@timestamp"
    }
    mutate {
        rename => ["MessageTemplate", "message" ]
        rename => ["Level", "level" ]
        merge => { "message" => "Exception" }
        remove_field => ["Exception", "Timestamp"]
    }
}
output {
    elasticsearch {
        cloud_id => "<<Cloud id>>"
        cloud_auth => "<<user>>:<<password>>"
        index => "demo-%{+YYYY.w}"
    }
}
```


### 參考資料
[Github - logstash-input-azure_event_hubs](https://github.com/logstash-plugins/logstash-input-azure_event_hubs)


最近又在規劃ELK的設定，這次比較不一樣的地方我選擇了elastic cloud以及服務部署的方式都採用PaaS的方式作為部署， 加掛volume或是在機器上安裝filebeat都是一個比較困難的事情，所以一開始考慮使用azure blob queue的方式存放log， 但後來選擇了官方有提供的input套件，Azure Event Hub來寫log在使用logstash去讀取傳送到elasticsearch上

Logstash Azure event hub input 設定


## 針對index的一些效能調校

在Index Management中有個index templates的頁簽，在這裡可以改變一些index的行為或是屬性，
有些index屬性對於整個ELK的查詢或是機器的影響是很巨大的，當Log量越大的時候就需要改變一些設定，
尤其是放在雲端的ELK，如果使用越大的機器消費金額就會變得很可觀，在不是賺錢的機器上還是能省則省。

`index.codec`在官方的文件中有兩個選項，預設是Default採用LZ4的壓縮，另一個選項是*best_compression*，
使用它可以得到更高的壓縮效率但會增加CPU的附載，不過減少硬碟的空間是可觀的

`refresh_interval`這個在官方文件說明是index的刷新頻率，這個選項會影響到新增的log多久內可能不會被看見，
但refresh index他需要消耗許多的CPU來處理，這個值如果越大刷新的頻率就會降低，機器的CPU usage就不會被這個吃掉，
可以減少一些CPU的運算

`number_of_replicas`是Elasticsearch會建立多少個副本，但複本越多所需要消耗的CPU與硬碟空間就會加大

```json
{
  "index": {
    "lifecycle": {
      "name": "production"
    },
    "codec": "best_compression",
    "refresh_interval": "15s",
    "number_of_replicas": 0
  }
}
```

## 自動維運Index的小技巧

通常架設了ELK初期會常常觀看一些硬碟空間, CPU usage, Memory usage等等的，時間久了就會忘記了...

但是硬碟的空間是有限的，Application Log其實也是有時效性的，他不需要永久的存在在硬碟上(畢竟要花錢的...)所以自動刪除index就變得很重要，
在Index Lifecycle Policies中我會設定兩個policy，一個production跟一個non-production的，production通常會留存30天以，
而非production的一般來說在兩週到三週就沒有參考價值了，所以非production只留存14天。

![ELK index lifecycle](elasticsearch-tuning-and-auto-operation/index-lifecycle.png)

## 參考連結
[Elasticsearch Index Module](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html)

[Tune for indexing speed](https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html)


在Index Management中有個index templates的頁簽，在這裡可以改變一些index的行為或是屬性， 有些index屬性對於整個ELK的查詢或是機器的影響是很巨大的，當Log量越大的時候就需要改變一些設定， 尤其是放在雲端的ELK，如果使用越大的機器消費金額就會變得很可觀，在不是賺錢的機器上還是能省則省。

自建Elasticsearch 8.2

Logstash Azure event hub input 設定

Elasticsearch 效能調整與自動維運