Examples
Application Support Team
Support staff spend a large proportion of their day looking at log files during fault investigations and often have to deal with a wide range of potential problems. Locating, viewing and analyzing the log files in their raw form is a time-consuming and error-prone task which frequently needs to be escalated to other staff. Below is an example of how Logfalcon can help support staff dramatically reduce fault investigation times, while also minimising the need for escalations:
John is a member of the support team supporting an order-management system. The team recently started using Logfalcon and very quickly setup a number of objects and screens in Logfalcon to cover most of their most common support calls. In addition, they use Logfalcon to easily search and navigate through various files during complex investigations.
• Search screen: John frequently receives supports calls related to problems with orders and is usually given an “Order Id”, which he uses to perform one or more pre-set searches in Logfalcon. These searches are object-based and can reveal the reasons for problems immediately, which could be due to a combination of events. Even if an Order Id is not provided John can quickly locate the order through Logfalcon using attributes such as the approximate time of order or order size or even through a simple text search.
• Charting: CPU / Memory / Hard Disk space of the application servers are charted in a time plot so that any potentially troublesome trends are detected and prevented from occurring. The moving average of the latency of the system is also monitored.
• Alerting: Occasionally the system can reject an incoming order. As the system receives thousands of orders a day, it is impossible to investigate all of these and many are resubmitted by the users anyway. However, the management is concerned with the potential loss of business of large orders. John is using Logfalcon to receive alerts whenever an order with a value exceeding 1000 has been rejected.
• Dashboard: Many of the above screens are combined in a real-time dashboard that John keeps open on his second displays throughout the day.
Network and Security Administrator
Paul is a network administrator in a medium-sized enterprise with additional security responsibilities. A very large amount of logging information from various network devices are collected and stored on a log file server. Paul uses Logfalcon to detect various conditions, as well as to get an overview from the vast quantities of information.
• Reporting Screen: Paul uses Logfalcon to produce a real-time report of the IP addresses with the most unsuccessful log-in attempts during the day. The report is sorted in descending order so that he can always see the most “troublesome” IPs at any point in time.
• Alerting Screen: Paul wants to be notified whenever a network link goes down. Additionally, he wants to see the total number of packets received from each IP address but only if the total is over a certain level. Paul achieves this by using the Alerting screen of Logfalcon.
• Search screen: Every morning Paul runs through a checklist to ensure that certain events have happened or did not happen the previous night. Using pre-set searches in Logfalcon Paul can go through this checklist with a few clicks of the mouse.
• Dashboard Screen: Paul has combined real-time reporting with alerting screens to create a dashboard that he keeps permanently open on his desktop.
Technical Team Leader
James is the team leader of a group of application developers on a recently developed in-house server application. James' current focus is to ensure the continuous operation of the server and the early identifications of any potential problems. James has identified some key areas he is concerned about and is monitoring them through Logfalcon.
• Time Plot Screen: James is using the time plot to identify the usage patterns and usage trends of the application. For example, what time people log-in to the server, and how many users are logged in at any point in time.
• Object Screen: James likes to compare the actions of various users, and uses the Object View to compare various aspects such as order sizes in a tabular format.
• Bar Screen: James is interested in the take-up of the new system, and wants to see various business metrics such as users per business area.
• Report Screen: It has been noted that due to bugs in the in-house application, the server occasionally fails to perform the requested user actions. James wants to see at any point throughout the day a report with the types of errors and the number of errors. Any unexpected errors are reported to the developers to repair. James also uses this report to ensure that these errors are being reduced and eliminated over time.
Business Manager
Richard is a business manager in an automated order management system. He already has access to a business intelligence system showing various business metrics. However, the business system is not a real-time system, something which Richard requires. Additionally, he occasionally requires additional types of business intelligence information which would need considerable development effort to be provided. Instead, he uses Logfalcon where a Dashboard Screen has been setup precisely for his needs. When his requirements change the Dashboard Screen is changed accordingly:
• Pie Chart: A break-down of which products are selling the most during the day is succinctly shown in a Pie Chart. A separate pie chart shows which products are selling the most by value.
• Multi Plotter Chart: Richard is interested in seeing whenthe most business activity is performed. In fact, he is interested in knowing when different types of orders for products are placed. A graph showing units sold for each product type is plotted on the same chart. Richard notices that some types of products are bought mainly during the “lunch period” around noon, which he considers to be of importance.
• Report: Richard is interested in finding out how many orders make it to completion and uses Logfalcon to see at any point during the day how many orders are in a given status, e.g. how many orders are Suspended, Unassigned, etc. and additional information such as the total value of the orders in each status.
• Bar Chart: In addition to the Report Screen, Richard uses a Bar Chart to easily see the relative number of orders in the various states. Ideally, he wants to see the bar for “Orders complete” as much higher than all the other order states as this would indicate the minimum potential revenue loss.
• Dashboard: The above screens are combined into a single Dashboard which Richard consults as and when necessary.
Application Developer
Peter is an application developer. Logging is critical during development and he views log files throughout the day, as the application server starts and stops, performs new operation etc. Logfalcon saves him a great amount of time by being in a single place so that he can view all the log events that he is interested in and at the same time filtering out the large amount of log events that he is not interested in. Additionally, he can perform higher-level analysis such as performance analysis and chart aspects of the system he is developing to get instant high-level insight.
Quality Assurance Analyst
Steve is a quality assurance analyst and is responsible for checking the correct behaviour of an order management server under development. Part of the testing of the server is checking whether the server correctly forwards orders to downstream systems. However, this can only be checked by looking at complex log files and there is no user interface for testing this. In the past, application developers had to be involved in this type of testing. Now, with the use of Logfalcon, object definitions for the relevant server actions have been defined, which enables Steve to test these scenarios himself.
