Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

What is Fluent Bit?

Fluent Bit is an open-source and multi-platform log processor tool which aims to be a generic Swiss knife for logs processing and distribution (verbatim from Fluent Bit’s documentation). For more information on Fluent Bit, refer to the documentation here.

Integrating Fluent Bit with Kloudfuse stack

Refer to installation instructions for Fluent Bit here. To configure Fluent Bit to send data to Kloudfuse stack, you can modify the agent’s config or values.yaml (if you’re going to install using helm).

You’ll need to configure HTTP output plugin to forward data to Kloudfuse.

HTTP plugin integration

Add the following configuration to Fluent Bit agent’s config for HTTP configuration.

    [OUTPUT]
        Name http
        Match <match_pattern>
        Host <kfuse_ingress_ip>
        Port 443
        TLS on
        URI /ingester/v1/fluent_bit
        Format {json|json_lines|json_stream|msgpack}

Note that the Host IP/DNS name in the above configuration can be the internal or external Kloudfuse ingress IP, depending on how you’ve configured the kfuse stack.

If you’re using internal ingress, then you can port 80 to forward the data. However, if you’re using external ingress, port must be 443.

Currently msgpack, json, json_lines and json_stream are supported formats for HTTP plugin.

Configuration

Kloudfuse UI allows you to filter log events based on log labels/tags. You’ll find the label selectors and filter on the left nav bar of the UI. To get a seamless experience with Kloudfuse while using Fluent Bit agent, we recommend the following configuration(s) or customization(s).

Kubernetes Labels

Fluent Bit has a filter called kubernetes which will enrich the log event with Kubernetes metadata. Refer to the documentation on this filter here. If you have application deployed in a Kubernetes environment, we highly recommend enabling this filter for all those applications. Here’s an example configuration for this filter:

    [FILTER]
        Name kubernetes
        Match *          # Match everything
        Merge_Log On
        Keep_Log Off
        K8S-Logging.Parser On
        K8S-Logging.Exclude On

If you’re going to add any of our recommended filters, ensure that they don’t conflict with the existing filter definitions.

Cloud Labels

We recommend adding/configuring the aws filter to get the availability-zone and instance-type. Refer to the documentation for this filter here. At a minimum, we recommend the following configuration for aws filter:

    [FILTER]
        Name aws
        Match *      # Match everything
        az true
        account_id true
        ec2_instance_type true

This filter does not include the cluster name, however. We recommend adding modify filter to include the cluster name as a separate tag. Here's a sample config on how to do that:

    [FILTER]
        Name modify
        Match *     # Match everything
        Add cluster_name <CLUSTER_NAME>

Note that the key, cluster_name in the above filter is configurable too. If you use a key name other than cluster_name or clusterName, then add the following section under logs-parser section in your custom Kloudfuse’s values.yaml

extraApplicationConfigs: |-
    agent.properties.fluent-bit.user_defined_overrides.cloud.cluster_name = [<YOUR_CUSTOM_CLUSTER_NAME_KEY>]

Log source

By default, Kloudfuse stack looks for container_name in the Fluent Bit payload as the log source. However, this will only be populated if the Fluent Bit agent is configured with kubernetes filter. If you want to Kloudfuse stack to use a different key as the log source, then include the following section under logs-parser section in your custom Kloudfuse’s values.yaml

extraApplicationConfigs: |-
    agent.properties.fluent-bit.user_defined_overrides.log_source = [<YOUR_CUSTOM_LOG_SOURCE_KEY>]

Log message

Fluent Bit agent includes the log event message in log key in the payload. However this can be overriden in the agent configuration. You can customize key which Kloudfuse stack should look for to get the log event message. To customize this setting, include the following section under logs-parser section in your custom Kloudfuse’s values.yaml

extraApplicationConfigs: |-
    agent.properties.fluent-bit.user_defined_overrides.message = [<YOUR_CUSTOM_LOG_MESSAGE_KEY>]

Kloudfuse stack already looks for log message with these key names in the payload: "log", "LOG", "Log", "message", "msg", "MSG", "Message"

Agent extracted key-value pairs

Fluent Bit supports various parsers to extract key value pairs from an unstructured log. For a full list of parsers, refer to the documentation here. By default, Kloudfuse will add all these key-value pairs to log facets, which can be filtered on the UI. Note that Kloudfuse cannot differentiate between these key-value pairs and any metadata fields, added by any filter other than kubernetes and aws. However, you can customize Kloudfuse stack by adding a list of prefix labels. To customize this setting, include the following section under logs-parser section in your custom Kloudfuse’s values.yaml

extraApplicationConfigs: |-
    agent.properties.fluent-bit.tags_append_list = [<LIST_OF_CANDIDATE_TAG_KEY_PREFIXES>]

tags_append_list is a list of key prefixes. So, any key that is a prefix match at the top level json will be included as a log label/tag, and not included as a log facet.

You don’t need to include any keys specified in log_source or message or metadata fields from kubernetes or aws filter. They’re automatically treated as metadata and not included as a log facet.

  • No labels