Инженеры Render обнаружили 7 TiB памяти, которая простаивала в их Kubernetes-класторе из-за неэффективного использования namespace'ов. Проблема заключалась в том, что daemonset'ы (особенно Calico для сетевой конфигурации и Vector для сбора логов) выполняли listwatch операций для namespace'ов на каждом узле. Это создавало огромную нагрузку на apiserver и потребляло значительные ресурсы, так как количество namespace'ов у Render достигло аномально высокого уровня по сравнению с другими кластерами.

Команда уже оптимизировала Calico, сотрудничая с разработчиками проекта, и обнаружила аналогичную проблему с Vector. Оказалось, Vector отслеживал namespace'ы только для проверки принадлежности pod'ов пользовательским namespace'ам. Инженеры нашли способ обойти эту необходимость, что позволило освободить колоссальные 7 TiB памяти. Это решение подчеркивает важность масштабирования не только по количеству узлов или pod'ов, но и по namespace'ам, которые могут стать скрытым узким местом в инфраструктуре.

• В обсуждении поднимается вопрос о том, что 1.2 ТБ памяти используется только для логов, что вызывает удивление и критику.
• Участники обсуждают, что такое использование ресурсов неэффективно и может быть улучшено, особенно если учесть, что в Kubernetes ключи и метки могут быть оптимизированы.
• Обсуждается, что вместо использования больших строковых ключей, можно было бы использовать UUID или другие уникальные идентификаторы, что сократит использование памяти и улучшит производительность.
• Участники также обсуждают, что вместо того, чтобы хранить логи в таком виде, можно было бы использовать встроенные инструменты для сбора и хранения логов, что было бы более эффективно.

В предоставленном фрагменте содержится только навигационная структура сайта Google Developers Blog и заголовок статьи "Say hello to a new level of interactivity in Gemini CLI", но отсутствует основной текст публикации.

Заголовок указывает на анонс обновлений для Gemini CLI, повышающих уровень интерактивности, но конкретные детали, функции или улучшения в тексте не раскрыты. Статья доступна на нескольких языках, включая английский, испанский, индонезийский, японский, корейский, португальский и китайский.

Для создания точного пересказа требуется полный текст статьи с описанием новых возможностей Gemini CLI.

• Пользователи жалуются на ненадёжность Gemini CLI: модель часто отказывается читать файлы вне проекта, путает \n и \n\n, а иногда и вовсе не может запустить интерактивную оболочку без дополнительного убеждения.
• Сообщество отмечает, что в отсутствии нормального MCP-протокола Gemini CLI уступает не только в UX, но и в надёжности: «по факту ты просто запускаешь процесс в псевдотерминале и смотришь стрим — без TUI-модели и без встроенного логгера снимков состояния».
• Несколько участников подтверждают, что даже базовые сценарии вроде git log или git diff заставляют модель «залипать» и требуют ручного перезапуска.
• Наблюдается общее чувство, что Google недооценивает как саму модель, так и экосистему вокруг неё: «Почему до сих пор нет нормального логгера, нормального MCP-сервера, нормального линтера или хотя бы нормального линтера?»
• Наконец, вопрос о лицензии: «кто владеет "сериализованными" терминальными сессиями, которые Google выгружает в облако?»

OpenTelemetry Collector: что это, когда нужен и когда нет

Практическое руководство по OpenTelemetry Collector: что делает, как работает, архитектурные паттерны и как решить, нужен ли он вам для производительности, контроля, безопасности и экономии.

Нужен ли вам OpenTelemetry Collector? Для небольших проектов — возможно нет. Для production-среды с множеством сервисов, где важны стоимость, производительность и безопасность — почти наверняка да.

Краткое определение

OpenTelemetry Collector — это нейтральный к вендорам, расширяемый конвейер телеметрии, который принимает, обрабатывает и экспортирует данные (трейсы, метрики, логи) из ваших приложений в одно или несколько хранилищ.

Он позволяет:

• Очищать данные (удалять чувствительные поля, добавлять контекст)
• Пакетировать отправки и повторять при сбоях
• Применять умное семплирование (сохранять ошибки и редкие медленные трейсы)
• Сглаживать различия между версиями SDK
• Маршрутизировать данные в разные хранилища
• Служить защитным барьером между приложениями и интернетом
• Снижать затраты, отсеивая малополезную телеметрию

Архитектура

Без Collector (прямой экспорт)

Каждый сервис отправляет телеметрию напрямую в бэкенд:

Плюсы:

• Проще (меньше компонентов)
• Меньше операционных затрат
• Подходит для маленьких приложений / POC

Минусы:

• Каждый сервис сам handles retries, auth, backpressure
• Сложно менять экспортеры
• Нет централизованного семплирования / очистки / маршрутизации
• Риск misconfigurations
• Выше стоимость исходящего трафика при отправке в несколько систем

С центральным Collector

Все приложения отправляют данные в центральный Collector, который затем экспортирует:

Плюсы:

• Централизованная конфигурация: семплирование, очистка, обогащение
• Один канал исходящего трафика с пакетированием и retry
• Развязывает жизненный цикл приложения от изменений вендоров
• Меньше нагрузки на приложения
• Безопасность: приложения не выходят в интернет напрямую

• Рекомендуется использовать коллектор OpenTelemetry для упрощения архитектуры, локальной отладки и управления аутентификацией
• Предлагается декаплеить коллектор от потребителей трассировок через брокеры сообщений (Kafka/NATS) для надежности и масштабируемости
• Коллектор рассматривается как защитный шлюз (read-only) между приложениями и базой данных для безопасности
• Отмечается сложность освоения OpenTelemetry, но подчеркивается его ценность как стандарта для интероперабельности
• Указывается полезность OTEL даже для монолитов благодаря возможностям корреляции и вложенных спэнов
• Обсуждаются альтернативы (Vector vs OTEL) и необходимость улучшения документации и примеров
• Упоминается использование коллектора для валидации и тестирования с помощью AI-агентов

Коротко:
Секреты в логах — это не «одним фиксом» решить нельзя. Ни 80/20, ни чудо-инструмента нет. Есть 10 «свинцовых пуль» — несовершенных, но при правильной раскладке работают.

---

Почему течёт

Причина	Пример
Прямой логинг	log.info(user) вместо log.info(user.id)
«Мусорные» дампы	logger.debug(req.headers)
Конфиги	debug=true выводит весь env
Зашитые секреты	JSON-поле password внутри структуры
Телеметрия	APM-сборщик хватает всё подряд
Пользователь	Вводит пароль в поле «имя»

---

10 «пуль»

1. Архитектура данных
   Разделяем «чувствительное» и «остальное» на уровне схемы; в логи идёт только последнее.

2. Трансформации
   Сериализуем через sanitize() или toLog() — явно выбрасываем секретные поля.

3. Domain-primitives

   • Компиляция: SecretString не реализует Display.
   • Рантайм: Redactable интерфейс, toString() → "***".

4. Read-once
   Пароль читается 1 раз, дальше объект пустой — логировать нечего.

5. Taint-tracking
   Помечаем вход как «грязный»; если доходит до логгера — exception. Дорого, но точно.

6. Форматтеры логов
   Пишем свой Layout / Encoder, который режет заранее заданные ключи рекурсивно.

7. Unit-тесты
   Проверяем assertThat(log).doesNotContain(secret); запускаем на каждый PR.

8. Сканеры
   Regex-правила + entropy-фильтры в CI и в production-потоке. Сэмплируем, чтобы не умереть от CPU.

9. Pre-processors
   Vector / Logstash / Cribl вырезают поля ещё до попадания в Elasticsearch.

10. Люди
    Code-review чек-лист: «есть ли тут .toString / JSON.stringify / printf без фильтров?».

---

Стратегия

1. Фундамент: классификация данных, единый словарь «что считать секретом».
2. Карта потока: от источника до хранилища логов.
3. Контрольные точки: валидация, sanitize, redact.
4. Защита в глубину: 2-3 слоя из списка выше.
5. План на инцидент: ротация, оповещение, forensics.

---

Итог:
Нет волшебства — только дисциплина и много мелких фиксов. Начните с 2-3 «пуль», которые дешёвле всего у вас, и двигайтесь дальше.

• Отличный пост: чёткий разбор проблемы «секреты в логах» и конкретные техники борьбы.
• Основные идеи: taint-tracking, in-band метки, GuardedString/SecureString, доменные примитивы new Secret(...).
• Сложности: стектрейсы, JSON, core-dumps, динамически создаваемые секреты, человеческий фактор.
• Защита в глубину: маскировать, ограничивать доступ к логам, не писать всё подряд, валидировать маски (Kingfisher).