Разворачивание Elastic Cloud on Kubernetes

 Привет всем. 

 ЕСК - это сбор, анализ и корреляция журналов, метрик и трассировок из контейнеров, приложений и служб, работающих поверх Docker и Kubernetes, — все это в одном месте.

Установим ЕСК на работающий кластер кубернетеса. В моем примере кубернетес работает под управлением Rancher'a. 

Elastic Cloud on Kubernetes (ECK) построен на шаблоне оператора Kubernetes.
Оператор ECK расширяет базовые возможности оркестрации Kubernetes для поддержки, настройки и управления Elasticsearch, Kibana и APM-сервером.

Операторы - программные расширения Kubernetes, которые используют пользовательские ресурсы для управления приложениями и их компонентами. Другими словами -это метод упаковки, развертывания и управления приложением Kubernetes.

Для установки оператора необходим работающий кластер Kubernetes с поддержкой RBAC и наличие командной утилиты kubectl, подключенной к кластеру.
Установка:
kubectl apply -f https://download.elastic.co/downloads/eck/1.2.1/all-in-one.yaml

Elasticsearch

С помощью kubectl выполним команду
cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 7.9.1
  nodeSets:
  - name: default
    count: 1
    config:
      node.master: true
      node.data: true
      node.ingest: true
      node.store.allow_mmap: false
EOF

Kibana

cat <<EOF | kubectl apply -f -
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 7.9.1
  count: 1
  elasticsearchRef:
    name: quickstart
EOF

Для примера созданы 2 модуля, посмотрим их в ранчере.

 

Для доступа из вне к кибане и эластику пробросим порты:

Готово! Можно подключать агенты сбора логов с приложений.

Ошибки во время установки

1. После установки модуля с кибаной появилась такая ошибка:

Readiness probe failed: Get https://10.41.1.44:5601/login: dial tcp : connect: connection refused

Смысл ее в том, что контейнер не успел задеплоиться из-за  HealthCkeck. Поэтому пришлось его отключить через настройки Workload модуля. 

Кубер включает в себя 2 типа проб(probes): liveness checks и readiness checks.

• Liveness Check: Проверяет, работает ли отслеживаемый контейнер. Если проба сообщает о сбое, Kubernetes убивает модуль, а затем перезапускает его в соответствии с политикой перезапуска развертывания (deployment restart policy).
• Readiness Check: Проверяет, готов ли контейнер принимать и обслуживать запросы. Если проба сообщает об отказе, модуль изолируется, пока не "починится".

2. Подключение к Elastic'у не выполняется по указаному порту. В логах такая ошибка:

Unable to revive connection: https://quickstart-es-http.default.svc:9200/

Проверьте протокол, скорей всего настроено на https, а не http

3. Для тестов можно отключить TLS. Требуется обновить конфиг эластика.

cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 7.9.1
  http:
    tls:
      selfSignedCertificate:
        disabled: true
  nodeSets:
  - name: default
    count: 1
    config:
      node.master: true
      node.data: true
      node.ingest: true
      node.store.allow_mmap: false
EOF

Успехов!

ELK: установка и запуск Elastalert оффлайн

Как мне показалось, что данное занятие совсем не тривиальное, решил создать небольшую заметку, как установить и запустить Elastalert. Сам делал по мануалу. Ну и плюс мои заметки.
Установка под RedHat 7.7
Итак, сохраняем все файлы с машины, где есть доступ к интернетам:
yum install --downloadonly --downloaddir=/elasta epel-release python36 python36-setuptools
 python36-devel python36-pip gcc
Затем устанавливаем все
yum install -y ...
Качаем последнюю версию elastalert'a и находим там файлик с зависимостями.
Далее сохраняем установочные файлы с помощью pip'a:
pip3 download -r /pathto/elastalert/requirements.txt
Устанавливаем по мануалу, или вкратце так:
Переносим все это добро в /tmp/elasta
Разорхивируем Elastalert в /opt/elastalert
Редактируем setup.py
Коментируем:
#'aws-requests-auth>=0.3.0',
 #'boto3>=1.4.4',
#'jira>=1.0.10,<1.0.15'
#'stomp.py>=4.1.17',
 #'twilio>=6.0.0,<6.1'
Изменяем версию jsonschema, чтобы подходила под требования.
'jsonschema>=2.6.0,<3.3.0'
Запускаем установку через Pip
python3 -m pip install . --find-links file:/tmp/elasta --no-index
Готово - установка завершена!
Создаем файл конфига:
cp config.yaml.example config.yaml
Редактируем настройки: время выполнения, хост-порт, авторизация и т.д.

После установки хочу запустить Elastalert(а именно сделать индекс под него elastalert-create-index), а получаю ошибку:
ModuleNotFoundError:
Все банальное просто - нужно добавить в env новый путь: /usr/local/bin
Ну или куда вы указали установить Elastalert.
export PATH="$PATH:/usr/local/bin/"
source ~/.bashrc
Также после запуска была такая ошибка:
File "/usr/local/lib/python3.6/site-packages/elastalert/auth.py", line 3, in <module>
    import boto3
ModuleNotFoundError: No module named 'boto3'
Т.к. в мануале я выключал установку boto3 то необходимо поправить скрипты запуска, закоментить вызовы бото и другого ПО, которое вы не установили.
vi /usr/local/lib/python3.6/site-packages/elastalert/auth.py

Создаем индекс для алертов:
elastalert-create-index --config /elastalert/config.yaml
 
Протестировать правило:
elastalert-test-rule --config config.yaml example_rules/example_frequency.yaml
Само правило => проверяем работоспособность апача, если ошибок более 500, отправляем уведомление:
# Rule name, must be unique
name: Example frequency rule

# Type of alert.
# the frequency rule type alerts when num_events events occur with timeframe time
type: frequency

# (Required)
# Index to search, wildcard supported
index: 87*

# (Required, frequency specific)
# Alert when this many documents matching the query occur within a timeframe
num_events: 500

# (Required, frequency specific)
# num_events must occur within this amount of time to trigger an alert
timeframe:
  hours: 4

# A list of Elasticsearch filters used for find events
# These filters are joined with AND and nested in a filtered query
# For more info: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html
filter:
- term:
    service.type: "apache"

# The alert is use when a match is found
alert:
- "email"

# a list of email addresses to send alerts to
email:
- "email@hst.ru"

smtp_host: "10.1.2.5"

Создаем службу для запуска Elastalert
vi /lib/systemd/system/elastalert.service
[Unit]
Description=elastalert
After=multi-user.target

[Service]
Type=simple
WorkingDirectory=/elastalert
ExecStart=/usr/local/bin/elastalert --verbose --rule example_rules/example_frequency.yaml

[Install]
WantedBy=multi-user.target


systemctl daemon-reload

В случае ошибки(или статуса работы) - мониторить:
tail  /var/log/messages | grep elasta

Успехов!

Kibana 7.5: ошибка отображения данных

Всем привет.
Столкнулся с проблемой построения данных в кибане при отображении дашборда за 7 дней и более. При том, что возникает не во всех дашбордах.
Ошибка звучит так:
Error in visualization
[esaggs] > Request to Elasticsearch failed: {"error":{}}         

Предположение: очевидное, но тем не менее - esaggs – это агрегации. Значит какие-то агрегации строятся и вызывают данную ошибку. При уменьшение интервала наблюдения до 5 дней, такой проблемы нет. Кроме того, график, который в рамках дашборда не отображается индивидуально открывается без проблем.

Начинаю анализировать на предмет "может есть какие-то логи в кибане, которые можно проанализировать на счет данной ошибки"?

Открываю логи эластика в режиме tail -f, логи Kibana:
tail /var/log/messages -f | grep kibana

Открываю дашборд на 10 дней. Запускаю обновление, смотрю сообщения о том, что происходит.Ошибок как таковых нет, все сообщения с ответом 200, все гут. Но не тут то было:
"res":{"statusCode":200,"responseTime":29929,"contentLength":9},"message":"POST /elasticsearch/apache*/_search?rest_total_hits_as_int=true&ignore_unavailable=true&ignore_throttled=true&preference=1581061538688&timeout=30000ms 200 29929ms - 9.0B"}
Есть такая тема как лимит ожидания, вот он то и виноват в этих сообщения. Есть визуализации, с двойными разрезами(split series) и фильтрами(filters), вот она и тормозит.
Нахожу в настройках эластика таймаут, увеличиваю:

# Time in milliseconds to wait for responses from the back end or Elasticsearch. This value
# must be a positive integer.
elasticsearch.requestTimeout: 40000

Сначала до 40 секунд, затем до 50. Зато теперь всплывают сообщения, что данные могут быть не полные, т.к. превышен лимит. Странно, что дефолтное значение мне про это не сказало.

В случае использования nginx'a, как прокси добавьте данные параметры:

proxy_connect_timeout       300;
proxy_send_timeout          300;
proxy_read_timeout          90m;
send_timeout                300;
 
client_max_body_size        1000m;

Успехов!

ELK-стек, немного теории

Индекс
Индекс в Elasticsearch - это набор документов, которые совместно используют некоторые
общие признаки. Каждый индекс содержит несколько типов, которые, в свою очередь, содержат несколько документов, и каждый документ содержит несколько полей. Индекс состоит из нескольких документов JSON, их может быть сколько угодно.
Примерно так:
http://localhost:9200/[index]/[type]/[doc]

Document
Документ в Elasticsearch - это документ JSON, хранящийся в индексе. Каждый
документ имеет тип и соответствующий идентификатор, который представляет его однозначно.
Типовой пример документа:

{
"_index" : "packtpub",

"_type" : "elk",

"_id" : "1",

"_version" : 1,

"found" : true,

"_source":{

    book_name : "learning elk" }

}

Тип
Тип используется для обеспечения логического разделения внутри индексов. Представляет собой класс аналогичных документов. Индекс может иметь
несколько типов, и мы можем определить их в соответствии с контекстом.
Например, индекс для Facebook может иметь "сообщение" в качестве одного из типов, комментарии - это другие типы документов.

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

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

Кластер
Кластер - это совокупность узлов, на которых хранятся индексированные данные.
Elasticsearch обеспечивает горизонтальную масштабируемость. Каждый кластер представлен именем кластера (имя кластера задается свойством с именем cluster.name в
конфигурация Elasticsearch elasticsearch.yml). По умолчанию, название кластера - Elasticsearch

Узел
Узел - это единственный запущенный экземпляр Elasticsearch, который принадлежит одному
из скоплений. По умолчанию каждый узел в Elasticsearch присоединяется к кластеру. Каждый Узел может иметь свою собственную конфигурацию, определенную в elasticsearch.yml, так же узел может иметь различные настройки относительно распределение памяти и ресурсов.

Data node
Узел данных - индексирует документы и выполняют поиск по ним. Всегда рекомендуется добавлять дополнительные узлы данных для повышения производительности или масштабирования кластера. Узел может быть представлен как узел данных, благодаря данным настройкам в формате YML
node.master = false
node.data=true

Masternode
Главный узел - отвечает за управление группой узлов. Для больших кластеров рекомендуется иметь три выделенных главных узла (один основной и два резервных), которые действуют только как главные узлы и не хранят индексы и не выполняют поиск. Узел может быть
сконфигурирован как выделенный главный узел с этой конфигурацией в формате YML:
node.master =true
node.data=false

Routing node or load balancer node
Узел маршрутизации или узел балансировки нагрузки - эти узлы не играют
роль либо главного узла, либо узла данных, но просто выполняют балансировку нагрузки, либо занимаются маршрутизацией запросов на поиск или индексирование документа в
соответствующие узлы. Это полезно для больших объемов поиска информации. Узел может быть настроен как узел маршрутизации в формате YML:
node.master =false
node.data=false

Успехов!

  
 

ELK: логи

Немного теории про логи (из книги Pranav SHukla и SHarat_Kumar ElasticSearch)
 
Логи — это записи об инцидентах или наблюдениях. Логи создаются широким спектром ресурсов, таких как системы, приложения, устройства и т.д. 
Типовой лог:

Log = Timestamp + Data

Логи используются для следующих целей.

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

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

• Аудит. Многие организации должны придерживаться тех или иных процедур проверки на соответствие и вынуждены вести логи. Например, входы пользователей в систему или их транзакции обычно хранятся в логах определенный промежуток времени, чтобы можно было провести аудит или анализ злоумышленной деятельности пользователей/хакеров.

• Предиктивная аналитика. С развитием машинного обучения, искусственного интеллекта и методов извлечения данных появился новый тренд — предиктивная аналитика.Как правило, используется для анализа пользовательских действий и показа ему рекламы=)

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

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

Перечислим некоторые из особенностей Logstash.

• Гибкая архитектура, основанная на плагинах. Logstash содержит более 200 плагинов, разработанных компанией Elastic и сообществом открытого исходного кода. Вы можете использовать их для объединения, сопоставления и организации различных источников ввода, фильтров и выводов, а также создания контейнеров для обработки данных.

• Расширяемость. Компонент Logstash написан на Jruby и поддерживает гибкую архитектуру. Допускается создание собственных плагинов для персональных нужд.

• Централизованная обработка данных. Данные из любых источников можно легко извлекать с применением разнообразных плагинов ввода, а также дополнять их, изменять и отправлять различным получателям.

• Универсальность. Logstash поддерживает обработку всех типов логов, таких как логи Apache, NGINIX, системные логи, логи событий Windows. Он также предоставляет сбор метрик из широкого спектра приложений через TCP и UDP. Logstash может трансформировать запросы HTTP в события, поддерживает такие приложения, как Meetup, GitHub, JIRA и др. Возможен также сбор данных из имеющихся реляционных/NoSQL баз данных и очередей, включая Kafka, RabbitMQ и т.п. Контейнер обработки данных Logstash может быть легко масштабирован горизонтально. Начиная с Logstash 5, поддерживаются постоянные очереди, благодаря чему обеспечивается возможность надежно обрабатывать большие объемы входящих событий/данных.

• Совместная работа. Logstash имеет высокую связность с компонентами Elasticsearch, Beats и Kibana, что облегчает создание сквозных решений для анализирования логов.