Это вы так за весь мир решили? Потому что от страны к стране может отличаться позиция. Но даже если рассматривать психологию со стороны математически-статистической дисциплины - это как то нивелирует проблему или делает исследования недействительными?
Лично я полагаю, что для того, что бы родители начали чему то учить детей, они должны сами хоть немного разбираться в том, чему они учат. Интернет меняется быстро, не факт что родители на себе познали то, с чем может столкнуться их ребенок. К сожалению люди не идеальны и не думаю, что прям очень большое кол-во родителей читает подборку научных статей по детской психологии. А фоновый шум из "телека" по типу "Социальные сети опасны для ваших детей, оградите их от социальных сетей" большинством воспринимается именно как фоновый шум.
Да, это уже проблема. На текущий момент наука полагает, что структуры мозга отвечающие за самоконтроль и чувствительность к социальному одобрению окончательно формируются к 21-25 годам, а дофаминовые механики соцсетей (лайки, бесконечная лента и тд) перегружают систему вознаграждения у детей. В PMC11641642 можно почитать как коррелирует частое использование социальных сетей школьниками и снижение у них самооценки, расстройством сна и симптомами социафобии.
Ну да, как я мог забыть, что детскую психологию могут изучать только дети, она же детская :) А если серьезно то как и во взрослой, через наблюдения, эксперименты и нейробиологию.
Это обязанность родителей и прочих родственников - учить, объяснять.
Есть небольшой нюанс, что бы чему то учить и объяснять - нужно разбираться в проблеме. И вот тут и кроется сложность - интернет меняется, меняется очень быстро и у родителей не факт что есть опыт, который они могут передать ребенку или что они нормально смогут понять проблему ребенка. Конечно базовые вещи вечны, но вот как взрослый сможет понять проблему влияния соцсетей, не читая выводы психологов на эту тему и профильные исследования - мне не понятно. А как много родителей будет это делать?
Должен - сам, себе и для себя!
Да да, ведь люди ответственные, логичные и последовательные разумные. Особенно дети!
А как вы это определили? Вы можете ознакомиться с исследованиями по влиянию тех же соцсетей на детей (раз, два, три) на самом деле их, исследований, много больше. То есть как минимум от детей интернет нужно регулировать.
Там не требуется игровой компьютер, хватает простого ноутбука. Но да, DMA может стоить в районе 400$ только за железо (без ноутбука) + еще подписка на читы :) Такие читы могут покупаться, что бы зарабатывать на этом, допустим предоставляя услуги "сопровода", популярно в экстракшен шутерах. 1 или 2 читера берут в группу покупателя, убивают всех на карте, покупатель лутает всю карту и всех противников. Еще DMA популярны у стримеров, так как с помощью такого чита можно легко на второй монитор вывести радар и как правило этого достаточно для успешной "скиловой" игры.
Если это нужно только мне, то я не вижу смысла заводить себе систему DNS. Ибо нет разницы, буду я менять его у себя локально или на dns сервере, который ещё поддерживать нужно будет.
Да, только то, что нравится лично вам и что является плохими практиками, вы тащите на хабр в статью. И разница есть. У вас «локально работает» только на конкретном экземпляре вашего компьютера, dns же будет работать даже если вам потребуется что то сделать в отпуске с кофеварки.
Возможно, я просто рассуждаю, этот сценарий и ваша убежденность в удобстве своего подхода родились из того, что эти сервера не являются вашей основной работой и вам не нужно их поддерживать на постоянной основе.
DNS это не так сложно. Хостинги DNS (AWS, Yandex Cloud) стоят не так дорого. К примеру в Yandex Cloud это примерно 44 рубля за зону(домен) в месяц и 38 рублей за 1 млн запросов к записям. Одного домена как правило достаточно.
Ansible же это не только про менять, редко или часто, конфигурацию на сервере. Это история про идемпотентность, то есть если вы 1 раз настроили какую то роль в ansible и далее простым действием раскатали эту роль на N серверов и вы будете уверены в том, что на все сервера конфигурация встало одинаково.
Вы же сами писали про большое кол-во серверов, имхо на масштабах, когда вы уже не помните, где и что у вас на серверах, жить без нормальных инструментов - это очень сильно не любить себя и свое время.
Вы тут пишете про нейминг и тд, и вот вроде это правильная мысль, только решение вы максимально убогое предложили. Даже ssh config будет не идеальным решением, потому что вы можете пересесть на другой компьютер где не будет вашего hosts и возможно config. Используйте нормально dns. А еще лучше используйте ansible, нечего руками по серверам ползать, что бы потом не удивляться откуда конфигурационный дрифт появился.
Автовазу от утиля ни горячо ни холодно. Основной заказчик государство, которое хочет, что хоть кто то пришел (китайцы) и загрузил производство простаивающих заводов (привет москвич и волга).
Ключевое различие между APM и набором open‑source инструментов кроется в архитектуре данных. APM‑решения изначально построены на концепции унифицированной наблюдаемости — единой платформы, где трассировки, метрики и логи существуют в общем контексте.
Ну если вы посмотрите на то, что в последнее время делает Grafana - они пришли к этому в облаке у себя и продвигают этот подход в своих OSS решениях.
Когда в продакшене падает микросервис, инженеру с APM не нужно открывать три разных вкладки: Grafana для графиков контейнеров, Jaeger для поиска трейсов и Kibana для чтения логов.
Пример конечно жизненный, но это говорит не о преимуществах или недостатках той или иной системы, а о том, что в компании нет культуры построения observability и/или нет экспертизы в этой области. Но даже если немного задуматься, то достаточно поставить полный elastic стек, что бы получить все из коробки.
И вот тут, уже, лично мое мнение, место для сравнения, потому что elastic (elasticsearch + kibana + (metrics|file)beats + apm server + logstash + apm agent) vs grafana стек (grafana + tempo + alloy + mimir + loki + opentelemetry collector + faro + opentelemetry agent) vs ваше решение, оно не только разное по стоимости настройки, оно еще и разное по стоимости владения (аренда вычислительных мощностей), ничего не знаю про ваше решение но мой опыт говорит, что Elastic быстрее внедряется но дороже во владении, так как дороже по стоимости хранения данных. OSS стек от Grafana + Opentelemetry дольше по внедрению, но дешевле во владении, так как все решения Grafana заточены на хранение данных в S3. А как у вас с этим?
Связность данных в этом случае становится отдельной инженерной задачей. А что делать с вендорскими продуктами, легаси системами? Как тут подключить и забрать Prometheus? Как внедрить trace id без доступа к коду?
Вы написали это в контексте минусов open-source решений, но простите, а какой эльфийской магией вы собираетесь это делать? Что такого особенного в вашем продукте, что не сможет Elastic APM агенты или Opentelemetry агенты которыми в ряде случаев можно обернуть вендорское приложение?
С открытым стеком (например, Prometheus + Grafana + Loki + Tempo) такая связка возможна, но требует серьёзных усилий по настройке. Нужно вручную настраивать проброс trace_id во все компоненты логирования, следить за совместимостью версий и писать специфические запросы PromQL/LogQL.
А можно уточнить, в чем конкретно сложность? В Java для logback это 5 строчек xml конфигурации, для Log4j2 и spring boot одна строчка, для .NET так же просто. Если в nodejs приложении используется pino то, добавить в логи traceid - 3 строчки кода. opentelemetry агенты весьма неплохо прокачались за последнее время. Но в любом случае, если у вас большая команда, много проектов, куча микросервисов, вам придется настраивать логирование, хотя бы для того, что бы придти к единому формату логов, что бы в мониторинге любой человек мог читать лог единообразно и работали общие правила парсинга таких логов.
Давайте посмотрим на классический путь разбора инцидентов при использовании open‑source решений и APM.
Ну явное же передергивание. Если система настроена нормально и есть процессы внутри команд, то почему оно должно бы так? :) Никакое внедрение коммерческого APM решения, магическим образом не выделит ответственных и не наладит процессы разбора инцидентов. Только если в комплекте с APM коробкой идет консалтинг на тему того "делайте хорошо, а плохо не делайте".
При этом не требуется сбор сотрудников с лозунгом «горит!» для совместного разбора. Исправлять ситуацию будут только ответственные.
Ага, а если ИИ ошибся?
Ну, и давайте посмотрим на условные цифры статистики по инциденту — в разборе участвовало 5 сотрудников, затронуто 500 клиентов, время решения — 15 минут. Массовый сбой предотвращен.
Это вообще к чему? Где вводные? Где подробное описание инцидента? Просто цифры из воздуха, именно такие абзацы и создают ощущение "булшита для менеджеров".
Здесь разрыв наиболее очевиден. Установка open‑source — это инженерная задача, которая может затянуться на спринт или даже месяц, особенно в условиях строгих compliance‑требований.
Для разворачивания APM нужно установить один агент на хост или подключить библиотеку в приложение. Современные платформы предлагают zero‑touch instrumentation — технологию, которая автоматически обнаруживает сервисы, базы данных и очереди, начиная собирать данные без правок конфигурационных файлов вручную. В течение нескольких часов после подключения вы получите полноценную карту сервисов и дашборды.
Простите, я не РФ живу и не вижу ваш сайт, у вас облако? Если у вас облако, то жестких требований по compliance у клиентов не возникнет? Ну для проверки гипотез, поставить Tempo + Loki и в графане настроить связывание trace id между логами и трейсами - это как бы задача на вечер. Да, если вы строите большую, сложную систему с кучей микросервисов, это может быть задачей, так как надо спланировать ресурсы, лимиты по тенантам и тд. но это может быть постепенным процессом.
По сути, команда берет на себя роль вендора. И нужно собирать и формировать команду прямо под весь стек open‑source, в итоге штат дорогих специалистов «пухнет».
Вот не согласен. Тут зависит от размеров компании и организации, если у вас большая компания и много команд разработки скорее всего у вас так и так сформирована отдельная команда observability, которая владеет инфраструктурой как продуктом и предоставляют инструменты продуктовым командам, которые уже отвечают за метрики своего домена, за свои дашборды, свои SLO, on-call и тд, возможно немного в стороне сформирован SRE консалтинг. Если компания небольшая, то observability это часть инфраструктуры которой владеет devops/платформенный инженер. Но все равно, каждая продуктовая команда так или иначе отвечает за наблюдаемость своих сервисов (метрики, алерты и тд)
Стоимость APM‑платформ — это прямые и понятные затраты «здесь и сейчас». С открытым исходным кодом расходы распределены по времени и менее очевидны, например, зарплата высококвалифицированных специалистов, время на внедрение, поддержку и последующую адаптацию. При этом эффект от использования APM заметен на этапе диагностики инцидентов — сокращается время на поиск причин, а значит и восстановление системы ускоряется.
Если решение облачное - то это зависит от модели ценообразования. Если как в Grafana Cloud то вот вообще не факт, так как стоимость там привязана к кол-ву логов, метрик и может расти нелинейно. Если же модель как у Elasticsearch Cloud то немного проще, но надо внимательно следить за местом на горячих и холодных нодах, так как elastic очень прожорливый до места. Я понимаю, что вы пишете про свое решение, но как писал выше нет возможности зайти на ваш сайт. У вас же там есть открытые цены, да? :)
Проблема обновлений. Выход новой мажорной версии Kubernetes или миграция с Ingress на Gateway API могут сломать самописные экспортеры Prometheus. Нужно следить за changelog'ами десятков утилит (kube‑state‑metrics, node‑exporter, promtail), своевременно обновлять Helm‑чарты и тестировать совместимость на staging‑окружении. Это время, которое senior‑инженеры тратят не на разработку продукта, а на обслуживание инфраструктурной «сантехники».
Я не понимаю, о ком идет тут речь. Вы про роль devops или разработчика? Если про разработчика, то как бы не его задачи и за чем он должен следить в любом случае, это за версией APM агента, но она по уровню совместимости как правило привязана к версии фреймворка который используется. Если же речь про devops роль, то про какую разработку продукта речь?
Статья в первую очередь для тех, кто уже сталкивался с мониторингом на практике — собирал стек на open-source или разбирал инциденты в проде.
Лично мое мнение, что статья больше похожа на шаблонный булшит для менеджеров, то есть это возможно неплохая статья что бы ссылаться на нее для пред-продажной коммуникации, но на техническом ресурсе выглядит откровенно слабо и много передергиваний.
Ну есть ФЗ 152, и РФ тут как бы не первые, Европа с их GDPR как пример, Индия с DPDP, Китай PIPL / CSL и тд и тп. С точки зрения граждан, подобные законы должны предоставлять "право на забвение", а так же возможность запросить информацию о том, как и кто обрабатывает ваши персональные данные и предоставить возможность отзыва разрешений на эту обработку. В случае если данные хранятся в юрисдикции другой страны, это сделать сложнее.
С точки зрения государства, это доп. стимуляция рынка ИТ (хранение данных, должности ответственных за безопасность данных и тд), приземление зарубежных компаний локально в стране, необходимость заводить там дочерние компании, открывать офисы и тд и тп., ну и, конечно, средство давления и контроля. Опять же, в случае вопросов у органов, намного проще придти в локальный офис, чем долго переписываться с офисом находящемся в другой стране. РФ тут не уникальны, не первые и не последние.
Это вы так за весь мир решили? Потому что от страны к стране может отличаться позиция. Но даже если рассматривать психологию со стороны математически-статистической дисциплины - это как то нивелирует проблему или делает исследования недействительными?
Нейробиология и несколько отраслей психологии
Лично я полагаю, что для того, что бы родители начали чему то учить детей, они должны сами хоть немного разбираться в том, чему они учат.
Интернет меняется быстро, не факт что родители на себе познали то, с чем может столкнуться их ребенок. К сожалению люди не идеальны и не думаю, что прям очень большое кол-во родителей читает подборку научных статей по детской психологии. А фоновый шум из "телека" по типу "Социальные сети опасны для ваших детей, оградите их от социальных сетей" большинством воспринимается именно как фоновый шум.
Да, это уже проблема. На текущий момент наука полагает, что структуры мозга отвечающие за самоконтроль и чувствительность к социальному одобрению окончательно формируются к 21-25 годам, а дофаминовые механики соцсетей (лайки, бесконечная лента и тд) перегружают систему вознаграждения у детей. В PMC11641642 можно почитать как коррелирует частое использование социальных сетей школьниками и снижение у них самооценки, расстройством сна и симптомами социафобии.
Ну тут вопрос не про воспитание, а про ограничение того, с чем не всегда взрослые то понимают как справляться.
Ну да, как я мог забыть, что детскую психологию могут изучать только дети, она же детская :)
А если серьезно то как и во взрослой, через наблюдения, эксперименты и нейробиологию.
Есть небольшой нюанс, что бы чему то учить и объяснять - нужно разбираться в проблеме. И вот тут и кроется сложность - интернет меняется, меняется очень быстро и у родителей не факт что есть опыт, который они могут передать ребенку или что они нормально смогут понять проблему ребенка. Конечно базовые вещи вечны, но вот как взрослый сможет понять проблему влияния соцсетей, не читая выводы психологов на эту тему и профильные исследования - мне не понятно. А как много родителей будет это делать?
Да да, ведь люди ответственные, логичные и последовательные разумные. Особенно дети!
А как вы это определили?
Вы можете ознакомиться с исследованиями по влиянию тех же соцсетей на детей (раз, два, три) на самом деле их, исследований, много больше.
То есть как минимум от детей интернет нужно регулировать.
Там не требуется игровой компьютер, хватает простого ноутбука. Но да, DMA может стоить в районе 400$ только за железо (без ноутбука) + еще подписка на читы :)
Такие читы могут покупаться, что бы зарабатывать на этом, допустим предоставляя услуги "сопровода", популярно в экстракшен шутерах. 1 или 2 читера берут в группу покупателя, убивают всех на карте, покупатель лутает всю карту и всех противников. Еще DMA популярны у стримеров, так как с помощью такого чита можно легко на второй монитор вывести радар и как правило этого достаточно для успешной "скиловой" игры.
Ни второй сезон, ни бесплатная неделя не спасут игру
Да, только то, что нравится лично вам и что является плохими практиками, вы тащите на хабр в статью. И разница есть. У вас «локально работает» только на конкретном экземпляре вашего компьютера, dns же будет работать даже если вам потребуется что то сделать в отпуске с кофеварки.
Возможно, я просто рассуждаю, этот сценарий и ваша убежденность в удобстве своего подхода родились из того, что эти сервера не являются вашей основной работой и вам не нужно их поддерживать на постоянной основе.
DNS это не так сложно. Хостинги DNS (AWS, Yandex Cloud) стоят не так дорого. К примеру в Yandex Cloud это примерно 44 рубля за зону(домен) в месяц и 38 рублей за 1 млн запросов к записям. Одного домена как правило достаточно.
Ansible же это не только про менять, редко или часто, конфигурацию на сервере. Это история про идемпотентность, то есть если вы 1 раз настроили какую то роль в ansible и далее простым действием раскатали эту роль на N серверов и вы будете уверены в том, что на все сервера конфигурация встало одинаково.
Вы же сами писали про большое кол-во серверов, имхо на масштабах, когда вы уже не помните, где и что у вас на серверах, жить без нормальных инструментов - это очень сильно не любить себя и свое время.
Вы тут пишете про нейминг и тд, и вот вроде это правильная мысль, только решение вы максимально убогое предложили. Даже ssh config будет не идеальным решением, потому что вы можете пересесть на другой компьютер где не будет вашего hosts и возможно config. Используйте нормально dns. А еще лучше используйте ansible, нечего руками по серверам ползать, что бы потом не удивляться откуда конфигурационный дрифт появился.
Автовазу от утиля ни горячо ни холодно. Основной заказчик государство, которое хочет, что хоть кто то пришел (китайцы) и загрузил производство простаивающих заводов (привет москвич и волга).
Ну если вы посмотрите на то, что в последнее время делает Grafana - они пришли к этому в облаке у себя и продвигают этот подход в своих OSS решениях.
Пример конечно жизненный, но это говорит не о преимуществах или недостатках той или иной системы, а о том, что в компании нет культуры построения observability и/или нет экспертизы в этой области. Но даже если немного задуматься, то достаточно поставить полный elastic стек, что бы получить все из коробки.
И вот тут, уже, лично мое мнение, место для сравнения, потому что elastic (elasticsearch + kibana + (metrics|file)beats + apm server + logstash + apm agent) vs grafana стек (grafana + tempo + alloy + mimir + loki + opentelemetry collector + faro + opentelemetry agent) vs ваше решение, оно не только разное по стоимости настройки, оно еще и разное по стоимости владения (аренда вычислительных мощностей), ничего не знаю про ваше решение но мой опыт говорит, что Elastic быстрее внедряется но дороже во владении, так как дороже по стоимости хранения данных. OSS стек от Grafana + Opentelemetry дольше по внедрению, но дешевле во владении, так как все решения Grafana заточены на хранение данных в S3. А как у вас с этим?
Вы написали это в контексте минусов open-source решений, но простите, а какой эльфийской магией вы собираетесь это делать? Что такого особенного в вашем продукте, что не сможет Elastic APM агенты или Opentelemetry агенты которыми в ряде случаев можно обернуть вендорское приложение?
А можно уточнить, в чем конкретно сложность? В Java для logback это 5 строчек xml конфигурации, для Log4j2 и spring boot одна строчка, для .NET так же просто. Если в nodejs приложении используется pino то, добавить в логи traceid - 3 строчки кода. opentelemetry агенты весьма неплохо прокачались за последнее время.
Но в любом случае, если у вас большая команда, много проектов, куча микросервисов, вам придется настраивать логирование, хотя бы для того, что бы придти к единому формату логов, что бы в мониторинге любой человек мог читать лог единообразно и работали общие правила парсинга таких логов.
Ну явное же передергивание. Если система настроена нормально и есть процессы внутри команд, то почему оно должно бы так? :) Никакое внедрение коммерческого APM решения, магическим образом не выделит ответственных и не наладит процессы разбора инцидентов. Только если в комплекте с APM коробкой идет консалтинг на тему того "делайте хорошо, а плохо не делайте".
Ага, а если ИИ ошибся?
Это вообще к чему? Где вводные? Где подробное описание инцидента? Просто цифры из воздуха, именно такие абзацы и создают ощущение "булшита для менеджеров".
Простите, я не РФ живу и не вижу ваш сайт, у вас облако? Если у вас облако, то жестких требований по compliance у клиентов не возникнет? Ну для проверки гипотез, поставить Tempo + Loki и в графане настроить связывание trace id между логами и трейсами - это как бы задача на вечер. Да, если вы строите большую, сложную систему с кучей микросервисов, это может быть задачей, так как надо спланировать ресурсы, лимиты по тенантам и тд. но это может быть постепенным процессом.
Вот не согласен. Тут зависит от размеров компании и организации, если у вас большая компания и много команд разработки скорее всего у вас так и так сформирована отдельная команда observability, которая владеет инфраструктурой как продуктом и предоставляют инструменты продуктовым командам, которые уже отвечают за метрики своего домена, за свои дашборды, свои SLO, on-call и тд, возможно немного в стороне сформирован SRE консалтинг.
Если компания небольшая, то observability это часть инфраструктуры которой владеет devops/платформенный инженер. Но все равно, каждая продуктовая команда так или иначе отвечает за наблюдаемость своих сервисов (метрики, алерты и тд)
Если решение облачное - то это зависит от модели ценообразования. Если как в Grafana Cloud то вот вообще не факт, так как стоимость там привязана к кол-ву логов, метрик и может расти нелинейно. Если же модель как у Elasticsearch Cloud то немного проще, но надо внимательно следить за местом на горячих и холодных нодах, так как elastic очень прожорливый до места. Я понимаю, что вы пишете про свое решение, но как писал выше нет возможности зайти на ваш сайт. У вас же там есть открытые цены, да? :)
Я не понимаю, о ком идет тут речь. Вы про роль devops или разработчика? Если про разработчика, то как бы не его задачи и за чем он должен следить в любом случае, это за версией APM агента, но она по уровню совместимости как правило привязана к версии фреймворка который используется. Если же речь про devops роль, то про какую разработку продукта речь?
Выше уже писал, что единый формат логов для всех продуктов - это то, что необходимо настроить в любом случае, есть у вас APM или нет.
PS: немного сумбурно написал, так как отвлекался и несколько раз возвращался к комментарию.
Лично мое мнение, что статья больше похожа на шаблонный булшит для менеджеров, то есть это возможно неплохая статья что бы ссылаться на нее для пред-продажной коммуникации, но на техническом ресурсе выглядит откровенно слабо и много передергиваний.
del
А что ваша APM система подсказывает о 404 на главной вашего сайта?
Ну и собственно хотелось бы понять, а для кого эта статья?
Ну есть ФЗ 152, и РФ тут как бы не первые, Европа с их GDPR как пример, Индия с DPDP, Китай PIPL / CSL и тд и тп. С точки зрения граждан, подобные законы должны предоставлять "право на забвение", а так же возможность запросить информацию о том, как и кто обрабатывает ваши персональные данные и предоставить возможность отзыва разрешений на эту обработку. В случае если данные хранятся в юрисдикции другой страны, это сделать сложнее.
С точки зрения государства, это доп. стимуляция рынка ИТ (хранение данных, должности ответственных за безопасность данных и тд), приземление зарубежных компаний локально в стране, необходимость заводить там дочерние компании, открывать офисы и тд и тп., ну и, конечно, средство давления и контроля. Опять же, в случае вопросов у органов, намного проще придти в локальный офис, чем долго переписываться с офисом находящемся в другой стране. РФ тут не уникальны, не первые и не последние.
Переключение с помощью caps lock спасает, это быстрее чем переносить руки на ряд с другим языком.