You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know the conversation about Splunk plugins isn’t new and a previous request was closed citing the “on call” plugin, but I wanted to open a discussion here that comesrr up all the time at our company:
Splunk logs, alerts, errors and links to indexes are an important part of a software engineer’s job. While easy access to runtimes and the logs they provide are nice, the minute a component is deployed to either a more complex runtime (multiple pods, cross-cluster for resiliency, etc) OR to multiple resources, you end up really benefiting from an aggregated log solution.
The problem lies in the fact that there may be a lack of a consistent interface for a reusable plugin, unlike the more predictable use cases in things like Dynatrace (problems, synthetics, dashboards).
In this case it seems that a Splunk plugin for backstage might actually generate a more consistent format and practice for aligning some common logging practices (structures?) for components, systems and resources.
The initial purpose here is more of an RFC to test the waters, but it seems like at a minimum it would be valuable to provide a link to the index containing the logs, with possibly more elegant support for a better UX if you choose to support some of those logging practices.
🌐 Project website (if applicable)
No response
✌️ Context
No response
👀 Have you spent some time to check if this plugin request has been raised before?
🔖 Summary
I know the conversation about Splunk plugins isn’t new and a previous request was closed citing the “on call” plugin, but I wanted to open a discussion here that comesrr up all the time at our company:
Splunk logs, alerts, errors and links to indexes are an important part of a software engineer’s job. While easy access to runtimes and the logs they provide are nice, the minute a component is deployed to either a more complex runtime (multiple pods, cross-cluster for resiliency, etc) OR to multiple resources, you end up really benefiting from an aggregated log solution.
The problem lies in the fact that there may be a lack of a consistent interface for a reusable plugin, unlike the more predictable use cases in things like Dynatrace (problems, synthetics, dashboards).
In this case it seems that a Splunk plugin for backstage might actually generate a more consistent format and practice for aligning some common logging practices (structures?) for components, systems and resources.
The initial purpose here is more of an RFC to test the waters, but it seems like at a minimum it would be valuable to provide a link to the index containing the logs, with possibly more elegant support for a better UX if you choose to support some of those logging practices.
🌐 Project website (if applicable)
No response
✌️ Context
No response
👀 Have you spent some time to check if this plugin request has been raised before?
✍️ Are you willing to maintain the plugin?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
No, I don't have time to work on this right now
The text was updated successfully, but these errors were encountered: