Flowlogs2metrics - Transform flow logs into metrics

Overview

Flow-Logs to Metrics (a.k.a. FL2M) is an observability tool that consumes raw network flow-logs and transforms them from their original format (NetFlow or IPFIX) into prometheus numeric metrics format. FL2M allows to define mathematical transformations to generate condense metrics that encapsulate network domain knowledge.

In addition, FL2M decorates the metrics with context, allowing visualization layers and analytics frameworks to present network insights to SRE’s, cloud operators and network experts.

Along with Prometheus and its ecosystem tools such as Thanos, Cortex etc., FL2M provides efficient scalable multi-cloud solution for comprehensive network analytics that rely solely based on metrics data-source.

Default metrics are documented here docs/metrics.md.

Note: prometheus eco-system tools such as Alert Manager can be used with FL2M to generate alerts and provide big-picture insights.

Data flow

Usage

Expose network flow-logs from metrics  
  
Usage:  
  flowlogs2metrics [flags]  
  
Flags:  
      --config string                          config file (default is $HOME/.flowlogs2metrics)  
  -h, --help                                   help for flowlogs2metrics  
      --log-level string                       Log level: debug, info, warning, error (default "error")  
      --pipeLine.ingest.collector string       Ingest collector API  
      --pipeline.decode.type string            Decode type: aws, json, none (default "none")  
      --pipeline.encode.prom string            Prometheus encode API  
      --pipeline.encode.type string            Encode type: prom, none (default "none")  
      --pipeline.extract.aggregates string     Aggregates (see docs)  
      --pipeline.extract.type string           Extract type: aggregates, none (default "none")  
      --pipeline.ingest.aws.fields strings     aws fields  
      --pipeline.ingest.file.filename string   Ingest filename (file)  
      --pipeline.ingest.type string            Ingest type: file, collector,file_loop (required)  
      --pipeline.transform string              Transforms (list) API (default "[{"type": "none"}]")  
      --pipeline.write.type string             Write type: stdout, none (default "none")

Note: for API details refer to docs/api.md.

Configuration generation

flowlogs2metrics network metrics configuration ( --config flag) can be generated automatically using the confGenerator utility. confGenerator aggregates information from multiple user provided network metric definitions into flowlogs2metrics configuration. More details on confGenerator can be found in docs/confGenrator.md.

To generate flowlogs2metrics configuration execute:

make generate-configuration
make dashboards

Deploy into OpenShift (OCP)

To deploy FL2M on OCP perform the following steps:

  1. Deploy OCP and make sure kubectl works with the cluster
kubectl get namespace openshift
  1. Deploy FL2M (into default namespace)
kubectl config set-context --current --namespace=default
make deploy
  1. Enable export OCP flowlogs into FL2M
flowlogs2metrics_svc_ip=$(kubectl get svc flowlogs2metrics -o jsonpath='{.spec.clusterIP}')
./hack/enable-ocp-flow-export.sh $flowlogs2metrics_svc_ip
  1. Verify flowlogs are captured
kubectl logs -l app=flowlogs2metrics -f

Deploy with Kind and netflow-simulator (for development and exploration)

These instructions apply for deploying FL2M development and exploration environment with kind and netflow-simulator, tested on Ubuntu 20.4 and Fedora 34.

  1. Make sure the following commands are installed and can be run from the current shell:
    • make
    • go (version 1.17)
    • docker
  2. To deploy the full simulated environment which includes a kind cluster with FL2M, Prometheus, Grafana, and netflow-simulator, run (note that depending on your user permissions, you may have to run this command under sudo):
    make local-deploy
    If the command is successful, the metrics will get generated and can be observed by running (note that depending on your user permissions, you may have to run this command under sudo):
    kubectl logs -l app=flowlogs2metrics -f
    The metrics you see upon deployment are default and can be modified through configuration described later.

Technology

FL2M is a framework. The main FL2M object is the pipeline. FL2M pipeline can be configured (see Configuration section) to extract the flow-log records from a source in a standard format such as NetFLow or IPFIX, apply custom processing, and output the result as metrics (e.g., in Prometheus format).

Architecture

The pipeline is constructed of a sequence of stages:

  • ingest - obtain flows from some source, one entry per line
  • decode - parse input lines into a known format, e.g., dictionary (map) of AWS or goflow data
  • transform - convert entries into a standard format; can include multiple transform stages
  • extract - derive a set of metrics from the imported flows
  • encode - make the data available in appropriate format (e.g. prometheus)
  • write - provide the means to transfer the data to some target, e.g. prometheus, object store, standard output, etc

The encode and write stages may be combined in some cases (as in prometheus), in which case write is set to none

It is expected that the ingest module will receive flows every so often, and this ingestion event will then trigger the rest of the pipeline. So, it is the responsibility of the ingest module to provide the timing of when (and how often) the pipeline will run.

Configuration

It is possible to configure flowlogs2metrics using command-line-parameters, configuration file, environment variables, or any combination of those options.

For example:

  1. Using command line parameters: ./flowlogs2metrics --pipeline.ingest.type file --pipeline.ingest.file.filename hack/examples/ocp-ipfix-flowlogs.json
  2. Using configuration file:
  • create under $HOME/.flowlogs2metrics.yaml the file:
pipeline:
  ingest:
    type: file
    file:
      filename: hack/examples/ocp-ipfix-flowlogs.json
  • execute ./flowlogs2metrics
  1. using environment variables:
  • set environment variables
export FLOWLOGS2METRICS_PIPELINE_INGEST_TYPE=file
export FLOWLOGS2METRICS_PIPELINE_INGEST_FILE_FILENAME=hack/examples/ocp-ipfix-flowlogs.json
  • execute ./flowlogs2metrics

Syntax of portions of the configuration file

Supported stage types

Supported options and stage types are provided by running:

flowlogs2metrics --help

Transform

Different types of inputs come with different sets of keys. The transform stage allows changing the names of the keys and deriving new keys from old ones. Multiple transforms may be specified, and they are applied in the order of specification. The output from one transform becomes the input to the next transform.

Transform Generic

The generic transform module maps the input json keys into another set of keys. This allows to perform subsequent operations using a uniform set of keys. In some use cases, only a subset of the provided fields are required. Using the generic transform, we may specify those particular fields that interest us.

For example, suppose we have a flow log with the following syntax:

{"Bytes":20800,"DstAddr":"10.130.2.2","DstPort":36936,"Packets":400,"Proto":6,"SequenceNum":1919,"SrcAddr":"10.130.2.13","SrcHostIP":"10.0.197.206","SrcPort":3100,"TCPFlags":0,"TimeFlowStart":0,"TimeReceived":1637501832}

Suppose further that we are only interested in fields with source/destination addresses and ports, together with bytes and packets transferred. The yaml specification for these parameters would look like this:

pipeline:
  transform:
    - type: generic
      generic:
        rules:
        - input: Bytes
          output: bytes
        - input: DstAddr
          output: dstAddr
        - input: DstPort
          output: dstPort
        - input: Packets
          output: packets
        - input: SrcAddr
          output: srcAddr
        - input: SrcPort
          output: srcPort
        - input: TimeReceived
          output: timestamp

Each field specified by input is translated into a field specified by the corresponding output. Only those specified fields are saved for further processing in the pipeline. Further stages in the pipeline should use these new field names. This mechanism allows us to translate from any flow-log layout to a standard set of field names. If the input and output fields are identical, then that field is simply passed to the next stage. For example:

pipeline:
  transform:
    - type: generic
      generic:
        rules:
        - input: DstAddr
          output: dstAddr
        - input: SrcAddr
          output: srcAddr
    - type: generic
      generic:
        rules:
        - input: dstAddr
          output: dstIP
        - input: dstAddr
          output: dstAddr
        - input: srcAddr
          output: srcIP
        - input: srcAddr
          output: srcAddr

Before the first transform suppose we have the keys DstAddr and SrcAddr. After the first transform, we have the keys dstAddr and srcAddr. After the second transform, we have the keys dstAddr, dstIP, srcAddr, and srcIP.

Transform Network

transform network provides specific functionality that is useful for transformation of network flow-logs:

  1. Resolve subnet from IP addresses
  2. Resolve known network service names from port numbers and protocols
  3. Perform simple mathematical transformations on field values
  4. Compute geo-location from IP addresses
  5. Resolve kubernetes information from IP addresses
  6. Perform regex operations on field values

Example configuration:

pipeline:
  transform:
    - type: network
      network:
        KubeConfigPath: /tmp/config
        rules:
        - input: srcIP
          output: srcSubnet
          type: add_subnet
          parameters: /24
        - input: value
          output: value_smaller_than10
          type: add_if
          parameters: <10
        - input: dstPort
          output: service
          type: add_service
          parameters: protocol
        - input: dstIP
          output: dstLocation
          type: add_location
        - input: srcIP
          output: srcK8S
          type: add_kubernetes
        - input: srcSubnet
          output: match-10.0
          type: add_regex_if
          parameters: 10.0.*

The first rule add_subnet generates a new field named srcSubnet with the subnet of srcIP calculated based on prefix length from the parameters field

The second add_if generates a new field named value_smaller_than10 that contains the contents of the value field for entries that satisfy the condition specified in the parameters variable (smaller than 10 in the example above). In addition, the field value_smaller_than10_Evaluate with value true is added to all satisfied entries

The third rule add_service generates a new field named service with the known network service name of dstPort port and protocol protocol. Unrecognized ports are ignored

Note: protocol can be either network protocol name or number

The fourth rule add_location generates new fields with the geo-location information retrieved from DB ip2location based on dstIP IP. All the geo-location fields will be named by appending output value (dstLocation in the example above) to their names in the [ip2location](https://lite.ip2location.com/ DB (e.g., CountryName, CountryLongName, RegionName, CityName , Longitude and Latitude)

The fifth rule add_kubernetes generates new fields with kubernetes information by matching the input value (srcIP in the example above) with k8s nodes, pods and services IPs. All the kubernetes fields will be named by appending output value (srcK8S in the example above) to the kubernetes metadata field names (e.g., Type, Name and Namespace)

Note: kubernetes connection is done using the first available method:

  1. configuration parameter KubeConfigPath (in the example above /tmp/config) or
  2. using KUBECONFIG environment variable
  3. using local ~/.kube/config

The sixth add_regex_if generates a new field named match-10.0 that contains the contents of the srcSubnet field for entries that match regex expression specified in the parameters variable. In addition, the field match-10.0_Matched with value true is added to all matched entries

Note: above example describes all available transform network Type options Note: above transform is essential for the aggregation phase

Aggregates

Aggregates are used to define the transformation of flow-logs from textual/json format into numeric values to be exported as metrics. Aggregates are dynamically created based on defined values from fields in the flow-logs and on mathematical functions to be performed on these values. The specification of the aggregates details is placed in the extract stage of the pipeline.

For Example, assuming set of flow-logs, with single sample flow-log that looks like:

{"srcIP":   "10.0.0.1",
"dstIP":   "20.0.0.2",
"level":   "error",
"value":   "7",
"message": "test message"}

It is possible to define aggregates per srcIP or per dstIP of per the tuple srcIPxdstIP to capture the sum, min, avg etc. of the values in the field value.

For example, configuration record for aggregating field value as average for srcIPxdstIP tuples will look like this::

pipeline:
  extract:
    type: aggregates
    aggregates:
    - Name: "Average key=value for (srcIP, dstIP) pairs"
      By:
      - "dstIP"
      - "srcIP"
      Operation: "avg"
      RecordKey: "value"

Prometheus encoder

The prometheus encoder specifies which metrics to export to prometheus and which labels should be associated with those metrics. For example, we may want to report the number of bytes and packets for the reported flows. For each reported metric, we may specify a different set of labels. Each metric may be renamed from its internal name. The internal metric name is specified as input and the exported name is specified as name. A prefix for all exported metrics may be specified, and this prefix is prepended to the name of each specified metric.

pipeline:
  encode:
    type: prom
    prom:
      port: 9103
      prefix: test_
      metrics:
        - name: Bytes
          type: gauge
          valuekey: bytes
          labels:
            - srcAddr
            - dstAddr
            - srcPort
        - name: Packets
          type: counter
          valuekey: packets
          labels:
            - srcAddr
            - dstAddr
            - dstPort

In this example, for the bytes metric we report with the labels which specify srcAddr, dstAddr and srcPort. Each different combination of label-values is a distinct gauge reported to prometheus. The name of the prometheus gauge is set to test_Bytes by concatenating the prefix with the metric name. The packets metric is very similar. It makes use of the counter prometheus type which adds reported values to prometheus counter.

Development

Build

  • Clone this repository from github into a local machine (Linux/X86): git clone [email protected]:MCNM/observability.git
  • Change directory into flowlogs2metrics into: cd flowlogs2metrics
  • Build the code: make build

FL2M uses Makefile to build, tests and deploy. Following is the output of make help :

  
Usage:  
  make <target>  
  
General  
  help                  Display this help.  
  
Develop  
  lint                  Lint the code  
  build                 Build flowlogs2metrics executable and update the docs  
  dashboards            Build grafana dashboards  
  docs                  Update flowlogs2metrics documentation  
  clean                 Clean  
  test                  Test  
  benchmarks            Benchmark  
  run                   Run  
  
Docker  
  push-image            Push latest image  
  
kubernetes  
  deploy                Deploy the image  
  undeploy              Undeploy the image  
  deploy-prometheus     Deploy prometheus  
  undeploy-prometheus   Undeploy prometheus  
  deploy-grafana        Deploy grafana  
  undeploy-grafana      Undeploy grafana  
  deploy-netflow-simulator  Deploy netflow simulator  
  undeploy-netflow-simulator  Undeploy netflow simulator  
  
kind  
  create-kind-cluster   Create cluster  
  delete-kind-cluster   Delete cluster  
  
metrics  
  generate-configuration  Generate metrics configuration  
  
End2End  
  local-deploy          Deploy locally on kind (with simulated flowlogs)  
  local-cleanup         Undeploy from local kind  
  local-redeploy        Redeploy locally (on current kind)  
  ocp-deploy            Deploy to OCP  
  ocp-cleanup           Undeploy from OCP  
  dev-local-deploy      Deploy locally with simulated netflows
Comments
  • NETOBSERV-497 allow direct metrics pipeline

    NETOBSERV-497 allow direct metrics pipeline

    This PoC creates a new "SimpleProm" Encode stage that directly extracts metrics from flows without an intermediate Aggregate stage

    The rationale is that Prometheus already manages labels aggregations. It leaves more responsibilities (and more power) to the query side. For instance, aggregations such as sum/avg etc. would be performed in PromQL at query time rather than upstream.

    Pipelines to generate are simpler as they don't need an "Aggregate" stage, and the prom-encode stage itself has less parameters, e.g.:

    	enrichedStage.SimpleEncodePrometheus("prometheus", api.SimplePromEncode{
    		Port:   int(b.desired.PrometheusPort),
    		Prefix: "netobserv_",
    		Metrics: []api.SimplePromMetricsItem{{
    			Name:      "bytes_total",
    			RecordKey: "Bytes",
    			Type:      "counter",
    			Labels:    []string{"SrcK8S_Namespace", "DstK8S_Namespace"},
    		}, {
    			Name:      "packets_total",
    			RecordKey: "Packets",
    			Type:      "counter",
    			Labels:    []string{"SrcK8S_Namespace", "DstK8S_Namespace"},
    		}},
    	})
    
  • Avoid json encoding on flow ingestion #212 (breaking change)

    Avoid json encoding on flow ingestion #212 (breaking change)

    I had to create a "fake" stage DecodeCast, just to fix incompatible types map[string]interface{} and GenericMap (which are actually the same). However I think we could do better by merging all Ingest and Decode stages (reach out on slack to discuss)

  • multipipe

    multipipe

    Took some inspiration from the go-pipes. Allow the same ingest to be directed to multiple pipelines. We allow a single ingest and a single decode stage. After that, we allow any order of transform, extract, encode, write stages. Sample syntax:

    pipeline:
      - stage: ingest
        name: ingest1
        params:
          ingest:
            type: file_loop
            file:
              filename: playground/goflow2_input.txt
      - stage: decode
        name: decode1
        follows: ingest1
        params:
          decode:
            type: json
      - stage: transform
        name: generic1
        follows: decode1
        params:
          transform:
            type: generic
            generic:
              rules:
                 ..........
      - stage: write
        name: write1
        follows: generic1
        params:
          write:
            type: stdout
      - stage: transform
        name: generic2
        follows: decode1
        params:
          transform:
            type: generic
            generic:
              rules:
                 .......
      - stage: write
        name: write2
        follows: generic2
        params:
          write:
            type: stdout
    

    This example shows 2 generic transforms receiving the same flows from the decoder and performing different transforms and different write with them.

  • There are some inconsistencies in the API

    There are some inconsistencies in the API

    The api is not fully consistent, some names are camelCase, other lowcase and sometimes snake_case, e.g:

    • valuekey
    • expirytime
    • readTimeout
    • batchSize
    • buffer_length

    We should agree on a convention to follow

  • Unify ingest metrics too

    Unify ingest metrics too

    Except for netflow/ipfix which continue to use goflow2 metrics, other ingester now adopt the same "framework" for metrics as the other stages, hence also have new names with a prefix

    New metrics are:

    ingest_batch_size_bytes

    | Name | ingest_batch_size_bytes | |:---|:---| | Description | Ingested batch size distribution, in bytes | | Type | summary | | Labels | stage |

    ingest_errors

    | Name | ingest_errors | |:---|:---| | Description | Counter of errors during ingestion | | Type | counter | | Labels | stage, type, code |

    ingest_flows_processed

    | Name | ingest_flows_processed | |:---|:---| | Description | Provides number of flows processed, batches processed, and batch size stats (in number of flows) | | Type | summary | | Labels | stage |

    ingest_latency_ms

    | Name | ingest_latency_ms | |:---|:---| | Description | Latency between flow end time and ingest time, in milliseconds | | Type | histogram | | Labels | stage |

  • NETOBSERV-341 configure netflow v5 separately (breaking change if using v5)

    NETOBSERV-341 configure netflow v5 separately (breaking change if using v5)

    Fixes #200

    @eranra @KalmanMeth Is it ok with you to have a breaking changes here? (people who used legacy v5 now have to configure it explicitly) If that's a problem, we could default to the previous behaviour (legacy port = main port +1) and have another setting to disable v5, but I think it's more simple to keep default as 0 = legacy disabled.

  • Cannot build project with golang 1.18

    Cannot build project with golang 1.18

    There are many linting errors that stop the project from being built/used.

    make build
    cmd/confgenerator/main.go:27:2: "github.com/json-iterator/go" imported but not used as jsoniter (typecheck)
            jsoniter "github.com/json-iterator/go"
            ^
    cmd/flowlogs-pipeline/main.go:28:2: "github.com/json-iterator/go" imported but not used as jsoniter (typecheck)
            jsoniter "github.com/json-iterator/go"
            ^
    pkg/confgen/confgen.go:150:8: undeclared name: `yaml` (typecheck)
            err = yaml.Unmarshal(yamlFile, &defFile)
                  ^
    pkg/confgen/config.go:78:8: undeclared name: `yaml` (typecheck)
            err = yaml.Unmarshal(yamlFile, &config)
                  ^
    pkg/confgen/flowlogs2metrics_config.go:115:21: undeclared name: `yaml` (typecheck)
            configData, err := yaml.Marshal(&config)
                               ^
    pkg/confgen/confgen.go:29:2: "gopkg.in/yaml.v2" imported but not used (typecheck)
            "gopkg.in/yaml.v2"
            ^
    pkg/confgen/config.go:25:2: "gopkg.in/yaml.v2" imported but not used (typecheck)
            "gopkg.in/yaml.v2"
            ^
    pkg/confgen/flowlogs2metrics_config.go:24:2: "gopkg.in/yaml.v2" imported but not used (typecheck)
            "gopkg.in/yaml.v2"
            ^
    pkg/pipeline/pipeline_test.go:25:2: "github.com/netobserv/flowlogs-pipeline/pkg/pipeline/decode" imported but not used (typecheck)
            "github.com/netobserv/flowlogs-pipeline/pkg/pipeline/decode"
            ^
    pkg/pipeline/pipeline_test.go:26:2: "github.com/netobserv/flowlogs-pipeline/pkg/pipeline/ingest" imported but not used (typecheck)
            "github.com/netobserv/flowlogs-pipeline/pkg/pipeline/ingest"
            ^
    pkg/pipeline/encode/encode_prom.go:21:2: could not import container/list (-: could not load export data: cannot import "container/list" (unstable iexport format version 2, just rebuild compiler and std library), export data is newer version - update tool) (typecheck)
            "container/list"
            ^
    pkg/pipeline/transform/transform_network.go:54:25: n.Rules undefined (type *Network has no field or method Rules) (typecheck)
            for _, rule := range n.Rules {
                                   ^
    pkg/pipeline/transform/connection_tracking/connection_tracking.go:21:2: could not import container/list (-: could not load export data: cannot import "container/list" (unstable iexport format version 2, just rebuild compiler and std library), export data is newer version - update tool) (typecheck)
            "container/list"
            ^
    pkg/pipeline/transform/kubernetes/kubernetes_test.go:86:15: informerMock.On undefined (type *InformerMock has no field or method On) (typecheck)
            informerMock.On("GetIndexer", mock.Anything, mock.Anything, mock.Anything).Return(nil)
                         ^
    pkg/pipeline/transform/kubernetes/kubernetes.go:28:2: "k8s.io/api/apps/v1" imported but not used as appsv1 (typecheck)
            appsv1 "k8s.io/api/apps/v1"
            ^
    pkg/pipeline/transform/location/location.go:54:17: undeclared name: `ip2location` (typecheck)
    var locationDB *ip2location.DB
                    ^
    pkg/pipeline/transform/location/location.go:146:19: undeclared name: `ip2location` (typecheck)
            db, openDBErr := ip2location.OpenDB(DBFileLocation + "/" + DBFilename)
                             ^
    pkg/pipeline/transform/location/location_test.go:125:16: undeclared name: `ip2location` (typecheck)
            locationDB = &ip2location.DB{}
                          ^
    pkg/pipeline/transform/location/location.go:33:2: "github.com/ip2location/ip2location-go/v9" imported but not used (typecheck)
            "github.com/ip2location/ip2location-go/v9"
            ^
    pkg/pipeline/transform/location/location_test.go:31:2: "github.com/ip2location/ip2location-go/v9" imported but not used (typecheck)
            "github.com/ip2location/ip2location-go/v9"
            ^
    pkg/pipeline/write/write_loki_test.go:108:5: fe.On undefined (type fakeEmitter has no field or method On) (typecheck)
            fe.On("Handle", mock.Anything, mock.Anything, mock.Anything).Return(nil)
               ^
    pkg/pipeline/write/write_loki_test.go:118:5: fe.AssertCalled undefined (type fakeEmitter has no field or method AssertCalled) (typecheck)
            fe.AssertCalled(t, "Handle", model.LabelSet{
               ^
    pkg/pipeline/write/write_loki_test.go:124:5: fe.AssertCalled undefined (type fakeEmitter has no field or method AssertCalled) (typecheck)
            fe.AssertCalled(t, "Handle", model.LabelSet{
               ^
    pkg/pipeline/write/write_loki_test.go:161:7: fe.On undefined (type fakeEmitter has no field or method On) (typecheck)
                            fe.On("Handle", mock.Anything, mock.Anything, mock.Anything).Return(nil)
                               ^
    pkg/pipeline/write/write_loki_test.go:165:7: fe.AssertCalled undefined (type fakeEmitter has no field or method AssertCalled) (typecheck)
                            fe.AssertCalled(t, "Handle", model.LabelSet{},
                               ^
    pkg/pipeline/write/write_loki_test.go:204:7: fe.On undefined (type fakeEmitter has no field or method On) (typecheck)
                            fe.On("Handle", mock.Anything, mock.Anything, mock.Anything).Return(nil)
                               ^
    make: *** [Makefile:69: lint] Error 1
    
    golangci-lint version
    golangci-lint has version 1.39.0 built from 9aea4aee on 2021-03-26T08:02:53Z
    
  • Network transform: Align kubernetes transform with kube-enricher

    Network transform: Align kubernetes transform with kube-enricher

    Align the network transform functionality of flowlogs2metrics with https://github.com/netobserv/goflow2-kube-enricher so that the information and fields added by the network transform phase are equivalent. This will allow smooth integration with NOO.

  • NETOBSERV-578: removing arrays from pipeline interfaces

    NETOBSERV-578: removing arrays from pipeline interfaces

    This PR removes the batching logic in the Kafka ingester and processes flows 1 by 1 on each pipeline stage.

    While the CPU usage doesn't seem to noticeably decrease:

    image

    It greatly improves memory consumption:

    image

    (as well as simplifies some parts of the code)

  • NETOBSERV-578: decrease informers' memory consumption

    NETOBSERV-578: decrease informers' memory consumption

    This PR adds a Transformer for each Kubernetes informer that converts the watched Pods, Services, and Nodes to Info instances, that are stored by the informers cache and contain only the data that is required for the decoration.

    This also alleviates the load on the Garbage Collector: before this patch, a new Info instance was created for each flow decoration. Now the same objects are reused on GetInfo invocations for the same IP.

    In Flowlogs-Pipelines with mid-to-low loads, no improvements have been observed in terms of CPU and slight improvements in terms of memory. In the image below, the middle part corresponds to the new version of FLP.

    image
  • Allow enabling Go Pprof

    Allow enabling Go Pprof

    If the profile.port argument is set to something different than 0, it will add a pprof endpoint so we can inspect what's going on FLP in terms of memory and CPU.

  • NETOBSERV-386 IP categorization

    NETOBSERV-386 IP categorization

    JIRA: https://issues.redhat.com/browse/NETOBSERV-386

    Allows to configure IP ranges and assign them any name IPs falling in those ranges are flagged with that name

  • Updated Dockefile for crosscompilation compatibility

    Updated Dockefile for crosscompilation compatibility

    This update the Dockerfile to make it possible to cross build FLP container image.

    Example of manual cross build command: podman buildx build --platform=linux/ppc64le -t test -f ./contrib/docker/Dockerfile .

    Could someone with docker installed could confirm that the cli API is identical and the example above also works with docker?

  • conntrack: Configurable timeouts

    conntrack: Configurable timeouts

    This PR allows configuring different timeouts for connections based on their key fields.

    conntrack:
      keyDefinition:
        fieldGroups:
        - name: protocol
          fields:
          - Proto
        # ...
      scheduling:
      - selector: # UDP connections
          Proto: 17
        endConnectionTimeout: 5s
        updateConnectionInterval: 40s
      - selector: {} # Default group
        endConnectionTimeout: 10s
        updateConnectionInterval: 30s
    

    Implementation: Instead of using a single Multi-Order Map in the connection store for all the connections, the connection store will have a Multi-Order Map for each scheduling group. In addition, the store has a new hashId2groupIdx map that given a connection hash ID, finds the Multi-Order Map of the connection.

    TODO:

    • [ ] Add a scheduling group label to the conntrack_memory_connections metric. This will allow monitoring the number of active connections per scheduling group.
  • conntrack: Allow configuring multiple hash IDs to connection records

    conntrack: Allow configuring multiple hash IDs to connection records

    Currently, we have only a single hash ID for a connection which is a hash on some selected fields. The flow direction (i.e. "ingress" or "egress") is also added to these fields to eliminate aggregation of duplicate stats (such as bytes and packets). This makes 2 different hashes for the same connection. The problem is that in the console plugin we would like to group together the records of the 2 hashes. One option to do so is to add another hash ID that excludes the flow direction field. This will generate the same hash regardless of the flow direction. This new hash can be used in the console plugin to group records by.

  • IPFIX Export support for Kubernetes transformations

    IPFIX Export support for Kubernetes transformations

    This PR adds IPFIX export support for FLP o/p:

    Way to enable this in config, for e.g.:

        write:
          type: ipfix
          ipfix:
            targetHost: 127.0.0.1
            targetPort: 9998
            transport: tcp
            enterpriseID: 27207
    

    enterpriseID is a custom registry ID for kubernetes transformations, and other non-standard entries.

    Main Changes in the following files:

    1. pkg/api/write_ipfix.go
    2. pkg/api/api.go
    3. pkg/config/config.go
    4. pkg/pipeline/pipeline_builder.go
    5. pkg/pipeline/write/write_ipfix.go
    6. go.mod
The metrics-agent collects allocation metrics from a Kubernetes cluster system and sends the metrics to cloudability

metrics-agent The metrics-agent collects allocation metrics from a Kubernetes cluster system and sends the metrics to cloudability to help you gain vi

Jan 14, 2022
ThoughtLoom: Transform Data into Insights with OpenAI LLMs
ThoughtLoom: Transform Data into Insights with OpenAI LLMs

ThoughtLoom: Transform Data into Insights with OpenAI LLMs ThoughtLoom is a powerful tool designed to foster creativity and enhance productivity throu

May 4, 2023
Secret - Prevent your secrets from leaking into logs and std*

secret - Prevent your secrets from leaking into logs and std* The package provid

Dec 30, 2022
cluster-api-state-metrics (CASM) is a service that listens to the Kubernetes API server and generates metrics about the state of custom resource objects related of Kubernetes Cluster API.

Overview cluster-api-state-metrics (CASM) is a service that listens to the Kubernetes API server and generates metrics about the state of custom resou

Oct 27, 2022
Flash-metrics - Flash Metrics Storage With Golang

Flash Metrics Storage bootstrap: $ echo -e "max-index-length = 12288" > tidb.con

Jan 8, 2022
This library provides a metrics package which can be used to instrument code, expose application metrics, and profile runtime performance in a flexible manner.

This library provides a metrics package which can be used to instrument code, expose application metrics, and profile runtime performance in a flexible manner.

Jan 18, 2022
Transform latin letters to runes & vice versa. Go version.

Riimut Transform latin letters to runes & vice versa. Go version. Includes transformers for four main runic alphabets: Elder Futhark Younger Futhark M

Aug 2, 2022
Substation is a cloud native toolkit for building modular ingest, transform, and load (ITL) data pipelines

Substation Substation is a cloud native data pipeline toolkit. What is Substation? Substation is a modular ingest, transform, load (ITL) application f

Dec 30, 2022
Vilicus is an open source tool that orchestrates security scans of container images(docker/oci) and centralizes all results into a database for further analysis and metrics.
Vilicus is an open source tool that orchestrates security scans of container images(docker/oci) and centralizes all results into a database for further analysis and metrics.

Vilicus Table of Contents Overview How does it work? Architecture Development Run deployment manually Usage Example of analysis Overview Vilicus is an

Dec 6, 2022
Exporter your cypress.io dashboard into prometheus Metrics

Cypress.io dashboard Prometheus exporter Prometheus exporter for a project from Cypress.io dashboards, giving the ability to alert, make special opera

Feb 8, 2022
cloud native application deploy flow
cloud native application deploy flow

Triton-io/Triton English | 简体中文 Introduction Triton provides a cloud-native DeployFlow, which is safe, controllable, and policy-rich. For more introdu

May 28, 2022
Hexagonal architecture paradigms, such as dividing adapters into primary (driver) and secondary (driven)Hexagonal architecture paradigms, such as dividing adapters into primary (driver) and secondary (driven)

authorizer Architecture In this project, I tried to apply hexagonal architecture paradigms, such as dividing adapters into primary (driver) and second

Dec 7, 2021
ecsk is a CLI tool to interactively use frequently used functions of docker command in Amazon ECS. (docker run, exec, cp, logs, stop)
ecsk is a CLI tool to interactively use frequently used functions of docker command in Amazon ECS. (docker run, exec, cp, logs, stop)

English / 日本語 ecsk ECS + Task = ecsk ?? ecsk is a CLI tool to interactively use frequently used functions of docker command in Amazon ECS. (docker run

Dec 13, 2022
A TUI interface to navigate and view OpenShift 4 must-gather logs
A TUI interface to navigate and view OpenShift 4 must-gather logs

MGR "Must Gather Reader" MGR "not the final name" is a simple TUI interface to navigate and view OpenShift 4 must-gather files. How to run it: Downloa

Dec 21, 2022
Aggregate Kubernetes logs using cli command.
Aggregate Kubernetes logs using cli command.

kubelog kubelog allows user to aggregate logs using cli command. How to use You can aggregate logs like this: Examples Stream logs from pod nginx with

Jan 11, 2021
Logkubed - Serve K8s container logs in realtime with websockets

log3 (logkubed) logcubed is a mini app that helps you stream Kubernetes pod logs

Aug 31, 2022
Ostent is a server tool to collect, display and report system metrics.
Ostent is a server tool to collect, display and report system metrics.

Ostent Ostent collects metrics to display and report to InfluxDB, Graphite, Librato. The interactive display UI (demo): System metrics collected and r

Sep 27, 2022
📡 Prometheus exporter that exposes metrics from SpaceX Starlink Dish
📡  Prometheus exporter that exposes metrics from SpaceX Starlink Dish

Starlink Prometheus Exporter A Starlink exporter for Prometheus. Not affiliated with or acting on behalf of Starlink(™) ?? Starlink Monitoring System

Dec 19, 2022
Prometheus exporter for Chia node metrics

chia_exporter Prometheus metric collector for Chia nodes, using the local RPC API Building and Running With the Go compiler tools installed: go build

Sep 19, 2022