Pull to refresh

Comments 18

Это тема Shades of Purple, но с немного кастомизироваными цветами.
settings.json
"workbench.colorCustomizations": {
"[Shades of Purple]": {
"activityBar.activeBorder": "#fa00e5",
"activityBar.foreground": "#fa00e5",
"editor.selectionHighlightBorder": "#cc42aa",
// "editor.lineHighlightBorder": "#cc42aa",
"editor.lineHighlightBackground": "#b242e680",
"list.activeSelectionForeground": "#cc42aa",
"editorSuggestWidget.highlightForeground": "#cc42aa",
"editorSuggestWidget.foreground": "#ddaad0",
"menu.selectionForeground": "#cc42aa",
"statusBar.background": "#7e01a7",
"peekViewResult.selectionForeground": "#cc42aa",
"breadcrumb.focusForeground": "#cc42aa",
"dropdown.foreground": "#ddaad0",
"badge.foreground": "#cc42aa",
"editorHint.foreground": "#fa00bb",
"editorLineNumber.activeForeground": "#fa00bb",
"list.focusForeground": "#fa00e5",
"tab.activeForeground": "#b974e0",
"breadcrumb.activeSelectionForeground": "#cc42aa",
"breadcrumb.foreground": "#ddaad0",
"contrastActiveBorder": "#cc42aa",
"focusBorder": "#cc42aa",
// "foreground": "#fa00bb",
"widget.shadow": "#cc42aa",
// "contrastBorder": "#fa00bb"
}
}

Поставил плюс, ну, потому что круто же!
Какие планы дальше? Netflow?
Но все равно не отпускает вопрос — а не похоже ли это на стрельбу по воробьям? Когда для мониторинга одной маленькой маломощной железки собирается железный кластер о трёх серверах?


Так как в последних версиях docker-compose выпилили параметр mem_limit и добавили deploy, запускающийся только в swarm mode (docker stack deploy), то запуск docker-compose up конфигурации с лимитами приводит к ошибке. Так как я не использую swarm, а лимиты ресурсов иметь хочется, запускать приходится с опцией --compatibility, которая конвертирует лимиты из docker-compose новых версий в нон-сварм эквивалент.

Дополнение. Это не новая версия компоуза, а есть два параллельных формата — 2+2.x и 3.x. Первый — с лимитами и прочими полезными ништяками, второй — для сворма. Т.к. сворм не используете, то имеет смысл переключиться на 2.4.


depends_on

плохая история. При ребуте сервера порядок запуска сервисов (докер контейнеров) будет произвольный. Оборачивать docker-compose в systemd unit — фу-фу-фу. Лучше уж тогда: перейти на отдельные systemd юниты для сервисов, деплоить ансиблом. Но здесь важно от того насколько это MVP/PoC.


И еще. Приложенный компоуз не заведется, т.к. на хосте с эластиком надо sysctl из раздела vm подпраивть.

Спасибо за замечания. По поводу «стрельбы по воробьям» — это делалось как простой PoC на выходных в свободное от работы время, чтобы разобраться с некоторыми технологиями, использовать такую схему никому не предлагаю :) то есть, это чисто для демонстрации тонких моментов сбора и визуализации данных.

Когда для мониторинга одной маленькой маломощной железки собирается железный кластер о трёх серверах?

Ну это же не мониторинг, роутер используется чисто как приманка для автоматических сканеров портов и ботнетов с той стороны интеренетов. С таким же успехов можно взять дешёвый VPS и там развернуть syslog + logstash, например. О каких железных кластерах идёт речь, не понял. У меня все сервисы запускаются на одном домашнем сервере (на самом деле, Elastic и Kibana я потом запустил на другом более мощном сервере и прокинул порты через SSH).

Это не новая версия компоуза, а есть два параллельных формата — 2+2.x и 3.x. Первый — с лимитами и прочими полезными ништяками, второй — для сворма. Т.к. сворм не используете, то имеет смысл переключиться на 2.4.

Всё верно, две ветки параллельно развивающиеся ветки, я немного неправильно передал смысл. Но я уже привык было к спецификациям версии 3.х (в других многочисленных docker-compose.yml), а в этом проекте понадобилось залимитировать ресурсы, так как запускать ELK без лимитов на низкопроизводительном железе чревато (у меня сервер иногда вис намертво). Оказалось, что в версии 3.х можно использовать с лимитами ресурсов и без swarm с этим ключом --compatibility.

плохая история. При ребуте сервера порядок запуска сервисов (докер контейнеров) будет произвольный.

А как правильно сделать, чтобы у сервиса оставалась зависимость от другого сервиса и всё работало нормально? Я где-то видел рекомендации на этот счёт, но как-то не вникал в суть, всё-таки это не продакшен и если что-то не так, что вручную можно разрулить проблему с незапустившимся сервером.

Оборачивать docker-compose в systemd unit — фу-фу-фу.

Ну так тут про systemd юниты речь не идёт, я не сторонник такого. А про автоматический деплой такой лабы ансиблом вообще тоже думал, было бы интересно реализовать.

Приложенный компоуз не заведется, т.к. на хосте с эластиком надо sysctl из раздела vm подпраивть.

Возможно, на чистой системе нужно будет что-то сделать дополнительно на уровне OS, я не проверял весь сценарий на свежеразвёрнутом докер-хосте, а на своих двух серверах это сделал давно. В любом случае, это немного выходит за скоп тех знаний, что я хотел донести до сообщества :) хотя добавить в статью не сложно, сейчас сделаю.

Какие планы дальше? Netflow?

Если будет не лень, то когда-нибудь в следующем году добавлю сбор Netflow (или sflow), для этого нужно найти интересный участок сети, домашняя локалка уже не так интересна для этого. Либо можно добавить access логи реверс-прокси, чтобы видеть, в какие url долбятся боты, это тоже забавно. И совсем не сложно сделать по аналогии.
Возможно, на чистой системе нужно будет что-то сделать дополнительно на уровне OS, я не проверял весь сценарий на свежеразвёрнутом докер-хосте, а на своих двух серверах это сделал давно. В любом случае, это немного выходит за скоп тех знаний, что я хотел донести до сообщества :) хотя добавить в статью не сложно, сейчас сделаю.

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


А как правильно сделать, чтобы у сервиса оставалась зависимость от другого сервиса и всё работало нормально?

Обернуть конкретные контейнеры в системди юниты и между ними наладить связи?


Оказалось, что в версии 3.х можно использовать с лимитами ресурсов и без swarm с этим ключом --compatibility.

Интересно, спасибо


каких железных кластерах идёт речь, не понял.

Я имел в виду две вещи. И то что эластик очень ресурсоемок (джава как никак), так и то, что маленький микротик может генерить логов столько, что для их разбора понадобится существенно больше вычислительных ресурсов.

Но все равно не отпускает вопрос — а не похоже ли это на стрельбу по воробьям? Когда для мониторинга одной маленькой маломощной железки собирается железный кластер о трёх серверах?

Микротиков в хозяйстве может быть несколько сотен, например. Топовые клауд-роутеры вполне себе производительные. Зато благодаря контейнеризации это можно всё масштабировать.

Это все истерия с контейнеризацией. Не все нужно туда всовывать по разным причинам. И тот же КХ и эластик масштабируются сами по себе нормально. Без контейнеров. Я уж не говорю о том, что джава — сама по себе контейнер в некотором смысле.
Т.е. — если надо масштабировать горизонтально КХ/эластик — проще нарезать виртуальных машин. Или железных серверов доставить. Чем играть с контейнерами. Я уж не говорю о том, что оба продукта не любят делить вычислительный узел с какой-либо ещё нагрузкой. Иначе можно ловить весьма странные спецэффекты
Если речь про тестовый стенд — ну, да, тут контейнеры могут помочь его собрать из готовых компонентов максимально быстро. Но надо же отделять "демо" и "промышленную" эксплуатацию

