Первый и главный инструмент в арсенале — это **Cloud Logging** (ранее Stackdriver). Практически все сервисы GCP по умолчанию пишут логи сюда. Для аналитика, работающего с BigQuery, Dataflow, Dataproc или Cloud Composer, это центральная точка диагностики. Начните с настройки целенаправленных запросов. Например, при ошибке в запросе BigQuery не ограничивайтесь сообщением в UI; перейдите в Logging и используйте Query Builder, чтобы найти полную запись лога по resource.type="bigquery_project" и severity=ERROR. Вы увидите детализацию, включая job_id, текст запроса и полную трассировку стека. **Рекомендация**: Создайте и сохраните полезные запросы (например, «все ошибки из Dataflow за последние 24 часа») в панели мониторинга Logs Explorer для быстрого доступа.
Второй ключевой сервис — **Cloud Monitoring** (ранее Stackdriver Monitoring). Если логи отвечают на вопрос «*что* произошло», то метрики и дашборды в Monitoring помогают понять «*почему*». Для отладки проблем с производительностью пайплайнов настройте дашборды для критически важных метрик. При работе с BigQuery отслеживайте `query_count`, `slot_utilization` и `query_execution_time`. Если запросы начали выполняться медленнее, всплеск утилизации слотов может указать на конкуренцию за ресурсы в проекте. Для Dataflow ключевыми являются метрики `System Lag` (задержка обработки), `Current vCPU Count` (масштабирование) и `Element Count` (прогресс). Резкий рост lag — явный сигнал к проверке логики преобразования или источника данных.
Третья область для отладки — это **IAM и управление доступом**. Ошибки вида «Permission denied» или «Access denied» — одни из самых частых. В GCP права доступа иерархичны и наследуются от ресурсов к ресурсам. Для диагностики используйте встроенные инструменты. **Cloud Audit Logs** (часть Cloud Logging) фиксируют все операции, связанные с управлением ресурсами и доступом. Ищите события типа `google.iam.v1.loggedAuditData`. Более простой способ — использовать **Policy Troubleshooter** прямо в консоли IAM. Укажите член (пользователя или сервисный аккаунт), ресурс и разрешение, которое нужно проверить; инструмент покажет, есть ли доступ и какие политики его предоставляют или блокируют. Для аналитиков, запускающих пайплайны, критически важно правильно настроить сервисные аккаунты для Dataflow, Composer или Cloud Functions.
Четвертый аспект — отладка **распределенных вычислений**, особенно в Dataflow (Apache Beam) и Dataproc (Apache Spark). Здесь сложность в том, что ошибка может возникнуть в одном из сотен воркеров. Cloud Logging агрегирует логи всех воркеров, но их объем огромен. Используйте группировку по `job_id` и `worker_id`. Ищите шаблоны: если множество воркеров падают с одной и той же ошибкой (например, проблема с парсингом данных), причина, скорее всего, в коде преобразования или «грязных» данных. В Dataflow используйте встроенную **интроспекцию пайплайна** (Pipeline Inspector) в интерфейсе Jobs. Она позволяет визуализировать граф выполнения, увидеть задержки на каждом этапе (PCollection) и даже просмотреть образцы данных, проходящих через каждый шаг (PCollection), что бесценно для проверки логики трансформаций.
Пятый, часто упускаемый из виду инструмент — **Cloud Trace** (для трассировки распределенных систем) и **Cloud Debugger** (для инспекции состояния работающего приложения без его остановки). Если ваш аналитический пайплайн включает микросервисы на Cloud Run или App Engine, Cloud Trace покажет полный путь запроса через все сервисы, выделяя узкие места. Cloud Debugger же позволяет, например, «заснепшотить» состояние переменных в Cloud Function, которая обрабатывает данные, в момент ее выполнения при определенном условии.
Наконец, выработайте **методологию систематической отладки**:
- **Локализация**: Определите, в каком сервисе и на каком этапе пайплайна возникла проблема (загрузка в BigQuery, преобразование в Dataflow, оркестрация в Composer).
- **Проверка логов**: Изучите Cloud Logging на предмет ошибок и предупреждений, фильтруя по соответствующему ресурсу и временному интервалу.
- **Анализ метрик**: Перейдите в Cloud Monitoring, чтобы увидеть, не предшествовали ли ошибке аномалии в использовании ресурсов (память, CPU, слоты).
- **Воспроизведение и изоляция**: Попробуйте воспроизвести ошибку на уменьшенном наборе данных или в изолированной среде (отдельный проект или dataset).
- **Документирование**: Фиксируйте найденные решения. Часто ошибки связаны с квотами, лимитами API или особенностями данных.
Комментарии (12)