#elk — Public Fediverse posts

National Elk Refuge, Wyoming. March, 2018.

📷 Fujifilm X-T2 + XF100-400mmF4.5-5.6 R LM OIS WR
🎞 132 mm – 1/1700″ – f/5 – ISO 200
🔗 https://www.allencompassingtrip.com/2266/elk?utm_campaign=random-wildlife&utm_medium=social&utm_source=Mastodon

#Wildlife #Photography #Elk #NationalWildlifeRefuges

Whether or not they claim to support #Markdown, here are the results for some #Mastodon clients I have access to…

* ✅ — @pachli (via "Lab experiments")
* 🚫 — @Mastodon, @elk, @pinafore, @moshidon, @Tusky

I'm surprised, because I think I've seen #Elk support Markdown in other posts. I also thought Markdown support would be more common than that.

Soreka of Redlake - https://www.patreon.com/posts/157623239

Commission for Eldestberry on Discord!

Please support my work, it's a huge help: https://www.patreon.com/ratte / https://ko-fi.com/ratte

#art #artist #artists #ArtistsOnMastodon #MastoArt #DigitalArt #illustration #furry #FurryArt #patreon #kofi #digitalArt #commission #deer #elk #wapiti #female

Reduce developer friction – Configuring tools like Fluent Bit (and Fluentd)

Something that vendors like Microsoft have been really good at is reducing the friction on getting started – from simplifying installations with MSI files and defaulted options through to very informative error messages in Excel when you’ve got a function slightly wrong. Apple is another good example of this; while no two Android phones are the same, my experience is that setting up an iPhone is just so much easier than setting up an Android phone. It is also the setup/configuration where most friction comes from.

Open-Source Software (OSS), as a generalisation, tend to be a bit weaker at minimising friction – this comes from several factors:

• When OSS is part of a business model, vendors can reduce that friction, making their enhanced version more attractive.
• OSS contributors are typically focused on the core problem space and are usually close enough to the fine details to not need those fancy features to keep the rest of us out of trouble.
• The expectation is that tools to make configuration easy are embedded in the application, making it heavier, when the aim is to keep things as light as possible.
• Occasionally, a little bit of intellectual snobbery can creep in

The common challenge

The issue that I have observed is that we often go through cycles of working with a technology. For example, you’re building a microservice. Chances are, you’ll start writing and running it locally, without worrying about containerization. Once you’re pretty happy with things, you’ll Dockerize the service, start testing it locally, and then you’ll be ready to deploy it to a cluster. Now you’ll need your YAML. It may well be weeks since you last looked at Helm charts. You end up cutting and pasting your last configuration. But now you need to use another feature of Helm, can you remember the exact settings for the feature. So now you’re trawling the net for documentation, and then it takes several tries to get it right.

AI may well step in to help developers in this area, where solutions and products are well-documented. But with the wrong model or insufficient detail in the prompt, it’s easy to make a mistake. Personally, I’d turn to AI when it becomes necessary to trawl code to better understand the configuration and its behaviour, and to set options.

Experimental Solution

Solution – well, that depends upon the configuration syntax. We have been experimenting with RJSF (React JSON Schema Form), which provides a React-based UI that can be dynamically driven by a JSON schema and validate data with AJV (an alternative stack considered would have been around JSON Forms).

 {    "type": "object",    "title": "Dummy",    "properties": {      "name": {        "type": "string",        "const": "dummy",        "title": "Plugin"      },      "copies": {        "type": "integer",        "description": "Number of messages to generate each time messages are generated.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "integer",        "default": 1      },      "dummy": {        "type": "string",        "description": "Dummy JSON record.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "string",        "default": "{\"message\":\"dummy\"}"      },      "fixed_timestamp": {        "type": "boolean",        "description": "If enabled, use a fixed timestamp.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "boolean",        "default": false      }    }  }  

The above fragment shows part of the Schema definition for the Dummy plugin for Fluent Bit.

By then creating a schema that defines the different plugins, attributes, etc., we can drive validation and menu items easily in the UI. Admittedly, the config file is significant given all the plugins and configuration options, but it is a fair price to pay for a UI that validates the data. Establishing the schema to start with, we’ve covered it through scripting the retrieval and scraping of the Fluent Bit pages, which are pretty consistent in structure.

We have added some custom elements into the definition, for example, x-doc-reference, which allows us to extend the React components to provide features such as a link back to the original documentation as you select attributes or plugins.

As a result, we very quickly have a UI that can look like this:

A lot easier to view and tweak, with no need to hunt for valid options. Even if we want more information, we’re just a button click away from the open-source data. Perhaps we should provide a version that hyperlinks to the Manning Live Books on Fluent Bit, etc.

There are a few other factors to consider; for example, Fluent Bit configuration is YAML, not JSON, which can be easily resolved given the relationship between the two standards. Then there are processors that can embed Lua code or a SQL-like syntax. As we’ve chosen to provide a Python backend, we’ve addressed this by providing REST endpoints which can query out of the JSON the code or SQL and perform validation using the Python Lua Parser, and the SQL syntax can be addressed using the Lark library for processing the SQL, as the syntax is simple enough to define and maintain the syntax.

Outstanding Gaps for Fluent Bit

We still need to address several features that Fluent Bit has, specifically:

• Environment variables
• Includes

These issues should be straightforward to overcome, although dynamically including the included elements into the UI view elements can be done. The challenge is: if any changes need to go into something that has been included, how do we push them back to the included file? Particularly if there are multiple layers of inclusion.

What about Fluentd?

Fluentd configuration isn’t JSON-based notation, but it is structured. So, to apply the same mechanism, we’ll need to define a schema and a mapping mechanism. The tricky part of the schema is that Fluentd supports nesting plugins, since the way pipelines are defined for routing differs. While JSON schema will enable this with constructs such as anyOf, oneOf, object nesting, and bounded object arrays, the structure will be more complex.

The second challenge will be the transformer/renderer, so we don’t introduce issues from having to escape and unescape characters, since JSON Schema is stricter about character use.

Then What?

Well, if we get this going, we’ll probably incorporate the capability into our OpAMP project and maybe create a build that lets the configuration tool run independently. Lastly, perhaps we should look to see if we can make the different layers a little more abstract, so we can plug in editors for other configurations, such as OTel Collectors or the ELK Stack.

As a bonus, perhaps transform the Schema into a quick reference web document?

Reduce developer friction – Configuring tools like Fluent Bit (and Fluentd)

Something that vendors like Microsoft have been really good at is reducing the friction on getting started – from simplifying installations with MSI files and defaulted options through to very informative error messages in Excel when you’ve got a function slightly wrong. Apple is another good example of this; while no two Android phones are the same, my experience is that setting up an iPhone is just so much easier than setting up an Android phone. It is also the setup/configuration where most friction comes from.

Open-Source Software (OSS), as a generalisation, tend to be a bit weaker at minimising friction – this comes from several factors:

• When OSS is part of a business model, vendors can reduce that friction, making their enhanced version more attractive.
• OSS contributors are typically focused on the core problem space and are usually close enough to the fine details to not need those fancy features to keep the rest of us out of trouble.
• The expectation is that tools to make configuration easy are embedded in the application, making it heavier, when the aim is to keep things as light as possible.
• Occasionally, a little bit of intellectual snobbery can creep in

The common challenge

The issue that I have observed is that we often go through cycles of working with a technology. For example, you’re building a microservice. Chances are, you’ll start writing and running it locally, without worrying about containerization. Once you’re pretty happy with things, you’ll Dockerize the service, start testing it locally, and then you’ll be ready to deploy it to a cluster. Now you’ll need your YAML. It may well be weeks since you last looked at Helm charts. You end up cutting and pasting your last configuration. But now you need to use another feature of Helm, can you remember the exact settings for the feature. So now you’re trawling the net for documentation, and then it takes several tries to get it right.

AI may well step in to help developers in this area, where solutions and products are well-documented. But with the wrong model or insufficient detail in the prompt, it’s easy to make a mistake. Personally, I’d turn to AI when it becomes necessary to trawl code to better understand the configuration and its behaviour, and to set options.

Experimental Solution

Solution – well, that depends upon the configuration syntax. We have been experimenting with RJSF (React JSON Schema Form), which provides a React-based UI that can be dynamically driven by a JSON schema and validate data with AJV (an alternative stack considered would have been around JSON Forms).

 {    "type": "object",    "title": "Dummy",    "properties": {      "name": {        "type": "string",        "const": "dummy",        "title": "Plugin"      },      "copies": {        "type": "integer",        "description": "Number of messages to generate each time messages are generated.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "integer",        "default": 1      },      "dummy": {        "type": "string",        "description": "Dummy JSON record.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "string",        "default": "{\"message\":\"dummy\"}"      },      "fixed_timestamp": {        "type": "boolean",        "description": "If enabled, use a fixed timestamp.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "boolean",        "default": false      }    }  }  

The above fragment shows part of the Schema definition for the Dummy plugin for Fluent Bit.

By then creating a schema that defines the different plugins, attributes, etc., we can drive validation and menu items easily in the UI. Admittedly, the config file is significant given all the plugins and configuration options, but it is a fair price to pay for a UI that validates the data. Establishing the schema to start with, we’ve covered it through scripting the retrieval and scraping of the Fluent Bit pages, which are pretty consistent in structure.

We have added some custom elements into the definition, for example, x-doc-reference, which allows us to extend the React components to provide features such as a link back to the original documentation as you select attributes or plugins.

As a result, we very quickly have a UI that can look like this:

A lot easier to view and tweak, with no need to hunt for valid options. Even if we want more information, we’re just a button click away from the open-source data. Perhaps we should provide a version that hyperlinks to the Manning Live Books on Fluent Bit, etc.

There are a few other factors to consider; for example, Fluent Bit configuration is YAML, not JSON, which can be easily resolved given the relationship between the two standards. Then there are processors that can embed Lua code or a SQL-like syntax. As we’ve chosen to provide a Python backend, we’ve addressed this by providing REST endpoints which can query out of the JSON the code or SQL and perform validation using the Python Lua Parser, and the SQL syntax can be addressed using the Lark library for processing the SQL, as the syntax is simple enough to define and maintain the syntax.

Outstanding Gaps for Fluent Bit

We still need to address several features that Fluent Bit has, specifically:

• Environment variables
• Includes

These issues should be straightforward to overcome, although dynamically including the included elements into the UI view elements can be done. The challenge is: if any changes need to go into something that has been included, how do we push them back to the included file? Particularly if there are multiple layers of inclusion.

What about Fluentd?

Fluentd configuration isn’t JSON-based notation, but it is structured. So, to apply the same mechanism, we’ll need to define a schema and a mapping mechanism. The tricky part of the schema is that Fluentd supports nesting plugins, since the way pipelines are defined for routing differs. While JSON schema will enable this with constructs such as anyOf, oneOf, object nesting, and bounded object arrays, the structure will be more complex.

The second challenge will be the transformer/renderer, so we don’t introduce issues from having to escape and unescape characters, since JSON Schema is stricter about character use.

Then What?

Well, if we get this going, we’ll probably incorporate the capability into our OpAMP project and maybe create a build that lets the configuration tool run independently. Lastly, perhaps we should look to see if we can make the different layers a little more abstract, so we can plug in editors for other configurations, such as OTel Collectors or the ELK Stack.

As a bonus, perhaps transform the Schema into a quick reference web document?

Reduce developer friction – Configuring tools like Fluent Bit (and Fluentd)

Something that vendors like Microsoft have been really good at is reducing the friction on getting started – from simplifying installations with MSI files and defaulted options through to very informative error messages in Excel when you’ve got a function slightly wrong. Apple is another good example of this; while no two Android phones are the same, my experience is that setting up an iPhone is just so much easier than setting up an Android phone. It is also the setup/configuration where most friction comes from.

Open-Source Software (OSS), as a generalisation, tend to be a bit weaker at minimising friction – this comes from several factors:

• When OSS is part of a business model, vendors can reduce that friction, making their enhanced version more attractive.
• OSS contributors are typically focused on the core problem space and are usually close enough to the fine details to not need those fancy features to keep the rest of us out of trouble.
• The expectation is that tools to make configuration easy are embedded in the application, making it heavier, when the aim is to keep things as light as possible.
• Occasionally, a little bit of intellectual snobbery can creep in

The common challenge

The issue that I have observed is that we often go through cycles of working with a technology. For example, you’re building a microservice. Chances are, you’ll start writing and running it locally, without worrying about containerization. Once you’re pretty happy with things, you’ll Dockerize the service, start testing it locally, and then you’ll be ready to deploy it to a cluster. Now you’ll need your YAML. It may well be weeks since you last looked at Helm charts. You end up cutting and pasting your last configuration. But now you need to use another feature of Helm, can you remember the exact settings for the feature. So now you’re trawling the net for documentation, and then it takes several tries to get it right.

AI may well step in to help developers in this area, where solutions and products are well-documented. But with the wrong model or insufficient detail in the prompt, it’s easy to make a mistake. Personally, I’d turn to AI when it becomes necessary to trawl code to better understand the configuration and its behaviour, and to set options.

Experimental Solution

Solution – well, that depends upon the configuration syntax. We have been experimenting with RJSF (React JSON Schema Form), which provides a React-based UI that can be dynamically driven by a JSON schema and validate data with AJV (an alternative stack considered would have been around JSON Forms).

 {    "type": "object",    "title": "Dummy",    "properties": {      "name": {        "type": "string",        "const": "dummy",        "title": "Plugin"      },      "copies": {        "type": "integer",        "description": "Number of messages to generate each time messages are generated.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "integer",        "default": 1      },      "dummy": {        "type": "string",        "description": "Dummy JSON record.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "string",        "default": "{\"message\":\"dummy\"}"      },      "fixed_timestamp": {        "type": "boolean",        "description": "If enabled, use a fixed timestamp.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "boolean",        "default": false      }    }  }  

The above fragment shows part of the Schema definition for the Dummy plugin for Fluent Bit.

By then creating a schema that defines the different plugins, attributes, etc., we can drive validation and menu items easily in the UI. Admittedly, the config file is significant given all the plugins and configuration options, but it is a fair price to pay for a UI that validates the data. Establishing the schema to start with, we’ve covered it through scripting the retrieval and scraping of the Fluent Bit pages, which are pretty consistent in structure.

We have added some custom elements into the definition, for example, x-doc-reference, which allows us to extend the React components to provide features such as a link back to the original documentation as you select attributes or plugins.

As a result, we very quickly have a UI that can look like this:

A lot easier to view and tweak, with no need to hunt for valid options. Even if we want more information, we’re just a button click away from the open-source data. Perhaps we should provide a version that hyperlinks to the Manning Live Books on Fluent Bit, etc.

There are a few other factors to consider; for example, Fluent Bit configuration is YAML, not JSON, which can be easily resolved given the relationship between the two standards. Then there are processors that can embed Lua code or a SQL-like syntax. As we’ve chosen to provide a Python backend, we’ve addressed this by providing REST endpoints which can query out of the JSON the code or SQL and perform validation using the Python Lua Parser, and the SQL syntax can be addressed using the Lark library for processing the SQL, as the syntax is simple enough to define and maintain the syntax.

Outstanding Gaps for Fluent Bit

We still need to address several features that Fluent Bit has, specifically:

• Environment variables
• Includes

These issues should be straightforward to overcome, although dynamically including the included elements into the UI view elements can be done. The challenge is: if any changes need to go into something that has been included, how do we push them back to the included file? Particularly if there are multiple layers of inclusion.

What about Fluentd?

Fluentd configuration isn’t JSON-based notation, but it is structured. So, to apply the same mechanism, we’ll need to define a schema and a mapping mechanism. The tricky part of the schema is that Fluentd supports nesting plugins, since the way pipelines are defined for routing differs. While JSON schema will enable this with constructs such as anyOf, oneOf, object nesting, and bounded object arrays, the structure will be more complex.

The second challenge will be the transformer/renderer, so we don’t introduce issues from having to escape and unescape characters, since JSON Schema is stricter about character use.

Then What?

Well, if we get this going, we’ll probably incorporate the capability into our OpAMP project and maybe create a build that lets the configuration tool run independently. Lastly, perhaps we should look to see if we can make the different layers a little more abstract, so we can plug in editors for other configurations, such as OTel Collectors or the ELK Stack.

As a bonus, perhaps transform the Schema into a quick reference web document?

Reduce developer friction – Configuring tools like Fluent Bit (and Fluentd)

Something that vendors like Microsoft have been really good at is reducing the friction on getting started – from simplifying installations with MSI files and defaulted options through to very informative error messages in Excel when you’ve got a function slightly wrong. Apple is another good example of this; while no two Android phones are the same, my experience is that setting up an iPhone is just so much easier than setting up an Android phone. It is also the setup/configuration where most friction comes from.

Open-Source Software (OSS), as a generalisation, tend to be a bit weaker at minimising friction – this comes from several factors:

• When OSS is part of a business model, vendors can reduce that friction, making their enhanced version more attractive.
• OSS contributors are typically focused on the core problem space and are usually close enough to the fine details to not need those fancy features to keep the rest of us out of trouble.
• The expectation is that tools to make configuration easy are embedded in the application, making it heavier, when the aim is to keep things as light as possible.
• Occasionally, a little bit of intellectual snobbery can creep in

The common challenge

The issue that I have observed is that we often go through cycles of working with a technology. For example, you’re building a microservice. Chances are, you’ll start writing and running it locally, without worrying about containerization. Once you’re pretty happy with things, you’ll Dockerize the service, start testing it locally, and then you’ll be ready to deploy it to a cluster. Now you’ll need your YAML. It may well be weeks since you last looked at Helm charts. You end up cutting and pasting your last configuration. But now you need to use another feature of Helm, can you remember the exact settings for the feature. So now you’re trawling the net for documentation, and then it takes several tries to get it right.

AI may well step in to help developers in this area, where solutions and products are well-documented. But with the wrong model or insufficient detail in the prompt, it’s easy to make a mistake. Personally, I’d turn to AI when it becomes necessary to trawl code to better understand the configuration and its behaviour, and to set options.

Experimental Solution

Solution – well, that depends upon the configuration syntax. We have been experimenting with RJSF (React JSON Schema Form), which provides a React-based UI that can be dynamically driven by a JSON schema and validate data with AJV (an alternative stack considered would have been around JSON Forms).

 {    "type": "object",    "title": "Dummy",    "properties": {      "name": {        "type": "string",        "const": "dummy",        "title": "Plugin"      },      "copies": {        "type": "integer",        "description": "Number of messages to generate each time messages are generated.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "integer",        "default": 1      },      "dummy": {        "type": "string",        "description": "Dummy JSON record.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "string",        "default": "{\"message\":\"dummy\"}"      },      "fixed_timestamp": {        "type": "boolean",        "description": "If enabled, use a fixed timestamp.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "boolean",        "default": false      }    }  }  

The above fragment shows part of the Schema definition for the Dummy plugin for Fluent Bit.

By then creating a schema that defines the different plugins, attributes, etc., we can drive validation and menu items easily in the UI. Admittedly, the config file is significant given all the plugins and configuration options, but it is a fair price to pay for a UI that validates the data. Establishing the schema to start with, we’ve covered it through scripting the retrieval and scraping of the Fluent Bit pages, which are pretty consistent in structure.

We have added some custom elements into the definition, for example, x-doc-reference, which allows us to extend the React components to provide features such as a link back to the original documentation as you select attributes or plugins.

As a result, we very quickly have a UI that can look like this:

A lot easier to view and tweak, with no need to hunt for valid options. Even if we want more information, we’re just a button click away from the open-source data. Perhaps we should provide a version that hyperlinks to the Manning Live Books on Fluent Bit, etc.

There are a few other factors to consider; for example, Fluent Bit configuration is YAML, not JSON, which can be easily resolved given the relationship between the two standards. Then there are processors that can embed Lua code or a SQL-like syntax. As we’ve chosen to provide a Python backend, we’ve addressed this by providing REST endpoints which can query out of the JSON the code or SQL and perform validation using the Python Lua Parser, and the SQL syntax can be addressed using the Lark library for processing the SQL, as the syntax is simple enough to define and maintain the syntax.

Outstanding Gaps for Fluent Bit

We still need to address several features that Fluent Bit has, specifically:

• Environment variables
• Includes

These issues should be straightforward to overcome, although dynamically including the included elements into the UI view elements can be done. The challenge is: if any changes need to go into something that has been included, how do we push them back to the included file? Particularly if there are multiple layers of inclusion.

What about Fluentd?

Fluentd configuration isn’t JSON-based notation, but it is structured. So, to apply the same mechanism, we’ll need to define a schema and a mapping mechanism. The tricky part of the schema is that Fluentd supports nesting plugins, since the way pipelines are defined for routing differs. While JSON schema will enable this with constructs such as anyOf, oneOf, object nesting, and bounded object arrays, the structure will be more complex.

The second challenge will be the transformer/renderer, so we don’t introduce issues from having to escape and unescape characters, since JSON Schema is stricter about character use.

Then What?

Well, if we get this going, we’ll probably incorporate the capability into our OpAMP project and maybe create a build that lets the configuration tool run independently. Lastly, perhaps we should look to see if we can make the different layers a little more abstract, so we can plug in editors for other configurations, such as OTel Collectors or the ELK Stack.

As a bonus, perhaps transform the Schema into a quick reference web document?

Reduce developer friction – Configuring tools like Fluent Bit (and Fluentd)

Something that vendors like Microsoft have been really good at is reducing the friction on getting started – from simplifying installations with MSI files and defaulted options through to very informative error messages in Excel when you’ve got a function slightly wrong. Apple is another good example of this; while no two Android phones are the same, my experience is that setting up an iPhone is just so much easier than setting up an Android phone. It is also the setup/configuration where most friction comes from.

Open-Source Software (OSS), as a generalisation, tend to be a bit weaker at minimising friction – this comes from several factors:

• When OSS is part of a business model, vendors can reduce that friction, making their enhanced version more attractive.
• OSS contributors are typically focused on the core problem space and are usually close enough to the fine details to not need those fancy features to keep the rest of us out of trouble.
• The expectation is that tools to make configuration easy are embedded in the application, making it heavier, when the aim is to keep things as light as possible.
• Occasionally, a little bit of intellectual snobbery can creep in

The common challenge

The issue that I have observed is that we often go through cycles of working with a technology. For example, you’re building a microservice. Chances are, you’ll start writing and running it locally, without worrying about containerization. Once you’re pretty happy with things, you’ll Dockerize the service, start testing it locally, and then you’ll be ready to deploy it to a cluster. Now you’ll need your YAML. It may well be weeks since you last looked at Helm charts. You end up cutting and pasting your last configuration. But now you need to use another feature of Helm, can you remember the exact settings for the feature. So now you’re trawling the net for documentation, and then it takes several tries to get it right.

AI may well step in to help developers in this area, where solutions and products are well-documented. But with the wrong model or insufficient detail in the prompt, it’s easy to make a mistake. Personally, I’d turn to AI when it becomes necessary to trawl code to better understand the configuration and its behaviour, and to set options.

Experimental Solution

Solution – well, that depends upon the configuration syntax. We have been experimenting with RJSF (React JSON Schema Form), which provides a React-based UI that can be dynamically driven by a JSON schema and validate data with AJV (an alternative stack considered would have been around JSON Forms).

 {    "type": "object",    "title": "Dummy",    "properties": {      "name": {        "type": "string",        "const": "dummy",        "title": "Plugin"      },      "copies": {        "type": "integer",        "description": "Number of messages to generate each time messages are generated.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "integer",        "default": 1      },      "dummy": {        "type": "string",        "description": "Dummy JSON record.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "string",        "default": "{\"message\":\"dummy\"}"      },      "fixed_timestamp": {        "type": "boolean",        "description": "If enabled, use a fixed timestamp.",        "x-doc-reference": "https://docs.fluentbit.io/manual/data-pipeline/inputs/dummy#configuration-parameters",        "x-doc-required": false,        "x-config-data-type": "boolean",        "default": false      }    }  }  

The above fragment shows part of the Schema definition for the Dummy plugin for Fluent Bit.

By then creating a schema that defines the different plugins, attributes, etc., we can drive validation and menu items easily in the UI. Admittedly, the config file is significant given all the plugins and configuration options, but it is a fair price to pay for a UI that validates the data. Establishing the schema to start with, we’ve covered it through scripting the retrieval and scraping of the Fluent Bit pages, which are pretty consistent in structure.

We have added some custom elements into the definition, for example, x-doc-reference, which allows us to extend the React components to provide features such as a link back to the original documentation as you select attributes or plugins.

As a result, we very quickly have a UI that can look like this:

A lot easier to view and tweak, with no need to hunt for valid options. Even if we want more information, we’re just a button click away from the open-source data. Perhaps we should provide a version that hyperlinks to the Manning Live Books on Fluent Bit, etc.

There are a few other factors to consider; for example, Fluent Bit configuration is YAML, not JSON, which can be easily resolved given the relationship between the two standards. Then there are processors that can embed Lua code or a SQL-like syntax. As we’ve chosen to provide a Python backend, we’ve addressed this by providing REST endpoints which can query out of the JSON the code or SQL and perform validation using the Python Lua Parser, and the SQL syntax can be addressed using the Lark library for processing the SQL, as the syntax is simple enough to define and maintain the syntax.

Outstanding Gaps for Fluent Bit

We still need to address several features that Fluent Bit has, specifically:

• Environment variables
• Includes

These issues should be straightforward to overcome, although dynamically including the included elements into the UI view elements can be done. The challenge is: if any changes need to go into something that has been included, how do we push them back to the included file? Particularly if there are multiple layers of inclusion.

What about Fluentd?

Fluentd configuration isn’t JSON-based notation, but it is structured. So, to apply the same mechanism, we’ll need to define a schema and a mapping mechanism. The tricky part of the schema is that Fluentd supports nesting plugins, since the way pipelines are defined for routing differs. While JSON schema will enable this with constructs such as anyOf, oneOf, object nesting, and bounded object arrays, the structure will be more complex.

The second challenge will be the transformer/renderer, so we don’t introduce issues from having to escape and unescape characters, since JSON Schema is stricter about character use.

Then What?

Well, if we get this going, we’ll probably incorporate the capability into our OpAMP project and maybe create a build that lets the configuration tool run independently. Lastly, perhaps we should look to see if we can make the different layers a little more abstract, so we can plug in editors for other configurations, such as OTel Collectors or the ELK Stack.

As a bonus, perhaps transform the Schema into a quick reference web document?

Elk, Grand Teton National Park. April, 2019. 📷 Fujifilm X-T3 + XF100-400mmF4.5-5.6 R LM OIS WR 🎞 400 mm – 1/600″ – f/8 – ISO 1600 🏷️ #Elk #Wildlife #Photography #NationalParks

#SilentSunday #photography #Elk #Evergreen #Colorado #RockyMountains

Painting on paper, 20 x 30 cm: Ambiguous impulses for your mental cinema!
#kunst #analogueArt #painting #mentalCinema #contemporaryArt #rubberStamp #reliefPrinting #acrylicColours #climateActionNow #saveBioDiversity #systemChange #endFossilFuels #makeArtNotWar #NoRacism #noAFD #NoFascism #tightRopeWalking #artist #acrobat #topper #balancing #equilibrium #umbrella #elk #moose #wheat #nutrition #harvest #feedTheWorld #screamingLoud #screamingHeads #screamingMen

Painting on paper, 20 x 30 cm: Ambiguous impulses for your mental cinema!
#kunst #analogueArt #painting #mentalCinema #contemporaryArt #rubberStamp #reliefPrinting #acrylicColours #climateActionNow #saveBioDiversity #systemChange #endFossilFuels #makeArtNotWar #NoRacism #noAFD #NoFascism #tightRopeWalking #artist #acrobat #topper #balancing #equilibrium #umbrella #elk #moose #wheat #nutrition #harvest #feedTheWorld #screamingLoud #screamingHeads #screamingMen

Painting on paper, 20 x 30 cm: Ambiguous impulses for your mental cinema!
#kunst #analogueArt #painting #mentalCinema #contemporaryArt #rubberStamp #reliefPrinting #acrylicColours #climateActionNow #saveBioDiversity #systemChange #endFossilFuels #makeArtNotWar #NoRacism #noAFD #NoFascism #tightRopeWalking #artist #acrobat #topper #balancing #equilibrium #umbrella #elk #moose #wheat #nutrition #harvest #feedTheWorld #screamingLoud #screamingHeads #screamingMen

Painting on paper, 20 x 30 cm: Ambiguous impulses for your mental cinema!
#kunst #analogueArt #painting #mentalCinema #contemporaryArt #rubberStamp #reliefPrinting #acrylicColours #climateActionNow #saveBioDiversity #systemChange #endFossilFuels #makeArtNotWar #NoRacism #noAFD #NoFascism #tightRopeWalking #artist #acrobat #topper #balancing #equilibrium #umbrella #elk #moose #wheat #nutrition #harvest #feedTheWorld #screamingLoud #screamingHeads #screamingMen

Painting on paper, 20 x 30 cm: Ambiguous impulses for your mental cinema!
#kunst #analogueArt #painting #mentalCinema #contemporaryArt #rubberStamp #reliefPrinting #acrylicColours #climateActionNow #saveBioDiversity #systemChange #endFossilFuels #makeArtNotWar #NoRacism #noAFD #NoFascism #tightRopeWalking #artist #acrobat #topper #balancing #equilibrium #umbrella #elk #moose #wheat #nutrition #harvest #feedTheWorld #screamingLoud #screamingHeads #screamingMen

National Elk Refuge, Wyoming. March, 2018. 📷 Fujifilm X-T2 + XF100-400mmF4.5-5.6 R LM OIS WR 🎞 252 mm – 1/2000″ – f/5 – ISO 200 🏷️ #NationalWildlifeRefuges #Photography #Elk #Wildlife

Bull Elk, Grand Teton National Park. October, 2019.

📷 Fujifilm X-T3 + XF100-400mmF4.5-5.6 R LM OIS WR
🎞 400 mm – 1/500″ – f/8 – ISO 5000
🔗 https://www.allencompassingtrip.com/3166/bull-elk?utm_campaign=random&utm_medium=social&utm_source=Mastodon

#NationalParks #Wildlife #Photography #Elk

Sci-Fi Deer1 #Scifi #Beast #Character #Scifi #Mech #Elk #Animated #Npc #Enemy #Postapocalyptic #Lowpoly #Pbr #AssetStore

https://u3dn.com/packages/sci-fi-deer1-285949

I see #elk does syntax highlighting of code blocks, but lisp gets no respect

Kelly Warm Spring, Grand Teton National Park. March, 2018. 📷 Fujifilm X-T2 + XF100-400mmF4.5-5.6 R LM OIS WR 🎞 400 mm – 1/800″ – f/5.6 – ISO 200 🏷️ #NationalParks #Photography #Wildlife #Elk

Elk, Grand Teton National Park. August, 2019.

📷 Fujifilm X-T3 + XF100-400mmF4.5-5.6 R LM OIS WR
🎞 400 mm – 1/1250″ – f/8 – ISO 1600
🔗 https://www.allencompassingtrip.com/2959/elk?utm_campaign=random-wildlife&utm_medium=social&utm_source=Mastodon

#Wildlife #NationalParks #Elk #Photography

Bull Elk at the National Elk Refuge, Wyoming. January, 2020. 📷 Fujifilm X-T3 + XF100-400mmF4.5-5.6 R LM OIS WR 🎞 400 mm – 1/500″ – f/8 – ISO 800 🏷️ #Wildlife #Elk #Photography #NationalWildlifeRefuges

Elk’s Paradise
Don’t forget to enjoy the moments you can.

#photography #nature #landscape #elk #silentsunday

Elk, Antelope Flats, Grand Teton National Park. April, 2020.

📷 Fujifilm X-T3 + XF100-400mmF4.5-5.6 R LM OIS WR
🎞 400 mm – 1/500″ – f/11 – ISO 8000
🔗 https://www.allencompassingtrip.com/3432/elk?utm_campaign=random-wildlife&utm_medium=social&utm_source=Mastodon

#NationalParks #Photography #Elk #Wildlife

@pontasu #Mastodon :mastodon: の Web クライアントもサードパーティーのもので複数のアカウントでログイン出来るものがあるのでそういうのを使うとよいかもしれません〜 :tony_santa:

ちなみに僕は #PhanpySocial というのを使ってまして、こちらもマルチアカウント利用できます✨（ただ、ブラウザ通知飛ばせるのは1アカウントだけですが）
https://phanpy.social/

Web 版のクライアントだと他にも #Elk とかもマルチアカウントで使えたはず…です！
https://elk.zone/

ご参考まで〜 :mastodon_mascot:

#wildlifephotography #wildlife #photography #elk

I caught up with some Tule #Elk in some tule fog, go figure. I have no idea what to do with my camera in thick fog, I put my Z6iii on all auto. Old 600mm Sigma with Z mount adaptor. I ran the pics through DXO and then still had to play with it, fog is weird.
#wildlifephotography #wildlife #photography

Last week, I posted a question on Mastodon to check if people are using @elk. We got a massive response and some interesting insights. In this video I go through the data and what it means for the future of Elk.

👉 https://www.youtube.com/watch?v=AEi-lhFC0x8

#mastodon #fediverse #socialweb #elk #decentralized #socialmedia #socialnetworkingapp #foss #opensource #webdevelopment #webdeveloper

One year the elk shared the bison's huge pasture. I wish they did this with more animals that can easily co-exist.

#Elk #Bison #TorontoZoo #JPegsFolder

Anyone else get this auth failure with Elk?

#elk #mastodon

Elk, Grand Teton National Park. April, 2019. 📷 Fujifilm X-T3 + XF100-400mmF4.5-5.6 R LM OIS WR 🎞 400 mm – 1/1100″ – f/8 – ISO 1600 🏷️ #Photography #NationalParks #Elk #Wildlife

Как я собрал AI-оркестратор расследования продовых инцидентов на `SKILL.md`, субагентах и API

Тикет «404 на оплате» раньше означал для меня 5 вкладок и 15-20 минут ручного расследования: Sentry, Kibana, Grafana, база, Jira. Я собрал AI-оркестратор расследования на SKILL.md , субагентах и обычных API: теперь агент за 3-5 минут приносит первый черновик отчёта. Показываю архитектуру, контракт между агентами, рабочие формулировки и границы, где AI-оркестрация реально помогает, а где начинает буксовать.

https://habr.com/ru/articles/1013858/

#Claude_Code #SKILLmd #Agent_Skills #субагенты #MCP #автоматизация #Sentry #ELK

Как я собрал AI-оркестратор расследования продовых инцидентов на `SKILL.md`, субагентах и API

Тикет «404 на оплате» раньше означал для меня 5 вкладок и 15-20 минут ручного расследования: Sentry, Kibana, Grafana, база, Jira. Я собрал AI-оркестратор расследования на SKILL.md , субагентах и обычных API: теперь агент за 3-5 минут приносит первый черновик отчёта. Показываю архитектуру, контракт между агентами, рабочие формулировки и границы, где AI-оркестрация реально помогает, а где начинает буксовать.

https://habr.com/ru/articles/1013858/

#Claude_Code #SKILLmd #Agent_Skills #субагенты #MCP #автоматизация #Sentry #ELK

Sebagai catatan, sudah dicoba buat akses #gotosocial:

• #tuba (Linux flatpak, bisa tulis markdown)
• #tusky (android, tidak bisa tulis markdown)
• #moshidon (android, bisa tulis markdown)
• #pinafore (web, tidak bisa tulis markdown)
• #enaforce (web, fork dari pinaforce, bisa tulis markdown)
• #phanpy (web, tidak bisa tulis markdown)
• #elk dot zone (web, bisa tulis markdown tapi tidak ke-render di mastodon dan aplikasi lain)

PEMENANG SAAT INI VERSI SAYA:

• tuba buat di desktop linux saya.
• moshidon buat di hape android saya.

Maaf, tidak bisa test lingkungan lain (windows, macos, ios, dll), anggap saja "tidak ada akses" ke perangkat-perangkat tersebut.

Hype for the Future 121J: The Pennsylvania Wilds

https://novatopflex.wordpress.com/2026/03/01/hype-for-the-future-112j-the-pennsylvania-wilds/

Using #macOS and other apple ecosystem exclusive apps has ruined Windows for me in a way.

Like... outside of web clients like #Elk, there doesn't seem to be any good #Windows clients for #Mastodon. I tried #Tokodon by #KDE, but it's broken on Windows. It doesn't load icons...

Anyone know of Mastodon clients? Thank you!

A debilitating #hoof disease affecting #elk herds across the Pacific Northwest appears to be driven not by a single #pathogen but by multiple #bacterial species working together
#Veterinary #Microbiology #VeterinaryMicrobiology #WildlifeEpidemiology #sflorg
https://www.sflorg.com/2026/02/vet02022601.html

A debilitating #hoof disease affecting #elk herds across the Pacific Northwest appears to be driven not by a single #pathogen but by multiple #bacterial species working together
#Veterinary #Microbiology #VeterinaryMicrobiology #WildlifeEpidemiology #sflorg
https://www.sflorg.com/2026/02/vet02022601.html

A debilitating #hoof disease affecting #elk herds across the Pacific Northwest appears to be driven not by a single #pathogen but by multiple #bacterial species working together
#Veterinary #Microbiology #VeterinaryMicrobiology #WildlifeEpidemiology #sflorg
https://www.sflorg.com/2026/02/vet02022601.html

A debilitating #hoof disease affecting #elk herds across the Pacific Northwest appears to be driven not by a single #pathogen but by multiple #bacterial species working together
#Veterinary #Microbiology #VeterinaryMicrobiology #WildlifeEpidemiology #sflorg
https://www.sflorg.com/2026/02/vet02022601.html

A debilitating #hoof disease affecting #elk herds across the Pacific Northwest appears to be driven not by a single #pathogen but by multiple #bacterial species working together
#Veterinary #Microbiology #VeterinaryMicrobiology #WildlifeEpidemiology #sflorg
https://www.sflorg.com/2026/02/vet02022601.html

Сервисы — место, где живет бизнес-логика II

Здравствуйте! Это вторая часть из серии статей « Сервисы — место, где живет бизнес логика ». Если Вы еще не знакомы с первой частью , то рекомендую начать с нее, чтобы у вас сложилась общая картина. Сегодня мы постараемся ответить на все оставшиеся вопросы: познакомимся с прекрасной, легковесной DI-библиотекой , научимся « инжектить » в Django , посмотрим на несколько дашбордов в Кибане и поговорим про доменные модели.

https://habr.com/ru/articles/983228/

#python #django #drf #сервисы #di #dependency #injection #elk #сервисный #слой

US #BlackHawk #helicopter trespasses on private #Montana ranch to grab #elk #antlers

Was it really possible that US #military personnel were using multimillion-dollar government aircraft to land on private property in the #CrazyMountains —yes, that's their actual name—just to grab some antlers valued at a few hundred bucks?

https://arstechnica.com/culture/2026/01/us-black-hawk-helicopter-trespasses-on-private-montana-ranch-to-grab-elk-antlers/

@ethicalrevolution Thanks.
Happy holidays from #Platon, #Teddy, fake #plushtodon, a fake #Elk mascot and me.

Return Of Wolves To Yellowstone Has Led To A Surge In Aspen Trees Unseen For 80 Years
--
https://www.livescience.com/animals/land-mammals/return-of-wolves-to-yellowstone-has-led-to-a-surge-in-aspen-trees-unseen-for-80-years <-- shared technical article
--
https://doi.org/10.1016/j.foreco.2025.122941 <-- shared paper
--
https://cdn.jwplayer.com/previews/pwZObUXR <-- shared video
--
https://www.livescience.com/animals/land-mammals/reintroducing-wolves-to-yellowstone-helped-entire-ecosystem-thrive-20-year-study-finds <-- shared related technical article
--
"Gray wolves were reintroduced in Yellowstone National Park in 1995 to help control the numbers of elk that were eating young trees, and it is finally paying off for quaking aspen...."
#elk #cervuscanadensis #bison #bisonbison #wolf #wolves #canislupus #quakingaspen #populustremuloides #herd #browsing #predation #aspen #vegetation #forest #rophiccascade #yellowstone #YellowstoneNationalPark #ecosystem #restoration #natural #balance #canopy #graywolves #habitatloss #predator #saplings #growth #mature #ecology #reintroduction #survey #spatialanalysis #spatiotemporal #herbaceous #browsing

Пошаговая настройка вывода логов из .NET-автотестов в ELK (Filebeat → Logstash → Elasticsearch → Kibana)

Всем привет, с вами Юрий Ковальчук, backend разработчик в ВебРайз. В этой статье разберем процесс вывода логов из приложения c автотестами на .NET в ELK с последующей визуализаций в Kibana. ELK представляет из себя достаточно массивный инструмент для сбора, хранения, обработки и анализа логов, организации мониторингов. С наскоку разобраться с ним вряд ли получится, поэтому подготовили небольшую инструкцию с примерами - на базе простого теста прокинуть результаты до Kibana.

https://habr.com/ru/articles/966038/

#elk #elasticsearch #logstash #kibana #filebeat #логирование #логи #net #net_core #c#

#elk #elks #pic #pictures #picture #pics #animal #animals

Elk herd while out hiking - taken near Enumclaw, WA, Mt. Peak area. #enumclaw #washington #elk #nature #photography #photo #naturephotography #wildlife #critters

@da_667 you know you sell people a bunch of pc butfor medium biz they really can benefit from stuff like debian, dual nas, opnsense, pihole, - the basics but also faster networking, ids/ips system, pkt cap 24/7, even ssl proxy, rsync backups to nvme. having more visibility into the network allows organizations to leverage the data that piles up in the db as well as real time. a point needs to be made for the minimum raw basic infrastructure and then orgs can realize gestalt #p2v #fwupd #elk stack scripting #dashboards #centralized logs #netbox #zeek #snort #sigs

@da_667 you know you sell people a bunch of pc butfor medium biz they really can benefit from stuff like debian, dual nas, opnsense, pihole, - the basics but also faster networking, ids/ips system, pkt cap 24/7, even ssl proxy, rsync backups to nvme. having more visibility into the network allows organizations to leverage the data that piles up in the db as well as real time. a point needs to be made for the minimum raw basic infrastructure and then orgs can realize gestalt #p2v #fwupd #elk stack scripting #dashboards #centralized logs #netbox #zeek #snort #sigs