Best Practices for ...
 
Notifications
Clear all

Best Practices for Remote Monitoring of Server Services on Client Machines

17 Posts
2 Users
0 Reactions
1,137 Views
(@korbikorb)
Active Member Registered
Joined: 8 months ago
Posts: 11
Topic starter  

Hello everyone,

I’d like to discuss a scenario and get your insights on the best approach to achieve it.

Scenario:

We have a single server running multiple databases and Windows services.
There are several clients that use this server to store or fetch data.
On the server, I am using DesktopInfo to monitor service and database availability, and it works perfectly. Here is a sample of the output:

Database and Service Availability:

  • Database_A: Running
  • My_Service_A: Running
  • My_Service_B: Stopped

Now, I want to display this entire "Database and Service Availability" section on all client machines without using the same desktopinfo.ini file with the same routines. The reason for this is that some of the monitoring routines include very specific command line instructions with usernames and passwords.

Key Benefits:

Clients can use a simple desktopinfo.ini file that never needs updating because the relevant information is fetched from the server’s DesktopInfo instance.
This setup ensures that clients do not have access to sensitive information, such as the usernames and passwords used in the service monitoring routines.

 

I’m looking for advice on how to achieve this securely and efficiently. Any suggestions or experiences with similar setups would be greatly appreciated.

Thanks in advance for your help!


   
Quote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

Have you perused the Remote Monitoring section in the manual?


   
ReplyQuote
(@korbikorb)
Active Member Registered
Joined: 8 months ago
Posts: 11
Topic starter  

Now that you mention it, I read through the manual again and realized I had been focusing mainly on the example configurations. However, if I understand correctly, I can only access remote IDs that are known to the client. I cannot silently add more monitorings on the server side that are automatically included on all clients. Or is it possible to build a package on the server side which contains all monitoring configurations but is then accessible via a single ID?


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

Not currently but I like the ideas.


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

I suppose a single id could identify a group rather than a single item then you're free to manage the group on the server side.


   
ReplyQuote
(@korbikorb)
Active Member Registered
Joined: 8 months ago
Posts: 11
Topic starter  

Do you see any technical blocking point to implement this feature ? 😀 😀 

 


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

Posted by: @korbikorb

Do you see any technical blocking point to implement this feature ? 😀 😀 

 

Not off the top of my head but I'd have to look at the code to be sure.

 


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

how do you imagine configuring it on the server side? I can think of two ways:

1. An item has an option called 'group' which is an id of the group it's in. This could list several group ids so an item can be a member of more than one group.

2. Create a new item called GROUP which has an id and a list of member items. This makes it easier to see what groups you have and what the members are.

I suppose in theory I could do both...


   
ReplyQuote
(@korbikorb)
Active Member Registered
Joined: 8 months ago
Posts: 11
Topic starter  

Posted by: @glenn

how do you imagine configuring it on the server side? I can think of two ways:

1. An item has an option called 'group' which is an id of the group it's in. This could list several group ids so an item can be a member of more than one group.

2. Create a new item called GROUP which has an id and a list of member items. This makes it easier to see what groups you have and what the members are.

I suppose in theory I could do both...

 

I would prefer option 2 to have a new item called GROUP. I think it would be easier, when multiple groups are created, to not lose track of which item is added to which group. Additionally, existing configurations do not have to be adapted; only GROUP(s) need to be created, and existing items need to be added with their IDs.

 

Following usecases are currently in my mind: 

Server Side:

[items] section will remain untouched 

id:a

id:b

id:c

id:d

 

[GROUP] new section

id:x, items:a,b

id:y, items:b,c

id:z, items:d, group:x

 

Client Side

DTI=id:x (Group x contains items a , b)

DTI=id:y (Group y contains items b , c)

DTI=id:z (Group z contains items a , b , d)

 

 

 


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

i probably wouldn't create a new section, rather just a new item:

GROUP=id:x, items:a b

GROUP=id:y, items:b c

GROUP=id:z, items:d x

i just noticed you snuck in the embedded group, nice.


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

this works insofar as a group can return multiple rows of data and the client can display it. But the data is raw, unformatted data. The client still needs to format and display it.  So this doesn't solve the problem of setting the client display from the server.

It would seem we need to fully format the display on the server side before the clients get it.

<desktop_info version="3.13.2">
<raw_values>
<row>
<data name="cpu" type="5">25.9433962264151</data>
<data name="kernel" type="5">12.7358490566038</data>
<data name="queue" type="5">0</data>
<data name="processes" type="5">176</data>
<data name="threads" type="5">1591</data>
<data name="systemcallspersec" type="5">51088</data>
<data name="contextswitchespersec" type="5">13769</data>
<data name="exceptiondispatchespersec" type="5">55</data>
</row>
<row>
<data name="Active" type="11">True</data>
<data name="ActiveTripPoint" type="258"><null></data>
<data name="ActiveTripPointCount" type="6">5</data>
<data name="CriticalTripPoint" type="6">3782</data>
<data name="CurrentTemperature" type="6">3010</data>
<data name="InstanceName" type="8">ACPI\ThermalZone\TZ00_0</data>
<data name="PassiveTripPoint" type="6">0</data>
<data name="Reserved" type="6">0</data>
<data name="SamplingPeriod" type="6">0</data>
<data name="ThermalConstant1" type="6">0</data>
<data name="ThermalConstant2" type="6">0</data>
<data name="ThermalStamp" type="6">7</data>
</row>
<row>
<data name="usedbytes" type="21">7173754880</data>
<data name="total" type="21">17080180736</data>
<data name="usedpct" type="21">42</data>
<data name="freebytes" type="21">9906425856</data>
<data name="freepct" type="21">57</data>
</row>
</raw_values>
</desktop_info>

   
ReplyQuote
(@korbikorb)
Active Member Registered
Joined: 8 months ago
Posts: 11
Topic starter  

Posted by: @glenn

this works insofar as a group can return multiple rows of data and the client can display it. But the data is raw, unformatted data. The client still needs to format and display it.  So this doesn't solve the problem of setting the client display from the server.

It would seem we need to fully format the display on the server side before the clients get it.

 

Yes, this makes all items accessible from the client side with a known group ID, which solves 50% of the problem. We can call this a small win 🙂

I don't think that the elements added to a group need to automatically inherit the "display options" from the server configuration.

Would it make sense that the group creator can also set display options for the group, which would then be applicable to all group elements?

All elements are then shown as a list with the display options applied.

Something like this:

GROUP=id:x, items:a b, display_option:font-size:90%, align:3, style:iwb, color:#488695

The only gap I see is the missing "text" behind a and b.

Possible adpation:

GROUP=id:x, items:a b, text:[text_a, text_b], display_option:font-size:90%, align:3, style:iwb, color:#488695

 

Client side then needs a appropriate call to open the group which is capable to convert the group to a list view. 

Again, these are just ideas rushing through my mind.


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

This is my current plan:

a new item called GROUP will collate data from selected items. It will collect all raw and formatted item data at regular intervals. The formatted data may collect multiple display lines from each target item. You give it a unique id using the id option. The server side config would look something like this:

CPU=blah blah
NETWORK=blah blah
PHYSICALDISK=blah blah

GROUP=id:group-1,items: CPU NETWORK PHYSICALDISK

 

So on the server you set up your items to display the way you want and create your groups as required.

The client side will use the DTI item to collect data from the server. The data is transmitted using XML as noted in the earlier post. It will contain the "raw_values" node and a new "formatted_values" node.

DTI=host:10.0.0.247,id:group-1,interval:10

On the client side you now have a choice of how to display the data collected by the DTI item. If you use the "display" option then it will format and display the raw values in the usual manner.  If you leave out the "display" option altogether it will use the formatted data.

This allows you to set the client config once and then control the client display from the server.


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

Posted by: @korbikorb

Posted by: @glenn

this works insofar as a group can return multiple rows of data and the client can display it. But the data is raw, unformatted data. The client still needs to format and display it.  So this doesn't solve the problem of setting the client display from the server.

It would seem we need to fully format the display on the server side before the clients get it.

 

Yes, this makes all items accessible from the client side with a known group ID, which solves 50% of the problem. We can call this a small win 🙂

I don't think that the elements added to a group need to automatically inherit the "display options" from the server configuration.

Would it make sense that the group creator can also set display options for the group, which would then be applicable to all group elements?

All elements are then shown as a list with the display options applied.

Something like this:

GROUP=id:x, items:a b, display_option:font-size:90%, align:3, style:iwb, color:#488695

The only gap I see is the missing "text" behind a and b.

Possible adpation:

GROUP=id:x, items:a b, text:[text_a, text_b], display_option:font-size:90%, align:3, style:iwb, color:#488695

 

Client side then needs a appropriate call to open the group which is capable to convert the group to a list view. 

Again, these are just ideas rushing through my mind.

 

By "display" option, I'm referring to the actual "display" item option which controls number formats and such, not fonts and colours etc.

my plan would require you to set fonts and general layout on the client side but the actual information it displays is set on the server side.  I think it's probably feasible to set fonts etc on the server side but I'm inclined to leave that for phase 2.

 


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1409
 

so to be clear, the group item will inherit the "display" output of each item and pass that down to the client.


   
ReplyQuote
Page 1 / 2
Glenn's Page