მე მქვია იგორ სიდორენკო, მე ვარ ტექნიკური ლიდერი ადმინისტრატორთა გუნდში, რომლებიც ინარჩუნებენ დომკლიკის მთელ ინფრასტრუქტურას მუშა მდგომარეობაში.

მსურს გაგიზიაროთ ჩემი გამოცდილება Elasticsearch-ში განაწილებული მონაცემთა შენახვის დაყენების შესახებ. ჩვენ განვიხილავთ, თუ რა პარამეტრებია კვანძებზე პასუხისმგებელი ფრაგმენტების განაწილებაზე, როგორ არის სტრუქტურირებული და მუშაობს ILM.

ისინი, ვინც მუშაობენ ჟურნალებთან, ასე თუ ისე აწყდებიან გრძელვადიანი შენახვის პრობლემას შემდგომი ანალიზისთვის. ეს განსაკუთრებით ეხება Elasticsearch-ში, რადგან კურატორის ფუნქციონირება სავალალო იყო. 6.6 ვერსიაში გამოჩნდა ILM ფუნქციონირება. იგი შედგება 4 ფაზისგან:

ცხელი — ინდექსი აქტიურად განახლდება და იკითხება.
თბილი - ინდექსი აღარ არის განახლებული, მაგრამ მაინც მოთხოვნილი.
ცივი - ინდექსი აღარ არის განახლებული და იშვიათად იკითხება. ინფორმაცია მაინც უნდა იყოს მოძიებული, მაგრამ მოთხოვნები შეიძლება უფრო ნელი იყოს.
წაშლა - ინდექსი აღარ არის საჭირო და მისი უსაფრთხოდ წაშლა შესაძლებელია.

მოცემული

Elasticsearch Data Hot: 24 პროცესორი, 128 GB მეხსიერება, 1,8 TB SSD RAID 10 (8 კვანძი).
Elasticsearch Data Warm: 24 პროცესორი, 64 GB მეხსიერება, 8 TB NetApp SSD პოლიტიკა (4 კვანძი).
Elasticsearch Data Cold: 8 პროცესორი, 32 გბ მეხსიერება, 128 ტბ HDD RAID 10 (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

Warm- კვანძები:

~]# 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-ის მეშვეობით ინდექსების მართვის მაგალითს. ის ქმნის ინდექსს და ვრცელდება ინდექსის შაბლონი და შესაბამისი ILM.

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
    }
}

Kibana-ს დაყენება

არსებობს ძირითადი შაბლონი, რომელიც ვრცელდება ყველა ახალ ინდექსზე. იგი ადგენს ცხელი ინდექსების განაწილებას, ფრაგმენტების რაოდენობას, რეპლიკებს და ა.შ. შაბლონის წონა განისაზღვრება ვარიანტით 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-* უფრო მაღალი წონის შაბლონის გამოყენებით.

GET _template/k8s-ingress

{
  "k8s-ingress" : {
    "order" : 100,
    "index_patterns" : [
      "k8s-ingress-*"
    ],
    "settings" : {
      "index" : {
        "lifecycle" : {
          "name" : "k8s-ingress",
          "rollover_alias" : "k8s-ingress"
        },
        "codec" : "best_compression",
        "routing" : {
          "allocation" : {
            "require" : {
              "box_type" : "hot"
            }
          }
        },
        "number_of_shards" : "8",
        "number_of_replicas" : "1"
      }
    },
    "mappings" : {
      "numeric_detection" : false,
      "_meta" : { },
      "_source" : { },
      "dynamic_templates" : [
        {
          "all_fields" : {
            "mapping" : {
              "index" : false,
              "type" : "text"
            },
            "match" : "*"
          }
        }
      ],
      "date_detection" : false,
      "properties" : {
        "kubernetes" : {
          "type" : "object",
          "properties" : {
            "container_name" : {
              "type" : "keyword"
            },
            "container_hash" : {
              "index" : false,
              "type" : "keyword"
            },
            "host" : {
              "type" : "keyword"
            },
            "annotations" : {
              "type" : "object",
              "properties" : {
                "value" : {
                  "index" : false,
                  "type" : "text"
                },
                "key" : {
                  "index" : false,
                  "type" : "keyword"
                }
              }
            },
            "docker_id" : {
              "index" : false,
              "type" : "keyword"
            },
            "pod_id" : {
              "type" : "keyword"
            },
            "labels" : {
              "type" : "object",
              "properties" : {
                "value" : {
                  "type" : "keyword"
                },
                "key" : {
                  "type" : "keyword"
                }
              }
            },
            "namespace_name" : {
              "type" : "keyword"
            },
            "pod_name" : {
              "type" : "keyword"
            }
          }
        },
        "@timestamp" : {
          "type" : "date"
        },
        "nginx" : {
          "type" : "object",
          "properties" : {
            "access" : {
              "type" : "object",
              "properties" : {
                "agent" : {
                  "type" : "text"
                },
                "response_code" : {
                  "type" : "integer"
                },
                "upstream" : {
                  "type" : "object",
                  "properties" : {
                    "port" : {
                      "type" : "keyword"
                    },
                    "name" : {
                      "type" : "keyword"
                    },
                    "response_lenght" : {
                      "type" : "integer"
                    },
                    "response_time" : {
                      "index" : false,
                      "type" : "text"
                    },
                    "addr" : {
                      "type" : "keyword"
                    },
                    "status" : {
                      "index" : false,
                      "type" : "text"
                    }
                  }
                },
                "method" : {
                  "type" : "keyword"
                },
                "http_version" : {
                  "type" : "keyword"
                },
                "bytes_sent" : {
                  "type" : "integer"
                },
                "request_lenght" : {
                  "type" : "integer"
                },
                "url" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword"
                    }
                  }
                },
                "remote_user" : {
                  "type" : "text"
                },
                "referrer" : {
                  "type" : "text"
                },
                "remote_ip" : {
                  "type" : "ip"
                },
                "request_time" : {
                  "format" : "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis||dd/MMM/YYYY:H:m:s Z",
                  "type" : "date"
                },
                "host" : {
                  "type" : "keyword"
                },
                "time" : {
                  "format" : "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis||dd/MMM/YYYY:H:m:s Z",
                  "type" : "date"
                }
              }
            },
            "error" : {
              "type" : "object",
              "properties" : {
                "server" : {
                  "type" : "keyword"
                },
                "upstream" : {
                  "type" : "object",
                  "properties" : {
                    "port" : {
                      "type" : "keyword"
                    },
                    "proto" : {
                      "type" : "keyword"
                    },
                    "host" : {
                      "type" : "keyword"
                    },
                    "url" : {
                      "type" : "text",
                      "fields" : {
                        "keyword" : {
                          "type" : "keyword"
                        }
                      }
                    }
                  }
                },
                "method" : {
                  "type" : "keyword"
                },
                "level" : {
                  "type" : "keyword"
                },
                "http_version" : {
                  "type" : "keyword"
                },
                "pid" : {
                  "index" : false,
                  "type" : "integer"
                },
                "message" : {
                  "type" : "text"
                },
                "tid" : {
                  "index" : false,
                  "type" : "keyword"
                },
                "url" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword"
                    }
                  }
                },
                "referrer" : {
                  "type" : "text"
                },
                "remote_ip" : {
                  "type" : "ip"
                },
                "connection_id" : {
                  "index" : false,
                  "type" : "keyword"
                },
                "host" : {
                  "type" : "keyword"
                },
                "time" : {
                  "format" : "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis||dd/MMM/YYYY:H:m:s Z",
                  "type" : "date"
                }
              }
            }
          }
        },
        "log" : {
          "type" : "text"
        },
        "@version" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "ignore_above" : 256,
              "type" : "keyword"
            }
          }
        },
        "eventtime" : {
          "type" : "float"
        }
      }
    },
    "aliases" : { }
  }
}

ყველა შაბლონის გამოყენების შემდეგ, ჩვენ ვიყენებთ 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" : { }
          }
        }
      }
    }
  }
}

პრობლემები

იყო პრობლემები დაყენების და გამართვის ეტაპზე.

ცხელი ფაზა

ინდექსების სწორი ბრუნვისთვის, არსებობა ბოლოს index_name-date-000026 ფორმატის ნომრები 000001. კოდში არის სტრიქონები, რომლებიც ამოწმებს ინდექსებს ბოლოში რიცხვების რეგულარული გამოხატვის გამოყენებით. წინააღმდეგ შემთხვევაში, იქნება შეცდომა, ინდექსზე პოლიტიკა არ იქნება გამოყენებული და ის ყოველთვის ცხელ ფაზაში იქნება.

თბილი ფაზა

Shrink (დაჭრა) - ნამსხვრევების რაოდენობის შემცირება, რადგან თბილ და ცივ ფაზაში გვაქვს 4 კვანძი.დოკუმენტაცია შეიცავს შემდეგ სტრიქონებს:

ინდექსი უნდა იყოს მხოლოდ წაკითხვადი.

ინდექსის ყველა ფრაგმენტის ასლი უნდა იყოს იმავე კვანძზე.

კლასტერის ჯანმრთელობის მდგომარეობა უნდა იყოს მწვანე.

ინდექსის ამოსაჭრელად Elasticsearch გადააქვს ყველა პირველადი ფრაგმენტი ერთ კვანძში, ამეორებს ამოჭრილ ინდექსს საჭირო პარამეტრებით და შემდეგ წაშლის ძველს. Პარამეტრი total_shards_per_node უნდა იყოს ტოლი ან მეტი, ვიდრე ძირითადი ნატეხების რაოდენობა, რათა მოთავსდეს ისინი ერთ კვანძზე. წინააღმდეგ შემთხვევაში, იქნება შეტყობინებები და ფრაგმენტები არ გადავა საჭირო კვანძებში.

GET /shrink-k8s-ingress-2020.06.06-000025/_settings

{
  "shrink-k8s-ingress-2020.06.06-000025" : {
    "settings" : {
      "index" : {
        "refresh_interval" : "5s",
        "auto_expand_replicas" : "0-1",
        "blocks" : {
          "write" : "true"
        },
        "provided_name" : "shrink-k8s-ingress-2020.06.06-000025",
        "creation_date" : "1592225525569",
        "priority" : "100",
        "number_of_replicas" : "1",
        "uuid" : "psF4MiFGQRmi8EstYUQS4w",
        "version" : {
          "created" : "7060299",
          "upgraded" : "7060299"
        },
        "lifecycle" : {
          "name" : "k8s-ingress",
          "rollover_alias" : "k8s-ingress",
          "indexing_complete" : "true"
        },
        "codec" : "best_compression",
        "routing" : {
          "allocation" : {
            "initial_recovery" : {
              "_id" : "_Le0Ww96RZ-o76bEPAWWag"
            },
            "require" : {
              "_id" : null,
              "box_type" : "cold"
            },
            "total_shards_per_node" : "8"
          }
        },
        "number_of_shards" : "4",
        "routing_partition_size" : "1",
        "resize" : {
          "source" : {
            "name" : "k8s-ingress-2020.06.06-000025",
            "uuid" : "gNhYixO6Skqi54lBjg5bpQ"
          }
        }
      }
    }
  }
}

ცივი ფაზა

ყინვები (გაყინვა) - ჩვენ ვყინავთ ინდექსს ისტორიული მონაცემების საფუძველზე მოთხოვნების ოპტიმიზაციისთვის.

გაყინულ ინდექსებზე შესრულებული ძიებები იყენებს მცირე, გამოყოფილ, search_throttled threadpool-ს, რათა გააკონტროლოს თანმხლები ძიებების რაოდენობა, რომლებიც ხვდება გაყინულ ფრაგმენტებს თითოეულ კვანძზე. ეს ზღუდავს დამატებითი მეხსიერების რაოდენობას, რომელიც საჭიროა გაყინული ფრაგმენტების შესაბამისი გარდამავალი მონაცემთა სტრუქტურებისთვის, რაც, შესაბამისად, იცავს კვანძებს მეხსიერების გადაჭარბებული მოხმარებისგან.
გაყინული ინდექსები არის მხოლოდ წაკითხვადი: თქვენ არ შეგიძლიათ მათში ინდექსირება.
მოსალოდნელია, რომ გაყინულ ინდექსებზე ძიება ნელა შესრულდება. გაყინული ინდექსები არ არის განკუთვნილი მაღალი საძიებო დატვირთვისთვის. შესაძლებელია, რომ გაყინული ინდექსის ძიებას დასჭირდეს წამები ან წუთები, მაშინაც კი, თუ იგივე ძიება დასრულდა მილიწამებში, როდესაც ინდექსები არ იყო გაყინული.

შედეგები

ჩვენ ვისწავლეთ როგორ მოვამზადოთ კვანძები ILM-თან მუშაობისთვის, დავაყენეთ შაბლონი ცხელ კვანძებს შორის ფრაგმენტების განაწილებისთვის და დავაყენეთ ILM ინდექსისთვის ცხოვრების ყველა ფაზისთვის.

სასარგებლო ბმულები

წყარო: www.habr.com

მონაცემთა გრძელვადიანი შენახვა Elasticsearch-ში