Комментарии 21
За рассказ про Vector — спасибо, за подробную инструкцию о том, как перезапускать сервисы systemd… Мы же не в детском саду, правда? А то так можно ещё рассказывать как нажимать Ctrl-C (Нажмите и держите зажатым Ctrl...), как попу вытирать и т.д. А то, вдруг, кто не знает.
Я к тому, что статья была бы куда читаемее, если бы там не уделялось внимание всем этим микротривиальным опрерациям. Я для себя его существование отметил, но из вашей статьи я не понял что он умеет и насколько хорошо — слишком много sysctl, сборок rpm и прочей требухи.
Выключаем Selinux на всех ваших серверах
дальше читать не стал…
Расскажите что с этим не так, пожалуйста.
… В статье про vector лучше не надо вот этого вот мяса. В целом, SELinux как технология защиты требует слишком много внимания от оператора, так что начинать отладку с отключения selinux, к сожалению, общепринятая практика.
И виноват в этом дизайн selinux'а.
Да, к сожалению проблем от SEL больше чем пользы в большинстве случаев. И если пакет не идёт с хорошо составленными правилами для него — проще выключить, чем тратить кучу времени на настройку.
Но это всё, конечно же, зависит от требований безопасности.
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 вызовет полное сканирование таблицы. Которое хотя и очень быстрое, но, всё же, если таблицы большие — будет идти долго.
Ну и в vector можно легко делать разветвления и фильтры, например error логи кинуть в elastic а access логи в clickhouse. Мы переходили на эту связку так как нам нужна была именно статистика в разрезе клиента за 3 месяца и лог за сутки в эластике весил 200-250 гиг.Ну и vector может заменить logstash который ест очень много памяти.
А в 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? Нет сталкивались с тем что данные могут дублироваться?
Спросите в чате https://t.me/vectordev_ru
Отправка Nginx json логов с помощью Vector в Clickhouse и Elasticsearch