Data Streaming

Data Streaming é um produto de Observe que permite que você alimente suas plataformas de stream, SIEM e big data com os logs de eventos de suas aplicações na Azion em tempo real. Para manter uma performance avançada, usa a codificação ASCII para evitar problemas de parser e problemas na interpretação dos dados.

Você pode escolher de quais produtos e domínios disponíveis na Azion deseja coletar seus dados de logs e conectá-los ao endpoint de sua plataforma de análise de dados. Você também pode escolher quais variáveis quer usar em sua análise.

Ao criar um data streaming, você consegue:

  • Ter um conjunto de logs organizado.
  • Conectar o seu data streaming a endpoints.
  • Entender o comportamento de seus usuários.
  • Identificar dados de ameaças à segurança.
  • Tomar decisões informadas.
  • Aperfeiçoar suas aplicações e seu negócio através de práticas confiáveis de observabilidade.

Após configurar seu data streaming, você pode conferir os seus logs de dados sendo enviados com sucesso através do Real-Time Events.

Veja os primeiros passos do Data Streaming.

TarefaGuia
Configurar data streamingComo utilizar o Data Streaming
Associar domíniosComo associar domínios no Data Streaming
Criar template personalizadoComo criar um template personalizado no Data Streaming

Por padrão, o Data Streaming envia seus logs de eventos quando o bloco com as variáveis atinge 2.000 registros, a cada 60 segundos, ou quando o tamanho do pacote atinge o valor determinado no campo Max Size do payload, o que ocorrer primeiro. No entanto, se você estiver usando o endpoint AWS Kinesis Data Firehose, o Data Streaming enviará seus logs de eventos quando o bloco atingir 500 registros ou a cada 60 segundos.

Por exemplo, se um bloco atinge 2.000 registros em 13 seconds, ele é enviado.

Ao ativar um data streaming, ocorre um tempo de propagação até que os logs fiquem disponíveis para consulta em ferramentas ou produtos como o Real-Time Events.

Para informações detalhadas sobre cada seção de configuração do Data Streaming, continue lendo as próximas subseções.


Um Data Source representa a aplicação na Azion que gera os registros de eventos que você quer usar. Ao selecionar um data source, você decide de onde seus dados vão ser coletados e as demais configurações são feitas de acordo com sua escolha.

Selecionar um data source na lista suspensa é obrigatório. Você pode escolher entre:

Cada data source tem variáveis pré-configuradas, combinadas em um template, que representam a informação específica que você pode receber dos seus registros de eventos. Veja os pré-requisitos e as variáveis de cada data source e que dados fornecem a seguir.

Não é possível associar domínios ao usar o data source Activity History.

O data source Activity History exibe os dados referentes aos registros de atividade de sua conta no RTM. As seguintes variáveis estão disponíveis para essa opção:

VariávelDescrição
$author_emailEmail do usuário do Real-Time Manager que executou a atividade.
$author_nameNome do usuário do Real-Time Manager que executou a atividade.
$clientIdentificador único de cliente Azion. Exemplo: 4529r
$commentCampo em branco disponível para que usuários possam adicionar comentários ao realizarem mudanças.
$timeData e hora da requisição. Exemplo: Oct. 31st, 2022 - 19:30:41
$titleTítulo da atividade, composto por: nome do modelo, nome e tipo de atividade. Exemplo: Pathorigin Default Origin was changed
$typeTipo de ação executada no Real-Time Manager: CREATED, CHANGED, DELETED ou SIGNED UP.

O data source Edge Applications exibe os dados das requisições feitas para suas edge applications na Azion. As seguintes variáveis estão disponíveis para essa opção:

VariávelDescrição
$asnAutonomous System Number Allocation (ASN), que são redes de endereços IP gerenciadas por uma ou mais operadoras de rede que têm uma política de roteamento clara e única. Exemplo: AS52580
$bytes_sentNúmero de bytes enviados para o cliente. Exemplo: 191
$clientIdentificador único de cliente Azion. Exemplo: 4529r
$configurationIdentificador único de configuração Azion definido no arquivo de configuração do virtual host. Exemplo: 1595368520
$countryPaís do cliente detectado pela geolocalização de endereço IP. Exemplo: United States
$hostInformação de host enviada na linha da requisição. Armazena: nome do host da linha da requisição, ou o nome do host do campo Host do campo host do cabeçalho, ou o nome do servidor correspondente à requisição.
$http_referrerEndereço da página na qual o usuário fez a requisição. Valor do cabeçalho Referer. Exemplo: https://example.com
$http_user_agentIdentificação da aplicação, do sistema operacional, do fornecedor, e/ou da versão do usuário final. Valor do cabeçalho User-Agent. Exemplo: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
$proxy_statusCódigo de status de erro HTTP ou da origem quando nenhuma resposta é obtida da origem. Exemplo: 520. Em caso de cache, a resposta é -.
$remote_addrEndereço IP da origem que gerou a requisição.
$remote_portPorta remota da origem que gerou a requisição.
$request_idIdentificador único da requisição. Exemplo: 5f222ae5938482c32a822dbf15e19f0f
$request_lengthTamanho da requisição, incluindo a linha da requisição, cabeçalhos e corpo.
$request_methodMétodo da requisição. Exemplo: GET ou POST
$request_timeTempo de processamento da requisição decorrido desde que os primeiros bytes foram lidos a partir do cliente com resolução de milisegundos. Exemplo: 1.19
$request_uriURI da requisição realizada pelo usuário, sem a informação do host e de protocolo e com argumentos. Exemplo: /v1?v=bo%20dim
$requestPathURI da requisição sem a informação de Query String, Host e Protocol. Exemplo: se request_uri: /jira/plans/48/scenarios/27?vop=320#plan/backlog, então requestPath: /jira/plans/48/scenarios/27
$requestQueryParâmetros da URI da requisição. Exemplo: requestQuery: vid=320#plan/backlog
$schemeEsquema da requisição. Exemplo: HTTP ou HTTPS
$sent_http_content_typeCabeçalho “Content-Type” enviado na resposta da origem. Exemplo: text/html; charset=UTF-8.
$sent_http_x_original_image_sizeCabeçalho “X-Original-Image-Size” enviado na resposta da origem. Informa o tamanho da imagem original. Exemplo: 987390
$server_addrEndereço IP do servidor que recebeu a requisição.
$server_portPorta remota do servidor que recebeu a requisição.
$server_protocolProtocolo da requisição. Exemplo: HTTP/1.1, HTTP/2.0, HTTP/3.0
$session_idIdentificação da sessão.
$ssl_cipherString de cifra utilizada para estabelecimento de conexão TLS. Exemplo: TLS_AES_256_GCM_SHA384
$ssl_protocolProtocolo de uma conexão TLS estabelecida. Exemplo: TLS v1.2
$ssl_server_nameNome do servidor, informado pelo cliente, que o cliente está tentando conectar. Exemplo: www.example.com
$ssl_session_reusedRetorna r se a sessão TLS for reutilizada; nos demais casos, retorna ..
$stateEstado do cliente detectado pela geolocalização de endereço IP. Exemplo: CA
$statusCódigo de status HTTP da requisição. Exemplo: 200
$streamID definida através de configuração de host virtual com base na diretiva de localização. Definido no arquivo de configuração do host virtual.
$tcpinfo_rttTempo de Round-Trip Time (RTT) medido pelo edge para o usuário. Disponível em sistemas que suportam a opção TCP_INFO socket.
$timeData e hora da requisição. Exemplo: Oct. 31st, 2022 - 19:30:41
$tracebackInforma os nomes dos Rules Engine do Edge Application e do Edge Firewall executadas pela requisição.
$upstream_addrEndereço IP e porta do cliente. Também pode armazenar múltiplos servidores ou grupos de servidores. Exemplo: 192.168.1.1:80. Quando a resposta é 127.0.0.1:1666, o upstream é o Azion Cells Runtime.
$upstream_bytes_receivedNúmero de bytes recebidos pelo edge da origem, se o conteúdo não estiver em cache. Exemplo: 8304
$upstream_bytes_sentNúmero de bytes enviados para a origem. Exemplo: 2733
$upstream_cache_statusStatus do cache local do edge. Exemplo: MISS, BYPASS, EXPIRED, STALE, UPDATING, REVALIDATED ou HIT.
$upstream_connect_timeTempo, em milisegundos, para o edge estabelecer uma conexão com a origem. No caso de TLS, inclui tempo gasto em handshake. 0 no caso de KeepAlive e - no caso de cache.
$upstream_header_timeTempo, em milissegundos, para que o edge receba os cabeçalhos de resposta da origem. Exemplo: 0.345. No caso de cache, a resposta é -.
$upstream_response_timeTempo, em milisegundos, para o edge receber uma resposta padrão da origem, incluindo cabeçalhos e corpo. Exemplo: 0.876. No caso de cache, a resposta é -.
$upstream_statusCódigo de status HTTP da origem. Se um servidor não pode ser selecionado, a variável mantém o código de status 502 (Bad Gateway). No caso de cache, a resposta é -.
$waf_attack_actionInforma a ação do WAF em relação à ação. Pode ser: $BLOCK, $PASS, $LEARNING_BLOCK ou $LEARNING_PASS.
$waf_attack_familyInforma a classificação da infração de WAF detectada na requisição. Exemplo: SQL, XSS, TRAVERSAL, entre outras.
$waf_blockInforma se o WAF bloqueou ou não a ação. 0 quando não bloqueado e 1 quando bloqueado. Quando em Learning Mode, ele não será bloqueado, independentemente do retorno.
$waf_headersQuando os cabeçalhos de solicitação enviados pelo usuário são analisados pelo módulo WAF e marcados como blocked, $waf_block = 1. Tem uma string codificada em base64. Caso contrário, ele terá um traço -. Aplica-se aos modos WAF Learning ou Blocking.
$waf_learningInforma se o WAF está em Learning Mode. Pode ser 0 ou 1.
$waf_matchLista de infrações encontradas na requisição do usuário final. É formada por elementos chave-valor: a chave é referente ao tipo de infração detectada; o valor apresenta a string que gerou a infração.
$waf_scoreInforma a pontuação que será incrementada em caso de match com as regras criadas para o WAF.
$waf_total_blockedInforma o número total de requisições bloqueadas.
$waf_total_processedInforma o número total de requisições processadas.

As variáveis: $upstream_bytes_received; $upstream_cache_status; $upstream_connect_time; $upstream_header_time; $upstream_response_time e $upstream_status podem apresentar mais de um elemento separado por vírgula. Quando uma conexão é disparada, seja por redirecionamento interno ou escolha de origem com Load Balancer, por exemplo, cada valor contido no campo representa a respectiva conexão iniciada. O campo pode ser separado por:

  • Uma vírgula, representando múltiplos IPs.
  • Dois-pontos, representando redirecionamento interno.

Se vários servidores foram contatados durante o processamento da solicitação, seus endereços são separados por vírgulas, por exemplo: 192.168.1.1:80, 192.168.1.2:80.

Se ocorre um redirecionamento interno de um grupo de servidores para outro, iniciado por X-Accel-Redirect ou Error Responses, os endereços de servidores de diferentes grupos são separados por dois-pontos. Exemplo: 192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80.

Se um servidor não puder ser selecionado, a variável mantém o nome do grupo de servidores.

Considerando vários valores como transições na conexão, o último valor tende a ser o mais importante. Se você usa o recurso Error Responses nas suas edge applications, você verá dois valores nos campos upstream que representam o status da origem e o resultado da solicitação feita para que o conteúdo seja entregue. Em casos normais, você terá 502: 200.

502 é o código de erro HTTP para a resposta da primeira tentativa de obter conteúdo do servidor de origem. Como ele retornou um erro 502, considerando que você configurou uma Error Responses para o status 502, outra solicitação será feita para que o URI seja definido. Em seguida, a página será entregue e o status HTTP será adicionado aos campos upstream, respeitando sua posição para todos eles. Neste exemplo, o resultado é a composição 502 : 200.


Requer: Edge Functions

O data source Edge Functions exibe os dados referentes às solicitações feitas para suas edge functions na Azion.

As seguintes variáveis estão disponíveis para essa opção:

VariávelDescrição
$clientIdentificador único de cliente Azion. Exemplo: 4529r
$edge_function_idIdentificador da Edge Function. Exemplo: 1321
$global_idIdentificador da configuração.
$log_levelNível do log gerado: ERROR, WARN, INFO, DEBUG ou TRACE.
$log_messageMensagem editável usada para o log na chamada da função. Disponível para usuários identificarem e reportarem acontecimentos.
$message_sourceFonte da mensagem. Quando as mensagens são geradas pela API do Console: CONSOLE; quando são relacionadas a uma mensagem de erro: RUNTIME.
$request_idIdentificador único da requisição. Exemplo: 5f222ae5938482c32a822dbf15e19f0f
$timeData e hora da requisição. Exemplo: Oct. 31st, 2022 - 19:30:41

Requer: Web Application Firewall

O data source WAF Events exibe os dados referentes às requisições analisadas pelo Web Application Firewall (WAF) para que você possa mapear a pontuação atribuída à requisição, às regras de WAF que deram match e aos motivos do bloqueio.

As seguintes variáveis estão disponíveis para essa opção:

VariávelDescrição
$blockedInforma se o WAF bloqueou ou não a ação. 0 quando não bloqueado e 1 quando bloqueado. Quando em Learning Mode, ele não será bloqueado, independentemente do retorno.
$clientIdentificador único de cliente Azion. Exemplo: 4529r
$configurationIdentificador único de configuração Azion definido no arquivo de configuração do virtual host. Exemplo: 1595368520
$countryPaís do cliente detectado pela geolocalização de endereço IP. Exemplo: United States
$headersQuando os cabeçalhos de solicitação enviados pelo usuário são analisados pelo módulo WAF e marcados como blocked, $waf_block = 1. Tem uma string codificada em base64. Caso contrário, ele terá um traço -. Aplica-se aos modos WAF Learning ou Blocking.
$hostInformação de host enviada na linha da requisição. Armazena: nome do host da linha da requisição, ou o nome do host do campo Host do campo host do cabeçalho, ou o nome do servidor correspondente à requisição.
$remote_addrEndereço IP da origem que gerou a requisição.
$requestPathURI da requisição sem a informação de Query String, Host e Protocol. Exemplo: se request_uri: /jira/plans/48/scenarios/27?vop=320#plan/backlog, então requestPath: /jira/plans/48/scenarios/27
$requestQueryParâmetros da URI da requisição. Exemplo: requestQuery: vid=320#plan/backlog
$server_protocolProtocolo da requisição. Exemplo: HTTP/1.1, HTTP/2.0, HTTP/3.0
$timeData e hora da requisição. Exemplo: Oct. 31st, 2022 - 19:30:41
$truncated_bodyEssa variável foi descontinuada. Portanto, não terá um valor atribuído à ela, apenas - no lugar de um valor.
$versionA versão de Azion Log usada. Exemplo: v5
$waf_argsArgumentos da requisição.
$waf_attack_actionInforma a ação do WAF em relação à ação. Pode ser: $BLOCK, $PASS, $LEARNING_BLOCK ou $LEARNING_PASS.
$waf_attack_familyInforma a classificação da infração de WAF detectada na requisição. Exemplo: SQL, XSS, TRAVERSAL, entre outras.
$waf_learningInforma se o WAF está em modo Learning. Pode ser 0 ou 1.
$waf_matchLista de infrações encontradas na requisição do usuário final. É formada por elementos chave-valor: a chave é referente ao tipo de infração detectada; o valor apresenta a string que gerou a infração.
$waf_scoreInforma a pontuação que será incrementada em caso de match com as regras criadas para o WAF.
$waf_serverHostname usado na requisição de WAF. Exemplo: api-login.azion.com.br
$waf_uriURI usada na requisição do WAF. Exemplo: /access/v2/after-login

Um template no Data Streaming fornece o conjunto de variáveis pré-configuradas disponíveis para cada data source em um formato adequado para a transferência dos seus registros de eventos. Após selecionar o seu data source, você pode:

  • Selecionar o template correspondente, fornecido pela Azion.
  • Personalizar seu próprio template, escolhendo quais variáveis quer usar.

Você encontra quatro templates fornecidos pela Azion e um Custom Template, que permite que você decida quais variáveis serão usadas. Os templates estão disponíveis na lista suspensa Template e as variáveis para os templates são exibidas no campo de código Data Set em formato JSON.

Veja qual template corresponde a qual data source:

Data SourceTemplate
Activity HistoryActivity History Collector
Edge ApplicationsEdge Applications + WAF Event Collector
Edge FunctionsEdge Functions Event Collector
WAF EventsWAF Event Collector
TodosCustom Template

Ao selecionar um dos templates fornecidos pela Azion, você não consegue modificar as variáveis exibidas no campo de código Data Set. Ao selecionar Custom Template, você consegue personalizar quais variáveis quer usar de acordo com suas necessidades.

Como criar um template personalizado

Você pode associar os seus domínios existentes registrados na Azion ao seu data streaming. Se você ainda não tem um domínio registrado na sua conta, veja a documentação sobre Criar um novo domínio associado a sua edge application.

Ao associar um domínio, os eventos relacionados a esse ou a esses domínios específicos são coletados e enviados para seu endpoint. Você pode associar um ou mais domínios e você tem a opção de filtrar domínios com Filter Domains ou selecionar todos os domínios com All Domains.

Ao selecionar All Domains, a plataforma seleciona automaticamente todos os domínios atuais e futuros de sua conta no RTM.

Como associar domínios

Se você selecionar a opção All Domains, você também pode configurar a porcentagem de dados que quer receber, de forma aleatória, do seu data streaming através da opção de Sampling. Além de filtrar por amostra, a opção também reduz custos de coleta e análise de dados.

O campo Sampling (%) deve conter a porcentagem de dados que quer receber. Essa porcentagem retornará dados relacionados a todos os seus domínios.

Quando a opção de Sampling está habilitada, você só pode adicionar um data streaming em sua conta. Após esse data streaming ser desabilitado, a opção Add Streaming é habilitada novamente na tela do Data Streaming no RTM.


O endpoint é o destino para onde você quer enviar os dados coletados pela Azion, que costuma ser uma plataforma de processamento de stream ou uma ferramenta de análise que você já usa. O tipo de endpoint representa o método que você quer configurar como destino para os seus dados.

A Azion suporta os seguintes endpoints:

Para configurar um endpoint, você deve selecionar um Endpoint Type na lista suspensa do RTM. Em seguida, você deve preencher os campos apresentados de acordo com sua escolha de tipo de endpoint.

Veja mais sobre cada um dos endpoints disponíveis e seus campos a seguir. Campos marcados com asterisco * no RTM são obrigatórios.


Para configurar o endpoint Apache Kafka, você deve ter acesso à plataforma para obter as seguintes informações:

  • Bootstrap Servers: os servidores — hosts e portas — no cluster do Kafka. Você pode adicionar um ou mais servidores Kafka separando-os com vírgula , e sem espaços. Devem estar neste formato: myownhost.com:2021,imaginaryhost.com:4525,anotherhost:4030.

