Verifiquei os logs do MySQL no Google Cloud e encontrei os seguintes logs. Isso acontece a cada 15 minutos. O que é isso? Posso ignorar? O MySQL é 8.0.31.
[Nota] [MY-000000] [Servidor] O comprimento é 0 e a política é 1
Tentei pesquisar, mas não consegui encontrar nenhuma documentação.
Estou tentando criar uma verificação de uptime no Google Cloud Platform usando o cliente de linha de comando gcloud. Este é um exemplo:
gcloud monitoring uptime create 'example uptime check' --resource-labels=host=...,project_id=... --resource-type=uptime-url --protocol=https --port=443 "--path=..." --request-method=get --validate-ssl=true --status-codes=200 --matcher-type=contains-string "--matcher-content=..." --period=5 --timeout=30 --user-labels=instance-group=production,instance-type=authentication,monitoring-type=uptime
Isso geralmente funciona, ou seja, a verificação de uptime é criada e nenhum erro é relatado. No entanto, meus rótulos de usuário são silenciosamente ignorados.
Acredito que estou seguindo a documentação ( https://cloud.google.com/sdk/gcloud/reference/monitoring/uptime/create ) corretamente:
--user-labels=[KEY=VALUE,…]
List of label KEY=VALUE pairs to add.
Keys must start with a lowercase character and contain only hyphens (-),
underscores (_), lowercase characters, and numbers. Values must contain only
hyphens (-), underscores (_), lowercase characters, and numbers.
Adicionei com sucesso rótulos de usuário muito semelhantes para calcular instâncias, discos etc.
Também tentei adicionar rótulos de usuário às verificações de tempo de atividade existentes via gcloud monitoring uptime update, mas isso também não funcionou.
Atualização: Criei um relatório de bug conforme sugerido por Daniel T.: https://issuetracker.google.com/issues/393989630
Estou testando as permissões necessárias para criar uma consulta agendada no BigQuery.
A consulta agendada será criada programaticamente com uma conta de serviço ( [email protected]) que eu posso personificar. A consulta agendada será executada como outra conta de serviço ( [email protected]).
Eu concedi as seguintes funções:
[email protected]ativarproject1[email protected]Conta de serviço Usuário para[email protected][email protected]o conjunto de dados de destino ( test_dataset)[email protected]ativarproject1[email protected]uma organização (porque a consulta está usando a region-us.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATIONvisualização)Estou executando o seguinte enquanto conectado a project1(o conjunto de dados de destino está neste projeto). Também tentei fazer o mesmo com o Terraform, com a mesma mensagem de erro.
gcloud config set auth/impersonate_service_account [email protected]
bq mk \
--transfer_config \
--target_dataset=test_dataset \
--display_name='test bq scheduled query' \
--params='{"destination_table_template":"test_jobs", "write_disposition":"WRITE_APPEND", "query":"SELECT job_id FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION` WHERE DATE_TRUNC(creation_time, DAY) = '2025-01-22'"}' \
--data_source=scheduled_query \
[email protected]
Recebo a seguinte saída:
Updated property [auth/impersonate_service_account].
WARNING: This command is using service account impersonation. All API
calls will be executed as [[email protected]].
BigQuery error in mk operation:
Requesting user [email protected] does not have
iam.serviceAccounts.actAs permission to act as service account
[email protected]
O erro é mentira, pois [email protected]tem a função Usuário de Conta de Serviço[email protected] ativada e essa função inclui iam.serviceAccounts.actAspermissão.
Tem algo que estou esquecendo aqui? O suporte do GCP está me deixando louco, não está sendo útil em nada.
(os nomes da conta de serviço, do conjunto de dados e do projeto foram alterados)
Estou implantando um webapp de painel simples em python. Tudo sobre a implantação é mais ou menos idêntico às implantações anteriores, que funcionaram. (Mesmo YAML, mesmo código de autenticação, etc.)
Entretanto, quando implanto este próximo aplicativo, o Google Cloud CLI gera o erro acima gcloud app create.
ERROR: (gcloud.app.create) INVALID_ARGUMENT: The project must have a billing account attached
Não consegui encontrar uma solução em vários fóruns, além de "esperar e tentar mais tarde". Supostamente isso funciona. Mas ainda estou curioso para saber por que esse erro ocorre / algum conselho mais experiente.
Estou passando pelo Security Command Center no Google Cloud e tenho a seguinte descoberta de segurança:
Próximos passos
Visite esta página do Google Cloud Platform que ajudará você a resolver a violação de localização que está afetando o recurso padrão google.compute.Subnetwork.
Exclua este recurso para resolver a violação de recurso associada à política da organização 'gcp.resourceLocations'.
Eliminação
Quando vou lá VPC networksvejo muitas defaultredes, mas elas não podem ser excluídas.
Como posso excluí-los?
Estou implantando um contêiner em uma instância COS (Container OS). Muito simples.
Quero que ele reinicie diariamente. Qual é a melhor maneira de fazer isso? Uma simples aba CRON que eu poderia configurar na VM? O problema com isso é que precisará ser refeito sempre que a VM for reimplantada.
Seguindo os documentos disponíveis do GCP aqui: https://cloud.google.com/artifact-registry/docs/repositories/cleanup-policy
Configurei a política de limpeza no meu repositório de artefatos com a opção de execução a seco habilitada, mas não consegui gerar nenhum log de auditoria usando o comando.
gcloud logging read 'protoPayload.serviceName="artifactregistry.googleapis.com" AND protoPayload.request.parent:"projects/gift-service-app-jm/locations/australia-southeast1/repositories/gcf-artifacts" AND protoPayload.request.validateOnly=true' \
--resource-names="projects/gift-service-app-jm" \
--project=gift-service-app-jm
Consegui confirmar que a política foi definida e a opção de execução a seco está habilitada usando o gcloud artifacts repositories describe gcf-artifactscomando
{
"cleanupPolicies": {
"Delete Previous Versions": {
"action": "DELETE",
"condition": {
"olderThan": "864000s",
"tagState": "UNTAGGED"
},
"id": "Delete Previous Versions"
}
},
"cleanupPolicyDryRun": true,
"createTime": "2023-09-27T05:07:31.256470Z",
"description": "This repository is created and used by Cloud Functions",
"format": "DOCKER",
"labels": {
"goog-managed-by": "cloudfunctions"
},
"mode": "STANDARD_REPOSITORY",
"name": "projects/gift-service-app-jm/locations/australia-southeast1/repositories/gcf-artifacts",
"updateTime": "2024-07-10T05:39:56.088672Z"
}
Alguém já teve esse problema antes? Eu apliquei a função de proprietário ao meu principal do IAM, mas também tentei adicionar as funções de visualizador de logs e visualizador de logs privados explicitamente.
Eu tenho um modelo de instância do Google Cloud Compute Engine com um script de inicialização.
No script de inicialização o servidor gera um certificado. Após gerar o certificado ele envia uma mensagem para uma API para informar um sistema central sobre o certificado. A solicitação fica assim:
curl --location 'https://my-side.com/hello?hostname=$hostname' \
--header 'Authorization: SUPER_SECRET_API_KEY'
A chave de API é armazenada como texto bruto no script de inicialização. Está tudo bem ou deveria ser movido para um armazenamento secreto de exemplo? Em caso afirmativo, como posso ler a chave da API no script de inicialização?
Meu cluster Kubernetes em execução no piloto automático do GKE tem um nó não íntegro. O nó tem um Readystatus, mas todos os pods em execução nele têm um CreateContainerErrorstatus e parecem estar travados na pesquisa de imagens de contêiner.
Exemplo:
(Normal puxado 101s (x1326 acima de 4h49m) imagem do contêiner kubelet "gke.gcr.io/cluster-proportional-autoscaler:v1.8.10-gke.3@sha256:274afbfd520aef0933f1fefabddbb33144700982965f9e3632caabb055e912c6" já presente na máquina).
Algo deu errado em uma atualização do Kubernetes porque minha conta ficou sem cota (aparentemente 1 TB de armazenamento computacional não é suficiente para um cluster pequeno). Consegui mais cota, mas o cluster do piloto automático não se repara sozinho.
Eu "cordonei" o nó para marcá-lo como não programável e excluí manualmente meus pods dele. Novos pods foram agendados em nós mais saudáveis, então não é tão ruim.
Agora quero fazer uma limpeza. Os pods antigos ficaram presos no Terminatingestado, mas a exclusão forçada deles os fez desaparecer.
Não posso fazer o mesmo nos namespaces kube-systemand gke-gmp-system. Vejo os pods "gerenciados" com um CreateContainerErrorstatus e eles estão extraindo imagens de contêiner em um loop. A pessoa também está presa a um Terminatingstatus.
Eu gostaria de remover esse nó, e aparentemente você precisa drenar o nó e ignorar os erros no kube-systemnamespace . Eu drenei o nó, mas ele ainda está lá.
Como eu poderia remover o nó não íntegro?
Estou clonando vários repositórios (usando git clone) dentro do meu trabalho do Google Cloud Run e um deles faz o Google Cloud encerrar o contêiner com a saída 1. Veja o log:
{
insertId: "xxx",
labels: {
instanceId: "xxx"
run.googleapis.com/execution_name: "xxx",
run.googleapis.com/task_attempt: "0",
run.googleapis.com/task_index: "0"
},
logName: "xxx/run.googleapis.com%2Fstderr",
receiveTimestamp: "2024-03-13T09:05:28.686787232Z",
resource: {
labels: {
job_name: "xxx",
location: "xxx",
project_id: "xxx"
},
type: "cloud_run_job"
},
textPayload: "Killed",
timestamp: "2024-03-13T09:05:28.685133Z"
}
O repositório clonado possui 10.828 arquivos e seu tamanho é de 1,8 GB. O uso de memória e CPU não excedeu 50%. Acontece durante .git clone [email protected]:usr/bad_repo.git
Presumo que esteja relacionado a um limite, mas não encontrei nada.
Passos para reproduzir:
git clone -q --depth 1 --no-tags --filter=blob:limit=100k [email protected]:supabase/supabase.git
Todos os registros:
