Skip to end of metadata
Go to start of metadata

Monitor Properties

The current workflow engine properties that can be monitored are:

  • per facade
    • state (prepared, running, paused, completed, cancelled)
  • per processor
    • sentJobsCount
    • completedJobsCount
    • totalTranslatedErrors
    • totalReflectedErrors
  • per processor invocation
    • queueSize
    • errorsReflected
    • errorsTranslated
  • plus any properties added by MonitorableAsynchronousActivity - are there any?

Monitor Nodes

The workflow engine registers, and deregisters, monitor nodes as the workflow runs. The following workflow objects are currently regitered as nodes:

  • WorkflowInstanceFacade
    • registered - facade.fire()
    • deregistered - facade.checkWorkflowFinished()
  • Dataflow
    • registered - dataflow.tokenReceived()
    • deregistered - facade.checkWorkflowFinished()
  • Processor
    • registered - dataflow.tokenReceived()
    • deregistered - processor.dispatchStack.finishedWith() via facade.ProcessorFinishedObserver
  • Activity
    • registered invokeLayer.receiveJob()
    • deregistered invokeLayer.InvokeCallBack.fail(), receiveCompletion(), receiveResult()

Current Workbench Monitors

GraphMonitor

The GraphMonitor displays:

  • the ratio of completed interations to total interations (completedJobsCount / ((sentJobsCount + queueSize))
  • the number of completed iterations (completedJobsCount)
  • the number of errors (totalTranslatedErrors)

Progress Monitor

The ProgressMonitor displays:

  • the workflow/processor state
  • the number of queued iterations (queueSize)
  • the number of iterations done (sentJobsCount)
  • the number of iterations with errors (totalTranslatedErrors)
  • average time per iteration (calculated for activity monitors node register/deregister times)
  • first iteration started date
  • last iteration ended date

Platform Monitoring Proposals

The Platform will provide monitoring through a Workflow Report that will give access to the current monitor properties, the state of the workflow/processors and the times that states change.

Questions

Is there anything else that we would like to monitor?

Do we need to change the way the current monitoring works or is it enough to hide the complexity behind a new interface?

Monitoring and Provenance

The information recorded by the Provenance system and the proposed Workflow Report is duplicated in some cases. The Provenance information is collected independently of the monitoring system so the same workflow information may be recorded by different locations in the code. The following table is an attempt at a high level overview of the information captured by Provenance, the current Workbench and the proposed Platform.

Workflow Event

Provenance

Workbench

Platform

Comments

Workflow started

(tick)

(tick)

(error)

WorkflowFacade fired

Workflow finished

(tick)

(tick)

(error)

All processors finished and data on all ports

Workflow inputs

(tick)

(error)

(tick)


Workflow outputs

(tick)

(tick)

(tick)


Dataflow started

(error)

(tick)

(tick)

Dataflow fired

Dataflow finished

(error)

(tick)

(tick)

All processors finished and data on all ports

Processor started

(error)

(tick)

(tick)

All processors started when dataflow fired

Processor finished

(error)

(tick)

(tick)

Processor finishedWith

Processor iteration started

(tick)

(error)

(error)

Provenance layer job received

Processor iteration finished

(tick)

(error)

(error)

Provenance layer result/error received

Processor iteration inputs

(tick)

(error)

(error)


Processor iteration outputs

(tick)

(error)

(error)


Activity started

(tick)

(tick)

(tick)

Node registered

Activity finished

(error)

(tick)

(tick)

Node deregistered

Activity inputs

(error)

(error)

(error)


Activity outputs

(error)

(error)

(error)


Ideas from meeting on 2011-01-12

  • Need to rename events to make more obvious e.g. "Processor started" -> "Processor activated" and "Processor finished" -> "Processor deactivated"
  • Mixing of monitoring and provenance is confusing code-wise and conceptually.  David to look at the needs for provenance.
  • Need to be able (potentially) to capture looping, retries, values and errors

Ideas from meeting on 2011-01-18

  • Distinguish between what a listener can be notified about and what can be included in a report when they ask for it
  • Need to be able to register for notification
  • Need to authenticate when registering for notification or asking for report
  • Some enactors may have in-built notification mechanisms.  Need to be able to ask for those and also know how to register to use them.
  • David raised issue of too many notifications - so what you can be notified about is a subset of what can be included in a report
  • May not want all of a report, just a subset of it
  • Distinguish in a report between "zero activity invocations" and "activity invocations are not monitored"
  • Many of the enactor interactions, e.g. registration for notification and asking for a report, need to be available for the server.

Taverna server already has the potential to notify when a workflow run finishes.  For the next release, the ability to monitor workflow finishing and to be notified for that will be exposed as minimal examples of what can be done.

Labels
  • None
  1. 2011-01-19

    Andrea wants to be able to configure what provenance info is captured.