поддержу.
пару лет назад игрался в разворачивание нескольких шард эластика плюс конечно же логстеш и кибана в докере и все внутри одного хоста.
И что-то вся эта фигня очень долго взлетала и через несколько часов стабильно падала. Правда данных было действительно много. принимал логи разные + netflow с ядра немаленькой ентерпрайз сети. Но как прототип эта конструкция вполне себя оправдала.
В свое время тоже использовали logstash. Но сейчас переходим на fluentd. Более легковесный, использует немного ресурсов, настраивается легко и есть встроенные парсеры по syslog.
Конкретно по особенностям реализации в микротик, надо поставить «галку» «BSD Syslog» и логи будут приходить в читаемом виде, вместо Src.Address по итогу в поле hosts будет приходить «Identity name» — что особенно полезно в случае роутеров, которые находятся за 2-3 натом и нет впн.
Полезное замечание для тех, кто собирает логи в продакшене. Я использовал logstash только лишь из-за того, что это популярный продукт, с понятным мануалом и конфигом, и есть уже готовые шаблоны, в том числе для того формата, который стоит в Микротике по умолчанию. Так-то ест он много, я тоже думаю попробовать перейти на fluentd, хотя у меня нагрузки особо нет и запускаю такое время от времени.
А что стало причиной перехода? Logstash перестал переваривать поток логов? Или конфигурация разрослась и стало крайне неудобно?

ну, мне лично вообще из елка импонирует только сам эластик, а вся обвязка их… Ну, такое себе. Да, это цельная экосистема, да — можно получить поддержку от эластика (только вот исторически в РФ за нее никто не платит). Но вот fluentd в фонде CNCF, что напрямую не является преимуществом. Но говорит о том, что вендор-лока никакого не будет.

Интересное мнение. У нас немного другой опыт. Из всей связки мы используем только Logstash. ES выкинули на помойку по ряду причин. Во-первых, он таки тяжелый. Во-вторых, он не очень хорошо переживает «катастрофы» в виде отключения питания. Да, понимаю, тут сказывается небольшой опыт работы с ним. Но, если он исключительно для логов, далеко не все будут для этой цели искать нормального специалиста или глубоко изучать это решение. И третье — скорость работы. И последнее, документоориентированные СУБД позволяют вольности в виде содержимого документов, а это может превратить данные в помойку.
Собственно, на данный момент в роли хранилища логов используем ClickHouse. Из плюсов, достаточно быстрый, особенно на фоне ES (для сравнение, ClickHouse на аналогично наборе данных отдает ответ за 300мс против 1,5 сек у ES). Также, он не позволяет вольностей в виде содержимого записей, и как итог — предсказуемое наполнение базы.
А вот Logstash пока импонирует, вероятно потому что событий у нас не так много, порядка 150 событий/сек.

Касательно КХ — мне не очень понравилась их реализация шардинга-репликации.
По Эластику — у них раньше действительно была проблема с целостностью данных, но КХ тоже не про это ) если подумать.
В принципе, мне кажется, что КХ для логов — это не самый плохой и допустимый вариант.

уточню — fluentd или fluent-bit? Второй тоже неплохой и ЕЩЕ БОЛЕЕ ЛЕГКОВЕСЕН.

td-agent (fluentd). Как писал выше, с logstash в качестве hosts выступает src address, если хочется менять имя, то надо менять в грок, откуда пришло-менять имя и перенаправлять. Но ведь хочется один конфиг и чтобы все автоматом.
также по другим логам, раскидываешь в свои индексы меняя match и store.
По fluent-bit посмотрю, слышал но не тестил.
P.S. По домашним замерам от работы fluentd и logstash — также есть видимая разница по нагрузке процессора и потреблению электричества. Хотел написать отдельно статью по часто используемому софту с сопоставимой нагрузкой, касательно энергопотребления.
Было бы очень интересно почитать про энергопотребление, так как мне как раз актуально для таких хобби-проектов запускать софт на домашнем мини-сервере. И в планах купить ещё пару серверов, собрать кластер. Интресно, на сколько энергопотребление различается при использовании разных софтовых продуктов.
Прикольно. Пару лет назад игрался ровно в то же самое.
Правда не в микротик а в JuniperSRX. Там можно логировать каждую сессию.
В результате на основе логов получился чудный анализатор трафика.
Самое сложное было грок фильтр набросать.
Где то у меня это все осталось. Могу поделиться.
Sign up to leave a comment.

Articles