Комментарии 18
"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 подпраивть.
Когда для мониторинга одной маленькой маломощной железки собирается железный кластер о трёх серверах?
Ну это же не мониторинг, роутер используется чисто как приманка для автоматических сканеров портов и ботнетов с той стороны интеренетов. С таким же успехов можно взять дешёвый 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 с ядра немаленькой ентерпрайз сети. Но как прототип эта конструкция вполне себя оправдала.
Конкретно по особенностям реализации в микротик, надо поставить «галку» «BSD Syslog» и логи будут приходить в читаемом виде, вместо Src.Address по итогу в поле hosts будет приходить «Identity name» — что особенно полезно в случае роутеров, которые находятся за 2-3 натом и нет впн.
ну, мне лично вообще из елка импонирует только сам эластик, а вся обвязка их… Ну, такое себе. Да, это цельная экосистема, да — можно получить поддержку от эластика (только вот исторически в РФ за нее никто не платит). Но вот fluentd в фонде CNCF, что напрямую не является преимуществом. Но говорит о том, что вендор-лока никакого не будет.
Собственно, на данный момент в роли хранилища логов используем ClickHouse. Из плюсов, достаточно быстрый, особенно на фоне ES (для сравнение, ClickHouse на аналогично наборе данных отдает ответ за 300мс против 1,5 сек у ES). Также, он не позволяет вольностей в виде содержимого записей, и как итог — предсказуемое наполнение базы.
А вот Logstash пока импонирует, вероятно потому что событий у нас не так много, порядка 150 событий/сек.
уточню — fluentd или fluent-bit? Второй тоже неплохой и ЕЩЕ БОЛЕЕ ЛЕГКОВЕСЕН.
также по другим логам, раскидываешь в свои индексы меняя match и store.
По fluent-bit посмотрю, слышал но не тестил.
P.S. По домашним замерам от работы fluentd и logstash — также есть видимая разница по нагрузке процессора и потреблению электричества. Хотел написать отдельно статью по часто используемому софту с сопоставимой нагрузкой, касательно энергопотребления.
Правда не в микротик а в JuniperSRX. Там можно логировать каждую сессию.
В результате на основе логов получился чудный анализатор трафика.
Самое сложное было грок фильтр набросать.
Где то у меня это все осталось. Могу поделиться.
Разбор настройки ELK 7.5 для анализа логов Mikrotik