Как показывает практика — бoльшая часть клиентов никак не мониторит используемые ресурсы, арендуемых ими услуг (особенно это заметно на дешевых услугах VPS от 3$).То есть, после установки системы и настройки необходимого для проекта софта, дальнейшая судьба сервера отдается на откуп случаю. И, когда появляются проблемы с работоспособностью сервера, информации для анализа не слишком много.

Кроме установленного и настроенного логирования в atop (который так же встречается не часто), логов системы, хотелось бы иметь больше информации с которой можно работать.

В данной статье будет описана процедура установки и настройки collectd и collectd-web на примере ОС семейства Debian.

Как-то я посчитал, что 1 минута простоя hh.ru в будни днем затрагивает около 30 000 пользователей. Мы постоянно решаем задачу снижения количества инцидентов и их длительности. Снизить количество проблем мы можем правильной инфраструктурой, архитектурой приложения — это отдельная тема, ее мы пока не будем брать во внимание. Поговорим лучше о том, как быстро понять, что происходит в нашей инфраструктуре. Тут как раз нам и помогает мониторинг.

В этой статье на примере hh.ru я расскажу и покажу, как покрыть мониторингом все слои инфраструктуры:

• client-side метрики
• метрики с фронтендов (логи nginx)
• сеть (что можно добыть из TCP)
• приложение (логи)
• метрики базы данных (postgresql в нашем случае)
• операционная система (cpu usage тоже может пригодиться)

Добрый день. Недавно меня заинтересовал модуль ngx_http_gzip_static_module, и я решил погонять мой домашний сервер немного с разными настройками сжатия nginx, чтобы убедится, действительно ли современные процессоры настолько быстрые, что можно ставить сжатие в 9-тку и не париться. В качестве подопытного файла выступала слитая главная страница lenta.ru – 170кб. Во время тестирования обнаружилась интересная особенность, которая изменила мои взгляды на выбор количества процессов nginx.

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

Let's Encrypt — это некоммерческая инициатива, предоставляющая бесплатный, автоматизированный и открытый CA (certificate authority — центр сертификации), созданный ISRG на благо общества:

• бесплатно: владелец всякого доменного имени может воспользоваться Let's Encrypt и получить доверенный (читать как «признаётся любым современным браузером») TLS-сертификат (TLS — наследник SSL) совершенно бесплатно;
• автоматизированно: Let's Encrypt предоставляет бесплатное и свободное программное обеспечение (клиент), которое, будучи настроенным на веб-сервере, может полностью автоматически запрашивать безвозмездно предоставляемые сертификаты Let’s Encrypt, автоматически конфигурировать и обновлять их;
• безопасно: Let’s Encrypt строится как платформа для продвижения наилучших практик безопасности TLS как на стороне центра сертификации (CA), так и на стороне веб-сайтов, помогая администраторам должным образом настраивать веб-серверы;
• прозрачно: информация о выпуске и отзыве каждого сертификата Let's Encrypt доступна вполне и публично так, что любой желающий изучить её сможет это сделать;
• свободно: протоколы взаимодействия со CA, позволяющие автоматизировать процессы выпуска и обновления сертификатов, будут опубликованы как открытый стандарт для максимального внедрения;
• кооперативно: как и любой протокол, лежащий в основе Интернета и Всемирной паутины, Let’s Encrypt является совместным, неподконтрольным какой-либо конкретной организации некоммерческим проектом созданным исключительно для того, чтобы принести пользу обществу.

В нашем блоге мы уже рассказывали о способах работы с типографикой в дизайне email-рассылок, а сегодня представляем вашему вниманию адаптированный перевод материала издания Bloomberg о том, почему использования популярных шрифтов Helvetica и Arial в письмах — может быть не лучшим решением.

Шрифтовые дизайнеры избегают выбирать Helvetica и Arial. Вам тоже следует их опасаться.

Helvetica, наиболее очевидный выбор для многих брендов и «нердов от типографики», по умолчанию используется в приложении Apple Mail. Gmail по умолчанию использует Arial, шрифт, который один дизайнер назвал «неказистым внебрачным сыном Гельветики». Если браузер не поддерживает Arial, Gmail использует вместо него Гельветику.

Хотя Helvetica – любимый вариант для многих «помешанных на дизайне», поскольку он относительно нейтрален, недостаточное расстояние между элементами шрифта и их сильная схожесть затрудняют чтение объемных текстов. «Буквы начинают слипаться, – говорит Надин Шахин (Nadine Chahine), шрифтовый дизайнер из Monotype. – Это делает текст слишком скученным».

Сумеречными зимними вечерами под песнь вьюги, укутавшись в овечий плед с бокальчиком «яблочной самогонки», я люблю почитывать логи на сервере. Авторизация по ключам упрощает сие, так что если в публичное помещение меня и не пустят, то сервер всегда рад приютить, старый чертяга.

В мире много чего происходит, у кого счастливое 200, кто-то недоуменно смотрит на 301, кто-то царапает похабщину на 403.

Но самый ценных мех — это исследователи. Это те, кто открывает новый для себя мир на основе своих знаний путем проб и 404.

Хочу поделиться с вами опытом написания компонента выбора даты для текстового поля.

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

Основная проблема в том, что выполнить оценку производительности сервера нужно быстро, без использования специальных (читай, сложных) инструментов и, разумеется, до релиза. Мы должны уметь снять с сервера некие метрики и, умножив их на известные показатели приложения, получить оценку производительности приложения на этом сервере.

В жизни выполнить эту задачу может далеко не каждый разработчик, а из оставшихся далеко не каждый хочет её выполнять.

В этой статье я хочу рассказать о тех приёмах и инструментах, которые мы используем для оценки производительности сервера.

В сентябре этого года в Киеве прошла конференция, посвящённая большим данным — BigData Conference. По старой традиции, мы публикуем в нашем блоге некоторые материалы, представленные на конференции. И начинаем с доклада Александра Демидова.

Сейчас очень многие интернет-магазины осознали, что одной из главных задач для них является повышение собственной эффективности. Возьмем два магазина, каждый из которых привлек по 10 тыс. посетителей, но один сделал 100 продаж, а другой 200. Вроде бы, аудитория одинаковая, но второй магазин работает в два раза эффективнее.

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

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

Для работы над Яндекс.Музыкой нам всегда важно помнить о разных тонкостях, которые таит в себе звук. Что такое громкость, как она меняется и от чего зависит? Как работают звуковые фильтры? Какие бывают шумы? Как меняется звук? Как люди его воспринимают.



Мы довольно много узнали обо всём этом, работая над нашим проектом, и сегодня я попробую описать на пальцах некоторые основные понятия, которые требуется знать, если вы имеете дело с цифровой обработкой звука. В этой статье нет серьёзной математики вроде быстрых преобразований Фурье и прочего — эти формулы несложно найти в сети. Я опишу суть и смысл вещей, с которыми придётся столкнуться.

Поводом для этого поста можете считать то, что мы добавили в приложения Яндекс.Музыки возможность слушать треки в высоком качестве (320kbps). А можете не считать. Итак.

^{В ситуации полной и беспросветной задницы власть в AI сразу забирали военные, и это иногда спасало партию.}

Для нашего AI Шакала пришлось написать целых 4 разных AI, каждый из которых отвечал за свою задачу. А затем они собирались вместе и голосовали за то, что же делать пиратам на поле в этом ходу.

Вся эта сложная система понадобилась, потому что у нас не было единой оценочной функции. Грубо говоря, AI бывают двух типов: когда понятно, как численно оценивать вашу позицию, и когда это совершенно непонятно. Та же партия в Го в определённый момент превращается в поединок интуитивных догадок, то есть сваливается в неалгоритмизируемую по сложности и по неопределённости задачу.

Давным-давно мой преподаватель профессор Сербин рассказывал байку с сыроваром из Европы. К этому обаятельному толстяку приезжали автоматизаторы и спрашивали, как он делает такой вкусный сыр. Им нужны были эвристики для температуры, густоты и так далее. Сыровар опускал палец в мягкий сыр, медленно и кайфно чертил там дугу, улыбался во всё хитрое лицо и говорил: «Ну как вы не чувствуете!».

Алгоритмизировать процесс гости так и не смогли. Так вот, разработка шла так: мы чертили дуги и хитро улыбались, а парни проигрывали нам в настольный Шакал. И мечтали, что за них отомстит AI.

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

