Migre da Cloudflare para a Azion

Um projeto na Cloudflare se distribui entre builds do Pages, Workers, arquivos de roteamento, namespaces KV, buckets R2, bancos de dados D1, regras de segurança e DNS. Movê-lo significa recriar cada um desses itens na Azion e confirmar que o projeto responde corretamente antes da mudança de DNS.

Na Azion, uma aplicação e suas regras assumem a entrega, o roteamento e o cache. Functions executa o código dos Workers. KV Store, Object Storage e SQL Database guardam os dados. Firewall filtra o tráfego, um workload atende o domínio e Edge DNS responde pela zona. Real-Time Metrics, Real-Time Events e Data Stream mostram o que acontece com cada requisição.

Cada etapa deste guia move uma camada, na ordem em que uma migração acontece: inventário, deployment, código e regras, dados, segurança, monitoramento e DNS. A maior parte do código migra com mudanças pontuais: como uma função lê variáveis, como abre o armazenamento e como chama um modelo. Quando um downtime próximo de zero não é um requisito, migre em fases com janelas de manutenção. As gravações param durante cada passo, então os dados não precisam de sincronização paralela.

Os pré-requisitos e os procedimentos desta página mudam conforme a interface que você seleciona:

Pré-requisitos

• Uma conta Azion. Para abrir uma, cadastre-se no Azion Console. Para mais informações, consulte Crie uma conta.
• A conta Cloudflare, com acesso aos seus projetos, Workers, armazenamentos de dados e zonas DNS.
• Acesso aos registros DNS ou ao registrador de cada domínio que você move.
• curl e dig, para verificar as respostas HTTP e as respostas DNS.

Faça o inventário da conta Cloudflare

Mova um projeto primeiro. Escolha um que teste o caminho completo e ainda migre rápido. Um bom primeiro projeto tem um build, alguns redirecionamentos, algumas variáveis de ambiente, um Worker e uma quantidade de dados gerenciável. Use-o para documentar o processo e depois mova os próximos projetos na mesma ordem. Mantenha o primeiro deployment pequeno e comprove que ele faz o build e roda na Azion antes de mover domínios, armazenamento ou bancos de dados.

Antes de criar qualquer coisa na Azion, liste o que o projeto usa:

• Projetos do Pages, seus comandos de build, diretórios de saída e presets de framework.
• wrangler.toml e as configurações de CI/CD que fazem o deploy do projeto.
• Variáveis de ambiente e secrets, das configurações do Pages, do wrangler.toml, dos secrets gerenciados pela CLI e das configurações de CI/CD.
• Workers, suas rotas e os bindings que cada um lê.
• Arquivos _redirects e _headers e regras de redirecionamento, origens, transformações e cache.
• Pools do Load Balancing e suas origens.
• Transformações de imagem e chamadas ao Workers AI.
• Namespaces do Workers KV, buckets R2 e bancos de dados D1.
• Domínios personalizados, zonas e registros DNS, DNSSEC e certificados.
• Regras de WAF, configurações de bots, regras de rate limiting e configurações de DDoS.
• Dashboards de analytics e exportações de logs.

Cada item da lista corresponde a uma etapa deste guia. A tabela em Mapeie cada produto da Cloudflare para a Azion indica o destino de cada um.

Mapeie cada produto da Cloudflare para a Azion

Todo produto da Cloudflare do inventário tem um destino na Azion. Encontre o produto na primeira coluna e mova-o com a etapa que indica seu destino. Um traço (-) na última coluna significa que a Azion não tem um equivalente direto.

A Azion possui um relatório SOC 2 Type 2 e um relatório SOC 3 e é PCI DSS 4.0.1 Level 1 Service Provider. Para as atestações, consulte SOC 2 e SOC 3 e Certificação PCI DSS.

Faça o deploy do projeto na Azion

Na Azion, um projeto do Pages se torna uma aplicação, e um workload atende essa aplicação em um domínio. A Cloudflare guarda a configuração de build no wrangler.toml. A Azion a guarda no azion.config.js, que também pode ser azion.config.mjs ou azion.config.cjs, conforme o preset.

