Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #10465] API could accept check results in bulk #3553

Open
icinga-migration opened this issue Oct 26, 2015 · 7 comments
Open
Labels
area/api REST API enhancement New feature or request queue/wishlist

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/10465

Created by vytenis on 2015-10-26 16:10:25 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2015-11-25 16:06:56 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

Would be nice to be able to send check results to Icinga2 via the API in bulk, instead of 1 HTTP request per check.


Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-11-25 16:06:56 +00:00

  • Target Version set to Backlog

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-09-02 07:49:37 +00:00

  • Relates set to 12626

@icinga-migration icinga-migration added enhancement New feature or request area/api REST API labels Jan 17, 2017
@icinga-migration icinga-migration added this to the Backlog milestone Jan 17, 2017
@dnsmichi
Copy link
Contributor

PRs welcome as always. Keep in mind that you'll need to adjust the object name somehow, if different result sets are processed.

@dnsmichi dnsmichi modified the milestone: Backlog Sep 13, 2017
@dnsmichi dnsmichi added the needs-sponsoring Not low on priority but also not scheduled soon without any incentive label Nov 9, 2017
@dnsmichi dnsmichi self-assigned this Aug 2, 2019
@dnsmichi dnsmichi added this to the 2.12.0 milestone Sep 2, 2019
@dnsmichi dnsmichi modified the milestones: 2.12.0, 2.13.0 Oct 8, 2019
@dnsmichi dnsmichi removed the needs-sponsoring Not low on priority but also not scheduled soon without any incentive label Jan 14, 2020
@dnsmichi
Copy link
Contributor

Requires a new endpoint process-check-results with a an s suffix. This avoids different behaviour with the existing endpoint where this doesn't fit.

@dnsmichi
Copy link
Contributor

/v1/actions/process-check-results as URL endpoint.

Request body:

{
  "check_results": [
     {
       "name": "host1!svc",
       "exit_status": 2,
       "plugin_output": "Multiple results, 1"
     },
     {
       "name": "host2!svc",
       "exit_status": 1,
       "plugin_output": "Multiple results, 2"
     }
  ]
}

There's a few principles to keep in mind:

  • The process-check-result action requires a filter, and type parameter. For our approach with mapping each check result for a given host/service name, this does not work -> new action endpoint required.
  • The action handler needs to check for the check_results key being an array, and then loop over the structure.
  • Within each item being a Dictionary, extract the name, exit_status, plugin_output, etc. similar to the existing single action.
  • Get the object ptr from the given name string
  • Create a new CheckResult object, set along the attributes from the received item.
  • Call obj->ProcessCheckResult(cr); to finish processing

Additional tasks:

  • Error handling and sanity checks
  • Documentation

@lippserd The above will be done in short exercises by @sukhwinder33445 as shown below.

IMG_5452

@Al2Klimov
Copy link
Member

@sukhwinder33445 You're not working on this, right?

@sukhwinder33445
Copy link

Yes, I'm not working on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api REST API enhancement New feature or request queue/wishlist
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants