2015-02-22

О музыке

Все знают, что у нас в музыке сем нот: доремифасольляси. Многие знают, что ля первой октавы — это 440 герц (это частота классического камертона). Некоторые знают, что частота нот с интервалом в октаву различается в два раза. Что все это значит? Что такое музыка с точки зрения физики и математики?
MLP Music
Звук — это колебания давления. Они порождаются колебанием струны или язычка музыкального инструмента, или мембраны динамика акустической системы. Распространяются колебания через воздух. И вызывают ответные колебания барабанной перепонки в нашем ухе, которые через всякие молоточки, наковальни, стремечки и улитки таки воспринимаются нашим мозгом.
Кстати, даже в фортепиано, где музыкант нажимает на клавиши, источником звука являются струны, по которым ударяют молоточки. А в саксофоне, который весь такой металлический и духовой, звучит деревянный язычок.
Гармонические колебания — это синусоида. Колебания имеют частоту, которую измеряют в герцах. В музыке частоту звуковых колебаний называют высотой звука.


Чистую синусоиду мы можете получить с помощью специальных приборов или же в какой-нибудь программе для обработки звука, например, Audacity. Звучит она не очень. У настоящих инструментов к основному тону добавляются всякие колебания кратных частот, влияют всякие резонаторы и т.д. и т.п. Так и рождается уникальный тембр данного инструмента. Однако на частотной диаграмме пик все же должен указывать на ту ноту, которая играет в данный момент. Теоретически.
Синусоида показывает изменение интенсивности звукового давления во времени. И именно это изменение записывается на пластинку или магнитную ленту. Значениям амплитуды назначаются цифровые значения, и это записывается на компакт диск или в файл. При обработке звука мы будем видеть на горизонтальной шкале время, а по-вертикали — интенсивность сигнала, в числах или даже в децибелах.
Но если мы проведем над этими значениями преобразование Фурье, то получим частотное представление сигнала. Грубо говоря, чистые синусоиды какой частоты и интенсивности нам надо сложить, чтобы получить исходный сигнал. На частотной диаграмме по-горизонтали у нас будет частота, а по-вертикали — «интенсивность» данной частоты в сигнале.


Частота — это высота. А по высоте у нас — ноты.
На самом деле, в современном музыкальном строе нот не семь, а двенадцать. Посмотрите на клавиатуру фортепиано. Есть белые клавиши. А есть и черные. Белые — это и есть те самые семь нот с названиями, которые часто еще обозначают латинскими буквами. До — C, ре — D, ми — E, фа — F, соль — G, ля — A, си — B (или H). Как видите, буквенная нумерация начинается с ля, так сложилось исторически.
А вот у черных клавиш своих имен нет. Но они отличаются на полутон от соседних белых клавиш. Для перехода на полутон вверх используется специальный знак: диез — # (не шарп, а диез). Для перехода на полутон вниз используется другой знак: бемоль — . Таким образом первая черная клавиша в октаве — это до-диез, потому что на полтона выше ноты до, или ре-бемоль, потому что на полтона ниже ноты ре.


Частоты нот, различающихся на одну октаву, например, от до до до, различаются в два раза. А между до одной октавы и до другой октавы имеется ровно двенадцать полутонов. Сосчитайте черные и белые клавиши на клавиатуре. Шкала логарифмическая. То, что отличается по высоте на сколько-то полутонов, отличается по частоте во столько-то раз. А значит, разница в один полутон, это разница в частоте звука в раз. Это называется равномерно темперированный строй. Бывали и другие, но это было давно и неправда.
Ну а теперь нажмите последовательно на фортепианной клавиатуре белые клавиши: доремифасольляси и до следующей октавы. Для этого не обязательно бежать к ближайшему клавишнику, достаточно поставить на телефон приложение вроде xPiano. Нажали? Поздравляю, вы только что сыграли гамму до-мажор. Звучит неплохо, правда?
До-мажор (он же C-dur или C major) — это тональность или лад. Вы начали с до и закончили доДо, в данном случае, — первая ступень нашего лада, тоника. Это самый устойчивый звук в тональности. Если вы будете играть что попало, но только белыми клавишами, и закончите до, то звучать это будет более-менее прилично для человеческого слуха. И звучать это будет весело — мажорно.
Другими устойчивыми ступенями в тональности являются третья — ми, и пятая — соль. Попробуйте сыграть домисоль, и до следующей октавы. Звучит? А теперь одновременно домисоль. Тоже звучит? Поздравляю, вы только что сыграли мажорное трезвучие — основной аккорд мажорного лада. Играйте что попало, только белыми клавишами, почаще задерживайтесь на доми, и соль, и всем будет счастье.


В тональности семь ступеней. И мажорной тональностью будет любая, где между ступенями будут такие интервалы. Между первой и второй (до и ре) — два полутона, один тон, интервал под названием секунда. Между второй и третьей (ре и ми) — снова секунда. Между третьей и четвертой (ми и фа) — полутон, малая секунда, на клавиатуре там нет черной клавиши. Ну и так далее. Если между белыми клавишами есть черная — между ними тон. Если между белыми клавишами нет черной — между ними полутон.
Вы можете сыграть мажор не обязательно начиная с до. Главное соблюсти указанные интервалы в гамме и трезвучии. Тут вам понадобятся черные клавиши.
Так уж устроен наш слух, что гармоничными, созвучными мы воспринимаем звуки с определенным соотношением частот. Это 1:2 в случае октавы — от до до следующего до. Это 1: в большой терции от до до ми, и 1: в малой терции от ми до соль в трезвучии.
Мажорное трезвучие
Смотрите, в равномерно темперированном строе, который является основным в музыке с XVIII века, отношения частот какие-то не очень красивые. И в самом деле, в натуральном строе соотношения гораздо более красивые: 4:5 для большой терции и 5:6 для малой. Проблема с натуральным строем в том, что согласно нему можно настроить музыкальный инструмент только под одну единственную тональность. Попытки сыграть другие тональности, вроде того же мажора, но не до, что я советовал раньше, будут звучать фальшиво. Равномерно темперированный строй — это попытка равномерно размазать все нужные интервалы по большущей клавиатуре фортепиано и при этом сохранить соотношение частот, близкое к идеальному (по мнению натурального строя), но иметь возможность играть в любой тональности в любой части клавиатуры. Искажения идеала в угоду универсальности.
Натуральный строй
Ну а теперь сыграйте гамму, тоже белыми клавишами, но не от до, а от лялясидоремифасольля. Звучит? Но как-то грустнее. А теперь трезвучие. Последовательно: лядомиля. Аккордом: лядоми. Поздравляю, вы познакомились с ля минором.


Это другая, уже минорная тональность. Заметьте, те же семь ступеней, но изменилось соотношение частот между ними. И изменились расстояния между ступенями в трезвучии.
Это — натуральный минор. Есть еще гармонический и мелодический миноры, с немного другим соотношением высот ступеней. Плюс мажор, который чаще всего натуральный, и очень редко бывает гармоническим или мелодическим. Вот и все разновидности тональностей, т.е. соотношений частот звуков, извлекаемых музыкальным инструментом, приятных для нашего слуха. Берем за основу, за первую ступень тональности, какую-то ноту, а с равномерно темперированным строем это может быть абсолютно любая нота, и вперед. Семь ступеней, три из них устойчивые. Здравствуй, мелодия.

2015-02-08

О мониторинге