A Azion suporta 19 frameworks e 5 presets genéricos. Azion Console importa um repositório com um de seis presets, e Azion CLI pede o preset em um seletor.

O deployment responde em um domínio de workload que a Azion atribui sob map.azionedge.net. Antes de mover qualquer domínio de produção, envie uma requisição para o caminho raiz, com esse domínio no lugar de <your-workload-domain>:

A resposta traz o status, os headers e o corpo que o projeto retorna para /. Envie a mesma requisição para cada rota crítica.

Se o build falhar na Azion, compare o preset com o framework do projeto e verifique build.preset, build.entry e build.bundler no azion.config.js. O bloco build não tem campo de comando.

Mova as variáveis de ambiente

Variáveis de ambiente guardam chaves de API, credenciais de banco de dados, secrets de autenticação, endpoints de serviços, feature flags e configurações por ambiente. Uma variável que não chega à Azion quebra o projeto em tempo de execução, mesmo quando o deployment tem sucesso.

Na Cloudflare, um Worker lê uma variável do parâmetro env. Na Azion, as variáveis pertencem à conta, até 100 delas, e uma função as lê com Azion.env.get(). Cada variável tem uma chave, um valor e uma flag que a marca como secret.

Depois altere o código que lê as variáveis:

Uma função em produção também lê uma variável como process.env.API_KEY. No azion dev, uma função lê o arquivo .env do projeto em vez das variáveis da conta, ou todo o ambiente do shell quando não há arquivo .env. Se uma função informar que uma variável não foi encontrada, confirme que a variável existe na conta e que o código a lê com Azion.env.get().

Mova Workers para Functions

Os Workers costumam carregar a lógica mais crítica de um projeto: autenticação, personalização, orquestração de APIs e integrações com serviços de terceiros. Na Azion, esse código roda em Functions. Uma função guarda o código, uma instância de função o executa em uma aplicação, e uma regra decide quais requisições chegam até ela.

O handler mantém sua assinatura, mas env é um objeto vazio em uma função em produção, e ctx traz args e waitUntil. Qualquer valor que um Worker lê de um binding em env passa para uma variável, ou para a API de runtime do seu armazenamento:

A geolocalização passa de request.cf para request.metadata:

No azion dev, request.metadata é undefined. Teste o código que o lê em uma função em produção.

O código que lê Workers KV, D1 ou Workers AI também muda suas chamadas. As etapas Mova dados do Workers KV para KV Store, Mova bancos de dados D1 para SQL Database e Mova Workers AI para AI Inference mostram as novas chamadas. Para as APIs de runtime, consulte Web APIs.

Recrie redirecionamentos e reescritas

Redirecionamentos protegem rankings de busca, links de campanhas, backlinks e favoritos. Quando um redirecionamento quebra, o resultado é perda de tráfego e jornadas de usuário interrompidas. A Cloudflare os guarda em um arquivo _redirects. A Azion os guarda nas regras da aplicação, que você escreve no Azion Console, na API ou no azion.config.js.

Converta cada padrão em uma expressão regular:

Os critérios de uma regra selecionam as requisições, mas não capturam nada. Para reutilizar parte do caminho no destino, adicione um comportamento Capture Match Groups antes do redirecionamento, na mesma regra. Capture Match Groups requer Application Accelerator na aplicação. O array é local, então só a regra que o captura pode lê-lo.

Para verificar o redirecionamento, requisite um caminho antigo:

A resposta traz 301 Moved Permanently e um header location que termina em /blog/post. Uma regra nova pode levar alguns minutos para se propagar. Diante de uma resposta inesperada, aguarde e tente de novo antes de diagnosticar.

Para servir conteúdo de outro caminho sem redirecionamento, use Rewrite Request com as mesmas capturas. Em mudanças sensíveis para SEO, prefira redirecionamentos permanentes, evite cadeias de redirecionamento, mantenha os caminhos canônicos consistentes e teste os caminhos com e sem barra final.

Recrie headers personalizados

Headers controlam o cache, a segurança e o comportamento do navegador. A Cloudflare os guarda em um arquivo _headers, apenas para respostas. A Azion os adiciona com regras em qualquer uma das fases: Add Request Header altera a requisição enviada à origem, e o mesmo comportamento em uma regra da Response Phase altera a resposta enviada ao usuário.

Este azion.config.js adiciona dois headers de segurança a toda resposta da aplicação:

O valor tem o formato Name: value, e o Console recusa qualquer outro formato com Header must follow the header-name: value format. Um workload precisa atender a aplicação para que os headers cheguem a um domínio. Execute azion deploy e depois verifique uma resposta:

A resposta traz x-frame-options: SAMEORIGIN e x-content-type-options: nosniff.

Recrie as configurações de cache

Na Azion, uma configuração de cache define por quanto tempo uma resposta fica em cache e o que faz duas requisições compartilharem uma cópia em cache. Uma regra com Set Cache Policy aplica a configuração às requisições a que corresponde. A regra seleciona uma configuração, e a configuração guarda o TTL e a chave de cache.

Max Age tem padrão de 60 segundos. Um valor abaixo de 60 requer Application Accelerator, e uma configuração de cache com Tiered Cache ativado precisa de pelo menos 3 segundos e de Override cache behavior. Stale cache respeita o stale-while-revalidate que a origem envia, ou mantém uma janela de 300 segundos com Override cache behavior. Ele vem ativado por padrão no Azion Console e desativado na API e na CLI.

Para variar o cache por query string, cookie ou dispositivo, use os controles Cache vary by da configuração de cache: Cache vary by Query String, Cache vary by Cookies e Cache vary by Devices. Eles requerem Application Accelerator na aplicação. Cache vary by Devices com o comportamento Allowlist mantém uma cópia para cada grupo de dispositivos que você seleciona, entre os grupos da aba Device Groups da aplicação. Para os controles, consulte Variação de cache.

Para fazer purge de conteúdo em cache, envie uma requisição POST para o endpoint de purge do tipo correspondente:

Purge é um endpoint de nível superior, não aninhado em applications. Um purge por URL aceita até 50 itens, e um purge por wildcard aceita uma expressão. Só um purge por chave de cache, em /v4/workspace/purge/cachekey, alcança Tiered Cache com "layer": "tiered_cache". Um purge por URL ou wildcard com essa camada falha com 30001. Para os tipos de purge, consulte Real-Time Purge.

Balanceie o tráfego entre origens

Na Azion, Load Balancer é um módulo de um connector, não um recurso separado. Um connector do tipo http guarda cada origem como um endereço, até 15 endereços com Load Balancer ativado e um endereço sem ele. Uma regra com Set Connector envia as requisições da aplicação para o connector.

Cada endereço tem um Weight de 1 a 100, que define sua parcela do tráfego. IP Hash recusa endereços Backup, com 28005 na API. Max Retries aceita de 0 a 20, Connection Timeout de 1 a 300 segundos e Read/Write Timeout de 1 a 600 segundos. Esses campos existem apenas com Load Balancer ativado. Quando você o ativa no Azion Console, o formulário preenche Round Robin, 3, 30 e 60. Os padrões da API são 0, 60 e 120.

Para os campos do connector, consulte Configurações de connectors.

Entregue imagens otimizadas

Image Processor redimensiona, recorta, converte e aplica filtros a imagens sob demanda. Ele não armazena nada: lê a imagem de origem da origem da aplicação, que pode ser um bucket do Object Storage atrás de um connector.

Image Processor funciona em dois passos: ative o módulo na aplicação e depois crie uma regra com o comportamento Optimize Images. Uma requisição que nenhuma regra desse tipo atende é entregue sem processamento.

Image Processor lê a transformação do parâmetro de query ims:

Image Processor converte para WebP quando o header Accept do cliente permite. AVIF precisa de ?ims=filters:format(avif) e de um cliente que aceite image/avif. Para manter em cache uma cópia para cada valor de ims, ative Application Accelerator e varie o cache por query string. Para cada parâmetro, consulte Parâmetros de URL.

Mova Workers AI para AI Inference

