
Наверное вы уже догадались, о чём пойдёт речь под катом? :)
DevOps, системный администратор, архитектор, лид
«Всё хорошо в меру» — этот постулат относится к вечным ценностям. Но давайте посмотрим правде в глаза: кое-чего лучше вообще избегать. Это относится и к веществам, которые сегодня массово используются при производстве продуктов питания. Собственно, большую часть из них даже нельзя, строго говоря, считать едой. Пищевые технологи научились подменять самые, казалось бы, привычные продукты правдоподобными подделками, а индустрия оперирует тысячами наименований, начиная от искусственных красителей и заканчивая соединениями, произнести названия которых могут только кандидаты химических наук. В обычных условиях вы не стали бы даже трогать это, а не то что пробовать. Хотя вся эта дрянь и заполонила прилавки, радуя глаз ложным изобилием, это ещё не значит, что её стоит покупать и есть.
Под катом — вопиющие примеры того, как некоторые продукты питания являются по своему составу вовсе не тем, чем должны быть.
Что мы получим после этой статьи:
Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.
Какие логи будем собирать:
Обоснование выбора системы
Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.
Требования:
Приступим или добро пожаловать под кат
Данная статья отражает личный опыт и мнение её авторов и написана с целью призвать сообщество к обсуждению. Здесь не будут называться имена, ни на кого не будут показывать пальцем.
Мы попытаемся обратить внимание на то, что считаем проблемой современного российского рынка услуг в сфере информационной безопасности.
Чтобы читателям был понятен контекст, мы решили начать с бэкграунда. Статья написана аналитиком информационной безопасности (мной) и специалистом по тестированию на проникновение (моим коллегой InfiniteSuns ).
Работая с заказчиками, мы систематически сталкиваемся с непониманием сути оказываемых нами услуг. Нередко это непонимание вызвано тем, что оно перенеслось на заказчика от компании, которая оказывала эти услуги. Однажды в ходе проведения внутреннего пентеста повышение привилегий и устранение средств защиты на предоставленной заказчиком офисной машине вызвало недоумение у начальника службы ИБ.
Далее в ходе обсуждения выяснилось, что до этого под названием «пентест» заказчику продавали сканирование внутренней сети при помощи «nmap» с параметром «--script vuln». Естественно, в очередной раз заказчик ожидал от пентестеров подобного поведения и искренне удивился, когда они начали захватывать его контроллер домена.
Привет.
Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.
Самодостаточная система — это та, которая способна восстанавливаться и адаптироваться. Восстановление означает, что кластер почти всегда будет в том состоянии, в котором его запроектировали. Например, если копия сервиса выйдет из строя, то системе потребуется ее восстановить. Адаптация же связана с модификацией желаемого состояния, так чтобы система смогла справиться с изменившимися условиями. Простым примером будет увеличение трафика. В этом случае сервисам потребуется масштабироваться. Когда восстановление и адаптация автоматизировано, мы получаем самовосстанавливающуюся и самоадаптирующуюся систему. Такая система является самодостаточной и может действовать без вмешательства человека.
Как выглядит самодостаточная система? Какие ее основные части? Кто действующие лица? В этой статье мы обсудим только сервисы и проигнорируем тот факт, что железо также очень важно. Такими ограничениями мы составим картину высокого уровня, которая описывает (в основном) автономную систему с точки зрения сервисов. Мы опустим детали и взглянем на систему с высоты птичьего полёта.
Если вы хорошо разбираетесь в теме и хотите сразу всё понять, то система изображено на рисунке ниже.