С момента публикации статьи о внедрении Intel SGX в наше публичное облако прошло несколько месяцев. За это время решение было существенно доработано. В основном улучшения касаются устранения мелких багов и доработок для нашего же удобства.



Есть, однако, один момент, о котором хотелось бы рассказать подробнее.

Сегодня из подручных материалов мы соберём в Яндекс.Облаке Telegram-бот с использованием Yandex Cloud Functions (или Яндекс-функции — для краткости) и Yandex Object Storage (или Объектное хранилище — для ясности). Код будет на Node.js. Однако, имеется одно пикантное обстоятельство — некая организация под названием, скажем так, РоссКомЦензур (цензура запрещена статьёй 29 Конституции РФ), не позволяет интернет-провайдерам России передавать запросы в Telegram API по адресу: https://api.telegram.org/ (UPD: В РФ уже снята блокировка Telegram API). Ну мы и не будем — нет так нет. Ведь в нашем саквояже имеются т.н. вебхуки — с их помощью мы не делаем запросы на конкретный адрес, а всего лишь шлём свой запрос в качестве ответа на любой запрос к нам. То есть, как в Одессе — отвечаем вопросом на вопрос. Поэтому Telegram API в нашем коде фигурировать не будет.

Привет, Хабр!

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

Я вполне могу обходиться без мессенджеров, однако именно Telegram мне нужен был для работы. Установить клиент на рабочую машину не представлялось возможным, использовать личный ноутбук — тоже. Еще одним решением видится использовать его официальную веб-версию, но как вы можете догадаться — она так же была недоступна. Вариант с поиском неофициального зеркала я сразу вычеркиваю (надеюсь по вполне очевидным причинам).

К счастью, Webogram — это opensource-проект, исходный код которого доступен в github его автора (За что огромное ему спасибо!)
Сама установка и запуск не представляет из себя ничего сложного, однако, в условиях эксплуатации внутри сети с заблокированным доступом к серверам Telegram вас скорее ждет разочарование, чем успех, так как веб-версия отправляет запросы на серверы Telegram с машины пользователя.

К счастью, это довольно просто (но не очень очевидно) исправить. Хочу предупредить, что я не являются автором данного решения. Мне удалось найти его в ветке, в которой обсуждалась проблема похожая на мою. Решение, которое предложил пользователь github tecknojock, мне очень помогло, однако, уверен, что оно может помочь еще кому нибудь, поэтому решился на написание данного туториала.

Под катом вас ждет пошаговая настройка своего зеркала Webogram и настройка проксирования его запросов до серверов Telegram с использованием nginx.

Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"

В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.

Команда конференции Mieloconf подготовила подборку классных фильмов о науке и ученых для долгих новогодних каникул.

Про свои любимые фильмы рассказали: AI-евангелист ABBYY, автор подкаста «Проветримся» Иван Ямщиков, физик-ядерщик Дмитрий Горчаков, руководитель инфраструктурной команды в «Контуре» Алексей Кирпичников и программист Павел Аргентов.

У нас было 4 Amazon-аккаунта, 9 VPC и 30 мощнейших девелоперских окружений, стейджей, регрессий — всего более 1000 EC2 instance всех цветов и оттенков. Раз уж начал коллекционировать облачные решения для бизнеса, то надо идти в своем увлечении до конца и продумать, как все это автоматизировать.

Привет! Меня зовут Кирилл Казарин, я работаю инженером в компании DINS. Мы занимаемся разработкой облачных коммуникационных решений для бизнеса. В своей работе мы активно используем Terraform, с помощью которого мы гибко управляем нашей инфраструктурой. Поделюсь опытом работы с этим решением.

Статья длинная, поэтому запаситесь попкорном чаем и вперед!

И еще один нюанс — статья писалась на основе версии 0.11, в свежей 0.12 многое изменилось но основные практики и советы по прежнему актуальны. Вопрос миграции с 0.11 на 0.12 заслуживает отдельной статьи!

Я совсем не долго изучаю и использую git практически везде, где только можно. Однако, за это время я успел многому научиться и хочу поделиться своим опытом с сообществом.

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

Предисловие

Часто возникает потребность в режиме реального времени сообщать администратору о проблемах, связанных с БД (базой данных).

В данной статье будет описано, что необходимо настроить в Zabbix для слежения за базой данных MS SQL Server.

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

