Skip to main content
A rotação substitui uma chave de ingestão do projeto. Ela não muda o projeto nem a telemetria armazenada. Gerencie as chaves com a autenticação da conta. Uma chave de ingestão só pode enviar telemetria. Ela não consegue gerenciar chaves. Antes de começar, instale a CLI e entre na sua conta. Defina LOGBREW_PROJECT_ID com o UUID do projeto. Defina LOGBREW_API_URL como https://api.logbrew.co. Os exemplos usam Bash, curl 7.76.0 ou mais recente e jq. Na rotação planejada, crie, implante e teste a chave substituta antes de revogar a chave antiga. Defina o intervalo de rotação na sua política de segurança. Se uma chave tiver data de expiração, substitua a chave antes dessa data.
Uma chave exposta é um incidente de segurança. Revogue a chave imediatamente, mesmo antes de implantar a substituta. Aplicações que ainda usam uma chave revogada não conseguem enviar telemetria.
1

Crie a chave substituta

POST /api/projects/{project_id}/ingest-keys aceita um label não vazio de até 120 caracteres. kind é cli, sdk, browser, server ou artifact. Uma chave artifact não pode enviar telemetria. Um expires_at opcional precisa ser um horário RFC3339 no futuro.Use o mesmo kind da chave antiga. A CLI usa sdk quando você omite --kind e CLI-created SDK key quando você omite --label. A CLI não tem flag de expiração. Para definir expires_at, use a API.A CLI salva o token de uso único em um arquivo novo, fora do controle de versão, que só o dono pode acessar. Ela imprime os metadados, não o token:
Continue só depois que o comando der certo. Defina NEW_KEY_ID com o ingest_key.id retornado.Se o resultado for incerto, execute exatamente o mesmo comando de novo. A CLI reutiliza a chave de nova tentativa pendente. Não use --abandon-retry nesta nova tentativa.Um cliente que chama a API diretamente recebe o token uma única vez, na resposta. Para tentar de novo, envie o mesmo cabeçalho Idempotency-Key com o mesmo corpo. Por 24 horas, essa nova tentativa retorna a mesma chave. Nunca imprima, faça commit ou compartilhe o token.
2

Implante a nova chave com a antiga ainda ativa

Coloque o novo token na configuração protegida de implantação. Implante a aplicação. Mantenha a chave antiga ativa. Mantenha os dois tokens fora do código-fonte, da saída do build e dos logs.
3

Envie um evento sintético

Carregue o novo token na variável de shell new_ingest_key. Não imprima o token. Envie um log sintético com a nova chave e depois leia esse log:
Continue só quando a leitura retornar este log com o mesmo occurred_at. Um log de verificação de rotação mais antigo não prova que a nova chave funciona. Confirme também que a aplicação implantada envia telemetria. Se um comando falhar, pare e leia a resposta. Mantenha a chave antiga ativa, a não ser que ela tenha sido exposta.
4

Liste os metadados das chaves sem segredos

Defina LOGBREW_ACCOUNT_BEARER com a autenticação da sua conta. Encontre o ID da chave antiga. Confirme que NEW_KEY_ID está active:
A resposta é um array de metadados de chaves, sem tokens. O status é active, expired ou revoked. Uma chave fica expired quando o horário de expires_at já passou.
5

Revogue só a chave antiga

Defina OLD_KEY_ID a partir da lista. O comando revoga a chave antiga só quando os dois IDs são diferentes:
DELETE é idempotente. Ele retorna os metadados da chave com status: "revoked" e revoked_at preenchido. Você pode repetir o comando com segurança depois de uma resposta incerta.Execute unset new_ingest_key. Trate o arquivo da chave conforme sua política de segredos.

Recupere com segurança

Se a rotação ainda falhar, abra Relatar um problema. Compartilhe só os metadados das chaves. Não inclua credenciais, cabeçalhos, telemetria bruta, dados de clientes, caminhos locais ou código-fonte.