Pls replace – with - in commands, DOC-70
This commit is contained in:
uldis
Tatjana Dubrovica
parent
f0314f0b2a
commit
30fe43b552
13 changed files with 29 additions and 29 deletions
|
|
@ -101,7 +101,7 @@ msgid ""
|
|||
"on all objects that contains this :guilabel:`Container`. Every object has "
|
||||
"set of attributes; some of them are common (like :guilabel:`id` and "
|
||||
":guilabel:`name` or :guilabel:`status`), while other depends on object "
|
||||
"class – for example, only :guilabel:`Node` objects have attribute "
|
||||
"class - for example, only :guilabel:`Node` objects have attribute "
|
||||
":guilabel:`SNMP community string`. There are default attributes and custom "
|
||||
"attributes defined either by user or integrated application via NetXMS API."
|
||||
msgstr ""
|
||||
|
|
@ -109,11 +109,11 @@ msgstr ""
|
|||
# 71ea474760a044ebb1260f8c707489f4
|
||||
#: ../../concepts.rst:64
|
||||
msgid ""
|
||||
"NetXMS has eight top level objects – ``Entire Network``, ``Service Root``, "
|
||||
"NetXMS has eight top level objects - ``Entire Network``, ``Service Root``, "
|
||||
"``Template Root``, ``Policy Root``, ``Network Map Root``, ``Dashboard "
|
||||
"Root``, ``Report Root``, and ``Business Service Root``. These objects served"
|
||||
" as an abstract root for appropriate object tree. All top level objects has "
|
||||
"only one editable attribute – name."
|
||||
"only one editable attribute - name."
|
||||
msgstr ""
|
||||
|
||||
# 769958afaabe4992891adb62fac9d31d
|
||||
|
|
@ -259,7 +259,7 @@ msgid ""
|
|||
"checking whether that port is available. For the predefined standard "
|
||||
"services the system will also check whether an appropriate response is "
|
||||
"returned. In case of SMTP, the system will send a test mail, in case of POP3"
|
||||
" – try to log in with a certain user, in case of HTTP – check whether the "
|
||||
" - try to log in with a certain user, in case of HTTP - check whether the "
|
||||
"contents of a desired web page correspond to a certain given template. As "
|
||||
"soon as the Network Service object is created, it will be automatically "
|
||||
"included into the status poll. Each time when the status poll for the "
|
||||
|
|
@ -327,7 +327,7 @@ msgstr ""
|
|||
# 3290ea85df294eb19994aab8dc1129dd
|
||||
#: ../../concepts.rst:165
|
||||
msgid ""
|
||||
"Object representing complicated condition – like \"cpu on node1 is "
|
||||
"Object representing complicated condition - like \"cpu on node1 is "
|
||||
"overloaded and node2 is down for more than 10 minutes\"."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -218,7 +218,7 @@ msgstr "Политика обработки событий"
|
|||
msgid ""
|
||||
"List of rules which defines system reaction on :term:`events <Event>`. All "
|
||||
"events are matched against list of rules in Event Processing Policy, if "
|
||||
"match is found – configured actions are executed."
|
||||
"match is found - configured actions are executed."
|
||||
msgstr ""
|
||||
|
||||
# 0ae9467189af43408c88a3e473abda72
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ msgstr ""
|
|||
|
||||
# d3062a9b925547f8b93bcf61590bacda
|
||||
#: ../../object-management.rst:18
|
||||
msgid "Containers – bind/unbind"
|
||||
msgid "Containers - bind/unbind"
|
||||
msgstr ""
|
||||
|
||||
# 459b92103c90469e994c887baa63e62c
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ msgstr ""
|
|||
|
||||
# 7bb3b91370a348fe8f0eee372a1928b2
|
||||
#: ../../quickstart.rst:8
|
||||
msgid "(clean system after install; setup minimal monitoring – CPU of FS)"
|
||||
msgid "(clean system after install; setup minimal monitoring - CPU of FS)"
|
||||
msgstr ""
|
||||
|
||||
# 38474ccbd4204cb79cb2a2c4ea31a5db
|
||||
|
|
|
|||
|
|
@ -669,7 +669,7 @@ following:
|
|||
- X
|
||||
-
|
||||
-
|
||||
* - File manager – all write operations, e.g. file or folder creation, deletion, etc. (also requires enabling file manager and specifying root folder in agent configuration file)
|
||||
* - File manager - all write operations, e.g. file or folder creation, deletion, etc. (also requires enabling file manager and specifying root folder in agent configuration file)
|
||||
- X
|
||||
-
|
||||
-
|
||||
|
|
|
|||
|
|
@ -36,17 +36,17 @@ right on all objects that this :guilabel:`Container` contains.
|
|||
|
||||
Every object has set of attributes; some of them exist for all objects (like
|
||||
:guilabel:`id` and :guilabel:`name` or :guilabel:`status`), while other depend
|
||||
on object class – for example, only :guilabel:`Node` objects have attribute
|
||||
on object class - for example, only :guilabel:`Node` objects have attribute
|
||||
:guilabel:`SNMP community string`. In addition to the above mentioned
|
||||
attributes, it's possible to define custom attributes. This can be done by user
|
||||
in the Management Client, from NXSL script or by external application via
|
||||
|product_name| API.
|
||||
|
||||
|product_name| has seven top level objects – ``Entire Network``, ``Service
|
||||
|product_name| has seven top level objects - ``Entire Network``, ``Service
|
||||
Root`` (named "Infrastructure Services" after system installation), ``Template
|
||||
Root``, ``Asset Root``, ``Network Map Root``, ``Dashboard Root`` and ``Business
|
||||
Service Root``. These objects serve as an abstract root for an appropriate
|
||||
object tree. All top level objects have only one editable attribute – name.
|
||||
object tree. All top level objects have only one editable attribute - name.
|
||||
|
||||
|
||||
.. list-table::
|
||||
|
|
@ -135,7 +135,7 @@ object tree. All top level objects have only one editable attribute – name.
|
|||
can be configured as a part of a rack.
|
||||
- - Node
|
||||
* - Condition
|
||||
- Object representing complicated condition – like "cpu on node1 is
|
||||
- Object representing complicated condition - like "cpu on node1 is
|
||||
overloaded and node2 is down for more than 10 minutes". Conditions may
|
||||
represent more complicated status checks because each condition can have
|
||||
a script attached. Interval for evaluation of condition status is
|
||||
|
|
@ -497,7 +497,7 @@ Network discovery
|
|||
-----------------
|
||||
|
||||
|product_name| can detect new devices and servers on the network and automatically
|
||||
create node objects for them. Two modes are available – passive and active.
|
||||
create node objects for them. Two modes are available - passive and active.
|
||||
|
||||
In passive mode server will use only non-intrusive methods by querying ARP and
|
||||
routing tables from known nodes. Tables from the server running |product_name| are
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Glossary
|
|||
Event Processing Policy
|
||||
List of rules which defines system reaction on :term:`events <Event>`.
|
||||
All events are matched against list of rules in Event Processing Policy, if
|
||||
match is found – configured actions are executed.
|
||||
match is found - configured actions are executed.
|
||||
|
||||
Infrastructure services
|
||||
System :term:`container <Container>` which can be used by Administrator to
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Syslog Monitoring
|
|||
|product_name| has built-in syslog server, which can be used to receive logs
|
||||
from network devices and servers. It is also possible to parse incoming syslog
|
||||
messages in a way similar to Windows Event Log monitoring. To parse syslog
|
||||
messages, ``LOGWATCH`` subagent is not required – parsing is done by the server
|
||||
messages, ``LOGWATCH`` subagent is not required - parsing is done by the server
|
||||
itself. You only need to define monitoring rules in
|
||||
:menuselection:`Configuration --> Syslog Parser`
|
||||
|
||||
|
|
@ -263,7 +263,7 @@ additional options:
|
|||
|
||||
Inside the ``<rule>`` section there are the following additional tags:
|
||||
``<match>``, ``<description>``, ``<event>``, and ``<context>``. Only
|
||||
``<match>`` section is mandatory – it specifies regular expression against
|
||||
``<match>`` section is mandatory - it specifies regular expression against
|
||||
which log record should be matched. All other tags are optional and define
|
||||
parser behavior if a record matches the regular expression.
|
||||
|
||||
|
|
|
|||
|
|
@ -154,7 +154,7 @@ MACaddress
|
|||
|
||||
This section is used to list previously searched MAC addresses or to start a new
|
||||
search by scanning a barcode value (this feature needs the installation of Barcode
|
||||
Scanner from Zxing Team – freely available on the Google Play), by input it manually
|
||||
Scanner from Zxing Team - freely available on the Google Play), by input it manually
|
||||
or by getting it directly from a node via the “Find Switch port” command.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ User Interface
|
|||
|
||||
All reporting-related operations are available in Management Client in a
|
||||
separate :guilabel:`Reporting` perspective. Perspective contains two main areas
|
||||
– list of available reports on the left and report details view on the right.
|
||||
- list of available reports on the left and report details view on the right.
|
||||
Details view show information about currently selected report.
|
||||
|
||||
.. figure:: _images/reporting_perspective.png
|
||||
|
|
@ -166,8 +166,8 @@ Report definitions are .jar files prepared by Jaspersoft® Studio. During
|
|||
operation reporting server scans workspace/definitions directory for \*.jar
|
||||
files. Each file is unpacked into it's own folder based on jar name (e.g.
|
||||
"report1.jar" will be unpacked into "report1"). Each archive should contain at
|
||||
least one file – "main.jrxml", which is main report definition. It can also
|
||||
contain subreports, images – or anything else, supported by Jasper Reports. Any
|
||||
least one file - "main.jrxml", which is main report definition. It can also
|
||||
contain subreports, images - or anything else, supported by Jasper Reports. Any
|
||||
additional resources should be referenced using paths relative to root folder of
|
||||
unpacked report, which is set as additional parameter "SUBREPORT_DIR" (e.g.
|
||||
"$P{SUBREPORT_DIR}/logo.png").
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ In many parts of the system, fine tuning can be done by using |product_name| bui
|
|||
scripting language called NXSL (stands for |product_name| Scripting Language). NXSL was
|
||||
designed specifically to be used as embedded scripting language within |product_name|,
|
||||
and because of this has some specific features and limitations. Most notable is
|
||||
very limited access to data outside script boundaries – for example, from NXSL
|
||||
very limited access to data outside script boundaries - for example, from NXSL
|
||||
script you cannot access files on server, nor call external programs, nor even
|
||||
access data of the node object other than script is running for without
|
||||
explicit permission. NXSL is interpreted language – scripts first compiled into
|
||||
explicit permission. NXSL is interpreted language - scripts first compiled into
|
||||
internal representation (similar to byte code in Java), which is then executed
|
||||
inside NXSL Virtual Machine. Language syntax and available functions can be
|
||||
found in `NXSL documentation <https://www.netxms.org/documentation/nxsl-latest/>`_.
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ SMTP, FTP, HTTP, HTTPS, Telnet and Custom protocol type. For Custom protocol,
|
|||
user should define TCP port number and the system will be checking if it's
|
||||
possible to establish connection to that port. For the predefined standard
|
||||
services the system will also check whether an appropriate response is returned.
|
||||
In case of SMTP, the system will send a test mail, in case of POP3 – try to log
|
||||
in with a certain user, in case of HTTP – check whether the contents of a
|
||||
In case of SMTP, the system will send a test mail, in case of POP3 - try to log
|
||||
in with a certain user, in case of HTTP - check whether the contents of a
|
||||
desired web page correspond to a certain given template. As soon as the Network
|
||||
Service object is created, it will be automatically included into the status
|
||||
poll. Each time when the status poll for the particular node is carried out, all
|
||||
|
|
|
|||
|
|
@ -22,17 +22,17 @@ right on all objects that this :guilabel:`Container` contains.
|
|||
|
||||
Every object has set of attributes; some of them exist for all objects (like
|
||||
:guilabel:`id` and :guilabel:`name` or :guilabel:`status`), while other depend
|
||||
on object class – for example, only :guilabel:`Node` objects have attribute
|
||||
on object class - for example, only :guilabel:`Node` objects have attribute
|
||||
:guilabel:`SNMP community string`. In addition to the above mentioned
|
||||
attributes, it's possible to define custom attributes. This can be done by user
|
||||
in the Management Client, from NXSL script or by external application via
|
||||
|product_name| API.
|
||||
|
||||
|product_name| has seven top level objects – ``Entire Network``, ``Service
|
||||
|product_name| has seven top level objects - ``Entire Network``, ``Service
|
||||
Root`` (named "Infrastructure Services" after system installation), ``Template
|
||||
Root``, ``Asset Root``, ``Network Map Root``, ``Dashboard Root`` and ``Business
|
||||
Service Root``. These objects serve as an abstract root for an appropriate
|
||||
object tree. All top level objects have only one editable attribute – name.
|
||||
object tree. All top level objects have only one editable attribute - name.
|
||||
|
||||
|
||||
.. list-table::
|
||||
|
|
@ -120,7 +120,7 @@ object tree. All top level objects have only one editable attribute – name.
|
|||
can be configured as a part of a rack.
|
||||
- - Node
|
||||
* - Condition
|
||||
- Object representing complicated condition – like "cpu on node1 is
|
||||
- Object representing complicated condition - like "cpu on node1 is
|
||||
overloaded and node2 is down for more than 10 minutes". Conditions may
|
||||
represent more complicated status checks because each condition can have
|
||||
a script attached. Interval for evaluation of condition status is
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue