Report handles all the reporting events sent from the Pool, currently it exclusively sends these upstream to a Splunk server which then does further handling. The events are sent from the pool via calls to this instance’s functions that in turn call send().
Reporting can be disabled putting None (or a blank field) in the initial settings page. This has the same effect as not including the #report=”url” option within the options header of a script before conversion.
The reporting class also takes in the custom id="", run="", and project="" from kwargs / initial settings. It uses these settings when communicating unstream with the reporting server.
Parameters: | pool – Reference to our owning pool. This is primarily to access pool.options and not used much elsewhere. |
---|---|
Returns: | Report (self) |
See also
Sends a child process killed notification payload.
Parameters: | child – The index of the child reporting in self.children/pool.data. |
---|---|
Returns: | None |
If self.id was not already set by the user, it generates a deterministic ID based on the user running the script and the machine’s name.
Returns: | None |
---|
Sends a job failed notification payload.
Parameters: |
|
---|---|
Returns: | None |
Sends a job finish notification payload.
Parameters: |
|
---|---|
Returns: | None |
Sends a job start notification payload.
Parameters: | child – The index of the child reporting in pool.children/pool.data. |
---|---|
Returns: | None |
Sends a new child notification payload. This is called even when a child is restarted.
Parameters: | child – The index of the child reporting in self.children/pool.data. |
---|---|
Returns: | None |
Send enables a payload to be parsed and added into our local queue for transmission reporting server, where applicable. It is called as a sort of wrapper function from all of the individual reporting functions (such as endchild()) to facilitate standard transmission of the data upstream.
Currently (to be fixed) it encodes repeat information in every single payload including all identifying characteristics about the run, pool, and our id. There’s major issue for this except for further stressing network bandwidth and the JSON parser.
Parameters: |
|
---|
Sends data to a Splunk sever encoded in JSON.
Parameters: | data – JSON of data to send to the splunk server. |
---|---|
Returns: | The parsed splunk event on success. |
our payload (many individual reports) to the Splunk server.
If our report.queue has content in it, it prepares to send everything upstream. The payload is transmitted in JSON with the following general format:
{
"cid" => #, // Our client ID assigned by the server, nil if we don't have one yet.
"rid" => #, // Our run ID assined by the server, ^
"type" => R_START, // For example, this is the type of payload here.
"time" => UNIX_EPOCH, // Since sometimes the Queue has a delay in transmission, each
// payload contains it own timestamp.
// Some miscellaneous identifying information goes in here that's deprecated
// and unused.
// If the type involves a child:
"ChildID" => #, // The index of our child in pool.children / pool.data
// If the type involves a job:
"timetaken" => UNIX_EPOCH //The time the job took to complete.
}
This module attempts to send the payload upstream 5 times, waiting 5 seconds between reattempts. On the fifth failure it never tries again. It is noted in the log when it gives up.
Returns: | None |
---|