Обновить
Комментарии 19

За рассказ про Vector — спасибо, за подробную инструкцию о том, как перезапускать сервисы systemd… Мы же не в детском саду, правда? А то так можно ещё рассказывать как нажимать Ctrl-C (Нажмите и держите зажатым Ctrl...), как попу вытирать и т.д. А то, вдруг, кто не знает.


Я к тому, что статья была бы куда читаемее, если бы там не уделялось внимание всем этим микротривиальным опрерациям. Я для себя его существование отметил, но из вашей статьи я не понял что он умеет и насколько хорошо — слишком много sysctl, сборок rpm и прочей требухи.

Выключаем Selinux на всех ваших серверах


дальше читать не стал…

Расскажите что с этим не так, пожалуйста.

Да все не так. Добровольное понижение уровня безопасности системы в современном мире очень глупый ход. Как выше писал уважаемый amarao вместо детального how-to «как перезапускать сервисы» тут должен был быть раздел о правильной настройке Selinux под нужды Vector, а не вот єто вот.

… В статье про vector лучше не надо вот этого вот мяса. В целом, SELinux как технология защиты требует слишком много внимания от оператора, так что начинать отладку с отключения selinux, к сожалению, общепринятая практика.


И виноват в этом дизайн selinux'а.

Да, к сожалению проблем от SEL больше чем пользы в большинстве случаев. И если пакет не идёт с хорошо составленными правилами для него — проще выключить, чем тратить кучу времени на настройку.


Но это всё, конечно же, зависит от требований безопасности.

вот да, вместо простыни пошаговых мануалов авторам не помешало бы выпустить качественно сделаный пакет.

Любопытное сравнение кликхаус и эластиксерч.
Тестирую похожее решение, journald > vector на клиентах, vector > elasticsearch на сервере.
Преимущества: скорость, дисковый кэш, меньше в несколько раз потребление памяти чем *beats.

Вариант небольшого развития схемы:
CREATE TABLE vector.logs
(
    `node_name` LowCardinality(String),
    `timestamp` DateTime,
    `server_name` LowCardinality(String),
    `user_id` String,
    `request_full` String CODEC(ZSTD(2)),
    `request_user_agent` String CODEC(ZSTD(2)),
    `request_http_host` LowCardinality(String),
    `request_uri` String,
    `request_scheme` LowCardinality(String),
    `request_method` LowCardinality(String),
    `request_length` UInt64,
    `request_time` Float32,
    `request_referrer` String CODEC(ZSTD(2)),
    `response_status` UInt16,
    `response_body_bytes_sent` UInt64,
    `response_content_type` LowCardinality(String),
    `remote_addr` IPv4, -- тут возможно стоит хранить в IPv6, как уже писали в комментариях
    `remote_port` UInt32,
    `remote_user` String,
    `upstream_addr` IPv4,
    `upstream_port` UInt32,
    `upstream_bytes_received` UInt64,
    `upstream_bytes_sent` UInt64,
    `upstream_cache_status` LowCardinality(String),
    `upstream_connect_time` Float32,
    `upstream_header_time` Float32,
    `upstream_response_length` UInt64,
    `upstream_response_time` Float32,
    `upstream_status` UInt16,
    `upstream_content_type` LowCardinality(String),
    INDEX idx_http_host request_http_host TYPE set(0) GRANULARITY 1
)
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY timestamp
TTL timestamp + toIntervalMonth(1)
SETTINGS index_granularity = 8192;


LowCardinality, если упрощать, это ENUM которому не нужно предварительно описывать в схеме варианты его значения

Сравнивать напрямую используемое место между CH и ES наверное не очень корректно т.к. последний индексирует все поля по умолчанию. Поэтому полнотекстовый поиск по индексу ES будет быстрый, а поиск по не-первичным (и непокрытым data-skipping индексами) полям в CH вызовет полное сканирование таблицы. Которое хотя и очень быстрое, но, всё же, если таблицы большие — будет идти долго.

Можно использовать clickhouse для статистики и держать там данные за пол года например, а в эластике скажем за последнюю неделю именно для поиска и чтения логов.
Ну и в vector можно легко делать разветвления и фильтры, например error логи кинуть в elastic а access логи в clickhouse. Мы переходили на эту связку так как нам нужна была именно статистика в разрезе клиента за 3 месяца и лог за сутки в эластике весил 200-250 гиг.Ну и vector может заменить logstash который ест очень много памяти.
По ipv6 можно наверно при создании таблицы в clickhouse сделать `remote_addr` IPv6
А в vector проверять наличие: в поле remote_addr и если его нет то добавлять ::ffff: перед адресом, делать это наверно лучше перед geoip и использовать ipv6 базу maxmind

Действительно, за деревьями леса не видно, как по мне. Про внутренности вектора почти ничего и не рассказано, всё заслоняют второстепенные подробности. Придется самому изучать. Хочется верить что оно менее невменяемо чем fluentbit.

А что там с fluent-bit, подробнее расскажете?

Ну вот например типовой случай: нужно собрать все логи с докер-демона, обогатить их данными k8s, потом разные пространства имён k8s отправить в различные индексы эластика плюс не перечисленные пространства в дефолтный индекс. Какой минимальный конфиг делает такое в векторе?


Я делал что-то похожее на fluentbit в 2019 (заменяя жручий и глючный fluentd) но помню что изматерился потому что надо было нарисовать кастомные PARSER, FILTER, INPUT плюс OUTPUT на каждый вид индексов и всё это густо приправлено кастомными регулярками и совершенно неочевидной даже из документаций логикой работы модулей fluentbit-а.


Когда последний раз смотрел доку, там ничего особо не поменялось. Так что в новой инсталляций плюнул и скидываю логи в один индекс. Хотелось бы чего-то более декларативного и cloud-native из коробки (fluentbit делался для embeded/IoT).


Потыкать вектор для сбора логов кластеров всё руки не дойдут. Хотя из доки очевидно что там много интересных фич.

Цитирую себя же из объяснения коллеге в декабре 2019-го:


Документация страдает неполнотой. Есть примеры но они не помогают сделать что-либо чуть более сложное чем конфигурация из коробки. В частности, чтобы разделить разные пространства имён k8s на разные индексы, пришлось прочитать всю документацию по модулям ввода, вывода, фильтрации, изучить багтрекер, попробовать пяток вариантов задания конфигурации целиком.

Я правильно понимаю, что фронтенда для кликхауса так и нет и сделать из него аналог ELK(чтоб в 2 клика делать всяческую аналитику) не получится?

Спасибо за статью.


В vector есть обработка сценариев при недоступности или медленном отклике со стороны Clickhouse? Нет сталкивались с тем что данные могут дублироваться?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.