Not only did the task fail, it took nearly seven hours to fail. Now Mark can see details about the Epic Radiant Orders task. If Mark wants to investigate any task in detail, he can hover over it to see a tool tip for extra contextual information. The Big Book of Dashboardsįigure 18.1: The tool tip adds extra detail about the failure. The Epic Radiant Orders task is the clear problem on this day. Reference lines on each Gantt bar show the scheduled start time (dotted line) and the average time the task has taken(solid line). Gray ones succeeded, and red ones failed. Mark can see all the processes that took place that day. That’s a real problem, and significantly above the average failures for the previous 14 days. Mark can see that 6.7 percent of processes failed overnight. The average failure rate is shown as a dotted line. Comparing last night to the last two weeks allows Mark to easily see if last night was normal or an outlier. The most recent is at the far right (the highlighted bar in the overview dashboard). The bar chart at the top shows percentage of failures for each of the last 14 days. A static image of the dashboard is emailed to Mark Jackson, the dashboard designer, each morning. You are an event manager and need to track that tasks begin correctly and run to time.Īs an administrator responsible for keeping your enterprise’s systems up and running, you need to know if things are going wrong.You are a manufacturer and need to track the production schedule’s progress towards completion.Was this failure caused by a problem earlier in the process chain? Is this process consistently failing?
For any given failed process, you need extra contextual details to help you diagnose and fix the problem.If a high number fail or if some key processes fail, you need to click the email to go to the live dashboard and drill into the details. You need an email each morning with a summary report of overnight processes.If these processes are going to cause problems for the users, those problems need to be identified and addressed quickly. You manage a server and need to respond quickly if processes fail.Which processes are taking longer than usual?.Are the failing processes repeatedly failing?.Did our server processes succeed today?.To determine what to do next, you might ask the following questions: If it has, you need to do more research and decide on a course of action to fix the process. Also, you can delve into that process’s recent history to see if it’s been consistently problematic. If anything’s going wrong, you can jump directly to that process and take corrective action.
What you need is a dashboard you can look at each morning that shows you what, if anything, is holding up your server. You need to know if something went wrong with the overnight processes - before everyone gets to work. Your employees rely on your business intelligence service being online with the latest data when they arrive at work in the morning. Copyright © 2017 by Steve Wexler, Jeffrey Shaffer and Andy Cotgreave. Just because you have a http process running does not mean your web server is actually serving expected content.This article is excerpted from The Big Book of Dashboards: Visualizing Your Data Using Real-World Business Scenarios by Steve Wexler, Jeffrey Shaffer and Andy Cotgreave with the permission of Wiley.
The Web server is probably still serving traffic at this point though.ītw, you should also be doing URL monitoring for web sites. If your parent dies, but some children remain running (zombies) spectrum will not send an alert since you have more than 1 process running. If the parent dies, and kills all children you will have 0 "/usr/bin/httpd" process running. No alert is sent since there are more than 1 "/usr/bin/httpd" process running. Change to Less than 1 proc and more than 5 procs. Apache may spawn a new process "456" so it now looks like this: Spectrum sends alert since a pid has gone away. With "Alarm on Stop" selected it will track process ids.
0 kommentar(er)
