Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Flatly)
  • No Skin
Collapse
Brand Logo

NetXMS Forum

R

rz

@rz
Unfollow Follow
About
Posts
5
Topics
4
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Handling of errors for ExternalParameter
    R rz
    Feature Requests

    Hello,

    1. I'd be usefull to notify admin that monitoring by using ExternalParameter/ExternalParameterShellExec commands is not working correctly.

    If external command is failed, I expect that
     - event should be raised (e.g. SYS_DCI_UNSUPPORTED or any other new event) 
     - "Data collection error" of the ExternalParameter command should be set to <<ERROR>>, so it could be at least checked externally via thresholds.

    I've tested these error conditions: invalid command is launched, script having no execution permission is launched, syntax-error happens in shell/perl scripts, command returns non zero return code. I've tested it on linux/solaris servers (version 1.2.14) with following result: default value (i.e. 0 for int) or first value send to stdout is returned, no error is shown in the logfile, no event is raised. So it is impossible to identify incorrect commands. The same happens for ExternalParameter and ExternalParameterShellExec parameters.

    1. It could be probably better to raise event automatically if error happens, without explicit testing of "Data collection error" status via threshold for each external parameter.  The same behaviour could be applied for external commands with execution timeout exceeded (note: for timeouted external commands "Data collection error" status is set to <<ERROR>> and error could be seen in the logfile, but no event is raised).

    2. I'd appreciate if it is possible to see raw output (stdout/stderr) for these external commands from the console.

    Kind Regards,
    Roman


  • Monitoring of processes
    R rz
    Support

    Hi,

    1. What will be the best solution for monitoring of processes having long command line ?

        For example java process with argument "firstCell01 centosNode01 nodeagent" (arguments are placed at the end). Overall length of command line is longer then 1024 characters (2500).

        A) It seems that solution via DCI Process.CountEx("java","firstCell01 centosNode01 nodeagent") takes into account only first 1024 characters.
           
            Should be NetXMS subagent (processCmdLine[1024] in proc.cpp) updated ?

        B) Or is it better solution to monitor it via ExternalParameter DCI (i.e. ps xxx | grep yyy)

    1. Note: There are no values in column "Command Line" in <<Table>> System.Processes, other columns are populated correctly.
          I'm not sure if it works as expected.

    Kind Regards,
    Roman


  • Status calculation
    R rz
    Feature Requests

    Hi,

    Is status calculation (propagate and calculate) supported for business services ?
    It seems it is not working (tested on 1.2.14)

    Kind Regards,
    Roman


  • nxevent
    R rz
    Feature Requests

    Hi,

    Thank you for quick reply 🙂 

    During testing I've found following behaviour which I suppose is not correct:

    During import of configuration (e.g. events), user events (id > 100000) are not correctly replaced in the case event name and/or event id already exist. Events are always appended as new ones (with new id) regardless any checkbox is selected. Also more events can have the same name as uniqueness of name is not checked (there is no constrain).

    tested on 1.2.14, windows version

    Kind Regards,
    Roman


  • nxevent
    R rz
    Feature Requests

    Hello,

    I'd be very usefull to enhance nxevent utility for ability to send event by using event's name (instead of event_id code).

    Another not so important notes:

    • nxevent command should exit with non zero return code if sending of event was not successfull.

    • implementation of any kind of persistence (e.g. buffering of events at the sender's side) is welcomed for event sending utility to overcome situations like: short lasting server unavailability or broken network communication
        note: nxevent -w parameter seems it is not applied for this use case

    And thanks for nice software.

    Kind Regards,
    Roman

  • Login

  • Don't have an account? Register

  • Login or register to search.
Powered by NodeBB Contributors
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups