[nagios_xi] Add Nagios package with Service data stream #2944
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
packages/nagios_xi/manifest.yml
Outdated
| - monitoring | ||
| release: beta | ||
| conditions: | ||
| kibana.version: ^8.0.0 |
There was a problem hiding this comment.
This will be updated with 8.2.0 after testing this integration on 8.2.0.
kush-elastic
added
enhancement
|
Pinging @elastic/integrations (Team:Integrations) |
packages/nagios_xi/changelog.yml
Outdated
| changes: | ||
| - description: Nagios integration package with Logs, Host and Service metrics | ||
| type: enhancement | ||
| link: https://github.com/elastic/integrations/pull/2824 |
There was a problem hiding this comment.
nit: you have to update the PR link reference to point to this review.
| - name: nagios_xi | ||
| type: group | ||
| fields: | ||
| - name: service |
There was a problem hiding this comment.
Does it contain the same fields as for the host data stream?
There was a problem hiding this comment.
Not all the fields are same, but there are some common fields.
There was a problem hiding this comment.
I didn't check precisely the percentage of different fields, but maybe it's better to keep it as a single data stream. WDYT @ruflin ?
There was a problem hiding this comment.
The decision if one or multiple data streams should be less driven by how many fields are different then how users are going to consume it. Will some users only want to collect service or host? Will there be different retention periods?
There was a problem hiding this comment.
There are groups based on hosts and services.
If we consider merging host and service data-streams in one, user will get confused.
Services depends on hosts so same type of service can be collected from different hosts.
Another reason is, we have different endpoints for hosts and services. means we need two httpjson input.
And as we know we don't have a way to use multiple input in single data_stream.
There was a problem hiding this comment.
Thanks for the details @kush-elastic Based on this information I would go for 2 data streams for now. It is easier to merge 2 into one later on then the other way around I think.
| @@ -334,7 +334,7 @@ | |||
| "check_type": "0", | |||
| "current_check_attempt": "1", | |||
| "current_notification_number": "0", | |||
| "current_state": "0", | |||
| "current_state": "Up/Pending", | |||
kush-elastic
changed the title
| "failure_prediction_enabled": "0", | ||
| "flap_detection_enabled": "0", | ||
| "has_been_checked": "1", | ||
| "host_address": "www.nagios.org", |
There was a problem hiding this comment.
How these host* fields under the "service" metrics. Should these be part of core ECS host* fields. I am not sure, Checking with @mtojek
There was a problem hiding this comment.
Hey @lalit-satapathy,
In Nagios XI, There are groups based on hosts and services. and each services have again on specific hosts. so user will get confused if we show host name in both host and service data-stream. if we have different fields here user will be able to identify it much better.
Here services runs on specific hosts.
What do you think?
🌐 Coverage report
|
What does this PR do?
Checklist
changelog.ymlfile.How to test this PR locally
elastic-package testRelated issues
Screenshots