Using Instana

Problem detection

In IBM Tivoli Monitoring, you use the Tivoli® Enterprise Portal to create monitoring specifications, called Situations, to detect the occurrence of specific conditions or events, and raise an alert. Each situation is assigned (or distributed) to one or more managed systems that are to be monitored for a specific condition or a set of conditions.

To achieve the same purpose in Instana, you can set up Smart Alerts and Events, which detect, understand, and investigate quality of service issues in your applications. You can define your own thresholds based on the requirements, and configure custom alerts to notify you about errors and deviations in processes. When you receive an alert, you can proceed to drill down into the issue and diagnose the root cause.

Notifications

In IBM Tivoli Monitoring, you send notifications with the Send an email window or by using EIF events. You also use EIF Slot Customization to customize the content of your events. You also set up customizations through the SOAP interface to create other notification mechanisms.

In Instana, you can use Alert Channels to set up communications paths to 3rd party tools such as Watson AIOps, slack, Teams, and ServiceNow. Alerts help you to quickly and efficiently react to built-in events and custom events. You can define the alerts to configure specific events to be sent to specific alert channels. In this way, different teams can be notified about relevant events.

Logging

In IBM Tivoli Monitoring, you use the Tivoli Log File Agent (LFA) or OS Agent to monitor Application log files. LFA uses an opt-in approach to monitoring logs. Only the entries that match the regex that is provided by you are captured by the LFA.

When you use Instana to monitor application traces, Instana collects application and service logs automatically, correlate them with metrics and traces, and enhances traces or calls with extra messages.

Instana provides two options to monitor traditional logs: using OpenTelemtery to collect ASCII logs, and integrating LFA (or OS Agent logging) with Instana. The OpenTelemetry-based logging method in Instana varies from that of IBM Tivoli Monitoring in terms of the log entry capture mechanism. LFA in Instana uses an opt-out approach in which all log entries are captured unless you provide a regex to not include the log entry.

IBM Tivoli Monitoring provides a configuration option that helps you to forward log file entries to Instana. These entries show up as Events (Issues) on the Instana UI.

For more information on logging, see the following topics:

• Logging
• OpenTelemetry
• Integrating with OpenTelemetry by using the OpenTelemetry Collector

Custom monitoring

In IBM Tivoli Monitoring, you use Agent Builder to set up custom monitoring. By gathering data from common sources such as WMI, Perfmon, JDBC, SNMP, and JMX, you can build sophisticated monitoring solutions with a robust user interface.

By using the Agent Builder, you can monitor the following types of data:

• Availability: Process and service availability and command return codes
• Windows Event Log: Specific information from the Windows Event Log
• External data sources: Data from external sources

In addition to the Agent Builder, you can implement a custom monitoring by running a script through the OS Agent and capturing the script’s output data. This method requires relatively less effort but does not provide a friendly user interface.

In Instana, you can set up and use custom monitoring by using the following methods:

• Prometheus:

  You can collect metrics data with Prometheus. Either the data can be scraped from a Prometheus server or the Instana agent can become the target of a Prometheus exporter. By using Prometheus exporters, you can find many pre-made open source solutions.

• StatsD:

  You can comprehensively monitor your applications and services that use the StatsD protocol. The Instana agent itself acts as a StatsD collector daemon and receives metrics in the same way as a real StatsD daemon. This feature eliminates the need to deploy a separate StatsD daemon. You can view metrics that are related to your applications and services on the Instana UI after you configure the StatsD sensor. For more information, see Monitoring statsD.

• OpenTelemetry:

  Instana supports all OpenTelemetry signals.

  • Support for OpenTelemetry Traces is GA. OpenTelemetry and Instana AutoTrace spans can be combined for continuous mixed tracing.

  • Support for OpenTelemetry Metrics is in public preview and is available to all customers.

  • Support for OpenTelemetry Logs is GA.

  You can install the OpenTelemetry contrib collector and configure it to monitor any ASCII logs and Kubernetes container logs.

Additionally, on Windows, you can configure the host agent to collect any perfmon counters that are available.

Reporting

In IBM Tivoli Monitoring, you create and generate reports by using Cognos or the Cognos-based Tivoli Common Reporting. Additionally, all IBM Tivoli Monitoring agents come with a default set of reports. After you configure historical collection, you can run reports against the Tivoli Data Warehouse.

Instana does not have a built-in reporting solution. However, you can use the following capabilities to achieve your reporting objectives:

• Support for Grafana Enterprise: You can build a dashboard in Grafana with the required information. Then, use Grafana’s scheduling capabilities to generate reports in formats such as PDF and automatically email those reports to users.

• Analytics: You can view up to 30 days of data in the Analytics pages on the Instana UI. You can also define the required metrics and export the data as a CSV file.

• REST APIs: You can use Instana’s REST APIs to extract events, metrics, and traces. This data can then be inserted into other tools such as relational databases for reporting purposes.

• Custom dashboards: You can create a custom dashboard that shows data from any one month from the last 13 months. The maximum time frame of data cannot be more than 31 days. You can then share the dashboard with others by using the URL of the dashboard. When others open the dashboard, the dashboard displays the exact time frame that you specified. For example, if you specified to show the data between 01 January and 31 January, the dashboard displays the data between 01 January and 31 January to anyone who opens the URL.