Skip navigation
1 2 3 Previous Next

TrueSight Operations Mgmt

143 posts
Share This:

Hello TrueSight Operations Mgmt Family,


We are happy to announce a new 'Meet The Champions' blog post series, to spotlight those awesome members who dedicate their time to help other members of our community. You might have seen them replying to your questions (or others'), and sharing wisdom to make this a better place to be. We thank them, and we feel it is time the whole community get to know them better! Spotlighted champions will also be invited to be a part of an exclusive community, where they can interact with other champions on improving the overall BMC Communities experience.


In this edition, Roland Pocek from Austria talks about his experience with BMC Communities, personal life, and more!



Do you remember how you were introduced to BMC Communities? What was your journey like?

I started working as a consultant 14 years ago and by then joined BMC communities



Tell us a bit about your work and goals?

Working as a consultant for BMC products (discovery, patrol, tsom, tsim, appvis, …) for many years now, like to meet customers, learn new things every day, solving problems, …



What draws you to participate in BMC Communities?

Really good place for getting answers you maybe wont ask support, and pretty fun ppl there to share knowledge wtih, meet new ppl doing the same work/have the same problems and are willing to help each other



Did you make any new friends in BMC Communities? Do you have any stories to share?

Actually yes, met Matt Laurenceau (funniest skype talk I had in a long time) and was also able to meet BMC guys like Steve Mundy, John Gallagher, May Bakken and a few more in real life  



How did you end up picking a Sheldon Cooper (from Big Bang Theory) quote as your BMC Communities profile picture?

Really like the BAZINGA 


Do you have any message for the new members of BMC communities?

        Take the time and collaborate



How do you like to spend your spare time?

Playing drums/music and do lots of sports



If you could pick one thing that could be made better in BMC Communities, what would be it?

Get more BMC experts involved in answering questions in some communities and I would like to see more roadmap and upcoming products/features stuff


   View profile.png


Q. What  is your favorite movie(s)?

atm mostly watch tv series like banshee, gotham, santa clarita diet, …


Q. Who is the greatest player in your favorite sport?

Roger Federer


Q. What was the best vacation you have had?

Had the luck to see many different countries and cities, hard to say



Roland with May Bakken


Thank You Roland for all the wonderful work you are doing here!

Community members, please make sure that you visit Roland's profile, and click 'Follow' (in 'inbox' if you wish to be notified on all activities) to be in touch with him, and be updated.  If you have had an interaction with Roland that helped you, feel free to share with us in the comments below!

Share This:

Hello World,


Are you worried about the management of thousands of events generated by your infrastructure? Are you using many event adapters? Do you want to know about event collector functionality? What about applying effective policies for managing the events?

Do you want to reach the level where you can build complex service models on your own? And what about adding some Business Service Resolution functionality so that the incident management is fully automated?


Too many questions.. too many requirements... Solution - Very Simple !!!


Take our brand new trainings on TSOM 11.x Event Management and Service Modeling which will help you find solutions to all the above questions.


  • BMC TrueSight Operations Management 11.x: Advanced Event Management
  • BMC TrueSight Operations Management 11.x: Advanced Training - Service Modeling


More information can be found at: TrueSight Operations Management Training - BMC Software  and check for 11.x Learning Track. Course abstracts are attached for quick reference.


Feel free to get back to us on further queries, and we are happy to help, as always !!!



Nidhi Gupta Mani Singh Geoffrey Bergren Dirk Braune Rasika Sarnaik Steve Mundy Mohana Ghotankar Trupti Modi Rafael de Rojas Shweta Agarwal Kamraun Marashi Pankaj Pansare Sabrina Paprocki Jim Stephens

Share This:

Logs are crucial to help you understand what is happening inside your Kubernetes cluster.


Even though most applications have native logging mechanism out of the box, in the distributed and containerized environment (like Kubernetes), users will be better off with the centralized logging solution. That’s because they need to collect logs from multiple applications with different log formats and send them to some logging backend for subsequent storage, processing, and analysis. Kubernetes provides all the basic resources needed to implement such functionality.


In this tutorial, we explore Kubernetes logging architecture and demonstrate how to collect application and system logs using Truesight ITDA, which using Elasticsearch backend offers great full-text search, log aggregation, analysis, and visualization functionality. Let’s get started!


Overview of Kubernetes Logging Architecture and Logging Options

Docker containers in Kubernetes write logs to standard output (stdout) and standard (stderr) error streams. Docker redirects these streams to a logging driver configured in Kubernetes to write to a file in JSON format. Kubernetes then exposes log files to users via kubectl logs command. Users can also get logs from a previous instantiation of a container setting the --previous flag of this command to true. That way they can get container logs if the container crashed and was restarted.


However, if a pod is deleted from the node forever, all corresponding containers and their logs are also deleted. The same happens when the node dies. In this case, users are no longer able to access application logs. To avoid this situation, container logs should have a separate shipper, storage, and lifecycle that are independent of pods and nodes. Kubernetes does not provide a native storage solution for log data, but you can easily integrate your preferred logging shipper into the Kubernetes cluster using Kubernetes API and controllers.


Kubernetes architecture facilitates a number of ways to manage application logs. Common approaches to consider are:

  • using a logging sidecar container running inside an app’s pod.
  • using a node-level logging agent that runs on every node.
  • push logs directly from within an application to some backend.


Let’s briefly discuss the details of the first and the second approach.

To complete examples used below, you’ll need the following:

  • A running Kubernetes cluster.
  • A kubectl command line tool installed and configured to communicate with the cluster.


Pre-requisite: Creating ITDA collector Docker image

Let’s create ITDA collector Docker image which can be used to collect logs using both the approach.

Use following Dockerfile to create Docker image.


FROM centos


ENV TARGET Linux-2-6-x86-64-nptl




ADD truesight_itda.tar $BASEDIR


RUN useradd -p 8Iq9Omhord6cQ $PATUSER


RUN chmod -R 777 $INSTALLDIR


RUN echo "cat /etc/hostname" > /usr/bin/hostname

RUN chmod +x /usr/bin/hostname

RUN echo patAdm1n | passwd --stdin root


WORKDIR /opt/bmc_products

RUN sh



RUN mkdir $INSTALLDIR/Patrol3/admin

RUN mkdir $INSTALLDIR/Patrol3/images

RUN chown -R patrol:patrol $INSTALLDIR/Patrol3





RUN rm -rf /opt/bmc_products

CMD ["PatrolAgent"]


There are several things to pay attention to:

· It uses Truesight CMA repository package as installable. Package should have Patrol Agent, IT Data Analytics KM and JRE. Also make sure you apply correct integrationServices variable during package creation. Package should be saved as truesight_itda.tar.

· The collector needs root permission to read logs in /var/log. To avoid permission error, we will run collector with root user inside container. Create CMA repository package with PATROL default account as root. For this exercise root password is set to ‘patAdm1n’. If you change this then make sure to change it in Dockerfile as well.

In this blog, we will refer this image as “”

To know more details on creating Docker image, please check out my blog post. Once the Docker image is created, push it to Docker repository.


Approach I: Using Sidecar Containers



Let’s assume you have an application container producing some logs and outputting them to stdout, stderr , and/or a log file. In this case, you can create one or more sidecar containers inside the application pod. The sidecars will be watching for the log files and an app’s container stdout/stderr  and will stream log data to their own stdout  and stderr  streams. Optionally, a sidecar container can also pass the retrieved logs to a node-level logging agent for subsequent processing and storage. This approach has many benefits described in this great article from the official documentation. Let’s summarize them:

  • With sidecar containers, you can separate several log streams from your app container. This is handy when your app container produces logs with different log formats. Mixing different log formats would deteriorate manageability of your logging pipeline.
  • Sidecar containers can read logs from those parts of your application that lack support for writing to stdout or stderr.
  • Because sidecar containers use stdout and stderr , you can use built-in logging tools like kubectl logs .
  • Sidecar containers can be used to rotate log files which cannot be rotated by the application itself.

At the same time, however, sidecar containers for logging have certain limitations:

  • Writing logs to a file and then streaming them to stdout can significantly increase disk usage. If your application writes to a single file, it’s better to set /dev/stdout as the destination instead of implementing the streaming sidecar container approach.
  • If you want to ship logs from multiple applications, you must design a sidecar(s) for each of them.


Sidecar container with logging agent:


If the node-level logging agent is not flexible enough for your situation, you can create a sidecar container with a separate logging agent that you have configured specifically to run with your application.


Here is the pod configuration manifest that you can use to implement this approach. The pod mounts a volume where ITDA can pick the data.


     1 apiVersion: v1

     2 kind: Pod

     3 metadata:

     4    name: counter

     5 spec:

     6    containers:

     7    - name: count

     8      image: busybox

     9      args:

    10      - /bin/sh

    11      - -c

    12      - >

    13        i=0;

    14        while true;

    15        do

    16          echo "$i: This is BMC sidecar container first log file test message $(date)" >> /var/log/1.log;

    17          echo "$(date) INFO:This is BMC sidecar container second log file test message $i" >> /var/log/2.log;

    18          i=$((i+1));

    19          sleep 1;

    20        done

    21      volumeMounts:

    22      - name: varlog

    23        mountPath: /var/log

    24    - name: count-agent

    25      image:

    26      ports:

    27      - containerPort: 3181

    28        hostPort: 5010

    29      volumeMounts:

    30      - name: varlog

    31        mountPath: /var/log

    32    volumes:

    33    - name: varlog

    34 emptyDir: {}

There are some additional steps required to get data into ITDA server because of unknown log data format.

1. Once the pod is running, it should appear in the Managed Devices in Truesight presentation server.

2. Create Monitoring policy for IT Data Analytics solution to connect ITDA agent to ITDA collection station.

3. Once the policy is applied to pod agent. Next step is to create ITDA data collector, with file details and appropriate Data pattern format to index data correctly.

After few mins log data should appear in Truesight ITDA server.


Approach II: Using a Node-Level Logging Agent


In this approach, you deploy a node-level logging agent on each node of your cluster. This agent is usually a container with access to log files of all application containers running on that node. Production clusters normally have more than one nodes spun up. If this is your case, you’ll need to deploy a logging agent on each node.


The easiest way to do this in Kubernetes is to create a special type of deployment called DaemonSet. The DaemonSet controller will ensure that for every node running in your cluster you have a copy of the logging agent pod. The DaemonSet controller will also periodically check the count of nodes in the cluster and spin up/down a logging agent when the node count changes. DaemonSet structure is particularly suitable for logging solutions because you create only one logging agent per node and do not need to change the applications running on the node. The limitation of this approach, however, is that node-level logging only works for applications’ standard output and standard error streams.



Deploying ITDA Agent as Daemonset to collect system and application Logs


Using node-level logging agents is the encouraged approach in Kubernetes because it allows centralizing logs from multiple applications via installation of a single logging agent per each node. We now discuss how to implement this approach using ITDA agent deployed as a DaemonSet in your Kubernetes cluster.


We used same Docker image as that of sidecar approach to create Daemonset.


Step 1: Deploy a DaemonSet


Here is the Daemonset configuration manifest that you can use. Each Daemonset pod mounts a two volumes to host paths /var/log and /var/log/containers.


     1  apiVersion: apps/v1

     2  kind: DaemonSet

     3  metadata:

     4    name: truesight-itda

     5    namespace: default

     6    labels:

     7      k8s-app: truesight-itda

     8  spec:

     9    selector:

    10      matchLabels:

    11        name: truesight-itda

    12    template:

    13      metadata:

    14        labels:

    15          name: truesight-itda

    16      spec:

    17        tolerations:

    18        - key:

    19          effect: NoSchedule

    20        containers:

    21        - name: truesight-itda

    22          image:

    23          ports:

    24          - containerPort: 3181

    25            hostPort: 5003

    26          volumeMounts:

    27          - name: varlog

    28            mountPath: /var/log

    29          - name: varlibdockercontainers

    30            mountPath: /var/lib/docker/containers

    31            readOnly: true

    32        terminationGracePeriodSeconds: 30

    33        volumes:

    34        - name: varlog

    35          hostPath:

    36            path: /var/log

    37        - name: varlibdockercontainers

    38          hostPath:

    39            path: /var/lib/docker/containers


Let’s save the manifest in the ts-itda-ds.yaml  and create the DaemonSet:



kubectl create -f ts-itda-ds.yaml


Step 2: Configure log data collection


Once Deamonset is created successfully, it needs to be configured to collect data and index correctly to make log search and analysis easy and meaningful. In large cluster this could be cumbersome if one has to configure each node, that’s where Truesight policy configuration and Kubernetes ITDA content pack could make things easier and faster to setup.


To import “Kubernetes” content pack, login to ITDA server and use menu Administration -> Content Packs -> Import menu.


Once imported successfully, it adds Collection Profile template which includes two data collector configurations.

  1. varlogcontainer – To collect pod logs from each node residing in /var/log/containers
  2. varlogmessages – To collect system logs (kubelet and Docker log) from /var/log/messages file


Next step is to create Truesight CMA policy to configure Daemonset agents to connect to ITDA collection station and server with Elasticsearch backend and to use data collector templates created by content pack. The policy configuration remains same as we did for sidecar container with following two additions.

  1. Make sure Agent selection criteria is set as “Agent Host Name” starts with Daemonset name i.e. truesigh-itda. This could be useful in auto scaled cluster where nodes gets added/removed frequently.

   2. In IT Data Analytics monitor configuration, add Collection profile “kubernetes” to use data collector templates to automatically create data collectors in ITDA server.



With in few minutes ITDA agents will connect to server and automatically create required data collectors. For each node 2 data collectors will be created. For three node cluster it created 6 data collectors.

Data collectors: 

To see logs collected, click on search icon against respective data collector.






All things considered, Kubernetes platform facilitates implementation of full logging pipelines by providing such useful abstraction as DaemonSets. We saw how to easily implement cluster-level logging using node agents deployed as DaemonSets .

In this tutorial, we demonstrated how Truesight ITDA can easily centralize logs from multiple applications. Unlike sidecar containers that should be created for each application running in your cluster, node-level logging requires only one logging agent per node.

Share This:

PATROL Agent and KMs in Docker Containers



This blog explains a way to create Docker image of Truesight repository package. Using this, one can build Docker image of Truesight repository package to run inside Docker container. Docker container is not replacement of full OS and hence local OS monitoring (OS KM's) is not something its intended for. Remote monitoring KM's (like VMware, OS remote motoring etc. ) are the ideal and best suited for containerization. We have used VMware KM for this exercise.


Docker Overview

Docker is a platform that enables users to build, package, ship and run distributed applications. Docker users package up their applications, and any dependent libraries or files, into a Docker image. Docker images are portable artifacts that can be distributed across Linux environments. Images that have been distributed can be used to instantiate containers where applications can run in isolation from other applications running in other containers on the same host operating system.



  1. The PATROL components for which you want to create image should be in the form of Truesight CMA repository package only (tar file)
  2. Truesight repository should be v10.0 and above
  3. Make sure all the components are 64 bit only as Docker only support 64 architecture.
  4. Make note of all inputs used while creating repository package as same details should be used in Dockerfile as well (Ex. PATROL default account, Install dir. etc.).


PATROL package details used for this exercise:

  1. Components part of PATROL package are PATROL Agent for Linux v10.0, Oracle for Linux (JRE) and VMware KM v4.0.0
  2. Provide docker host root password for the root user details.
  3. Provide integration service to connect to during package creation.
  4. PATROL package should be saved as tar file.





# -------------------------------------------------------------

# The resulting image will have PATROL components installed which are part of PATROL package used



# -------------------------------------------------------------

# (1) patrol_cma_package.tar

# Please create the tar package of PATROL component from v10.0 and above CMA



# -------------------------------------------------------------

# Create new directory on Docker host and put tar package along with this Dockerfile in it.

# Run:

#      $ docker build -t "patrol:1" .


# Pull base image

# -------------------------------------------------------------

FROM centos


# Maintainer

# ----------



# [REVIEW]Environment variables required for this build (Change the values of PATUSER and INSTALLDIR if required)

# -------------------------------------------------------------

ENV TARGET Linux-2-6-x86-64-nptl





# Add the installer file to container file system

# -------------------------------------------------------------

ADD patrol_cma_package.tar $BASEDIR


#[REVIEW] Setup filesystem and patrol user

# Encrypted value next to -p argument is the password for patrol user.

# To get encrypted value of your password for patrol user use following command.

# openssl passwd -crypt <password>

# ------------------------------------------------------------

RUN useradd -p Q70GsdNXWnwzs $PATUSER


RUN chmod -R 777 $INSTALLDIR


# SETUP hostname command as this is being used by PATROL silent installer and not available as part of image

# --------------------------------------------------------------

RUN echo "cat /etc/hostname" > /usr/bin/hostname

RUN chmod +x /usr/bin/hostname


# Install PATROL package

# --------------------------------------------------------------

WORKDIR /opt/bmc_products

RUN sh


# Setup required PATROL environment

# --------------------------------------------------------------






# Remove PATROL installer

# --------------------------------------------------------------

RUN rm -rf /opt/bmc_products


# Define default command to start PATROL Agent

# This will start PATROL agent on default port 3181. To change the port replace command with following.

# CMD ["PatrolAgent", "-p", "6755"]

# -------------------------------------------------


CMD ["PatrolAgent"]

#***************END of Dockerfile****************


Building Docker Image:

  1. Create new directory on docker host
  2. Copy PATROL tar package in the new directory
  3. Copy Dockerfile in the same directory
  4. Review the Dockerfile sections marked with [REVIEW] and do the appropriate changes.
  5. Create new docker image using following command

          $ docker build -t "patrol:1" .

Note: In the command above “patrol” is the image name “1” is the tag. Do not remove “.” (dot) at the end of command.


Verify Docker image created:


Create container using Docker image:

To create container from docker image use following command:

$ docker run –d –p 5000:3181 –h patrolagent-1 “patrol:1”

Details of command above:

  1. -p 5000:3181 will bind the container port 3181 to 5000 of the docker host. To access PATROL agent externally user has to use 5000.
  2. –hostname is not mandatory however it will help to set valid hostname for the container which would be consumed by PATROL Agent for setting up device name in Truesight. By default container ID will be set as hostname

Note: To override ENV variables at run time please us –e argument of docker run command.


Things to know:

  1. PATROL Agent configuration running inside docker container can be changed using remote pconfig utility.
  2. Restart of PATROL agent using pconfig of console will not work. It stops the PATROL Agent however to start it container has to be started again.
  3. If not done while package creation, integration with Truesight will work by setting /AgentSetup/integration/integrationServices variable.
Share This:


Why would you change the beacon post from HTTP to HTTPS?


However, before explaining why we want to change the beacon post, let discuss what is a beacon post within the App Visibility End User Monitoring.


In App Visibility End User Experience Monitoring a JavaScript is injected into the actual pages loaded by users. That JavaScript then sends beacons to TrueSight App Visibility Manager which contains metrics collected from the end user’s browser about the page it just finished rendering.


App Visibility End User Experience Monitoring either needs an Agent to automatically inject the JavaScript (which can only work in servers supported by the AD Agent) or you need to manually add the JavaScript to your pages (which will work for any server).




Going forward we will also be introducing 2 more modes in Automatic Injection which will not require the agent.

As an application specialist you would be able to Automatically set up Active End User Monitoring for the following:

1)F5 Server

2)Apache Web Server




The AD Agent just monitors the request as normal. However, when it sees the response which contains the actual page which is being sent to the browser, it edits that page automatically before passing it on back to the client. In this edit, it inserts a <script> tag into the Head section of the HTML telling the browser where to find the JavaScript and leaves the rest of the page unchanged. Thus, when the page returns to the client browser, that browser begins to execute the JavaScript inside the browser itself. When significant actions happen in the browser, that script sends out notifications called Beacons to the TrueSight App Visibility Proxy component. Note that the hostname and port of the Proxy component were hard coded into the script when the AD Agent edited the page. Thus, all Beacons from that page will go to the same Proxy until the page is reloaded or a new page is loaded. A new Proxy component may be dynamically assigned by the AD Agent in that new edit of the page. The proxy component then sends its information up to the TrueSight App Visibility Portal where it becomes available just as any other TrueSight Application Visibility data.


The App Visibility End User Experience Monitoring data that comes in through the Proxy component to the TrueSight App Visible Portal is visible within the Application View is TrueSight Presentation Server.


Where the AD Agent Business Transaction data populates the Web, Business, and Database tiers, the App Visibility End User Experience Monitoring data populates the User and Network tiers.


Below is a link to the documentation that will explain App Visibility End User Monitoring further:



OK so why would you change the beacon post from HTTP to HTTPS?


