Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - blazarov

#16
Hello,

in the recently passed few weeks we noticed brand new issue:
one or few of the agent tunnels appear as unbound without anyone changing anything. Ofcourse data collection stops at that time until you manually bind the tunnel again to the appropriate node.

We use the agents as proxies, so lots of nodes are affected on each occurence.

Any ideas are welcome on how to approach the troubleshooting of this issue!

Thanks!
#17
Does that mean that even if in theory i write to code to translate to human readable text in instance discovery filter i will not be able to pass it back to the DCI parameter because the SNMP agent will not poll it if it is in text, and 255 characters are not enough to pass it as SNMP OID?
#18
I think i can write the code to translate to readable text in the instance discovery filtering script, but i found that some instances are just too long even for the DCI parameter. What is the maximimum length of {instance} and the DCI parameter?
#19
Hello,
i am trying to setup a nice template for monitoring F5 load balancers and their services with instance discovery.
I stumbled upon the way they are encode their object names in SNMP OIDs. I would like to use the decoded human readable string in NetXMS DCI instead of the long encoded code. Here is an example:

root@nxagent:~/.snmp/mibs# snmpwalk -v2c -c XXXXX 192.168.120.YYY iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500
iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500 = Gauge32: 10

root@nxagent:~/.snmp/mibs# snmpwalk -m F5-BIGIP-LOCAL-MIB -v2c -c XXXX 192.168.120.YYY iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500
F5-BIGIP-LOCAL-MIB::ltmPoolMemberStatServerCurConns."/Common/bok_finbridge_prod_pool"."/Common/bok_prod_10.102.149.41_finbridge".35500 = Gauge32: 10

root@nxagent:~/.snmp/mibs# snmptranslate -m F5-BIGIP-LOCAL-MIB iso.3.6.1.4.1.3375.2.2.5.4.3.1.11.31.47.67.111.109.109.111.110.47.98.111.107.95.102.105.110.98.114.105.100.103.101.95.112.114.111.100.95.112.111.111.108.40.47.67.111.109.109.111.110.47.98.111.107.95.112.114.111.100.95.49.48.46.49.48.50.46.49.52.57.46.52.49.95.102.105.110.98.114.105.100.103.101.35500
F5-BIGIP-LOCAL-MIB::ltmPoolMemberStatServerCurConns."/Common/bok_finbridge_prod_pool"."/Common/bok_prod_10.102.149.41_finbridge".35500

As seen above when i load the MIBs in the standard linux net-snmp tools it does it automatically, but i couldnt find a way to implement it in NetXMS DCI/Instance discovery, apart from writing the code for translation myself in the instance discovery filtering script.

Any ideas?
#20
Yes, that is it.
Is it by design?
I think it has been working for a while.
#21
Hello,
I've noticed since some time (probably since the last server upgrade) that "Force DCI Poll" does not work - neither from last values, nor from DCI configuration.
Anybody else having the same issue?
I am wondering if this is a general bug, or something specific to my environment.

Thanks!
#22
i have done some testing observing directly the DB and i think i got it.
Depending on server load i get anything between 1 and 5 minutes for the change in the template to get populated in the DB. I believe this is normal due to the DB writer queue which is usually at around 4k.

My initial test was quite quickly changing the template and immediately stopping the server. Most probably i didnt allow it enough time to get flushed from the DB queue and populated to the DB.

I think i am sorted now. Thanks again!
#23
Tested setting ImportConfigurationOnStartup to false. Fixed the problem with the default templates in the operating systems, but the problem with my custom template remains the same. It gets overwritten after server restart.
will try to see if it gets written to the database.
#24
Hi,
yes i noticed it initially on the standard templates - Operating System -> General UNIX and Linux
but before submitting the thread i tried it on one custom template that we created and it did the same thing.

I will try your suggestion and revert.
Thanks!
#25
Hello,
recently i noticed that changes that we make on the templates get somehow lost after netxmsd restart.
This is extremely annoying, mostly because of the wasted time in fine tuning stuff.  >:(

Anyone faced that?
Any ideas on how to approach troubleshooting it?
#26
Hello all,

I have an idea that will greatly help me in day to day activities, but i am not sure if it is possible to implement and how.

I am using DCI summary tables which are very very cool.

What i need is to somehow count the total entries in the DCI summary table, along with counting different matches and store them in a separate DCI so i can graph them.

For example i have now a perfectly working DCI summary table called Backup Status looking like this:


Node         Backup Status
srv1          OK; blablalba details
srv2          FAILED; blablabla details
srv3          WARNING; blablabla details
srv4          OK; blablalba details
srv5          OK; blablabla details
srv6          OK; blablabla details

Ideally i would like to configure 4 DCIs that execute the DCI summary table and store the counts of:
- count of total DCI summary table entries (6)
- count of DCI summary table entries matching BackupStatus like OK* (4)
- count of DCI summary table entries matching BackupStatus like WARNING* (1)
- count of DCI summary table entries matching BackupStatus like FAILED* (1)

That way i can have a nice history of the success rates of my backups over time.

So any ideas how to achieve that?
#27
General Support / Monitoring disk latency in Linux
October 17, 2017, 03:26:16 PM
Hi,

I need to monitor disk I/O for some of our Linux machines, precisely:
1. IOPs
2. disk throughput
3. avg latency

1 and 2 are easy since they are natively supported in nxagentd - System.IO.ReadRate, System.IO.WriteRate, System.IO.BytesReadRate, System.IO.BytesWriteRate

About latency - so far it seems my best chances are parsing iostat's output. I can imagine a way to make it work, but it would be very ugly and probably fragile. Mostly because i should execute iostat on a regular basis and write its output to a local file. Then use nxagent to parse the output.

Another idea would be to parse /proc/diskstats directly in netxms, but i dont think there's a latency counters there..?

Does anyone have an idea on how to realize it in a more clean and robust way?

Also i dont entierly understand if DiskTime has direct relation to the latency?
#29
Feature Requests / Re: drivers for fortigate
September 29, 2017, 02:54:14 PM
Quote from: Victor Kirhenshtein on April 03, 2017, 11:23:21 AM
Hi,

is it possible to provide us remote access to test device over SNMP? That will greatly simplify driver development.

Best regards,
Victor

I can. Just ping me on skype when someone will be working on it.
Fortinet is growing on market share very much so this would definately make sense.
#30
Hi,
Just to update with progress.

After a quick chat with Victor he realized that the indexing of dc_queue table of the SQLite is suboptimal. He had released a new development release of the source which had the optimized indexes here:
https://git.netxms.org/public/netxms.git/commit/51e38637be0790e18f0b38318ec3233bab76304c?js=1

We have just updated and so far results seem amazing. At least 5-10x performance increase. Data reconciliation that seemed impossible to catch up before now works like a charm. Also CPU utilization of the machine is very low compared to constant 100% on one of the cores before.

We will do some more tests and we'll continue to monitor and post some more feedback.

Thanks Victor!