Распределенное решение для анализа журналов в реальном времени Архитектура развертывания ELK

задняя часть Архитектура

I. Обзор

В настоящее время ELK стал самым популярным решением для централизованного ведения журналов.Он в основном состоит из Beats, Logstash, Elasticsearch, Kibana и других компонентов, которые вместе создают универсальное решение для сбора, хранения и отображения журналов в реальном времени. В этой статье будет представлена ​​общая архитектура ELK и решение связанных с ней проблем.

  1. Filebeat: Filebeat — это облегченный движок сбора данных, занимающий очень мало сервисных ресурсов, новый член семейства ELK, способный заменить Logstash в качестве движка сбора логов на стороне сервера приложений и поддерживающий вывод собранных данных в Kafka. Очереди, такие как Redis.
  2. Logstash: механизм сбора данных более тяжелый, чем Filebeat, но он интегрирует большое количество подключаемых модулей, поддерживает сбор обширных источников данных и может фильтровать, анализировать и форматировать собранные данные в формате журнала.
  3. Elasticsearch: поисковая система распределенных данных, основанная на Apache Lucene, может быть кластеризована, обеспечивая централизованное хранение данных, анализ и мощные функции поиска и агрегирования данных.
  4. Kibana: платформа визуализации данных, с помощью которой вы можете просматривать релевантные данные в Elasticsearch в режиме реального времени и предоставлять расширенные функции статистики диаграмм.

Во-вторых, общая архитектура развертывания ELK.

2.1, Logstash как сборщик логов

Эта архитектура является относительно примитивной архитектурой развертывания.Компонент Logstash развертывается на каждой стороне сервера приложений в качестве сборщика журналов, а затем данные, собранные Logstash, фильтруются, анализируются, форматируются и отправляются в хранилище Elasticsearch, и, наконец, используется Kibana. недостатком этой архитектуры является то, что Logstash потребляет больше ресурсов сервера, что увеличивает нагрузку на сервер приложений.

2.2, Filebeat как сборщик логов

Единственная разница между этой архитектурой и первой архитектурой заключается в том, что сборщик журналов на стороне приложения заменен на Filebeat. Filebeat является легким и занимает меньше ресурсов сервера. Поэтому Filebeat используется в качестве сборщика журналов на стороне сервера приложений. быть использован вместе с Logstash, Этот метод развертывания также является наиболее часто используемой архитектурой сегодня.

2.3. Знакомство с архитектурой развертывания кэш-очереди

Эта архитектура вводит очередь сообщений Kafka (или другие очереди сообщений) на основе второй архитектуры, отправляет данные, собранные Filebeat, в Kafka, а затем считывает данные в Kafka через Logstasth.Эта архитектура в основном предназначена для решения схемы сбора журналов. при большом объеме данных использование очередей кеша в основном предназначено для решения проблемы безопасности данных и балансировки нагрузки Logstash и Elasticsearch.

2.4. Резюме трех вышеупомянутых архитектур

Первая архитектура развертывания используется редко из-за занятости ресурсов.В настоящее время наиболее часто используется вторая архитектура развертывания.Что касается третьей архитектуры развертывания, я лично считаю, что нет необходимости вводить очереди сообщений, если нет других требований, потому что объем данных. В больших случаях Filebeat отправляет данные в Logstash или Elasticsearch, используя протокол, чувствительный к давлению. Если Logstash занят обработкой данных, он сообщает Filebeat замедлить чтение. После того, как перегрузка будет устранена, Filebeat возобновит свою первоначальную скорость и продолжит отправку данных.

3. Проблемы и решения

Вопрос: Как реализовать функцию многострочного слияния лога?

Журналы в системных приложениях обычно печатаются в определенном формате.Данные, относящиеся к одному и тому же журналу, могут быть напечатаны в несколько строк.При использовании ELK для сбора журналов необходимо объединить несколько строк данных, принадлежащих одному и тому же журналу.

Решение. Для этого используйте плагин многострочного слияния в Filebeat или Logstash.

При использовании многострочного многострочного плагина слияния следует учитывать, что разные архитектуры развертывания ELK могут использовать многострочное по-разному.Если это первая архитектура развертывания в этой статье, то многострочное развертывание необходимо настроить в Logstash.Если это вторая архитектура развертывания, то мультилайн нужно настраивать и использовать в Filebeat, и нет необходимости настраивать мультилайн в Logstash.

1. Как настраивается мультилиния в Filebeat:

filebeat.prospectors:
    -
       paths:
          - /home/project/elk/logs/test.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
output:
   logstash:
      hosts: ["localhost:5044"]
  • шаблон: регулярное выражение
  • отрицание: по умолчанию false, что означает, что строки, соответствующие шаблону, объединяются в предыдущую строку; true означает, что строки, не соответствующие шаблону, объединяются в предыдущую строку
  • match: after означает слияние с концом предыдущей строки, before означает слияние с началом предыдущей строки

Такие как:

pattern: '\['
negate: true
match: after

Эта конфигурация означает объединение строк, которые не соответствуют шаблону шаблона, до конца предыдущей строки.

2. Как настраивается мультилайн в Logstash

input {
  beats {
    port => 5044
  }
}

filter {
  multiline {
    pattern => "%{LOGLEVEL}\s*\]"
    negate => true
    what => "previous"
  }
}

output {
  elasticsearch {
    hosts => "localhost:9200"
  }
}

(1) Значением атрибута what, настроенного в Logstash, является предыдущее, что эквивалентно after в Filebeat, а значением атрибута what, настроенного в Logstash, является next, что эквивалентно before в Filebeat.
(2) LOGLEVEL в шаблоне => "%{LOGLEVEL}\s*\]" – это стандартный шаблон сопоставления, предварительно созданный Logstash, и существует множество готовых шаблонов регулярного сопоставления. Подробную информацию см. на странице https://github.com. /logstash-плагины/logstash-шаблоны-ядро/дерево/мастер/шаблоны

Вопрос: Как заменить поле времени в Kibana, показывающее журналы, на время в информации журнала?

По умолчанию поле времени, которое мы просматриваем в Kibana, не соответствует времени в информации журнала.Поскольку значением поля времени по умолчанию является текущее время, когда журнал собирается, необходимо заменить время в этом поле на время в информация журнала.

Решение: используйте плагин сегментации слов grok и плагин форматирования даты и времени для достижения

Настройте подключаемый модуль сегментации слов grok и подключаемый модуль форматирования даты и времени в фильтре файла конфигурации Logstash, например:

input {
  beats {
    port => 5044
  }
}

filter {
  multiline {
    pattern => "%{LOGLEVEL}\s*\]\[%{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME}\]"
    negate => true
    what => "previous"
  }

  grok {
    match => [ "message" , "(?<customer_time>%{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME})" ]
  }

  date {
        match => ["customer_time", "yyyyMMdd HH:mm:ss,SSS"] //格式化时间
        target => "@timestamp" //替换默认的时间字段
  }
}

output {
  elasticsearch {
    hosts => "localhost:9200"
  }
}

Если сопоставляемый формат журнала: «[DEBUG][20170811 10:07:31,359][DefaultBeanDefinitionDocumentReader:106] Загрузка определений компонентов», способ анализа поля времени журнала:

①Вводя записанный файл выражения, такой как файл выражения customer_patterns, содержимое:
CUSTOMER_TIME %{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME}
Примечание:Формат содержимого: [имя пользовательского выражения] [регулярное выражение]
Затем в logstash на него можно ссылаться так:

filter {
  grok {
      patterns_dir => ["./customer-patterms/mypatterns"] //引用表达式文件路径
      match => [ "message" , "%{CUSTOMER_TIME:customer_time}" ] //使用自定义的grok表达式
  }
}

②В форме элементов конфигурации применяются следующие правила: (?регулярные правила сопоставления), например:

filter {
  grok {
    match => [ "message" , "(?<customer_time>%{YEAR}%{MONTHNUM}%{MONTHDAY}\s+%{TIME})" ]
  }
}

Вопрос: Как просматривать данные в Kibana, выбирая разные модули syslog

Как правило, данные журнала, отображаемые в Kibana, смешиваются с данными из разных системных модулей, поэтому как выбрать или отфильтровать данные журнала, чтобы просмотреть только указанный системный модуль?

Решение: добавьте поля для идентификации различных системных модулей или создайте индексы ES на основе различных системных модулей.

1. Добавьте поле для идентификации различных системных модулей, а затем Kibana сможет фильтровать и запрашивать данные различных модулей в соответствии с этим полем.
Здесь объясняется вторая архитектура развертывания.Содержимое конфигурации в Filebeat:

filebeat.prospectors:
    -
       paths:
          - /home/project/elk/logs/account.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       fields: //新增log_from字段
         log_from: account

    -
       paths:
          - /home/project/elk/logs/customer.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       fields:
         log_from: customer
output:
   logstash:
      hosts: ["localhost:5044"]

Определите различные журналы системных модулей, добавив: поле log_from

2. Настройте соответствующий индекс ES в соответствии с различными системными модулями, а затем создайте соответствующее соответствие шаблону индекса в Kibana. Вы можете выбрать различные данные системного модуля в раскрывающемся списке шаблона индекса на странице.
Здесь объясняется вторая архитектура развертывания, которая разделена на два этапа:
① Содержимое конфигурации в Filebeat:

filebeat.prospectors:
    -
       paths:
          - /home/project/elk/logs/account.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       document_type: account

    -
       paths:
          - /home/project/elk/logs/customer.log
       input_type: log 
       multiline:
            pattern: '^\['
            negate: true
            match: after
       document_type: customer
output:
   logstash:
      hosts: ["localhost:5044"]

Идентифицировать различные системные модули по document_type

② Измените содержимое конфигурации вывода в Logstash следующим образом:

output {
  elasticsearch {
    hosts => "localhost:9200"
    index => "%{type}"
  }
}

Добавить атрибут индекса в вывод, %{type} означает построение индекса ES в соответствии с различными значениями document_type

4. Резюме

В этой статье в основном представлены три архитектуры развертывания анализа журнала ELK в реальном времени и проблемы, которые могут быть решены с помощью различных архитектур.Второй метод развертывания среди трех архитектур является наиболее популярным и часто используемым методом развертывания в настоящее время.Наконец, в нем представлены как ELK используется в Некоторые проблемы и решения в анализе журналов, В конце концов, ELK можно использовать не только как централизованный запрос и управление распределенными данными журнала, но также как проектное приложение и мониторинг ресурсов сервера и другие сценарии.Подробнее информацию смотрите на официальном сайте.

 

 

Категории