Этот мануал был написан в связи производственной необходимостью мониторить трафик (http и https) пользователей, а также распределения доступа по белым и черным спискам. За основу были взяты статьи: эта и вот эта , в которых использовалась технология peek-n-splice. В данных статьях конфигурация предполагает использование хоста со squid как шлюз, после доработки конфига, получился полноценный прокси-сервер с возможностью распределения прав доступа по группам из Active Directory. По завершению конфигурирования встал вопрос передачи настроек прокси-сервера для пользователей. В виду того, что в офисе часто ноутбуки берут домой — вся затея зашла в тупик. Изначально рассматривался вариант выдачи настроек прокси-сервера через DHCP, но он не самый лучший, т. к. офисы в разных подсетях, и разное оборудование, выходом из данной ситуации стал WPAD. Вкратце о данной технологии можно сказать так, клиентские машины на OS Windows ищут хост с именем wpad.example.ru (вплоть до доменов третьего уровня), чтобы запросить файл настроек для работы в сети. Исходя из такого принципа, нужно поднять веб-сервер, который просто бы отдавал файл wpad.dat Можно на самом хосте с прокси-сервером поднять веб-сервер (что и было сделано), а в DNS-сервере создать cname wpad на прокси-сервер. Прокси-сервер лучше использовать с возможностью сбора и просмотра статистики, благо выбор предостаточный. В виду некоторых консервативных соображений, было решено выбрать SARG. Он легкий в настройке, достаточно приемлемая статистика для офиса со штатом до 100 сотрудников.

Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.

Сразу оговорюсь, что в упомянутой выше статье этих ошибок нет, скорее фраза сработала как триггер.

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

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

Сегодня будем смотреть как и почему может распухать Write-Ahead Log (WAL) постгреса. Как обычно — примеры из реальной жизни в картинках.

Масштабирование СУБД – это непрерывно наступающее будущее. СУБД совершенствуются и лучше масштабируются на аппаратных платформах, а сами аппаратные платформы наращивают производительность, число ядер, памяти — Ахиллес догоняет черепаху, но все еще не догнал. Проблема масштабирования СУБД стоит во весь рост.

Компании Postgres Professional с проблемой масштабирования довелось столкнуться не только теоретически, но и практически: у своих заказчиков. И не раз. Об одном из таких случаев и пойдёт речь в этой статье.

PostgreSQL неплохо масштабируется на NUMA-системах, если это одна материнская плата с несколькими процессорами и несколькими шинами данных. О некоторых оптимизациях можно почитать здесь и здесь. Однако есть и другой класс систем, у них несколько материнских плат, обмен данными между которыми осуществляется с помощью интерконнекта, при этом на них работает один экземпляр ОС и для пользователя такая конструкция выглядит как единая машина. И хотя формально такие системы можно также отнести к NUMA, но по своей сути они ближе к суперкомпьютерам, т.к. доступ к локальной памяти узла и доступ к памяти соседнего узла отличаются радикально. В сообществе PostgreSQL считают, что единственный экземпляр Postgres, работающий на таких архитектурах, это источник проблем, и системного подхода к их решению пока нет.

В PostgreSQL начиная с очень давних времён аж версии 8.0 вышедшей в далёком 2005 году для восстановления в определённую точку времени использовался специальный файл конфигурации recovery.conf. Этот же файл впоследствии стал использоваться для режима standby и потоковой репликации.

Однако начиная со следующего релиза PostgreSQL 12 больше recovery.conf работать не будет: я его сломал.
Но зачем?

Чуть более месяца назад в Москве состоялась крупнейшая конференция постгресового сообщества PGConf.Russia 2019, собравшая в МГУ свыше 700 человек. Мы решили выложить видео и расшифровку лучших докладов. Выступление Ивана Фролкова с разбором типичных ошибок при работе с PostgreSQL было отмечено лучшим на конференции, поэтому мы начнем с него.

Для удобства мы разбили расшифровку на две части. В этой статье речь пойдет о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. Во второй части будут разобраны обработка ошибок, конкурентный доступ, неотменяемые операции, CTE и JSON.



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

Главный вывод, который я смог сделать из того, что я видел, довольно неожиданный: фактически любое приложение при должной настойчивости можно заставить работать. Был замечательный проект (я не могу упоминать все компании, с которыми мы работали), в котором еще более замечательное приложение создавало таблицы миллионами. Выглядело это так: в понедельник система работает неплохо, а уже в пятницу она практически не работает. На выходные дни запускают VACUUM FULL, и в понедельник она опять работает хорошо. Оказывается, над PostgreSQL можно вот так издеваться, и всё это довольно долго будет жить и работать. Другой товарищ сделал странную вещь: у него всё было построено на триггерах, процедур не было вообще. То есть большую часть таблиц трогать нельзя, сделать что-либо не получалось, но и эта база жила.

Здравствуйте, хабровчане! Предлагаю вашему вниманию перевод статьи «How a single PostgreSQL config change improved slow query performance by 50x» автора Pavan Patibandla. Она очень сильно мне помогла улучшить производительность PostgreSQL.

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

Отслеживая задержку на разных уровнях, мы поняли, что одному конкретному запросу PostgreSQL потребовалось 20 секунд для завершения. Для нас это стало неожиданностью, так как обе таблицы имеют индексы в соединяемом столбце.

Медленный запрос

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

Введение

«Ой, ерунда, ячейки памяти на современных SSD выйдут из строя через десятки лет обычного использования, не стоит об этом беспокоиться, и уж тем более переносить swap, виртуальные машины и папку профиля браузера на HDD» — типичный ответ на вопрос о надежности твердотельных накопителей c гарантированными ≈150 TBW. Если прикинуть, сколько типичное ПО может писать данных, то кажется, что 10-20 ГБ в сутки — уже большая цифра, пусть будет максимум 40 ГБ, куда уж больше. При таких цифрах ответ вполне разумен — нужно 10 лет, чтобы достичь гарантированных значений по количеству перезаписи ячеек, при 40 ГБ записанных данных ежедневно.
Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками несколько раз в день, что оборачивалось 30-секундными задержками в обслуживании записи.

После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
19.7 ТБ.
Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!

Дисклеймер

Я — разработчик. Я пишу код, с базой данных взаимодействую лишь как пользователь. Я ни в коем случае не претендую на должность системного администратора и, тем более, dba. Но…

Так вышло, что мне нужно было организовать резервное копирование postgresql базы данных. Никаких облаков — держи SSH и сделай, чтобы все работало и не просило денег. Что мы делаем в таких случаях? Правильно, пихаем pgdump в cron, каждый день бэкапим все в архив и если совсем разошлись — отправляем этот архив куда-нибудь подальше.

В этот раз сложность состояла в том, что по планам база должна была расти примерно на +- 100 МБ в день. Разумеется, уже через пару недель желание бэкапить все pgdump'ом отпадет. Тут на помощь приходят инкрементальные бэкапы.

Интересно? Добро пожаловать под кат.

Предлагаю читателям "Хабрахабра" перевод статьи "Хорошая практика в сообщении коммитов от OpenStack".

1 Git Commit Лучшая практика

Следующий документ основан на опыте разработки кода, устранении ошибок и просмотре кода в ряде проектов, использующих Git, включая libvirt, QEMU и OpenStack Nova. Рассмотрение других проектов с открытым исходным кодом, таких как Kernel, CoreUtils, GNULIB а также других, предполагает, что все они следуют достаточно распространенной практике. Это мотивировано желанием улучшить качество истории Git проекта Nova. Качество — это абстрактный термин для определения в разработке; когда для одного человека некий код «Красивый» (Thing of Beauty) — то для другого это «Костыль» (Evil Hack). Тем не менее мы можем сформулировать некоторые общие рекомендации о том, как и что делать, или, наоборот, чего не делать, когда отправляют Git коммиты для слияния с проектами в OpenStack.

Эта тема может быть разделена на две области:

1. Порядок объединения или разбиения на несколько коммитов
2. Информация в сообщениях коммитов

Все мы слышали, что знания – сила, однако, не всегда очевидно, где именно получить те самые знания, которые сделают из вас квалифицированного системного администратора или архитектора, готового к развитию технологий, и повысят вашу ценность в глазах потенциальных работодателей.



Мы поговорили с Алексеем Усовым, сертифицированным специалистом RHCA Level XIII – о том, как выбрать программу обучения, зачем нужна сертификация, как проходят экзамены, как к ним подготовиться и что все это дает на выходе.