Чем сложнее система, тем больше она обрастает всевозможными алертами. И возникает потребность на эти самые алерты реагировать, агрегировать их и визуализировать. Думаю, ситуация, знакомая многим до нервного тика.
Решение, о котором пойдёт речь, не самое неожиданное, но полноценной статьи по этой теме поиск не выдаёт.
Поэтому я решил поделиться опытом FunCorp и рассказать о том, как выстроен процесс дежурств, кто звонит, почему и как на это всё можно смотреть.
Давно была мысль посмотреть, что можно делать с ELK и подручными источниками логов и статистики. На страницах хабра планирую показать практический пример, как с помощью домашнего мини-сервера можно сделать, например, honeypot с системой анализа логов на основе ELK стека. В этой статье расскажу про простейший пример анализа логов firewall с помощью стека ELK. В дальнейшем хотелось бы описать настройку окружения для анализа Netflow трафика и pcap дампов инструментом Zeek.
Если у вас есть публичный IP-адрес и более-менее умное устройство в качестве шлюза/файрволла, вы можете организовать пассивный honeypot, настроив логирование входящих запросов на «вкусные» TCP и UDP порты. Под катом пример настройки маршрутизатора Mikrotik, но если у вас под рукой маршрутизатор другого вендора (или какая-то ещё security система), нужно просто немного разобраться с форматами данных и вендоро-специфичными настройками, и получится тот же результат.
Статья не претендует на оригинальность, здесь не рассматриваются вопросы отказоустойчивости сервисов, безопасности, лучших практик и т.д. Нужно рассматривать этот материал как академический, он подходит для ознакомления с базовым функционалом стека ELK и механизмом анализа логов сетевого устройства. Однако и не новичку может быть что-то интересно.
Проект запускается из docker-compose файла, соответственно развернуть своё подобное окружение очень просто, даже если у вас под рукой маршрутизатор другого вендора, нужно просто немного разобраться с форматами данных и вендоро-специфичными настройками. В остальном я постарался максимально подробно описать все нюансы, связанные с конфигурированием Logstash pipelines и Elasticsearch mappings в актуальной версии ELK. Все компоненты этой системы хостятся на github, в том числе конфиги сервисов. В конце статьи я сделаю раздел Troubleshooting, в котором будут описаны шаги по диагностике популярных проблем новичков в этом деле.
Читать полностью »
Те, кто уже работает в DevOps-культуре, не узнают ничего нового. А тем, кто только присматривается или планирует DevOps-трансформацию, мы расскажем:
— на каком этапе жизненного цикла сейчас находится DevOps как концепция;
— как с цифрами в руках понять экономический эффект от DevOps-трансформации и убедить руководство, что эта трансформация выгодна;
— как выглядит список DevOps-инструментов, и как мы на Слёрме DevOps помогаем изучить конкретный стек, чтобы быстро войти в тему;
— небольшое погружение в одну из тем Слёрма DevOps.
Ведет вебинар Эдуард Медведев, CTO Tungsten Lab, SRE-инженер, один из спикеров Слёрма DevOps.
Сейчас, когда наступил конец года и пришло время подводить итоги, мы хотим оглянуться на проделанную работу, отпраздновать достижения и поблагодарить всех, кто провел 2019 год вместе с Zabbix.
Эта заметка была написана в 2014-м году, но я как раз попал под репрессии на хабре и она не увидела свет. За время бана я про неё забыл, а сейчас нашёл в черновиках. Думал было удалить, но авось кому пригодится.
В общем, небольшое пятничное админское чтиво на тему поиска «включенного» LD_PRELOAD.
Читать полностью »
В одной из предыдущих статей я привел результаты тестирования дешевых виртуальных серверов от различных хостеров рунета. Спасибо всем комментаторам и людям, писавшим в личные сообщения, за обратную связь.
В этот раз я хочу представить результаты тестирования виртуальных серверов от известных и крупных компаний: DigitalOcean, Vultr, Linode и Hetzner. Сделано 38 тестов для всех доступных локаций.
Хотя характеристики виртуальных серверов на этот раз очень близки, но все же стоит напомнить, что формат тестирования не слишком объективен, и результаты стоит рассматривать с определенной долей иронии, так как измеренные величины весьма относительны.
Читать полностью »
Одним из реально полезных нововведений в Windows Server 2019 является возможность вводить серверы, не делая Sysprep или чистую установку. Развернуть инфраструктуру на виртуальных серверах с Windows Server никогда еще не было так просто.
Сегодня поговорим о том, насколько же, оказывается, просто устанавливать и управлять Active Directory через Powershell.
Читать полностью »
Реальность сетевого инженера (с лапшой и… солью?)
В последнее время, обсуждая с инженерами разные инциденты, я заметил интересную закономерность.
В этих обсуждениях неизменно возникает вопрос «первопричины». Верные читатели наверняка знают, что у меня есть несколько мыслей по этому поводу. Во многих организациях анализ инцидентов полностью основан на этой концепции. Они используют разные техники выявления причинно-следственных связей, такие как «Пять почему». Эти методы предполагают так называемую «линейность событий» как неоспоримую догму.
Когда вы подвергаете сомнению эту идею и указываете на то, что в сложных системах линейность успокаивающе обманчива, то рождается увлекательная дискуссия. Спорщики страстно настаивают, что только знание «первопричины» позволяет понять происходящее.
Я заметил интересную закономерность: разработчики и девопсы по-разному реагируют на эту идею. По моему опыту, разработчики чаще утверждают, что первопричина имеет значение и что в событиях всегда можно установить причинно-следственные связи. С другой стороны, девопсы чаще соглашаются, что сложный мир не всегда подчиняется линейности.
Читать полностью »
Прим. перев.: Эта практическая заметка от создателя LayerCI — отличный пример так называемых tips & tricks для Kubernetes. В ней рассказывается, как можно упростить некоторые привычные операции (по эксплуатации и отладке) благодаря использованию классических утилит. О том, какие именно операции, объясняет сам автор…
Представьте типичную ситуацию: вы хотите, чтобы порт на локальном компьютере волшебным образом перенаправлял трафик в pod/контейнер (или наоборот).Читать полностью »
Мы давно пользуемся облачными сервисами: почта, хранилища, соцсети, мессенджеры. Все они работают удаленно — отправляем сообщения и файлы, а хранятся и обрабатываются они на удаленных серверах. Также работает и облачный гейминг: пользователь подключается к сервису, выбирает игру и запускает. Для игрока это удобно, потому что игры запускаются почти мгновенно, не занимают память, и не нужен мощный игровой компьютер.
Для облачного сервиса все иначе — у него возникают проблемы хранения данных. Каждая игра может весить десятки или сотни гигабайт, например, «Ведьмак 3» занимает 50 Гбайт, а «Call of Duty: Black Ops III» — 113. При этом игроки не будут пользоваться сервисом с 2-3 играми, как минимум нужно несколько десятков. Кроме хранения сотен игр, сервису нужно решать, какой объем хранилища выделять на одного игрока, и масштабироваться, когда их будут тысячи.
Хранить ли все это на своих серверах: сколько их нужно, где ставить дата-центры, как «на лету» синхронизировать данные между несколькими дата-центрами? Покупать «облака»? Использовать виртуальные машины? Можно ли хранить данные пользователей со сжатием в 5 раз и предоставлять их в real-time? Как исключить любое влияние пользователей друг на друга при последовательном использовании одной и той же виртуальной машины?
Все эти задачи успешно удалось решить в Playkey.net — облачной игровой платформе. Владимир Рябов — руководитель отдела системного администрирования — подробно расскажет о технологии ZFS для FreeBSD, которая в этом помогла, и ее свежем форке ZOL (ZFS on Linux).
Читать полностью »
