Освой работу с Prometheus, Grafana, ELK, etc и настрой мониторинг!

✅ Владение инструментами Observability открывает новые карьерные горизонты администраторам Linux, DevOps-инженерам 

Стройте сложные эффективные системы мониторинга и логирования инфраструктуры и приложений 

💪 Ответьте на 15 вопросов и проверьте, насколько вы готовы к обучению на курсе «Observability: мониторинг, логирование, трейсинг» от OTUS.

+ 5 новых занятий, для вашего профессионального развития

Пройти тест и получить спец. предложение:  
https://otus.pw/QJUi/?erid=LjN8KPbx5

#реклама
О рекламодателе

Часто приходится работать с контрольными суммами? Облегчите себе жизнь при помощи утилиты OpenHashTab https://github.com/namazso/OpenHashTab с открытым исходным кодом под лицензией GPL 3.0.

Утилита встраивается в Проводник Windows и показывает на отдельной вкладке информацию о контрольных суммах файла (или файлов, если открыть свойства папки). Также она позволяет быстро проверить контрольную сумму на совпадение, достаточно просто скопировать ее в буфер обмена, утилита подставит и проверит ее автоматически.

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

​​Эскалации в Zabbix

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

И очень часто в дело вступает человеческий фактор, который превращает небольшое происшествие в проблему масштаба предприятия.

Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?

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

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

Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?

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

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

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

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

Но и выставлять слишком большой период тоже не стоит, иначе может оказаться что мы начали «бить в колокола» слишком поздно.

Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.

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

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

Ждем еще 15 минут, если нет реакции, то мы можем не только продолжать уведомлять все более вышестоящие лица, но и выполнять некоторые действия для решения проблемы. Например, снять отчеты по нагрузке на CPU, память, диски и отправить их кому надо.

Снова нет реакции? Ну тогда в дело вступают роботы, можем прибить самый ресурсоемкий процесс. Не помогло? Кстати, для этого можно и не ждать следующие 15 минут, а задать произвольное время шага, допустим 5 минут.

Через 5 минут после того, как мы прибили процесс снова высокая нагрузка? Ну давайте последний раз всех предупредим. Не помогло? Ну тогда идем на крайние меры и перезагружаем узел.

Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.

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

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

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

Ansible: Какой тип инвентаря применяется в Ansible по умолчанию? 🤔

a) База данных
b) Динамический инвентарь
c) Инвентарь в формате JSON
d) Файл инвентаря

Пройдите тест и получите скидку на курс «Ansible: Infrastructure as Code».

На курсе мы:
✔️ систематизируем знания по Ansible и изучаем подход IaC;
✔️ учимся писать плейбуки и роли;
✔️ деплоим Flask-приложение;
✔️ настраиваем IaC в Gitlab;
✔️ обеспечиваем поддержку наших решений вдолгую.

5 вопросов по Ansible ждут вас внутри бота.
Проверяйте себя и до встречи на обучении! 🔥

#реклама
О рекламодателе
erid: LjN8KJpVQ

​​И снова о выборе мыши, часть 1. Разрешение

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

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

Сегодня основной размер экранов в пикселях – это FHD, так, для 1920 x 1080 диагональ экрана составит 2202 px, а для 2K экрана – уже 2937 px.

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

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

Возьмем дешевую мышь с разрешением 800 dpi, это значит, что при движении мыши на 1 дюйм в физическом пространстве курсор пройдет на экране 800 px.

Нетрудно посчитать, что для того, чтобы переместить курсор из одного конца диагонали FHD экрана в другой нам нужно физически передвинуть мышь на 2,75 дюйма или почти 7 см.

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

Но если мы увеличим разрешение мыши вдвое, то нам потребуется для этого всего 3,5 см физического расстояния, а если взять мышь с разрешением 2400 dpi, то получим весьма комфортные 2,33 см.

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

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

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

Почему так происходит? Все просто, обычная геометрия. Допустим, человек прикинул, что ему нужно подвинуть мышь на 45 градусов, но человек не робот и он на самом деле подвинул ее на 43 градуса.

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

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

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

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

Вроде бы так. Но вот мышь – тоже не идеальное устройство и имеет свою точность. Грубо говоря даже строго подвинув мышь на 45 градусов, мы не получим идеальной прямой. А получим тот же круговой сектор, в котором может оказаться курсор мыши.

