influxdata / influxdata/telegraf
Guidance on writing an internal vs external plugin
- Dominant language
- Go
- Stars
- 17.8k
- Forks
- 5.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 161
Description
### Use Case
I've started (and almost completed) a new Webhook plugin for Telegraf (based on the existing webhook plugins) that will receive requests from Jamf Pro (a device management framework - [info on their webhooks here](https://developer.jamf.com/developer-guide/docs/webhooks)). From an ease of consumption point of view, raising a PR to have this included in the main project would mean that other Systems Engineers could easily consume this data but I'm unsure whether this Input is too niche for the project.
There is already some great documentation around writing new plugins (even using the existing Webhook inputs as a template to create new ones), but there isn't clear guidance on whether this sort of niche plugin should be merged into the main project.
### Expected behavior
Clear guidance on what makes a good plugin to be included in the main project.
### Actual behavior
N/A
### Additional info
My initial work on the new Webhook plugins can be found here https://github.com/smithjw/telegraf/tree/feat/jamf_webhooks/plugins/inputs/webhooks/jamf
Contributor guide
Research direction
Read Telegraf's existing documentation on writing plugins and inspect the existing webhook inputs as templates. Review the proposed plugins/inputs/webhooks/jamf path for the concrete use case. Done means documenting clear criteria for choosing an internal versus external plugin, including whether a niche Jamf Pro input belongs in the main project.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100