Não é necessário incluir todos os servidores de seu cluster nesse campo, mas apenas alguns dos servidores que serão usados para a conexão inicial.

  • Kafka Topic: nome do tópico do seu cluster Kafka para o qual o Data Streaming deve enviar mensagens. Este campo aceita apenas um tópico. Exemplo: azure.analytics.fct.pageviews.0

  • Transport Layer Security (TLS): opção para fazer envios criptografados usando o Transport Layer Security (TLS). O TLS é um protocolo criptográfico projetado para fornecer segurança de comunicação em uma rede de computadores e é amplamente usado como uma camada de segurança de HTTP. Para usar a opção, selecione Yes.

Se você deseja usar esse protocolo, certifique-se de que o endpoint que irá receber os dados esteja devidamente protegido com um certificado digital emitido por uma _Certificate Authority (CA)* reconhecida globalmente, como IndenTrust, DigiCert, Sectigo, GoDaddy, GlobalSign ou Let’s Encrypt.

A variável de TLS use_tls recebe true ou false para ativar/desativar seu uso.


Para configurar o endpoint AWS Kinesis Data Firehose, você deve ter acesso à plataforma para obter as seguintes informações:

  • Stream Name: refere-se ao nome do stream que o usuário definiu ao criar o Kinesis Data Firehose. Exemplo: MyKDFConnector_`
  • Region: refere-se à região para a qual vamos enviar os dados. Exemplo: us-east-1.
  • Access Key: refere-se à chave pública para acessar o Data Firehose, que é fornecida pela AWS. Exemplo: ORIA5ZEH9MW4NL5OITY4
  • Secret Key: refere-se à chave secreta para acessar o Data Firehose, que é fornecida pela AWS. Exemplo: +PLjkUWJyOLth3anuWXcLLVrMLeiiiThIokaPEiw
Como utilizar o AWS Kinesis Data Firehose para receber dados

Para configurar o endpoint Azure Blob Storage, você deve ter acesso à plataforma para obter as seguintes informações:

  • Storage Account: nome da conta de armazenamento que você definiu no Blob Storage. Exemplo: mystorageaccount
  • Container Name: nome do container de armazenamento que você definiu no Blob Storage. Exemplo: mycontainer
  • Blob SAS Token: token gerado pelo Blob Storage. Deve ter acesso concedido para criar, ler, escrever e listar. Exemplo: sp=oiuwdl&st=2022-04-14T18:05:08Z&se=2026-03-02T02:05:08Z&sv=2020-08-04&sr=c&sig=YUi0TBEt7XTlxXex4Jui%2Fc88h6qAgMmCY4XIXeMvxa0%3F
Como utilizar o Azure Blob Storage para receber dados

Para configurar o endpoint Azure Monitor, você deve ter acesso à plataforma para obter as seguintes informações:

  • Log Type: o tipo de registro dos dados que estão sendo enviados. Pode conter apenas letras, números, o caractere underline (_) e não pode exceder 100 caracteres. Exemplo: AzureMonitorTest
  • Shared Key: chave compartilhada do Workspace no Azure Monitor. Exemplo: OiA9AdGr4As5Iujg5FAHsTWfawxOD4
  • Time Generated Field: é usado para gerar o campo TimeGenerated, que traz quanto tempo levará para que o registro fique disponível após ser coletado. Quando não especificado, usa o tempo de ingestão. Exemplo: myCustomTimeField
  • Workspace ID: ID do seu Workspace no Azure Monitor. Exemplo: kik73154-0426-464c-aij3-eg6d24u87c50
Como utilizar o Azure Monitor para receber dados

Para configurar o endpoint Datadog, você deve ter acesso à plataforma para obter as seguintes informações:

  • Datadog URL: a URL ou a URI do seu endpoint no Datadog. Exemplo: https://inputs.splunk-client.splunkcloud.com:1337/services/collector
  • API Key: chave de API gerada no dashboard do Datadog. Exemplo: ij9076f1ujik17a81f938yhru5g713422
Como utilizar o Datadog para receber dados

Para configurar o endpoint Elasticsearch, você deve ter acesso à plataforma para obter as seguintes informações:

  • Elasticsearch URL: endereço da URL + index do ElasticSearch que irá receber os dados coletados. Exemplo: https://elasticsearch-domain.com/myindex
  • API Key: chave base64 fornecida pelo Elasticsearch. Exemplo: VuaCfGcBCdbkQm-e5aOx:ui2lp2axTNmsyakw9tvNnw
Como utilizar o Elasticsearch para receber dados

Para configurar o endpoint Google BigQuery, você deve ter acesso à plataforma para obter as seguintes informações:

  • Project ID: ID do seu projeto no Google Cloud. Exemplo: mycustomGBQproject01
  • Dataset ID: ID do seu dataset no Google BigQuery. Ele é único por projeto e diferencia maiúsculas de minúsculas. Exemplo: myGBQdataset
  • Table ID: nome escolhido para a tabela no Google BigQuery. Exemplo: mypagaviewtable01
  • Service Account Key: arquivo JSON fornecido pelo Google Cloud. Ele possui o seguinte formato:
{
"type": "service_account",
"project_id": "mycustomGBQproject01",
"private_key_id": "key-id",
"private_key": "-----BEGIN PRIVATE KEY-----\nprivate-key\n-----END PRIVATE KEY-----\n",
"client_email": "service-account-email",
"client_id": "client-id",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/service-account-email"
}
Como utilizar o Google BigQuery para receber dados

Para configurar o endpoint IBM Qradar, você deve ter acesso à plataforma para obter as seguintes informações:

  • URL: URL configurada em sua plataforma que irá receber os dados.

Você pode usar qualquer tipo de provedor de S3 (Simple Storage Service) de sua escolha. Para configurar o endpoint S3, você deve ter acesso à plataforma escolhida para obter as seguintes informações:

  • Host URL: URL do seu Host S3. Exemplo: https://myownhost.s3.us-east-1.myprovider.com
  • Bucket Name: nome do bucket para o qual o objeto será enviado. Exemplo: mys3bucket
    • O bucket deve ser criado antes de habilitar o Data Streaming a enviar os objetos.
  • Region: região na qual o bucket está hospedado. Exemplo: us-east-1
  • Access Key: chave pública para acesso ao bucket fornecida pelo seu provedor. Exemplo: ORIA5ZEH9MW4NL5OITY4
  • Secret Key: à chave secreta para acesso ao bucket fornecida pelo seu provedor. Exemplo: +PLjkUWJyOLth3anuWXcLLVrMLeiiiThIokaPEiw
  • Object Key Prefix: prefixo que você pode adicionar aos arquivos que serão enviados. Os nomes dos objetos são compostos de Prefixo + Timestamp + UUID. Exemplo: se você usar waf_logs como prefixo, um dos objetos enviados será salvo como waf_logs_1622575860091_37d66e78-c308-4006-9d4d-1c013ed89276
  • Content Type: formato em que o objeto será criado no bucket. É possível escolher entre plain/text ou application/gzip.
Como utilizar o Amazon S3 para receber dados

Para configurar o endpoint Splunk, você deve ter acesso à plataforma para obter as seguintes informações:

  • Splunk URL: URL que irá receber os dados coletados. Se você tiver um índice alternativo para indicar, pode adicioná-lo no final da URL. Exemplo: https://inputs.splunkcloud.com:8080/services/collector?index=myindex
  • API Key: token do HTTP Event Collector, fornecido pela instalação do Splunk. Exemplo: crfe25d2-23j8-48gf-a9ks-6b75w3ska674
Como utilizar o Splunk para receber dados

Para personalizar esse endpoint, você deve obter as seguintes informações:

  • Endpoint URL: URL que irá receber os dados. Exemplo: https://app.domain.com/
  • Custom Headers (opcional): o nome e o valor para cada cabeçalho para enviar para o endpoint. Você pode informar um ou mais cabeçalhos customizados para a sua requisição HTTP/HTTPS. Exemplo: header-name:value

Requer: Endpoint Standard HTTP/HTTPS POST

Ao usar o endpoint Standard HTTP/HTTPS POST, o payload para o seu endpoint não é pré-definido. Você tem a opção de personalizar as informações essenciais que serão enviadas em seus dados da forma que achar melhor.

Para personalizar o payload enviado pelo conector no Data Streaming, você tem os seguintes campos:

  • Max Size (opcional): define, em bytes, o tamanho de pacotes de dados que serão enviados. Aceita valores a partir de 1000000.
  • Log Line Separator (opcional): define que informação será usada no fim de cada linha de registro (log). Usado para quebrar informações em linhas diferentes.
  • Payload Format (opcional): define qual informação será enviada em seus dados para cada requisição de data streaming.

Por padrão, o Data Streaming recomenda o formato NDJSON com o uso de \n como um log line separator e $dataset como payload format, que usa as informações fornecidas no campo de código Data Set, descrevendo as variáveis escolhidas como template.

Você pode escolher outras opções para ambos os campos. Dependendo dos tipos de seus registros, você pode usar , como log line separator, por exemplo.

O formato NDJSON não usa os arrays típicos de JSON [], e cada dado é apresentado em uma linha diferente, sem vírgula separando-as. Ele pode ser útil para dados estruturados com processamentos de um registro por vez. Já o formato JSON é o mais conhecido e possui tabulação de dados, usando arrays [] e sendo separado por vírgulas. Com ele, o payload pode ser tratado como um registro individual.

Por exemplo, se o Log Line Separator receber , e o Payload Format receber [$dataset], e o template tem as seguintes variáveis no campo de código Data Set:

$request_method
$host
$status

Você receberá uma resposta em JSON semelhante a isso:

[
{
"request_method": "GET",
"host": "www.onedomain.com",
"status": "200"
},
{
"request_method": "POST",
"host": "www.anotherdomain.com.br",
"status": "200"
}
]

Mas se o Log Line Separator receber \n e o Payload Format receber $dataset, você receberá uma resposta em NDJSON semelhante a isso:

{"request_method": "GET", "host": "www.onedomain.com", "status": "200"}
{"request_method": "POST", "host": "www.anotherdomain.com.br", "status": "200"}

Payload personalizado com Activity History

Seção intitulada Payload personalizado com Activity History

Você pode personalizar o payload com informações específicas se você está usando o data source Activity History e o endpoint Standard HTTP/HTTPS POST.

As seguintes informações devem ser usadas nos campos de payload para configurá-lo:

  • Log Line Separator: \n
  • Payload Format: ‘v1\t$time_iso8601\t$clientid\t$title\t$comment\t$type\t$author_name\t$author_email’

Os servidores do Data Streaming funcionam em duas etapas: monitoram os endpoints uma vez por minuto (1x/min) e declaram o endpoint como available, disponível, ou unavailable, indisponível.

O Data Streaming tenta enviar mensagens para endpoints que estão available. Se o endpoint estiver unavailable, as mensagens não são enviadas, pois as informações são descartadas. No minuto seguinte, o Data Streaming faz o envio dos dados novamente se o endpoint ficar available.

Para ser considerado como available, o endpoint deve ser aprovado por todos os servidores da Azion. Se um dos servidores indicar que o endpoint está unavailable, as mensagens não são enviadas.

Ocorre quando o endpoint responde ao teste com sucesso, mas não recebe as mensagens dentro do tempo de timeout: 20 segundos para endpoints do tipo HTTP POST.

Ocorre quando o endpoint é declarado como unavailable, indisponível, pela monitoração do endpoint. Portanto, o Data Streaming não tenta enviar as mensagens.

Como o sistema é distribuído, não é possível saber qual o servidor específico que envia as mensagens para cada endpoint.




Contributors