Add a common notifications client & its utilities #145
Conversation
yhabteab
force-pushed
the
notifications
branch
2 times, most recently
from
609ec3f to
82eff34
Compare
|
I'm not sure if this is the right place to add this. The reasoning probably is similar to Icinga/icinga-notifications#304. One thing to consider here: do we expect external projects using this eventually? In this case, this would create dependency updates for them even though if nothing relevant to them changed. So I think having a separate repository with independent versioning for this is also worth considering. |
yhabteab
force-pushed
the
notifications
branch
2 times, most recently
from
e4215c5 to
55c038b
Compare
I like this idea. How about a MIT licensed |
|
After today's discussion to keep these changes in the IGL, I have skimmed the PR once again. In general, it looks good to me. However, it should be merged together with its sibling PRs as otherwise fix-up PRs would follow here. |
yhabteab
force-pushed
the
notifications
branch
from
55c038b to
641e970
Compare
yhabteab
force-pushed
the
notifications
branch
from
641e970 to
5032573
Compare
notifications/source/client.go
Outdated
| Rules map[int64]RuleResp // Rules is a map of rule IDs to their corresponding RuleResp objects. | ||
| } | ||
|
|
||
| // Iter returns an iterator over the rules in the SourceRulesInfo. |
There was a problem hiding this comment.
| // Iter returns an iterator over the rules in the SourceRulesInfo. | |
| // Iter returns an iterator over the rules in the RulesInfo. |
There was a problem hiding this comment.
This code won't last long though ;)! When sources start to manage their own event rules config by their own, this will become obsolete.
yhabteab
force-pushed
the
notifications
branch
from
5032573 to
64209e7
Compare
Moved from Icinga Notifications with some enhancements made.
This is analogous to the `MakeInt` and `MakeString` functions but for Bool.
Alvar did most of the work here in the Icinga DB repo, I'm just trying to outsource the basic functionality to this library, so that they can also be used by other projects. Co-Authored-By: Alvar Penning <[email protected]>
yhabteab
force-pushed
the
notifications
branch
from
64209e7 to
f54aa70
Compare
|
Changed the tabular test cases to use |
- Bump IGL to latest changes in Icinga/icinga-go-library#145. - Allow specifying which pipeline keys are relevant, ignore others. - Allow specifying which pipeline key should be parsed in which type. - Create history.DowntimeHistoryMeta as a chimera combining history.DowntimeHistory and history.HistoryDowntime to allow access event_type, distinguishing between downtime_start and downtime_end. - Trace times for submission steps in the worker. Turns out, the single threaded worker blocks roughly two seconds for each Client.ProcessEvent method call. This might sum up to minutes if lots of events are processed at once. My current theory is that the delay results in the expensive bcrypt hash comparison on Notifications.
- Bump IGL to latest changes in Icinga/icinga-go-library#145. - Allow specifying which pipeline keys are relevant, ignore others. - Allow specifying which pipeline key should be parsed in which type. - Create history.DowntimeHistoryMeta as a chimera combining history.DowntimeHistory and history.HistoryDowntime to allow access event_type, distinguishing between downtime_start and downtime_end. - Trace times for submission steps in the worker. Turns out, the single threaded worker blocks roughly two seconds for each Client.ProcessEvent method call. This might sum up to minutes if lots of events are processed at once. My current theory is that the delay results in the expensive bcrypt hash comparison on Notifications.
Synchronize codebase against latest version of Icinga/icinga-go-library#145, containing package changes.
- Bump IGL to latest changes in Icinga/icinga-go-library#145. - Allow specifying which pipeline keys are relevant, ignore others. - Allow specifying which pipeline key should be parsed in which type. - Create history.DowntimeHistoryMeta as a chimera combining history.DowntimeHistory and history.HistoryDowntime to allow access event_type, distinguishing between downtime_start and downtime_end. - Trace times for submission steps in the worker. Turns out, the single threaded worker blocks roughly two seconds for each Client.ProcessEvent method call. This might sum up to minutes if lots of events are processed at once. My current theory is that the delay results in the expensive bcrypt hash comparison on Notifications.
This PR introduces a new
notificationspackage to our Icinga Go library. The package is designed to handle commonIcinga Notifications related tasks, that can be used by any Icinga Notifications source. It provides a set of functions and types that simplify and centralize the interaction with Icinga Notifications API. Within the root of this package, you will find the following files:
client.go: This file contains the actual client implementation with a custom HTTP round tripper that handlesthe necessary authentication before sending the final request to the Icinga API.
config.go: This file defines the configuration structure that every Icinga Notifications source is required to provide.xhttp_headers.go: This file contains our custom HTTP header constants only that should be used by the IcingaNotifications sources to ensure consistency and compatibility with the Icinga API. Currently, it includes only
X-Icinga-Rules-Versionheader, which is used to specify the version of the rules that are being used by the source andX-Icinga-Rules-Idheader, which is used to specify the unique identifier of the rules that are being used by the source.Of course, in order to be consistent with the HTTP header naming conventions in Icinga Web 2, both custom headers
are prefixed with
X-Icinga-.The
eventpackage within thenotificationspackage contains common event related types and utilities that shouldbe used by any Icinga Notifications source as well as by the Icinga Notifications daemon itself.
The change list appears to be quite big, but don't be fooled by it :). Most of them are just unit tests and autogenerated
code. The actual code changes are quite minimal and focused on the new functionality described above.
Oops, did I say autogenerated code? Yes, I did ;)! The
notificationspackage makes use of the Gostringertool to implement theString()method for theevent.Typeandevent.Severitytypes in an efficient manner. So, don't be surprised to see the autogenerated files in theeventpackage.Oh, and one more thing: most of the work was done by Alvar in the Icinga DB repository, so I just had to outsource it to the Icinga Go library with some minor adjustments. So, credit goes to him for the majority of the work.