A transformação de dados organiza e enriquece seus dados de log, reduzindo o tempo de processamento e os custos operacionais. Com a configuração adequada, você pode diminuir ainda mais os custos de armazenamento em 12% a 30%.
Configuração típica
Com base nos princípios de transformação e no guia de desempenho, simplifique seu plano de coleta: ingira os dados em um ou mais Logstores e use a transformação de dados para distribuí-los. Configure o período de retenção e o índice de cada Logstore de destino conforme necessário.
Fatores de custo
Os e o método de faturamento indicam que o custo depende de três fatores:
Volume diário de ingestão de dados.
Período de retenção de dados.
Configuração de índice.
Os dois exemplos a seguir demonstram como otimizar custos ajustando a estrutura e o conteúdo do armazenamento.
Otimize a estrutura de armazenamento
Cenário base: uma aplicação grava 100 GB/dia, armazenados por 30 dias com índice de texto completo. Custo mensal: aproximadamente USD 562.
Se apenas 20% dos logs (como logs de operação e de erro) exigirem retenção de 30 dias e o rest precisar de apenas 7 dias, adote o seguinte plano de transformação:
Crie um Logstore de source para armazenar dados por 3 dias, sem índice.
Crie o Logstore de destino 1 para armazenar logs de operação e de erro por 30 dias, com índice.
Crie o Logstore de destino 2 para armazenar logs gerais por 7 dias, com índice.
O custo mensal cai para aproximadamente USD 421, gerando uma economia de cerca de 25%.
Para um cenário base de 60 dias, armazenar 20% dos logs importantes por 60 dias e o rest por 7 dias gera uma economia de 12% e dobra o período de retenção dos logs críticos.
Otimize o conteúdo de armazenamento
Considerando o mesmo cenário base (100 GB/dia, retenção de 30 dias, índice de texto completo), o custo mensal é de aproximadamente USD 562.
Exemplo de log bruto (1021 bytes):
__source__: 192.0.2.0
__topic__: ddos_access_log
body_bytes_sent: 3866
cc_action: none
cc_blocks:
cc_phase:
content_type: text/x-flv
host: www.example.com
http_cookie: i1=w1;x2=q2
http_referer: http://www.example.com
http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/192.0.2.1 Safari/537.36
http_x_forwarded_for: 192.0.2.2
https: true
isp_line: BGP
matched_host: www.example.com
method: GET
real_client_ip: 192.0.2.3
remote_addr: 192.0.2.4
remote_port: 48196
request_length: 2946
request_method: GET
request_time_msec: 78920
request_uri: /request/nvwlvvkhw
server_name: www.example.com
status: 502
time: 2019-07-22T17:40:26+08:00
ua_browser: mozilla
ua_browser_family:
ua_browser_type:
ua_browser_version: 9.0
ua_device_type:
ua_os: windows_7
ua_os_family:
upstream_addr: 192.0.2.4:80
upstream_ip: 192.0.2.5
upstream_response_time: 0.858
upstream_status: 200
user_id: st0s2b5Para manter apenas campos importantes indexados por 30 dias e descartar o rest após 3 dias, adote o seguinte plano de transformação:
Crie um Logstore de source com período de retenção de dados de 3 dias e sem índice.
Crie um Logstore de destino com período de retenção de dados de 30 dias e índice para os campos necessários.
Se o log processado corresponder a cerca de 60% do tamanho original, o custo mensal cairá para aproximadamente USD 393, resultando em uma economia de cerca de 30%.
Após a transformação, o log diminui de 1021 bytes para 618 bytes:
__source__: 192.0.2.0
__topic__: ddos_access_log
body_bytes_sent: 3866
content_type: text/x-flv
host: www.example.com
http_referer: http://www.example.com
ua_browser: mozilla
ua_browser_family:
ua_browser_type:
ua_browser_version: 9.0
ua_device_type:
ua_os: windows_7
http_x_forwarded_for: 192.0.2.2
matched_host: www.example.com
method: GET
real_client_ip: 192.0.2.3
request_length: 2946
request_uri: /request/nvwlvvkhw
status: 502
upstream_addr: 192.0.2.4:80
upstream_ip: 192.0.2.5
upstream_response_time: 0.858
upstream_status: 200
user_id: st0s2b5