На 6,5 диагонали смотреть очень даже комфортно, даже более чем. Для эксперимента увеличил масштаб, получилось вообще нечитаемо, видимо потому что интервал между строк тоже увеличился. Видел решение на некоторых сайтах кнопки увеличить/уменьшить шрифт. Думаю это идеальное решение.
Не совсем так, горизонтальное масштабирование возможно и когда порядок сообщений важно не нарушить.
Группы консумеров всё-таки классная штука. Один консумер может читать одновременно из нескольких партиций, но уже два консумера одновременно читать из одной партиции не могут, один из них будет всегда в режиме ожидания. Можно несколько консумеров сразу запустить на один топик, они поделят между собой партиции "случайным" образом. Может один консумер захватить все сразу партиции и читать из всех них, а могут поделить, один консумер читает одну часть партиций, второй - другую.
Если на первом произойдёт сбой, второй автоматически подхватит из режима ожидания и собственно продолжить читать сообщения из всех сразу партиций.
Вот здесь как раз и важен ключ партицирования, чтобы сообщение маршрутизировалось всегда в одну и ту же партицию. Без указания этого ключа сообщение практически рэндомно будет помещаться в любую партицию в топике. В опциях консумера даже можно выбрать алгоритм каким образом это будет происходить, но по сути это будет происходить случайным образом. Хотите постоянности, указывайте partition key при отправке сообщения в кафку продюсером.
При использовании групп консумеров в итоге не важно в каком из конкретных экземпляров консумеров происходит чтение партиции. Это и есть горизонтальное масштабирование, узел целиком упал, но второй консумер автоматом подхватил и смаршрутизировал всё что недоставлено в те же самые очереди и топики.
Моей ошибкой когда я разбирался в этом, было вычисление промежуточных данных и кеширование непосредственно в процессе-экземпляре конкретного консумера, чтобы разгрузить приёмник сообщений, и при падении консумера, конечно же всё это терялось. А второй подхватывал с пустым кешем, что в итоге ломало всю вышестоящую логику.
гарантия, что сообщения будут прочитаны в порядке их попадания в хранилище;
Kafka гарантирует строгую упорядоченность только в пределах одной партиции. Если топик разбит на две или более партиции, упорядоченность можно сохранить в пределах каждой отдельно взятой партиции, если при записи в топик указать ключ партицирования. Kafka гарантирует, что сообщения с одним и тем же ключом партицирования будут попадать в одну и ту же партицию, тогда упорядоченность сохраниться, но в пределах отдельных партиций. И при горизонтальном масштабировании с использованием групп консемеров, нужно это учитывать.
Полностью согласен, конечно же так нельзя делать. У меня много карт разных банков, но кроме как от имени Сбера мне ни разу никто из мошенников не звонил. Один раз даже назвали часть номера карты. После этого я отказался от хранения денег в нём. И поэтому в этом конкретном случае, я могу себе позволить так шутить. Но после разговора все равно обязательно сообщаю в настоящий Сбер о звонке и номере телефона.
Служба безопасности Сбербанка. От вас был перевод 15тыс Иванову Рашиду Оксидовичу подтверждаете? Подтверждаю. Разблокируйте пожалуйста перевод. (усиленно думают и чаще всего кладут трубку) Хотя некоторые не сдаются с первого раза, но это уже другая история. У меня нет уже давно этой карты.
Не нужно себя втягивать в разговор. Единственное правило.
А в моём варианте так ведь и есть, если не было изменений в репозитории, скрипт завершится с кодом ошибки 1. Если изменения были, изменения вытянутся через git pull и после этого можно перегенерировать список хостов. Можно сделать вокруг него скрипт-обвязку, проверять код возврата, и принимать решение. А можно сразу после git pull дописать свой код. Мне было удобнее сделать обвязку.
Лет 5-6-7 назад не помню точно, когда я внедрял РКН фильтр меня тоже посетила паранойя по этому поводу. Точнее почему Avast имел наглость подменить сертификат который был был уже подменён фильтром для вывода заглушки блокировки. И даже проверял на контролируемых хостингах на разных антивирусах, что всё происходит корректно, без модификации кода.
Насчёт паранойи пошутил, нужно было проверить корректность подмены сертификата.
Вот вот, не знаю как коллегам обьяснить, как я с 21 лет стажа работы с бсд и линуксом до сих пор сижу на винде на рабочей станции. А потому что заморочек не нужно, и всё работает. А дома линукс чисто для души, ибо я по своему опыту знаю, обновление версий дистрибутива легко превращает всё в тыкву. Плюс современные интерфейсы не нравятся. Гном сам по себе неудобный, даже плагинами не исправить, kde не лучше. Идеальный был kde3 после него неинтересен десктоп
Приобрёл c пару лет назад Dell Vostro 3580, изначально шёл с Ubuntu 18.04. Основная беда у меня с ним возникла с настройкой DPI для fullHD. Из коробки очень мелко, Gnome Tweaks давал только мыло на картинке, не спасла даже замена матрицы на IPS (родная TFT очень отвратительного качества). Вторая проблема возникла с модулем Wifi, он отказывался просыпаться после гибернации, тут было 50 на 50, либо проснётся, либо нет. И только ребут, что жутко бесило.
В поисках решения с DPI перебрал с десяток дистрибутивов, пока не добрался до Fedora на тот момент 29. Проблема ушла сразу, больше никакого мыла на экране. С просыпанием wifi модуля правда только в прошлом году что-то пофиксили, то ли ядро обновилось, то ли после апгрейда всей системы.
После очередного обновления федоры пару месяцев назад ноут превратился в тыкву, загрузил ubuntu 20.04, и опять это мыло на экране, либо чтение с лупой и спящий wifi. Я даже не знаю как это обьяснить, с одной стороны экспериментальная сущность федоры, с другой стороны попсовость убунты, но по моему опыту, с федорой на десктопе намного меньше проблем, чем с ubuntu
Вылезли все четыре годам к 20-25ти, три нормально, но четвёртый это было больно, десну прорезал очень долго. Два года назад почти друг за другом оба левых съел кариес, пришлось удалить. И оказалось очень даже жевательные были, сейчас на этой стороне не очень хорошо жевать получается. И ни одной пломбы не было и нет на них, в отличии от соседних, вторых моляров.
Ни разу ничего не отваливалось из-за этого. Много лет в проде работает.
Единственное, нужно ещё добавить в правила форвардинга трафик контейнеров, и маскарадинг. Без этого действительно сеть в контейнерах сломается
Что-то типа такого:
Заголовок спойлера
DOCKER_NET=«172.0.0.0/8»
iptables -t nat -A POSTROUTING! -o docker0 -s ${DOCKER_NET} -j MASQUERADE
iptables -A FORWARD -s ${DOCKER_NET} -j ACCEPT
iptables -A FORWARD -d ${DOCKER_NET} -j ACCEPT
iptables -A INPUT -s ${DOCKER_NET} -j ACCEPT
Я однажды по не знанию сделал такую дыру, с тех пор запускаю dockerd с опцией --iptables=false, ну или в daemon.json опцию «iptables»: false. Бонус в отличие 127.0.0.1:xxxx:yyyy — теперь можно нормально управлять списком трастед хостов через iptables/ufw.
За давностью лет могу и ошибаться, но всё таки, как мне помнится, всё таки не 8086, а именно 80186 там был. Клоны IBM PC XT точно выпускались на нём. А вот это клон был или оригинал, это я уже затрудняюсь сказать.
В 2000-2004 работал на одном военном заводе, там был парк в цехах от 186 до 386, штук 15-20, оригинальные даже, не клоны. Маркировку IBM точно видел. Там дискеты 5.25 умирали от нескольких недель до нескольких месяцев. Если я правильно помню, на 386х такое случалось намного чаще чем на остальных. Благо запас дискет был, целый стеллаж был забит «новыми» дискетами, а может и действительно новыми. Память подсказывает что BASF, но это не точно. В итоге всегда наготове всегда были пара-тройка дискет с досом и фокс про. На одном 286 или 386 кстати был hdd, но уже умерший к моему приходу, я честно пытался оживить, но не смог, а дискеты ещё жили наверно после меня
рунит c 2014 года не обновляется, конечно стабильность есть. Но иногда нет уверенности как рунит поведет себя в паре системд, в проде как-бы нужна стабильность, поэтому рисковать нет особо желания. Поттеринг реально опасный тип, поэтому и приходится на нативный в дитрибутив запуск переходить. Моя бы воля, на дебиане7 бы до сих пор сидел, но ядро уже по тех требованиям не подходит. Почти смирился уже )
— Проблема с journald (одна из) совсем в другом, на самом-то деле — он пишет всё что есть, нет возможности фильтрации до записи (кроме как по уровням), со всеми неудобствами (очень много мусора)…
Ну вот, собственно, это и причиняет неудобства. Я не совсем корректно выразился, что хотел сказать. С этим разобрался, конечно, с флагами, но то что пишется всё в одну кучу, не айс. Смешались в кучу, люди, кони, и всё другое. Это нехорошо. И всё равно, даже есть такая возможность, на основной процесс, который рулит всей системой, вешать логирование неправильно, причём без права разделения.
Первое впечатление о systemd было неоднозначным, было много негатива, а порой даже агрессивных выпадов в духе да как они могли покуситься на святое, было много разборов багов и неожиданных поведений во вполне ожидаемых событиях, но почему-то systemd считал по другому.
Решился в итоге на обновления виртуалок с debian 7 только спустя год после выхода 8ки jessie, и в принципе не пожалел. И следом обновил совсем уж старые centos6 до centos7. Разницы конечно глобально не заметил, upstart на центоси и runit на дебиане функции свои выполняли исправно, единственное, что стало плюсом, одинаковый конфиг сервисов на любой ОС. Хотя понравилось что ушли от своеобразной системы логирования у runit, всё стало логироваться в syslog.
Но как я понимаю, что это до поры до времени, journalctl пока не повсеместно используется, пока в 10м дебиане и центос8 логи пишутся по старинке, но вот в домашней федоре уже просто грепом по файликам не пройтись, и это не очень нравится. Конечно, дело привычки, но всё же.
По стабильности, за 4 года столкнулся всего два раза что сервисы переставали отвечать на команды, не запускались, не останавливались. Оба раза помогло systemctl daemon-reexec, без дорогостоящей перезагрузки всей системы.
Из мелочей — не работает опция CapabilityBoundingSet, например CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права, решилось установкой через setcap непосредственно на бинарник.
И в итоге — по моему опыту использования как раз основная претензия к journalctl, если остальные компоненты systemd занимаются ровно тем, чем должны по идеологии PID1, на мой взгляд как раз логирование выходит за эти рамки.
ASN.1 используется также и в протоколе SNMP всех версий. Думаю этот формат с нами надолго.
На 6,5 диагонали смотреть очень даже комфортно, даже более чем. Для эксперимента увеличил масштаб, получилось вообще нечитаемо, видимо потому что интервал между строк тоже увеличился. Видел решение на некоторых сайтах кнопки увеличить/уменьшить шрифт. Думаю это идеальное решение.
Скрин
Не совсем так, горизонтальное масштабирование возможно и когда порядок сообщений важно не нарушить.
Группы консумеров всё-таки классная штука. Один консумер может читать одновременно из нескольких партиций, но уже два консумера одновременно читать из одной партиции не могут, один из них будет всегда в режиме ожидания. Можно несколько консумеров сразу запустить на один топик, они поделят между собой партиции "случайным" образом. Может один консумер захватить все сразу партиции и читать из всех них, а могут поделить, один консумер читает одну часть партиций, второй - другую.
Если на первом произойдёт сбой, второй автоматически подхватит из режима ожидания и собственно продолжить читать сообщения из всех сразу партиций.
Вот здесь как раз и важен ключ партицирования, чтобы сообщение маршрутизировалось всегда в одну и ту же партицию. Без указания этого ключа сообщение практически рэндомно будет помещаться в любую партицию в топике. В опциях консумера даже можно выбрать алгоритм каким образом это будет происходить, но по сути это будет происходить случайным образом. Хотите постоянности, указывайте partition key при отправке сообщения в кафку продюсером.
При использовании групп консумеров в итоге не важно в каком из конкретных экземпляров консумеров происходит чтение партиции. Это и есть горизонтальное масштабирование, узел целиком упал, но второй консумер автоматом подхватил и смаршрутизировал всё что недоставлено в те же самые очереди и топики.
Моей ошибкой когда я разбирался в этом, было вычисление промежуточных данных и кеширование непосредственно в процессе-экземпляре конкретного консумера, чтобы разгрузить приёмник сообщений, и при падении консумера, конечно же всё это терялось. А второй подхватывал с пустым кешем, что в итоге ломало всю вышестоящую логику.
Это мой личный экспириенс )
Kafka гарантирует строгую упорядоченность только в пределах одной партиции. Если топик разбит на две или более партиции, упорядоченность можно сохранить в пределах каждой отдельно взятой партиции, если при записи в топик указать ключ партицирования. Kafka гарантирует, что сообщения с одним и тем же ключом партицирования будут попадать в одну и ту же партицию, тогда упорядоченность сохраниться, но в пределах отдельных партиций. И при горизонтальном масштабировании с использованием групп консемеров, нужно это учитывать.
Полностью согласен, конечно же так нельзя делать. У меня много карт разных банков, но кроме как от имени Сбера мне ни разу никто из мошенников не звонил. Один раз даже назвали часть номера карты. После этого я отказался от хранения денег в нём. И поэтому в этом конкретном случае, я могу себе позволить так шутить. Но после разговора все равно обязательно сообщаю в настоящий Сбер о звонке и номере телефона.
Много лет мой диалог звучит примерно так
Служба безопасности Сбербанка. От вас был перевод 15тыс Иванову Рашиду Оксидовичу подтверждаете? Подтверждаю. Разблокируйте пожалуйста перевод. (усиленно думают и чаще всего кладут трубку) Хотя некоторые не сдаются с первого раза, но это уже другая история. У меня нет уже давно этой карты.
Не нужно себя втягивать в разговор. Единственное правило.
А в моём варианте так ведь и есть, если не было изменений в репозитории, скрипт завершится с кодом ошибки 1. Если изменения были, изменения вытянутся через git pull и после этого можно перегенерировать список хостов. Можно сделать вокруг него скрипт-обвязку, проверять код возврата, и принимать решение. А можно сразу после git pull дописать свой код. Мне было удобнее сделать обвязку.
Я таким способом проверяю обновления z-i без выкачивания всего репозитория:
Лет 5-6-7 назад не помню точно, когда я внедрял РКН фильтр меня тоже посетила паранойя по этому поводу. Точнее почему Avast имел наглость подменить сертификат который был был уже подменён фильтром для вывода заглушки блокировки. И даже проверял на контролируемых хостингах на разных антивирусах, что всё происходит корректно, без модификации кода.
Насчёт паранойи пошутил, нужно было проверить корректность подмены сертификата.
Вот вот, не знаю как коллегам обьяснить, как я с 21 лет стажа работы с бсд и линуксом до сих пор сижу на винде на рабочей станции. А потому что заморочек не нужно, и всё работает. А дома линукс чисто для души, ибо я по своему опыту знаю, обновление версий дистрибутива легко превращает всё в тыкву. Плюс современные интерфейсы не нравятся. Гном сам по себе неудобный, даже плагинами не исправить, kde не лучше. Идеальный был kde3 после него неинтересен десктоп
Приобрёл c пару лет назад Dell Vostro 3580, изначально шёл с Ubuntu 18.04. Основная беда у меня с ним возникла с настройкой DPI для fullHD. Из коробки очень мелко, Gnome Tweaks давал только мыло на картинке, не спасла даже замена матрицы на IPS (родная TFT очень отвратительного качества). Вторая проблема возникла с модулем Wifi, он отказывался просыпаться после гибернации, тут было 50 на 50, либо проснётся, либо нет. И только ребут, что жутко бесило.
В поисках решения с DPI перебрал с десяток дистрибутивов, пока не добрался до Fedora на тот момент 29. Проблема ушла сразу, больше никакого мыла на экране. С просыпанием wifi модуля правда только в прошлом году что-то пофиксили, то ли ядро обновилось, то ли после апгрейда всей системы.
После очередного обновления федоры пару месяцев назад ноут превратился в тыкву, загрузил ubuntu 20.04, и опять это мыло на экране, либо чтение с лупой и спящий wifi. Я даже не знаю как это обьяснить, с одной стороны экспериментальная сущность федоры, с другой стороны попсовость убунты, но по моему опыту, с федорой на десктопе намного меньше проблем, чем с ubuntu
Вылезли все четыре годам к 20-25ти, три нормально, но четвёртый это было больно, десну прорезал очень долго. Два года назад почти друг за другом оба левых съел кариес, пришлось удалить. И оказалось очень даже жевательные были, сейчас на этой стороне не очень хорошо жевать получается. И ни одной пломбы не было и нет на них, в отличии от соседних, вторых моляров.
Единственное, нужно ещё добавить в правила форвардинга трафик контейнеров, и маскарадинг. Без этого действительно сеть в контейнерах сломается
Что-то типа такого:
Ну вот, собственно, это и причиняет неудобства. Я не совсем корректно выразился, что хотел сказать. С этим разобрался, конечно, с флагами, но то что пишется всё в одну кучу, не айс. Смешались в кучу, люди, кони, и всё другое. Это нехорошо. И всё равно, даже есть такая возможность, на основной процесс, который рулит всей системой, вешать логирование неправильно, причём без права разделения.
Решился в итоге на обновления виртуалок с debian 7 только спустя год после выхода 8ки jessie, и в принципе не пожалел. И следом обновил совсем уж старые centos6 до centos7. Разницы конечно глобально не заметил, upstart на центоси и runit на дебиане функции свои выполняли исправно, единственное, что стало плюсом, одинаковый конфиг сервисов на любой ОС. Хотя понравилось что ушли от своеобразной системы логирования у runit, всё стало логироваться в syslog.
Но как я понимаю, что это до поры до времени, journalctl пока не повсеместно используется, пока в 10м дебиане и центос8 логи пишутся по старинке, но вот в домашней федоре уже просто грепом по файликам не пройтись, и это не очень нравится. Конечно, дело привычки, но всё же.
По стабильности, за 4 года столкнулся всего два раза что сервисы переставали отвечать на команды, не запускались, не останавливались. Оба раза помогло systemctl daemon-reexec, без дорогостоящей перезагрузки всей системы.
Из мелочей — не работает опция CapabilityBoundingSet, например CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права, решилось установкой через setcap непосредственно на бинарник.
И в итоге — по моему опыту использования как раз основная претензия к journalctl, если остальные компоненты systemd занимаются ровно тем, чем должны по идеологии PID1, на мой взгляд как раз логирование выходит за эти рамки.