NetXMS Support Forum

Отличие статуса Resolved от Terminated в том, что аларм остается видимым в консоли, хотя и не оказывает влияния на статус хоста. В нокоторых организациях это используется для того, чтобы сменные операторы видели недавнюю историю. Например, при автоматическом решении проблемы можно в event processing policy использовать resolve alarm вместо terminate alarm - тогда оператор видит, что проблема была и уже решена, и может вручную сделать terminate. Т.е. теперь у аларма 4 состояния: Outstanding -> (Acknowledged) -> (Resolved) -> Terminated.

Hi all!

NetXMS version 1.2.5 is out! Changes since previous release:

- Topology-based event correlation improved
- Network discovery improved
- Mapping tables
- New NXSL functions: ceil, floor, round, format, map
- Management console:
   - "Alarm Details" view
   - "Area" option implemented on line charts
   - Multiple DCIs can be combined on one graph on "Performance" tab
   - New dashboard element: separator
   - DCIs can be created from MIB Explorer
   - Textual conventions for selected MIB object displayed in MIB explorer
   - Fixed bug with chart titles in dashboards
   - "Snap to grid" and "Align to grid" options in network maps
   - Improved Y-range adjustment in line charts
   - Improved tooltips in line charts
   - Custom logo can be set on login screen in web console
   - Fixed performance and stability issues with image library
- Android client:
   - Select all/unselect all in alarms list
   - Multipliers for graphs and last values: binary (power of two) and decimal (power of ten)
   - Show number of pending alarms in home screen
- API for creating embedded application agents
- Initial (alpha) version of mobile agent for Android devices
- Fixed issues: #23, #47, #49, #131, #154, #162, #163, #172, #175, #177, #178, #180, #186, #187, #188, #189, #192, #196

Best regards,
Victor

There are no much development documentation yet. Just ask me on forum and I'll provide an answer.

Best regards,
Victor

Мне как программисту нынешнее поведение скриптов трансформации казалось логичным Однако данное предложение думаю действительно уменьшит количество недопониманий и и ошибок. Сделал что если скрипт не возвращает значения или возвращает null, то значение DCI не изменится.

Hi!

You can get history of events via event log viewer (View -> Event Log).

Best regards,
Victor

Hi!

Thank you! You can send me output of nxsnmpwalk on OIDs mentioned before:

.1.3.6.1.2.1.1
.1.3.6.1.2.1.2
.1.3.6.1.2.1.17.1
.1.3.6.1.2.1.4.20.1
.1.3.6.1.4.1.9.9.401.1
.1.3.6.1.4.1.9.9.134.1
.1.3.6.1.4.1.9.9.276.1
.1.3.6.1.4.1.9.9.173.1
.1.3.6.1.4.1.9.9.128
.1.3.6.1.4.1.9.9.68

You can send them to [email protected].

Best regards,
Victor

For counting processes there are separate parameter Process.CountEx, which has two arguments - process name and command line, both are regular expressions.

Wiki is supposed to be most up-to-date information source, but unfortunately it still missing lot of information, including detailed description of agent parameters. We are updating wiki, but it's a slow process.

Best regards,
Victor

Hi!

You can specify command line filter in all Process.* parameters. Full syntax of Process.CPUTime (and others Process.*) is following:

Process.CPUTime(process, type, cmdline)

Where

process - process name. If cmdline is not given, only processes with matched name will be counted and read. If cmdline is given, process interpreted as regular expression.
type     - representation type (meaningful when more than one process with the same name exists). Valid values are:
         min - minimal value among all processes named <process>
         max - maximal value among all processes named <process>
         avg - average value for all processes named <process>
         sum - sum of values for all processes named <process>
cmdline  - command line (regular expression to match).

So to match all processes named qemu-kvm with word test in command line, you can use

Process.CPUTime(^qemu-kvm$, sum, test)

Don't forget that both process name and command line are regular expressions when extended format is used, so if you use "qemu-kvm" as process name (without ^ and $), processes contained this in the name (like qemu-kvm2) will also be matched.

Best regards,
Victor

Hi!

What you mean by "disappeared"? It stops collecting data, or configured schedule really disappears from DCI configuration?

Best regards,
Victor

Hi!

You can just type &lt; and &gt; in XML file in old console (don't forget semicolon!). And if you need & character, you should use &amp;

Best regards,
Victor

Hi!

You can set number of polls required to change status of node's interface(s) (in interface object's properties on "Polling" page). Server will consider interface down only if it is not responding for n polls, and therefore entire node will be considered down only after n polls.

Best regards,
Victor

Hi!

Yes, I've found a bug in event source installation code. It appears in 1.2.3, when agent was converted to UNICODE. I've fixed it in 1.2.5.

Best regards,
Victor

Hi!

Server do ICMP ping automatically during status polls for all registered nodes. If node didn't respond, SYS_NODE_DOWN event will be generated. You only need to setup PING subagent if you want to measure response time or want to ping some nodes from remote location. You can disable using ICMP for status polling by checking "Disable ICMP" on "Polling" page in node properties.

Best regards,
Victor

Hi!

I decide to drop deleted_objects table completely and just store last used ID.

If you have database writer queue always around 30-50, you can try to increase number of database writers - as updates usually goes to different tables, they often can run effectively in parallel. Default number of writers is 1.

Best regards,
Victor

For example, you have syslog records like this coming in:

Error: some error text

and you want to have everything after "Error:" to be message text of your event. First, you should create new event with name, for example, SYSLOG_ERROR and with message simply set to %1 (value of first parameter). Then, the following syslog parser will create correct events:


<parser>
    <rules>
        <rule>
            <match>Error: (.*)</match>
            <event params="1">SYSLOG_ERROR</event>
        </rule>
    </rules>
</parser>


what will be catch by first matching group in regexp will come into first parameter of the event, second matching group to second parameter, and so on.

Best regards,
Victor