{"id":2488,"date":"2011-07-14T21:41:07","date_gmt":"2011-07-14T19:41:07","guid":{"rendered":"http:\/\/contoso.se\/blog\/?p=2488"},"modified":"2011-07-14T21:41:07","modified_gmt":"2011-07-14T19:41:07","slug":"building-a-log-for-your-runbooks","status":"publish","type":"post","link":"http:\/\/contoso.se\/blog\/?p=2488","title":{"rendered":"Building a log for your runbooks"},"content":{"rendered":"

The last week I have been working on a way to handle logs for multiple runbooks in Orchestrator. Opalis and Orchestrator will\u00c2\u00a0executes but\u00c2\u00a0as soon as they are done, they\u00c2\u00a0will drop everything, and will not “remember anything”. They only\u00c2\u00a0keeps\u00c2\u00a0data in memory during execution (and maybe in some logs). That is one of the reasons why it is important to log to a external system when working with Opalis or Orchestrator. You most likely want to store information in a external system so you can go back and review it later, for example what triggered the runbook to\u00c2\u00a0start,\u00c2\u00a0what files was it moving\u00c2\u00a0and with which parameters? Some scenarios can be\u00c2\u00a0solved\u00c2\u00a0by using Service Manager and change management. When someone submits a change, you will have all the information in the change request, that will trigger Orchestrator. But there will not always be a change request, you could then use for example a SQL database that each runbook writes to.\u00c2\u00a0In this blogpost I share some ideas around logging to a SQL database. I will use the Orchestrator beta build but most of this you can build exactly the same in Opalis.<\/p>\n

In this example I have\u00c2\u00a0a runbook that creates the database I will use to store logs. Of course you can create the database manually, but it is easy to keep it in a runbook, easy if you copy the runbook to a new environment. Then you know that the database will be setup the same every time. The “Create LOG Database” runbook looks like<\/p>\n

\"\"<\/a><\/p>\n

    \n
  1. “Create log database”, creates the log database. If it works there is a 10 sec delay on the link before tables are created. If it doesn’t work it will go to 4\"\"<\/li>\n
  2. “Create tables”, creates tables in the database. If it works it will move on to 5, else it will go to 3<\/li>\n
  3. “Drop db”, deletes the database<\/li>\n
  4. “Error Event”, writes a platform event saying that the database or tables could not be created<\/li>\n
  5. “Get timestamp”, gets the current timestamp in a suitable format<\/li>\n
  6. “Insert test event”, test insert a event in the database<\/li>\n
  7. “Write Error Event”, if the test insert activity don\u00c2\u00b4t work a platform event is generated
    \n    \"\"<\/a><\/li>\n
  8. “Send OK event”, a platform event is generating saying the database has been created<\/li>\n
  9. Get a timestamp in correct format. I notice when I was moving this runbook between environment that the default time stamp is different, so I use this activity to format the data format to yyyy-M-d h:m:s<\/li>\n
  10. Insert a test event into the database<\/li>\n
  11. Send a platform event saying the database is created<\/li>\n<\/ol>\n

    After the database is created and is working we need to create the runbook that will add events to the database.\u00c2\u00a0 In the picture\u00c2\u00a0there is\u00c2\u00a0a example of a runbook that writes log data to the log database, the “write to log runbook”. When you trigger this runbook you need to send some parameters,<\/p>\n