Это здорово, что вы думаете про мониторинг и метрики сразу.
Но точно ли вам нужно изобретать свое решение? В инфраструктуре больше одного сервера мониторинг в целом не помешает, а уж на масштабе - просто необходим, поэтому рядом с вашей платформой уже что-то будет, она же не единственная система в условной компании.
Те же ошибки HTTP логичнее собирать с балансировщиков, например.
Когда у разных команд есть один инструмент для всех частей и не нужно делать свою - обычно получается лучше.
Поддерживать одновременно два варианта, один из которых больше нигде не может использоваться - будто бы накладно, если вы и так отдаете метрики в принятом индустрией стандарте сейчас.
А потом добавляем к атакам через общий page cache большие кластеры kubernetes в каком-нибудь enterprise, с одинаковыми базовыми образами у большинства сервисов - получается совсем неприятно.
После таких вот приколов kata/firecracker/etc уже не выглядят чем-то избыточным.
Удивляет, что Canonical не озаботились защитой от DDoS для этих ресурсов. Тем более на фоне copy fail, вчера так и не смог проверить у них, вышли ли патчи.
Если есть доступ у сотрудника, то на уровне СХД (ONTAP, PowerStore, OceanProtect) до S3, можно вполне себе изменить права на ресурсе и данные вполне себе стираются
Нет, наличие административного доступа в таких СХД не позволяет уничтожить данные никаким способом, в этом их смысл - обеспечить immutable. Только физически идти и ломать оборудование.
То же самое касается внешних S3 хранилищ - compliance lock не позволяет вам отменить блокировку или уменьшить ее срок, даже если у вас есть полный доступ ко всем бакетам.
Вы пишете правильные вещи про риски и необходимость immutable storage. Но создаётся впечатление, что "настоящий" WORM - это только лента, что не так. Тем более, восстанавливаться с нуля, с перечитыванием метаданных с ленты, можно долго.
Есть много альтернатив - от реализации на уровне СХД (ONTAP, PowerStore, OceanProtect) до S3 с compliance object lock.
https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/#dashboard-permissions
Это может казаться удобным, но при деградации зависимость мониторинга от самой этой системы - это очень слабое место.
Кстати о метриках - в grafana вполне себе есть гибкое управление доступом к дашбордам.
Там будет намного больше, чем "пара" :)
Если вы целитесь и в такой сегмент - лучше сразу предусмотреть типовые потребности эксплуатации и не забывать про это.
Если ваша платформа может отдать свой статус, ещё и с детализацией, вам будут благодарны.
Пользователи - нет, а вот эксплуатация - да :)
Согласен, наличие в продукте метрик для интеграции со своим мониторингом сильно упрощает жизнь.
Обычно очень увлекательно изобретать свои велосипеды вокруг, если это не предусмотрели разработчики.
Это здорово, что вы думаете про мониторинг и метрики сразу.
Но точно ли вам нужно изобретать свое решение? В инфраструктуре больше одного сервера мониторинг в целом не помешает, а уж на масштабе - просто необходим, поэтому рядом с вашей платформой уже что-то будет, она же не единственная система в условной компании.
Те же ошибки HTTP логичнее собирать с балансировщиков, например.
Когда у разных команд есть один инструмент для всех частей и не нужно делать свою - обычно получается лучше.
Поддерживать одновременно два варианта, один из которых больше нигде не может использоваться - будто бы накладно, если вы и так отдаете метрики в принятом индустрией стандарте сейчас.
Есть ZFS, можно собрать в установщике или webui.
Это всегда было, независимо от зрелости и стабильности направления. Тем более, если сейчас это модно, как AI, который все пытаются внедрить везде.
А потом добавляем к атакам через общий page cache большие кластеры kubernetes в каком-нибудь enterprise, с одинаковыми базовыми образами у большинства сервисов - получается совсем неприятно.
После таких вот приколов kata/firecracker/etc уже не выглядят чем-то избыточным.
Он редиректит на лежавший вчера https://ubuntu.com/security/CVE-2026-31431
Удивляет, что Canonical не озаботились защитой от DDoS для этих ресурсов. Тем более на фоне copy fail, вчера так и не смог проверить у них, вышли ли патчи.
Думал, где уже раньше видел эту мысль - нашёл.
Там приходят к выводу, что хоть потенциал и есть, сейчас реализовать что-то подобное будет невозможно.
Но сама идея, конечно, выглядит заманчиво. Был бы способ её воплотить :)
Классная идея и реализация!
Еще и с открытым кодом, спасибо :)
Лезть внутрь appliance и надеяться, что вы не потеряете поддержку так - ну, странно.
В vcenter же есть SNMP и API, они отдают данные по тому же месту, памяти и CPU. Зачем тащить внутрь zabbix agent?
Кстати, на картинке у вас "Zibbacx".
Нет, наличие административного доступа в таких СХД не позволяет уничтожить данные никаким способом, в этом их смысл - обеспечить immutable. Только физически идти и ломать оборудование.
То же самое касается внешних S3 хранилищ - compliance lock не позволяет вам отменить блокировку или уменьшить ее срок, даже если у вас есть полный доступ ко всем бакетам.
Знакомо, вспомнил свои приключения с реверсом. После пары месяцев в IDA - byteswap в голове и прыжки по указателям туда-сюда даже веселят.
А уж какие потом эмоции от встречи переименованной тобой функции где-нибудь в дебрях :)
Вы пишете правильные вещи про риски и необходимость immutable storage. Но создаётся впечатление, что "настоящий" WORM - это только лента, что не так. Тем более, восстанавливаться с нуля, с перечитыванием метаданных с ленты, можно долго.
Есть много альтернатив - от реализации на уровне СХД (ONTAP, PowerStore, OceanProtect) до S3 с compliance object lock.
Вам не кажется, это цена одной неплохой квартиры в СПб :)
Если в заголовок написать "Заключили контракт на продажу квартиры в Японию" будет уже не эпично.
Интересно, как сейчас в этой ситуации будут вести себя поставщики в РФ.
Пару лет назад мы закупали 8500L и ждали поставку месяцев 8, если не дольше.
А у вас был контракт на поддержку? Так и не понял, обещает ли Cisco замену без него или нет.
Обычный RMA в рамках контрактов всегда делался без проблем.
Согласен с многими пунктами.
Многие коллеги не всё ещё не принимают, что уметь рассказать про себя и свой опыт - не менее важно, чем иметь этот самый опыт, к сожалению.
И вообще часто вижу, что люди несерьёзно подходят к собеседованиям, с обеих сторон.
Интересно, пишите ещё :)
Я бы почитал про pathfinder и вообще про сходимость сети подробнее.