AI Inference executa um catálogo de modelos open source: large language models, vision language models, um modelo de embedding e um reranker. Um modelo não é um objeto que você cria, e a Azion não hospeda um endpoint de inferência para ele. Uma função chama um modelo pelo seu ID com Azion.AI.run() e não precisa de credencial:

No azion dev, Azion.AI é undefined. Teste a chamada em uma função em produção. Para os campos da requisição, consulte Invocação de modelos e a API de runtime de IA.

Para um endpoint /v1/chat/completions compatível com OpenAI, faça o deploy do template AI Inference Starter Kit. Ele cria uma aplicação e uma função que atendem esse endpoint. Para fazer o deploy, acesse Azion Console > Create, selecione o template e selecione Deploy. Azion CLI não tem flag de template.

Mova dados do Workers KV para KV Store

KV Store guarda configurações, feature flags, estado de sessão, tabelas de roteamento e preferências por usuário. Uma função abre um namespace com Azion.KV.open(), um global do runtime que não precisa de linha de import:

Azion.KV.open() é o único ponto de entrada e é assíncrono. O namespace precisa existir antes, ou open() lança NotFound. get() retorna null para uma chave inexistente, assim como para uma chave expirada.

KV Store não tem importação em massa, e nenhuma API, comando da CLI ou tela do Console lê ou grava chaves. Para mover os dados:

1. Exporte as chaves da Cloudflare pela API dela.
2. Crie o namespace com uma requisição POST para https://api.azion.com/v4/workspace/kv/namespaces. O nome aceita de 3 a 63 caracteres, diferencia maiúsculas de minúsculas e é permanente: um namespace não pode ser renomeado nem excluído.
3. Grave as chaves a partir de uma função em produção com kv.put().

A função grava uma chave no máximo uma vez por segundo. Um valor aceita até 25 MB, uma chave até 512 bytes e os metadados até 1.024 bytes. Associe cada TTL da Cloudflare à opção expiration, em segundos Unix, ou a expirationTtl, em segundos com mínimo de 60. Uma gravação fica visível em todos os lugares em até 60 segundos, ou dentro do cacheTtl da leitura. Antes da importação, revise os prefixos das chaves, os formatos dos valores e o código que trata uma chave inexistente. Para o cliente, consulte API de runtime do KV Store.

Mova buckets do R2 para Object Storage

Object Storage guarda imagens, documentos, assets estáticos, mídia, uploads e arquivos gerados. Ele fala o protocolo S3, então ferramentas e SDKs S3 o alcançam com um novo endpoint, uma região e um par de chaves.

O par de chaves vem de uma credencial do Object Storage. Crie-a no Azion Console ou com uma requisição POST para https://api.azion.com/v4/workspace/storage/credentials. A secret_key só volta na resposta de criação. Para migrar, a credencial precisa de pelo menos listBuckets, listFiles e writeFiles, além de listAllBucketNames para listar os buckets.

Um script de migração em Node.js alcança Object Storage com o AWS SDK:

Para copiar os dados com o s3cmd, crie antes o bucket de destino no Azion Console, na API ou na CLI. O s3cmd não cria nem remove um bucket na Azion: s3cmd mb e s3cmd rb são recusados com 403 AccessDenied. Um nome de bucket aceita de 6 a 63 caracteres, é único entre todas as contas e não pode começar com azion.

1. Execute s3cmd --configure -c ~/.s3cfg-azion e informe estes valores:

   • Access Key e Secret Key: o par de chaves da credencial.
   • Default Region: us-east-005.
   • S3 Endpoint: s3.us-east-005.azionstorage.net.
   • DNS-style bucket+hostname
     template: %(bucket).s3.us-east-005.azionstorage.net.
   • Use HTTPS protocol: true.

2. Configure um segundo arquivo, ~/.s3cfg-r2, com o endpoint e as chaves do bucket R2. Uma configuração do s3cmd guarda um endpoint.

3. Baixe os objetos do R2:

   s3cmd -c ~/.s3cfg-r2 sync s3://r2-bucket/ ./export/

4. Envie-os para a Azion:

   s3cmd -c ~/.s3cfg-azion sync ./export/ s3://azion-bucket/

Os objetos estão no bucket da Azion. Para verificar, liste-os com s3cmd -c ~/.s3cfg-azion ls s3://azion-bucket/. s3cmd ls sem bucket lista todos os buckets, o que exige listAllBucketNames na credencial. s3cmd sync s3://source-bucket/ s3://dest-bucket/ copia apenas entre dois buckets do mesmo provedor. Outros comandos funcionam da mesma forma: s3cmd put file.png s3://my-bucket/ envia um objeto, e s3cmd get s3://my-bucket/file.png baixa um. O rclone, a AWS CLI e outras ferramentas S3 também funcionam.

Azion Console recusa um upload individual acima de 300 MB. A API e as ferramentas S3 não estão sujeitas a esse limite. Antes da migração, mapeie os buckets, os prefixos de objetos, os assets públicos e privados e a lógica de URLs assinadas. O acesso do bucket aos workloads é read_only, read_write ou restricted, e uma credencial funciona de forma independente dele. A entrega pública passa por um connector e uma aplicação, não pelo endpoint S3. Para as operações S3, consulte Compatibilidade com S3 e Use ferramentas compatíveis com S3. Para os buckets e seus objetos, consulte Crie e modifique um bucket, Faça upload e download de objetos, Use um bucket como origem e a biblioteca Storage.

Mova bancos de dados D1 para SQL Database

SQL Database usa o dialeto SQLite e é totalmente compatível com ACID. Uma instância principal recebe todas as gravações, e réplicas de leitura respondem às leituras. SQL Database está em Preview em todos os planos.

Uma função lê o banco de dados por uma conexão somente leitura com uma réplica. Azion.Sql é um global, e o import azion:sql faz o build falhar:

rows.next() retorna a próxima linha, ou null depois da última, e row.getString(i) lê uma coluna pelo índice. Um insert ou delete pela conexão falha com attempt to write a readonly database. No azion dev, Azion.Sql é undefined, então teste o código em uma função em produção. Para scripts do lado do servidor e ferramentas de build, o pacote @aziontech/sql gerencia bancos de dados pela API.

Para mover os dados, exporte o banco de dados D1 para um arquivo SQL:

Crie o banco de dados na Azion. Depois execute as instruções do dump por um destes caminhos:

• A API: envie as instruções no array statements de uma requisição POST para https://api.azion.com/v4/workspace/sql/databases/<database-id>/query. Uma instrução que falha ainda retorna HTTP 200, com uma chave error no lugar de results.
• O EdgeSQL Shell: .read dump.sql executa o script. O shell não inicia em uma instalação limpa, então verifique EdgeSQL Shell antes de depender dele. Para instalá-lo, consulte Instale o SQL Shell.

Azion CLI não tem comando para SQL Database. Para os outros formatos de importação, consulte Importe dados para SQL Database. Para a API de runtime, consulte API de runtime do SQL Database.

Proteja a aplicação com WAF

Web Application Firewall pontua as requisições em relação a oito famílias de ameaças: cross-site scripting, directory traversal, evading tricks, file upload, identified attack, remote file inclusion, SQL injection e unwanted access. Um conjunto de regras WAF guarda uma sensibilidade para cada família, e uma regra de firewall o aplica com Set WAF.

mode é obrigatório em todo comportamento Set WAF e não tem padrão. Comece em Logging para verificar o que o conjunto de regras bloquearia e depois mude para Blocking. No modo Blocking, uma requisição que o conjunto de regras bloqueia recebe 400. Para evitar que uma requisição legítima corresponda, adicione uma exceção de WAF ou use a aba Tuning.

Converta cada regra personalizada da Cloudflare em critérios de firewall. As variáveis do firewall diferem das variáveis da aplicação: o caminho é ${request_uri}, e uma faixa de endereços vai em uma Network List comparada com ${network}.

O critério ${network} requer Network Shield no firewall. Para as variáveis e os operadores, consulte Rules Engine para Firewall.

Conte com DDoS Protection

DDoS Protection está ativado em todo workload, sem nada para criar e nada para configurar. Ele mitiga ataques volumétricos, de protocolo e de camada de aplicação, como floods UDP e ICMP, SYN floods, fragmentação de pacotes, floods HTTP e slowloris, nas camadas 3, 4, 6 e 7.

Um firewall mostra a chave DDoS Protection Unmetered em Main Settings > Modules, sempre ativada. Na API, modules.ddos_protection é somente leitura. DDoS Protection não tem limiares, chaves por regra nem alertas. Para uma mitigação direcionada, escreva regras personalizadas no firewall vinculado ao workload. O Security Response Team é um add-on dos suportes Enterprise e Mission-Critical. Para os tipos de ataque, consulte Mitigação de ataques.

Network Shield é um módulo diferente do firewall. Ele compara o endereço do cliente com uma Network List de endereços IP, faixas CIDR, ASNs ou países, por meio do critério ${network}. Use-o para bloquear ou permitir conjuntos de clientes, restringir países ou aplicar rate limit a um conjunto de clientes.

Recrie o gerenciamento de bots

Bot Manager pontua cada requisição e age conforme a pontuação. Bot Manager Lite é a função do Marketplace incluída em todos os planos, e Bot Manager completo está disponível no Enterprise.

Bot Manager Lite pontua uma requisição com 26 regras estáticas, em relação a um threshold cujo padrão é 30, e executa a ação deny por padrão. Ele também pode verificar o cliente em Network Lists de reputação. Os níveis de tolerância pertencem às regras dinâmicas do Bot Manager completo, que Bot Manager Lite não tem.

Para configurar Bot Manager Lite no Azion Console:

O firewall pontua as requisições do workload. Para cada argumento, consulte Instale Bot Manager Lite e Bot Manager Lite. Para saber como uma função roda em um firewall, consulte Functions para Firewall. A proteção contra bots de terceiros também está disponível pela integração Radware Bot Manager.

Para bloquear um cliente pelo seu user agent, adicione uma regra de firewall:

${header_user_agent} requer o módulo WAF no firewall e suporta apenas matches e does not match. O firewall não tem comportamento de permissão: para isentar um cliente, adicione um critério does not match à regra de bloqueio ou ordene as regras. Um cliente pode enviar qualquer user agent, então verifique um bot legítimo de outra forma. Para verificar a regra:

A resposta é 403, com a página de erro Forbidden. Uma requisição com o user agent de um navegador recebe a resposta normal.

Recrie os rate limits

A Azion limita a taxa de requisições de duas formas, e cada uma cobre uma parte diferente do que as regras de rate limiting da Cloudflare fazem. Use o comportamento nativo Set Rate Limit de uma regra de firewall para limitar as requisições por segundo ou por minuto, por endereço IP do cliente ou entre todos os clientes. Use a integração Upstash Rate Limiting, um rate limit com penalidade executado como função de firewall, para chaves personalizadas, janelas personalizadas ou um período de penalidade.

Use o rate limit nativo

Um comportamento Set Rate Limit conta as requisições a que sua regra corresponde. Os critérios da regra definem o escopo do limite, como o caminho com ${request_uri}. Rate Limit Type é Req/s ou Req/min, e Limit By é Client IP address ou Global. Average Rate Limit aceita no mínimo 1, e Maximum Burst Size aceita no mínimo 1 e se aplica apenas a Req/s. Nenhum comportamento pode vir depois de Set Rate Limit em uma regra. Uma regra cujos critérios unem vários caminhos com or compartilha uma contagem entre todos eles.

Uma requisição além da taxa e do burst recebe 429, com a página de erro intitulada Too Many Requests. Para saber como a taxa e o burst admitem requisições, consulte Set Rate Limit.

Use o rate limit com penalidade

A função Upstash Rate Limiting mantém seus contadores em um Upstash Global Database. Por isso, ela conta cada requisição em toda a rede, e não em cada data center. Uma requisição durante uma penalidade recebe 403 Forbidden. Uma requisição válida é contada, e a função retorna 429 Too Many Requests quando a contagem atinge o limite.

Para configurá-la no Azion Console:

A função conta as requisições a que a regra corresponde. Estes argumentos definem uma sliding window de 2 requisições a cada 20 segundos, da meia-noite ao meio-dia UTC, com uma penalidade de 45 segundos:

A chave une o prefixo e cada valor que os argumentos selecionam. Neste exemplo, ela é my_rate_limit + client IP + x-a-custom-header value + hostname, como my_rate_limit_127.0.0.1_Value_azion.com. Para a configuração completa, consulte Instale a integração Upstash Rate Limiting.

Reconstrua o monitoramento

A Azion divide a observabilidade em três produtos. Real-Time Metrics mostra agregados ao longo do tempo em gráficos, Real-Time Events responde a consultas sobre requisições individuais, e Data Stream envia os logs para destinos externos.

Real-Time Metrics

Os dashboards de Applications mostram:

• Requests: total de requisições, requisições por método e por esquema e Average Request Time, o tempo médio em segundos que a Azion leva para processar e responder a uma requisição.
• Status Codes: as respostas 2XX, 3XX, 4XX e 5XX e a tabela Requests by Status and Upstream Status, que distingue erros da Azion de erros da origem.
• Data Transferred: dados e largura de banda economizados e perdidos e Edge Offload.
• Cache: Requests Offloaded, Saved Requests e Missed Requests.

Real-Time Metrics não informa latência, tempo até o primeiro byte nem tempo de resposta da origem. Para ler o status de cache das requisições, filtre um dashboard por Upstream Cache Status, cujos valores incluem HIT, MISS, STALE e EXPIRED. Para encontrar erros da origem, filtre por Upstream Status, que é 0 quando a origem não respondeu.

Para abrir os dashboards, acesse Azion Console > Real-Time Metrics. Ele abre em Build > Applications > Data Transferred, nos Last 5 minutes. Para restringir um dashboard a um workload, adicione o filtro Domain ou Workload. Para exportar um gráfico, abra seu menu More options e selecione Export CSV.

Para consultar os mesmos dados, envie uma consulta GraphQL para https://api.azion.com/v4/metrics/graphql:

Substitua as datas por um intervalo dentro do período de retenção. Um intervalo fora dele retorna um array vazio. limit aceita até 10.000 linhas e tem padrão 10. O dataset httpMetrics de consultas antigas ainda funciona, mas está obsoleto. Para cada campo, consulte Campos GraphQL do Real-Time Metrics e Crie dashboards. Para dashboards no Grafana, consulte Dashboards personalizados do plugin Grafana e dashboards pré-configurados. Para ler os dashboards, consulte Analise métricas. Para medições de usuários reais, use Edge Pulse.

Real-Time Events

Real-Time Events não precisa de configuração. Suas fontes de dados são HTTP Requests, Functions, Functions Console, Image Processor, Tiered Cache, Edge DNS, Data Stream e Activity History. Os resultados do WAF são campos de HTTP Requests.

Para consultar os eventos no Azion Console:

A tabela de resultados lista os eventos. Selecione uma linha para abrir o registro completo.

Para consultar os mesmos dados, envie uma consulta GraphQL para https://api.azion.com/v4/events/graphql. O dataset workloadEvents guarda as requisições HTTP:

Substitua as datas por um intervalo dentro dos últimos 7 dias. upstreamResponseTime mostra - para uma resposta entregue a partir do cache. Para cada campo, consulte Campos GraphQL do Real-Time Events e Investigue requisições com a API GraphQL.

Data Stream

Um stream envia uma fonte de dados para um destino:

• Armazenamento: Amazon S3, Azure Blob Storage e Azion Object Storage, pelo tipo S3.
• Monitoramento: Datadog, Splunk, Elasticsearch e Azure Monitor.
• Streaming: AWS Kinesis Data Firehose e Apache Kafka.
• Analytics: Google BigQuery.
• Segurança: IBM QRadar.
• Personalizado: Standard HTTP/HTTPS POST.

Um stream precisa de exatamente um entre sampling e um filtro de workload. Salvar um stream ativo com sampling desativa todos os outros streams da conta. Streams com filtro coexistem.

Para um destino Object Storage, a credencial precisa de listAllBucketNames, listBuckets, listFiles e writeFiles, ou todo envio falha com 503. Para os campos, consulte Configurações do stream e Endpoints. Para guias de destinos, consulte Amazon S3, Azion Object Storage, Datadog, Splunk, Elasticsearch, Kinesis, BigQuery e Configure o sampling.

Prepare o certificado

Certificate Manager guarda os certificados que os workloads servem. Prepare o certificado antes de o domínio apontar para a Azion, para que os usuários acessem o projeto por HTTPS desde a primeira requisição.

A Azion emite um certificado Let’s Encrypt sem custo adicional assim que você escolhe um preset Let’s Encrypt. Escolha o desafio conforme onde o DNS responde:

• HTTP-01 precisa que o hostname, e cada nome alternativo, já apontem para a Azion.
• DNS-01 funciona antes da migração. Em um provedor de DNS externo, adicione um CNAME de _acme-challenge.<domain> para <domain>.letsencrypt.azion.com. No Edge DNS, o registro é automático.

Para uma migração a partir da Cloudflare, use DNS-01.

Se o certificado não ficar ativo, leia seus campos status e status_detail. Para HTTP-01, verifique se o hostname aponta para a Azion. Para DNS-01, verifique o CNAME _acme-challenge. As novas tentativas continuam conforme o cronograma, então um registro corrigido emite o certificado mais tarde. Para as regras de emissão, consulte Emissão e renovação.

O mTLS precisa de um certificado Trusted CA, e um certificado gerado pela Azion não pode ser o Trusted CA. A equipe de vendas ativa o mTLS na conta. Depois defina mtls.enabled, mtls.config.certificate e verification, enforce ou permissive, no workload pela API ou com azion update workload --file. O mTLS funciona apenas por HTTPS. Para os passos, consulte Configure o mTLS em um workload e mTLS.

Mova zonas DNS para Edge DNS

Mover a zona para Edge DNS dá à Azion todos os registros do domínio, incluindo o apex. Toda zona usa os mesmos três nameservers, ns1.aziondns.net, ns2.aziondns.com e ns3.aziondns.org. Pule esta etapa quando mantiver o provedor de DNS atual e apontar apenas subdomínios, como mostra Aponte o domínio para o workload.

Recrie cada registro da Cloudflare com seu tipo:

Edge DNS recusa outros tipos, como SOA. Os registros A, AAAA, ANAME, DS, MX e NS guardam até 10 valores cada.

Com o DNSSEC ativado, Edge DNS mostra quatro valores DS: Key Tag, Algorithm 13, Digest Type 2 e Digest. Recarregue a página depois de salvar para vê-los. Adicione-os no registrador, que pode levar até 48 horas para publicá-los. Para os passos, consulte DNSSEC.

Para verificar a migração, consulte os nameservers e os registros:

O primeiro comando lista os três nameservers da Azion assim que a mudança no registrador se propaga. O segundo mostra a resposta do Edge DNS antes que a mudança chegue a todos os resolvers. Com o DNSSEC ativado, o terceiro retorna dois registros DNSKEY, com flags 257 e 256 e algoritmo 13. Não consulte um nome novo antes de o registro dele existir: Edge DNS mantém a resposta negativa em cache por uma hora. Para mais comandos, consulte Execute o comando dig e Execute o comando traceroute.

Aponte o domínio para o workload

A mudança de DNS é a virada: assim que o domínio resolve para o workload, os usuários acessam o projeto pela Azion. Trate-a como uma transição controlada. Antes da virada, confirme que:

• O certificado está ativo.
• O hostname está nos Domains do workload.
• Os registros DNS estão prontos.
• As rotas críticas e os redirecionamentos respondem como esperado no domínio do workload. Para testá-los com o hostname real antes da virada, consulte Teste uma aplicação pelo arquivo hosts.
• O monitoramento está pronto para acompanhar o tráfego depois da virada.

Aponte cada nome com o registro que sua zona permite:

Para verificar um CNAME:

A resposta é o domínio do workload, como xxxxxxxxxx.map.azionedge.net. Mudanças de DNS levam tempo para se propagar. Para as configurações do domínio personalizado no Console, consulte Aponte um domínio para um workload. Para mover os nameservers, consulte Migre os nameservers para a Azion.

Próximos passos