Практика применения и эксплуатации и обслуживания Elasticsearch в области анализа логов

Большое количество данных

Этот обмен сделан старшим инженером из Alibaba.Чжао Ханьцинпринес. В основном рассказывает:

  • Система анализа логов на базе ELK + Kafka
  • Опыт оптимизации Elasticsearch
  • Практика эксплуатации и обслуживания Elasticsearch

Введение в эластичный поиск

Распределенная поисковая система анализа в реальном времени, преимущества включают в себя:

  • запрос почти в реальном времени
  • Небольшое потребление памяти и высокая скорость поиска
  • Сильная масштабируемость
  • Высокая доступность

структура данных

  • FST(Finite State Transducer)

file这种数据结构适用于文本查询。通过对词典中单词前缀和后缀的重复利用,压缩存储空间,压缩比率一般在 3~20 倍之间。 O(len(str)) сложность времени запроса.范围搜索,前缀搜索比传统的 hashmap 有明显优势。

  • BDK Tree

Применимо к многомерным типам данных, таким как числовая и географическая информация ( geo ). Когда K = 1, бинарное дерево поиска, журнал сложности запроса (N)file

K=2, определяют измерение сегментации, а точка сегментации выбирает среднюю точку этого измерения.file

Расширяемость

Благодаря механизму сегментирования индекса реализовано горизонтальное расширение кластера.file

Высокая доступность

Избыточное резервное копирование с помощью сегментов, развертывание в зонах доступности и моментальные снимки данных. Борьба со сбоем узла кластера и повреждением данных.

file

Семейная корзина ElasticSearch

Kibana: визуализация данных, взаимодействует с elasticsearch. Elasticsearch: магазин, индекс, поиск. Logstash: Сбор данных, фильтрация, преобразование. Beats: легче и универсальнее, чем logstash: Filebeat, Metricbeat, Packetbeat, Winlogbeat…

file

Система анализа логов на базе ELK и Kafka

file

Логсташ Преимущества

Предоставляет большое количество плагинов для фильтрации данных и преобразования. Удаление: выбросьте ненужные данные. один отпечаток пальца записи: предотвратить вставку дубликатов данных

Недостатки Logstash: сбор журналов неэффективен и потребляет ресурсы. Filebeat: компенсирует недостатки, но имеет меньше собственных плагинов.

Доставка журналов с помощью Kafka

Kafka имеет возможности кэширования данных. Данные Kafka можно использовать повторно. Сама Kafka обладает высокой доступностью для предотвращения потери данных. Пропускная способность Kafka лучше. Кафка широко используется.

Практический опыт: разные сервисы создают разные темы. Установите количество разделов темы в соответствии с объемом журнала службы. Настройте Consumer_threads в соответствии с количеством разделов kafka и количеством журналов, использующих тему. Постарайтесь четко указать logstash и соответствующую тему (ы) потребления и используйте меньше подстановочных знаков для темы использования конфигурации.

Основные вопросы кластерного планирования:

  1. Общий размер данных: сколько данных передается каждый день и сколько дней данные сохраняются.

Ежедневное увеличение объема данных: ежедневный новый объем журнала * количество резервных копий. Если включеноПоле all удваивается на основе вышеизложенного. Например, лог 1T добавляется каждый день, на каждом шарде 1 бэкап, включитьВ целом фактическое увеличение данных кластера Elasticsearch составляет около 4T. Если вам нужно хранить данные 4T каждый день, если вы сохраняете данные в течение 30 дней, минимальный требуемый объем хранилища составляет 120T, и обычно добавляется 20% буфера. Требуется не менее 144T дискового пространства. По характеристикам сценариев журналов можно разделить горячие и теплые узлы. В горячих узлах обычно используются SSD-диски, а в теплых узлах — обычные механические диски.

  1. Конфигурация с одним узлом: сколько индексов, сколько сегментов на узел и насколько контролируется каждый размер сегмента.
    На основе общего объема данных и одноузловой конфигурации получается общий размер кластера.
    Для одного узла, по опыту, соотношение CPU:Memory обычно составляет 1:4.
    Соотношение Память : Диск 1 : 24.
    Параметр xmx для кучи Elasticsearch обычно не превышает 32g.
    Соотношение памяти и шарда составляет от 1:20 до 1:25.
    Размер каждого осколка не превышает 50 г.

Практический пример

Когда на производственной линии происходит аварийное переключение службы, объем журналов резервного копирования кластера внезапно увеличивается, также внезапно увеличивается объем данных в kafka, а также объем данных, которые logstash потребляет и вводит в Elasticsearch в единицу времени. Концентрируясь на одном узле, служба Elasticsearch узла будет слишком занята из-за таких факторов, как большой объем данных, которые необходимо проиндексировать, и одновременный ответ на несколько массовых запросов logstash.

Если он не отвечает на запрос, отправленный главным узлом (например, контроль работоспособности кластера), главный узел будет заблокирован в ожидании ответа узла, в результате чего другие узлы будут думать, что главный узел потерян, что вызовет ряд чрезвычайных ситуаций. ответы, такие как переизбрание мастера.

Если он не сможет вовремя ответить на запрос logstash, в logstash connect elasticsearch появится тайм-аут, logstash распознает elasticsearch как мертвый и больше не будет потреблять kafka. Когда Kafka обнаруживает, что потребитель в той же группе потребителей исчезает, вся группа потребителей выполняет перебалансировку, что влияет на потребление других журналов и пропускную способность всего кластера.

типичныйстадный эффект, необходимость устранения влияния лидера. Доступно через API elasticsearch: GET/cat/threadpool / bulk?v&h =name , host,active,queue,rejected,completed Определите, какой узел занят: очередь относительно велика, и число отклоненных увеличивается. затем через ПОЛУЧИТЬ/cat/shards находит активные осколки на этом узле. и, наконец, через POST /API кластера/перенаправления перемещает сегмент на узел с меньшей нагрузкой, чтобы уменьшить нагрузку на узел.

Практика эксплуатации и обслуживания кластера ElasticSearch

Наше основное внимание сосредоточено на:

  1. состояние работоспособности кластера
    2. Кластерная индексация и производительность поиска
  2. Процессор узла, память, использование диска

Кластер зеленый, нормальный. Кластер выделен желтым цветом, в основном из-за того, что есть невыделенные осколки реплик. Кластер выделен красным, потому что есть неназначенные первичные осколки.

Основная причина: использование диска узла кластера превышает водяной знак (по умолчанию 85%). Доступно через api GET/cat/location для просмотра использования диска узлом. Доступно через api GET/cluster/ settings, чтобы узнать, отключен ли cluster.routing.allocation.enable. Конкретные причины, по которым шарды не распределяются по узлам, можно просмотреть через api GET /_cluster/allocation/explain?Pretty.

Рекомендуемый инструмент мониторинга: cerebro (https://github.com/lmenezes/cerebro)

filefile

Опыт оптимизации ElasticSearch

Оптимизация индекса

  1. Создайте индекс заранее
  2. Чтобы избежать разреженного индексирования, структура документа в индексе должна быть согласованной.Если структура документа непоследовательна, рекомендуется разделить индекс и использовать индекс с небольшим количеством сегментов для хранения документов с разными форматами полей.
    3. Вы можете установить обновление при загрузке большого количества данныхинтервал =-1 , индекс.номерof_replicas = 0, установите его обратно после завершения индексации.
    4. В случае низкого нагрузки и давления IO, использование объема более эффективно, чем одна операция поставленного / удаления.
    5. Настройте индексный буфер ( index.memory.indexbufferразмер ).
  3. Для полей, которым не требуется оценка, отключите нормы; для полей, не требующих сортировки или агрегирования, отключите doc_value.

Оптимизация запросов

Используйте маршрутизацию, чтобы повысить скорость запроса данных измерения. Чтобы не возвращать слишком много наборов результатов поиска, используйте limit. Если объем кучи невелик, кэш запросов узла ( index.queries.cache.size ) можно соответствующим образом увеличить. Добавление резервных копий сегментов может улучшить параллелизм запросов, но обратите внимание на общее количество сегментов на узле. Периодически объединяйте сегменты.

Облачный сервис Alibaba ElasticSearch

Elasticsearch Ali Cloud Services предлагается включить мониторинг, тревогу, визуализацию журнала, характеристики расширения ключейfilefilefilefile

Отказ от ответственности: если не указано иное, все статьи в этой учетной записи являются оригинальными, и читатели официальной учетной записи имеют приоритет для чтения и не могут воспроизводиться без разрешения автора, в противном случае они будут нести ответственность за нарушение.

Подпишитесь на мой официальный аккаунт и ответьте на [JAVAPDF] в фоновом режиме, чтобы получить 200 страниц тестовых вопросов!Большие данные, на которые обращают внимание 50 000 человек, — это дорога к Богу, почему бы вам не прийти и не узнать об этом?50 000 человек обращают внимание на то, как большие данные становятся богом, разве вы не хотите узнать об этом?50 000 человек обращают внимание на то, как большие данные становятся богом, вы уверены, что действительно не хотите прийти и узнать об этом?

приветствую ваше внимание«Дорога к большим данным становится Богом»

大数据技术与架构

Примечания: Весь контент сначала публикуется на официальном аккаунте. Реальное время и полнота здесь не гарантируются. Пожалуйста, отсканируйте QR-код в конце статьи, чтобы обратить внимание~