Чем точнее мышь, тем уже угол данного сектора, а площадь сектора – это набор точек пространства, где может оказаться курсор. Только вот площадь сектора растет не в прямой, а в геометрической пропорции от радиуса.

Так увеличив радиус всего на 10, мы увеличим площадь на 100. В нашем случае 10 – это скорость, а 100 – точность. Ну это совсем ни в какие ворота. И именно этим страдают дешевые мыши, где разрешение подняли программно.

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

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

Как это сделать? Совершенно несложно, достаточно воспользоваться утилитой BgInfo от Sysinternals. Эта небольшая программа от Марка Руссиновича считывает всю необходимую информацию и выводит ее прямо на обоях рабочего стола. Т.е. достаточно запустить ее один раз и вся необходимая информация будет у вас перед глазами пока вы не смените обои.

Подробнее в статье: Как вывести информацию о системе на рабочий стол

​​Атомарные дистрибутивы – будущее настольного Linux?

Выходные – самое время отвлечься от насущных рабочих дел и почитать что вообще происходит в отрасли. Тем более что есть достаточно интересные новости.

Разработчики KDE объявили о разработке собственного дистрибутива KDE Linux, который будет предоставлять всем желающим все преимущества графической оболочки KDE из первых рук.

Система будет базироваться на пакетной базе Arch Linux и предоставляться в трех выпусках: стабильном, для энтузиастов (на основе бета-версий оболочки) и тестовом.

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

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

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

На этом фоне становится все равно на какой именно пакетной базе собран дистрибутив. Это не имеет никакого значения, потому что для нас это обычный черный ящик, доступный только на чтение.

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

Практически одновременно с ними разработчики GNOME OS заявили, что они планируют в ближайшее время превратить дистрибутив, который сейчас нацелен на разработчиков и тестировщиков GNOME в дистрибутив общего назначения.

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

Практически близнецы братья, точнее не близнецы, а двойняшки. И это хорошо показывает современные тенденции в мире настольного Linux, который сильно тяготеет к концепции Android.

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

Классическая концепция разработки в Linux, когда разработчики пишут код, майнтрейнеры собирают и поддерживают его в рамках дистрибутива сильно устарела. Особенно там, где это касается прикладного, пользовательского ПО.

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

Попытки пользователя самостоятельно обновлять софт в рамках пакетных дистрибутивов приводят к подключению сомнительных источников пакетов и ведут в сторону неизбежных проблем и потери стабильности системы.

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

Поэтому появление Flatpak и аналогов было принято на ура – собрал один раз универсальный пакет и все им пользуются, на любом дистрибутиве.

А дальше возникает логичная идея: а зачем вообще нужны дистрибутивы в их современном виде? Настольные разумеется. Ведь есть же отличный пример Andriod, где все что нужно пользователю – это научиться пользоваться магазином.

Поэтому давайте сделаем атомарную систему, сломать которую будет практически невозможно и прикрутим к ней такой же магазин, только Flatpak.

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

И настольный Linux серьезно настроен двигаться этим путем, нравится нам это или нет.

Как мне кажется, скоро название Linux останется только за серверными ОС, которые продолжат использовать классическую пакетную базу.

А настольные ОС станут просто GNOME OS, KDE OS, Ubuntu или Fedorа и только специалисты будут вспоминать, что под капотом там тоже вроде-как Linux.

​​Четвертые сутки пылают станицы…

Как гром среди ясного неба прозвучала новость: в известный дистрибутив Manjaro разработчики собрались добавить телеметрию.

И понеслось, начались бурные обсуждения и осуждения на всех тематических, а особенно околотематических площадках что у нас, что у них.

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

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

https://forum.manjaro.org/t/testers-needed-manjaro-data-donor/170163

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

Но кому это нужно, ведь прозвучало ключевое – ТЕЛЕМЕТРИЯ!!!

Хотя, если разобраться, ничего криминального в этом нет. Наоборот, разработчикам нужно знать портрет своей аудитории, а человек – существо ленивое и сам делиться такой информацией не спешит.

Другое дело, что собирать и отправлять можно разное, но это уже относится к этической стороне вопроса. Тем более что собирают и отправляют сегодня все кому не лень.

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

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

А для этого как раз и нужно понимание своей аудитории, скажем, если практически никто не использует x86 архитектуру, то можно отказаться от ее поддержки.

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

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

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

