Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

[WIP] Add generic log message generation basic on a custom templates for log fields #62

Closed

Conversation

robskillington
Copy link
Member

@robskillington robskillington commented Apr 8, 2024

Based loosely on github.com/mingrammer/flog for field generation with ability to use arbitrary templates (have included sprig template functions too).

TODO:

  • Micro benchmark integration test ideally to ensure can publish fast enough to meet fast rate config (e.g. >1k per second or more? I couldn't go very high for some reason using low "rate" per to generate high volume but not sure if it's a limitation of the Go plugin module architecture with the buffered channel or some other limitation? shrug).

@robskillington robskillington changed the title Add set of simulated datagen sources for dummy data Add generic log message generation basic on a custom templates for log fields Apr 23, 2024
@robskillington robskillington changed the title Add generic log message generation basic on a custom templates for log fields [WIP] Add generic log message generation basic on a custom templates for log fields Apr 25, 2024
@robskillington robskillington requested a review from a team as a code owner April 25, 2024 12:41
buffer strings.Builder
)

data = TemplateData{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why using template data? I think these could be template functions to give more control.
I think it makes more sense to use a function since its generating data, instead of accessing to some predefined values.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gofakeit already allows be be exposed to text/template https://github.com/brianvoe/gofakeit?tab=readme-ov-file#templates

if err := v.Execute(&buffer, data); err != nil {
return nil, fmt.Errorf("failed to execute template for field '%s': %w", k, err)
}
record[k] = buffer.String()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔
This will always produce a string. Not allowing, numbers, booleans or more complex data types.

}
case "template":
plug.gen = genTemplate
fieldsStr := fbit.Conf.String("fields")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried about field order.
Since Go plugins sends the records as map[string]any it won't keep the order of these fields. But the user might expect them in the given order.


plug.template = NewLogGenerator()
for _, field := range fields {
fieldValue := fbit.Conf.String(field)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried about this "dynamic" config in where the config schema is unknown.
I think I would just prefer if the template evaluates to a JSON string (At least for now since we don't support reading objects from the YAML config).

pipeline:
  inputs:
    - name: datagen
      template: |-
        {
          "id": "{{UUID}}",
          "host": "{{IPv4Address}}",
          "userAgent": "{{UserAgent}}",
          "version": "{{AppVersion}}",
          "date": "{{PastDate}}"
        }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this, for sure

Copy link
Contributor

@nicolasparada nicolasparada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments.
I'll move the code into datagen plugin here https://github.com/chronosphereio/calyptia-core-fluent-bit-plugin-datagen

@nicolasparada nicolasparada deleted the rob/add-datagen-sources-for-go-dummy-plugin branch June 6, 2024 06:27
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants