Хранение журналов в Stackdriver GCP

ТЕПЕРЬ это возможно, см. этот пост ниже (отредактировано)

Предыдущий ответ:

Срок хранения журнала составляет 30 дней, и его нельзя настроить, вы платите только за хранилище.

Stackdriver Logging позволяет хранить журналы в течение 30 дней и предоставляет инструмент настройки одним щелчком мыши для архивирования данных в течение более длительного периода в Google Cloud Storage.

https://cloud.google.com/logging/

Но вы можете создать приемник для своих журналов и хранить их в Big Query или Google Cloud Storage (или в обоих из них).

Сохранение журнала теперь ВОЗМОЖНО.

Используйте эту документацию для настраиваемых периодов хранения. Это может быть от 1 day до 3650 days.

gcloud beta logging buckets update _Default --location=global --retention-days=[RETENTION_DAYS]

Объяснение:

Для каждого проекта Google Cloud Logging автоматически создает два сегмента журналов: _Required и _Default. Все журналы, созданные в проекте, хранятся в сегментах _Required и _Default журналов, которые находятся в проекте, в котором создаются журналы:

_Required: в этом сегменте хранятся журналы аудита действий администратора, журналы аудита системных событий и журналы прозрачности доступа, которые хранятся в течение 400 дней. С вас не взимается плата за журналы, хранящиеся в _Required, и срок хранения журналов, хранящихся здесь, не может быть изменен. Вы не можете удалить это ведро.

_Default: в этом сегменте хранятся все остальные загруженные журналы в проекте Google Cloud, за исключением журналов, хранящихся в сегменте _Required. К этим журналам применяется стандартная цена Cloud Logging. Записи журнала, хранящиеся в корзине _Default, хранятся в течение 30 дней, если вы не примените специальные правила хранения.

С помощью настраиваемых сегментов и сегментов _Default вы можете настроить пользовательские периоды хранения для разных журналов.

Помимо 30 дней, журналы аудита хранятся в течение 400 дней.

Шаблоны проектирования для экспорта журналов охватывает особенности экспорт в GCS, BigQuery и PubSub (для потоковой передачи журналов).

Удержание Stackdriver:

1. Действия администратора (400 дней)
2. Доступ к данным (30 дней)
3. Системное событие (400 дней)
4. Другие журналы (30 дней)

Пункты с 1 по 3 представляют собой журналы аудита, которые можно включить на странице iam > audit logs. Помните, что это может быть большой поток журналов. Это особенно актуально для журналов доступа к данным, поскольку регистрируют каждый объект доступа, например, в GCS (Google Cloud Storage) или Cloud Datastore. Некоторые передовые практики заключаются в том, что вы отключаете ведение журнала аудита для разработки или включаете ведение журнала аудита только для часто используемых служб (KMS, IAM, хранилище и т. Д.) И отключаете ведение журнала аудита для Cloud Build, Cloud Functions и т. Д.

Маркер 4, другие журналы, могут быть журналами приложений из облачных функций, App Engine и т. Д. Это журналы, которые поступают из приложений, которые вы запускаете на GCP. Хранение всех журналов Stackdriver теперь настраивается (апрель 2020 г.). Подробнее об этом можно узнать здесь.

Хотите хранить журнал в течение более длительного периода времени?

Есть много вариантов использования, в которых вы хотите вести журнал в течение более длительного периода времени. Это может быть сделано для аналитических целей, мониторинга или соблюдения требований. Вы можете экспортировать журналы с логином на уровне проекта, каталога или даже организации. Сами логинки бесплатны, вы платите только за хранилище места назначения, которое может быть одним из следующих:

• Облачное хранилище Google
• Пабы / саб
• Bigquery

Pub / sub может быть отличным решением, если вы хотите переместить экспорт журналов в другое место, возможно, вне GCP. Недавно я узнал, что Google Cloud Storage и Big Query не сильно различаются по стоимости хранения. Они оба предлагают слезы для хранения более низкого класса для более длительного хранения.

Рекомендации по Logsink

• Для многих случаев использования Big Query может быть лучшим и самым простым решением. Затраты на хранение сопоставимы со стандартными и близкими к Big Query классами хранения. И у вас есть возможность легко запрашивать данные.
• Используя Big Query, не запускайте слишком часто запросы, охватывающие большой объем данных. Это может стать дорогим.
• Используя Big Query, разделите свои данные так, чтобы каждый день или каждую неделю данные вставлялись в новый раздел или таблицу. Что, в свою очередь, автоматически снижает стоимость хранения таблиц, которые не обновляются, на 50%.
• Когда вам нужно хранить данные в течение нескольких лет (3, 5 или даже 7 лет) из-за соображений соответствия. Я бы рекомендовал экспортировать данные в облачное хранилище Google. С помощью управления жизненным циклом объекта вы можете поместить эти данные в архивное хранилище, которое стоит лишь небольшую часть (15%) от стандартного хранилища.

Теперь вы можете настроить индивидуальное хранение с помощью команды:

gcloud alpha logging buckets update _Default --location=global --retention-days=[RETENTION_DAYS]

См. https://cloud.google.com/logging/docs/storage#logs-retention