- CPU лимиты
- Docker и server class machine
- CPU лимиты (да, опять) и фрагментация памяти
- Обрабатываем Java-OOM
- Оптимизируем потребление памяти
- Ограничиваем потребление памяти: heap, non-heap, direct memory
- Ограничиваем потребление памяти: Native Memory Tracking
- Java и диски
- Как за всем уследить?
Пользователь
Ломаем и чиним Kubernetes
Kubernetes отличная платформа как для оркестрации контейнеров так и для всего остального. За последнее время Kubernetes ушёл далеко вперёд как по части функциональности так и по вопросам безопасности и отказоустойчивости. Архитектура Kubernetes позволяет с лёгкостью переживать сбои различного характера и всегда оставаться на плаву.
Сегодня мы будем ломать кластер, удалять сертификаты, вживую реджойнить ноды и всё это, по возможности, без даунтайма для уже запущенных сервисов.
Load Average в Linux: разгадка тайны
Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.
MikroTik Скрипт: Уведомление о успешном входе на устройство или простой парсер журнала MikroTik
Разбираем скриптом внутренний журнал событий MikroTik отбирая уведомления вход/выход пользователей на устройство. Отправляем события на почту или Telegram.
Написать свой скрипт меня сподвигло желание упростить монструозные скрипты, которые можно найти по этому запросу в интернете, выполняющие это несложное действие (например с Wiki MikroTik). Статья разбирает пример скрипта уведомления вход/выход пользователя, особенность журнала MikroTik и почему инженеры MikroTik живут в Лондоне.
На примере скрипта вы с легкостью можете перенастроить отправку сообщений на любое событие в журнале устройства MikroTik.
Массивы bash
Если вы используете «стандартную» оболочку *NIX-системы, возможно, вы не знакомы с такой полезной особенностью bash как массивы. Хотя массивы в bash не так круты, как в P-языках (Perl, Python и PHP) и других языках программирования, они часто бывают полезны.
Bash-массивы имеют только численные индексы, но они не обязательны к использованию, то есть вы не должны определять значения всех индексов в явном виде. Массив целиком может быть определен путем заключения записей в круглые скобки:
arr=(Hello World)
Отдельные записи могут быть определены с помощью знакомого всем синтаксиса (от Бейсика (да простит меня Дейкстра — прим. переводчика) до Фортрана):
arr[0]=Hello
arr[1]=World
Cкоростная синхронизация миллиарда файлов
К тому же, время от времени нужно удалять устаревшие файлы сразу на всех серверах, что пока делается вручную и занимает несколько суток. Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.
После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.
UPD: Как показала практика, необходимо ощутимое измение и дополние в тексте. Я решил внести лишь незначительные правки в основную часть, а новыми выводами поделиться в конце статьи.
Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон
Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.
Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.
Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".
IPSec всемогущий
Лучшие IT-комедии. Топ 3 сериала
Многие очень тепло приняли мою предыдущую статью про сериал «Mr.Robot». Огромное спасибо вам за это!
Как я и обещал, подготовил продолжение цикла и надеюсь, новая статья придётся вам также по душе.
Сегодня речь пойдёт о трёх, на мой взгляд, главных комедийных сериалах в сфере IT. Многие сейчас находятся на карантине, многие — работают. Эта подборка, надеюсь поможет вам в это трудное время. Кому-то отвлечься от проблем, кому-то расслабиться после работы, кому-то сохранить немного позитива.
Ansible это вам не bash. Сергей Печенко
Предлагаю ознакомиться с расшифровкой доклада 2019 года Сергея Печенко "Ansible — это вам не bash!"
Здоровье индексов в PostgreSQL глазами Java-разработчика
Привет.
Меня зовут Ваня, и я Java-разработчик. Так получилось, что я много работаю с PostgreSQL – занимаюсь настройкой БД, оптимизацией структуры, производительностью и немного играю в DBA по выходным.
За последнее время я привёл в порядок несколько баз данных в наших микросервисах и написал java-библиотеку pg-index-health, которая облегчает эту работу, экономит моё время и помогает избежать некоторых типовых ошибок, допускаемых разработчиками. Именно об этой библиотеке сегодня и пойдёт речь.
Disclaimer
Основная версия PostgreSQL, с которой я работаю, это 10-ка. Все используемые мною SQL-запросы также проверены на 11-й версии. Минимальная поддерживаемая версия — это 9.6.
Предыстория
Началось всё почти год назад со странной для меня ситуации: конкурентное создание индекса на ровном месте завершилось с ошибкой. Сам индекс, как водится, в невалидном состоянии остался в базе. Анализ логов показал нехватку temp_file_limit. И понеслось… Копнув поглубже, я обнаружил целый ворох проблем в конфигурации БД и, засучив рукава, с блеском в глазах принялся их чинить.
Основы мониторинга PostgreSQL. Алексей Лесовский
Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"
В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.
Создание отказоустойчивой ИТ инфраструктуры. Часть 2. Установка и настройка кластера oVirt 4.3
Эта статья является продолжением предыдущей – «Создание отказоустойчивой ИТ инфраструктуры. Часть 1 — подготовка к развёртыванию кластера oVirt 4.3».
В ней будет рассмотрен процесс базовой установки и настройки кластера oVirt 4.3, для хостинга высокодоступных виртуальных машин, с учётом того, что все предварительные шаги по подготовке инфраструктуры, уже выполнены ранее.
Визуальное руководство по диагностике неисправностей в Kubernetes
TL;DR: вот схема, которая поможет вам отладить deployment в Kubernetes:
Шпаргалка для сисадмина по SELinux: 42 ответа на важные вопросы
Здесь вы получите ответы на важные вопросы о жизни, вселенной и всем таком в Linux с улучшенной безопасностью.
«Важная истина, что вещи не всегда являются тем, чем кажутся, общеизвестна…»
―Дуглас Адамс, Автостопом по Галактике
Безопасность. Повышение надежности. Соответствие. Политика. Четыре Всадника Апокалипсиса сисадмина. В дополнение к нашим ежедневным задачам — мониторингу, резервному копированию, внедрению, настройке, обновлению и т. д. — мы также отвечаем за безопасность наших систем. Даже тех систем, где сторонний провайдер рекомендует нам отключить усиленную безопасность. Это похоже на работу Этана Ханта из “Миссия невыполнима”.
Greenplum DB
Немного о наших инсталляциях:
- проект живёт у нас чуть больше двух лет;
- 4 контура от 10 до 26 машин;
- размер БД около 30 Тб;
- в БД около 10000 таблиц;
- до 700 queries per second.
За тем, как оно работает, прошу под кат!
Файловые разрешения в Linux
Файловые разрешения предлагают безопасную альтернативу исполняемым файлам SUID, но могут показаться немного запутанными на первый взгляд.
Создание отказоустойчивой ИТ инфраструктуры. Часть 1. Подготовка к развёртыванию кластера oVirt 4.3
Вниманию читателей предлагается ознакомиться с принципами построения отказоустойчивой инфраструктуры небольшого предприятия в рамках одного ЦОДа, которые будут детально рассмотрены в небольшом цикле статей.
Иллюстрированное руководство по OAuth и OpenID Connect
В «каменном веке» интернета делиться информацией между сервисами было легко. Вы просто давали свой логин и пароль от одного сервиса другому, чтобы тот вошел в вашу учетную запись и получил любую необходимую ему информацию.
«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*
Жуть! Никто и никогда не должен требовать от пользователя поделиться логином и паролем, его учётными данными, с другим сервисом. Нет никакой гарантии, что организация, стоящая за этим сервисом, будет хранить данные в безопасности и не соберет больше персональной информации, чем нужно. Это может показаться дикостью, но некоторые приложения до сих пор применяют подобную практику!
Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).
Отлаживаем сетевые задержки в Kubernetes
Пару лет назад Kubernetes уже обсуждался в официальном блоге GitHub. С тех пор он стал стандартной технологией для развёртывания сервисов. Теперь Kubernetes управляет значительной частью внутренних и публичных служб. Поскольку наши кластеры выросли, а требования к производительности стали более жёсткими, мы стали замечать, что в некоторых службах на Kubernetes спорадически появляются задержки, которые нельзя объяснить нагрузкой самого приложения.
По сути, в приложениях происходит будто случайная сетевая задержка до 100 мс и более, что приводит к тайм-аутам или повторным попыткам. Ожидалось, что службы смогут отвечать на запросы гораздо быстрее 100 мс. Но это невозможно, если само соединение отнимает столько времени. Отдельно мы наблюдали очень быстрые запросы MySQL, которые должны были занимать миллисекунды, и MySQL действительно справлялась за миллисекунды, но с точки зрения запрашивающего приложения ответ занимал 100 мс или больше.
Информация
- В рейтинге
- Не участвует
- Зарегистрирован
- Активность