Երկարաժամկետ տվյալների պահպանում Elasticsearch-ում
Ես Իգոր Սիդորենկոն եմ, ես տեխնիկական ղեկավար եմ ադմինների թիմում, ովքեր պահպանում են Domclick-ի ողջ ենթակառուցվածքը:
Ես ուզում եմ կիսվել Elasticsearch-ում բաշխված տվյալների պահպանման ստեղծման իմ փորձով: Մենք կնայենք, թե հանգույցների վրա ինչ կարգավորումներ են պատասխանատու բեկորների բաշխման համար, ինչպես է աշխատում և աշխատում ILM-ը:
Նրանք, ովքեր աշխատում են գերանների հետ, այսպես թե այնպես, բախվում են երկարաժամկետ պահեստավորման խնդրին հետագա վերլուծության համար: Elasticsearch-ում դա հատկապես ճիշտ է, քանի որ ամեն ինչ դժբախտ էր կուրատորի ֆունկցիոնալությամբ: 6.6 տարբերակը ներկայացրեց ILM ֆունկցիոնալությունը: Այն բաղկացած է 4 փուլից.
Թեժ - Ցուցանիշն ակտիվորեն թարմացվում և հարցվում է:
Ջերմ - Ցուցանիշն այլևս չի թարմացվում, բայց դեռ հարցման փուլում է:
Սառը - Ցուցանիշն այլևս չի թարմացվում և հազվադեպ է հարցման ենթարկվում: Տեղեկատվությունը դեռ պետք է որոնելի լինի, բայց հարցումները կարող են ավելի դանդաղ լինել:
Ջնջել - Ցուցանիշն այլևս անհրաժեշտ չէ և կարող է ապահով կերպով ջնջվել:
Այս կարգավորումները անհատական են, ամեն ինչ կախված է հանգույցների տեղից, ինդեքսների քանակից, տեղեկամատյաններից և այլն: Մենք օրական 2-3 ՏԲ տվյալ ունենք։
5 օր - Թեժ փուլ (8 հիմնական / 1 կրկնօրինակ):
20 օր - տաք փուլ (նեղանալ-ինդեքս 4 հիմնական / 1 կրկնօրինակ):
90 օր - Սառը փուլ (սառեցման ինդեքս 4 հիմնական / 1 կրկնօրինակ):
120 օր - Ջնջել փուլը:
Elasticsearch-ի կարգավորում
Հանգույցների վրա բեկորները բաշխելու համար ձեզ անհրաժեշտ է միայն մեկ պարամետր.
տաք- հանգույցներ:
~]# cat /etc/elasticsearch/elasticsearch.yml | grep attr
# Add custom attributes to the node:
node.attr.box_type: hot
Ջերմ- հանգույցներ:
~]# cat /etc/elasticsearch/elasticsearch.yml | grep attr
# Add custom attributes to the node:
node.attr.box_type: warm
Ցուրտ- հանգույցներ:
~]# cat /etc/elasticsearch/elasticsearch.yml | grep attr
# Add custom attributes to the node:
node.attr.box_type: cold
Logstash-ի կարգավորում
Ինչպե՞ս է այդ ամենը աշխատում և ինչպե՞ս ենք մենք ներդրել այս գործառույթը: Եկեք սկսենք Elasticsearch-ում տեղեկամատյաններ մուտքագրելով: Երկու ճանապարհ կա.
Logstash-ը Կաֆկայից գերաններ է վերցնում: Կարող է մաքուր վերցնել կամ վերափոխել ձեր կողմից:
Ինչ-որ բան ինքն է գրում Elasticsearch-ին, օրինակ՝ APM սերվեր:
Դիտարկենք Logstash-ի միջոցով ինդեքսների կառավարման օրինակ: Այն ստեղծում է ինդեքս և կիրառվում է դրա վրա ինդեքսային օրինակ և համապատասխան ԻԼՄ.
k8s-ingress.conf
input {
kafka {
bootstrap_servers => "node01, node02, node03"
topics => ["ingress-k8s"]
decorate_events => false
codec => "json"
}
}
filter {
ruby {
path => "/etc/logstash/conf.d/k8s-normalize.rb"
}
if [log] =~ "[warn]" or [log] =~ "[error]" or [log] =~ "[notice]" or [log] =~ "[alert]" {
grok {
match => { "log" => "%{DATA:[nginx][error][time]} [%{DATA:[nginx][error][level]}] %{NUMBER:[nginx][error][pid]}#%{NUMBER:[nginx][error][tid]}: *%{NUMBER:[nginx][error][connection_id]} %{DATA:[nginx][error][message]}, client: %{IPORHOST:[nginx][error][remote_ip]}, server: %{DATA:[nginx][error][server]}, request: "%{WORD:[nginx][error][method]} %{DATA:[nginx][error][url]} HTTP/%{NUMBER:[nginx][error][http_version]}", (?:upstream: "%{DATA:[nginx][error][upstream][proto]}://%{DATA:[nginx][error][upstream][host]}:%{DATA:[nginx][error][upstream][port]}/%{DATA:[nginx][error][upstream][url]}", )?host: "%{DATA:[nginx][error][host]}"(?:, referrer: "%{DATA:[nginx][error][referrer]}")?" }
remove_field => "log"
}
}
else {
grok {
match => { "log" => "%{IPORHOST:[nginx][access][host]} - [%{IPORHOST:[nginx][access][remote_ip]}] - %{DATA:[nginx][access][remote_user]} [%{HTTPDATE:[nginx][access][time]}] "%{WORD:[nginx][access][method]} %{DATA:[nginx][access][url]} HTTP/%{NUMBER:[nginx][access][http_version]}" %{NUMBER:[nginx][access][response_code]} %{NUMBER:[nginx][access][bytes_sent]} "%{DATA:[nginx][access][referrer]}" "%{DATA:[nginx][access][agent]}" %{NUMBER:[nginx][access][request_lenght]} %{NUMBER:[nginx][access][request_time]} [%{DATA:[nginx][access][upstream][name]}] (?:-|%{IPORHOST:[nginx][access][upstream][addr]}:%{NUMBER:[nginx][access][upstream][port]}) (?:-|%{NUMBER:[nginx][access][upstream][response_lenght]}) %{DATA:[nginx][access][upstream][response_time]} %{DATA:[nginx][access][upstream][status]} %{DATA:[nginx][access][request_id]}" }
remove_field => "log"
}
}
}
output {
elasticsearch {
id => "k8s-ingress"
hosts => ["node01", "node02", "node03", "node04", "node05", "node06", "node07", "node08"]
manage_template => true # включаем управление шаблонами
template_name => "k8s-ingress" # имя применяемого шаблона
ilm_enabled => true # включаем управление ILM
ilm_rollover_alias => "k8s-ingress" # alias для записи в индексы, должен быть уникальным
ilm_pattern => "{now/d}-000001" # шаблон для создания индексов, может быть как "{now/d}-000001" так и "000001"
ilm_policy => "k8s-ingress" # политика прикрепляемая к индексу
index => "k8s-ingress-%{+YYYY.MM.dd}" # название создаваемого индекса, может содержать %{+YYYY.MM.dd}, зависит от ilm_pattern
}
}
Կիբանայի տեղադրում
Կա բազային օրինաչափություն, որը վերաբերում է բոլոր նոր ինդեքսներին: Այն սահմանում է տաք ինդեքսների բաշխումը, բեկորների քանակը, կրկնօրինակները և այլն: Կաղապարի քաշը որոշվում է տարբերակով order. Ավելի մեծ քաշ ունեցող կաղապարները անտեսում են առկա կաղապարի պարամետրերը կամ ավելացնում նորերը:
GET_template/default
{
"default" : {
"order" : -1, # вес шаблона
"version" : 1,
"index_patterns" : [
"*" # применяем ко всем индексам
],
"settings" : {
"index" : {
"codec" : "best_compression", # уровень сжатия
"routing" : {
"allocation" : {
"require" : {
"box_type" : "hot" # распределяем только по горячим нодам
},
"total_shards_per_node" : "8" # максимальное количество шардов на ноду от одного индекса
}
},
"refresh_interval" : "5s", # интервал обновления индекса
"number_of_shards" : "8", # количество шардов
"auto_expand_replicas" : "0-1", # количество реплик на ноду от одного индекса
"number_of_replicas" : "1" # количество реплик
}
},
"mappings" : {
"_meta" : { },
"_source" : { },
"properties" : { }
},
"aliases" : { }
}
}
Այնուհետև կիրառեք քարտեզագրումը ինդեքսների վրա k8s-ingress-* օգտագործելով ավելի մեծ քաշ ունեցող ձևանմուշ:
Բոլոր կաղապարները կիրառելուց հետո մենք կիրառում ենք ILM քաղաքականությունը և սկսում վերահսկել ինդեքսների կյանքը։
GET _ilm/policy/k8s-ingress
{
"k8s-ingress" : {
"version" : 14,
"modified_date" : "2020-06-11T10:27:01.448Z",
"policy" : {
"phases" : {
"warm" : { # теплая фаза
"min_age" : "5d", # срок жизни индекса после ротации до наступления теплой фазы
"actions" : {
"allocate" : {
"include" : { },
"exclude" : { },
"require" : {
"box_type" : "warm" # куда перемещаем индекс
}
},
"shrink" : {
"number_of_shards" : 4 # обрезание индексов, т.к. у нас 4 ноды
}
}
},
"cold" : { # холодная фаза
"min_age" : "25d", # срок жизни индекса после ротации до наступления холодной фазы
"actions" : {
"allocate" : {
"include" : { },
"exclude" : { },
"require" : {
"box_type" : "cold" # куда перемещаем индекс
}
},
"freeze" : { } # замораживаем для оптимизации
}
},
"hot" : { # горячая фаза
"min_age" : "0ms",
"actions" : {
"rollover" : {
"max_size" : "50gb", # максимальный размер индекса до ротации (будет х2, т.к. есть 1 реплика)
"max_age" : "1d" # максимальный срок жизни индекса до ротации
},
"set_priority" : {
"priority" : 100
}
}
},
"delete" : { # фаза удаления
"min_age" : "120d", # максимальный срок жизни после ротации перед удалением
"actions" : {
"delete" : { }
}
}
}
}
}
}
Problems
Կարգավորման և վրիպազերծման փուլում խնդիրներ կային:
Թեժ փուլ
Ցուցանիշների ճիշտ պտտման համար կարևոր է վերջինիս առկայությունը index_name-date-000026 թվերի ձևաչափը 000001. Կոդում կան տողեր, որոնք ստուգում են ինդեքսները՝ օգտագործելով կանոնավոր արտահայտություն՝ վերջում թվերի առկայության համար: Հակառակ դեպքում սխալ կլինի, ինդեքսի նկատմամբ քաղաքականություն չի կիրառվի, և այն միշտ կլինի թեժ փուլում։
Ջերմ փուլ
Նեղանալ (կտրվածք) — բեկորների քանակի կրճատում, քանի որ տաք և սառը փուլերում մենք ունենք 4 հանգույց։ Փաստաթղթերը պարունակում են հետևյալ տողերը.
Ցուցանիշը պետք է լինի միայն կարդալու համար:
Ինդեքսի յուրաքանչյուր բեկորի պատճենը պետք է գտնվի նույն հանգույցում:
Կլաստերի առողջական վիճակը պետք է լինի կանաչ:
Ինդեքսը կտրելու համար Elasticsearch-ը տեղափոխում է բոլոր առաջնային բեկորները մեկ հանգույց, կրկնօրինակում է կտրված ինդեքսը անհրաժեշտ պարամետրերով, այնուհետև ջնջում է հինը: Պարամետր total_shards_per_node պետք է հավասար լինի կամ մեծ լինի մեկ հանգույցի վրա տեղավորվող հիմնական բեկորների քանակից: Հակառակ դեպքում կլինեն ծանուցումներ, և բեկորները չեն տեղափոխվի ճիշտ հանգույցներ:
GET /shrink-k8s-ingress-2020.06.06-000025/_settings
Սառեցնել (սառեցնել) - Մենք սառեցնում ենք ինդեքսը՝ պատմական տվյալների վերաբերյալ հարցումները օպտիմալացնելու համար:
Սառեցված ինդեքսների վրա կատարված որոնումները օգտագործում են փոքր, նվիրված, search_throttled threadpool-ը՝ վերահսկելու միաժամանակյա որոնումների քանակը, որոնք հարվածում են սառեցված բեկորներին յուրաքանչյուր հանգույցի վրա: Սա սահմանափակում է սառեցված բեկորներին համապատասխանող անցողիկ տվյալների կառուցվածքների համար պահանջվող լրացուցիչ հիշողության քանակը, ինչը հետևաբար պաշտպանում է հանգույցները հիշողության ավելորդ սպառումից:
Սառեցված ինդեքսները միայն կարդալու են. դուք չեք կարող ինդեքսավորել դրանց մեջ:
Սպասվում է, որ սառեցված ինդեքսների վրա որոնումները դանդաղ կկատարվեն: Սառեցված ինդեքսները նախատեսված չեն որոնման մեծ բեռի համար: Հնարավոր է, որ սառեցված ինդեքսի որոնումը կարող է ավարտվել վայրկյաններով կամ րոպեներով, նույնիսկ եթե նույն որոնումները ավարտվել են միլիվայրկյաններով, երբ ինդեքսները չեն սառեցվել:
Արդյունքները
Մենք սովորեցինք, թե ինչպես պատրաստել հանգույցներ ILM-ի հետ աշխատելու համար, ստեղծել ձևանմուշ՝ բեկորները տաք հանգույցների միջև բաշխելու համար և ստեղծել ILM կյանքի բոլոր փուլերի ինդեքսների համար: