मेरा नाम इगोर सिदोरेंको है, मैं व्यवस्थापकों की टीम में एक तकनीकी नेता हूं जो डोमक्लिक के पूरे बुनियादी ढांचे का रखरखाव करता है।
मैं एलिस्टिक्स खोज में वितरित डेटा संग्रहण स्थापित करने में अपना अनुभव साझा करना चाहता हूं। हम देखेंगे कि नोड्स पर कौन सी सेटिंग्स शार्क के वितरण के लिए जिम्मेदार हैं, ILM कैसे काम करता है और काम करता है।
जो लोग लॉग के साथ काम करते हैं, एक तरह से या किसी अन्य, बाद के विश्लेषण के लिए दीर्घकालिक भंडारण की समस्या का सामना करते हैं। इलास्टिसर्च में, यह विशेष रूप से सच है, क्योंकि क्यूरेटर की कार्यक्षमता के साथ सब कुछ दुर्भाग्यपूर्ण था। संस्करण 6.6 ने ILM कार्यक्षमता पेश की। इसमें 4 चरण होते हैं:
हॉट - इंडेक्स को सक्रिय रूप से अपडेट और क्वेरी किया जा रहा है।
वार्म - इंडेक्स अब अपडेट नहीं किया गया है, लेकिन अभी भी पूछताछ की जा रही है।
कोल्ड - इंडेक्स अब अपडेट नहीं किया जाता है और शायद ही कभी पूछताछ की जाती है। जानकारी अभी भी खोजने योग्य होनी चाहिए, लेकिन क्वेरी धीमी हो सकती हैं।
डिलीट - इंडेक्स की अब जरूरत नहीं है और इसे सुरक्षित रूप से डिलीट किया जा सकता है।
90 दिन - शीत चरण (फ्रीज-सूचकांक 4 मुख्य / 1 प्रतिकृति)।
120 दिन - चरण हटाएं।
इलास्टिक्स खोज की स्थापना
शार्क को नोड्स में वितरित करने के लिए, आपको केवल एक पैरामीटर की आवश्यकता है:
हाट-नोड्स:
~]# 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
लॉगस्टैश की स्थापना
यह सब कैसे काम करता है और हमने इस सुविधा को कैसे लागू किया? चलिए एलिस्टिक्स खोज में लॉग इन करके शुरू करते हैं। दो तरीके हैं:
लॉगस्टैश काफ्का से लॉग प्राप्त करता है। क्लीन पिक कर सकते हैं या अपनी तरफ कन्वर्ट कर सकते हैं।
कुछ खुद एलेस्टिक्स खोज को लिखते हैं, उदाहरण के लिए, एपीएम सर्वर।
लॉगस्टैश के माध्यम से इंडेक्स प्रबंधित करने के एक उदाहरण पर विचार करें। यह एक इंडेक्स बनाता है और उस पर लागू होता है सूचकांक पैटर्न और संगत इल्म.
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. अधिक वजन वाले टेम्प्लेट मौजूदा टेम्प्लेट पैरामीटर को ओवरराइड करते हैं या नए जोड़ते हैं।
_टेम्प्लेट/डिफ़ॉल्ट प्राप्त करें
{
"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 नीति लागू करते हैं और इंडेक्स के जीवन की निगरानी करना शुरू करते हैं।
_ilm/नीति/k8s-प्रवेश प्राप्त करें
{
"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" : { }
}
}
}
}
}
}
समस्याओं
सेटअप और डिबगिंग चरण में समस्याएं थीं।
गर्म चरण
सूचकांकों के सही घुमाव के लिए अंत में उपस्थिति महत्वपूर्ण है index_name-date-000026 प्रारूप संख्या 000001. कोड में ऐसी पंक्तियाँ हैं जो अंत में संख्याओं की उपस्थिति के लिए नियमित अभिव्यक्ति का उपयोग करके अनुक्रमणिका की जाँच करती हैं। अन्यथा, एक त्रुटि होगी, सूचकांक पर कोई नीति लागू नहीं की जाएगी, और यह हमेशा गर्म चरण में रहेगा।
गर्म चरण
झिझक (कटऑफ़) - शार्क की संख्या को कम करना, क्योंकि हमारे पास गर्म और ठंडे चरणों में 4 नोड हैं। प्रलेखन में निम्नलिखित पंक्तियाँ हैं:
इंडेक्स केवल पढ़ने के लिए होना चाहिए।
इंडेक्स में प्रत्येक शार्ड की एक प्रति उसी नोड पर होनी चाहिए।
क्लस्टर स्वास्थ्य की स्थिति हरी होनी चाहिए।
किसी इंडेक्स को प्रून करने के लिए, एलियस्टिक्स खोज सभी प्राथमिक शार्क को एक नोड में ले जाती है, आवश्यक मापदंडों के साथ ट्रंकेटेड इंडेक्स को डुप्लिकेट करती है, और फिर पुराने को हटा देती है। पैरामीटर total_shards_per_node एक नोड पर फ़िट होने के लिए मुख्य शार्क की संख्या के बराबर या उससे अधिक होना चाहिए। अन्यथा, सूचनाएं होंगी और शार्ड्स सही नोड्स पर नहीं जाएंगे।
GET /shrink-k8s-ingress-2020.06.06-000025/_सेटिंग्स
स्थिर (फ्रीज) - हम ऐतिहासिक डेटा पर प्रश्नों को अनुकूलित करने के लिए इंडेक्स को फ्रीज करते हैं।
जमे हुए सूचकांकों पर की गई खोजें छोटे, समर्पित, search_throttled थ्रेडपूल का उपयोग समवर्ती खोजों की संख्या को नियंत्रित करने के लिए करती हैं जो प्रत्येक नोड पर जमी हुई शार्क को हिट करती हैं। यह जमे हुए शार्क के अनुरूप क्षणिक डेटा संरचनाओं के लिए आवश्यक अतिरिक्त मेमोरी की मात्रा को सीमित करता है, जिसके परिणामस्वरूप अत्यधिक मेमोरी खपत के विरुद्ध नोड्स की सुरक्षा होती है।
जमे हुए सूचकांक केवल पढ़ने के लिए होते हैं: आप उनमें अनुक्रमित नहीं कर सकते।
जमे हुए सूचकांकों पर खोजें धीरे-धीरे निष्पादित होने की उम्मीद है। जमे हुए सूचकांक उच्च खोज भार के लिए अभिप्रेत नहीं हैं। यह संभव है कि एक जमे हुए सूचकांक की खोज को पूरा होने में सेकंड या मिनट लग सकते हैं, भले ही वही खोज मिलीसेकंड में पूरी हुई हो जब सूचकांक स्थिर नहीं थे।
परिणाम
हमने सीखा कि ILM के साथ काम करने के लिए नोड्स कैसे तैयार करें, हॉट नोड्स के बीच शार्क को वितरित करने के लिए एक टेम्प्लेट सेट करें, और जीवन के सभी चरणों के साथ एक इंडेक्स के लिए ILM सेट अप करें।