По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Ведение логов повсеместно присутствует в программных проектах и имеет множество различных форм и требований.
Ведение логов встречается повсеместно, от небольших стартапов, состоящих из одного человека, до крупных компаний. Даже простой вопрос алгоритмического программирования подразумевает ведение журнала.
Мы сильно зависим от логов для разработки, поддержки и обеспечения работы наших программ. Однако мало кто уделяет внимание их правильному проектированию. Часто логирование рассматривается второстепенно — его добавляют в код словно магический порошок, чтобы облегчить повседневную эксплуатацию системы.
Любой код со временем превращается в технический недочет, и логирование — не исключение. Логи быстро устаревают, и в итоге мы чаще исправляем ошибки, вызванные логами, чем получаем полезную информацию от них.
Как же навести порядок в логировании и превратить его в союзника, а не в проблему из прошлого?
Что такое логирование?
Вот интересное определение из статьи Колина Эберхардта:
Логирование — это процесс записи действий и состояния приложения во вспомогательный интерфейс.
Логирование вплетается в систему именно так. Мы, похоже, соглашаемся, что логи не относятся к конкретному слою системы, а являются общей функциональностью, разделяемой между различными компонентами приложения.
Простая схема, на которой протоколирование вписано в систему с чистой архитектурой, будет выглядеть примерно так:
Можно с уверенностью сказать, что ведение журнала само по себе является подсистемой в нашем приложении. И мы можем с уверенностью сказать, что без тщательного рассмотрения она часто выходит из-под контроля быстрее, чем мы думаем.
Хотя в том, что логирование является подсистемой приложения, нет ничего плохого, традиционное восприятие логирования (с 4-6 уровнями info, warn, error, debug и так далее) часто заставляет разработчиков сосредоточиться не на том, на чем нужно. Оно заставляет нас сосредоточиться на формате, а не на фактической цели, для которой мы пишем журналы.
Это одна из причин, почему мы выводим ошибки, не задумываясь о том, как их обрабатывать. Это также причина, по которой мы ведем журнал на каждом шаге нашего кода и, по иронии судьбы, не можем эффективно отлаживать его в случае возникновения проблем на производстве.
Именно поэтому предлагаем альтернативный фреймворк для протоколирования и, в свою очередь, то, как мы можем надежно спроектировать протоколирование в наших системах.
Хорошее, плохое и ужасное
Это схема того, как, по моему мнению, мы должны выстраивать стратегию ведения журнала. В ней есть три - и только три - категории или проблемы для наших журналов.
Первое правило ведения журнала: не вести журнал
Чрезмерное ведение логов вредит продуктивности наших команд и их способности справляться с обычными операциями.
Есть масса причин, по которым мы не должны «логировать при любой возможности», как советуют некоторые фанаты наблюдаемости. Ведение логов означает большее количество кода, который нужно поддерживать, оно влечет за собой расходы на производительность системы, а ведение логов подвергает нас большему количеству проверок на предмет конфиденциальности данных.
Тем не менее, не советуем полностью отказаться от ведения журналов. Ведение журналов при правильном использовании может существенно помочь нам обеспечить надежную работу наших систем.
Предлагаем начать без протоколирования и работать по нарастающей, чтобы определить места, где нам нужно протоколировать, а не «протоколировать везде, так как нам может понадобиться посмотреть на них».
Мое эмпирическое правило при добавлении строки журнала: «Если мы не можем определить точную причину или сценарий, когда мы будем смотреть на журнал, не записывайте».
С учетом сказанного, как мы можем безопасно внедрить ведение журнала, когда это абсолютно необходимо? Как мы должны структурировать наши журналы и оформлять их содержимое? Какую информацию необходимо включать в журналы?
Ужасный журнал
Это первый тип журналов, который можно встретить реже всего. (Если мы находим их слишком часто, то, возможно, в наших системах есть более серьезные проблемы!)
«Ужасные» журналы — это журналы катастрофических или неожиданных сценариев, которые требуют немедленных действий (например, катастрофические ошибки, требующие перезапуска приложения). Можно утверждать, что при таких обстоятельствах имеет смысл использовать инструменты оповещения, такие как Sentry.
Тем не менее, журнал ошибок все еще может быть полезен, чтобы предоставить нам больше контекста вокруг этих ошибок, который недоступен в их стековой трассировке. Но они могут помочь в воспроизведении этих ошибок, например, пользовательского ввода.
Как и ошибки, которые они сопровождают, эти журналы должны быть сведены к минимуму в нашем коде и размещены в одном месте. Они также должны быть разработаны/документированы в спецификации как обязательное поведение системы для обработки ошибок. Кроме того, они должны быть вплетены в исходный код, где происходит обработка ошибок.
Хотя формат и уровень «уродливых» журналов полностью зависит от конкретной команды, я бы рекомендовал использовать log.error или log.fatal до изящного выключения и перезапуска приложения. Также следует приложить полную трассировку стека ошибки и входные данные функции или запросов для воспроизведения в случае необходимости.
Плохой журнал
«Плохие» журналы -—это журналы, в которых рассматриваются ожидаемые ошибки, такие как проблемы с сетью и валидация пользовательского ввода. Этот тип журналов требует внимания разработчиков только в случае возникновения аномалии.
Вместе с монитором, настроенным на оповещение разработчиков об ошибке, эти журналы удобны для смягчения потенциальных серьезных проблем с инфраструктурой или безопасностью.
Этот тип журнала также должен быть указан в технических требованиях к обработке ошибок, и его можно объединить, если мы обрабатываем ожидаемые и неожиданные ошибки в одном и том же месте кода.
В зависимости от характера того, что они делают «видимым» для разработчиков, log.warn или log.error могут быть использованы для «плохих» журналов, если команда придерживается определенной конвенции.
Хороший журнал
Последний, но, безусловно, не менее важный, «Хороший» тип журнала, который должен чаще всего появляться в нашем исходном коде - но его зачастую сложнее всего сделать правильно. «Хорошие» журналы - это журналы, связанные со „счастливыми“ этапами работы наших приложений, свидетельствующие об успешном выполнении операций.
В силу самой своей природы, указывающей на начало/успешное выполнение операций в нашей системе, «Хорошие» часто злоупотребляются разработчиками, которые соблазняются мантрой: «Еще один бит данных в журнале, он может нам пригодиться».
И снова я возвращаюсь к нашему самому первому правилу ведения журнала: «Не ведите журнал, если вам это не нужно». Чтобы не допустить такого рода избыточного протоколирования, мы должны документировать «Добро» как часть наших технических требований, дополняющих основную бизнес-логику.
Кроме того, каждый из «хороших» журналов, которые находятся в нашем техническом задании, должен пройти лакмусовую бумажку: есть ли обстоятельства, при которых мы будем смотреть на этот журнал (будь то запрос в службу поддержки, запрос внешнего аудитора)? Только в этом случае log.info не станет страшным наследием, заслоняющим разработчикам видение наших приложений.
Остальное, что вам нужно знать
Полагаю, вы уже заметили, что общая тема предложенной мною стратегии ведения журналов сводится к четкому и конкретному документированию цели ведения журнала. Важно, чтобы мы рассматривали ведение журнала как часть наших требований, и чтобы мы точно определили, какие ключевые слова и сообщения мы хотим помечать в контексте каждого журнала, чтобы они эффективно индексировались.
Только так мы сможем быть в курсе каждого журнала, который мы создаем, и, в свою очередь, иметь четкое представление о наших системах.
Поскольку журналы становятся первоклассными инструкциями с конкретными техническими требованиями в наших спецификациях, это приведет к тому, что их нужно будет
поддерживать и обновлять по мере развития бизнеса и технических требований
проводить модульные и интеграционные тесты.
Это может показаться большим объемом дополнительной работы, чтобы сделать наши журналы правильными. Однако я утверждаю, что именно такого внимания и усилий заслуживает ведение журналов, чтобы они могли быть полезными.
Практическое руководство по миграции
Нет смысла в новой стратегии ведения логов (или в любых других новых стратегиях/фреймворках) для старых проектов, если нет возможности перевести их из беспорядочного состояния в идеальное.
Поэтому у нас есть общий план из трех шагов для тех, кто разочарован логами своей системы и готов потратить время на более эффективное ведение логов.
Определите обычных подозреваемых
Поскольку идея состоит в том, чтобы уменьшить количество мусорных логов, первым шагом будет определение того, где прячутся преступники. С помощью мощных текстовых редакторов и IDE, которыми мы сегодня располагаем (или grep, если вы читаете это в прошлом через окно в будущее), можно легко определить все случаи ведения логов.
Документ (или электронная таблица, если вы хотите быть организованным), документирующий все эти случаи регистрации, может понадобиться, если их слишком много.
Исключите все плохие логи
После выявления всех подозреваемых пришло время отсеять плохие яблоки. Дублирующиеся или недоступные журналы - это низко висящие плоды, которые мы можем немедленно исключить из нашего исходного кода.
Что касается остальных случаев ведения логов, то пора привлечь других заинтересованных лиц. Например, инженера, который начал проект (если это возможно), менеджеров по продукту, службу поддержки клиентов или специалистов по соблюдению нормативных требований, чтобы ответить на вопрос: Нужен ли нам каждый из этих журналов, и если да, то для чего они используются?
Подведем итог
Теперь, когда у нас есть суженный список абсолютно необходимых журналов, превращение их в технические требования с документированным назначением каждого из них необходимо для заключения контракта (или мы можем назвать его спецификацией) для нашей подсистемы протоколирования. Спросите себя, что делать, когда происходит log.error, и для кого мы ведем log.info?
В этой статье мы расскажем о нескольких единицах CSS для настройки размера шрифта текста при создании веб-страниц. Существует множество других единиц, таких как pt, pc, ex и т.д., но мы сосредоточимся на трех самых популярных единицах: px, em и rem.
Многие разработчики обычно не понимают, в чем разница между этими единицами (мы тоже не понимали, пока не прошло много лет в нашей карьере); поэтому мы постараемся объяснить их как можно яснее.
Давайте начнем!
Пиксель (Pixel, PX)
Пиксель, вероятно, является самой часто используемой единицей в CSS и очень популярен при установке размера шрифта текста на веб-страницах. Один пиксель (1px) определяется как 1/96 дюйма в печатных материалах. Однако на экранах компьютеров они обычно не связаны с реальными измерениями, такими как сантиметры и дюймы, как можно было бы подумать; они просто определены как маленькие, но видимые. Что считается видимым, зависит от устройства.
Как мы знаем, у разных устройств разное количество пикселей на дюйм на их экранах, что называется плотностью пикселей. Если бы мы использовали количество физических пикселей на экране устройства для определения размера контента на этом устройстве, у нас возникли бы проблемы с тем, чтобы сделать так, чтобы все выглядело одинаково на экранах разных размеров. Здесь вступает в игру коэффициент пикселей устройства. Это по сути способ рассчитать, сколько места займет CSS-пиксель (1px) на экране устройства, чтобы он выглядел одинаково по размеру по сравнению с другим устройством.
Это могло быть сложным для восприятия, позвольте упростить. В принципе, разные экраны имеют разное количество пикселей (плотность пикселей), и компьютеры выполняют некоторые вычисления, чтобы обеспечить согласованность размера отображаемого контента на экранах, независимо от плотности пикселей.
Посмотрим на пример ниже.
Немного HTML:
Чуть-чуть CSS:
* {
font-family: Arial, Helvetica, sans-serif;
}
.container {
width: 100%;
height: 100vh;
display: flex;
justify-content: center;
align-items: center;
}
.container div {
max-width: 500px;
padding: 5px 20px;
border: 1px grey solid;
border-radius: 10px;
}
p {
font-size: 16px;
}
Результат:
Верхний блок показывает, как это выглядит на большом экране, например, на ноутбуке, а нижний блок демонстрирует, как это выглядит на маленьком экране, например, на телефоне.
Обратите внимание, что текст в обоих блоках одинакового размера. Это как раз то, как работает пиксель. Он помогает веб-контенту (не только тексту) выглядеть одинаково по размеру на разных устройствах.
EM (M)
Единица EM получила свое название от заглавной буквы «M» (em), так как большинство единиц CSS происходит из типографики. Единица EM использует текущий размер шрифта родительского элемента в качестве основы. Она фактически может использоваться для увеличения или уменьшения размера шрифта элемента в зависимости от размера шрифта, унаследованного от родителя.
Предположим, у нас есть родительский div с размером шрифта 16px. Если мы создадим элемент параграфа в этом div и установим ему размер шрифта 1em, размер шрифта параграфа будет 16px. Однако, если мы зададим другому параграфу размер шрифта 2em, это будет соответствовать 32px. Посмотрим на пример ниже.
Немного HTML:
Чуть-чуть CSS:
* {
font-family: Arial, Helvetica, sans-serif;
}
.div-one {
font-size: 15px;
}
.div-two {
font-size: 20px;
}
.one-em {
font-size: 1em;
}
.two-em {
font-size: 2em;
}
И вот так!
Из скриншота выше мы видим, как единица EM может увеличивать размер текста и как размер шрифта изменяется в зависимости от текущего размера шрифта, унаследованного от родительского контейнера.
Прежде чем вы сильно обрадуетесь, мы должны предостеречь вас... не рекомендуется использовать EM, особенно на страницах со сложной структурой. Если использовать его неправильно, мы можем столкнуться с проблемами масштабирования, когда элементы могут не иметь правильный размер из-за сложного наследования размеров в дереве DOM.
REM (Root EM)
И наконец, REM. Он работает почти так же, как и EM, но основное различие заключается в том, что REM ссылается только на размер шрифта корневого элемента на странице, а не на размер шрифта родителя.
Корневой размер шрифта — это размер шрифта по умолчанию, установленный либо пользователем в настройках браузера, либо вами, разработчиком.
По умолчанию размер шрифта в веб-браузере обычно составляет 16px, поэтому 1rem будет равен 16px, а 2rem будет равен 32px. Однако, если корневой размер шрифта изменен, например, на 10px, тогда 1rem будет равен 10px, а 2rem — 20px.
Давайте рассмотрим пример, чтобы сделать это немного яснее.
Немного HTML:
И CSS:
html {
font-size: 16px;
}
* {
font-family: Arial, Helvetica, sans-serif;
}
.div-one {
font-size: 40px;
}
.one-em {
font-size: 1em;
}
.two-em {
font-size: 2em;
}
.one-rem {
font-size: 1rem;
}
.two-rem {
font-size: 2rem;
}
Получается:
Как вы можете видеть, параграфы, заданные с помощью единиц REM, полностью не затронуты размером шрифта, установленным в нашем контейнере, и строго рендерятся относительно корневого размера шрифта, определенного в селекторе элемента html.
Вердикт
Теперь, когда вы понимаете, как работает каждая единица, мы расскажем, какая из них выигрывает в этой напряженной борьбе и почему.
Как уже упоминалось, мы не рекомендуем использовать EM из-за возможности возникновения сложной иерархии вложенных элементов. Это может привести к проблемам, поскольку EM относительно размера шрифта, унаследованного от родителя, что означает, что размер текста может масштабироваться неконтролируемо, если не управлять этим правильно.
Теперь PX и REM в основном оказывают одинаковое влияние на текст; мы получим одинаковый результат, если используем 32px и 2rem. Это связано с тем, что размер шрифта по умолчанию равен 16px.
Однако REM имеет преимущество, когда речь заходит о доступности.
При учете доступности мы хотим, чтобы пользователи с ограниченным зрением могли комфортно читать контент на наших веб-сайтах. Один из способов настроить размер текста на экране — это использовать функцию масштабирования браузера.
Функция масштабирования (показана выше) отлично работает как для PX, так и для REM. Однако существует другой способ, который тоже можно использовать. Это когда пользователь изменяет размер шрифта по умолчанию в настройках браузера. Этот метод позволяет тексту на экране пользователя отображаться крупнее или меньше в зависимости от того, как он это настроит. Это освобождает пользователей от необходимости вручную масштабировать каждую страницу, которую они посещают. Давайте посмотрим, как REM и PX работают с этим методом.
Первый параграф установлен с размером шрифта 16px, а второй — с размером шрифта 1rem. Как вы видите, они оба одинакового размера.
В данный момент настройка размера шрифта в браузере установлена на средний. Давайте посмотрим, что произойдет, если изменить ее на очень большой.
Результат:
Тексты с надписями "Этот параграф 16px" и "Этот параграф 1rem", стилизованные соответственно 16px и 1rem. Но в этот раз текст с REM немного больше, потому что настройка размера шрифта в браузере была изменена.
Как видно, текст, установленный с помощью REM, корректно масштабировался с новым размером шрифта по умолчанию, который мы указали в настройках браузера.
Поэтому мы определенно рекомендуем использовать REM при работе с текстовым контентом на ваших веб-страницах.
This is a paragraph
Lorem ipsum, dolor sit amet consectetur adipisicing elit. Reprehenderit incidunt perferendis iure veritatis cupiditate delectus omnis at! Officiis praesentium officia, nemo veniam consequatur nostrum sunt aliquid ipsam, corporis quas quaerat. Lorem ipsum dolor sit amet consectetur adipisicing elit. Hic quam beatae voluptatibus amet possimus iure impedit assumenda distinctio aliquid debitis, autem vel ullam aut, quod corporis ratione atque ducimus dolorum.
1 em на основе 10px
2 em на основе 10px
1 em на основе 10px
2 em на основе 10px
1 em на основе контейнера (40px)
2 em на основе контейнера (40px)
1 rem на основе корня (16px)
2 rem на основе корня (16px)
Перед использованием раздел диска необходимо отформатировать и смонтировать. Процесс форматирования также может быть выполнен по ряду других причин, таких как изменение файловой системы, исправление ошибок или удаление всех данных.
В этом руководстве вы узнаете, как форматировать и монтировать разделы диска в Linux с использованием файловой системы ext4, FAT32 или NTFS.
Проверка разделов
Перед форматированием найдите раздел, который хотите отформатировать. Для этого запустите команду lsblk, которая отображает блочные устройства. Блочные устройства - это файлы, которые представляют такие устройства, как жесткие диски, RAM-диски, USB-накопители и CD/ROM.
lsblk
Терминал покажет список всех блочных устройств, а также информацию о них:
NAME - имена устройств
MAJ:MIN - старший или младший номер устройства
RM - является ли устройство съемным (1, если да, 0, если нет)
SIZE - размер устройства
RO - доступно ли устройство только для чтения
TYPE - тип устройства
MOUNTPOINT - точка монтирования устройства
В качестве примера мы будем использовать раздел /dev/sdb1.
Команда lsblk без дополнительных параметров не отображает информацию о файловых системах устройств.
Чтобы отобразить список, содержащий информацию о файловой системе, добавьте параметр -f:
lsblk -f
Терминал покажет список всех блочных устройств. Разделы, не содержащие информации об используемой файловой системе, являются неформатированными разделами.
Форматирование раздела диска в Linux
В зависимости от типа файловой системы существует три способа форматирования разделов диска с помощью команды mkfs:
ext4
FAT32
NTFS
Общий синтаксис форматирования разделов диска в Linux:
mkfs [options] [-t type fs-options] device [size]
Форматирование раздела диска с файловой системой ext4
1. Отформатируйте раздел диска с файловой системой ext4, используя следующую команду:
sudo mkfs -t ext4 /dev/sdb1
2. Затем проверьте изменение файловой системы с помощью команды:
lsblk -f
Терминал покажет список блочных устройств.
3. Найдите нужный раздел и убедитесь, что он использует файловую систему ext4.
Форматирование раздела диска с файловой системой FAT32
1. Чтобы отформатировать диск в файловой системе FAT32, используйте:
sudo mkfs -t vfat /dev/sdb1
2. Снова запустите команду lsblk, чтобы проверить изменение файловой системы и найти нужный раздел в списке.
lsblk -f
Ожидаемый результат:
Форматирование раздела диска с файловой системой NTFS
1. Запустите команду mkfs и укажите файловую систему NTFS для форматирования диска:
sudo mkfs -t ntfs /dev/sdb1
Терминал покажет подтверждающее сообщение, когда процесс форматирования завершится.
2. Затем проверьте изменение файловой системы, используя:
lsblk -f
3. Найдите нужный раздел и убедитесь, что он использует файловую систему NFTS.
Монтирование раздела диска в Linux
Перед использованием диска создайте точку монтирования и смонтируйте к ней раздел. Точка монтирования - это каталог, используемый для доступа к данным, хранящимся на дисках.
1. Создайте точку монтирования, введя:
sudo mkdir -p [mountpoint]
2. После этого смонтируйте раздел с помощью следующей команды:
sudo mount -t auto /dev/sdb1 [mountpoint]
Примечание. Замените [mountpoint] предпочтительной точкой монтирования (пример: /usr/media).
Если процесс завершился успешно, вывода нет.
3. Убедитесь, что раздел смонтирован, используя следующую команду:
lsblk -f
Ожидаемый результат:
Понимание файловой системы Linux
Выбор правильной файловой системы перед форматированием диска для хранения имеет решающее значение. Каждый тип файловой системы имеет разные ограничения размера файла или разную совместимость с операционной системой.
Наиболее часто используемые файловые системы: FAT32, NTFS и ext4
Их основные особенности и отличия:
Файловая система
Поддерживаемый размер файла
Совместимость
Идеальное использование
FAT32
до 4 ГБ
Windows, Mac, Linux
Для максимальной совместимости
NTFS
16 EiB - 1 КB
Windows, Mac (только для чтения), большинство дистрибутивов Linux
Для внутренних дисков и системного файла Windows
Ext4
16 GiB - 16 TiB
Windows, Mac, Linux (для доступа требуются дополнительные драйверы)
Для файлов размером более 4 ГБ