Прим. перев.: для более полной картины здесь вас также будет ждать перевод Hashing Passwords with the PHP 5.5 Password Hashing API, на которую автор ссылается в статье.

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

ХолодныйСинтез:
«Доброго времени суток форумчане. Действительно, не знал, где создать тему, но для таких как я сделали целый раздел, за это и спасибо.
Вкратце, живу в далекой глуши, где отбирают бизнес и не дают ничем спокойно заняться… и вот пришла ко мне идейка сделать сервер для услуг хостинга ну или чего-то прочего.

Интересуют такие вопросы:
*Что надо для старта, какое оборудование, программы и т.д
*Что нужно купить для начала
*В какой бюджет можно влезть
Может найдутся «знавцы» это темы. чтоб мне поведать что и как? …»

И конечно же в лучших традициях «серча» начался срач:

pavellift:
«ХолодныйСинтез, может лучше переехать?»

voltamper:
«ТС, не стоит суваться, если вообще в этом не понимаете.
Брутанут и вообще без штанов останетесь».

sladkydze:
«Автор, я поддерживаю товарищей, которые не советуют соваться.

Что-то тут можно поймать:
1. Имея знания в области и опыт.
2. Имея как минимум от 10.000$ на первоначальные вложения. А лучше от 50.000$. Остальное — бултыхание в луже».

[umka]:
«Это как начать автопрокатную компанию, имея в качестве «первоначального оборудования» ушатанный ВАЗ 2106. Ну и плюс сайт, конечно же».

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

Сразу вспомнилось, как начинал я, и стало просто невыносимо грустно от таких советов, ведь люди заблуждались, все возможно и без бюджета, и без начальных знаний. Потому что именно так возник «ua-hosting». И далее я поведаю небольшую историю успеха и разочарований…

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях awk и grep. Оба подхода сильно различаются по своей производительности:



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Разработка Parallels Access потребовала создания геораспределенного сервиса, позволяющего безопасно устанавливать связь между компьютерами и мобильными клиентами пользователей в различных точках земного шара. Команда, которая над ним трудится, хочет поделиться полученным опытом в форме цитат, чтобы облегчить участь тем, кто только планирует создание своего клиент/серверного продукта, и погрузить в ностальгию профессионалов, имеющих за спиной дюжину успешных проектов:

Привет, Хабр! Цыплят, как известно, по осени считают. Осень в самом разгаре, давайте смотреть, чему мы научили поиск Google за это лето.



Развитие поиска происходит в двух направлениях. Одно из них вы не видите — это внутренние изменения, тайна за семью печатями, святая святых и всё такое. Именно там творится магия, распознаются слова, обрабатываются голосовые запросы, ищутся и находятся картинки, видео и музыка.

Второе же направление — пользовательские интерфейсы и инструменты взаимодействия с поисковым сервисом Google вы можете наблюдать лично. Об этих улучшениях сегодня и поговорим, вдруг кто что пропустил?

Почему видеохостинг такой дорогой

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

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

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

Чтобы решить эту проблему, нам пришлось сделать софт умнее.

Новый тренд на HighLoad++ — множество докладов об использовании оперативной памяти. Слово Константину Осипову, разработчику платформы Tarantool, автору доклада «Что особенного в СУБД для данных в оперативной памяти».

Ты отвечал в MySQL за производительность, как так получилось, что ты решил разрабатывать свою СУБД?

В MySQL я руководил одной из команд разработки сервера, за производительность там отвечали все.

MySQL по многим параметрам был работой мечты, но, к сожалению после того, как мы стали частью Oracle, многое изменилось.

Несколько моих коллег ушли в MariaDB, кто-то основал свою компанию (SeveralNines, FromDual). Я никогда не чувствовал себя «недогруженным», а с уходом многих ключевых разработчиков работа вообще превратилась в марафон по передаче знаний. Сопротивление поглощению, желание начать всё с чистого листа, бунт против медленного принятия решений большой компанией, нежелание по разным причинам уезжать в США, в конце концов, хорошее предложение от Mail.Ru, которому к этому моменту уже было около года — и я ушёл.

Если бы знал, куда ухожу, ещё десять раз подумал бы. Иногда вообще не было веры, что удастся сделать что-то полезное, чем будут пользоваться за пределами Mail.Ru, да и сейчас Tarantool очень далёк пока от «идеальной СУБД».