By default, the behaviour of the Beacons is that it matches the protocol used by the page. For example, if the application web page is HTTPS then the App Visibility End User Monitoring will inject the JavaScript into the web page, and the beacon post will be HTTPS.


If the application web page is HTTP then a setting in the App Visibility End User Monitoring will need to be changed in order to inject the JavaScript into the http web page, and the beacon post will be HTTP.  However, there may be certain situation where the user would like to receive the Beacon in https while the application web page is in HTTP.

So, if the user wants the beacon post to be more secure then the protocol would need to be changed to HTTPS.



Below are the steps to change the beacon post from HTTP to HTTPS:


In the JavaScript code, there are variables to App Visibility Proxy http and https ports. You need to look for the code that builds the beacon URL based on the page protocol, search for the URL that is built for HTTP protocol and update the beacons URL to use HTTPS port and protocol. 

In all App Visibility Proxies install directory, update <apm-proxy-install-dir>/webapps/static-resources/aeuem-10.1.0.min.js file. Change 'http' to 'https' in all places that are marked in the screenshot.


Changing Beacon Post.png




How to verify that the beacon post is now HTTPS?


The best way to verify that beacons are being sent with HTTPS is to use the Developer tool which is available in any browser.

After opening the Developer tool, you should check the Network Tab -- >JavaScript(JS)-->Protocol


Here you can see “beacons” item and verify that it is sent with HTTPS


Does this step apply to Manual and Automatic JavaScript Injection Or just manual JavaScript Injection?


These steps will apply both for Manual as well as Automatic Injection (Any Kind)

Share This:

Excited to announce the availability of the following role based trainings and certified associate exams on TrueSight Operations Management 11.x.


New ILT Courses:

  • BMC TrueSight Operations Management 11.x: Fundamentals Installing
  • BMC TrueSight Operations Management 11.x: Fundamentals Administering

New Certified Associate Exams:

  • BMC Certified Associate: TrueSight Operations Management 11.x for Administrators Online Exam
  • BMC Certified Associate: TrueSight Operations Management 11.x for Consultants Online Exam


To know more and to register, go to the TrueSight Operations Management Learning Path:


Nidhi Gupta Dirk Braune Rafael de Rojas Vrushali Athalye  Geoffrey Bergren Pankaj Pansare Jim Stephens Shweta Agarwal Kamraun Marashi

Sabrina Paprocki Jimish Thakkar Mani Singh

Share This:

BMC TrueSight Operations Management users can now get more out of their network data.  Entuity Network Analytics seamlessly integrates with TrueSight, to provide your IT team with the complete tools they need for success.



Reduce Your Alert Noise:   Let Entuity Network Analytics for TrueSight weed out the non-essential network event alerts that get escalated into TrueSight for more productive management