Уговорили доложить о чем-нибудь девопсовом. Докладываю о мониторинге.
Sentry
Под мониторингом в ИТ понимают несколько довольно разных вещей. В зависимости от того, что является целью и задачей мониторинга.
Во-первых, мы хотим мониторить метрики. Те самые цифры, которые показывают трафик на сетевых интерфейсах, загрузку ЦПУ в процентах или load average в попугаях.
Некоторые цифры сами по себе имеют смысл (загрузка ЦПУ). Для других интересно их изменение во времени (счетчики пакетов/байтов на сетевых интерфесах). Во втором случае нам нужна по сути производная (в математическом смысле) наблюдаемой величины.
Цифры эти мы собираем с завидной периодичностью. Раз в пять минут, раз в минуту, иногда даже хочется раз в секунду. А значит, метрики у нас образуют временные ряды, они же time series data. Если дать волю математикам, они могут сделать с временными рядами много интересного. Предсказать будущие значения, обнаружить аномальные отклонения, и прочее. Но простым бородатым сисадминам это обычно не интересно.
В старые времена было модно получать эти самые цифры через SNMP. Еще один протокол со словом "simple" в названии. Протокол, позволяющий управлять различными устройствами по сети, а также снимать показания всяких счетчиков, т.е. метрики. Любой приличный свич или роутер и в наши дни вполне себе умеет SNMP. SNMP — это не только сетевой протокол, но и общирные стандарты, описывающие параметры устройств, которыми можно управлять и которые можно считывать. Как общие параметры, например, всех свичей, так и специализированные параметры конкретного производителя или даже конкретного устройства.
Ну а сейчас модно использовать протокол, специфичный для наблюдаемой системы. Для БД, например, сбор метрик осуществляется какими-нибудь запросами к специальным таблицам или выполнением специальных команд через обычное клиентское подключение. А протокол передачи метрик определяется системой сбора метрик. Встречаются универсальные агенты, вроде Diamond, которые умеют собирать метрики кучей разных способов и отправлять их куче разных серверов мониторинга.
Метрики нужно не только собирать, но и хранить. Для этого часто используется принцип под названием RRD — Round Robin Database. А также конкретную реализацию этого принципа: RRDtool. Фокус номер один: нам нужны только свежие данные. Никому не интересны метрики пятигодичной давности. Поэтому, при вставке новых, мы просто выкидываем старые данные. Фокус номер два: нам не нужны детальные данные. Допустим, мы собираем метрики каждые пять минут. Такая детализация нам нужна только на пару дней. Для более старых данных нам достаточно, скажем, получасовой точности. Все равно в графиках за неделю пятиминутные отчеты не разглядишь. А для данных старше месяца возмем двухчасовую точность, спишем их в архив. Применив оба фокуса мы сможем отвести под хранения одной метрики в течение пяти лет буквально килобайты. Причем размер этот фиксирован и определяется на этапе создания RRD. Компактно и эффективно.
RRDtool используется под капотом кучи разных систем мониторинга: CactiGangliaMunin... тысячи их.
Некоторые обходятся и без RRDtool. Zabbix хранит метрики в реляционной БД. OpenTSDB — это вообще специальная база данных для хранения time series data, построенная поверх HBase, который построен поверх Hadoop, который... OpenTSDB никогда не удаляет и не «сворачивает» старые данные, совсем не RRD, все отчеты хранятся в том виде, как были сохранены. Graphitовый Whisper похож на RRD, но не RRDtool, по некоторым тонкостям использования он удобнее.
Собрать метрики мало. Их обычно еще визуализируют в красивые графики. RRDtool сам умеет генерировать готовые png файлы. OpenTSDB и Graphite тоже умеют, но как правило к ним есть еще разнообразные вебмордочки, чтобы удобно и красиво собрать разные графики на одном экране. Graphite тут немного уникален, потому что позволяет производить разнообразные математические операции над данными: находить производные, складывать, вычитать, умножать метрики, по-разному сводить несколько графиков на одной картинке.
Получается, что цепочка обработки метрик довольно длинна. Нужно собрать их на месте, передать по сети, сохранить в БД, преобразовать, нарисовать графики, показать графики пользователю. Инструментов на каждом этапе довольно много. Не все инструменты покрывают всю цепочку. Стандартов взаимодействия (ну, кроме, пожалуй, SNMP) шагов цепочки нет. Не все так радужно.
Metrics processing
Во-вторых, кроме метрик мы хотим получать уведомления и алерты, когда на наших серверах, в нашем кластере или датацентре что-то пошло не так.
Базовым показателем здесь является факт сетевой доступности узла сети. Мы делаем ping: посылаем несколько ICMP Echo-Request и ждем ICMP Echo-Reply от узла. Если все пинги вернулись — все хорошо. Если часть пингов вернулось — все хорошо, хотя может быть и не так хорошо, как надо. Если ни один пинг не вернулся — все плохо. Если было хорошо, а стало плохо, надо послать СМС админу. Если было плохо, а стало хорошо, надо снова послать СМС админу. Так всякие Nagios и работают. Впрочем, Nagios умер и теперь надо использовать Icinga.
Наличие или отсутствие пинга, это вроде как и не метрика, тут нет числового значения. Или булева метрика, где есть два значения: пинг есть или пинга нет. Или метрика в процентах: количество вернувшихся ICMP Echo-Reply пакетов. Или метрика в миллисекундах: среднее время отклика, между посылкой Echo-Request и получением Echo-Reply. И то, и другое, и третье может представлять интерес, в зависимости от характера наблюдаемых явлений. Действие одно, а метрик несколько.
По-хорошему, мы должны делать какие-то проверочные действия над системой: посылать пинги, запрашивать статус БД и счетчики интерфейсов, — снимать множество метрик по каждому действию, сохранять их во временные ряды, анализировать ряды на предмет поиска аномалий и выхода значений за указанные пределы (было бы суперкруто, если эти пределы определялись автоматически), посылать уведомления, если имеются аномалии.
Т.е. вполне можно объединить сбор метрик, проверку работоспособности системы и отсылку уведомлений. Только почему-то почти никто так не делает. Nagios/Icinga пользуется своими средствами сбора показателей и проверки выхода значений за границы, и шлет уведомления, но не хранит сами значения и их историю. Graphite хранит метрики и историю, но не анализирует значения показателей. Zabbix, конечно, объединяет и то и другое, но он вещь в себе и не взаимодействует с другими системами.
Metrics and alerts
В-третьих, мы хотим видеть ексепшены и сведения о падении нашего приложения. Это те самые просьбы отослать крэшдампы и стектрейсы разработчику, которые вы видите в Windows, Ubuntu, Android и любой приличной системе, взаимодействующей с пользователем. Для мобильных приложений это особенно актуально, потому что аппаратных конфигураций тут просто чудовищное количество.
Ну а для своего серверного приложения можно поднять Sentry. Это не супергерой, а сервер для сбора данных об ексепшенах под свободной лицензией. В более сложных облачных случаях можно попробовать платный New Relic.
В-четвертых, мы хотим видеть не только ошибки приложения, но и статистику его использования. Нам нужно мониторить события. Для серверных приложений событием может быть запись в логе. Т.е. нам нужно мониторить логи. Для клиентских приложений событием может быть любое действие пользователя: нажатие на кнопку и т.п.
Тут мы переходим грань между чисто техническими нуждами мониторинга и рыночным анализом. Например, мы можем половине пользователей показать зеленую кнопку, а другой половине — красную кнопку. Затем, подсчитав количество нажатий на зеленую и на красную, мы можем определить какой цвет больше нравится нашей аудитории. Это называется A/B тестом.
Ну а из анализа логов запросов к веб серверу естественным образом вытекает статистика посещаемости веб страниц этого сервера. Что уже может быть интересно и сисадминам.
Сбором логов занимается, например, Logstash. Визуализацией — Kibana. Оба этих продукта имеют тесное отношение к Elasticsearch, потому что логи, это вам не просто числа.
Аналитикой занимаются, например, Google Analytics или Flurry Analytics. Первый больше заточен под веб, второй — под мобильные приложения. И то и другое — платные облачные продукты.
В случае мониторинга крэшей или событий нам приходится наблюдать систему изнутри. Нужны явные действия программиста, чтобы отправить стектрейс в Sentry, чтобы сделать запись в лог, чтобы нажатие на кнопку отразилось в Google Analytics. Либо же нам нужно вмешательство в выполняемый код, аналогичное отладке или профилировке, чтобы отследить ветки выполнения кода и найти проблемные места, это может New Relic.
Крэши и события — это не просто числовые метрики. С каждым событием связана целая кучка сопутствующих данных: цвет нажатой кнопки, User-Agentкуки, сам стектрейс... Конечно, количество событий в единицу времени вполне является метрикой, проблема в том, как их группировать. Допустим, событием является прохождение IP пакета через сетевой интерфейс. Мы можем сгруппировать по IP адресу отправителя или получателя, и получить метрики трафика пользователя или конкретного сайта. Или группировать по протоколу (TCP или UDP) и номеру порта, тогда получим трафик различный приложений, например, браузера. Получается, что из одного набора событий можно извлечь множество различных метрик в зависимости от интерпретации сопутствующих событию данных. Именно поэтому для анализа логов используется Elasticsearch — инструмент для полнотекстового поиска.
Events monitoring
А универсальных инструментов для мониторинга метрик, анализа состояния системы и отсылки уведомления, сбора и анализа ошибок, логов и событий — нет. И, к сожалению, нет и приемлемого способа собрать это дело из существующих решений. Ибо нет стандартов по их взаимодействию. Есть, где развернуться девопсам/программистам.