vagrant@ubuntu:~$ mkdir nodejs && cd $_
vagrant@ubuntu:~/nodejs$ npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.
See `npm help json` for definitive documentation on these fields
and exactly what they do.
Use `npm install < pkg> save` afterwards to install a package and
save it as a dependency in the package.json file.
name: (nodejs)
version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
keywords:
author: ESSch
license: (ISC)
About to write to /home/vagrant/nodejs/package.json:
{
"name": "nodejs",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "ESSch",
"license": "ISC"
}
Is this ok? (yes) yes
Для начала создадим WEB-сервер. Я воспользуюсь библиотекой для его создания:
vagrant@ubuntu:~/nodejs$ npm install Express save
npm WARN deprecated Express@3.0.1: Package unsupported. Please use the express package (all lowercase) instead.
nodejs@1.0.0 /home/vagrant/nodejs
Express@3.0.1
npm WARN nodejs@1.0.0 No description
npm WARN nodejs@1.0.0 No repository field.
vagrant@ubuntu:~/nodejs$ cat << EOF > index.js
const express = require('express');
const app = express();
app.get('/healt', function (req, res) {
res.send({status: "Healt"});
});
app.listen(9999, () => {
console.log({status: "start"});
});
EOF
vagrant@ubuntu:~/nodejs$ node index.js &
[1] 18963
vagrant@ubuntu:~/nodejs$ { status: 'start' }
vagrant@ubuntu:~/nodejs$ curl localhost:9999/healt
{"status":"Healt"}
Наш сервер готов к работе с Prometheus. Нам нужно настроить Prometheus на него.
Проблема масштабирования Prometheus возникает, когда данные не помещаются на один сервер, точнее, когда один сервер не успевает записывать данные и когда обработка данных одним сервером не устраивает по перформансу. Thanos решает эту проблему, не требуя настройки федерации, предоставляя пользователю интерфейс и API, которые он транслирует на инстансы Prometheus. Пользователем доступен веб-интерфейс, аналогичный Prometheus. Сам он взаимодействует с агентами, которые установлены на инстансах как side-car, как это делает Istio. Он и агенты доступны как контейнера и как Helm-чарт. Например, агент может быть поднят как контейнер, настроенный на Prometheus, а Prometheus настраивается конфигом с последующей перезагрузкой.
docker run rm quay.io/thanos/thanos:v0.7.0 help
docker run -d net=host rm \
v $(pwd)/prometheus0_eu1.yml:/etc/prometheus/prometheus.yml \
-name prometheus-0-sidecar-eu1 \
u root \
quay.io/thanos/thanos:v0.7.0 \
sidecar \
-http-address 0.0.0.0:19090 \
-grpc-address 0.0.0.0:19190 \
-reloader.config-file /etc/prometheus/prometheus.yml \
-prometheus.url http://127.0.0.1:9090
Важной составляющей мониторинга являются уведомления. Уведомления состоят из триггеров срабатывания и провайдера. Триггер срабатывания пишется на PromQL как правило с условием в Prometheus. Когда сработал триггер (условие по метрике), Prometheus сигнализирует провайдеру отправить уведомление. Стандартным провайдером является Alertmanager и он способен отравлять сообщения в различные приёмники, такие как электронная почта и Slack.
, Например, метрика "up", принимающая значения 0 или 1, может быть использована, чтобы отравлять сообщение, если сервер выключен более 1 минуты. Для этого записывается правило:
groups:
name: example
rules:
alert: Instance Down
expr: up == 0
for: 1m
Когда метрика более 1 минуты равняется 0, то срабатывает этот триггер и Prometheus отравляет запрос на Alertmanager. В Alertmanager прописано, что делать с этим событием. Мы можем прописать, что при получении события InstanceDown нужно отравлять сообщение на почту. Для этого сконфигурируем Alertmanager это сделать:
global:
smtp_smarthost: 'localhost:25'
smtp_from: 'youraddress@example.org'
route:
receiver: example-email
receivers:
name: example-email
email_configs:
to: 'youraddress@example.org'
Сам Alertmanager воспользуется установленным протоколом на этом компьютере. Для того, чтобы он смог это сделать, его нужно установить. Возьмём, к примеру, протокол SMTP (Simple Mail Transfer Protocol). Для проверки, установим консольный почтовый сервер в параллель с Alert Manager sendmail.
Быстрый и наглядный анализ логов системы
Для быстрого поиска по логам используется OpenSource движок полнотекстового поиска Lucene. На его основе были построены два низкоуровневых продукта: Sold и Elasticsearch, довольно сходных по возможностям, но отличающихся по удобству использования и лицензии. На их построены многие популярные сборки, например, просто набор поставки с ElasticSearch: ELK (Elasticsearch(Apache Lucene), Logstash, Kibana), EFK (Elasticsearch, Fluentd, Kibana), так и продукты, например, GrayLog2. Как GrayLog2, так и сборки (ELK/EFK) активно используются из-за меньшей необходимости настраивать не тестовых стендах, так, например, поставить EFK в кластере Kubernetes можно практически одной командой
helm install efk-stack stable/elastic-stack set logstash.enabled=false set fluentd.enabled=true set fluentd-elastics
Альтернативой, пока не получившей большого рассмотрения являются системы, построенные на рассмотренном ранее Prometheus, например, PLG (Promtail(агент) Loki(Prometheus) Grafana).
helm install efk-stack stable/elastic-stack set logstash.enabled=false set fluentd.enabled=true set fluentd-elastics
Альтернативой, пока не получившей большого рассмотрения являются системы, построенные на рассмотренном ранее Prometheus, например, PLG (Promtail(агент) Loki(Prometheus) Grafana).
Сравнение ElasticSearch и Sold (системы сопоставимы):
Elastic:
** Коммерческий с открытым кодом и возможность коммитить (через апрув);
** Поддерживает более сложные запросы, больше аналитики, поддержка из коробки распределенных запросов, более полный REST-full JSON-BASH, чейнинг, машинное обучение, SQL (платный);
*** Full-text search;
*** Real-time index;
*** Мониторинг (платный);
*** Мониторинг через Elastic FQ;
*** Машинное обучение (платно);
*** Простая индексация;
*** Больше типов данных и структур;
** Движок Lucene;
** Parent-child (JOIN);
** Scalable native;
** Документация с 2010;
Solr:
** OpenSource;
** Большая скорость при JOIN;
*** Full-text search;
*** Real-time index;
*** Мониторинг в админке;
*** Машинное обучение через модули;
*** Входные данные: Work, PDF и другие;
*** Необходима схемы для индексации;
*** Данные: вложенные объекты;
** Движок Lucene;
** JSON join;
** Scalable: Solar Cloud (настройка) && ZooKeeper (настройка);
** Документация с 2004.
В нынешнее время всё чаще применяется микро сервисная архитектура, которая позволяет за счёт слабой
связанности между своими компонентами и их простоты упростить их разработку, тестирование и отладку.
Но в целом систему из-за её распределённости становится сложнее анализировать. Для анализа состояния
в целом применяются логи, собираемые в централизованное место и преобразуемые в понятный вид. Также возникает
необходимость в анализе других данных, например, access_log NGINX, для сбора метрик о посещаемости, лога почты,
почтового сервера для выявления попытки подбора пароля и т.д. Примером такого решения возьмём ELK. Под ELK понимается
связка трёх продуктов: Logstash, Elasticsearch и Kubana, первый и последний из который сильно заточены на центральный и
обеспечивают удобство работы. Более обобщённо ELK называют Elastic Stack, так как инструмент подготовки логов Logstash
может быть заменён аналогом, например Fluentd или Rsyslog, а средство визуализации Kibana на Grafana. Например, хоть и
Kibana предоставляет большие возможности для анализа, Grafana предоставляет отправку уведомлений при возникновениях событий, и
может использоваться совместно с другими продуктами, например, CAdVisor анализа состояния системы и отдельных контейнеров.
Продукты EKL могут быть установлены самостоятельно, скачаны в виде самодостаточных контейнеров, для которых нужно настроить
связь или в виде одного контейнера.
Для нормальной работы Elasticsearch нужно, чтобы данные приходили в формате JSON. Если данные предавать в
текстовом формате (лог пишется одной строкой, отделяется от предыдущий переносом строки), то он сможет
предоставить только полнотекстовый поиск, так как они будут восприниматься одной строкой. Для передачи
логов в формате JSON имеется два варианта: или настроить исследуемый продукт выдавать в этом формате,
например, для NGINX имеется такая возможность. Но, зачастую это невозможно, так как имеется уже
накопленная база логов, а традиционно они пишутся в текстовом формате. Для таких случаев необходима
пост обработка логов из текстового формата в JSON, которой занимается Logstash. Важно заметить, что если
есть возможность сразу же передавать данные в структурированном виде (JSON, XML и других), то следует это
сделать, так как если сделать детальный парсинг, то любое отклонение одностороннее отклонение от формата
приведёт с неработоспособности, а при поверхностном теряем ценную информацию. В любом случае парсинг в
этот системе является узким горлышком, хотя может ограниченно масштабироваться до сервиса или лога
файла. К счастью, всё больше и больше продуктов начинают поддерживать структурированные логи, например,
последние версии NGINX поддерживает логи в JSON формате.
Для систем, не поддерживающих данный формат можно использовать преобразование к нему с помощью таких
программ, как Logstash, File bear и Fluentd. Первый из них входит в стандартную поставку Elastic Stack от вендора
и может быть установлен одним образом ELK в Docker контейнер. Он поддерживает получение данных от файлов, сети и
стандартного потока как на входе, так и на выходе, а главное нативно внутренний протокол Elastic Search.
Logstash мониторит log-файлы на основе даты изменения или получает по сети данные по telnet от распределённой