When it comes to service management, the more details you can see  about the network the better.  However, some of these details are not entirely useful.  While network alerts can act as a flag for when something is wrong, they can also act as a false flag, alerting the professional to an event that is not or will not lead to a major service incident. You and your team probably  get countless alerts throughout the day.  If there is a major incident, these alerts should help prevent or lessen a network outage, not create more work accessing whether they are a critical alerts.  If they are not major alerts, they serve as a noisy distraction from the day to day tasks and projects that you are occupied with.  Often too much  time is spent categorizing these alerts into events.   When too much time is spent on tasks like these insignificant events, other projects do not receive the attention they require. When integrated with TrueSight, Entuity Network Analytics (ENA) eliminates the non-essential network alerts by pre-processing network incidents.  With the non-threatening events weeded out before the IT professional sees them, the overall event information that TrueSight receives is more effective.  This means ENA adds more value to your TrueSight Operations and you can expect that when the network noise is reduced that event alerts being escalated are legitimate alerts. More efficient event processing permits IT staff to tackle more pressing issues rather than wasting time manually validating event alerts.


Network services can be managed individually to ensure performance stability with powerful sets of analytics (order processing, VoIP, E-Commerce, remote branch IT performance)


ENA lets you take your management to the next level with the ability to manage by Network Services. Now IT teams can track particular applications’ traffic patterns out and back to the user and associate all of the devices that are encompassed for an application.  For example, an order processing application can be managed by not only the application with TrueSight but through ENA you can see how the order processing data gets sent back and forth to the user.  Is the performance slow because of the application or is it because of how the data is being transported?  ENA can manage by network service to answer the question how the service is being handled on the network. Coupled with TrueSight, ENA gives you another way to manage your applications for outstanding performance.  Visit for more information.

Share This:

Consider the following typical business scenario:


business scenario.png

Effective operation management is essential for maintaining a healthy and thriving business. IT operations must keep applications, infrastructure, middleware, and services up and running to support key business processes.

BMC TrueSight Operations Management is unique performance and availability management solution that goes beyond monitoring to handle complex IT environments and diverse data streams to deliver actionable IT intelligence. This can help to resolve issues before they impact the business.

Additionally, BMC TrueSight Operations Management provides application-aware infrastructure monitoring IT Operations, bringing together infrastructure and application monitoring in one integrated solution.

Operators play a crucial role in day-to-day product management. They need to monitor events, devices, event groups, work with dashboards, to address the performance monitoring and incident management for an IT Infrastructure.

BMC TrueSight Operations Management 11.x: Fundamentals Operating training is specially designed for TSOM 11.x operators which covers all the exciting features of the product which are crucial for the operators. It's a 1-day training which contains many relevant labs which are useful for operators. For more information and details about registration, feel free to visit: Education COURSE page - BMC TrueSight Operations Management 11.x: Fundamentals Operating - BMC Software



Nidhi Gupta Dirk Braune Jimish Thakkar Rasika Sarnaik Geoffrey Bergren Kristen Linehan Sabrina Paprocki Steve Mundy Namita Maslekar

Share This:

As your system grows, you may want to start putting multiple Synthetic TEA agents on a single Windows system.  It is BMC best practice when you do this to only have 1 TEA Agent from a single location on each machine.  For instance, let's say you have 3 locations and 3 TEA Agents assigned to each location:

Blue Location:

Blue Agents.png

Black Location:

Black Agents.png

Green Location:

Green Agents.png


You will then set up 3 Windows systems and install 3 TEA Agents on each system.  Each TEA Agent will point to one of the above locations.  For instance:

Windows Systems.png


If Windows System 3, Blue Location Agent 3 goes down:

Agent Crashes.png


then the system will load balance the Execution Plans from that System and Agent to the other agents on System 1 and System 2,  but there will only a single agent on System 1 and System 2 that will be affected, so it will not have such a large impact on the system resources.


