• 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.

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.

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:

• Activity History
• Edge Applications
• Edge Functions
• WAF Events

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:

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:

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:

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:

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:

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.

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.

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:

• Apache Kafka
• AWS Kinesis Data Firehose
• Azure Blob Storage
• Azure Monitor
• Datadog
• Elasticsearch
• Google BigQuery
• IBM QRadar
• Simple Storage Service (S3)
• Splunk
• Standard HTTP/HTTPS POST

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

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

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

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

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

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"
}

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
  • Ao usar o provedor Amazon S3 Storage, você pode usar o endpoint padrão da AWS: https://s3.amazonaws.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.

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

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"}

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.