Configuring

Network management technology implies presence of two sides: managing (Iotellect Network Manager in our case) and managed (i.e. network devices, and services/applications they run). Both sides should be properly configured.

System configuration is covered in Configuring Iotellect Network Manager section. If you are new to the product, check the following tasks:

• Register devices for management and monitoring. You can do it either manually or automatically (using discovery). It's a good idea to configure first several devices manually, as this will help you to better understand various aspects of this task. As the next step, when you need to manage and monitor more devices you'll master automatic discovering procedures.

• The task of manual registering devices is tightly coupled with the task of their configuration, i.e. adjusting parameters for them. You should master this task really well as it is literally crucial one for successful network management and monitoring.

• Setup monitoring tools (e.g. alerts, charts or reports) for registered devices. Refer to the monitoring section to familiarize yourself with available tools and types of monitoring they provide.

The task of configuring managed side cannot be fully covered, since there is a vast amount of different hardware and software products that can be managed or monitored. If you are not familiar with configuration issues of your devices, services and applications, leave their default settings at this stage. With gaining more experience and skills you'll get back to this subject and customize your managed items for better interaction with Iotellect Network Manager.

Refer to Configuring Environment section to get information about some commonly experienced issues.

In production systems where the collection volume is significant, ensure that the system is configured to use an appropriate relational database.

Furthermore, event storage configuration must be appropriate for the type of queries that will run against the collected data. Data in the event data table is serialized when stored in a database, creating a “blob” of data which must be de-serialized in order to be read. This has implications for storage methods, depending on what kind of queries will be run against the events.

• If the majority of queries will not search against the serialized data in the event data table , but instead only query based on context, timestamp, or level of the event, than simply ensure that the event storage database is able to process incoming events.

• If queries will search against data in the event data table, then it may be necessary to store the data from each event in a “flat” data structure in order to optimize queries. Generally, this means extracting the data which will be queried from the event data table for each event instance, and saving it using persistence bindings. Another solution is using a class to store events.

Was this page helpful?

Tell us more

Send

Thank you!