В продолжение об своих экспериментах с хранением логов на ELKR пишу некий «мануал» по установке и базовой настройке.

Те статьи, которые ОЧЕНЬ помогли:
Собираем, парсим и отдаём логи с помощью Logstash — матчасть
Собираем и анализируем логи с помощью Lumberjack+Logstash+Elasticsearch+RabbitMQ — хороший пример реального использования

Спасибо авторам!

Итак, мы будем разворачивать следующую архитектуру:
Device => HAProxy => Logstash-Listener => RabbitMQ => Logstash-Filter => Elasticsearch-Balancer => Elasticsearch DATA/MASTER

Сегодня Intel Edison с набором датчиков и актюаторов поможет нам сделать следующее: сыграть песенку «В траве сидел кузнечик», определить, хорошо ли течет вода, горит ли огонь, перекачать воду, проверить есть ли в воздухе пары спирта, пыльная ли комната, проследить, как закипает чайник, определить свои координаты, найти магнит. И что-нибудь ещё.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Каждому сисадмину приходится иногда обслуживать компьютеры знакомых или совершать надомные выезды. В этом деле ему помогает проверенный набор утилит. Наш обзор расскажет только о бесплатных, не требующих установки и ставших стандартом де-факто.

Что делать если вашего роутера не оказалось в списке поддерживаемых устройств OpenWRT? Конечно же сделать свой порт. Это можно сделать довольно быстро, если поддержка данной платформы уже реализована.
В этой статье я расскажу о процессе портирования прошивки в целом и о моем опыте портирования OpenWRT на ASUS DSL N12U.

Рад сообщить, что cайт lamptest.ru (он же lamptest.com), над которым мы работали полгода, сегодня заработал в «боевом» режиме.



На сайте собраны данные по протестированным мной светодиодным лампам. Сейчас их там 102, но уже скоро добавится ещё пара десятков. На сайте уже есть данные по всем лампочкам Ikea, по большому количеству ламп Thomson, Navigator, Gauss.

Привет Хабр! Это вторая статья по практическому применению модулей Ethernet-управления Laurent (здесь первая часть) и, как ты любишь, речь пойдет про программирование, а, точнее, про подгонку WEB-интерфейса под свои интересы. Может пригодиться системным интеграторам для того, чтобы предоставить заказчикам продукт со своим фирменным внешним видом, да и частному пользователю будет удобнее оперировать кнопками с понятными названиями, без лишней обвязки на экране. Кроме этого, доступно и некоторое изменение функционала.

Итак…

Bareos (Backup Archiving Recovery Open Sourced) является централизованной, клиент-серверной и кроссплатформерной системой для резервного копирования, архивирования и восстановления данных.



Является форком Bacula и активно развивается. Имеет клиенты под Linux и Windows. Полный список поддерживаемых фич на Github.

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.

Один мой друг, большой поклонник идеи родовых поместий, примерно год назад стал обживать свой участок земли вдали от сел и городов. Построил деревянный дом, баню, организовал подсобное хозяйство. Обзавелся красавицей-женой, собакой модели «хаскоалабай» и кошкой Кусей. И все вроде хорошо, можно жить и развиваться, но здорово не хватает подключения к интернету — ездить каждый раз за 70км в город, чтобы почитать форумы по строительству, солнечной энергетике, садоводству да и просто пообщаться с друзьями онлайн стало неудобно и накладно.

С этой проблемой он обратился ко мне. Я приступил к решению задачи, уточнив вводные условия:

• Из сотовых 3G-операторов голосовая связь работает только у Билайна, и то, если подойти к окошку. Ловится еще TELE2, но у него нет 3G;
• Интернет через USB-модем у соседей загружает среднюю страницу по 10 минут;
• Ближайший населенный пункт в 7км, ближайший «крупный» (28 тыс.человек) — в 30км;

Здравствуйте! Сегодня хочу рассказать о том, как сделать устройство, которое позволяет копировать Touch Memory фирмы Dallas. Статья предназначена для тех, кто имеет опыт в программирование на языках C/C++. Рассказывать, как устроен протокол OneWire я не собираюсь, т.к. в интернете куча информации на эту тему.

Итак, что нам понадобится для изготовления данного устройства:

1) Atmega8
2) FTDI RL232, преобразующий USB в USART
3) Драйвер для FTDI RL232
4) Программатор(Я использовал USBasp)
5) Visual Studio
6) Atmel Studio
7) Макетная плата

Оказывается, кодовые замки можно делать не только из железа, но и из дерева. Вряд ли его можно использовать на практике, но простая конструкция выглядит довольно изящно. Неплохой проект, чтобы помастерить на выходных. К тому же модель хорошо показывает, как на самом деле работают кодовые замки (ведь ими интересовался даже сам Ричард Фейнман).

Кстати, никто не мешает изготовить всё из железных деталей по тому же принципу — получится настоящий кодовый замок, который можно использовать в деле!

В компании заказчика появилась необходимость в неком хранилище логов с возможностью горизонтального масштабирования. Исходя из начала задачи первая мысль — Splunk. К сожалению, стоимость данного решения уходила далеко за пределы бюджета заказчика.

В итоге выбор пал на связку Logstash + Elasticsearch + Kibana.

В этом howto мы с вами просто и быстро, шаг за шагом, запустим гипервизор Qemu-KVM в debian 8.



Будем запускать виртуальную машину в qemu-kvm от пользователя username, используя spice, qxl и virtio.
Предполагается, что установлен Debian 8 amd64, с выбранными в tasksel стандартными утилитами и SSH сервером. Доустановим.

aptitude install -y firmware-linux bridge-utils etckeeper

Зачастую возникает необходимость отслеживать различные параметры работы приложения/сервиса. Например, интерес представляет количество запросов в секунду, среднее время ответа сервера, количество ответов сервера с различным HTTP-статусом (технические метрики), количество регистраций пользователей в час, количество платежных транзакций в минуту (бизнес-метрики) и пр. Без системы сбора метрик разработка и сопровождение продукта происходит практически вслепую.



Данная статья является руководством по настройке системы сбора и анализа метрик приложения на базе Graphite и vimeo/graph-explorer.

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

DISCLAIMER

Не пытайтесь повторить это со своими телефонами и телефонами коллег! Судя по комментариям, много людей уже заразили свои телефоны, а 100%-тного лекарства еще нет!

DISCLAIMER 2

Даже не пытайтесь назвать так Wi-fi точку!

Около 15 часов назад на Reddit появился забавный пост, который рассказывал о перезагрузке айфона после странного сообщения вида:

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

В принципе, маркировка кабелей с использованием термоусаживаемых материалов — идея далеко не новая, но сейчас она получает широкое распространение. Некоторые компании выпускают удобные ручные инструменты для маркировки с использованием такого рода материалов. При этом надписи на этикетках-маркерах получаются очень четкими и стойкими. Вопрос маркировки кабелей действительно важен, для унификации этого процесса вводятся специальные стандарты, одним из которых (добровольный стандарт, созданный институтом ANSI) является ANSI / TIA 606-B.

Ситуация

В сети на сегодняшний день достаточно много описаний по развертыванию IP телефонии и в основном это два варианта:

• Берём готовый дистрибутив в виде установочного образа (Elastix,Trixbox etc...) и в результате получаем рабочий комплекс не имея никаких знаний в Linux
• Устанавливаем комплекс самостоятельно занимаясь при этом компиляцией из исходных кодов и ручной правкой множества конфигурационных файлов.

У каждого варианта имеются как достоинства, так и недостатки. Если первый способ подразумевает практически нулевую подготовку и дает возможность получить результат ничего не поняв, как это работает, то второй напротив требует обширных знаний в linux и очень сложен для начинающих хоть и обеспечивает высокую гибкость и масштабирование.

Предпосылки

В процессе внедрения IP телефонии в одной из компаний с разветвленной структурой филиалов рассматривались оба варианта но оба не устраивало по ряду причин:

• Бюджет на проект не подразумевал затрат на привлечение сторонних компаний для развертывания проекта, весь комплекс телефонии было решено развертывать своими силами.
• Большинство системных администраторов в филиалах были не знакомы с Linux системами и являлись чистыми Winows админами.
• Требовалось заложить высокую гибкость системы под будущие, еще не придуманные задачи.

Перед нами встала дилемма, с одной стороны проще настроить сервера и разослать их в регионы, а с другой весь груз сопровождения такого «черного ящика» ложится на наши плечи, а нас мало. В общем нас самих такая ситуация не устраивала. Вариант заказа внедрения сторонней компании был сразу отметен руководством по финансовым причинам.
Вариант с готовым дистрибутивом тоже отпал, поскольку проект подразумевал необходимость расширения функционала телефонии под нужды компании с учетом особенностей филиалов и это расширение необходимо было выполнять силами местных сотрудников. То есть без обучения nix системам никак.

С наших Download-серверов каждый день скачивается несколько миллионов драйверов (статичных .exe и .zip файлов). Для анализа поведения пользователей перед нами встала задача посчитать следующие параметры: когда, сколько, как часто и даже кто именно скачивает драйверы.

Самым очевидным решением было бы использовать инструменты типа AWstat, GoAccess, ELK stack или Splunk, а в крайнем случае собирать логи Nginx.

Но у каждого варианта есть свои минусы: неудобный интерфейс, скудность данных, сложность настройки и, самое главное, отсутствие возможности строить сегменты в пользовательских отчётах.

И тогда мы решили заставить Nginx самостоятельно отправлять события в Google Analytics сразу же после скачивания файла. Мы также смогли передать в GA уникальный идентификатор пользователя ClientID.
В результате мы получили аналитику по статичным файлам, к которым раньше невозможно было привязать счетчик GA.

Под катом готовый конфиг и примеры работы нашей системы.