​​Некоторые особенности использования устаревших дистрибутивов Debian и Ubuntu

Иногда так получается, что мы бываем вынуждены использовать старые дистрибутивы Linux, чаще всего это связано с поддержкой некоторого, специфичного софта, которого нет под более новые системы, либо его обновление связано с объективными трудностями.

В этом случае правильный выбор ОС становится особенно важным. В семействе DEB-дистрибутивов выбор невелик: Debian или Ubuntu и многие выбирают Debian. Скорее по привычке, ну и за то, что более консервативен.

Однако в нашем случае следует рассматривать ситуацию совсем под иным углом.

Для примера возьмем такой программный комплекс как Aspia, который разработчик собирает исключительно под Ubuntu 20.04 и Debian 11.

Давайте смотреть:

🔸 Ubuntu 20.04 LTS Focal Fossa. Дата выпуска - 2020-04, EOL - 2025-04

🔸 Debian 11 Bullseye. Дата выпуска - 2021-08, EOL - 2026-06

Может показаться, что выбор Debian дает нам лишний год, но на самом деле это не так.

Да, основная поддержка Ubuntu 20.04 закончится уже весной следующего года, но это коммерческий дистрибутив и его разработчики предлагают приобретение пакета расширенной поддержки общим сроком до 10 лет, прямо как у CentOS, за что его многие и выбирали.

Таким образом поддержка Ubuntu 20.04 будет у нас до 2030 года, а у Debian закончится уже летом 2026.

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

Кроме того, любому желающему выдается подписка на 5 узлов (физические ПК или виртуальные машины) для личного некоммерческого использования.

Мы, как законопослушные граждане, конечно, хотели бы купить лицензию за 25$, но обстоятельства не позволяют нам этого сделать, в тоже время бесплатные лицензии даются за простую регистрацию, можно даже на почтовые ящики в зоне RU.

В состав подписки Ubuntu PRO входят не только обновления, а ряд дополнительных сервисов, например Livepatch Service, позволяющий устанавливать обновления ядра без перезагрузки.

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

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

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

Крутая возможность для тех, кто:
• уже работает в ИТ и хочет сменить направление
• студент или выпускник ИТ/ИБ профессий
• начинающий ИБ-специалист

Приходи на бесплатный вебинар
«Как защититься от хакерских атак в 2024. Популярные техники и способы обнаружения»

✅ узнаешь типы кибератак и как от них защититься
✅ сделаешь первые шаги как Blue Team специалист
✅ научишься обнаруживать атаки с помощью SIEM
✅ попробуешь реальные инструменты ИБ-шников, погрузишься в практику и попробуешь профессию изнутри

→ Смотри программу и регистрируйся

Сделай правильный выбор для своего будущего :)

TCPING

Tcping – простая кроссплатформенная утилита написанная на Go для проверки доступности узлов по протоколу TCP. По принципу действия повторяет классическую утилиту Ping.

Может быть полезна для контроля узлов, где запрещен ICMP, а также для контроля работы отдельных сетевых служб или проверки доступности портов.

Также утилита позволяет оценить RTT – время приема-передачи, которое характеризует задержку канала, причем сразу вычисляются минимальное, максимальное и среднее значения.

Использовать утилиту крайне просто, указываем узел и желаемый порт:

tcping  example.com 80

Чтобы получить справку по используемым ключам просто запустите утилиту без параметров или с ключом -h.

Скачать утилиту можно с официальной страницы на GitHub: https://github.com/pouriyajamshidi/tcping

Уже было, но не все знают, хотя актуальность вопроса повысилась.

Установка сервера 1C:Предприятие, PostgreSQL и Apache2 на Альт Сервер 10

Данная статья довольно необычна для нашего ресурса, потому что мы в своей работе используем дистрибутивы Debian / Ubuntu, но многие наши читатели, в рамках импортозамещения, пробуют переходить на Альт.

Сервер 1С:Предприятия - также одна из самых востребованных ролей. И вот мы начали получать сообщения, что многие испытывают сложности с настройкой этой связки, хотя проблемам там взяться, вроде бы неоткуда.

Поэтому мы самостоятельно изучили данный вопрос и подготовили практическую инструкцию с учетов всех особенностей и подводных камней для Альт Сервер 10

https://interface31.ru/tech_it/2022/12/ustanovka-servera-1cpredpriyatiya-postgresql-apache2-na-alt-server-10.html