our firm sometimes an extra maintenance is planned for one of the applications
we are monitoring. Normally we are informed per email, but sometimes we are
forgotten. Therefore we would like to have a way to give our colleagues
themselves the possibility to stop / blackout the task that is running against
their application. The idea we have is to define a different blackout in every
task and give our colleagues a command line or PowerShell possibility to define
the blackout. Is this possible?
Solved! Go to Solution.
I think there are two parts to your request: command-line
interface and the ability to do frequent changes to your black-out schedule.
The product currently does not have a command-line interface
for modifying the black-out schedule. Nevertheless, you can modify the
black-out schedule by executing the Framework configuration utility, running
the CVFW_Maintenance script.
You might need to have one or several robots that would be
available for running the CVFW_Maintenance script. To facilitate the
application blackouts, you may even consider installing an Agent on computer(s)
that are used for different purposes and never schedule any scripts or
autochecks on these machines.
Hope this helps.
Hello @Yuriy Look, L
for your answer!
thought so, that there is no command line interface. I'll post an enhancement
request later on.
use of the CVFW_Maintenance script is a workaround. We didn't use the blackout
function before. In this solution we would give our server guys the possibility
to run this script and change the CVFW ini file (on the Agent Manager Server
because a Group of agents is involved). I'll make a test if it works in our
want to delegate the responsibility of the availability and Performance of an
application (in our firm called Service) to the Group that is responsible for
the application / Service itself. If they are planning a maintenance for their
service, they should have the possibility to put the script tasks in a
maintenance mode themselves. In our firm we are using Microsoft SCOM for the
system monitoring. In SCOM they put their systems in maintenance mode. In that
situation the relevant script tasks should be put in maintenance mode to. The
interface between SCOM and Dynatrace Enterprise Synthetic Monitoring would be a
PowerShell script or a command line call.
@Antoon Rodoe Hi Antoon,
What you’ve put in your previous comment does not tell why
GUI is not as good as command line. But,
if command-line is so important to you, you can mimic what the Framework does
in a separate script and take parameters of the needed action from a file. Since the maintenance utility code is
available to you, this should be doable. The file can be a plain text file, a
.csv, a .ini, an XML file – whatever you can parse.
To execute a script, you can use TP.exe from the Recorder installation
directory with the following parameters:
-u <UserId>, usually Admin;
-p <Recorder database password>, usually admin;
-s <script name>;
-r <project name>. This parameter is optional and defaults to shared, the project that has
all Framework assets.
Would this approach satisfy your needs?
I'm sorry I don't exactly understand what you want to
achieve with the Recorder script. My server guys don't have a Recorder
installed on their PCs. Of course I can copy the blackout part of the CVFW
Maintenance script and bring it in a new script. But what would that bring if
our server guys cannot use it? Perhaps I’m thinking in a wrong direction.
This is related to my original post in this thread, specifically to this phrase:
...you may even consider installing an Agent on computer(s) that are used
for different purposes and never schedule any scripts or autochecks on
Onece again, installing Agent software per se would not make the machine a robot, it can be installed on any machine should it be beneficial. Hope you now understand what I mean.
My thoughts as well...
Edited to add: Ah, but that would also require a mechanism to publish the configuration in the database to the Agents. Just writing the config to the database will not help, only after publishing that data to the Agents will they have the updated config.
So that would still require a mechanism to trigger publishing the configuration from the command line. So I think Antoons idea makes sense.