Тут смотря о каких масштабах использования речь все же, да и о каких задачах.
Нередки случаи, когда счета на API за 1-2 месяца превышают стоимость A100. И я бы не сказал, что это экономия на спичках. Ну и не то, чтобы качество это плохо, просто не все могут и готовы к большим счетам за использование облачных моделей. А многим на самом деле достаточно небольших моделей для узких задач, и не надо впустую столько ресурсов тратить.
Ну и не стоит забывать про ФЗ152 и GDPR, который многих тоже ограничивает от использования онлайн сервисов, из-за чего и приходится использовать локальные сервисы.
Если речь про личное пользование, то тут и нет, и не было вопросов, облачное для личного будет в 99% случаев выгоднее. Вы не сможете один фиг утилизировать ресурсы локальных моделей, поэтому окупаемость долгая будет.
Ну можно начать с того, что на прод среду неправильный конфиг доехать и не должен вовсе, как минимум, это должно быть предварительно протестировано на препрод и\или тесте. Если все правится руками на горячую - ну тогда это вообще последняя проблема ;)
OpenTelemetry будет переполнятся память и возможно он упадет.
Ну давайте не делать из разработчиков лог-агрегаторов идиотов, пожалуйста ;)
Все подобные агрегаторы, типа Otel, Fluent-bit, Vector, Filebeat, и т.д. проектируется с учетом вероятных проблем на стороне экспортеров и такой кейс заведомо предусматривается, поэтому делается логика ограниченного буфера на диске или в памяти, при достижении лимита, в зав-сти от продукта и настроек, происходит либо очистка старых записей в буфере, либо остановка пайплайна, давая знать вышестоящим источникам об этом ( условно, если это происходит по HTTP - то дает знать при помощи кода 429 агентам ), и вышестоящие источники уже на стороне агентов верно интерпретируют это, останавливая чтение, если это возможно. Этот механизм везде называют по разному, но мне нравится backpresure - именно так можно встретить в документации Vector и Fluent-bit, например. Ну еще вот эта страница у Vector может быть интересна.
Сам тезис про единую точку отказа разбивается только лишь об тот факт, что в реальной прод нагрузке инстансов агрегаторов все же больше одного, а то и десятки, если мы говорим про сколько-нибудь заметную нагрузку highload или приближенную к нему. Если же у вас нагрузка настолько микроскопическая, что вам достаточно одного агрегатора, то скорее всего он вам и не нужен действительно ;)
Если при ресенде будет ошибка(а тг любит иногда кидать 400ку), либо инет моргнет, то как потом понять, что именно надо переотправить. Ну окей залогируем мы. А если мы пропустим ошибку и чухнемся через неделю только? ;)
В чем преимущество Cisco/Mikrotik перед Keenetic в стандартных домашних консюмерских условиях, если мы не строим сеть для маленькой soho компании внутри дома на 100500+ девайсов в нескодьких vlanах с отдельной стойкой под сервера/nas?
На самом деле, Keenetic полностью закрывает этот вопрос даже в этом кейсе, и его хватит надолго. Ну ладно, я бы может и поставил микрот в кач-че маршрутизаторов, но в качестве точек доступа оставил бы кинетик, все таки в ТД wifi довольно важный компонент, в микротах он остается до сих пор для галочки, со своими приколами.
По поводу ZigBee - никто ж не запрещает использовать несколько стандартов. Почему то и дело люди хотят крутиться в узком кругу технологий.
Как правило самые "вкусные" и качественные устройства идут от глобальных игроков, которые объединяются в каком-то решении.
... И делают вендорлок на себе с возможностью управления только из своих приложений/google/apple/Amazon без возможности нормально прокинуть девайс в сторонние системы УД. Благо с приходом matter стало попроще, с zvawe вот зоопарк вендорлока удручал.
Напишите, пожалуйста, эти вкусные устройства, может я все время ищу не то, и не там ....
Как мне кажется, во всем этом главное не уходить в крайности и, в том числе, не доводить аргументы и контраргменты до абсурда.
В самой статье как раз нет речи о запрете, речь идёт о разумном и правильном использовании инструмента. И в комментариях нет речи о запрете, есть лишь отчасти оправданный пессимизм в бездумном использовании ИИ. Вы же сами для себя придумали соломенное чучело в виде запрета и попытались его разбить довольно необычными аналогиями с доведением до абсурда. Тут даже спорить не с чем.
А что будут делать ваши дети, если родители их сверстников смогут адаптировать такой инструмент как ии, чтобы они быстрее и эффективнее развивались?
Да, именно. Ключевое именно в адаптации инструмента для целей быстрого и эффективного развития, именно в этом вывод и статьи, и это разделяют большинство хабравчан. Но как показывает сегодняшняя действительность, пока мало кто об этом задумывается из родителей. Бездумное решение домашних заданий через ИИ, даже без осознания и вдумчивого чтения ответа - это сейчас повсеместная практика. И вот это как раз плохо и именно на это и надо обратить внимание. Не запрещать, а именно научиться с этим работать, но чтобы и не отупеть самому. И, опять же, именно об этом в статье и речь!
Нет, конечно, некоторая доля людей, конечно, будет использовать как инструмент, попытаются извлечь из этого пользу для обучения.
Но в массе своей такого не будет, пока существует вариант решения текущих задач более простым путем. Пока есть возможность получить сразу ответ на свой вопрос и не думать над ним - никто сам не будет специально усложнять себе жизнь.
Со смартфонами у детей такая же ситуация. Лишь для единиц смартфон это инструмент с огромным массивом интересных и полезных данных, для чтения книг и пр. Для основной массы же сейчас смартфон это видосики и тиктоки посмотреть, да початиться. Причем даже про поисковик не все в курсе, доходит до абсурда, вместо гугления чего-то люди спрашивают в чатиках.
К полному атрофированию не привело, как и ИИ не приведет. Тут и нет речи о деградации в ноль, глупо этого ожижать. Речь идёт о значительной негативной тенденции.
С ТС же было бы справедливым отметить тот факт, что время физической активности у среднего жителя действительно критически снизилось и продолжает довольно активно снижаться. Даже если смотреть небольшой отрезок времени, по оценке ВОЗ доля взрослого населения планеты с дефицитом физ.активности с 2010 по 2022 год выросла с 26% до 31% и к 2030 году достигнет 35% оценочно. Тенденция довольно таки серьезная.
Ну и надеюсь не надо пояснять, что дефицит физ.активности в свою очередь приводит к значительному ухудшению качества жизни человека, и по многим исследованиям косвенно, но заметно влияет и на продолжительность самой жизни ( в частности, восстановление после травм, операций, и тд )
Но само это действие уже будет вызывать подозрение.
Увы, не будет. Мы, как пользователи, этого и не увидим. Вот есть текущий единый эндпоинт, через него начали лить ещё другого типа данные. И все. Так и остался один эндпоинт. Чтобы увидеть разницу нам, из доступного, нужна историческая статистика трафика при использовании, но и то, не факт, что поможет - телеметрия на фоне полезных данных может быть в микрооъемах.
Если речь идёт про нормальную сеть работадателя, а не проходной двор, именуемый рабочим wifi, то, как правило, любой незарегистрированный mac адрес, включая частный мак, идёт куда подальше ввиду отсутствия его в arp. Поэтому сотруднику обычно говорят, что требуется явно отключать такие штуки для рабочей сети.
К тому же, факт использования этого частного мака вполне легко и непринужденно устанавливается, даже домашними роутерами, при необходимости все попытки частного мака тоже можно заблочить отдельно.
Ну и ниже тоже правильно подметили, чаще в последнее время можно встретить уникальный логин/пароль или captive portal. То есть ваш сколь угодно рандомный мак будет явно связан с вами. Хоть обменяйиесь до потери пульса
Но вы всегда можете продолжать спорить об уникальности с вики и с кучей компьютерной литературой, конечно. Конечно же они все дураки и не правы.
То, что возможна его рандомищация (частный мак) или установка вручную, не отменяет его свойства в обычных условиях по умолчанию, буквально требований для нормальной работы. Да и рамках одной нормально работающей сети мак будет уникален всегда. Ну банально потому, что если будет в сети два девайса с одним маком, то работать нормально из них не будет никто, проблемы то у одного, то у второго.
центральные хранилки точно также позволяют скачать логи которые можно грепать.
Если у вас есть центральная хранилка, то зачем вам их скачивать тогда тогда? Чтобы что?
скачать всю необходимую информацию с сотни хостов - вообще не проблема
Ну вообще это проблема. Если мы говорим про сколько-нибудь большое решение, а не hello world ( а если у нас сотня другая хостов, то это и подразумевается ), то логи могут ротироваться так быстро, что запись, сделанная сейчас, уже будет отсутствовать через пару часов, а то и раньше. Собственно, это одна из проблем, которую закрывает центральная хранилка.
Нет, ну вы, конечно, можете подкинуть на каждый из хостов бесконечный диск чисто для логов ( бесконечной скоростью чтения и записи ), а еще бесконечный сетевой канал, чтобы вытягивать эти гигабайты лог-файлов за вменяемое количество времени в моменте, а не к концу SLA в 4 часа для решения инцидента.... Я бы посмотрел.
Возвращаясь к "во-первых" - на таких объемах пользоваться грепом будет уже довольно больновато, знаете ли.
Нет, я не спорю, для 1-3 серваков проще юзать греп, и не ставить ради них отдельную центральную логохранилку, ибо это оверхед, особенно, если ELK. Но если честно, я таких уже довольно давно не видел в промышленной эксплуатации. И в посте, знаете ли, тоже не мелкая компания.
А скрипты для вытягивания это все от луковаого, кстати. Хуже вариантов я еще не слышал)
Спойлер, с выбором инструмента бекенда у людей, как правило, и нет проблем, тут выбор не особо большой вообще.
Проблемы возникают на более ранних этапах, на этапе выбора стандартов, форматов логов, формате метрик, что там модно у трейсов и прочие вопросы. А ещё не всегда все команды вообще готовы подпиливать приложения, чтобы отдавать в наиболее удобном и модном формате, виде, структуре. Сейчас благо есть Otel, если с нуля все собирать решение наблюдаемости или наводить порядок в текущем, то направление очевидно. А если вы просто льёте зоопарк в озеро разрозненных данных - тут вообще без разницы, какой у вас инструмент будет, ибо везде будет не очень обсервабилити :)
Но я это к чему вообще... ни openobserve, ни splunk, ни datadog, ни elk - не являются волшебной пилюлей, все делающей за вас, к сожалению.
базы в Kubernetes (k8s) — сложные, ненадёжные и их неудобно поддерживать. Но я считаю, что это не так. Если систему немного «допилить», то результат точно окупится: бизнес будет расти и масштабироваться быстрее.
Вопрос не в удобстве или ненадежности. По моему мнению, основная и довольно весомая проблема баз в кубере - вам нужен не просто хороший DBA, а хороший DBA с опытом внедрения и эксплуатации БД в K8S. K8S так или иначе привносит свои нюансы работы в систему, дополнительные абстракции, о которых DBA должен знать и помнить. Ну типа вы понимаете проблему для большинства компаний? DBA и так толковых не найдешь, а тут ещё таких.
Это у вас вот есть целый DBaaS, вы можете себе позволить такое, команда как раз и нацелена решать именно такие вопросы. Но DBaaS ну вот вообще не везде есть, не все могут такое себе позволить. Не все компании размером с Авито.
Запихнуть то базу as is в кубер - это то без проблем, вот вообще без проблем. А вот что делать при проблемах, что делать с тонкими настройками у конкретной компании.
Что-то так сумбурно написано, что я даже не вник, а о чем статья-то? Что за боты, что за ПФ, причем тут открытые порты.. Помогите..
Эх, мечты мечты ..
Тут смотря о каких масштабах использования речь все же, да и о каких задачах.
Нередки случаи, когда счета на API за 1-2 месяца превышают стоимость A100. И я бы не сказал, что это экономия на спичках. Ну и не то, чтобы качество это плохо, просто не все могут и готовы к большим счетам за использование облачных моделей. А многим на самом деле достаточно небольших моделей для узких задач, и не надо впустую столько ресурсов тратить.
Ну и не стоит забывать про ФЗ152 и GDPR, который многих тоже ограничивает от использования онлайн сервисов, из-за чего и приходится использовать локальные сервисы.
Если речь про личное пользование, то тут и нет, и не было вопросов, облачное для личного будет в 99% случаев выгоднее. Вы не сможете один фиг утилизировать ресурсы локальных моделей, поэтому окупаемость долгая будет.
Ну можно начать с того, что на прод среду неправильный конфиг доехать и не должен вовсе, как минимум, это должно быть предварительно протестировано на препрод и\или тесте. Если все правится руками на горячую - ну тогда это вообще последняя проблема ;)
Ну давайте не делать из разработчиков лог-агрегаторов идиотов, пожалуйста ;)
Все подобные агрегаторы, типа Otel, Fluent-bit, Vector, Filebeat, и т.д. проектируется с учетом вероятных проблем на стороне экспортеров и такой кейс заведомо предусматривается, поэтому делается логика ограниченного буфера на диске или в памяти, при достижении лимита, в зав-сти от продукта и настроек, происходит либо очистка старых записей в буфере, либо остановка пайплайна, давая знать вышестоящим источникам об этом ( условно, если это происходит по HTTP - то дает знать при помощи кода 429 агентам ), и вышестоящие источники уже на стороне агентов верно интерпретируют это, останавливая чтение, если это возможно. Этот механизм везде называют по разному, но мне нравится backpresure - именно так можно встретить в документации Vector и Fluent-bit, например. Ну еще вот эта страница у Vector может быть интересна.
Сам тезис про единую точку отказа разбивается только лишь об тот факт, что в реальной прод нагрузке инстансов агрегаторов все же больше одного, а то и десятки, если мы говорим про сколько-нибудь заметную нагрузку highload или приближенную к нему. Если же у вас нагрузка настолько микроскопическая, что вам достаточно одного агрегатора, то скорее всего он вам и не нужен действительно ;)
Для надежности.
Если при ресенде будет ошибка(а тг любит иногда кидать 400ку), либо инет моргнет, то как потом понять, что именно надо переотправить. Ну окей залогируем мы. А если мы пропустим ошибку и чухнемся через неделю только? ;)
Почему завтра? По данным всемирного банка, пингвины уже не первый год торгуют с США и импортируют в США на миллионы долларов каждый год.
https://wits.worldbank.org/CountryProfile/en/Country/USA/Year/LTST/TradeFlow/EXPIMP/Partner/HMD/Product/All-Groups
К сожалению, да. Если "аналитики" не дошли до настолько банальных данных, то грош цена выводам этих аналитиков.
В чем преимущество Cisco/Mikrotik перед Keenetic в стандартных домашних консюмерских условиях, если мы не строим сеть
для маленькой soho компании внутри домана 100500+ девайсов в нескодьких vlanах с отдельной стойкой под сервера/nas?На самом деле, Keenetic полностью закрывает этот вопрос даже в этом кейсе, и его хватит надолго. Ну ладно, я бы может и поставил микрот в кач-че маршрутизаторов, но в качестве точек доступа оставил бы кинетик, все таки в ТД wifi довольно важный компонент, в микротах он остается до сих пор для галочки, со своими приколами.
По поводу ZigBee - никто ж не запрещает использовать несколько стандартов. Почему то и дело люди хотят крутиться в узком кругу технологий.
... И делают вендорлок на себе с возможностью управления только из своих приложений/google/apple/Amazon без возможности нормально прокинуть девайс в сторонние системы УД. Благо с приходом matter стало попроще, с zvawe вот зоопарк вендорлока удручал.
Напишите, пожалуйста, эти вкусные устройства, может я все время ищу не то, и не там ....
Как мне кажется, во всем этом главное не уходить в крайности и, в том числе, не доводить аргументы и контраргменты до абсурда.
В самой статье как раз нет речи о запрете, речь идёт о разумном и правильном использовании инструмента. И в комментариях нет речи о запрете, есть лишь отчасти оправданный пессимизм в бездумном использовании ИИ. Вы же сами для себя придумали соломенное чучело в виде запрета и попытались его разбить довольно необычными аналогиями с доведением до абсурда. Тут даже спорить не с чем.
Да, именно. Ключевое именно в адаптации инструмента для целей быстрого и эффективного развития, именно в этом вывод и статьи, и это разделяют большинство хабравчан. Но как показывает сегодняшняя действительность, пока мало кто об этом задумывается из родителей. Бездумное решение домашних заданий через ИИ, даже без осознания и вдумчивого чтения ответа - это сейчас повсеместная практика. И вот это как раз плохо и именно на это и надо обратить внимание. Не запрещать, а именно научиться с этим работать, но чтобы и не отупеть самому. И, опять же, именно об этом в статье и речь!
Не смогут.
Нет, конечно, некоторая доля людей, конечно, будет использовать как инструмент, попытаются извлечь из этого пользу для обучения.
Но в массе своей такого не будет, пока существует вариант решения текущих задач более простым путем. Пока есть возможность получить сразу ответ на свой вопрос и не думать над ним - никто сам не будет специально усложнять себе жизнь.
Со смартфонами у детей такая же ситуация. Лишь для единиц смартфон это инструмент с огромным массивом интересных и полезных данных, для чтения книг и пр. Для основной массы же сейчас смартфон это видосики и тиктоки посмотреть, да початиться. Причем даже про поисковик не все в курсе, доходит до абсурда, вместо гугления чего-то люди спрашивают в чатиках.
К полному атрофированию не привело, как и ИИ не приведет. Тут и нет речи о деградации в ноль, глупо этого ожижать. Речь идёт о значительной негативной тенденции.
С ТС же было бы справедливым отметить тот факт, что время физической активности у среднего жителя действительно критически снизилось и продолжает довольно активно снижаться. Даже если смотреть небольшой отрезок времени, по оценке ВОЗ доля взрослого населения планеты с дефицитом физ.активности с 2010 по 2022 год выросла с 26% до 31% и к 2030 году достигнет 35% оценочно. Тенденция довольно таки серьезная.
Ну и надеюсь не надо пояснять, что дефицит физ.активности в свою очередь приводит к значительному ухудшению качества жизни человека, и по многим исследованиям косвенно, но заметно влияет и на продолжительность самой жизни ( в частности, восстановление после травм, операций, и тд )
Увы, не будет. Мы, как пользователи, этого и не увидим. Вот есть текущий единый эндпоинт, через него начали лить ещё другого типа данные. И все. Так и остался один эндпоинт. Чтобы увидеть разницу нам, из доступного, нужна историческая статистика трафика при использовании, но и то, не факт, что поможет - телеметрия на фоне полезных данных может быть в микрооъемах.
Утопично, но в целом, звучит хорошо
Если речь идёт про нормальную сеть работадателя, а не проходной двор, именуемый рабочим wifi, то, как правило, любой незарегистрированный mac адрес, включая частный мак, идёт куда подальше ввиду отсутствия его в arp. Поэтому сотруднику обычно говорят, что требуется явно отключать такие штуки для рабочей сети.
К тому же, факт использования этого частного мака вполне легко и непринужденно устанавливается, даже домашними роутерами, при необходимости все попытки частного мака тоже можно заблочить отдельно.
Ну и ниже тоже правильно подметили, чаще в последнее время можно встретить уникальный логин/пароль или captive portal. То есть ваш сколь угодно рандомный мак будет явно связан с вами. Хоть обменяйиесь до потери пульса
Ну вообще соответствует.
Но вы всегда можете продолжать спорить об уникальности с вики и с кучей компьютерной литературой, конечно. Конечно же они все дураки и не правы.
То, что возможна его рандомищация (частный мак) или установка вручную, не отменяет его свойства в обычных условиях по умолчанию, буквально требований для нормальной работы. Да и рамках одной нормально работающей сети мак будет уникален всегда. Ну банально потому, что если будет в сети два девайса с одним маком, то работать нормально из них не будет никто, проблемы то у одного, то у второго.
Поясните про интерфейсы.
Если у вас есть центральная хранилка, то зачем вам их скачивать тогда тогда? Чтобы что?
Ну вообще это проблема. Если мы говорим про сколько-нибудь большое решение, а не hello world ( а если у нас сотня другая хостов, то это и подразумевается ), то логи могут ротироваться так быстро, что запись, сделанная сейчас, уже будет отсутствовать через пару часов, а то и раньше. Собственно, это одна из проблем, которую закрывает центральная хранилка.
Нет, ну вы, конечно, можете подкинуть на каждый из хостов бесконечный диск чисто для логов ( бесконечной скоростью чтения и записи ), а еще бесконечный сетевой канал, чтобы вытягивать эти гигабайты лог-файлов за вменяемое количество времени в моменте, а не к концу SLA в 4 часа для решения инцидента.... Я бы посмотрел.
Возвращаясь к "во-первых" - на таких объемах пользоваться грепом будет уже довольно больновато, знаете ли.
Нет, я не спорю, для 1-3 серваков проще юзать греп, и не ставить ради них отдельную центральную логохранилку, ибо это оверхед, особенно, если ELK. Но если честно, я таких уже довольно давно не видел в промышленной эксплуатации. И в посте, знаете ли, тоже не мелкая компания.
А скрипты для вытягивания это все от луковаого, кстати. Хуже вариантов я еще не слышал)
Ставить можно, все, что душе угодно ;)
Спойлер, с выбором инструмента бекенда у людей, как правило, и нет проблем, тут выбор не особо большой вообще.
Проблемы возникают на более ранних этапах, на этапе выбора стандартов, форматов логов, формате метрик, что там модно у трейсов и прочие вопросы. А ещё не всегда все команды вообще готовы подпиливать приложения, чтобы отдавать в наиболее удобном и модном формате, виде, структуре. Сейчас благо есть Otel, если с нуля все собирать решение наблюдаемости или наводить порядок в текущем, то направление очевидно. А если вы просто льёте зоопарк в озеро разрозненных данных - тут вообще без разницы, какой у вас инструмент будет, ибо везде будет не очень обсервабилити :)
Но я это к чему вообще... ни openobserve, ни splunk, ни datadog, ни elk - не являются волшебной пилюлей, все делающей за вас, к сожалению.
А к самому openobserve вопросов нет ;)
Я не против грепа, конечно, но грепать вы предлагаете вручную на сотне хостов, без использования центральных хранилок? Или что вы тут подразумеваете?
Я бы кстати послушал опыт Oracle в k8s
Вопрос не в удобстве или ненадежности. По моему мнению, основная и довольно весомая проблема баз в кубере - вам нужен не просто хороший DBA, а хороший DBA с опытом внедрения и эксплуатации БД в K8S. K8S так или иначе привносит свои нюансы работы в систему, дополнительные абстракции, о которых DBA должен знать и помнить. Ну типа вы понимаете проблему для большинства компаний? DBA и так толковых не найдешь, а тут ещё таких.
Это у вас вот есть целый DBaaS, вы можете себе позволить такое, команда как раз и нацелена решать именно такие вопросы. Но DBaaS ну вот вообще не везде есть, не все могут такое себе позволить. Не все компании размером с Авито.
Запихнуть то базу as is в кубер - это то без проблем, вот вообще без проблем. А вот что делать при проблемах, что делать с тонкими настройками у конкретной компании.
>> Решил не продолжать тест, так как он выбивается за рамки "по-быстрому"
Добавление буквально 4 строчек в docker-compose, очевидно, довольно долгое занятие ;)