cloud-logging-query-generation

Этот навык предназначен для подготовки запросов Logging Query Language (LQL) к Google Cloud Logging из естественного описания задачи. Его область применения ограничена Cloud Logging: исходная инструкция отдельно предупреждает, что такой навык не следует использовать для запросов к другим базам данных, например SQL или Cloud Spanner. Практический смысл записи — помочь превратить намерение вроде поиска ошибок конкретного сервиса в синтаксически аккуратный фильтр, сохранив различия между типами ресурсов, полями и способами поиска. В каждом результате требуется использовать двойные кавычки для строковых литералов, писать логические операторы AND, OR и NOT прописными буквами и явно группировать условия скобками. Это не косметические требования: они делают границы строковых значений и приоритет логики однозначными. Для запросов, относящихся к определённому сервису или ресурсу, навык рекомендует включать ограничения resource.type и log_id. Глобальный поиск последних ошибок может обойтись без них, но это уже другой, более широкий сценарий. Особое внимание уделено типовым ошибкам. Для ресурса gce_instance нельзя смешивать числовой instance ID со строковым instance name. Если известно только имя, инструкция предлагает искать его через SEARCH или через доступную метку resource.labels.instance_name. Тип resource.type также нельзя угадывать: перед построением фильтра нужно свериться с сервисным справочником, потому что похожие задачи могут использовать разные значения. В качестве примера приведено различие между internal_http_lb_rule и слишком общим http_load_balancer для правил внутреннего HTTP(S)-балансировщика. Навык задаёт строгий формат выдачи: только необёрнутый текст LQL, без разговорного вступления и без блока Markdown, если пользователь его отдельно не попросил. Если для рабочего запроса не хватает идентификатора, нужно вставлять placeholder в угловых скобках только там, где значение действительно обязательно, например в имени регионального log bucket вместе с PROJECT_ID. Поле с неизвестным необязательным значением следует опустить, иначе placeholder превратится в лишний фильтр и скроет реальные записи. Поэтому отсутствие данных не должно приводить к выдуманному project ID, instance name или адресу. Для сервисов из перечня Google необходимо сначала открыть соответствующий reference-файл: в репозитории есть отдельные инструкции для Cloud Run, BigQuery, Cloud SQL, Compute Engine, GKE, IAM, сетевых, security и других сценариев. Для audit/admin/API-событий дополнительно требуется прочитать справочник audit logs и использовать правильные пути protoPayload. Если точное поле не подтверждено справочником, инструкция требует перейти к SEARCH по ключевому слову в корректном resource.type и добавить в начало валидный LQL-комментарий о применении глобального поиска. Это снижает риск выдумать структуру jsonPayload или protoPayload. Граница полезности навыка также определена источником. Он помогает сформировать фильтр и выбрать подтверждённые поля, но не проверяет права доступа к проекту, полноту поступления логов, retention, стоимость запросов или качество эксплуатационной диагностики. Полученный LQL всё равно нужно запускать в среде с нужными разрешениями и сопоставлять результат с конкретной схемой ресурса. Для незнакомого сервиса допустим общий SEARCH-сценарий, но точность результата зависит от реальных полей и данных Cloud Logging. Для ежедневной диагностики это полезный генератор запроса, а не замена проверке инцидента, IAM и мониторингу.