If you have a scenario where your agents are not well balanced, then you may run into a situation where you have too many agents from the same location on the same system.  In this scenario, if one of those agents goes down or if the system goes down, then the system will load balance the Execution Plans to the other available agents.   This may lead to all the Execution Plans going to the same system or becoming "unbalanced" which could overwhelm the resources on that machine and either bring down that agent, or cause that agent to become very slow and take several hours to recover.

Too Many Agents crash.png

Share This:

Why should I have minimal access and very few applications running on my system that is hosting a TEA Agent?


Typically, you run a Truesight Synthetic TEA Agent as a process because your script will need access to the desktop or will require special privileges that running the TEA agent as a service will not provide.


It is BMC's recommendation that when you run your TEA Agent as a process, that you do not run any other applications on the system that may interfere with the TEA Agent or your script.  It is also important that you do not allow any users to log into the system.  This is because some scripts must have access to the desktop and mouse in order to work properly.  If a user is logging in and taking control of the mouse, then there is a very significant chance that the scripts will lose the mouse and not be able to click on items when needed thereby causing the scripts to fail and give false alarms.


Also, if there are other processes running on the system that are using resources that are needed by the scripts, then the scripts may start to fail continuously until the TEA Agent can be restarted.  On a production server, this can be very hard to do when you can only restart processes during maintenance windows.

Share This:

Coming up on October 18, 2018 is BMC’s annual user event, the BMC Exchange in New York City!



During this free event, there will be thought-provoking keynotes including global trends and best practices.  Also, you will hear from BMC experts and your peers in the Digital Service Operations (DSO) track.  Lastly, you get to mingle with everyone including BMC experts, our business partners, and your peers.  Pretty cool event to attend, right? 


In the DSO track, we are so excited to have 3 customers tell their stories. 

  • Cerner will speak about TrueSight Capacity Optimization and their story around automation and advanced analytics for capacity and planning future demand.   Check out Cerner’s BizOps 101 ebook
  • Park Place Technologies’ presentation will focus on how they leverage AI technology to transform organizations.
  • Freddie Mac will join us in the session about vulnerability management.  Learn how your organization can protect itself from security threats.  Hear how Freddie Mac is using BMC solutions. 


BMC product experts will also be present in the track and throughout the entire event.

  • Hear from the VP of Product Management on how to optimize multi-cloud performance, cost and security
  • Also, hear from experts on cloud adoption.  This session will review how TrueSight Cloud Operations provides you visibility and control needed to govern, secure, and manage costs for AWS, Azure, and Google Cloud services.


At the end of the day, there will be a networking reception with a raffle (or 2 or 3).  Stick around and talk to us and your peers.  See the products live in the solutions showcase. Chat with our partners.  Stay around and relax before heading home. 


Event Info:

Date: October 18th 2018

When: 8:30am – 7:00pm

  • Keynote begins at 9:30am
  • Track Sessions begin at 1:30pm
  • Networking Reception begins at 5:00pm

Where: 415 5th Ave, NY, NY 10016


For more information and to register, click here


Look forward to seeing you in NYC!  Oh, and comment below if you are planning to attend!  We are excited to meet you.

Share This:

Thank you for participating in the TrueSight IT Data Analytics Community. To expand opportunities for collaboration, and simplify participation for members, this community will be consolidated with the TrueSight Operations Management community in the near future.

Cloud App 1-RR.png

This enhancement will continue to allow you to share information with ITDA customers, but will also expand your opportunities for collaboration by adding members of the much larger, TrueSight Operations Management community.   You will still be able to share ideas and experiences about ITDA, and how the collection of IT operations data (logs, machine data, events) can help you investigate and solve problems faster, avoid outages, increase efficiency, and reduce manual effort.  In addition, you will be able to view ITDA within the larger context of TrueSight Operations Management and communicate with customers who have that expanded solution.


Your support of this improvement is appreciated and we look forward to your continued and expanded collaboration in the future.


What does it mean for you?

You will be able to participate as in the past, on any content, the scope of the community will be broader and as a consequence increase knowledge sharing.

Is there something you need to do?

Yes, if you have not done it already, click follow on the TrueSight Operations Management Community:

Screen Shot 2018-07-27 at 09.07.51.png

For more information about the simplification of TrueSight communities read this post.


Any question? Comment below

Share This:

Thank you for participating in the TrueSight App Visibility Manager Community. To expand opportunities for collaboration, and simplify participation for members, this community will be consolidated with the TrueSight Operations Management community in the near future.



This enhancement will continue to allow you to share information with TrueSight App Visibility Manager customers, but will also expand your opportunities for collaboration by adding members of the much larger, TrueSight Operations Management community.   You will still be able to share ideas and experiences about application visibility from an infrastructure and end-user standpoint, and how to improve application performance with capabilities such as machine learning and advanced analytics.


In addition, you will be able to view application management within the larger context of TrueSight Operations Management and communicate with customers who have that expanded solution. Your support of this improvement is appreciated and we look forward to your continued and expanded collaboration in the future.


What does it mean for you?

You will be able to participate as in the past, on any content, the scope of the community will be broader and as a consequence increase knowledge sharing.

Is there something you need to do?

Yes, if you have not done it already, click follow on the TrueSight Operations Management Community:

Screen Shot 2018-07-27 at 09.07.51.png

For more information about the simplification of TrueSight communities read this post.


Any question? Comment below

Share This:

We've listened to your feedback (survey and more), and looked at TrueSight communities traffic.

You've told us loud and clear that you want a simplified structure to interact with your peers, fostering greater collaboration.


Special thanks to Patrick Mischler

We're ready to make it happen.

Cloud App 1-RR.png

Simplified structure

We're delighted to announce an expansion to the  TrueSight Operations Management community, soon consolidating the following sub-communities:

Screen Shot 2018-08-02 at 10.01.42.png


BMC has done this in the past with other product families, and the outcome has been very positive.


You can expect to see this transition taking place in the next weeks, and being fully completed by August 31st.


What does it mean for you?

You will be able to participate as in the past, on any content, the scope of the community will be broader and increase knowledge sharing.

Is there something you need to do?

Yes, if you have not done it already, click follow on the TrueSight Operations Management Community:

Screen Shot 2018-07-27 at 09.07.51.png


Thanks again for your continued participation in BMC Communities


Any question? Comment below

Share This:

When EUEM components are deployed, they are communicating with each other in different ways. Let’s refer to the basic architecture of a simple deployment of EUEM.




Let’s review each component roles


  • The Cloud Probe is the capture engine. It is capturing TCP/IP packets and is building objects (HTTP( and HTTPS request and response pairs) and extracts whatever data it is configured to. When objects are captured, they are sent to the Real User Collector.


  • The Real User Collector buffers those objects (several Cloud Probes may send data to one collector) for the Analyzer to consume (one or several Analyzers may get data from one Collector).


  • The Real User Analyzer retrieves data from one or more Real User Collectors and performs most of the processing.



All the communications between EUEM components occur on a secure channel using HTTPS. The same goes for managing EUEM by accessing its web interface.


The Collector and the Analyzer have their own built-in SSL certificates. When deployed a self-signed SSL certificate is generated for each component. Given that the authentication between each EUEM components is done via user accounts, there is no two-way SSL authentication as in other TrueSight Operations Management products.


Replacing a SSL certificate on any EUEM component does not impact the entire deployment and without causing any disruption in the way the product works. This means that one can use a signed certificate on an Analyzer and still use the self-signed certificate on the Collector without breaking the flow between the components. This also means that one does not have to change anything on the TrueSight Presentation Server for the Analyzer & TSPS integration or on the App Visibility Portal server when the App Visibility integration is configured.


As long as the configured SSL certificate is a valid and signed one, there is no problem!


The steps below are for the Real User Analyzer but the same procedure applies to the Real User Collector. Since there is no web UI for Cloud Probe, there is no SSL certificate on Cloud Probe to change.


EUEM is a Java application running on a Tomcat server.  Replacing the SSL certificate is very simple. The steps are

  1. Get a signed SSL certificate from a Certificate Authority and the original SSL private Key.
  2. Bundle them in a Java keystore format.
  3. Configure EUEM to use this keystore instead of the default one created at installation time.


Important notice: It is your responsibility to provide the Java keystore file. BMC is not responsible and will not provide help in generating it.


Configuring the Analyzer to use your keystore file

  1. Copy your keystore file to the Real User Analyzer server.
  2. Make a copy of the following file as a backup.
    1. $EUEM_HOME/analyzer/apache-tomcat/conf/server.xml
  3. Edit the server.xml file
  4. Look for the following lines. The first line is a pointer to the full pathname of your keystore file. The second line specifies the password (*) to that keystore.
    1. keystoreFile="${truesight.home}/conf/platform/security/keystore/java/keystore"
    2. keystorePass="tsPwDSt0r3"
  5. Restart the Real User Analyzer at your convenience to have the changes take effect.


If you have the Real User Collector deployed on the same system you have to repeat the steps as its SSL certificate configuration is separate.



(*) About storing the keystore password in clear text in the server.xml file. This is a constraint from the Tomcat design itself. This is best and fully described in the official Apache Tomcat FAQ.

Filter Blog

By date:
By tag: