Question

需要帮助弄清楚如何使用流利的位解析istio-log或如何使流利的位解析更“可辩驳”（哪个“位”失败）

在下面找到我的流利位配置

  input-kubernetes.conf: |
    [INPUT]
        Name              tail 
        Tag_Regex         (?<pod_name>[a-z0-9](?:[-a-z0-9]*[a-z0-9])?(?:\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*)_(?<namespace_name>[^_]+)_(?<container_name>.+)-(?<docker_id>[a-z0-9]{64})\.log$
        Tag               k8s_containers.<namespace_name>.<container_name>.<pod_name>.<docker_id>-                                                                                                                  
        Path              /var/log/containers/*.log       
        Exclude_Path      /var/log/containers/mailhog*    
        Parser            docker        
        DB                /var/log/flb_kube.db            
        Mem_Buf_Limit     5MB  
        Skip_Long_Lines   On   
        Refresh_Interval  10   

  filter-kubernetes.conf: |    
    [FILTER]
        Name                kubernetes
        Match               k8s_containers.**
        Kube_Tag_Prefix     k8s_containers.
        Kube_URL            https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}                                                                                                                             tls.verify          Off
        K8S-Logging.Parser  On 
        K8S-Logging.Exclude On 
        Merge_Log           On 
        Merge_Log_Key       log_processed
        Regex_Parser        k8s-custom-tag

    [FILTER]
        Name                istioproxy
        Match               k8s_containers.*.istio-proxy    
        Key_Name            log
        Parser              envoy

  output-elasticsearch.conf: |
    [OUTPUT]
        Name            es
        Match           *
        Host            ${FLUENT_ELASTICSEARCH_HOST}
        Port            ${FLUENT_ELASTICSEARCH_PORT}
        Logstash_Format On
        Replace_Dots    On
        Retry_Limit     False
        Time_Key        timestamp-es
        Include_Tag_Key On
        tls             On
        tls.verify      Off
        tls.crt_file    /fluent-bit/etc/certs/tls.crt
        tls.key_file    /fluent-bit/etc/certs/tls.key
        HTTP_User       elastic
        HTTP_Passwd     ${ELASTIC_PASSWORD}

<<snip>>

  parsers.conf: |
    [PARSER]
        Name    k8s-custom-tag
        Format  regex
        Regex   (?<namespace_name>[^_]+)\.(?<container_name>.+)\.(?<pod_name>[a-z0-9](?:[-a-z0-9]*[a-z0-9])?(?:\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*)\.(?<docker_id>[a-z0-9]{64})-$


    [PARSER]
        Name        nginx-ingress
        Format      regex
        Regex       ^(?<host>[^ ]*) - \[(?<real_ip>[^ ]*)\] - (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*) "(?<referer>[^\"]*)" "(?<agent>[^\"]*)" (?<request_length>[^ ]*) (?<request_time>[^ ]*) \[(?<proxy_upstream_name>[^ ]*)\] (?<upstream_addr>[^ ]*) (?<upstream_response_length>[^ ]*) (?<upstream_response_time>[^ ]*) (?<upstream_status>[^ ]*) (?<last>[^$]*)
        Time_Key    time
        Time_Format %d/%b/%Y:%H:%M:%S %z

    [PARSER]
        Name        envoy
        Format      regex
        Regex       \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)? (?<protocol>\S+)" (?<code>[^ ]*) (?<dunno1>[^ ]*) "(?<dunno2>\S+)" "(?<dunno3>\S+)" (?<maybe_bytes_sent>[^ ]*) (?<maybe_bytes_received>[^ ]*) (?<maybe_duration>[^ ]*) (?<maybe_duration2>[^ ]*) "(?<ips>[0-9\.\-,\s]*)" "(?<agent>[^\"]*)" "(?<request_id>[^\"]*)" "(?<url>[^\"]*)" "(?<destination_ip>[^\"]*)" (?<magic>[^ ]*) (?<dunno4>[^ ]*) (?<another_ip>[^ ]*) (?<another_ip2>[^ ]*) (?<magic2>[^ ]*)
        #Time_Keep   Off
        Time_Key    time
        Time_Format %Y-%m-%dT%H:%M:%S.%L

我确实有其他可行的解决方案-正确解析了nginx-ingress日志。

使用istio-proxy注入的容器，我必须自己进行解析器匹配（在这些容器上没有注释）。

我找到了一些资源，例如https://blog.donbowman.ca/2018/10/03/the-rabbit-hole-of-log-parsing-istio-proxy-sidecar-log-routing-and-parsing-with-fluent-bit/

我的特使正则表达式似乎可以通过https://regex101.com/或https://rubular.com/进行所有随机的istio-proxy日志检查

[2019-08-23T00:39:51.546Z] "GET /api/authenticate?login_challenge=30cd90e278ff4591a07e9bef80235a7b HTTP/1.1" 200 - "-" "-" 0 1284 25 25 "25.25.25.25" "Go-http-client/1.1" "57d14491b1441a5634f0354d6425b882" "login.example.com" "127.0.0.1:80" inbound|80|http|frontend.uat.svc.cluster.local - 10.233.120.18:80 25.25.25.25:0 outbound_.80_._.frontend.uat.svc.cluster.local

不幸的是，Istio-proxy日志出现在kibana中，但未解析。

帮助表示感谢！

Answer 1

在标记解析中进行了一些重大更改。检查您的kube。*。istio-proxy是否匹配。我的猜测是您现在中间有一条非常不便的路。

大约18个月前，我已对此进行了更改，因此标记为kube.namespace.pod.container，但随后将其更改为kube..namespace。这是我的猜测，标记不匹配。

请参阅https://docs.fluentbit.io/manual/installation/upgrade_notes#fluent-bit-v-1-1 ...您现在需要将原始的尾巴输入路径放入标签中。

Answer 2

在minikube集群上测试fluent-bit：v1.2.1时，我发现了相同的问题。所以我挖了一下，对envoy filter做了一些修改，但没有任何效果。

Match: kube.*.istio-proxy是问题所在。 Routing似乎很晦涩。因此，我将匹配规则更改为kube.istio-proxy.*，并将输入部分中的标记定义更改为kube.<container_name>.<namespace_name>.xxxx和解析器部分。

而且有效！

更新后：读完parser document之后，我将Reserve_Data添加到我的filter

[FILTER]
        Name                parser
        Match               kube.istio-proxy.*
        Key_Name            log
        Reserve_Data        On 
        Parser              envoy

如何使用流利的位来解析istio-proxy日志

2 个答案: